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.
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@gmail.com
2012-Jun-12 12:30 UTC
Re: [Puppet Users] Determining the syslog provider
On Tue, Jun 12, 2012 at 8:12 AM, Julien C. <cornuwel@gmail.com> 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.
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.
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. <cornuwel@gmail.com> 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.
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.
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.
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.
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.
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.
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.
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.