rsyslog configuration worker
Andrew Wilkins
andrew.wilkins at canonical.com
Mon Feb 24 05:02:06 UTC 2014
I'm been working on https://bugs.launchpad.net/bugs/1281071, to enable TLS
on rsyslog connections. The core work is done, it's now down to upgrades.
Ideally we should upgrade all existing rsyslog configuration to use TLS.
The problem with this is that currently, our rsyslog configuration is
effectively static: you cannot change syslog-port after bootstrap, and
similarly you would not be able to change syslog-tls (which I'm adding, and
making the default for new environments).
It is true that we can change rsyslog config on upgrade (and will - there's
a step defined already), but this doesn't seem ideal to me. You still can't
change the port, and you still couldn't change the TLS flag easily. We
could hack the environment config in state on upgrade, but this seems ugly
to me. So, I think the best path forward is to have a new worker to manage
the configuration.
The question I have for the group is, is it of enough value to have rsyslog
configured during bootstrap/provisioning that we continue to do it in
machine init? If we take it out of there, we simplify the provisioning
code, and relegate all rsyslog configuration to this single worker.
Upgrades should be automatic; the rsyslog config worker would simply
rewrite the configuration file at machine agent startup and kill -HUP
rsyslogd. The (only?) downside is that we would not see any logging if the
machine agent failed to start. It would still be there on the machine, but
not accumulated in all-machines.log. OTOH, if the machine agent failed that
early on, there's a good chance there's nothing to accumulate anyway.
Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140224/4113581c/attachment.html>
More information about the Juju-dev
mailing list