checks for maximum uid need to be removed

OSX allows negative uids (i.e. -2), which later become large unsigned ints. This is why there is a check for very large uids. A design decision needs to be made on how to handle this.

Ben <abnormaliti@clivepeeters.com.au> reports on the mailing list:

The following manifest is causing an error/warning and permissions are not set. i do not understanding why:

   file {   "/diskless/swaps":
              ensure  => directory,
              owner   => nfsnobody,
              group   => nfsnobody,
              mode    => 1777;
        }

The error is:

Fri Sep 21 14:53:05 EST 2007 //default/remote1/boot-server/File[/diskless/swaps]/owner (:warning): current state is silly: 4294967294
Fri Sep 21 14:53:05 EST 2007 //default/remote1/boot-server/File[/diskless/swaps]/owner (:notice): user 4294967294 does not exist

The user and group do exist:

# grep nfsnobody /etc/passwd
nfsnobody:x:4294967294:4294967294:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
# grep nfsnobody /etc/group
nfsnobody:x:4294967294:

The above problem was seen on a CentOS 5 x86_64.

The odd thing is that the very same manifest behaves as expected on a CentOS 5 i386 system. No complaints logged and permissions and mode are set correctly.

Both using puppet-0.23.2-1.el5

Debian etch does this too:

david@zion:~/Work/puppet/misspiggy/puppet-luke$ grep ^{test /etc/passwd test:x:-3:1005:test:/home/test:/bin/bash david@zion:~/Work/puppet/misspiggy/puppet-luke$ getent passwd test test:x:4294967293:1005:test:/home/test:/bin/bash david@zion:~/Work/puppet/misspiggy/puppet-luke$}

I Think the way to go forward on this is to munge incoming uids to unsigned int of the local architecture. This creates slightly unportable UIDs but on the other hand, useradd/groupadd do not accept negative values for uid/gid, so this could be disallowed completely too.

david@zion:~/Work/puppet/misspiggy/puppet-luke$ grep ^test /etc/passwd
test:x:-3:1005:test:/home/test:/bin/bash
david@zion:~/Work/puppet/misspiggy/puppet-luke$ getent passwd test
test:x:4294967293:1005:test:/home/test:/bin/bash

getting late ...

I don't see an actual solution to this. I initially added the 'silly' things because the only thing I can really do here is fail -- if I try to write out the value that I get back from the system, I just get a failure. That is, Etc will tell me the value is some huge unsigned int, I try to write that out, and I get a failure.

I've patched this a bit in [56aad69f8cdf8b0b08fdb7985014986223fa4455], increasing the max value and making it tunable, but I can't find a way to fix this problem, so I'm delaying it.

I think this is essentially unsurmountable at this point, and I'm closing the ticket unless someone can come up with an actual solution.

Marking #1169 as duplicate.

Mostly fixed in #1169.