FAQ
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,

--
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.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Felix Frank at Jun 12, 2012 at 12:26 pm
    Hi,
    On 06/12/2012 02:12 PM, Julien C. wrote:
    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,
    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Maillists0 at Jun 12, 2012 at 12:31 pm

    On Tue, Jun 12, 2012 at 8:12 AM, Julien C. wrote:
    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 ?

    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'.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Julien C. at Jun 12, 2012 at 12:45 pm
    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.

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Darin Perusich at Jun 12, 2012 at 1:32 pm
    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

    On Tue, Jun 12, 2012 at 8:45 AM, 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.

    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.

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Felix Frank at Jun 12, 2012 at 1:33 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Alex at Jun 12, 2012 at 1:40 pm

    On 06/12/2012 02:45 PM, 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.

    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.
    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Julien Cornuwel at Jun 12, 2012 at 9:39 pm
    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 <alexpuppetgroup@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.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Ramin K at Jun 12, 2012 at 9:45 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • David Schmitt at Jun 14, 2012 at 3:38 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Julien Cornuwel at Aug 17, 2012 at 4:44 pm
    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 <jason@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

    On 06/12/2012 08:12 AM, Julien C. wrote:

    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,
    --
    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.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Despite at Aug 20, 2012 at 8:47 am
    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.
    On Friday, August 17, 2012 11:43:33 AM UTC-5, Julien C. wrote:

    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 <javascript:>>:
    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

    On 06/12/2012 08:12 AM, Julien C. wrote:

    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,
    --
    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.
    To post to this group, send email to puppet...@googlegroups.com<javascript:>.
    To unsubscribe from this group, send email to
    puppet-users...@googlegroups.com <javascript:>.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    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/-/wTni-rP0STgJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 12, '12 at 12:12p
activeAug 20, '12 at 8:47a
posts12
users8
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase