Re: Getting shadow into shape
On Monday 05 March 2007 01:43, Bruce Dubbs wrote: Matthew Burgess wrote: Now, we can either install a 'users' group as GID 1000, or we can change the default in /etc/default/useradd to one of the GIDs in /etc/passwd. Personally, I'd prefer the former, as I can't see a suitable default group in /etc/passwd. I'd prefer a default of 200 or 500. No real reason, but 1000 seems too big to me. Well, Kubuntu uses gid 100 for their 'users' group, so that seems a sane enough default. My *real* preference would be for the system to automatically make a new group with the same name as the user if -g is not specified and use that. I think that's how RedHat does it. Kubuntu does this too. Unfortunately, it doesn't look like it'd be trivial enough to get this functionality in to LFS. This is from their almost entirely commented out /etc/default/useradd file: # Please be aware that Debian's adduser defaults to user groups # which means that one group is created for each user # There is no way to achieve this with useradd which must remains a low # level utility # GROUP=100 If I get some time I'll figure out just how issuing `useradd' manages to invoke `adduser' behaviour though! I have no problem with LFS installing a mail group using a vule of 34. That would require a minor adjustment to BLFS, but it wouldn't be a big problem. Great. My bigger problem is why is shadow's useradd creating a user mailbox at all. It would seem to me that assumptions are being made that are not valid for most systems. My mailbox is in ~/.mozilla. 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 the second error message is caused because '/home/users' is specified in /etc/default/useradd but we don't create that directory. Again, this seems that assumptions are being made that are not warranted. They may have been at one time, but what goes in /home besides users? Make the default /home. OK, the default gid and home directory can be changed via the command line: useradd -D -g 100 -b /home So, I'm thinking now of adding two new groups to LFS - mail=34 and users=100. Then, we'll use the `useradd -D' and `sed' commands above to change shadow's defaults. I'll leave this for a couple of days for further comments, but all going well Shadow will start behaving itself shortly after that :-) Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Getting shadow into shape
Matthew Burgess wrote: So, I'm thinking now of adding two new groups to LFS - mail=34 and users=100. Then, we'll use the `useradd -D' and `sed' commands above to change shadow's defaults. Sounds sane to me. As a bonus, the users=100 setting goes logically with nobody=99. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Getting shadow into shape
Matthew Burgess wrote:
# Please be aware that Debian's adduser defaults to user groups
# which means that one group is created for each user
# There is no way to achieve this with useradd which must remains a low
# level utility
# GROUP=100
If I get some time I'll figure out just how issuing `useradd' manages to
invoke `adduser' behaviour though!
Well, adduser is not part of shadow; it's a separate Debian program or
script or something, which has its own configuration. Based on the
configuration, adduser invokes useradd with the correct options (maybe
even overriding most of the /etc/defaults/useradd file?).
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.
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 also
probably patched it to change the behavior of useradd and usermod
regarding groups, but I'm not sure on that either. If I did, the patch
I used is attached. This patch may be what makes my useradd do user-groups.
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. The only issue is it's a lot of slashes. We might be able
to get away with something like:
sed -i 's/(CREATE_MAIL_SPOOL=)yes/\1no/'
but that may be confusing. I suppose if we don't have any other
instances of sed backreferences in the book, this might be a good way to
show them to the reader too.
Well, whatever. I think any of these will work for now. :-)
useradd -D -g 100 -b /home
So, I'm thinking now of adding two new groups to LFS - mail=34 and users=100.
Then, we'll use the `useradd -D' and `sed' commands above to change shadow's
defaults.
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... ;-) )
--- shadow-4.0.18.1.orig/src/useradd.c 2006-07-28 19:42:48.0 +0200
+++ shadow-4.0.18.1/src/useradd.c 2006-08-04 09:24:34.0 +0200
@@ -203,13 +203,17 @@
long gid;
char *errptr;
+ struct group* grp = getgrnam (grname);
+ if (grp)
+ return grp;
+
gid = strtol (grname, errptr, 10);
if (*errptr || errno == ERANGE || gid 0) {
fprintf (stderr,
_(%s: invalid numeric argument '%s'\n), Prog,
grname);
exit (E_BAD_ARG);
}
- return getgrnam (grname);
+ return getgrgid (gid);
}
static long get_number (const char *numstr)
--- shadow-4.0.18.1.orig/src/usermod.c 2006-07-28 19:42:48.0 +0200
+++ shadow-4.0.18.1/src/usermod.c 2006-08-04 09:24:21.0 +0200
@@ -165,13 +165,17 @@
long val;
char *errptr;
+ struct group* grp = getgrnam (grname);
+ if (grp)
+ return grp;
+
val = strtol (grname, errptr, 10);
if (*errptr || errno == ERANGE || val 0) {
fprintf (stderr, _(%s: invalid numeric argument '%s'\n), Prog,
grname);
exit (E_BAD_ARG);
}
- return getgrnam (grname);
+ return getgrgid (val);
}
/*
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Released jhalfs-2.2
The jhalfs development team is pleased to announce the release of jhalfs-2.2. New features in this version: - Better support for CLFS Sysroot and CLFS Embedded books - Support for BLFS-6.2.0 - Added customized tools support to all books - Added blfs-tool support to all books (except CLFS Embedded that can't use it) - Several bugs fixes and code clean-up The jhalfs-2.2 tarball can be downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/jhalfs-2.2.tar.bz2 The list of supported books can be found at http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks Please, try it out and send any comments or bugs you find to the alfs-discuss mailing list. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
