Subject: Re: The new rc.d stuff... [now rc.conf]
To: Robert Elz <kre@munnari.OZ.AU>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: current-users
Date: 05/11/2000 03:10:50
On Aug 29, 4:31pm, Robert Elz wrote:
} Date: Sat, 8 Apr 2000 01:24:38 -0700
} From: jnemeth@victoria.tc.ca (John Nemeth)
}
} | That's nice. However, there are a bunch of us that want it to
} | stay, because removing it would make our lives as administrator's far
} | more difficult.
}
} I actually doubt that, once you got a little used to it.
It would be nice if you would stop trying to convince us of this.
I (and I assume others such as Greywolf) have used enough systems that
I know what works for me and what doesn't.
} | Why should your needs and/or desires take precedence
} | over other peoples?
}
} Of themselves, they shouldn't, nor should yours.
However, you have been makeing demands, "rc.conf must go." I may
have expressed my opinion rather strongly, but they still boil down to
if NetBSD makes certain changes, then it may no longer meet my needs.
} | Says who? As of this moment, you're not even on the list of
} | contributors (although you are listed as contributing to CSRG) much
} | less being listed as having any kind of authority. I just checked at
} | http://www.netbsd.org/People/ .
}
} You're right, I have no authority in NetBSD at all. You can take some
} heart at that if you like (that is, it isn't likely, or even possible,
The problem I have is more to do with the way you expressed your
opinion then what it is. You've said things like "rc.conf must go"
which sounds like a demand, and "rc.conf will go" which sounds like a
statement of authority.
} | ssh, apache, amanda, and Xserver are all
} | applications, not part of the OS. Their configs don't belong in rc.conf
} | which is an OS config file. Nobody is arguing for a "Registry".
}
} rc.conf is an OS config file? My OS config file, last time I looked,
} was in /sys/arch/`uname -m`/conf/NAME
This isn't the L* camp (an OS consists of more then just a kernel)...
} Or is it that you're saying that syslog, cron, named, ntp, sendmail,
} xdm, gated ... are all "part of the OS" ?
syslog and cron can certainly be considered to be part of the OS.
named, ntp, and sendmail are debatable. I wouldn't consider xdm and
gated to be part of the OS (note that gated isn't supplied with NetBSD).
} And if so, why aren't you wanting their config files to be merged into
} rc.conf ? They all have separate config files that you have to manage
} separately from rc.conf, and they're all also listed in rc.conf as well.
As I said, I really don't want an M$ registry. Perhaps, I should
have said OS startup configuration. That should narrow things down to
just the subject at hand.
} | As long as the file keeps a defined format, this isn't true. If
} | somebody violates the defined format, then they probably don't care
} | about automated tools.
}
} The "defined format" for rc.conf is that it's a shell script that
} contains only variable settings and comments. Aside from that, it
} looks as if almost anything goes, just consider this fragment...
I've already suggested that for people that want to treat the file
as a general shell script, they should put a line like
"#@NO_AUTOMATION" at the top which would tell any automated tools to
not touch it. If that line isn't there then the "defined format"
should be restricted to simple variable settings and comments.
} # NFS daemons and parameters
} nfs_client=NO # enable client daemons
} nfsiod_flags="-n 4"
} nfs_server=NO # enable server daemons
} mountd_flags=""
} nfsd_flags="-tun 4"
} lockd=NO lockd_flags=""
} statd=NO statd_flags=""
} amd=NO amd_flags="-l syslog -x error,noinfo,nostats"
} amd_dir=/amd # mount dir
} amd_master=/etc/amd/master # master map
}
} While I guess you could write something that can figure out what is
} going on there, parse it, and re-create it, I think I'd prefer not
} to have to.
That wouldn't be very hard, and several people have stepped
forward offering to do just that. Some have even suggested that the
tool have a configuration file that lists accounts that can change
certain variables. This should solve everybody's complaints.
I really don't understand the reluctance to have a large text file
that can be either maintained by hand or programmatically. There are
several examples of this already. One that everybody knows would be
/etc/passwd. A somewhat more freeform example (variable definitions
and comments seperated into subsections) would be the M$ Windows 3.x
*.ini files. These files are very similar to *.conf and are usually
maintained programmatically, but you could modify them by hand if you
wish (and I have). In other words, this is a solved problem.
} And all this is ignoring the possibility of actually allowing both
} options to continue to exist - letting you keep all your settings in
} rc.conf if you like, but also allowing them to be in individual files.
This could make for a maintenance nightmare.
} And even the latter is "all in one place" really for those who claim
} that is what they need - it's just that the "place" is a directory
} rather than a file.
A directory barely qualifies as "all in one place" and handling a
directory full of files as opposed to just one file is a major pain in
the neck.
}-- End of excerpt from Robert Elz