Hi Danny, Am Samstag, den 02.01.2021, 16:04 +0100 schrieb Danny Milosavljevic: > Hi Leo, > > > > Considering the goal of Guix, it's weird that with Guix, one > > > needs to > > > store&restore /etc/passwd at all. It's state, but not very > > > useful > > > one. > > > I mean that's how it is right now--but it's still weird. > > > With /etc/shadow maybe there's a slightly better case, but note > > > that > > > the key > > > to find stuff in /etc/shadow can't be the uid--the uid isn't even > > > in > > > there! > > AFAIU yes, it's state, but not one that Guix can simply do away > > with. > > It's easily possible to recreate /etc/passwd from scratch if the uids > are > always specified in <user-account>s and thus /etc/passwd would not > need to > be persistent state anymore. Right now everything from /etc/passwd > except > the uid and the comment is already specified in <user-account>. > > So Guix can indeed simply do away with the persistent state of > /etc/passwd--that's why I suggested specifying the uids in the first > place. > > (By now I don't think that's the best way to make UIDs stable, but > it's > factually incorrect to assert that Guix can't simply do away with > that > persistent state specifically. It can.) > > > There is not yet a syntax for keeping secrets, which would be > > needed to > > fully populate /etc from config.scm. Perhaps we'll get there some > > day. > > /etc/passwd does not contain secrets. Neither does /etc/group. > > And /etc/shadow doesn't contain uids. > > So there is no conflict. Point taken, it is indeed possibly to do away with one of those files, but looking at them as a trio (as one ought to imo), I don't think removing one while keeping the other(s) is the way to go.
Also if you do go that route, you would need a way to specify that your passwd has hitherto been different to all other Guix installations; hence forcing you to make system account [GU]IDs configurable once again. Regards, Leo
