On Monday 05 March 2007 23:38, Bryan Kadzban wrote: > Matthew Burgess wrote: > > Do you know how useradd works if GROUP is commented out in the config > file? I'd assume it either gives you an error or creates a group with > the same name as the user, but I don't know for sure.
See src/useradd.c:78-86 /* * These defaults are used if there is no defaults file. */ static gid_t def_group = 100; static const char *def_gname = "other"; static const char *def_home = "/home"; static const char *def_shell = ""; static const char *def_template = SKEL_DIR; static const char *def_create_mail_spool = "no"; But, see below... > My /etc/default/useradd doesn't have a GROUP line in it at all, and > useradd creates a new group with the same name as the user (and the same > GID as the user's UID). I *think* I have shadow 4.0.18.1, but I can't > tell for sure because none of the binaries support --version. I observe the same behaviour with `useradd' from shadow-4.0.18.1 with that patch applied. The patch fixes an error whereby the '-g' option of useradd(8) and usermod(8) don't accept strings as their arguments. I can't see how it would affect this behaviour we're observing. None of this is actually documented to work this way though! > > It's because of the 'CREATE_MAIL_SPOOL=yes' in /etc/default/useradd. I > > can't see a way of changing this via the command line, unlike the default > > home directory and gid (see below). So, I think the following will have > > to do: > > > > sed -i 's/yes/no/' /etc/default/useradd > > Or this (which is a bit more specific): > > sed -i '/CREATE_MAIL_SPOOL/s/yes/no/' /etc/default/useradd > > I don't know whether any other lines in the file will ever have a "yes" > value set, but if so, this will skip everything except the one we want > to change. Yeah, I wondered the same thing, but as this is being done prior to installation, it's easy enough to verify that we're only changing the lines we need to. > Do we need the mail group if we turn off CREATE_MAIL_SPOOL? We may not > need the users group either, if we remove the GROUP line from the config > file, but maybe that should be a local policy decision. (I know what > I'll decide, in any case... ;-) ) Well, the way I see it is that although we provide a default configuration, the system should be able to handle the alternative configuration if, as in this case, it is easy enough to do. Likewise for the default group, though now I'm left wondering how one would get the old behaviour of actually using the default group back! Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
