Greetings list-members! I''m a puppet newb and I''m trying to
write a
recipe that replaces the standard Redhat sysklogd with syslog-ng. I
do this to separate shorewall-generated iptables log messages from /
var/log/messages into a separate log.
I have something that works now but it spews warnings every time
puppetd runs on the client. The outline of what I wanted was to
- install syslog-ng
- configure syslog-ng
- stop the syslog service
- start syslog-ng
- uninstall the sysklogd package
- remove sysklogd configuration files
Ordering is important here since:
- rpm dependencies require that at least one syslog be installed
at any time
- stopping a service requires that package to be present
My first stab at puppet code for this was like so (edited for
brevity''s sake):
class syslog-ng {
package { syslog-ng:
ensure => installed,
before => Package[sysklogd]
}
# ... blah blah configure syslog-ng
package { sysklogd:
ensure => absent,
}
file { ["/etc/syslog.conf", "/etc/sysconfig/syslog"]:
ensure => absent,
require => Package[sysklogd],
}
service { syslog:
ensure => stopped,
enable => false,
before => Package[sysklogd],
}
}
So I think this sets up all the ordering constraints that I need and
it switches out the packages the first time through.
The problem is that the next time through, service syslog fails
because /etc/init.d/syslog isn''t there. That sets off a cascade of
other warnings about failed dependencies. Even worse, had I
interrupted puppet after the service was stopped and package removed
but before the other stuff was cleaned up those things never would be
cleaned up.
So this leads me to these questions:
- is there a way to ignore the outcome of a resource for the
purposes of dependencies?
- alternatively, is there a way to specify ordering without actual
dependency on outcome?
- barring that, can I do something like onlyif on a service to
test for /etc/init.d/syslog myself?
- am I missing some essential puppetism that would make this whole
problem easier and would sidestep the above issues?
Thanks in advance!
-Marek Gilbert
On Apr 30, 2007, at 12:56 AM, Marek Gilbert wrote:> My first stab at puppet code for this was like so (edited for > brevity''s sake): > [...]Ok.> So I think this sets up all the ordering constraints that I need and > it switches out the packages the first time through. > > The problem is that the next time through, service syslog fails > because /etc/init.d/syslog isn''t there. That sets off a cascade of > other warnings about failed dependencies. Even worse, had I > interrupted puppet after the service was stopped and package removed > but before the other stuff was cleaned up those things never would be > cleaned up.So removing the package doesn''t automatically stop the service? That''s what I would expect. Otherwise... This is always going to be hard, because you can only talk about the service if the package is present, which will only be the case on the first run, and Puppet doesn''t support that at this point.> So this leads me to these questions: > > - is there a way to ignore the outcome of a resource for the > purposes of dependencies?Unfortunately, no.> - alternatively, is there a way to specify ordering without actual > dependency on outcome?Similarly, no.> - barring that, can I do something like onlyif on a service to > test for /etc/init.d/syslog myself?Three for three, no.> - am I missing some essential puppetism that would make this whole > problem easier and would sidestep the above issues?I don''t think so, but maybe you''re trying to have Puppet do too much and the packaging system do too little. I''d be surprised if the packaging system didn''t stop the service for you, which means you just need to remove the package and configuration file, and not worry about the service. -- Neonle will continue to be rude, and will nretend that you had a small stroke which makes you unable to say or see the letter "n". Stunid nractical joke, if you ask me. Bunch of noon-heads, huh? -- Fred Barling, Humorscope --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com