"Michael Steffens" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Michael, > > Michael Fair wrote: > > The admin would have to rechown all the files from the > > old ids to the new ones, but a simple find command could > > probably manage that. > > > > How does that work? Any major wrinkles? > > I'm not feeling really comfortable with winbind assigning all > UIDs and GIDs on a system, as it does need to coexist with other > means and tools for Unix user management. > > Reassigning their IDs is a major pain, and often impossible. > > If winbind could only be used when taking over ID management > entirely, we would be in trouble. So this behaviour needs to > be at least optional...
Oh yes, entirely! Nothing I mentioned was an attempt to put winbind in control of all the UID/GIDs on a system. I personally have never used, nor even heard of a system that used UID/GIDs 100,000,000 and above. That's the address space that winbind would be using. Everything below that 0 through 99,999,999 would be reserved for the normal system (as I mentioned earlier in the post). But just because I haven't encountered doesn't mean it doesn't exist which was my primary concern (if the address space is in use, then it is not a solution and we'll need to come up with something else). The snippet you grabbed was part of an optional step 7 that an administrator could, if they were so inclined, use to get an existing UNIX user to be directly mapped to the new Windows User created by winbind (mostly because the admin doesn't want to specify the ACL for the unix user separate from the ACL for the Windows User). This not something winbind would do. This is only something an administrator would do manually (perhaps with the aid of some scripts, and only if it was found to actually be a valuable operation). If the existing UNIX UID is heavily ACLed then this of course would probably not be used. The two IDs would remain separated. If the UNIX admin was following the "best practices" recommendation and only assigning ACLs on the GIDs that Winbind created, then the same effect could be gotten by placing the UNIX user in the "private group" that Winbind created for the Windows User. The only purpose having winbind create a UNIX user serves is exactly that, to let the system have an honest to goodness UNIX user to use for operations in the system. The concept is: 1) Winbind only uses IDs 100,000,000 and above ( the bit friendly version is IDs 134,217,728 and above) 2) Each domain encountered gets its own 100,000,000 offset. So 100,000,000 for D1, 200,000,000 for D2, etc. 3) Winbind only creates GIDs, except in the case it has detected a Windows User, then it also creates a UID with the same number as the GID for that object (and for that object only) 4) Suggest that a "best practice" be adopted where only the GID gets ACLs on the local system (this might be unnecessary with the addition of the "Give users a UID as well" approach. The only thing this proposal really does is break up the UID/GID space into 100,000,000 offest segments, the first of which is for the UNIX system (Local_Machine if you will) and the rest for each Domain it encounters, up to 42 domains (or 31 domains if using the bit friendly version). (I personally thing that even 67,108,864 offsets is reasonable with up to 63 domains, but I've never deployed a large scale enterprise before so I don't know how big those numbers get) -- Michael --