Hello Ingo, first of all: thanks for taking the time!
schwa...@usta.de (Ingo Schwarze), 2014.10.24 (Fri) 15:00 (CEST): > Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 02:22:55PM +0200: > > > But be warned (it's biting me a bit): using ``rcctl disable xxxxxx'' > > doesn't just remove xxxxxx from pkg_scripts, it removes the > > xxxxxx_flags as well. In case you had carefully crafted command line > > parameters there, the simple ``rcctl disable'' command might make you > > unhappy. (rcctl disable is not reversed by rcctl enable, that is.) > > > > Question: why does "rcctl disable xxxxxx" not just remove xxxxxx from > > pkg_scripts? (But also removes xxxxxx_flags.) > > It's a carefully pondered design decision. The rcctl(8) utility > is intended for use by management frameworks taking care of many Alright, thanks for the clue, this explains... (But I think I've carefully read everything publicly available wrt rcctl(8) lately. Are you guys hanging out on h..k..s@, again? ;-) Are you talking about existing (non-base) management frameworks or are you heading for an in-base management framework and rcctl is only the first step? (Talking about a ``management framework'' in base OpenBSD feels strange.) > machines at once. In such a context, it is useful to keep configuration > files in a clean, normalized state, and information stored on > individual machines is not only useless; in general, it even tends > to obstruct automated changes. You don't have your carefully crafted > flags in rc.conf.local(8) on one single machine, but in some central > place. Just started my central place. > Of course, you are welcome to run it manually, too, but the I've seen instructions to do so on current.html. > requirements of management frameworks constrain the design quite a > bit, so there is not that much room left for decisions to improve > convenience for manual use. ACK > > Removing the xxxxxx_flags could be done via > > ``rcctl disable xxxxxx flags ""'' if really wanted, no? > > Well, in case we would implement saving flags for disabled services, > the quotes would be useless. Remember: > > rcctl enable identd flags " " > -> identd_flags=" " # in /etc/rc.conf.local > -> identd will start without flags > > rcctl enable identd flags > -> identd_flags= > -> identd will start with default flags (-e) > rcctl enable identd > -> no change if already enabled > -> enable with default flags if disabled 1) *_flags=" " => no flags, not even default 2) *_flags= => default flags from rc.d/* script daemon_flags 3) *_flags="-param" => use specified flags, not default > But i don't think we will support saving flags for disabled daemons. ACK > It's just additional complexity for little gain, and there is a > risk to confuse people who look at /etc/rc.conf.local and don't > remember whether it's a base or a package daemon. The gain for me would be > little, but you guys usually have the broader picture. > Besides, if you really want to keep the flags when disabling, > firing up sudoedit(8) and manually editing pkg_scripts is not > significantly more keystrokes than "rcctl disable xxxxxx". Right, but from the point of view of rcctl I'm putting rc.conf.local in an inconsistent state then. But rcctl handles this gracefully, after manual removal of a service from pkg_scripts and leaving service_flags untouched a ``rcctl service enable'' just adds the service back to pkg_scripts and leaves service_flags alone. Since rcctl(8) appends the service to the pkg_scripts, the order of your ``rcctl enable xxxxxx flags yyyy'' commands might matter. > > And while I'm in asking mode: the rcctl(8) ``default'' command cannot > > have values for non-base services/daemons, right? > > It can: > > $ rcctl default wesnothd > -d > $ rcctl default saslauthd > -a getpwent You cought me there; the default values are the daemon_flags within the individual rc.d(8) script. I assumed (yes, I know...) these were in rc.conf. Again, thanks for your time and knowledge! Bye, Marcus > !DSPAM:544a4d8a299169175019724!
