Determining the syslog provider

[Julien C.]

Hi,

I'm trying to make all my servers send their logs to a central server. Which seems quite simple, at first.

My problem is that my servers are on different versions of different operating systems.

And each of them has a different syslog default provider (syslog, rsyslog, syslog-ng...).

Which of course might have been replaced by an admin who prefered another...

Even funnier, SLES10 has its configuration in syslog-ng-conf.in and SLES11 in syslog-ng.conf !

How would you approach such a task ?

Regards,

[Felix Frank]

Hi,

there's a bunch of facter variables that tell puppet what platform a
given box is. Your manifest for syslog deployment should be a
mambo-jumbo of if and case clauses that pick the right things to do.

Hopefully you can get away with "ensure"ing all inferior solutions
absent (via package) and get rsyslog on all platforms. Er, I mean, your
preferred tool of course ;-)

As for SLES10 vs SLES11, same answer: depending on
$operatingsystemrelease, manage the appropriate config file.

HTH,
Felix

[maill...@gmail.com]

OS type and version are available in puppet via Facter as
"operatingsystem' and 'operatingsystemrelease'. You don't have to do
anything to set it up, just start using them. You could, for example,
use a case statement to test those variables and decide which file and
packages to distribute based on that.

To see what Facts are available, run 'facter -p' and just 'facter'.

[Julien C.]

Thanks to both of you for your answers. 

I am aware of the operatingsystem and release variables, but I can't rely on them because servers don't always use the default syslog provider, as stated in my original post.

I can't enforce the same provider on every node because it would destroy any customization made in the original provider's configuration.

I need to know which is the running logger and add my configuration in its config files.

The first step to do this is to identify it, hence this post's title.

[Darin Perusich]

On SuSE systems the init script determines which syslog daemon by the
value of SYSLOG_DAEMON in /etc/sysconfig/syslog, the values can be
"syslogd", "syslog-ng", "rsyslogd" or "" for autodetect. You should be
able to leverage those to determine which logger to use.

--
Later,
Darin

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/9J4Tgh7fTUAJ.
>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

[Felix Frank]

On 06/12/2012 02:45 PM, Julien C. wrote:
>
> I need to know which is the running logger and add my configuration in
> its config files.
> The first step to do this is to identify it, hence this post's title.

Huh, well the most canon apprach is custom facts:
http://docs.puppetlabs.com/guides/custom_facts.html

You need to teach puppet how to learn the things you wish it to know.
Then you can build from there.

HTH,
Felix

[Alex]

On 06/12/2012 02:45 PM, Julien C. wrote:

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/9J4Tgh7fTUAJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

Would a custom fact work in this case? I am not a ruby coder, but I
can't imagine it being too difficult to create a new fact that could
hold the name of the running logger. Maybe look at the list of running
processes, or installed packages.

http://docs.puppetlabs.com/guides/custom_facts.html

Cheers,

Alex

[Julien Cornuwel]

I think you are right (all three of you). I need to find out how to
find it in other OS families (debian & redhat should be enough) and
write a custom fact to get the data in my manifests.
Thanks for the pointers.

2012/6/12 Alex <alexpup...@gmail.com>:

> Would a custom fact work in this case?  I am not a ruby coder, but I can't
> imagine it being too difficult to create a new fact that could hold the name
> of the running logger.  Maybe look at the list of running processes, or
> installed packages.
>
> http://docs.puppetlabs.com/guides/custom_facts.html
>
> Cheers,
>
> Alex
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.

[Ramin K]

On 6/12/2012 2:39 PM, Julien Cornuwel wrote:
> I think you are right (all three of you). I need to find out how to
> find it in other OS families (debian & redhat should be enough) and
> write a custom fact to get the data in my manifests.
> Thanks for the pointers.

The downside to a custom fact is that it doesn't handle the reimaging
or provisioning a new server case. When the machine runs Puppet for the
first time it may or may not have the syslog that should be running on
it. Because you'll need to know which syslog to install or use the
default you may as well specify if per hostgroup/fqdn with Hiera or some
other external data source.

Ramin

[David Schmitt]

On 12.06.2012 14:45, Julien C. wrote:
> Thanks to both of you for your answers.
> I am aware of the operatingsystem and release variables, but I can't
> rely on them because servers don't always use the default syslog
> provider, as stated in my original post.
> I can't enforce the same provider on every node because it would destroy
> any customization made in the original provider's configuration.

Stop right there.

If you fear destruction of customizations through configuration
automation, then you are setting yourself up for some massive pain
short- and long-term.

The point of automation is either to get rid of these "customizations"
or codify them.

In the former case you WANT to enforce, in the latter case you need to
identify the "business" need for those customizations and extract this
information either into your ENC/hiera or other data feeder.


Best Regards, David

[Julien Cornuwel]

Hi,

Sorry for letting this thread die. I ended up enforcing rsyslog
everywhere and waiting for someone/something to complain. Turns out
noone/nothing complained and there wasn't any customisation after
all...

Regards,


2012/8/17 Jason Antman <ja...@jasonantman.com>:
> Julien,
>
> What did you end up doing for this? If you wrote a custom fact, would you be
> willing to share it? I've just come up against the identical problem
> (dealing with RHEL and CentOS 5-6 as well as SLES9) and was about to start
> work on a custom fact when I found this thread...
>
> Thanks for any code/suggestions,
> Jason Antman

>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msg/puppet-users/-/Qy9c94L9SIgJ.

[Despite]

Ahh, that's a great solution.  I'm glad you bumped this right now -- I was just considering the same problem.  Now I realize my solution is similar -- if I'm going to deploy puppet on a system, I'm going to update it to a modern OS at the same time, which will include rsyslog.