On Tue, 2005-05-31 at 23:53 +0100, Mark Brown wrote: > On Tue, May 31, 2005 at 05:56:42PM -0400, Andres Salomon wrote: > > > First, the postinst checks whether /etc/defaultdomain is set, and if > > not, resets nis/domain, sets the default value to `hostname --fqdn`, and > > prompts the user for the value. > > Yes, I know. This needs some TLC but it's not getting it until after > sarge goes out the door (as I said to myself over a year ago :P ).
Hehe, that's been my standard excuse for the past year as well. However, now that sarge is officially frozen (and potentially releasing in a week), it's a good time to start moving on stuff. > > > What this probably should do instead is, in the config script, prompt > > the user (using `hostname --fqdn` as the default if nis/domain is not > > already set). In the postinst, get this value and > > overwrite /etc/defaultdomain with it. > > It just needs the entire thing except for the output of defaultdomain to > be moved into config. The /etc/defaultdomain parsing needs to be done > otherwise the package will trash user configuration each time it's > upgraded (and on reconfiguration but it's easier to get away with it > then). > Right; get debconf value, get current /etc/defaultdomain value, prompt user for a new debconf value, overwrite defaultdomain (that last bit being done in postinst). > > Ditto for nis/not-yet-configured, which shouldn't care whether the > > machine has actually be configured yet; the note should be displayed > > when the package is first installed, and never again. People who can > > I think it's useful to also display the prompt on reconfiguration if > the message is going to be displayed at all - if people are trying to > reconfigure NIS they may be trying to get it to start using the NIS > configuration and a kick to go do the manual stuff is likely to be > helpful. > I disagree. Actually, I don't particularly feel the message needs to be displayed at all; a README.Debian stating what still needs to be done would suffice, I would think. There are plenty of packages out there that require the admin to finish configuring things, once installed; we don't need debconf prompts for them all. > > If you want patches for this, let me know. I'm also interested in > > seeing things like #231808 fixed; > > To be honest I'm not terribly convinced it's worth adding much to the > debconf configuration of the NIS package. The server configuration > option seems plausible given the startup failures reported but as noted > in the log for that bug properly configuring a NIS client involves > messing with critical system files like /etc/passwd and friends which > just has bad idea written all over it. This means that you're mostly > going to need something external to the package (be it a sysadmin with a > text editor or something more automated) to set up a NIS client for use. > I certainly agree messing w/ /etc/passwd and friends is a bad idea. However, doing as much as possible for the user would be beneficial. This means setting yp.conf in addition to defaultdomain. > Something like RedHat's authconfig which provides an integrated > interface to the configuration of the system databases and > authentication seems like it would provide a much more usable user > interface as well as standing more chance of being robust. > I can't say I've played w/ authconfig. However, I did notice update-passwd; I wonder if that can't be used to sanely deal w/ adding necessary entries to the passwd/shadow/group files. I'm talk to kamion about it, since it looks like it'd need some additional work to handle nis entries. > > I can provide initial patches if necessary. > > I wouldn't bother - writing the patches isn't the problem here. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
