On Thu, Jul 03, 2003 at 04:15:54PM -0500, Gunnar Wolf wrote: > David B Harris dijo [Thu, Jul 03, 2003 at 04:23:03AM -0400]: > > I certainly agree with the general idea, as well as the specific > > proposal of allocating 2^16 UIDs for Samba's idmap usage. > > > > That being said, will Sarge release with the minimum requisites for the > > 2^32 UIDs? If so, I'm happy. But somebody should ask the RM to be sure. > > Otherwise, I would think it'd have to wait until Sarge+1. > > > > Specifically, quota stuff. Every tree but Marcello's has implemented 32 > > bit quotas, as far as I know, but not his. So 32 bit quotas aren't > > "official" yet. Might need Xu to patch the default kernel images. > Not only that... Are 32-bit UIDs legal in *BSD or HURD? I don't think > Samba should be limited to Linux-only installs. You mean the length of uids on the Hurd is limited by something other than the available virtual memory? >:) To be clear, Samba will still be useable in many cases without such an available uid range. It's only when someone tries to create an ACL on the Samba fileserver that references a foreign SID that the absence is felt. Now, when you're trying to deploy Samba on a network with multiple NT domains which have trust relationships, this absence will be felt acutely. When you're deploying it in a small office network with one domain and Samba is the PDC, it's not much of an issue. So the fact that 32-bit uids are currently unsupported on some Debian platforms is less of an issue, IMHO, than making sure that whatever range we choose can reasonably meet the needs of most users for the foreseeable future. Having a default range that's inaccessible to some (or even to everyone, in the worst case) is better than having a default range that's available to all, but which fills up within a few months or a year and leaves admins stuck with the task of migrating filesystem ACLs by hand. -- Steve Langasek postmodern programmer
Attachment:
pgp2AVAt1tBJD.pgp
Description: PGP signature