On 5/19/12 5:59 AM, Dustin Cartwright wrote: > On Fri, May 18, 2012 at 10:55 PM, Alexander Hansen > <alexanderk.han...@gmail.com <mailto:alexanderk.han...@gmail.com>> wrote: > > My thought is to borrow from what you've done, but do like David and > Merle suggested and store the following in fink.conf: > > AutoUid: boolean > > AutoUidBase: integer, default 600 > > AutoUidMax: integer, default 699 > > FinkBldUid: the UID > > FinkBldGid: the GID > > > AutoUid, FinkBldUid, and FinkBldGid would get set via "fink configure". > Networked folks would set AutoUid: false via a prompt, and FinkBldUid > and FinkBldGid would either be autogenerated, use an existing value > (left over from passwd-fink-bld) or have values set explicitly, > depending on what the user wants. (AutoUidBase and AutoUidMax wouldn't > be set by prompts, but would be changed via manually editing fink.conf). > > > As you like, but this seems excessively complicated to me for no real > gain. What's the difference between: > > 1. Setting AutoUidBase to n > 2. Setting AutoUidBase and AutoUidMax both to n > 3. Setting AutoUid to false and setting FinkBldUid to n > > As I see it, these are basically telling fink: > > 1. Create fink-bld with UID n, unless it's already used, in which case > take the next available UID. > 2. Create fink-bld with UID n, unless it's already used, in which case > fail and don't create fink-bld at all. > 3. Create fink-bld with UID n, even if it's in use because I don't care > whether or not I have to users with the same UID. > > 1 seems the most useful to me. Maybe some people would prefer the extra > control that comes with 2. But why would anyone prefer 3 over 1 or 2? It > seems like a good principle that fink should never create a user with a > UID that already exists. If you believe that, then the only > configuration options which make sense are those giving fink a range of > UIDs to use. > > And for people who want to control which UIDs fink uses, there are > options, even without extra configuration parameters. They can use > AutoUidBase to restrict the UIDs to a specific range. They can create > the fink-bld user themselves with "dscl".
As I've shown in this thread, this is fraught with peril. A fairly lengthy sequence of commands is required to provide a working fink-bld user, so why not put that sequence in fink so that an administrator or user can just use 'fink configure' and get the right setup with Even if fink has created > fink-bld, they can change its UID using "dscl". If they're on a network, > they can create fink-bld on the central directory and then it will be on > all the other computers with the same UID. > > When fink is invoked for a build, it will check whether the fink-bld > user exists. If not, it will be created using these parameters from > fink.conf. If the UID and GID from fink.conf are different than those > in Directory Services, fink-bld will be updated to match fink.conf. > > > As I said, if someone wants to change fink-bld's UID, they can type: > > sudo dscl . /Users/fink-bld UniqueID <new id> > > This is not really any more complicated than setting a line in > fink.conf. On the other hand, putting some code into fink which will > modify the user database under circumstances where it will only rarely > get invoked seems like a dangerous idea to me. > > My opinion is that it would be best to just have two new configuration > settings: AutoUidMin (rather than AutoUidBase) and AutoUidMax. Also, > I've come around to the idea that there should be a prompt for > AutoUidMin during configure (and thus during bootstrap). Probably there > should also be a prompt the first time the user upgrades to a version of > fink which uses this option. Updating ConfFileCompatVersion forces a prompt after fink is updated (though it just advises running 'fink configure', has a default choice of "N", and then moves on.) I think I'm hesitant only because my > annoyance at the passwd package for requiring user interaction during > the build process makes me not want to add prompts where they don't > normally exist. > > Dustin My thought was that _we_ should have an interface to control how _our_ user gets set up, and that the user should be involved, as David mentioned (we also discussed this on IRC). I'd thought that it would be nice to have that information in fink.conf so that we could maintain some internal consistency on people's systems when we're generating IDs dynamically. I'm done. We can come back to this once Mountain Lion is out. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
