Rsyslog imtcp issue
Hello, I am the maintainer of the rsyslog/forwarder charms. While i was working implementing an option to expose the protocol/port used by rsyslogd I noticed that enabling TCP on rsyslogd using imtcp ($InputTCPServerRun 514) was not possible on any machine deployed by Juju. The root cause is that /etc/rsyslog.d/26-juju-unit-primary-0.conf declares a DefaultNetStreamDriver to use gTLS, and apparently both plain && tls sockets cannot live together on rsyslogd. After changing the $DefaultNetstreamDriver from gtls to ptcp it worked correctly, for both actions collecting logs via TCP 514 and forwarding logs to 10.0.3.1:6514;LongTagForwardFormat. I know is not an option to abandon the usage of gTLS, but ideally, Juju should have a separated service and configuration path that doesn't interrupts any other rsyslogd process running on the host. I think we can workaround/fix this by running 2 different rsyslogd services with different configurations (maybe a default path different for juju /etc/rsyslog.d/juju/ ?), Please any observation would be appreciated Cheers. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Rsyslog imtcp issue
On 24 September 2014 23:25, Jorge Niedbalski wrote: > I know is not an option to abandon the usage of gTLS, but ideally, > Juju should have a separated service and configuration path that > doesn't interrupts any other rsyslogd process running on the host. I > think we can workaround/fix this by running 2 different rsyslogd > services with different configurations (maybe a default path different > for juju /etc/rsyslog.d/juju/ ?), > > Please any observation would be appreciated I too had difficulty when I needed to implement the rsyslog interface in my charm. I did not like that I needed to reconfigure a service required for juju to function correctly, as I have no guarantees that my changes will continue to work with future versions of juju (and for a beginner, rsyslogd is certainly not fun or easy to configure). If syslog remains, it would be nice if juju setup its own separate daemon so I don't have to worry about taking the environment down by accidentally spamming my logs at the controller node :) -- Stuart Bishop -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Rsyslog imtcp issue
FWIW, unit/machine agents no longer need rsyslog to stream logs to the state machine as of this merge: https://github.com/juju/juju/pull/499 Removing rsyslog as a dependency should be safe I think... On 25.09.2014 12:26, Stuart Bishop wrote: > On 24 September 2014 23:25, Jorge Niedbalski > wrote: > >> I know is not an option to abandon the usage of gTLS, but ideally, >> Juju should have a separated service and configuration path that >> doesn't interrupts any other rsyslogd process running on the host. I >> think we can workaround/fix this by running 2 different rsyslogd >> services with different configurations (maybe a default path different >> for juju /etc/rsyslog.d/juju/ ?), >> >> Please any observation would be appreciated > I too had difficulty when I needed to implement the rsyslog interface > in my charm. I did not like that I needed to reconfigure a service > required for juju to function correctly, as I have no guarantees that > my changes will continue to work with future versions of juju (and for > a beginner, rsyslogd is certainly not fun or easy to configure). > > If syslog remains, it would be nice if juju setup its own separate > daemon so I don't have to worry about taking the environment down by > accidentally spamming my logs at the controller node :) > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Rsyslog imtcp issue
Hello, On Thu, Sep 25, 2014 at 7:28 AM, Gabriel Samfira wrote: > FWIW, unit/machine agents no longer need rsyslog to stream logs to the > state machine as of this merge: > > https://github.com/juju/juju/pull/499 > Thank you for pointing out this. > Removing rsyslog as a dependency should be safe I think... > Does anybody else could confirm that removal of rsyslog is OK? > > > On 25.09.2014 12:26, Stuart Bishop wrote: >> On 24 September 2014 23:25, Jorge Niedbalski >> wrote: >> >>> I know is not an option to abandon the usage of gTLS, but ideally, Thanks. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Rsyslog imtcp issue
The state servers still use rsyslog, so you'd still have to be careful when deploying the charm to a state server. Probably it's best if we just fix the juju code to use its own daemon so as not to collide with charms that use it. The unit machines don't need rsyslog... unless you decide to turn one into a state machine using ensure-availability... so I don't think we can just blindly assume it won't be there. On Mon, Sep 29, 2014 at 10:29 AM, Jorge Niedbalski < jorge.niedbal...@canonical.com> wrote: > Hello, > On Thu, Sep 25, 2014 at 7:28 AM, Gabriel Samfira > wrote: > > FWIW, unit/machine agents no longer need rsyslog to stream logs to the > > state machine as of this merge: > > > > https://github.com/juju/juju/pull/499 > > > > Thank you for pointing out this. > > > Removing rsyslog as a dependency should be safe I think... > > > > Does anybody else could confirm that removal of rsyslog is OK? > > > > > > > On 25.09.2014 12:26, Stuart Bishop wrote: > >> On 24 September 2014 23:25, Jorge Niedbalski > >> wrote: > >> > >>> I know is not an option to abandon the usage of gTLS, but ideally, > > Thanks. > > -- > Jorge Niedbalski R. > Software Sustaining Engineer @ Canonical > Canonical Technical Services. > > -- > 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
