[Puppet Users] allow statements in namespaceauth.conf
The namespaceauth.conf file seems to require FQDNs in the allow statements, but does anyone know if 'allow puppet' (assuming a correctly configured DNS CNAME record exists for puppet) will be accepted? Specifically, if I have a namespaceauth.conf that contains: [puppetrunner] allow puppet Will that allow puppetrun to be used from 'puppet' to request a node check in for configuration changes? Do the allow entries always have to have FQDNs? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Possible to maintain bad configs on the client?
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Possible to maintain bad configs on the client?
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 = 64
## 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 = 64
## 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 <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> 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
[Puppet Users] Re: Possible to maintain bad configs on the client?
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 = 64\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 = 64\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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
