Re: some woes about rc.conf.site (solution)
I'd have to agree with another message. Merging the defaults into rc sounds to me like the best solution, then have rc.conf handle the changes. I personally prefer to hand edit this file. This is coming from a user on 3.0-stable however... .conf normally means that it should be edited, not left alone... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site (solution)
I agree with this approach. However, I believe this is OBE. Jkh just committed the changes to cvs. Having the default values at the head of rc makes more sense. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 12:48:13PM -0800, Mike Smith wrote: I hate it unreservedly. If we need a source of seeded default values, we should have rc.conf.default, uncommented, read-only. rc.conf is where people expect to make their changes, and it is immensely bogus to have sysinstall creating rc.conf.site which is quietly included *after* everything in rc.conf (so that when someone changes rc.conf, the change is overridden). I hate to be an AOL'er, but I would like to voice agreement with Mike. It seems we are coming very close to violating POLA and a web of stacking. On Sun, Feb 07, 1999, John Fieber wrote: As for for all the debate on the name, if it is supposed to be an untouchable file, the name of rc.conf has GOT to change. IF things are too far along to break from the current path, John is very right that the name has to change. Remember, we changed the name from /etc/sysconfig to /etc/rc.conf due to overwhelming requests from sysadmins for us to be similarly named with other Unixes. People expect to edit /etc/rc.conf. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, Mike Smith wrote: I hate it unreservedly. If we need a source of seeded default values, we should have rc.conf.default, uncommented, read-only. rc.conf is Absolutely...agreed! _ Lauri Laupmaa ...speaking for myself only... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 04:33:00PM -0800, Parag Patel wrote: Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. Then I would suggest renaming rc.conf to be rc.vars or rc.config-vars or something more appropriate than rc.conf, which like all the other *.conf files is intended for local editing and maintainence. I do like the local overriding feature though. Yesterday I took out all my local rc.conf mods into rc.conf.local and copied in the default /usr/src/etc/rc.conf to /etc. The local mods are much smaller and much more obvious as to what is different from the default setup. I think rc.conf and nothing else wasn't that bad. rc.conf was a _reference_ for all possible settings and easy manageable. And mergemaster is an excellent tool, to update it on demand. -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Hopefully that is now fixed. It is. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Date: Sun, 07 Feb 1999 12:48:13 -0800 From: Mike Smith m...@smith.net.au What do you think ? Or what are your experiences ? I hate it unreservedly. If we need a source of seeded default values, we should have rc.conf.default, uncommented, read-only. rc.conf is where people expect to make their changes, and it is immensely bogus to have sysinstall creating rc.conf.site which is quietly included *after* everything in rc.conf (so that when someone changes rc.conf, the change is overridden). I confess that I experienced what sure felt like a POLA violation when I set up a system with a recent 3.0-SNAP (from about 01 February or so): Since it was on a scratch box, I did a fresh install. But I wanted to see what it would take to make the box play nice on our internal Engineering network. So immediately after sysinstall finished, and I told the system to boot single-user (since sysinstall doesn't seem to provide a way to specify the NIS domain name), and: fsck -p mount -a cd vi .cshrc [change EDITOR from ee to vi] csh cd /etc mkdir /RCS ci -u sendmail.cf rc.conf fstab printcap group inetd.conf [hand-enter descriptions of each file] co -l !:3* vi !:2* [hand-enter the NIS domain. Also change the amd_map_program amd_flags; those are easier to change w/ a normal editor. Do reality check on everything else in rc.conf.] [Add MFS-mounted /tmp.] [Add a couple of networked printers.] [Add the NIS magic cookie to /etc/group.] [Add the amanda client-side entry.] ci -u !* [hand-enter brief descriptions of the above] vipw [Add NIS magic cookie to passwd.] reboot intending to come up multi-user. (Note that I had deliberately not changed sendmail.cf yet; that comes later.) Machine comes up... amd says no work to do--quitting. Huh? I try logging in (as dhw); no go. ??!? Login as root; works fine. ls -F ~dhw/ -- no such user. Foo. domainname... null. :-( grep nis /etc/rc.conf -- yeah; the domain name is set. ??!??! *Then* my manager points out rc.conf.site. :-( So I check *that* file in out, edit it, check it back in, come up multi-user, and things are *much* happier. So then I'm able to cd /etc cp -p /usr/local/share/sendmail/cf-8.9.2/cf/dhw.cf sendmail.cf ci -u !$ kill `head -1 /var/run/sendmail.pid` tail -f /var/log/maillog OK so far (Then all I needed to do was un-tar a bunch of the a.out libraries (as well as /usr/libexec/ld.so) where they can be found.) *Then* I was able to login Later, on another machine (on an engineer's desk), I've upgraded the box to that SNAP. And now he's re-booted, and can't login. I login as root, and we happen to look at the results of rcsdiff -u /etc/rc.conf.site ??!? All kinds of changes Then he says he was doing some things with sysinstall. :-( Fine; co /etc/rc.conf.site restores it back again. Re-boot, and he can login again Seems that whatever he did completely trashed thinsg like the NIS domain name OK; this note is way too long already But it does seem to me that there's a bit of a POLA violation, if nothing else, in the naming. You see, when I got here, I inherited a network where /usr/local was NFS-exported from a box (that is now running 2.2.6-R). And this seems to be rather at odds with the expectation of the ports system. Now, since this has been my first experience with FreeBSD, I didn't know any better... and I had no idea how much hassle this usage of /usr/local would be in an environment where such a ports system is used. Further, having /usr/local be site-local vs. machine-local isn't all that unusual in the environments I've used and administered before (mostly Suns). But if /usr/local is expected to be machine-specific, it seems to me that what sysinstall messes with should also be machine-specific, and the names should be of a similar pattern. At the same time, there is value in having a site-specific configuration file (just as there is value in having some site-wide files, some of which may well be executables). I would expect, moreover, that the machine-specific information would override the site-specific information. I hope that was of *some* use (or interest, at least), david -- 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: some woes about rc.conf.site
Sorry to say this, but after having to use rc.conf.site as it is now I really kind of 'hate' it. Sorry to say this, but you really don't understand it. :) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. Well now that much is true - I suppose I could sort it, or something. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Are we even talking about a 3.0/4.0 snapshot made after 99/2/5 23:00 PST? I did send email out about this. Well, maybe I overlooked some things advantages ;-) Then please tell me. As usual, I think you're just out of date and we're not even talking about current technology. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 08:29:57AM -0800, Jordan K. Hubbard wrote: Sorry to say this, but after having to use rc.conf.site as it is now I really kind of 'hate' it. Sorry to say this, but you really don't understand it. :) What ? ;-) Don't tell me that ;-) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. Yes, true, but with the new concept of leaving this file untouched and only altering rc.conf.site I have the overhead as described in my mail. I have to choose things in rc.conf, but to change it in a different file. Browing and changing in one file (rc.conf) was easier for me. Well, my private workaround is now to remove rc.conf.site. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. Well now that much is true - I suppose I could sort it, or something. Would be fine, if it would have the same sortorder as rc.conf. This would make it easier to browse through both files in two windows. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Are we even talking about a 3.0/4.0 snapshot made after 99/2/5 23:00 PST? I did send email out about this. Well I speak of a SNAPSHOT I made myself and I followed the discussion and found the idea nice. But now when having to edit rc.conf.site manually with vi, I have the feeling, that this concept sucks a bit. It's ok, if you always use the user interface (sysinstall). But if you want to fine tune system settings by hand with vi it has the overhead I descripbed in my previous e-mail: And that actually is: you have always to compare rc.conf and rc.conf.site if you want to add or modify a feature. Or you simply copy rc.conf over rc.conf.site and start over. Well, maybe I overlooked some things advantages ;-) Then please tell me. As usual, I think you're just out of date and we're not even talking about current technology. :) Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! Well browsing and modifying only one file (rc.conf) at the same time was a lot more comfortable for me. But, if I'm the only person who complains, then forget about it. It's not so important then ;-) Andreas /// -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! I still cannot see any reason for you to do this. I haven't had any of the problems you describe since I can't even imaging approaching the problem in the way that you have chosen to. :-( - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
No I have to use two vi sessions (or one ,more' and one ,vi' session) in two different (!) windows (especially after a new installation, Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, John Robert LoVerso wrote: No I have to use two vi sessions (or one ,more' and one ,vi' session) in two different (!) windows (especially after a new installation, Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. When I last did SVR4 admin, with ESIX, I kind of liked that. Now I'm in the midst of getting used to Solaris7 (which I stuck on the new machine, to give me broader experience) and I have to say, the extreme balkanization of the startup and shutdown scripts is disheartening. It's no doubt a wonderful thing for the folks who write GUIs to manage it, but I only like GUIs that are tightly under control (for years, I wouldn't touch GUIs at all). The extreme splitting up of the scripts is horrible for someone who wants to tweak scripts. Any thought of moving to a more layered style of admin'ing has to be very carefully considered, because it surely can make a hostile environment for anyone who doesn't want *precisely* what the GUI architect wants them to want. I want the move, but *please* don't let it be driven only by how much easier it is to control by a GUI. +--- 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: some woes about rc.conf.site
Hi, On Sun, Feb 07, 1999 at 06:05:15PM +0100, Andreas Klemm wrote: Sorry to say this, but you really don't understand it. :) sorry Andreas, ... I have to second this ;) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. hmmm. I hated the old behaviour of sysinstall to make changes directly to /etc/rc.conf. Why? Because I'm used to use /etc/rc.conf just as a 'reference manual' for all the 'knobs'. If mergemaster tells me that rc.conf has changed, I have the 'diff' as a rough guideline if I have to change my rc.conf.locale, too. Typically I use 'sysinstall' exactly once in one machine's lifetime. My old method of dealing with 'rc.conf' and 'rc.conf.local' was: = sysinstall generates a modified rc.conf = mv rc.conf rc.conf.local = cp /usr/src/etc/rc.conf rc.conf = vi rc.conf.local delete all the lines not suitable for rc.conf.local after making a new world: = mergemaster if there are diffs between the old and the new rc.conf = let mergemaster install the new rc.conf = have a close look at the 'diffs' and check if any of the changes conflict with my current rc.conf.local. Now, with 'rc.conf.site' I just don't have to bother with rc.conf after a fresh installation. I would just move rc.conf.site to rc.conf.local and then procede as earlier mentioned. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. I have to admit, that I havn't met a real rc.conf.site, yet. If the sort order differs significantly it should really be corrected. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Just as I have only the minimum set of knobs in rc.conf.local. or am I really the only person, who hacks rc.conf.site with vi no :=) both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! hmm. diff rc.conf.old rc.conf should point you directly to the changed options or changed default behaviors. But, if I'm the only person who complains, then forget about it. It's not so important then ;-) ;) .. Regards, Andreas -- : TSE TeleService GmbH : Gsf: Arne Reuter: : : Hovestrasse 14: Andreas Braukmann : We do it with : : D-48351 Everswinkel : HRB: 1430, AG WAF : FreeBSD/SMP: :: : PGP-Key: http://www.tse-online.de/~ab/public-key : : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
What do you think ? Or what are your experiences ? I hate it unreservedly. If we need a source of seeded default values, we should have rc.conf.default, uncommented, read-only. rc.conf is where people expect to make their changes, and it is immensely bogus to have sysinstall creating rc.conf.site which is quietly included *after* everything in rc.conf (so that when someone changes rc.conf, the change is overridden). -- \\ 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: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 09:13:27AM -0800, Jordan K. Hubbard wrote: Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! I still cannot see any reason for you to do this. I haven't had any of the problems you describe since I can't even imaging approaching the problem in the way that you have chosen to. :-( Don't take it too serious. Perhaps I should have put a smiley at the end of the sentence. Somtimes political means bad things(tm) I didn't meant it soo bad ;-) -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 12:41:17PM -0500, Chuck Robey wrote: On Sun, 7 Feb 1999, John Robert LoVerso wrote: Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. Ok, thanks, could do that. Then it would be nice, if Jordan could actually kind of sort things, so that it's easier to configure options in rc.conf.site. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. When I last did SVR4 admin, with ESIX, I kind of liked that. Now I'm in the midst of getting used to Solaris7 (which I stuck on the new machine, to give me broader experience) and I have to say, the extreme balkanization of the startup and shutdown scripts is disheartening. It's no doubt a wonderful thing for the folks who write GUIs to manage it, but I only like GUIs that are tightly under control (for years, I wouldn't touch GUIs at all). The extreme splitting up of the scripts is horrible for someone who wants to tweak scripts. Agreed. I like our way more, since renaming or deleting startup scripts to disable things isn't very comfortable. And you have to be very very careful about the design of the start and stop scripts ... -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
: : What do you think ? Or what are your experiences ? : :I hate it unreservedly. If we need a source of seeded default values, :we should have rc.conf.default, uncommented, read-only. rc.conf is :where people expect to make their changes, and it is immensely bogus to :have sysinstall creating rc.conf.site which is quietly included *after* :everything in rc.conf (so that when someone changes rc.conf, the change :is overridden). : :-- My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site The user messes with /etc/rc.conf.local Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. -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: some woes about rc.conf.site
On Sun, 7 Feb 1999, Matthew Dillon wrote: My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site The user messes with /etc/rc.conf.local Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. You don't think we should have different rc files for admining: 1) local options to system stuff, like setting net stuff, and 2) local ports-oriented options, that control things outside of of the base FreeBSD system? It looks like you don't draw that line, right? +--- 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: some woes about rc.conf.site
: : What do you think ? Or what are your experiences ? : :I hate it unreservedly. If we need a source of seeded default values, :we should have rc.conf.default, uncommented, read-only. rc.conf is :where people expect to make their changes, and it is immensely bogus to :have sysinstall creating rc.conf.site which is quietly included *after* :everything in rc.conf (so that when someone changes rc.conf, the change :is overridden). : :-- My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. We have a system-wide convention that *.conf files are parameter files which are to be edited by the administrator. rc.conf is the configuration file for the rc* process. It is not to be confused with the other rc.* files. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site No. The user messes with /etc/rc.conf.local And no again. You've just introduced an impossible layering problem here; auto-configurator or administrator - who has precedence? If you want more layering, add it yourself, in the file that's meant for adjustment. The fundamental problem here is that rc.conf.site is an unnecessary violation of our established conventions as well as POLA. Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. That's no better. -- \\ 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: some woes about rc.conf.site
My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. Matthew Dillon Then why bother having rc.conf in the first place? Just wire in all the defaults straight into /etc/rc and leave rc.conf strictly for overriding the defaults only, and eliminate rc.conf.* entirely. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, Andreas Klemm wrote: What do you think ? Or what are your experiences ? It has caused a lot of grief with my recent install of 3.0-19990205, but I gather I'm supposed to install something later before complaining. The main annoyance has been that running /stand/sysinstall after installation diligently clobbered settings in rc.conf.site...things like default_route, moused_enable, and network_interfaces to name a few of the more frustrating ones. Hopefully that is now fixed. As for for all the debate on the name, if it is supposed to be an untouchable file, the name of rc.conf has GOT to change. rc.defaults, rc.conf.defaults, rc.param or some such, with rc.conf being the one you normally edit and rc.conf.local being sourced for people who need it for some reason. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Then why bother having rc.conf in the first place? Just wire in all the defaults straight into /etc/rc and leave rc.conf strictly for overriding the defaults only, and eliminate rc.conf.* entirely. Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. The configuration information stored in rc.conf is applicable to more than just /etc/rc. Splitting out the configuration into a seperate file (rc.conf) means it can be sourced by other utility scripts, such as /etc/rc.firewall. Sourcing /etc/rc to pick up config info would be a disaster. And FWIW, I'm in favour of a read-only rc.conf with machine specific overrides in rc.conf.local. rc.conf.site should vanish. --lyndon pgpkyIExEMycO.pgp Description: PGP signature
Re: some woes about rc.conf.site
Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. Then I would suggest renaming rc.conf to be rc.vars or rc.config-vars or something more appropriate than rc.conf, which like all the other *.conf files is intended for local editing and maintainence. I do like the local overriding feature though. Yesterday I took out all my local rc.conf mods into rc.conf.local and copied in the default /usr/src/etc/rc.conf to /etc. The local mods are much smaller and much more obvious as to what is different from the default setup. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
