Re: Heads up! /etc/rc.conf.site is dead.
On Tue, Feb 09, 1999 at 02:21:09PM -0800, Jordan K. Hubbard wrote: Rather that listen to people wail over the next few months, it was decided instead to go to a slight variation on the previous theme in hopes that more people will be happy with the compromise. In essence, what used to be everything in /etc/rc.conf has moved to /etc/defaults/rc.conf and this file takes care of including (optionally) /etc/rc.conf and /etc/rc.conf.local. This means that you can go back to editing /etc/rc.conf again and the expected things will happen, though those interested in the full set of tunables will still need to look at /etc/defaults/rc.conf (which, like all defaults to eventually live in that directory, will be freely upgradable by the system). Since that made rc.conf.site obsolete, it was taken out of the configuration. Please move it to rc.conf on your system, should you be one of those folks who installed from an earlier snapshot and are now updating your /etc from -current or -stable sources (not likely to be all that many people). This change will also be in 3.1. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Any chance of something similar being done for make.conf? I've gotten in the habit of only adding stuff at the end, but it's still a pain copying file chunks back and forth. (Well, just forth I guess, no back) William R. Somsky wrsom...@halcyon.com Physicist, Baritone, Guitarist http://www.halcyon.com/wrsomsky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Fri, 12 Feb 1999 16:56:48 PST, Jaye Mathisen wrote: mergemaster is your friend. Mergemaster will help you update /etc/defaults/rc.conf, but you'll need to use something else to merge changes from that file into /etc/rc.conf . Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I may have missed this earlier in the thread, but has anyone given any consideration to upgrade installs? If an upgrade doesn't plant the new default files in /etc/default[s] after an upgrade, we now have two places and twice the files to compare on upgrade. As unorthodox as it sounds, if these defaults are meant to be unchanged, wouldn't a place like /boot/rc, or something similar, make sense? Upgrades get the new whistles, and administrators can fiddle files in /etc to their heart's content. -- Jay To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
mergemaster is your friend. On Fri, 12 Feb 1999, Jay Nelson wrote: I may have missed this earlier in the thread, but has anyone given any consideration to upgrade installs? If an upgrade doesn't plant the new default files in /etc/default[s] after an upgrade, we now have two places and twice the files to compare on upgrade. As unorthodox as it sounds, if these defaults are meant to be unchanged, wouldn't a place like /boot/rc, or something similar, make sense? Upgrades get the new whistles, and administrators can fiddle files in /etc to their heart's content. -- Jay To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I think people will get used to /etc/defaults fairly quickly just a note on naming: Solaris as well as HP-UX have /etc/default, not /etc/defaults. Seeing that we're introducing a change, we might just as well move to something others use as well. regards Michael -- Michael Schuster / michael.schus...@germany.sun.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Brian Somers [mailto:br...@awfulhak.org] Sent: 10 February 1999 18:47 To: RT Cc: curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? After mulling this over for a few days I can see that /etc/defaults is probably going to be a good thing. From your other mail, /usr/src/etc isn't any good for holding default system parameters since a) it might not be around since it's not in root. My previous suggestion of /usr/share fails this criteria as well, wasn't thinking clearly :-) b) it might not be around because there are no sources installed. If /etc/defaults is truly RO (I think the immutable flag should be set on those files to stop idle tampering) then it will solve the /etc upgrade problem or at least alleviate it greatly. Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. Changing the defaults for an existing setting are likewise not a problem. The local admin will still need to take a parse over the /etc settings when an upgrade is done to see if the defaults still suit the local requirements but the actuall installation of the new files can finally be automated without clobbering local settings and major changes to subsystems can take place without a lot of user intervention to upgrade the /etc/files by hand. They're going into /usr/share/examples/ppp soon. I have some other things (like tcl scripts for answering chap challenges) that will go in there, and it's a more generic place Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Hi Paul, Just a few criticisms of your comments... On Thu, 11 Feb 1999 11:56:31 GMT, p...@originative.co.uk wrote: Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. It won't be a doddle if, as you suggested, the defaults directory is system immutable. For exactly this reason, that suggestion wasn't a good one. I hope you agree. They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
What I don't like from the new rc.conf approach is the name rc.conf ;-). I think that the old sysconfig should come back. Then, there would be a /etc/defaults/sysconfig (R/O), and a /etc/sysconfig (storing the site-specific config). These files would contain _only_ variable assignments. The /etc/rc.conf script would be R/O too; it would read /etc/defaults/sysconfig and /etc/sysconfig in turn. Furthermore, both sysconfigs could be splitted into several files (net, nfs, time, console, isdn, etc.). In this case, another directory should be created under /etc (named siteconfig, for example), which would be the site-specific counterpart of /etc/defaults. My 0.02 euro, -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del País Vasco | mailto:j...@es.freebsd.org Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Sheldon Hearn [mailto:a...@iafrica.com] Sent: 11 February 1999 13:24 To: p...@originative.co.uk Cc: br...@awfulhak.org; tr49...@rcc.on.ca; curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. Hi Paul, Just a few criticisms of your comments... On Thu, 11 Feb 1999 11:56:31 GMT, p...@originative.co.uk wrote: Adding new knobs will be a doddle, the default file gets a new knob, with it's default setting and it'll just work. It won't be a doddle if, as you suggested, the defaults directory is system immutable. For exactly this reason, that suggestion wasn't a good one. I hope you agree. I don't see why. The only thing that should update the defaults directory is a system installation or 'make install'. Neither of which will be hampered in any way by the files or directory being immutable. We install new kernels without any problems. They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? I don't really agree, defaults is not for knobs that are turned on by default, for a start that assumes binary state which isn't the case. /etc/defaults will have the defaults for *all* knobs. That would include options that are disabled by default. Specifically with regard to ppp, having it work the same way would require changing ppp configuration code to parse a local file for overrides but there's no reason why all configuration couldn't adopt the same general principle of operation i.e. a defaults file that sets all configuration knobs into a default state and then a local override file for local changes. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Jon Hamilton hamil...@pobox.com writes: But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. Can we make something which compares /etc/rc.conf and /etc/default/rc.conf and emits warnings if a variable is set in /etc/rc.conf which isn't in /etc/default/rc.conf? I realize that this is not as simple as extracting all variable names from both files, sorting them, and running diff. There are a few variable names which are variable, for instance the network interface settings. kai `a FreeBSD newbie but hopefully not stupid' -- I like _b_o_t_h kinds of music. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
They're going into /usr/share/examples/ppp soon. [...] Besides, with all this activity, it'd be nice to get out of /etc altogether :-) Have another think about it. /etc/defaults does have its merits but it isn't going to work well unless everyone buys into it. /etc/defaults is for default knobs that are turned on by default and may be overridden. Examples are knobs that are not turned on by default. Can you see why the ppp examples are not a candidate for buy in? I don't really agree, defaults is not for knobs that are turned on by default, for a start that assumes binary state which isn't the case. /etc/defaults will have the defaults for *all* knobs. That would include options that are disabled by default. Specifically with regard to ppp, having it work the same way would require changing ppp configuration code to parse a local file for overrides but there's no reason why all configuration couldn't adopt the same general principle of operation i.e. a defaults file that sets all configuration knobs into a default state and then a local override file for local changes. I see no problem with the `default' section in ppp.conf. It allows the specification of defaults that can be overridden by individual profiles. ppp.*.sample are samples. They are purely there to give people a feel for what their configuration files might look like and to show them how to achieve things that require quite a few commands - such as playing server, doing multilink etc. Paul. Besides, IMHO, /etc/defaults will either be abused by system administrators or will be a poor-mans copy of src/etc. I can't see the problems going away by using something like this. -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On 11 Feb 1999 kai.grossjoh...@cs.uni-dortmund.de wrote: Jon Hamilton hamil...@pobox.com writes: But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. Can we make something which compares /etc/rc.conf and /etc/default/rc.conf and emits warnings if a variable is set in /etc/rc.conf which isn't in /etc/default/rc.conf? I realize that this is not as simple as extracting all variable names from both files, sorting them, and running diff. There are a few variable names which are variable, for instance the network interface settings. Actually, it's almost that easy. It may require a few hints at the beginning of the file, but I could make a shell script (not using sed/awk/whatnot) to do this if anyone would want it. kai `a FreeBSD newbie but hopefully not stupid' -- I like _b_o_t_h kinds of music. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Brian Somers [mailto:br...@awfulhak.org] Sent: 11 February 1999 20:56 To: p...@originative.co.uk Cc: a...@iafrica.com; br...@awfulhak.org; tr49...@rcc.on.ca; curr...@freebsd.org Subject: Re: Heads up! /etc/rc.conf.site is dead. I see no problem with the `default' section in ppp.conf. It allows the specification of defaults that can be overridden by individual profiles. ppp.*.sample are samples. They are purely there to give people a feel for what their configuration files might look like and to show them how to achieve things that require quite a few commands - such as playing server, doing multilink etc. Paul. Besides, IMHO, /etc/defaults will either be abused by system administrators or will be a poor-mans copy of src/etc. I can't see the problems going away by using something like this. I agree with the risk of /etc/defaults being abused, that's why I think the files should be immutable so that it's *VERY* clear to admins that they should not be touching those files. If they work their way around warning signs that huge then they really are on their own. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 09 Feb 1999 20:42:40 CST, Richard Wackerbarth wrote: But, I would not expect/allow defaults to be the mechanism which includes the real values. Neither would I, but only because this hasn't been made clear in such a way that guys like you and me get it. I reckon that a comment in /etc/rc.conf explaining that it's a set of values used to _override_ those in /etc/defaults/rc.conf ought to do the trick, eh? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, John Fieber wrote: On Wed, 10 Feb 1999, jack wrote: If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. Why must it contain only changes? Is there any reason it couldn't be a copy of the default rc.conf on a new installation? Alternately, it could be a copy of the default file with every item commented out. That would provide the clues for those who need to edit values and still not mess up the default behavior of a new install with old options that might have changed but were not explicitly overridden. The documentation in the file could also suggest that the user remove anything that they do not need. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
In message pine.bsf.4.05.9902100724470.1343-100...@nomad.dataplex.net, Richar d Wackerbarth wrote: } } On Wed, 10 Feb 1999, John Fieber wrote: } } On Wed, 10 Feb 1999, jack wrote: } } If /etc/rc.conf only contains changes from the defaults when } man something_or_other tells the user to find and edit } something_or_other_flags in /etc/rc.conf the entry won't be } there to edit. } } Why must it contain only changes? Is there any reason it } couldn't be a copy of the default rc.conf on a new installation? } } Alternately, it could be a copy of the default file with every item } commented out. That would provide the clues for those who need to } edit values and still not mess up the default behavior of a new install } with old options that might have changed but were not explicitly } overridden. But then you're right back where you started. Since rc.conf isn't supposed to be touched by the install/upgrade tools, it'll get out of date (and will become a hinderance rather than a help) as default settings change, and as settings are added/deleted. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, Sheldon Hearn wrote: On Tue, 09 Feb 1999 20:42:40 CST, Richard Wackerbarth wrote: But, I would not expect/allow defaults to be the mechanism which includes the real values. Neither would I, but only because this hasn't been made clear in such a way that guys like you and me get it. I reckon that a comment in /etc/rc.conf explaining that it's a set of values used to _override_ those in /etc/defaults/rc.conf ought to do the trick, eh? That would probably work. I'm not really oppposed to this concept I'd just like to see it documented in the distribution so that the lists aren't over run with questions when it hits the street and those who haven't been `heads uped' by the lists are in a state of confusion. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, jack wrote: If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. Why must it contain only changes? Is there any reason it couldn't be a copy of the default rc.conf on a new installation? Over time and upgrades it may get a little out of sync with the default file, but by then the user/admin will most likely be familiar enough with configuring the system that it won't exactly be a stumper. And how about this: stick a big comment at the top of /etc/rc.conf suggesting that the user consult /etc/defaults/rc.conf for a complete list of tunable parameters. Even in the worst case, the system behavior is exactly as it was before any of these changes came about. Exactly ! I've got the equivalent of /etc/defaults/rc.conf in /usr/src/etc at the moment. What have we gained ? What are we trying to gain ? The fundamental problem is not going to go away. When people upgrade, whether it's via ``make install'' or via sysinstall, they're still going to have to hand-install /etc, maybe with some help from mergemaster or a local script. If they don't, they'll be burned by a changed default value. What we've got now in -current is a place to put default variable values rather than having to make /etc/rc* behave reasonably if /etc/rc.conf isn't updated... not much of a gain IMHO. As long as the /etc/rc* files don't complain if /etc/defaults doesn't exist, i'll be happy. It's a waste of space when you've got /usr/src, and only confuses things. -john -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? They're going into /usr/share/examples/ppp soon. I have some other things (like tcl scripts for answering chap challenges) that will go in there, and it's a more generic place Besides, with all this activity, it'd be nice to get out of /etc altogether :-) -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Date: Tue, 09 Feb 1999 14:21:09 -0800 From: Jordan K. Hubbard j...@zippy.cdrom.com Since that made rc.conf.site obsolete, it was taken out of the configuration. Please move it to rc.conf on your system, should you be one of those folks who installed from an earlier snapshot and are now updating your /etc from -current or -stable sources (not likely to be all that many people). This change will also be in 3.1. OK; I gather that (by default) rc.conf will no longer be sourcing rc.conf.local either? Thanks, david (who is using a moderately recent SNAP for a growing number of machines) -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
:configuration. Please move it to rc.conf on your system, should you :be one of those folks who installed from an earlier snapshot and are :now updating your /etc from -current or -stable sources (not likely to :be all that many people). This change will also be in 3.1. : :OK; I gather that (by default) rc.conf will no longer be sourcing :rc.conf.local either? : :Thanks, :david (who is using a moderately recent SNAP for a growing number of machines) Sniff. I liked rc.conf where it was. /etc/rc, /etc/rc.conf. /etc/rc.local, /etc/rc.conf.local. Simple and obvious. Now we have /etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local. Considerably less simple and quite unobvious. -Matt :-- :David WolfskillUNIX System Administrator :d...@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, Matthew Dillon wrote: Sniff. I liked rc.conf where it was. /etc/rc, /etc/rc.conf. /etc/rc.local, /etc/rc.conf.local. Simple and obvious. Now we have /etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local. Considerably less simple and quite unobvious. Erm... I thought that the point of /etc/defaults/rc.conf was that one wouldn't touch it, and only work with rc.conf? (Haven't looked at the change myself, as my test machine is dead at the moment) mela...@yip.org - Shave A Tree Today! (TM) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Now we have /etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local. Considerably less simple and quite unobvious. Until you have to upgrade to the latest set of knobs; that problem is something I think people are not focusing sufficiently on in commenting only on the downsides of this. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
: Now we have /etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local. : Considerably less simple and quite unobvious. : :Erm... I thought that the point of /etc/defaults/rc.conf was that one :wouldn't touch it, and only work with rc.conf? : :(Haven't looked at the change myself, as my test machine is dead at the :moment) : :mela...@yip.org - Shave A Tree Today! (TM) Yah... kinda like nobody is supposed to touch /etc/rc, eh? /etc/rc - no touchee /etc/rc.conf- no touchee /etc/rc.local - touchees /etc/rc.conf.local - touchees That seems pretty obvious to me. I'm still partial to my /etc/rc.conf.N idea, where /etc/rc.conf.0 is a no-touchee and /etc/rc.conf.9 is the 'user can do whatever he wants with this file' touchee. The site configurator would mess with /etc/rc.conf.2. A post-install gui configurator would mess with either /etc/rc.conf.2 or /etc/rc.conf.3. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
: Now we have /etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local. : Considerably less simple and quite unobvious. : :Until you have to upgrade to the latest set of knobs; that problem :is something I think people are not focusing sufficiently on in :commenting only on the downsides of this. : :- Jordan /etc/rc.conf - no touchee /etc/rc.conf.local - touchees People are still stuck in the 'I want to edit /etc/rc.conf' mode of thinking. I say that if you intend to put the /etc/rc.* scripts in /etc, and make them read-only ( /etc/rc, /etc/rc.network, /etc/rc.firewall, etc... ) then /etc/rc.conf should stay where it is and also be read-only. If you want to put 'read only' junk into /etc/defaults, then why aren't you also sticking /etc/rc, /etc/rc.network, /etc/rc.firewall, etc etc etc into /etc/defaults ? It makes no sense to have an /etc/defaults/ directory if you are still mixing read-only and user-modifiable files in /etc. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Which rc.conf do you mean? :) The one in defaults/ will do everything the old one did save source rc.conf.site. - Jordan Date: Tue, 09 Feb 1999 14:21:09 -0800 From: Jordan K. Hubbard j...@zippy.cdrom.com Since that made rc.conf.site obsolete, it was taken out of the configuration. Please move it to rc.conf on your system, should you be one of those folks who installed from an earlier snapshot and are now updating your /etc from -current or -stable sources (not likely to be all that many people). This change will also be in 3.1. OK; I gather that (by default) rc.conf will no longer be sourcing rc.conf.local either? Thanks, david (who is using a moderately recent SNAP for a growing number of machines ) -- David Wolfskill UNIX System Administrator d...@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
If you want to put 'read only' junk into /etc/defaults, then why aren't you also sticking /etc/rc, /etc/rc.network, /etc/rc.firewall, etc etc etc into /etc/defaults ? It makes no sense to have an /etc/defaults/ directory if you are still mixing read-only and user-modifiable files in /etc. There is an eventual plan to put more things into /etc/defaults, yes. One has to, however, start somewhere. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Personally, I have to side with Matt. I like to have ALL of the files in one directory. That way I can grep ntpd /etc/rc* and find ALL the line that are likely to affect it. Moving some of the files into another directory just complicates things. I like the idea of having all the default knobs in one file. I recommend /etc/rc.conf.defaults On Tue, 9 Feb 1999, Jordan K. Hubbard wrote: If you want to put 'read only' junk into /etc/defaults, then why aren't you also sticking /etc/rc, /etc/rc.network, /etc/rc.firewall, etc etc etc into /etc/defaults ? It makes no sense to have an /etc/defaults/ directory if you are still mixing read-only and user-modifiable files in /etc. There is an eventual plan to put more things into /etc/defaults, yes. One has to, however, start somewhere. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I like the idea of having all the default knobs in one file. I recommend /etc/rc.conf.defaults The problem is that this doesn't scale. We (Mike and I) already debated this one back and forth for awhile and decided that quite a few files in /etc were due to be .defaulted and if this were kept flat, you'd very quickly wind up with far too much crap in /etc to keep track of. I think people will get used to /etc/defaults fairly quickly, especially as we move more things into there which currently get clobbered by the `make distribute' rule in /usr/src/etc. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
: :Personally, I have to side with Matt. :I like to have ALL of the files in one directory. :That way I can grep ntpd /etc/rc* and find ALL the line that are likely :to affect it. Moving some of the files into another directory just :complicates things. : :I like the idea of having all the default knobs in one file. :I recommend /etc/rc.conf.defaults I like this idea ( /etc/rc.conf.defaults ) better then /etc/defaults/rc.conf. Maybe /etc/rc.conf.distribution instead of /etc/rc.conf.defaults. Either is better then /etc/defaults/rc.conf. I don't think we should have an /etc/defaults/ directory, but if it is insisted on then *ALL* the read-only files should be moved into it, not just one of them. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
: :Personally, I have to side with Matt. :I like to have ALL of the files in one directory. :That way I can grep ntpd /etc/rc* and find ALL the line that are likely :to affect it. Moving some of the files into another directory just :complicates things. : :I like the idea of having all the default knobs in one file. :I recommend /etc/rc.conf.defaults I like this idea ( /etc/rc.conf.defaults ) better then /etc/defaults/rc.conf. As Jordan pointed out, this gets very messy very quickly. I don't think we should have an /etc/defaults/ directory, but if it is insisted on then *ALL* the read-only files should be moved into it, not just one of them. All of the files that currently mix read-only and read-write data will, ideally, be split so that the read-only content goes into /etc/defaults, and the local changes stay in /etc. The next big candidate for this is make.conf, but that will require careful testing first. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
:As Jordan pointed out, this gets very messy very quickly.
:
: I don't think we should have an /etc/defaults/ directory, but if
: it is insisted on then *ALL* the read-only files should be moved into
: it, not just one of them.
:
:All of the files that currently mix read-only and read-write data
:will, ideally, be split so that the read-only content goes into
:/etc/defaults, and the local changes stay in /etc. The next big
:candidate for this is make.conf, but that will require careful testing
:first.
I think it's a *BAD* idea to change rc.conf operation for the 3.1
distribution. Bad Bad Bad.
If you guys want to fix the read-only / read-write mess, fix it
for 3.2 and 4.x and don't just go piecemeal -- fix 90% of it right
off the bat. Move rc, rc.network, rc.firewall, rc.diskless{1,2},
rc.atm, rc.devfs, rc.isdn, rc.pccard, rc.serial, and rc.shutdown
into your defaults directory.
defaults is a bad name. Why not make it /etc/dist/ ?? for
'distribution files'. Much more obviously a 'do not mess with me'
directory then /etc/defaults is.
Either way, I really think we have enough problems to deal with
that changing rc.conf operation in 3.2 would just be asking for it.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, Matthew Dillon wrote: I think it's a *BAD* idea to change rc.conf operation for the 3.1 distribution. Bad Bad Bad. I have to agree. Let's not forget that there are over 30 man pages with references to /etc/rc.conf. There is already enough confusion over wcd in /dev with everything else refering to it as acd, and no documentation about when to just ignore tagged openings now . Both of these issues are already popping up in questions and the news groups. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I understand the scaling issue. However, I like to keep related things in one place. Perhaps we need to move ALL the rc files into a common directory. As for the read-only argument, I recommend, for those who wish to separate them, symbolic links from the read only area to a writable area. When that is not important, keeping them together can have advantages. Please understand that I support the general direction of these changes. However, since it is just about the same effort to implement any of the proposals and the status quo has a big advantage, I think that it is important to discuss the implications of each of the stratagies before commiting to any of them. PS: The same applies to DHCP. Since some of the well respected names have also supported ISC-DHCP, I hope that we can reach a concensus before anyone is allowed to make their bias the de-facto answer. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, jack wrote: On Tue, 9 Feb 1999, Matthew Dillon wrote: I think it's a *BAD* idea to change rc.conf operation for the 3.1 distribution. Bad Bad Bad. I have to agree. Let's not forget that there are over 30 man pages with references to /etc/rc.conf. Lets not forget that with the latest round of changes, the rc.conf in 3.1 will behave exactly as it has in the past. Think about it. rc.conf was a touchees file in the past and it is a touchees file now. The only difference is the addition of a no touchees reference copy in /etc/defaults that gets sourced before rc.conf so any essential variables introduced in an upgrade will have a safety fallaback in case you don't properly upgrade your rc.conf. The detour with rc.conf.site *did* change the way rc.conf was used. That was Bad Bad Bad and has just been fixed. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 09 Feb 1999 19:33:21 EST, John Fieber wrote: The only difference is the addition of a no touchees reference copy in /etc/defaults that gets sourced before rc.conf so any essential variables introduced in an upgrade will have a safety fallaback in case you don't properly upgrade your rc.conf. That's it? That's what all this is about? Hell, now that you've put it like that, it sounds like a really _great_ idea. Even the choice of directory name ``defaults'' makes sense, now. :-) Thanks for taking the time to clarify what's going on. I've been following my cvs-all and current mail quite closely but didn't quite get it until I read your mail. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
-Original Message- From: Matthew Dillon dil...@apollo.backplane.com To: Richard Wackerbarth r...@nomad.dataplex.net Cc: Jordan K. Hubbard j...@zippy.cdrom.com; Matthew Dillon dil...@apollo.backplane.com; David Wolfskill d...@whistle.com; curr...@freebsd.org curr...@freebsd.org Date: Tuesday, February 09, 1999 7:43 PM Subject: Re: Heads up! /etc/rc.conf.site is dead. :I like the idea of having all the default knobs in one file. :I recommend /etc/rc.conf.defaults I like this idea ( /etc/rc.conf.defaults ) better then /etc/defaults/rc.conf. Maybe /etc/rc.conf.distribution instead of /etc/rc.conf.defaults. Either is better then /etc/defaults/rc.conf. I don't think we should have an /etc/defaults/ directory, but if it is insisted on then *ALL* the read-only files should be moved into it, not just one of them. I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I tend to prefer that the editable knobs be kept together. The uneditable scripts and the defaults can go together. If you are going to divide things, I don't see why you should put uneditable scripts with editable knobs and apart from uneditable knobs. On Tue, 9 Feb 1999, RT wrote: I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? I would either turn examples into defaults OR expect them to go away when someone sets up their own version. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
But, I would not expect/allow defaults to be the mechanism which includes the real values. Perhaps this should be pushed into the script that will source both. On Wed, 10 Feb 1999, Sheldon Hearn wrote: The only difference is the addition of a no touchees reference copy in /etc/defaults that gets sourced before rc.conf so any essential variables introduced in an upgrade will have a safety fallaback in case you don't properly upgrade your rc.conf. That's it? That's what all this is about? Hell, now that you've put it like that, it sounds like a really _great_ idea. Even the choice of directory name ``defaults'' makes sense, now. :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, Matthew Dillon wrote: :As Jordan pointed out, this gets very messy very quickly. : : I don't think we should have an /etc/defaults/ directory, but if : it is insisted on then *ALL* the read-only files should be moved into : it, not just one of them. : :All of the files that currently mix read-only and read-write data :will, ideally, be split so that the read-only content goes into :/etc/defaults, and the local changes stay in /etc. The next big :candidate for this is make.conf, but that will require careful testing :first. I think it's a *BAD* idea to change rc.conf operation for the 3.1 distribution. Bad Bad Bad. This just puts it back where it was, there is nothing new, and so doing this now is quite directly in the spirit of POLA. defaults is a bad name. Why not make it /etc/dist/ ?? for Are you seriously worried about the naming, dist versus defaults? It seems a tiny argument, but defaults is used in several other OSs (like Solaris) for precisely this purpose, and dist is often used for completely different purposes. Jordan *seems* to have done the least surprising thing. We jumped on him for the changes, and now it seems like we're jumping on him for making the corrections. Not fair. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, John Fieber wrote: Lets not forget that with the latest round of changes, the rc.conf in 3.1 will behave exactly as it has in the past. Think about it. rc.conf was a touchees file in the past and it is a touchees file now. The only difference is the addition of a no touchees reference copy in /etc/defaults that gets sourced before rc.conf so any essential variables introduced in an upgrade will have a safety fallaback in case you don't properly upgrade your rc.conf. If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, jack wrote: If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. Why must it contain only changes? Is there any reason it couldn't be a copy of the default rc.conf on a new installation? Over time and upgrades it may get a little out of sync with the default file, but by then the user/admin will most likely be familiar enough with configuring the system that it won't exactly be a stumper. And how about this: stick a big comment at the top of /etc/rc.conf suggesting that the user consult /etc/defaults/rc.conf for a complete list of tunable parameters. Even in the worst case, the system behavior is exactly as it was before any of these changes came about. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
