I am still in the familiarisation and testing phase of my puppet implementation, and have a question for the enlightened: Is there an upper limit to the numeric user ID that puppet recognises? Here is what I have so far: System is RHEL4, puppet 0.23.1 All users are defined in LDAP rather than in /etc/password, and their numeric user IDs are sourced from LDAP as well. These numeric IDs can be quite large numbers. I am able to create home directories and change the ownership correctly. Then I try to create a public key. This succeeds for users with numeric IDs of 17874 and 30304, but fails for users with IDs of 86705 and 94587. Under puppet version 0.22.? I successfully created public keys for users with IDs 117311 and 123876. I deleted the id_dsa files for the user with ID 117310, and it was successfully recreated. I also try to create authorized_keys files and change the ownership of that to the username. Again, that is successful for the 2 users with the lower numeric IDs, but fails for the others. For the user with the ID of 123876, the log message is: warning: //basenode/key-server/sysadm-staff/account[csabc]/File[/opt/ home/csabc /.ssh]/owner: current state is silly: 123876 I am using the classes from the Authorized_keys recipe. Thanks for any help, Anne Anne Zanotti Systems Support Information Services Division Flinders University Adelaide Australia
On Thu, Aug 30, 2007 at 01:16:49PM +0930, anne zanotti wrote:> I am still in the familiarisation and testing phase of my puppet > implementation, and have a question for the enlightened: > > Is there an upper limit to the numeric user ID that puppet recognises?Yes. lib/puppet/type/pfile/owner.rb:113: # On OS X, files that are owned by -2 get returned as really # large UIDs instead of negative ones. This isn''t a Ruby bug, # it''s an OS X bug, since it shows up in perl, too. if currentvalue > 120000 self.warning "current state is silly: %s" % currentvalue currentvalue = :silly end It''d probably be worth a bug report or patch or something to constrain that check to OS X. - Matt -- "All I care about [a linux distro] is it detect my hardware (non-Debian strengths), and teach me to fish instead of just giving me a smelly old fish (most people ''xcept Debian), and I guess don''t just give me a fish biology textbook (gentoo)." -- Tom (in d-devel)
On Aug 30, 2007, at 12:31 AM, Matthew Palmer wrote:> On Thu, Aug 30, 2007 at 01:16:49PM +0930, anne zanotti wrote: >> I am still in the familiarisation and testing phase of my puppet >> implementation, and have a question for the enlightened: >> >> Is there an upper limit to the numeric user ID that puppet >> recognises? > > Yes. lib/puppet/type/pfile/owner.rb:113: > > # On OS X, files that are owned by -2 get returned as really > # large UIDs instead of negative ones. This isn''t a Ruby bug, > # it''s an OS X bug, since it shows up in perl, too. > if currentvalue > 120000 > self.warning "current state is silly: %s" % currentvalue > currentvalue = :silly > end > > It''d probably be worth a bug report or patch or something to > constrain that > check to OS X. >I''d just remove the check, since the exact same behavior occurs in a _lot_ of other systems, including Linux. In fact I''d go so far as to say that most mainstream OSes treat a negative uid as an offset from the maximum UID rather than as an actual negative number... Whether that offset ends up above or below 120000 is simply a matter of whether the platform has 16-bit or 32-bit uids... critter:/tmp root# uname Darwin critter:/tmp root# grep nobody /etc/passwd nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false critter:/tmp root# touch foo critter:/tmp root# chown nobody foo critter:/tmp root# ls -ln foo -rw-r--r-- 1 4294967294 0 0 Aug 30 10:18 foo [root@dev1-mgmt-01 tmp]# uname Linux [root@dev1-mgmt-01 tmp]# grep nfsnobody /etc/passwd nfsnobody:x:-2:-2:Anonymous NFS User:/var/lib/nfs:/sbin/nologin [root@dev1-mgmt-01 tmp]# touch foo [root@dev1-mgmt-01 tmp]# chown nfsnobody foo [root@dev1-mgmt-01 tmp]# ls -ln foo -rw-r--r-- 1 4294967294 0 0 2007-08-30 14:03 foo Many linux systems (like Red Hat) include a user nobody as 65535 and nfsnobody as 65534, which correspond to uid -1 and -2 if you have 16- bit uids just so they can try and avoid the problem where negative offsets end up being different users on different platforms. -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire
Thanks for the replies, Matthew and Jason. I changed the limit check in 2 places in owner.rb: uid2name (line 12) had a check for "if id > 70000" - changing this to "if id > 370000" fixed the problem of not creating the keys retrieve (line113) had the check described by Matthew: "if currentvalue > 120000" - changing this to "if currentvalue > 320000" fixed the problem of not changing the owner and reporting the "state is silly". Thanks for your help, Anne On 30/08/2007, at 11:52 PM, Jason Kohles wrote:> On Aug 30, 2007, at 12:31 AM, Matthew Palmer wrote: > >> On Thu, Aug 30, 2007 at 01:16:49PM +0930, anne zanotti wrote: >>> I am still in the familiarisation and testing phase of my puppet >>> implementation, and have a question for the enlightened: >>> >>> Is there an upper limit to the numeric user ID that puppet >>> recognises? >> >> Yes. lib/puppet/type/pfile/owner.rb:113: >> >> # On OS X, files that are owned by -2 get returned as really >> # large UIDs instead of negative ones. This isn''t a Ruby bug, >> # it''s an OS X bug, since it shows up in perl, too. >> if currentvalue > 120000 >> self.warning "current state is silly: %s" % currentvalue >> currentvalue = :silly >> end >> >> It''d probably be worth a bug report or patch or something to >> constrain that >> check to OS X. >> > I''d just remove the check, since the exact same behavior occurs in a > _lot_ of other systems, including Linux. In fact I''d go so far as to > say that most mainstream OSes treat a negative uid as an offset from > the maximum UID rather than as an actual negative number... Whether > that offset ends up above or below 120000 is simply a matter of > whether the platform has 16-bit or 32-bit uids... > > > critter:/tmp root# uname > Darwin > critter:/tmp root# grep nobody /etc/passwd > nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false > critter:/tmp root# touch foo > critter:/tmp root# chown nobody foo > critter:/tmp root# ls -ln foo > -rw-r--r-- 1 4294967294 0 0 Aug 30 10:18 foo > > > [root@dev1-mgmt-01 tmp]# uname > Linux > [root@dev1-mgmt-01 tmp]# grep nfsnobody /etc/passwd > nfsnobody:x:-2:-2:Anonymous NFS User:/var/lib/nfs:/sbin/nologin > [root@dev1-mgmt-01 tmp]# touch foo > [root@dev1-mgmt-01 tmp]# chown nfsnobody foo > [root@dev1-mgmt-01 tmp]# ls -ln foo > -rw-r--r-- 1 4294967294 0 0 2007-08-30 14:03 foo > > > Many linux systems (like Red Hat) include a user nobody as 65535 and > nfsnobody as 65534, which correspond to uid -1 and -2 if you have 16- > bit uids just so they can try and avoid the problem where negative > offsets end up being different users on different platforms. > > -- > Jason Kohles > email@jasonkohles.com > http://www.jasonkohles.com/ > "A witty saying proves nothing." -- Voltaire > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-usersAnne Zanotti System Support Information Services Division Flinders University Adelaide Australia
On Aug 30, 2007, at 7:15 PM, anne zanotti wrote:> Thanks for the replies, Matthew and Jason. > > I changed the limit check in 2 places in owner.rb: > > uid2name (line 12) had a check for "if id > 70000" - changing this to > "if id > 370000" fixed the problem of not creating the keys > > retrieve (line113) had the check described by Matthew: "if > currentvalue > 120000" - changing this to "if currentvalue > 320000" > fixed the problem of not changing the owner and reporting the "state > is silly".Can you file this as a bug, please? -- Sabbagh''s Second Law: The biggest problem with communication is the illusion that it has occurred. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Aug 31, 2007, at 11:33 AM, Luke Kanies wrote:> On Aug 30, 2007, at 7:15 PM, anne zanotti wrote: > >> Thanks for the replies, Matthew and Jason. >> >> I changed the limit check in 2 places in owner.rb: >> >> uid2name (line 12) had a check for "if id > 70000" - changing this to >> "if id > 370000" fixed the problem of not creating the keys >> >> retrieve (line113) had the check described by Matthew: "if >> currentvalue > 120000" - changing this to "if currentvalue > 320000" >> fixed the problem of not changing the owner and reporting the "state >> is silly". > > Can you file this as a bug, please? >And file it as a ''this check needs to be removed'' bug, rather than as a ''these arbitrarily selected values need to be larger arbitrarily selected values''. Or if you really just have to have a maximum value to check it against, then it should be sizeof(int32) or greater. -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire