Puppet users - Oct 2008 - Possible to maintain bad configs on the client?

I have puppetmaster running on RHEL4, and 2 puppet clients running on 
RHEL5.  All machines are running puppet version is 24.4 installed from 
EPEL.  The issue is that some configurations seem to be unusable by the 
RHEL5 clients when the puppetmaster is running on RHEL4.  However, if I 
put those same configs on the RHEL5 system (serving a RHEL5 client) or 
an F8 setup (client/server) there is no problem.  In the logs on the 
client, I see:

puppetd[10104]: Facts have changed; recompiling
puppetd[10104]: Configuration could not be translated from yaml; using 
cached catalog

Every time the client talks to the RHEL4 server, it thinks the facts 
have changed and need to be recompiled, and the configuration isn''t 
usable by the client.

Some of the configuration being pulled down are flat configuration 
files, whereas some are templates.  Most of the templates seem to be 
fine as do the flat files, but I have one template that I know causes 
this issue.  Is there a way to preserve the configuration the client is 
receiving from the server?  I''ve tried running puppet -vdto, but it 
didn''t give me any information I didn''t already have.  Any
other debug tips?

Rob


--~--~---------~--~----~------------~-------~--~----~
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''m discovered some more info related to this issue, and it''s
rather
disturbing.  I hacked puppetd to print out what it is receiving from the 
server and I believe I have found the issue, but unfortunately it seems 
to bring more questions.

I have a 106 line config file that I modify a few lines in which is my 
template.  The file the client receives has the modifications correctly, 
however the last few lines of the file are messed up.  What seems to 
have happened is that the first few lines of the file have gotten 
re-inserted in the middle of a line near bottom of the file.  So 
basically what should be:

NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central 
managers in the pool.\nCOLLECTOR_HOST = host.domain.com
...
## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n## 
Replication debug level \nREPLICATION_DEBUG = D_COMMAND\n## Replication 
log file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"

Is instead:

NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central 
managers in the pool.\nCOLLECTOR_HOST = host.domain.com
...
## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n## 
Replica"NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential 
central managers in the pool.\nCOLLECTOR_HOST = host.tion debug level 
\nREPLICATION_DEBUG = D_COMMAND\n## Replication log 
file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"

Has anyone else seen this before?

Rob

Robert Rati wrote:
> I have puppetmaster running on RHEL4, and 2 puppet clients running on 
> RHEL5.  All machines are running puppet version is 24.4 installed from 
> EPEL.  The issue is that some configurations seem to be unusable by the 
> RHEL5 clients when the puppetmaster is running on RHEL4.  However, if I 
> put those same configs on the RHEL5 system (serving a RHEL5 client) or 
> an F8 setup (client/server) there is no problem.  In the logs on the 
> client, I see:
> 
> puppetd[10104]: Facts have changed; recompiling
> puppetd[10104]: Configuration could not be translated from yaml; using 
> cached catalog
> 
> Every time the client talks to the RHEL4 server, it thinks the facts 
> have changed and need to be recompiled, and the configuration
isn''t
> usable by the client.
> 
> Some of the configuration being pulled down are flat configuration 
> files, whereas some are templates.  Most of the templates seem to be 
> fine as do the flat files, but I have one template that I know causes 
> this issue.  Is there a way to preserve the configuration the client is 
> receiving from the server?  I''ve tried running puppet -vdto, but
it
> didn''t give me any information I didn''t already have. 
Any other debug tips?
> 
> Rob
> 
> 
> > 
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

What does the template look like?

