On Mon, Feb 24, 2014 at 3:15 PM, John Meinel <j...@arbash-meinel.com> wrote:
> I'm not quite sure why we need the flexibility to change syslog port
> dynamically. If we want TLS, surely we want it always, which means there is
> an upgrade migration to TLS (where we upgrade machine-0 to support it, and
> then all agent machines to request it), but leave both ports open until the
> next upgrade where we know all agents are connected to TLS.
>
It depends on how we want to address this issue in rsyslog:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/789174
We can hack around it with iptables routing, but that's less than ideal.
I was just thinking about upgrades some more, and I don't think we can do
it automatically anyway. We need a certificate/key pair for the rsyslog
server, but because of https://codereview.appspot.com/66930043/ we cannot
use the state-server cert/key from existing environments. We don't push the
CA private key into the environment, so we can't generate a signed cert
automatically.
With that in mind, I'll propose my change without upgrade support... that
will have to be done by hand.
I can understand wanting people to configure their own environments, but in
> the end it is just more moving parts unless there is a real benefit to
> allowing it to be configurable.
> I may have missed the utility in it, though, so feel free to enlighten me.
>
So given that upgrades aren't handled anyway, the remaining utility is only
to simplify code (improving maintainability). We currently must thread
configuration through several API endpoints to the environment and
container provisioners; these then feed into environs/cloudinit to do the
machine initialisation. We also have upgrade steps that upgrade rsyslog
configuration (literally just be generating a fresh one and overwriting).
It doesn't necessarily have to be a worker, just something that runs once
at machine agent startup: wait for environ config, write rsyslog config,
restart rsyslog.
John
> =:->
>
>
>
> On Mon, Feb 24, 2014 at 9:02 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> 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
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
