Page MenuHomePhabricator

[OPS] syslog::server (in test) unusuable
Closed, ResolvedPublic


We have rsyslog installed with the base package on all servers. That also trigger the installation of misc::remote-syslog which use rsyslog to send logs to a central box.

When setting up the central box, one has to use the syslog::server class which try to install syslog-ng instead of rsyslog but still has misc::remote-syslog.

The end result is that each time puppet run on the host, whatever syslog system runs at that time is replaced by a the other one.

How to reproduce:

Log on deployment-syslog
Run twice: puppetd -tv

Version: unspecified
Severity: normal



Related Objects


Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:28 AM
bzimport set Reference to bz36748.
bzimport added a subscriber: Unknown Object (MLST).

Moving to beta project. Raising priority since that means we have no log!

From a quick discussion with Ryan, instances indeed include base class and thus always have misc::remote-syslog.

Moving bug back to pool and tagging for ops to look at.

While I am there, the correct puppet classes are:

base::remote-syslog (installs rsyslog)
misc::syslog-server (installs syslog-ng)

We need a way to conditionally disable the inclusion of base::remote-syslog to let misc::syslog-server install syslog-ng.

Gerrit change has been abandoned. Ops do not want the hack that is based on a labs instance name and would like the whole syslog system to be rethought. Not going to happen anytime soon unfortunately.

Bringing back the topic again on ops list and with a new change:

Change got merged.

On deployment-bastion, I have applied the class misc::syslog-server and created a symlink /home/wikipedia/syslog to /data/project/logs/syslog.

The file is now getting messages from all the instances :-]