On Wed, Oct 8, 2008 at 1:16 PM, Robert Rati <rrati@redhat.com> wrote:
>
> I''m discovered some more info related to this issue, and
it''s rather
> disturbing.  I hacked puppetd to print out what it is receiving from the
> server and I believe I have found the issue, but unfortunately it seems
> to bring more questions.
>
> I have a 106 line config file that I modify a few lines in which is my
> template.  The file the client receives has the modifications correctly,
> however the last few lines of the file are messed up.  What seems to
> have happened is that the first few lines of the file have gotten
> re-inserted in the middle of a line near bottom of the file.  So
> basically what should be:
>
> NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central
> managers in the pool.\nCOLLECTOR_HOST = host.domain.com
> ...
> ## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n##
> Replication debug level \nREPLICATION_DEBUG = D_COMMAND\n## Replication
> log file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"
>
> Is instead:
>
> NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central
> managers in the pool.\nCOLLECTOR_HOST = host.domain.com
> ...
> ## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n##
> Replica"NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential
> central managers in the pool.\nCOLLECTOR_HOST = host.tion debug level
> \nREPLICATION_DEBUG = D_COMMAND\n## Replication log
> file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"
>
> Has anyone else seen this before?
>
> Rob
>
> Robert Rati wrote:
> > I have puppetmaster running on RHEL4, and 2 puppet clients running on
> > RHEL5.  All machines are running puppet version is 24.4 installed from
> > EPEL.  The issue is that some configurations seem to be unusable by
the
> > RHEL5 clients when the puppetmaster is running on RHEL4.  However, if
I
> > put those same configs on the RHEL5 system (serving a RHEL5 client) or
> > an F8 setup (client/server) there is no problem.  In the logs on the
> > client, I see:
> >
> > puppetd[10104]: Facts have changed; recompiling
> > puppetd[10104]: Configuration could not be translated from yaml; using
> > cached catalog
> >
> > Every time the client talks to the RHEL4 server, it thinks the facts
> > have changed and need to be recompiled, and the configuration
isn''t
> > usable by the client.
> >
> > Some of the configuration being pulled down are flat configuration
> > files, whereas some are templates.  Most of the templates seem to be
> > fine as do the flat files, but I have one template that I know causes
> > this issue.  Is there a way to preserve the configuration the client
is
> > receiving from the server?  I''ve tried running puppet -vdto,
but it
> > didn''t give me any information I didn''t already
have.  Any other debug
> tips?
> >
> > Rob
> >
> >
> > >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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''ve provided the full template below.  It acts upon cm_list, which is
a
comma separated list of FQDNs.

Rob


NEGOTIATOR_HOST CONDOR_HOST 
## A list of all potential central managers in the pool.
COLLECTOR_HOST = <%= cm_list %>

## Define the port number on which the condor_had daemon will
## listen.  The port must match the port number used
## for when defining HAD_LIST.  This port number is
## arbitrary; make sure that there is no port number collision
## with other applications.
HAD_PORT = 51450
HAD_ARGS = -p $(HAD_PORT)

## The following macro defines the port number condor_replication will 
listen
## on on this machine. This port should match the port number specified
## for that replication daemon in the REPLICATION_LIST
## Port number is arbitrary (make sure no collision with other applications)
## This is a sample port number
REPLICATION_PORT = 41450
REPLICATION_ARGS = -p $(REPLICATION_PORT)

## The following list must contain the same addresses
## as HAD_LIST. In addition, for each hostname, it should specify
## the port number of condor_replication daemon running on that host.
## This parameter is mandatory and has no default value
REPLICATION_LIST = <%= cm_list.split(",").collect { |cm| 
"#{cm}:$(REPLICATION_PORT)" }.join(",") %>

## The following list must contain the same addresses in the same order
## as COLLECTOR_HOST. In addition, for each hostname, it should specify
## the port number of condor_had daemon running on that host.
## The first machine in the list will be the PRIMARY central manager
## machine, in case HAD_USE_PRIMARY is set to true.
HAD_LIST = <%= cm_list.split(",").collect { |cm|
"#{cm}:$(HAD_PORT)"
}.join(",") %>

## HAD connection time.
## Recommended value is 2 if the central managers are on the same subnet.
## Recommended value is 5 if Condor security is enabled.
## Recommended value is 10 if the network is very slow, or
## to reduce the sensitivity of HA daemons to network failures.
HAD_CONNECTION_TIMEOUT = 2

##If true, the first central manager in HAD_LIST is a primary.
HAD_USE_PRIMARY = true

##--------------------------------------------------------------------
##  Host/IP access levels
##--------------------------------------------------------------------

##  What machines have administrative rights for your pool?  This
##  defaults to your central manager.  You should set it to the
##  machine(s) where whoever is the condor administrator(s) works
##  (assuming you trust all the users who log into that/those
##  machine(s), since this is machine-wide access you''re granting).
HOSTALLOW_ADMINISTRATOR = $(HOSTALLOW_ADMINISTRATOR), $(COLLECTOR_HOST)

