On Wed, 3 May 2000, Miles Nordin wrote:

>> Because of this `mirror' of information, point 6 is needed to keep the two
>> configurations in sync.
>
>I haven't been following this well, so please ignore me if I'm going over 
>old ground.  I appologize in advance and hope this will be helpful.
>
>Here's my real question:  the purpose of rc.conf.d is to permit heavy-fisted 
>editing by the pkg system.  Under your plan, 'virc -s' guarantees a successful 
>unattended merge of these changes into the rc.conf text file.

from what i understand, the /etc/rc.d/script will parse 
/etc/rc.conf.d/script.conf.  The `mirror' is simply that, its not really a
configuration file, but a template with <insert value here> writen on it.
The fact that the <insert value here> is replaced with the actual value is
more for convince of the user, the system shouldnt reliy on it,
it should use the /etc/rc.conf.d/ configs.  Maybe i should explain it a bit
better:
---
# example rc.conf
rc_configured=YES

ppp=<insert value here>			ppp_peers=<insert value here>
httpd=<insert value here>
---
# example rc.conf.d/ppp
ppp=YES
ppp_peers=""
---
#example rc.conf.d/httpd
httpd=NO
---

<insert value here> can be anythingm but above should be ppp=YES ppp_peers=""
httpd=NO.

virc then performs the following
  for each file in rc.conf.d
    for each varible in file
      add name = value pair to list
    done
  done
  load rc.conf
  for each name=value pair in rc.conf
    lookup name in list
    if name is found
      replace value with value from list
    fi
  done
  for each name=value pair in list
    if we havent already been used
      add to end of file
    fi
  done
  EDIT FILE

then a simalar proecedure to replace varibles back in there right places.
instead of rc.conf we could have rc.conf.d/default to hold any default values
and /usr/share/misc/rc.conf.layout to have the default layout for the edited
file.  i though it made more sense to combine the two.

>bsd.pkg.mk 
>will presumably call 'virc -s' immediately after a heavy-fisted change.
>
>So, why bother?  Why not make 'virc -s' part of the pkg system?  If you can 
>write a '-s' tool that works, you have completely eliminated the reason 
>people wanted the separate files in the first place.
they pkg system could call virc -s (id hope it would) but if it didnt, its
configuration information is still avalibe, and will recieve ``template entrys''
in rc.conf next time virc is run.

>
>Does '-s' actually work?  It must use magic comments to separate sections 
>of rc.conf, or something like that, right? 

no, it builds a list of varibles and then uses that to set values. just
echo "sshd=NO sshd_flags=\"-someflag\"" > /etc/rc.conf.d/sshd
would result in entrys for sshd to apear in the edited file.

>Just as effectively, rc.conf 
>might be written in a grammar more restrictive than a shell script that 
>enforces sectioning and thus attributes each changeable region to a named tool 
>or rc.conf.d file.  grammars conducive simultaneously to machines and humans 
>are readily devisable, and it sounds like you've already made one to get 
>virc working.

oringinaly i tryed to handle all the posible name=value styles that sh did
i gave that up (: now it basicly alows name=value and name="value" with
whitespace anywhere in that.

>If you can do this, wouldn't it work just as well to write a 'virc' tool that 
>exports the necessary heavy-handed filesystem operations to the pkg system 
>as needed?  You can even give them the same names if that makes you feel warm 
>and fuzzy:
>
>  virc cat \> fooconfig            -> create or overwrite conf.d file
>  virc cat fooconfig               -> copy out fooconfig
>  virc rm fooconfig                -> delete conf.d file
>  virc lock/unlock fooconfig       -> to make multiple calls to virc atomic

a virc [add|rm|check] tool probably would be usefull, espcialy to the pkg system
alowing removal or addition, unless it replaced some values (for example
the site default for enabled or not of new scripts) copying a file, or removing
it, from /etc/rc.conf.d/ and /etc/rc.d/ would have the same effect.
check would have to just look up rcvar (or name) and do a rc.subr like
checkyesno() on it.

However the design i did for virc was to be a simple editor wraper, like
vipw(8).  I dont know if this the above functions you mentioned might
be useful in another tool (i have delibrtly made all the locking code
into a seperate file, based on libutils passwd locking incase this was
decided).

>How is this different from editing real files in the filesystem, and then
>calling 'virc -s'?  Of course, virc could do more, like tweak individual
>variable names--common domain-specific tweaks that the pkg system would
>have to do with sed and awk in the rc.conf.d plan.
>
>It seems to me better to put the damned machine behind a Layer of Abstraction 
>and Isolation, not the user.

all the individaul files under /etc/rc.conf.d/ can still be edited, all -s does
is bring the contents of /etc/rc.conf (which i again say, is more of a template
in a convenite place for greps etc) to match the real configuration.

>CVS and Coda have shown that merging two independently changed copies of 
>something together is necessarily ambiguous, and requires manual intervention 
>to happen sanely.  The normal solution to this is, ``never copy information.''
>master.passwd is a carefully-controlled exception.  virc may evolve as 
>another exception, but its task is more difficult, as the following analogies 
>show.
>
>   master.passwd      ::      rc.conf.d      (authoritative.)
>   spwd.db, pwd.db    ::      rc.conf        (copy.  authoritative->copy is 
>                                              guaranteed successful, just 
>                                              like 'make' dependency tree)
>
>   virc -s            ::      vipw      -> propogates information forward 
>                                           from the authoritative source
>   virc               ::      chpass    -> always updates master.passwd 
>                                           after editing the copy
>

id say virc -s is more like pwd_mkdb.

>virc is a lot harder to pull off than chpass, because chpass has one isolated 
>machine-originated database transaction, and virc lets you edit rc.conf so it 
>must be able to deal with any change to a free-form text file.

thats another reason i wanted to keep _all changes_ in /etc/rc.conf too,
its nothing more than a text file, with certain bits updated when you
edit it.

>I thought about this proposed virc scheme and wrote a much longer earlier 
>draft email about it, but the main points now seem to be:
>
>  o it sounds really cool.
>  o it sounds like it does everything it needs to.
>  o it sounds like it does a lot more than it needs to, for foolish 
>    linguistic and political reasons.

the only thing it doesnt do, but i dont plan on adding untill the current
code is ironed out, is alow an `out of sync' rc.conf file to be split back
over the /etc/rc.conf.d/* files. though the functions are all in place to do
it (since thats basicly what we do with the file we edit, load its vars into
a list and then put them into the right files)... humm, it probably would
only take 2 mins to add...

thank you for the feedback, the code is up under http://www.ansic.net/virc.tar.gz if you want to look at it and see how it works.

 - Scott
                              ("`-''-/").___..--''"`-._
 ------------------------------ `6_6  )   `-.  (     ).`-.__.`)
         sab@ansic.net |        (_Y_.)'  ._   )  `._ `. ``-..-'
  sab@zeekuschrist.com |      _..`--'_..-_/  /--'_.' ,'
 --------------------------- (il),-''  (li),'  ((!.-' ----