Subject: Posible virc(8) implementation
To: None <email@example.com>
From: Scott Aaron Bamford <firstname.lastname@example.org>
Date: 05/03/2000 18:13:49
From what i understand the decision has already been made to split rc.conf.
I still think that a mono configuration file is better to a human user than
many smaller files, though smaller files also have their advantages as many
other people have pointed out.
As such I have a proposal for the virc(8) application that has been mentioned
1) The application should collect all configuration data under
/etc/rc.conf.d/* into one file for editing.
2) The file to be edited should not be `cat /etc/rc.conf.d/* > tmpfile'
but should be ordered like the current rc.conf file.
3) The admin should have control over the order of the edited file.
4) Since more than one file exists to be edited, editing with virc(8) should
lock the rc configuration files.
5) Drop-in scripts, that do not have a place in the template for the edited
file should be appened to the end of the file, from where the admin can
move to an apropriate place in the template, where they will stay for next
(and all other) edits until moved again.
6) There should be a non-interactive way of brining the template file upto
date with any changes or new files in the /etc/rc.conf.d/ directory.
7) There needs to be a default location for varibles added to the file while
editing that do not exist in any /etc/rc.conf.d/* files.
8) All changes should be murged back into the /etc/rc.conf.d/ directory
in such a way that next time virc(8) is launched the to be edited
looks like the previous file it editied, but posiblty with some of
the information updated.
To satisfy 2,3,5,7 and 8 i suggest rc.conf is kept and used as the template
for the layout of information under /etc/rc.conf.d/, as well as being the
default location for varibles `without a home'. Since the layout of the
edited file needs to be kept, the values might as well be kept with it,
hopefully this will be useful to those who want to keep a mono rc.conf.
Effectivly this results in the contents of /etc/rc.conf becoming a
ordered copy of /etc/rc.conf.d/* 's confiuration. While still leaving
/etc/rc.conf.d/* files compleatly seperate.
Because of this `mirror' of information, point 6 is needed to keep the two
configurations in sync. A -s options should be added to virc(8) which
could be called from pkgsrc or by an adminsitrator after /etc/rc.conf.d/*'s
contents have changed without virc(8)'s interaction. This options should
be uninteractive and simply re-murge the changes into /etc/rc.conf and
To alow for 8 the default confiurations under /etc/rc.conf.d/* should provide
default values for all user-setable options of the service and these defaults
should never be removed by virc(8) even if the user removes the entry from
the editing file. If the user does remove an entry, it will reapear out of the
way at the bottom of the edited file on next edit, so the user is aware, but
can choose to ignore, of the settings.
To meet 4, a vipw(8) style lock on the rc files should be taken out, and
released by virc(8).
To meet 2, 3 and 8, virc(8) should simply copy the edited file, directly over
to /etc/rc.conf, then when loading the file to edit replace all values
in the file with the current values under /etc/rc.conf.d/; appeneding any
additions as needed.
As the name sugests, virc(8) should look, and feel like vipw as far as posible.
virc -s should perform identical to virc but without the interactive editing,
this includes locks.
I've tried to cover everything here. In particular i have tried to make
avalible the advantages of both a mono, and split configuration avalible
to the user, mainly the configuration information in one place for a
human to edit, and alow for automated process to drop-in scripts which
automaticly are gathered into one place next time the files are edited or
I've also tried not to force use of virc(8), but give it advantages that might
be benifical in its use. just executing
can be thought of as
was with the old system, copmleate with the garenty of uptodate information
and being saved ``as is'' to rc.conf to keep appearance between edits.
Likewise, for those who do not like to edit all the options together,
executing virc(8) will pull in all changes made into the files under
/etc/rc.conf.d/ since it was last run and virc -s will do this without the
need to edit anything, ie non-interactivly.
I have a implemention of this at
It has a manpage and examples, see README for instructions on how edit
pathnames.h to use the example tree (since the system wont be in place
on the current system, as there is no /etc/rc.conf.d/)
If anyone from either camp has ideas to make this more useful to them, please
tell me. I hope this will be as close as we an get to having both split
and mono configuration and keeping everyone happy, without the effort of
having to manually keep both a mono conf and split conf in sync in the tree.
Appolgys for the size of this mail.
------------------------------ `6_6 ) `-. ( ).`-.__.`)
email@example.com | (_Y_.)' ._ ) `._ `. ``-..-'
firstname.lastname@example.org | _..`--'_..-_/ /--'_.' ,'
--------------------------- (il),-'' (li),' ((!.-' ----