thr3ads.net - Puppet users - [Puppet Users] AW: nagios_service does not replace target file [Nov 2011]

If this information is useful, please help other people find it:
Share via:

Bernd Adamowicz

2011-Nov-16 22:57 UTC

[Puppet Users] AW: nagios_service does not replace target file

Hi all,

I''m a little bit confused that I did not get a single reply from the
list
concerning the problem of not re-created configuration files when using  
stored configurations for generating an Icinga/Nagios configuration.  
Please tell me at least if my question if this could be a bug seems to be  
reasonable (see below).

Is there no one else having the same problem? Any ideas from Puppetlabs?

Thanks Bernd
> Well, it turned out that I was not able to create a Puppet configuration  
> whichdoes a reliable re-creation of the Nagios configuration files. My  
> workaround >isnow to restart the Puppet agent with a cron job and before
> restarting I deletethe old configuration files like this:
> /bin/logger "$0: Preparing Puppet agent for execution"
> /bin/rm -f ${CFG_DIR}/*
> /bin/logger "$0: Deleted Icinga configuration files below
$CFG_DIR"
> /bin/logger "$0: Starting Puppet agent now"
> /usr/bin/puppet agent $PUPPET_OPTS
> /bin/logger "$0: Puppet run finished"
>
> Though a little bit ugly, this is now a reliable solution.
>
> I''d like to summarize the problems I''ve encountered:
>
> 1. If stored configurations change within the MySQL database, this will  
> not bereflected in the Nagios configuration files created by the  
> Nagios_* resources >-as described in my first mail.
>
> 2. If I try to do delete the configuration files using a exec resource  
> beforethe Nagios_* resources, I encounter alternating creation and  
> deletion of theconfiguration files - as describe in my second mail.
>
>
> Maybe (2.) was some kind of misconfiguration I did, but at least (1.)  
> could bea bug. Since I got no reply from the list, it seems that
I''m the
> only one everrunning into this problem. So I''d like to ask this
list and
> mainly the Puppetguys if you think this is worth filing a bug?
>
> Thanks
> Bernd
>> -----Ursprüngliche Nachricht-----
>> Von: puppet-users@googlegroups.com [mailto:puppet-
>> us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>> Gesendet: Mittwoch, 9. November 2011 13:44
>> An: ''puppet-users@googlegroups.com''
>> Betreff: [Puppet Users] AW: nagios_service does not replace target file
>>Now I tried this:
>>  exec {"/bin/rm -f
${icinga::baseconfigdir}/${conf_file_hosts}":
>>     require => File["${icinga::baseconfigdir}"],
>>   }
>>  Nagios_host <<||>> {
>>    target =>
"${icinga::baseconfigdir}/${conf_file_hosts}",
>>     require => Exec["/bin/rm -f
>> ${icinga::baseconfigdir}/${conf_file_hosts}"],
>>     before =>
File["${icinga::baseconfigdir}/${conf_file_hosts}"],
>>   }
>>  file { "${icinga::baseconfigdir}/${conf_file_hosts}":
>>     ensure => "present",
>>     owner => "puppet",
>>     group => "puppet",
>>     mode => "0644",
>>     backup => false,
>>     replace => false,
>>   }
>>This created alternating behavior of the file
>> ''${icinga::baseconfigdir}/${conf_file_hosts}''. If the
file was
>> generated, the next run will leave it empty. If it''s empty,
the next
>> run will regenerate the content as expected and so on.
>>I encountered the same behavior when using real Nagios resources like
>> ''nagios_hostgroup'' for example. Is there something
special about Nagios
>> resources which will create this strange behavior?
>>Bernd
>>> -----Ursprüngliche Nachricht-----
>> > Von: puppet-users@googlegroups.com [mailto:puppet-
>> > us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>> > Gesendet: Dienstag, 8. November 2011 17:48
>> > An: ''puppet-users@googlegroups.com''
>> > Betreff: [Puppet Users] nagios_service does not replace target
file
>> >
>> > Hi all,
>> >
>> > I''m using Puppet 2.6.6 on both clients and master along
with stored
>> > configurations. My clients provide Nagios configurations like this
>> > example:
>> >
>> >   @@nagios_service { "check_ping_${hostname}":
>> >        check_command =>
"check_ping!100.0,20%!500.0,60%",
>> >        use => "generic-service",
>> >        host_name => "$fqdn",
>> >        service_description => "${prefix}PING:
${hostname}",
>> >   }
>> >
>> > They are realized on the master with the Nagios_service:
>> >
>> >   Nagios_service <<||>> {
>> >
>> >     target => "${baseconfigdir}/${conf_file_srvs}",
>> >     require =>
File["${baseconfigdir}/${conf_file_srvs}"],
>> >   }
>> >
>> > Since I needed special access rights for the target file
(it''s
>> rsynced
>> > from another host), I added an appropriate file resource:
>> >
>> >   file { "${baseconfigdir}/${conf_file_srvs}":
>> >     ensure => "present",
>> >     owner => "puppet",
>> >     group => "puppet",
>> >     mode => "0644",
>> >     backup => false,
>> >     require => File["${baseconfigdir}"],
>> >   }
>> >
>> > Everything works fine on the first run. But once a client changes
its
>> > Nagios resources, the new configuration will not end up in the
target
>> > file of Nagios_service.
>> >
>> > I checked the table ''resources'' within the MySQL
database after the
>> > client executes - the changes to the exported resources are
>> definitely
>> > done there. (E.g.: mysql> select title,restype from resources
where
>> > host_id=6 and exported=1;)
>> >
>> > I tried to poke around and added
>> >
>> > content => " "
>> >
>> > to the file resource. Or I removed the ''require''
attribute from the
>> > Nagios_service resource. I also tried to keep the
"${baseconfigdir}
>> > clean by adding this resource:
>> >
>> >
>> >   file {"${baseconfigdir}":
>> >     ensure => "directory",
>> >     owner => "puppet",
>> >     group => "puppet",
>> >     mode => "0755",
>> >     backup => false,
>> >     recurse => true,
>> >     purge => true,
>> >     source =>
"puppet:///modules/icinga/puppet_generated",
>> >   }
>> >
>> > Within
''puppet:///modules/icinga/puppet_generated'' there''s
only a
>> > README file. And I thought with ''recurse'' and
''purge'' this will clean
>> > all other files. But obviously not. The only thing that currently
>> helps
>> > is manually deleting the target files.
>> >
>> > There are no errors in the log files, the catalog compiles without
>> > errors, I couldn''t find any related bug entry, so
I''m a little bit
>> lost
>> > at the moment.
>> >
>> > Thanks for any help
>> > Bernd
>> >
-- 
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.

Gabriel Filion

2011-Nov-17 03:36 UTC

head link

Re: [Puppet Users] AW: nagios_service does not replace target file

Hi,

the module I''m using is almost setup the same, but I don''t
experience
the same issue:

the nagios server collects nagios config resources (and sets the target
file for each kind of resource), and there''s a resource for the files
themselves which define the permissions.

however, there''s no "require" link between both.

what happens if you try and remove the require link from Nagios_XYZ ->
${baseconfigdir}/${conf_file_srvs} ?

On 11-11-16 05:57 PM, Bernd Adamowicz wrote:> Hi all,
> 
> I''m a little bit confused that I did not get a single reply from
the
> list concerning the problem of not re-created configuration files when
> using stored configurations for generating an Icinga/Nagios
> configuration. Please tell me at least if my question if this could be a
> bug seems to be reasonable (see below).
> 
> Is there no one else having the same problem? Any ideas from Puppetlabs?
> 
> Thanks Bernd
> 
>> Well, it turned out that I was not able to create a Puppet
>> configuration whichdoes a reliable re-creation of the Nagios
>> configuration files. My workaround >isnow to restart the Puppet
agent
>> with a cron job and before restarting I deletethe old configuration
>> files like this:
> 
>> /bin/logger "$0: Preparing Puppet agent for execution"
>> /bin/rm -f ${CFG_DIR}/*
>> /bin/logger "$0: Deleted Icinga configuration files below
$CFG_DIR"
>> /bin/logger "$0: Starting Puppet agent now"
>> /usr/bin/puppet agent $PUPPET_OPTS
>> /bin/logger "$0: Puppet run finished"
>>
>> Though a little bit ugly, this is now a reliable solution.
>>
>> I''d like to summarize the problems I''ve encountered:
>>
>> 1. If stored configurations change within the MySQL database, this
>> will not bereflected in the Nagios configuration files created by the
>> Nagios_* resources >-as described in my first mail.
>>
>> 2. If I try to do delete the configuration files using a exec resource
>> beforethe Nagios_* resources, I encounter alternating creation and
>> deletion of theconfiguration files - as describe in my second mail.
>>
>>
>> Maybe (2.) was some kind of misconfiguration I did, but at least (1.)
>> could bea bug. Since I got no reply from the list, it seems that
I''m
>> the only one everrunning into this problem. So I''d like to ask
this
>> list and mainly the Puppetguys if you think this is worth filing a bug?
>>
>> Thanks
>> Bernd
> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: puppet-users@googlegroups.com [mailto:puppet-
>>> us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>>> Gesendet: Mittwoch, 9. November 2011 13:44
>>> An: ''puppet-users@googlegroups.com''
>>> Betreff: [Puppet Users] AW: nagios_service does not replace target
file
>>> Now I tried this:
>>>  exec {"/bin/rm -f
${icinga::baseconfigdir}/${conf_file_hosts}":
>>>     require => File["${icinga::baseconfigdir}"],
>>>   }
>>>  Nagios_host <<||>> {
>>>    target =>
"${icinga::baseconfigdir}/${conf_file_hosts}",
>>>     require => Exec["/bin/rm -f
>>> ${icinga::baseconfigdir}/${conf_file_hosts}"],
>>>     before =>
File["${icinga::baseconfigdir}/${conf_file_hosts}"],
>>>   }
>>>  file { "${icinga::baseconfigdir}/${conf_file_hosts}":
>>>     ensure => "present",
>>>     owner => "puppet",
>>>     group => "puppet",
>>>     mode => "0644",
>>>     backup => false,
>>>     replace => false,
>>>   }
>>> This created alternating behavior of the file
>>> ''${icinga::baseconfigdir}/${conf_file_hosts}''. If
the file was
>>> generated, the next run will leave it empty. If it''s
empty, the next
>>> run will regenerate the content as expected and so on.
>>> I encountered the same behavior when using real Nagios resources
like
>>> ''nagios_hostgroup'' for example. Is there
something special about Nagios
>>> resources which will create this strange behavior?
>>> Bernd
>>>> -----Ursprüngliche Nachricht-----
>>> > Von: puppet-users@googlegroups.com [mailto:puppet-
>>> > us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>>> > Gesendet: Dienstag, 8. November 2011 17:48
>>> > An: ''puppet-users@googlegroups.com''
>>> > Betreff: [Puppet Users] nagios_service does not replace target
file
>>> >
>>> > Hi all,
>>> >
>>> > I''m using Puppet 2.6.6 on both clients and master
along with stored
>>> > configurations. My clients provide Nagios configurations like
this
>>> > example:
>>> >
>>> >   @@nagios_service { "check_ping_${hostname}":
>>> >        check_command =>
"check_ping!100.0,20%!500.0,60%",
>>> >        use => "generic-service",
>>> >        host_name => "$fqdn",
>>> >        service_description => "${prefix}PING:
${hostname}",
>>> >   }
>>> >
>>> > They are realized on the master with the Nagios_service:
>>> >
>>> >   Nagios_service <<||>> {
>>> >
>>> >     target =>
"${baseconfigdir}/${conf_file_srvs}",
>>> >     require =>
File["${baseconfigdir}/${conf_file_srvs}"],
>>> >   }
>>> >
>>> > Since I needed special access rights for the target file
(it''s
>>> rsynced
>>> > from another host), I added an appropriate file resource:
>>> >
>>> >   file { "${baseconfigdir}/${conf_file_srvs}":
>>> >     ensure => "present",
>>> >     owner => "puppet",
>>> >     group => "puppet",
>>> >     mode => "0644",
>>> >     backup => false,
>>> >     require => File["${baseconfigdir}"],
>>> >   }
>>> >
>>> > Everything works fine on the first run. But once a client
changes its
>>> > Nagios resources, the new configuration will not end up in the
target
>>> > file of Nagios_service.
>>> >
>>> > I checked the table ''resources'' within the
MySQL database after the
>>> > client executes - the changes to the exported resources are
>>> definitely
>>> > done there. (E.g.: mysql> select title,restype from
resources where
>>> > host_id=6 and exported=1;)
>>> >
>>> > I tried to poke around and added
>>> >
>>> > content => " "
>>> >
>>> > to the file resource. Or I removed the
''require'' attribute from the
>>> > Nagios_service resource. I also tried to keep the
"${baseconfigdir}
>>> > clean by adding this resource:
>>> >
>>> >
>>> >   file {"${baseconfigdir}":
>>> >     ensure => "directory",
>>> >     owner => "puppet",
>>> >     group => "puppet",
>>> >     mode => "0755",
>>> >     backup => false,
>>> >     recurse => true,
>>> >     purge => true,
>>> >     source =>
"puppet:///modules/icinga/puppet_generated",
>>> >   }
>>> >
>>> > Within
''puppet:///modules/icinga/puppet_generated'' there''s
only a
>>> > README file. And I thought with ''recurse''
and ''purge'' this will clean
>>> > all other files. But obviously not. The only thing that
currently
>>> helps
>>> > is manually deleting the target files.
>>> >
>>> > There are no errors in the log files, the catalog compiles
without
>>> > errors, I couldn''t find any related bug entry, so
I''m a little bit
>>> lost
>>> > at the moment.
>>> >
>>> > Thanks for any help
>>> > Bernd
>>> >
> 
-- 
Gabriel Filion

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

Bernd Adamowicz

2011-Nov-17 09:04 UTC

head link

Re: [Puppet Users] AW: nagios_service does not replace target file

Hi,

Removing the ''require'' link leads back to the very first
problem I''ve
encountered: The files are not regenerated even thought the stored  
configurations inside the MySQL database changed (I did check the table  
content before.).

Bernd

On Thu, 17 Nov 2011 04:36:26 +0100, Gabriel Filion <lelutin@gmail.com>  
wrote:
> Hi,
>
> the module I''m using is almost setup the same, but I
don''t experience
> the same issue:
>
> the nagios server collects nagios config resources (and sets the target
> file for each kind of resource), and there''s a resource for the
files
> themselves which define the permissions.
>
> however, there''s no "require" link between both.
>
> what happens if you try and remove the require link from Nagios_XYZ ->
> ${baseconfigdir}/${conf_file_srvs} ?
>
> On 11-11-16 05:57 PM, Bernd Adamowicz wrote:
>> Hi all,
>>
>> I''m a little bit confused that I did not get a single reply
from the
>> list concerning the problem of not re-created configuration files when
>> using stored configurations for generating an Icinga/Nagios
>> configuration. Please tell me at least if my question if this could be
a
>> bug seems to be reasonable (see below).
>>
>> Is there no one else having the same problem? Any ideas from
Puppetlabs?
>>
>> Thanks Bernd
>>
>>> Well, it turned out that I was not able to create a Puppet
>>> configuration whichdoes a reliable re-creation of the Nagios
>>> configuration files. My workaround >isnow to restart the Puppet
agent
>>> with a cron job and before restarting I deletethe old configuration
>>> files like this:
>>
>>> /bin/logger "$0: Preparing Puppet agent for execution"
>>> /bin/rm -f ${CFG_DIR}/*
>>> /bin/logger "$0: Deleted Icinga configuration files below
$CFG_DIR"
>>> /bin/logger "$0: Starting Puppet agent now"
>>> /usr/bin/puppet agent $PUPPET_OPTS
>>> /bin/logger "$0: Puppet run finished"
>>>
>>> Though a little bit ugly, this is now a reliable solution.
>>>
>>> I''d like to summarize the problems I''ve
encountered:
>>>
>>> 1. If stored configurations change within the MySQL database, this
>>> will not bereflected in the Nagios configuration files created by
the
>>> Nagios_* resources >-as described in my first mail.
>>>
>>> 2. If I try to do delete the configuration files using a exec
resource
>>> beforethe Nagios_* resources, I encounter alternating creation and
>>> deletion of theconfiguration files - as describe in my second mail.
>>>
>>>
>>> Maybe (2.) was some kind of misconfiguration I did, but at least
(1.)
>>> could bea bug. Since I got no reply from the list, it seems that
I''m
>>> the only one everrunning into this problem. So I''d like to
ask this
>>> list and mainly the Puppetguys if you think this is worth filing a
bug?
>>>
>>> Thanks
>>> Bernd
>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: puppet-users@googlegroups.com [mailto:puppet-
>>>> us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>>>> Gesendet: Mittwoch, 9. November 2011 13:44
>>>> An: ''puppet-users@googlegroups.com''
>>>> Betreff: [Puppet Users] AW: nagios_service does not replace
target
>>>> file
>>>> Now I tried this:
>>>>  exec {"/bin/rm -f
${icinga::baseconfigdir}/${conf_file_hosts}":
>>>>     require => File["${icinga::baseconfigdir}"],
>>>>   }
>>>>  Nagios_host <<||>> {
>>>>    target =>
"${icinga::baseconfigdir}/${conf_file_hosts}",
>>>>     require => Exec["/bin/rm -f
>>>> ${icinga::baseconfigdir}/${conf_file_hosts}"],
>>>>     before =>
File["${icinga::baseconfigdir}/${conf_file_hosts}"],
>>>>   }
>>>>  file {
"${icinga::baseconfigdir}/${conf_file_hosts}":
>>>>     ensure => "present",
>>>>     owner => "puppet",
>>>>     group => "puppet",
>>>>     mode => "0644",
>>>>     backup => false,
>>>>     replace => false,
>>>>   }
>>>> This created alternating behavior of the file
>>>>
''${icinga::baseconfigdir}/${conf_file_hosts}''. If the file was
>>>> generated, the next run will leave it empty. If it''s
empty, the next
>>>> run will regenerate the content as expected and so on.
>>>> I encountered the same behavior when using real Nagios
resources like
>>>> ''nagios_hostgroup'' for example. Is there
something special about
>>>> Nagios
>>>> resources which will create this strange behavior?
>>>> Bernd
>>>>> -----Ursprüngliche Nachricht-----
>>>> > Von: puppet-users@googlegroups.com [mailto:puppet-
>>>> > us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
>>>> > Gesendet: Dienstag, 8. November 2011 17:48
>>>> > An: ''puppet-users@googlegroups.com''
>>>> > Betreff: [Puppet Users] nagios_service does not replace
target file
>>>> >
>>>> > Hi all,
>>>> >
>>>> > I''m using Puppet 2.6.6 on both clients and master
along with stored
>>>> > configurations. My clients provide Nagios configurations
like this
>>>> > example:
>>>> >
>>>> >   @@nagios_service { "check_ping_${hostname}":
>>>> >        check_command =>
"check_ping!100.0,20%!500.0,60%",
>>>> >        use => "generic-service",
>>>> >        host_name => "$fqdn",
>>>> >        service_description => "${prefix}PING:
${hostname}",
>>>> >   }
>>>> >
>>>> > They are realized on the master with the Nagios_service:
>>>> >
>>>> >   Nagios_service <<||>> {
>>>> >
>>>> >     target =>
"${baseconfigdir}/${conf_file_srvs}",
>>>> >     require =>
File["${baseconfigdir}/${conf_file_srvs}"],
>>>> >   }
>>>> >
>>>> > Since I needed special access rights for the target file
(it''s
>>>> rsynced
>>>> > from another host), I added an appropriate file resource:
>>>> >
>>>> >   file { "${baseconfigdir}/${conf_file_srvs}":
>>>> >     ensure => "present",
>>>> >     owner => "puppet",
>>>> >     group => "puppet",
>>>> >     mode => "0644",
>>>> >     backup => false,
>>>> >     require => File["${baseconfigdir}"],
>>>> >   }
>>>> >
>>>> > Everything works fine on the first run. But once a client
changes
>>>> its
>>>> > Nagios resources, the new configuration will not end up in
the
>>>> target
>>>> > file of Nagios_service.
>>>> >
>>>> > I checked the table ''resources'' within
the MySQL database after the
>>>> > client executes - the changes to the exported resources
are
>>>> definitely
>>>> > done there. (E.g.: mysql> select title,restype from
resources where
>>>> > host_id=6 and exported=1;)
>>>> >
>>>> > I tried to poke around and added
>>>> >
>>>> > content => " "
>>>> >
>>>> > to the file resource. Or I removed the
''require'' attribute from the
>>>> > Nagios_service resource. I also tried to keep the
"${baseconfigdir}
>>>> > clean by adding this resource:
>>>> >
>>>> >
>>>> >   file {"${baseconfigdir}":
>>>> >     ensure => "directory",
>>>> >     owner => "puppet",
>>>> >     group => "puppet",
>>>> >     mode => "0755",
>>>> >     backup => false,
>>>> >     recurse => true,
>>>> >     purge => true,
>>>> >     source =>
"puppet:///modules/icinga/puppet_generated",
>>>> >   }
>>>> >
>>>> > Within
''puppet:///modules/icinga/puppet_generated'' there''s
only a
>>>> > README file. And I thought with
''recurse'' and ''purge'' this will
>>>> clean
>>>> > all other files. But obviously not. The only thing that
currently
>>>> helps
>>>> > is manually deleting the target files.
>>>> >
>>>> > There are no errors in the log files, the catalog compiles
without
>>>> > errors, I couldn''t find any related bug entry, so
I''m a little bit
>>>> lost
>>>> > at the moment.
>>>> >
>>>> > Thanks for any help
>>>> > Bernd
>>>> >
>>
>

-- 
Bernd Adamowicz
Softwaremanagement

Georg-Fahrbach-Straße 21
74653 Ingelfingen-Criesbach
Mobil: +49 (0)171 7278857
Mail: info@bernd-adamowicz.de
http://www.bernd-adamowicz.de

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

Gabriel Filion

2011-Nov-17 21:06 UTC

head link

Re: [Puppet Users] AW: nagios_service does not replace target file

On 11-11-17 04:04 AM, Bernd Adamowicz wrote:> Removing the ''require'' link leads back to the very first
problem I''ve
> encountered: The files are not regenerated even thought the stored
> configurations inside the MySQL database changed (I did check the table
> content before.).
hmm right, sorry you had mentioned this in your original post.

I must say I don''t understand why it wouldn''t be working.
I''m using
puppet 2.6.2 with this module:

https://labs.riseup.net/code/projects/shared-nagios

permissions are set right, and files get modified for new exported
resources.

You said you rsynced the files from somewhere else, though. If you hold
out that rsync process for a while, do you see new services getting
added to the file?

-- 
Gabriel Filion

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

Bernd Adamowicz

2011-Nov-17 21:29 UTC

head link

Re: [Puppet Users] AW: nagios_service does not replace target file

The rsync process does definitely not disturb the generation of the files.  
I''ve checked this several times. However I will have a look at the
module
mentioned by you as soon as I''m back in the office on Monday. Maybe
I''ll
find some issues.

Thanks so far!

Bernd

On Thu, 17 Nov 2011 22:06:02 +0100, Gabriel Filion <lelutin@gmail.com>  
wrote:
> On 11-11-17 04:04 AM, Bernd Adamowicz wrote:
>> Removing the ''require'' link leads back to the very
first problem I''ve
>> encountered: The files are not regenerated even thought the stored
>> configurations inside the MySQL database changed (I did check the table
>> content before.).
>
> hmm right, sorry you had mentioned this in your original post.
>
> I must say I don''t understand why it wouldn''t be working.
I''m using
> puppet 2.6.2 with this module:
>
> https://labs.riseup.net/code/projects/shared-nagios
>
> permissions are set right, and files get modified for new exported
> resources.
>
> You said you rsynced the files from somewhere else, though. If you hold
> out that rsync process for a while, do you see new services getting
> added to the file?
>

-- 
Bernd Adamowicz
Softwaremanagement

Georg-Fahrbach-Straße 21
74653 Ingelfingen-Criesbach
Mobil: +49 (0)171 7278857
Mail: info@bernd-adamowicz.de
http://www.bernd-adamowicz.de

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

Puppet users - Nov 2011 - AW: nagios_service does not replace target file

[Puppet Users] AW: nagios_service does not replace target file

Re: [Puppet Users] AW: nagios_service does not replace target file

Re: [Puppet Users] AW: nagios_service does not replace target file

Re: [Puppet Users] AW: nagios_service does not replace target file

Re: [Puppet Users] AW: nagios_service does not replace target file