On Mar 6, 2009, at 9:23 AM, Nigel Kersten wrote:
>
> On Thu, Mar 5, 2009 at 1:49 PM, Luke Kanies <[email protected]> wrote:
>>
>> On Mar 5, 2009, at 2:56 PM, Nigel Kersten wrote:
>>
>>>
>>> :maximum_uid => [4294967290, "The maximum allowed UID. Some
>>> platforms use negative UIDs
>>> but then ship with tools that do not know how to handle
>>> signed ints, so the UIDs show up as
>>> huge numbers that can then not be fed back into the
>>> system. This is a hackish way to fail in a
>>> slightly more useful way when that happens."],
>>>
>>> So this is a problem on OS X, and I only just noticed it.
>>>
>>> $ dscl . read /groups/nobody PrimaryGroupID
>>> PrimaryGroupID: -2
>>>
>>> $ ruby -e "require 'etc'; puts Etc.getgrnam('nobody').gid"
>>> 4294967294
>>>
>>> $ id nobody
>>> uid=4294967294(nobody) gid=4294967294(nobody)
>>> groups=4294967294(nobody)
>>>
>>> Obviously we can work around this by increasing maximum_uid, but I'm
>>> wondering why we have this setting at all? Is there some other
>>> problem
>>> it solves that I'm not aware of?
>>>
>>> At least on OS X, the reverse process works fine.
>>>
>>> # ls -l /tmp/foo
>>> -rw-r--r-- 1 nigelk wheel 13 Mar 4 14:36 /tmp/foo
>>>
>>> # chgrp 4294967294 /tmp/foo
>>>
>>> # ls -l /tmp/foo
>>> -rw-r--r-- 1 nigelk nobody 13 Mar 4 14:36 /tmp/foo
>>
>> The problem is that some tools give -2 as the UID and other tools
>> gives 4 quadrillion as the UID, so we always consider them out of
>> sync
>> and do stupid things.
>
> So I can't actually find any places where OS X reports the negative
> uid in Puppet for file resources. It will report negative ones for the
> user/group providers, but they're all contained in the
> directoryservice nameservice code.
>
> The Etc module seems to quite consistently report the unsigned
> integer.
>
> Was the inconsistent reporting perhaps seen on other platforms or
> before the Etc module was consistently used or something?
I'm probably actually more thinking of the inability to use this value
for files, rather than just for users. Maybe the file's owner and
group properties should just try to use the values, but recognize the
failure or something/
>
>>
>> Most likely, the right approach here is to use dscl for both reading
>> and writing, rather than relying on any Ruby tools.
>
> While there would be some advantages to that, it would be a bit
> frustrating not to be able to share all the existing posix code for
> this kind of work :(
Well, we're actually looking at directly parsing /etc/{passwd,group}
for a client, because the Etc module hits their ldap directory, too.
So it may be that we don't use much of that POSIX code anyway.
>> Here's a good demonstration of where it all goes to hell in a
>> handbasket. This code:
>>
>>
>> #!/usr/bin/ruby
>>
>> require 'etc'
>>
>> File.open("/tmp/testing", "w") { |f| f.puts "eh" }
>>
>> uid = Etc.getpwnam("nobody").uid
>> File.chown(uid, nil, "/tmp/testing")
>>
>> -----------------
>> Fails with:
>>
>> l...@phage $ sudo test.rb
>> /Users/luke/bin/test.rb:8:in `chown': bignum too big to convert into
>> `long' (RangeError)
>> from /Users/luke/bin/test.rb:8
>> l...@phage $
>>
>> So you can't use the same value end to end.
>>
>> Yes, (I assume) we could build a complicated system to switch between
>> signed and unsigned ints. Or, we could just stick our fingers in our
>> ears, say "nyah nyah" a hundred times, and act like it's not a real
>> problem.
>>
>> At this point, it happens so rarely that the latter has been at least
>> acceptable.
>>
>> --
>> To my embarrassment I was born in bed with a lady.
>> --Wilson Mizner
>> ---------------------------------------------------------------------
>> Luke Kanies | http://reductivelabs.com | http://madstop.com
>>
>>
>>>
>>
>
>
>
> --
> Nigel Kersten
> Systems Administrator
> Tech Lead - MacOps
>
> >
--
Susskind's Rule of Thumb:
Don't ask what they think. Ask what they do.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
