On Nov 7 07:37, Christian Franke wrote: > Corinna Vinschen wrote: > >On Nov 6 21:06, Corinna Vinschen wrote: > >>On Nov 6 20:51, Christian Franke wrote: > >>>Corinna Vinschen wrote: > >>>>On Nov 6 19:34, Christian Franke wrote: > >>>>>But why does > >>>>> mkpasswd -l (no host) -- adds a prefix > >>>>> mkpasswd -l THISHOST -- does not add a prefix > >>>>>when the machine is in a domain? Not consistent, IMO. > >>>>That's right. The reason is that the machine name is treated as a > >>>>foreign machine. In theory, this should always generate names > >>>>with prefixed machine name, but this is an entirely different > >>>>code path in mkpasswd/mkgroup. I guess this should be fixed. > >>>> > >>>>I wouldn't be unhappy about help... > >>>I would only fix it back to the old behaviour (mkpasswd -l = no prefix), > >>>sorry :-) > >>> > >>>At my real job we run several build & test machines which are members of a > >>>domain but use various local test user accounts (with no collision with > >>>domain users due to name space rules). Loosing the ability to use > >>>prefix-less local user names would break various existing test scripts > >>>(which are also used on Linux). > >>> > >>>Generated emails would have a from address with HOST+USER name part which > >>>might give interesting results if the mail system somehow interprets the > >>>NAME+EXTENSION address syntax... > >>> > >>>So there are use cases where prefix-less local user names are needed. This > >>>should be still supported, e.g. by mkpasswd -l, IMO. > >>But then... why not keep mkpasswd -L and use that instead? > >On second thought, it's completely wrong to allow printing local > >accounts from another machine without prefix. > > I agree. > > >In theory there should be only one option -l [machine], which prints the > >local accounts of the current machine unprefixed (standalone machine) or > >prefixed (domain machine), and always prefixed for a foreign machine. > >The -L option can just go away. > > I disgree. > > Why not keep the old behavior of -l/-L for user names of current machine for > those uses cases which rely on it?
You are always free to change the passwd/group files manually: $ mkpasswd -l | sed -e 's/^[^:]*+//' > /etc/passwd Does a system tool really have to generate a scheme which might lead to collisions? The Administrator account is only one of them: $ mkpasswd -l -d | sed -e 's/^[^:]*+//' | grep Administrator: Administrator:*:197108:197121:U-LOCAL_MACHINE\Administrator,[...] Administrator:*:1049076:1049089:U-DOMAIN\Administrator,[...] > Those users who are happy with prefixed > local user names and non-prefixed domain user names would simply no longer > need to use mkpasswd (which is good). > > Package search shows 156 usr/bin/*-config scripts. How many of these use > mkpasswd? I don't know, but I'm trying to fix up at least the ones I have under control. The other will follow over time. > BTW: None of my Linux machines have local user names with own HOSTNAME as > prefix :-) Your Linux machines usually don't have to maintain user and group accounts from various account DBs. This is all nice and easy in a single domain scenario, but as soon as you maintain multiple domains, you will have name collisions. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpjcZIjSNiLn.pgp
Description: PGP signature