##  Negotiator access.  Machines listed here are trusted central
##  managers.  You should normally not have to change this.
HOSTALLOW_NEGOTIATOR = $(HOSTALLOW_NEGOTIATOR), $(COLLECTOR_HOST)

## The location of executable files
HAD = $(SBIN)/condor_had
REPLICATION = $(SBIN)/condor_replication

DAEMON_LIST = $(DAEMON_LIST), HAD, REPLICATION
DC_DAEMON_LIST = $(DC_DAEMON_LIST), HAD, REPLICATION

## Enables/disables the replication feature of HAD daemon
## Default: no
HAD_USE_REPLICATION = true

## Name of the file from the SPOOL directory that will be replicated
## Default: $(SPOOL)/Accountantnew.log
STATE_FILE = $(SPOOL)/Accountantnew.log

## Period of time between two successive awakenings of the replication 
daemon
## Default: 300
REPLICATION_INTERVAL = 300

# Period of time, in which transferer daemons have to accomplish the
## downloading/uploading process
## Default: 300
MAX_TRANSFERER_LIFETIME = 300

# Period of time between two successive sends of ClassAds to the 
collector by HAD
## Default: 300
HAD_UPDATE_INTERVAL = 300

## The HAD controls the negotiator, and should have a larger
## backoff constant
MASTER_NEGOTIATOR_CONTROLLER    = HAD
MASTER_HAD_BACKOFF_CONSTANT     = 360

## The size of the log file
MAX_HAD_LOG = 640000
## debug level
HAD_DEBUG = D_COMMAND
## location of the condor_had log file
HAD_LOG = $(LOG)/HADLog

## The size of replication log file
MAX_REPLICATION_LOG = 640000
## Replication debug level
REPLICATION_DEBUG = D_COMMAND
## Replication log file
REPLICATION_LOG = $(LOG)/ReplicationLog


Andrew Shafer wrote:
> What does the template look like?
> 
> On Wed, Oct 8, 2008 at 1:16 PM, Robert Rati <rrati@redhat.com 
> <mailto:rrati@redhat.com>> wrote:
> 
> 
>     I''m discovered some more info related to this issue, and
it''s rather
>     disturbing.  I hacked puppetd to print out what it is receiving from
the
>     server and I believe I have found the issue, but unfortunately it seems
>     to bring more questions.
> 
>     I have a 106 line config file that I modify a few lines in which is my
>     template.  The file the client receives has the modifications
correctly,
>     however the last few lines of the file are messed up.  What seems to
>     have happened is that the first few lines of the file have gotten
>     re-inserted in the middle of a line near bottom of the file.  So
>     basically what should be:
> 
>     NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central
>     managers in the pool.\nCOLLECTOR_HOST = host.domain.com
>     <http://host.domain.com>
>     ...
>     ## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n##
>     Replication debug level \nREPLICATION_DEBUG = D_COMMAND\n## Replication
>     log file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"
> 
>     Is instead:
> 
>     NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all potential central
>     managers in the pool.\nCOLLECTOR_HOST = host.domain.com
>     <http://host.domain.com>
>     ...
>     ## The size of replication log file\nMAX_REPLICATION_LOG = 640000\n##
>     Replica"NEGOTIATOR_HOST =\nCONDOR_HOST =\n\n## A list of all
potential
>     central managers in the pool.\nCOLLECTOR_HOST = host.tion debug level
>     \nREPLICATION_DEBUG = D_COMMAND\n## Replication log
>     file\nREPLICATION_LOG = $(LOG)/ReplicationLog\n"
> 
>     Has anyone else seen this before?
> 
>     Rob
> 
>     Robert Rati wrote:
>      > I have puppetmaster running on RHEL4, and 2 puppet clients
running on
>      > RHEL5.  All machines are running puppet version is 24.4 installed
>     from
>      > EPEL.  The issue is that some configurations seem to be unusable
>     by the
>      > RHEL5 clients when the puppetmaster is running on RHEL4.
>      However, if I
>      > put those same configs on the RHEL5 system (serving a RHEL5
>     client) or
>      > an F8 setup (client/server) there is no problem.  In the logs on
the
>      > client, I see:
>      >
>      > puppetd[10104]: Facts have changed; recompiling
>      > puppetd[10104]: Configuration could not be translated from yaml;
>     using
>      > cached catalog
>      >
>      > Every time the client talks to the RHEL4 server, it thinks the
facts
>      > have changed and need to be recompiled, and the configuration
isn''t
>      > usable by the client.
>      >
>      > Some of the configuration being pulled down are flat
configuration
>      > files, whereas some are templates.  Most of the templates seem to
be
>      > fine as do the flat files, but I have one template that I know
causes
>      > this issue.  Is there a way to preserve the configuration the
>     client is
>      > receiving from the server?  I''ve tried running puppet
-vdto, but it
>      > didn''t give me any information I didn''t already
have.  Any other
>     debug tips?
>      >
>      > Rob
>      >
>      >
>      > >
> 
> 
> 
> 
> > 
--~--~---------~--~----~------------~-------~--~----~
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 Wed, Oct 8, 2008 at 12:42 PM, Robert Rati <rrati@redhat.com>
wrote:
>
> I have puppetmaster running on RHEL4, and 2 puppet clients running on
> RHEL5.  All machines are running puppet version is 24.4 installed from
> EPEL.  The issue is that some configurations seem to be unusable by the
> RHEL5 clients when the puppetmaster is running on RHEL4.  However, if I
> put those same configs on the RHEL5 system (serving a RHEL5 client) or
> an F8 setup (client/server) there is no problem.  In the logs on the
> client, I see:
>
> puppetd[10104]: Facts have changed; recompiling
> puppetd[10104]: Configuration could not be translated from yaml; using
> cached catalog
>
> Every time the client talks to the RHEL4 server, it thinks the facts
> have changed and need to be recompiled, and the configuration
isn''t
> usable by the client.
>
> Some of the configuration being pulled down are flat configuration
> files, whereas some are templates.  Most of the templates seem to be
> fine as do the flat files, but I have one template that I know causes
> this issue.  Is there a way to preserve the configuration the client is
> receiving from the server?  I''ve tried running puppet -vdto, but
it
> didn''t give me any information I didn''t already have. 
Any other debug tips?
>
Just off the top of my head, I would start by looking at the versions
of ruby and ruby ERB. Both FC8 and RHEL5 use newer versions of a lot
of libraries than RHEL4. This may very well cause the templates to be
parsed different enough between version to cause problems like this,
i.e: working when parsed by the newer libs, but not when parsed by the
older libs.

