Re: Automated service/daemon management
Hi, On Tue, 09.06.2009 at 15:52:55 -0400, Bryan Allen b...@mirrorshades.net wrote: My suggestion would be to move all your services to run under runit or daemontools. You can manage both with Puppet. I'm not familiar with runit, really, but I've used daemontools for years, quite happily, on several platforms, including OpenBSD. imho, runit is almost a drop-in replacement for daemontools, only better (eg. more powerful, and easier to handle). Kind regards, --Toni++
Re: Automated service/daemon management
On Tue, Jun 9, 2009 at 6:09 PM, patrick keshishianpkesh...@gmail.com wrote: On Tue, Jun 9, 2009 at 11:06 AM, (private) HKShks.priv...@gmail.com wrote: When my scripts install a package, they have to edit the monolithic /etc/rc.local in order to enable starting (rc.conf.local too, but that's a single line easily done with sed and checked with grep). Uninstalling a package is scarier since they're removing the parts of /etc/rc.local. Both of these rely on multi-line pattern matching and merging, which are imperfect sciences that wrack my nerves when they run automatically. The much larger problem, though, is with starting/stopping/restarting services. Say I add spamd as an enabled service on host1. For my scripts to start it properly, I have to replicate the code already in /etc/rc defining how spamd starts. This is prone to errors and runs the risk of breaking on upgrades. Restarting services that need more than a HUP is also a chore. As for stopping, some services like postgresql need some careful attention. This means replicating code from /etc/rc.shutdown. for ports you add to your system (such as postgresql) you can always use an external script for its start/stop and just add appropriate section to rc.local and rc.shutdown: --- e.g., --- rc.local # if [ -x /etc/rc.pgsql ] ; then /etc/rc.pgsql start ; fi rc.shutdown # ... if [ -x /etc/rc.pgsql ] ; then /etc/rc.pgsql stop ; fi next you need to write rc.pgsql that starts or stops postgresql based on $1 == start or == stop That should solve at least part of your problem. As for spamd enabling/disabling, just reboot that machine if you don't want to look through the rc script to figure out what you need run. --patrick Thanks to all for the suggestions. Right now the most convincing is the daemon tools suggestion - I'll dig into that and see if it suits my needs. I've resisted hacking rc.d and rcorder into my system mainly because I want to avoid recoding rc just to make a few things easier. There's a lot in OpenBSD's rc that doesn't translate directly into the rc.d type system, so it's not going to be a simple matter. That's a lot of work to avoid a lot of work, and I'm not sure which one really requires more. The other rc mods are interesting, and I'll look at using them if daemon tools doesn't do what I'm hoping. Thanks for the help. -HKS
Automated service/daemon management
As my environment grows, I'm automating more and more of my work (package installation, config file propagation, etc.) so I can keep up with it. The problem I'm running into with my OpenBSD boxes is with services/daemons. When my scripts install a package, they have to edit the monolithic /etc/rc.local in order to enable starting (rc.conf.local too, but that's a single line easily done with sed and checked with grep). Uninstalling a package is scarier since they're removing the parts of /etc/rc.local. Both of these rely on multi-line pattern matching and merging, which are imperfect sciences that wrack my nerves when they run automatically. The much larger problem, though, is with starting/stopping/restarting services. Say I add spamd as an enabled service on host1. For my scripts to start it properly, I have to replicate the code already in /etc/rc defining how spamd starts. This is prone to errors and runs the risk of breaking on upgrades. Restarting services that need more than a HUP is also a chore. As for stopping, some services like postgresql need some careful attention. This means replicating code from /etc/rc.shutdown. I've looked at adding some stupid delimiters to /etc/rc, /etc/rc.local, and /etc/rc.shutdown so I can just pull in the necessary chunks, but I'm wondering if there's anything available that's more elegant and won't break on every upgrade. Has anyone solved this problem on OpenBSD? -HKS
Re: Automated service/daemon management
(private) HKS wrote: Has anyone solved this problem on OpenBSD? -HKS I have not yet, but I've been meaning to look into systems such as cfengine [1], puppet [2], chef [3], etc. I'd be interested in any experiences folks have with these types of systems and OpenBSD. Nick [1] http://www.cfengine.org/ [2] http://reductivelabs.com/products/puppet/ [3] http://wiki.opscode.com/display/chef/Home
Re: Automated service/daemon management
On Tue, Jun 9, 2009 at 3:02 PM, Nick Hassernick.has...@gmail.com wrote: (private) HKS wrote: Has anyone solved this problem on OpenBSD? -HKS I have not yet, but I've been meaning to look into systems such as cfengine [1], puppet [2], chef [3], etc. I'd be interested in any experiences folks have with these types of systems and OpenBSD. Nick [1] http://www.cfengine.org/ [2] http://reductivelabs.com/products/puppet/ [3] http://wiki.opscode.com/display/chef/Home Puppet is the one I'm working with right now. It's great, but it doesn't solve the problems I outlined above. -HKS
Re: Automated service/daemon management
On Tue, Jun 09, 2009 at 02:06:59PM -0400, (private) HKS wrote:
The much larger problem, though, is with starting/stopping/restarting
services. Say I add spamd as an enabled service on host1. For my
scripts to start it properly, I have to replicate the code already in
/etc/rc defining how spamd starts. This is prone to errors and runs
the risk of breaking on upgrades. Restarting services that need more
than a HUP is also a chore. As for stopping, some services like
postgresql need some careful attention. This means replicating code
from /etc/rc.shutdown.
You can make this easier in rc.local by using a construct along the
lines described here:
http://erdelynet.com/tech/openbsd/rclocal-trick/
I've looked at adding some stupid delimiters to /etc/rc,
/etc/rc.local, and /etc/rc.shutdown so I can just pull in the
necessary chunks, but I'm wondering if there's anything available
that's more elegant and won't break on every upgrade.
It sounds like using rc.d would be better suited to your
environment. FreeBSD and NetBSD both use rcorder(8), which runs well
on OpenBSD. Hook that into your rc.local and write/manage init
scripts under /etc/rc.d.
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | email.willma...@ml1.net |
*-[ BSD: Live Free or Die ]*
Re: Automated service/daemon management
Will Maier, 06/09/09 22:33: On Tue, Jun 09, 2009 at 02:06:59PM -0400, (private) HKS wrote: The much larger problem, though, is with starting/stopping/restarting services. Say I add spamd as an enabled service on host1. For my scripts to start it properly, I have to replicate the code already in /etc/rc defining how spamd starts. This is prone to errors and runs the risk of breaking on upgrades. Restarting services that need more than a HUP is also a chore. As for stopping, some services like postgresql need some careful attention. This means replicating code from /etc/rc.shutdown. You can make this easier in rc.local by using a construct along the lines described here: http://erdelynet.com/tech/openbsd/rclocal-trick/ I've looked at adding some stupid delimiters to /etc/rc, /etc/rc.local, and /etc/rc.shutdown so I can just pull in the necessary chunks, but I'm wondering if there's anything available that's more elegant and won't break on every upgrade. It sounds like using rc.d would be better suited to your environment. FreeBSD and NetBSD both use rcorder(8), which runs well on OpenBSD. Hook that into your rc.local and write/manage init scripts under /etc/rc.d. Well, years i used, NetBSD and their rc.d scripts are quite usefull... Is there any specific reason why OpenBSD does not place startup scripts under rc.d? As long as administrator does not insert ie; service=YES flag into rc.conf, service not activated. Regards, Cem
Re: Automated service/daemon management
My suggestion would be to move all your services to run under runit or daemontools. You can manage both with Puppet. I'm not familiar with runit, really, but I've used daemontools for years, quite happily, on several platforms, including OpenBSD. -- bda cyberpunk is dead. long live cyberpunk.
Re: Automated service/daemon management
Well, years i used, NetBSD and their rc.d scripts are quite usefull... Is there any specific reason why OpenBSD does not place startup scripts under rc.d? As long as administrator does not insert ie; service=YES flag into rc.conf, service not activated. Because our total rc script is 816 lines, and our netstart script is 397 lines, and they do more than theirs? There are very specific solid reasons. When you split the script into a multitude of scripts, it takes about 3 days before people fuck it up so that syslogd or portmap or something else gets started in the wrong place and some type of install does not work.
Re: Automated service/daemon management
Theo de Raadt, 06/09/09 23:57: Well, years i used, NetBSD and their rc.d scripts are quite usefull... Is there any specific reason why OpenBSD does not place startup scripts under rc.d? As long as administrator does not insert ie; service=YES flag into rc.conf, service not activated. Because our total rc script is 816 lines, and our netstart script is 397 lines, and they do more than theirs? There are very specific solid reasons. When you split the script into a multitude of scripts, it takes about 3 days before people fuck it up so that syslogd or portmap or something else gets started in the wrong place and some type of install does not work. Ooops, i would expect people (who somehow use any-bsd) to be more familir to rc.d :) Thanks for clarification. Regards, Cem
Re: Automated service/daemon management
On Tue, Jun 9, 2009 at 11:06 AM, (private) HKShks.priv...@gmail.com wrote: When my scripts install a package, they have to edit the monolithic /etc/rc.local in order to enable starting (rc.conf.local too, but that's a single line easily done with sed and checked with grep). Uninstalling a package is scarier since they're removing the parts of /etc/rc.local. Both of these rely on multi-line pattern matching and merging, which are imperfect sciences that wrack my nerves when they run automatically. The much larger problem, though, is with starting/stopping/restarting services. Say I add spamd as an enabled service on host1. For my scripts to start it properly, I have to replicate the code already in /etc/rc defining how spamd starts. This is prone to errors and runs the risk of breaking on upgrades. Restarting services that need more than a HUP is also a chore. As for stopping, some services like postgresql need some careful attention. This means replicating code from /etc/rc.shutdown. for ports you add to your system (such as postgresql) you can always use an external script for its start/stop and just add appropriate section to rc.local and rc.shutdown: --- e.g., --- rc.local # if [ -x /etc/rc.pgsql ] ; then /etc/rc.pgsql start ; fi rc.shutdown # ... if [ -x /etc/rc.pgsql ] ; then /etc/rc.pgsql stop ; fi next you need to write rc.pgsql that starts or stops postgresql based on $1 == start or == stop That should solve at least part of your problem. As for spamd enabling/disabling, just reboot that machine if you don't want to look through the rc script to figure out what you need run. --patrick
Re: Automated service/daemon management
Cem, From cemkay...@eticaret.com.tr Tue Jun 9 22:11:38 2009 Ooops, i would expect people (who somehow use any-bsd) to be more familir to rc.d :) I think people coming from SysV systems like Solaris or Linux will generally find rc.d more familiar, but it isn't hard to learn this system. On the other hand, classic BSD types are going to find this system easier. Slackware has an rc script like setup, but it is much closer to OpenBSD's classic style scripts compared to the rc system used by FreeBSD or other Linux distributions. If someone really wanted to implement their own management of scripts in a similar way to rc.d, one might check out the Slackware way of doing it, as it is simpler than the others, while achieving pretty much the same end. On the other hand, I like OpenBSD in part because of the way it handles these scripts, so I hope I'll continue to see the current style used for a long time into the future. :-) -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