Evan

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

The difference in ruby-libs is my guess as well.  However, and I forgot 
to mention this in my previous posts, if I remove about 5 files from the 
template (just comment lines) then it is just fine.  The ruby code in 
the template executes correctly from the output I see (in the failed 
config), and running erb against the original 106 line template on the 
RHEL4 machine produces the expected results.

It seems the length of the template has an effect on the results for 
some reason...

Rob

Evan Hisey wrote:
> On Wed, Oct 8, 2008 at 12:42 PM, Robert Rati <rrati@redhat.com>
wrote:
>> I have puppetmaster running on RHEL4, and 2 puppet clients running on
>> RHEL5.  All machines are running puppet version is 24.4 installed from
>> EPEL.  The issue is that some configurations seem to be unusable by the
>> RHEL5 clients when the puppetmaster is running on RHEL4.  However, if I
>> put those same configs on the RHEL5 system (serving a RHEL5 client) or
>> an F8 setup (client/server) there is no problem.  In the logs on the
>> client, I see:
>>
>> puppetd[10104]: Facts have changed; recompiling
>> puppetd[10104]: Configuration could not be translated from yaml; using
>> cached catalog
>>
>> Every time the client talks to the RHEL4 server, it thinks the facts
>> have changed and need to be recompiled, and the configuration
isn''t
>> usable by the client.
>>
>> Some of the configuration being pulled down are flat configuration
>> files, whereas some are templates.  Most of the templates seem to be
>> fine as do the flat files, but I have one template that I know causes
>> this issue.  Is there a way to preserve the configuration the client is
>> receiving from the server?  I''ve tried running puppet -vdto,
but it
>> didn''t give me any information I didn''t already have.
Any other debug tips?
>>
> Just off the top of my head, I would start by looking at the versions
> of ruby and ruby ERB. Both FC8 and RHEL5 use newer versions of a lot
> of libraries than RHEL4. This may very well cause the templates to be
> parsed different enough between version to cause problems like this,
> i.e: working when parsed by the newer libs, but not when parsed by the
> older libs.
> 
> Evan
> 
> > 
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---