[Puppet Users] Re: Creation of modifiable files via puppet
Thanks for all the help, the two solutions + using them both together will solve all the situations I'm considering. Paul On Tuesday, October 9, 2012 9:19:20 AM UTC+4, pdurkin wrote: I've been looking around but can't seem to find an answer to this. I would like to create a file whose initial contents come from the default in the puppet server but is subsequently modifiable and puppet won't overwrite any changes. The reason for this is that if I deploy a user account via puppet and upload a default .bashrc/.profile, the user should be able to modify these without having puppet change them back to the originals every time it runs. Thanks Paul -- 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/-/CDzGG-naGVUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet client not listening on port 8139
Hi everyone,
Please help, I have built a new server and installed puppet (2.6.17)
running on RHEL 6.3. It seems that it is not listening on port 8139.
iptables -L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
/etc/puppet/puppet.conf:
[main]
# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet
# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet
# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl
[agent]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion. Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt
# Where puppetd caches the local configuration. An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig
listen = true
server = mypuppet server.fqdn
/etc/puppet/namespaceauth.conf:
[puppetmaster]
allow mypuppet server.fqdn
/etc/puppet/auth.conf:
# This is an example auth.conf file, it mimics the puppetmasterd defaults
#
# The ACL are checked in order of appearance in this file.
#
# Supported syntax:
# This file supports two different syntax depending on how
# you want to express the ACL.
#
# Path syntax (the one used below):
# -
# path /path/to/resource
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The path is matched as a prefix. That is /file match at
# the same time /file_metadat and /file_content.
#
# Regex syntax:
# -
# This one is differenciated from the path one by a '~'
#
# path ~ regex
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The regex syntax is the same as ruby ones.
#
# Ex:
# path ~ .pp$
# will match every resource ending in .pp (manifests files for instance)
#
# path ~ ^/path/to/resource
# is essentially equivalent to path /path/to/resource
#
# environment:: restrict an ACL to a specific set of environments
# method:: restrict an ACL to a specific set of methods
# auth:: restrict an ACL to an authenticated or unauthenticated request
# the default when unspecified is to restrict the ACL to authenticated
requests
# (ie exactly as if auth yes was present).
#
### Authenticated ACL - those applies only when the client
### has a valid certificate and is thus authenticated
# allow nodes to retrieve their own catalog (ie their configuration)
path ~ ^/catalog/([^/]+)$
method find
allow $1
# allow all nodes to access the certificates services
path /certificate_revocation_list/ca
method find
allow *
# allow all nodes to store their reports
path /report
method save
allow *
# Puppetrun settings
path /run
allow mypuppet server fqdn
# inconditionnally allow access to all files services
# which means in practice that fileserver.conf will
# still be used
path /file
allow *
### Unauthenticated ACL, for clients for which the current master doesn't
### have a valid certificate
# allow access to the master CA
path /certificate/ca
auth no
method find
allow *
path /certificate/
auth no
method find
allow *
path /certificate_request
auth no
method find, save
allow *
# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any
It seems as though the puppet is running:
4074 ?Ss 0:00 /usr/bin/ruby /usr/sbin/puppetd
--server=mypuppetserver.fqdn --logdest=/var/log/puppet/puppet.log
But I cant even telnet to port 8139 on the localhost to test that the port
is open.
Can any one please help?
Any suggestions welcome, I have copied the /etc/puppet/*.conf files from
another working server.
Please Help!
--
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/-/7kFNpVNAyd4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Scalability and performance
Hi guys, I am pretty new to this space, playing around with a few tools. I am trying to read up on how I would scale Puppet (or other tools) up in my installation, and came across this blog post comparing Puppet and CFEngine: http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/ The numbers presented here are pretty extreme: CFEngine agents running 166 times faster than Puppet agents in a small installation - and the difference is increasing? Also, it seems to be the case that Puppet is more centralized which results in everything slowing down: as the master gets more loaded, all the Puppet agents run slower. Is this correct? Could some of you with more experience please comment on this? Thanks. -- 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/-/5LcBoBBaZGQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Scalability and performance
On Tue, Oct 9, 2012 at 4:56 PM, Robjon robertjo...@gmx.us wrote: Hi guys, I am pretty new to this space, playing around with a few tools. I am trying to read up on how I would scale Puppet (or other tools) up in my installation, and came across this blog post comparing Puppet and CFEngine: http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/ The numbers presented here are pretty extreme: CFEngine agents running 166 times faster than Puppet agents in a small installation The results of that paper are not very realistic. The benchmark is based on doing nothing but running echo commands. Since cfengine is written in C (or C++) there is not question that it will perform many actions faster than Puppet, but saying that it is 100X faster or whatever is disingenuous (unless you can manage your infrastructure with nothing but echo commands). I would be more interested to see comparisons based on real admin tasks like managing packages or services. - and the difference is increasing? Also, it seems to be the case that Puppet is more centralized which results in everything slowing down: as the master gets more loaded, all the Puppet agents run slower. it is possible to either run puppet with or without a master. If you want more centralized control, use a master, if you need something that scales to the extreme, run puppet without a master using puppet apply (which is must more similar to how cfengine works) Is this correct? Could some of you with more experience please comment on this? Thanks. -- 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/-/5LcBoBBaZGQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the wrong
user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go. Really
though, I'd hoped that puppet had some kind of provision for starting
services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or do
they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem, but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet goes
and resets them all to system_u which is what they should be when checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and puppet is
going to be resetting them.
For some more detail, I've written something which will set the mysqld_db_t
selinux file_context on my data directories which are in /home, and I have a
notify which will go and check and re-set the selinux file_context if there
are any changes in these directories. They're set to recurse, so to stop
Puppet changing things from unconfined_u to system_u on a regular basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their heads!
:) I was going to make the file_context stuff much more re-usable, but want
to get my head around the best practices first - as I'm not that experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context} \${name}(/.*)?\,
unless = semanage fcontext -l | grep '^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}' | grep
\${context}\,
require = File[$name],
refreshonly = true,
}
}
add_selinux_context { $mysqldirs:
context = mysqld_db_t,
}
# Keep it running
service { mysqld:
ensure= running,
hasstatus = true,
require = [ Package[mysql-server], File[$mysqldirs], ]
}
--
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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Create files from array - Duplicate declaration
hello,
i want to create some files with an array:
class files (
...
$type = [ file1, file2, file3, file4, file5, file5 ]
) {
define rsyslog($owner = root, $group = root, $mode = 644,
$ensure = present) {
file {/etc/rsyslog.d/$type.conf:
ensure = $ensure,
owner = $owner,
group = $group,
mode= $mode,
content = template('template.erb'),
}
}
rsyslog { $type: }
}
Puppet says Duplicate declaration:
File[/etc/rsyslog.d/oevd-intern-accesserrors.conf *(and how to fix this?*)]
is already declared in file
It works with only one element in my array...
anyone can help me?
--
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/-/jiEFtSDdGL8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
Well, I've decided on a very simple way of doing this,
# Keep it running
service { mysqld:
ensure = running,
start = runcon -u system_u /etc/init.d/mysqld start,
hasrestart = false,
require= [ Package[mysql-server], File[$mysqldirs], ],
}
so, it starts under the correct selinux user context, and then using
restart on the init script is disabled so that it makes use of the start
command when doing a restart.
Not sure if this would be something that would make a good resource flag?
Many thanks. Tom.
On 10/10/12 07:55, Tom wrote:
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the
wrong user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go.
Really though, I'd hoped that puppet had some kind of provision for
starting services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or
do they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are
managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem,
but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when
MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet
goes
and resets them all to system_u which is what they should be when
checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and
puppet is
going to be resetting them.
For some more detail, I've written something which will set the
mysqld_db_t
selinux file_context on my data directories which are in /home, and
I have a
notify which will go and check and re-set the selinux file_context
if there
are any changes in these directories. They're set to recurse, so to
stop
Puppet changing things from unconfined_u to system_u on a regular
basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was
wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their
heads!
:) I was going to make the file_context stuff much more re-usable,
but want
to get my head around the best practices first - as I'm not that
experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context}
\${name}(/.*)?\,
unless = semanage fcontext -l | grep
'^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}'
| grep
\${context}\,
require = File[$name],
refreshonly = true,
}
}
add_selinux_context { $mysqldirs:
context = mysqld_db_t,
}
# Keep it running
service { mysqld:
ensure= running,
hasstatus = true,
require = [ Package[mysql-server], File[$mysqldirs], ]
}
--
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] Note on openssl on Ubuntu 12.04.0
Hello, Just a heads up to anyone who might be looking to run puppet on ubuntu 12.04.0 - you might wanna update your openssl and libssl packages (updates are available) for ssl to work properly, due to this bug https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/986147. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Create files from array - Duplicate declaration
On Wed, Oct 10, 2012 at 1:23 PM, Patrick
patrick.rohrb...@googlemail.com wrote:
hello,
i want to create some files with an array:
class files (
...
$type = [ file1, file2, file3, file4, file5, file5 ]
) {
define rsyslog($owner = root, $group = root, $mode = 644,
$ensure = present) {
file {/etc/rsyslog.d/$type.conf:
You could use $name here instead of $type,
ensure = $ensure,
owner = $owner,
group = $group,
mode= $mode,
content = template('template.erb'),
}
}
rsyslog { $type: }
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Create files from array - Duplicate declaration
Now puppet says Cannot reassign variable name... -- 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/-/b4ufhZOEEU8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] expiry attribut of users applied every time
Hello, I have class users with manage some user accounts. for some of them i have set the expiry attribut in the past '2012-01-01' to disable the account. The problem is that puppet set this expiration date at every run: ... /Stage[main]/Users/User[x]/expiry: defined 'expiry' as '2012-01-01' ... What is wrong? Thanks in advance. -- 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/-/P7y373uIIW0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Create files from array - Duplicate declaration
Fixed now :)
Just replaced $type (is used by puppet) with $logtype and used $name for
the files.
But my last problem ist the template.
I'm using %= scope.lookupvar('oevd_opendj::logtype') % and puppet writes
file1file2file3file4
How can i resolve that?
Am Mittwoch, 10. Oktober 2012 10:31:59 UTC+2 schrieb Patrick:
Now puppet says Cannot reassign variable name...
--
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/-/Acqm6XAn_RcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet caught TERM; calling stop - error
This may be related to the latest kernel: 2.6.32-279.9.1.el6.x86_64. My other CentOS 6.3 hosts with 2.6.32-279.5.2.el6.x86_64 kernel do not experience this issue. Anyone else have this problem? -- 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/-/-kAsCG1EqfwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet 3 and ENC deploy ... nothing
Hi @all, I have a problem with my Puppet setup after upgrading to Puppet 3 (OS: SL6.3). I use a puppetmaster with ENC (foreman) to provide classes to my clients. On the master, everything looks good as far as I can tell: $ cat /etc/puppet/puppet.conf ### /etc/puppet/puppet.conf # # Puppet configuration file # [main] # Non-default locations logdir = /var/log/puppet rundir = /var/run/puppet ssldir = /var/lib/puppet/ssl # Report to master puppet server report = true report_server = puppet.int.domain.local reports = log,foreman # Fact synchronisation pluginsync = true [agent] # Non-default locations classfile = /var/lib/puppet/classes.txt localconfig = /var/lib/puppet/localconfig # Interval and master runinterval = 3600 server = puppet.int.domain.local # Report actions report = true graph = true [master] # Settings for local database used by puppetmaster storeconfigs = true dbadapter = mysql dbuser = puppet dbpassword = dbserver = localhost dbsocket = /var/lib/mysql/mysql.sock # Syslog settings syslogfacility = user # The server through which to send email reports. smtpserver = mail.int.domain.local # Settings for reporting rrdgraph = true # Fix SSL settings ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY # Manage Puppet nodes configuration with Foreman external_nodes = /etc/puppet/node.rb node_terminus = exec $ /etc/puppet/node.rb wiki.int.domain.local --- parameters: root_pw: XX hostgroup: web mac: XX:XX:XX:XX:XX:XX foreman_env: production owner_email: XX comment: Mediawiki Server ip: XXX.XXX.XXX.XX owner_name: Thomas Bendler puppetmaster: domainname: int.domain.local (Unknown) classes: backup::bacula::client: mail::ssmtp: custom: backup::bacula: security: virtual: management: common: monitor: environment: production $ So far, so good. When I exceute the puppet agent on the client side it also looks good: $ puppet agent --test Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Caching catalog for wiki.int.domain.local Info: Applying configuration version '1349862242' Finished catalog run in 0.16 seconds $ But when I check the classes that are applied on this box I see only: $ cat /var/lib/puppet/classes.txt settings $ So it look like that not even one class is deployed on this box. This also applies to all other systems and when I change things in my current classes there is also nothing deployed to the clients. Any hints? Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Scalability and performance
Also, be aware that (unless this changed in 3.0), Exec statements and Service statements in Puppet stack into some sort of queue. Moving all Execs to simple native types will increase your performance dramatically and there are good examples of how to do this in the Puppet Labs stdlib module. I posted about this before but I'm not sure if there was a resolution. Trevor On Wed, Oct 10, 2012 at 2:44 AM, Dan Bode d...@puppetlabs.com wrote: On Tue, Oct 9, 2012 at 4:56 PM, Robjon robertjo...@gmx.us wrote: Hi guys, I am pretty new to this space, playing around with a few tools. I am trying to read up on how I would scale Puppet (or other tools) up in my installation, and came across this blog post comparing Puppet and CFEngine: http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/ The numbers presented here are pretty extreme: CFEngine agents running 166 times faster than Puppet agents in a small installation The results of that paper are not very realistic. The benchmark is based on doing nothing but running echo commands. Since cfengine is written in C (or C++) there is not question that it will perform many actions faster than Puppet, but saying that it is 100X faster or whatever is disingenuous (unless you can manage your infrastructure with nothing but echo commands). I would be more interested to see comparisons based on real admin tasks like managing packages or services. - and the difference is increasing? Also, it seems to be the case that Puppet is more centralized which results in everything slowing down: as the master gets more loaded, all the Puppet agents run slower. it is possible to either run puppet with or without a master. If you want more centralized control, use a master, if you need something that scales to the extreme, run puppet without a master using puppet apply (which is must more similar to how cfengine works) Is this correct? Could some of you with more experience please comment on this? Thanks. -- 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/-/5LcBoBBaZGQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
Tom,
It seems like having that as a parameter in the service type might be a
good idea worthy of at least some further discussion. Want to open a
feature request in Redmine to track it? I might (eventually) take a stab
at adding support for it.
Sean
On Wed, 2012-10-10 at 09:01 +0100, Tom wrote:
Well, I've decided on a very simple way of doing this,
# Keep it running
service { mysqld:
ensure = running,
start = runcon -u system_u /etc/init.d/mysqld start,
hasrestart = false,
require= [ Package[mysql-server], File[$mysqldirs], ],
}
so, it starts under the correct selinux user context, and then using
restart on the init script is disabled so that it makes use of the start
command when doing a restart.
Not sure if this would be something that would make a good resource flag?
Many thanks. Tom.
On 10/10/12 07:55, Tom wrote:
Hi,
Thanks for the response. Really, I think the way I'm approaching this
is thinking about starting mysqld under the right selinux user context
so that it doesn't label its own files incorrectly. Every time a
database or table is created, MySQL will be creating it under the
wrong user context, and selinux will then go and reset it back.
I think maybe a wrapper script using runcon which invokes the mysqld
service under the correct context is going to be the way to go.
Really though, I'd hoped that puppet had some kind of provision for
starting services with the correct user context!
Just wondering if anyone else has had the same issue in the past, or
do they just ignore all those seluser notifications? :-)
Many thanks. Tom.
On 10/10/12 01:50, Peter Brown wrote:
You need to add a require to the service for the config files you are
managing.
I find the best way to do that is put all the config files in a config
subclass and then require that in in the service.
On 10 October 2012 01:02, Tomt...@t0mb.net wrote:
Hi list,
I've got an issue at the moment, which isn't really a big problem,
but an
untidy annoyance really, and I'd just like to understand what the best
practice might be when dealing with the issue.
As a really quick summary, the issue is that Puppet is starting up the
mysqld service for the first time as unconfined_u, and then when
MySQL goes
and creates a load of its initial files also as unconfined_u, Puppet
goes
and resets them all to system_u which is what they should be when
checking
matchpathcon:
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and
puppet is
going to be resetting them.
For some more detail, I've written something which will set the
mysqld_db_t
selinux file_context on my data directories which are in /home, and
I have a
notify which will go and check and re-set the selinux file_context
if there
are any changes in these directories. They're set to recurse, so to
stop
Puppet changing things from unconfined_u to system_u on a regular
basis, and
sending refresh notices to my Exec resources, I've set
selinux_ignore_defaults to true in my File resources.
This strikes me as a bit of a dirty way of doing things, and I was
wondering
if anyone had any better ideas of how to manage this.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their
heads!
:) I was going to make the file_context stuff much more re-usable,
but want
to get my head around the best practices first - as I'm not that
experiened
with all of this stuff to be honest!
Many thanks. Tom.
# List of directories we're going to use with MySQL
$mysqldirs = [ /home/data, /home/logs, /home/mysqltmp, ]
# Set SELinux contexts
define add_selinux_context ($context = mysqld_db_t) {
file { $name:
ensure = directory,
owner = mysql,
group = mysql,
seltype = mysqld_db_t,
selinux_ignore_defaults = true,
recurse = true,
require = Package[mysql-server],
notify = [ Exec[add_file_context_${context}_${name}],
Exec[set_file_context_${context}_${name}], ],
}
# Set the default file_context regex for the path
exec { add_file_context_${context}_${name}:
command = semanage fcontext -a -t ${context}
\${name}(/.*)?\,
unless = semanage fcontext -l | grep
'^${name}(/.*)?:${context}:',
require = [ Package[policycoreutils-python], File[$name], ],
refreshonly = true,
}
# Reset the file_context using restorecon
exec { set_file_context_${context}_${name}:
command = restorecon -R ${name},
unless = ls -d --scontext ${name} | awk -F: '{print \$3}'
| grep
\${context}\,
require = File[$name],
[Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
Nobody has found this issue? On Monday, October 8, 2012 5:08:33 PM UTC+2, David Campos wrote: Hi all, I'm trying to migrate our configuration from puppet 2.6.7 to 3.0.0 but I am having a strange issue whilst applying the catalog. Error: Could not retrieve catalog from remote server: Could not intern from yaml: allocator undefined for Proc /usr/lib/ruby/1.8/yaml.rb:133:in `transfer' /usr/lib/ruby/1.8/yaml.rb:133:in `node_import' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/site_ruby/1.8/puppet/network/formats.rb:7:in `intern' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:12:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:12:in `protect' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:26:in `intern' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:108:in `convert_from' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:61:in `deserialize' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:121:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:244:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:348:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:347:in `thinmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:243:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:67:in `retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:107:in `prepare_and_retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:159:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:119:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:42:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:84:in `run_in_fork' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:41:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:338:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:311:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:76:in `execute' /usr/bin/puppet:10 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Debug: report supports formats: b64_zlib_yaml raw yaml; using yaml I only find references to an old 2010 bug but nothing helps me to solve this an apply the catalog. The catalog works on 2.x nodes by the way. Puppet master: 3.0.0 Puppet agent: either 2.6.7 or 3.0.0 -- 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/-/JFVXsYEsx1EJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet caught TERM; calling stop - error
On 10/4/12 8:32 AM, Will S. G. wrote: Wed Oct 03 23:26:55 -0700 2012 Puppet (err): Could not retrieve catalog from remote server: Error 400 on SERVER: could not obtain a database connection within 5 seconds. The max pool size is currently 5; consider increasing it. The puppet master is attempting to connect to a database to get information needed to compile the catalog and is timing out. Try setting playing around with setting dbconnections = some_positive_integer in your puppet.conf. If you are still having issues, post your puppet.conf in your reply. Regards, -g -- Garrett Honeycutt 206.414.8658 http://puppetlabs.com -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Escaping a /
Hi All
On the face of it this seems like it should be fairly simple.
Im using a shorewall module details of which can be found, according to the
README, here
http://reductivelabs.com/trac/puppet/wiki/Recipes/AqueosShorewall
I'm trying to create a shorewall hosts file, my module looks like:
class firewall::host{
shorewall::host {${interface_public}:0.0.0.0/0:
zone = 'net',
order = 100;
}
}
where $interface_admin in this case = bond0.2
From this I expect something like:
net bond0.2:0.0.0.0/0
Howerver I instead get
err:
/Stage[main]/Firewall::Host/Shorewall::Host[bond0.2:0.0.0.0/0]/Shorewall::Entry[hosts-100-bond0.2:0.0.0.0/0]/Concat_fragment[managed_file_hosts+100-bond0.2:0.0.0.0/0.tmp]/content:
change from net bond0.2:0.0.0.0/0 tcpflags,blacklist,norfc1918
to net bond0.2:0.0.0.0/0 tcpflags,blacklist,norfc1918
failed: No such file or directory -
/var/lib/puppet/concat/fragments/managed_file_hosts/100-bond0.2:0.0.0.0/0.tmp
I suspect that the /0 being used for the CIDR notation is confusing the
concat module and it thinks that
managed_file_hosts+100-bond0.2:0.0.0.0/0.tmp should be a directory when
in fact it should not.
I attempted to escape the / with \ but got a similar error:
err:
/Stage[main]/Firewall::Host/Shorewall::Host[bond0.2:0.0.0.0\/0]/Shorewall::Entry[hosts-100-bond0.2:0.0.0.0\/0]/Concat_fragment[managed_file_hosts+100-bond0.2:0.0.0.0\/0.tmp]/content:
change from net bond0.2:0.0.0.0\/0 tcpflags,blacklist,norfc1918
to net bond0.2:0.0.0.0\/0 tcpflags,blacklist,norfc1918
failed: No such file or directory -
/var/lib/puppet/concat/fragments/managed_file_hosts/100-bond0.2:0.0.0.0\/0.tmp
I expect that I am missing something glaringly obvious but any pointers
would be appreciated.
Regards
--
Callum
--
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/-/cOk1rasjED0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Create files from array - Duplicate declaration
ok fixed now ;)
Am Mittwoch, 10. Oktober 2012 13:14:34 UTC+2 schrieb Patrick:
Am Mittwoch, 10. Oktober 2012 12:25:39 UTC+2 schrieb kish:
On Wed, Oct 10, 2012 at 2:52 PM, Patrick
patrick@googlemail.com wrote:
Fixed now :)
Just replaced $type (is used by puppet) with $logtype and used $name
for the
files.
But my last problem ist the template.
I'm using %= scope.lookupvar('oevd_opendj::logtype') % and puppet
writes
file1file2file3file4
How can i resolve that?
You should iterate on logtype.
eg.
% env_settings.each do |env_setting| -%
%= env_setting %
% end -%
That should help.
Thanks.
But i think there is a problem now:
$InputFilename /opt/app/logs/%= logtype %
I have to replace %= logtype % with the current logtype
eg.
if puppet create the errors.conf file so $InputFilename should be
/opt/appt/errors.
scope.lookupvar('oevd_opendj::name') % does not work.
--
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/-/xDnm0tHZaxAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Scalability and performance
On Wednesday, October 10, 2012 6:48:20 AM UTC-5, Trevor Vaughan wrote: Also, be aware that (unless this changed in 3.0), Exec statements and Service statements in Puppet stack into some sort of queue. Moving all Execs to simple native types will increase your performance dramatically and there are good examples of how to do this in the Puppet Labs stdlib module. I posted about this before but I'm not sure if there was a resolution. As far as I know, the Puppet agent is single-threaded and serializes application of all resources of all types. I understood that to be an invariant of the execution model (i.e. intentional). Is that not / no longer true? John -- 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/-/KbSPhSZtFFkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Intermittent freeze on select when running standalone
Well working round the issue turned out to be quite painless really. To use the latest release: *wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb sudo dpkg -i puppetlabs-release-precise.deb sudo apt-get update sudo apt-get install puppet* With similar for the puppet master node too. *wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb sudo dpkg -i puppetlabs-release-precise.deb sudo apt-get update sudo apt-get install puppetmaster* David. On 30 July 2012 01:17, Joe Topjian joe.topj...@cybera.ca wrote: Hi Christopher, I didn't have any difficulty replacing the version in Ubuntu 10.04 with the version in Debian Squeeze. (Albeit that I rebuilt the package from the source deb.) It helped me get puppet kick going everywhere. Right. I did not mean that it's difficult to replace the stock package. I'm more frustrated at the extra step needed to upgrade the stock package given that 12.04 is the latest version of Ubuntu + it's an LTS release. This means that administrators will either have a special step to upgrade the stock version of puppet (and then maintain that non-stock version from there on out) or will have to put up with the bug mentioned in this thread as well as miss out on built-in puppet module support. All of which would not be necessary if 12.04 just shipped with 2.7.12+. The comment was more whining on my part. Thanks, Joe -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. -- 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Need help with rspec-puppet
Anybody else received this or similar error?
What I was able to figure out so far is that:
by adding require 'puppet' to the spec test my error changes to:
Error converting value for param 'plugindest': Error converting value for
param 'libdir': Could not find value for $vardir on node puppet-demo
So not a big improvement. The error probably occurs before the test itself.
Because the error is the same even if I delete the tested .pp file.
Any help would be appreciated :-).
Dňa štvrtok, 4. októbra 2012 10:24:48 UTC+2 Jian napísal(-a):
Hello Everyone,
I am fairly new to puppet and I would like to run som unit tests. I hope
rspec is the right tool for it. Unfortunately, after setting it up, when I
try to execute it I receive the following error:
Failures:
1) helloworld
Failure/Error: it { should include_class('helloworld') }
Puppet::Error:
Error converting value for param 'deviceconfig': Could not find
value for $confdir on node puppet-demo
# ./spec/classes/helloworld_spec.rb:8
Thiss error pops up for any test I try.
I wasn't able to find a solution yet. Can you please give me any advice?
Thank you.
--
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/-/B0NXfe9dD1gJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Need help with rspec-puppet
On Wednesday, October 10, 2012 9:43:47 AM UTC-5, Jian wrote:
Anybody else received this or similar error?
What I was able to figure out so far is that:
by adding require 'puppet' to the spec test my error changes to:
Error converting value for param 'plugindest': Error converting value for
param 'libdir': Could not find value for $vardir on node puppet-demo
So not a big improvement. The error probably occurs before the test
itself. Because the error is the same even if I delete the tested .pp file.
Any help would be appreciated :-).
What version of puppet are you using?
Can you share your code - module and test? Either put in the email, or for
better readability, use pastie or gist.
Dňa štvrtok, 4. októbra 2012 10:24:48 UTC+2 Jian napísal(-a):
Hello Everyone,
I am fairly new to puppet and I would like to run som unit tests. I hope
rspec is the right tool for it. Unfortunately, after setting it up, when I
try to execute it I receive the following error:
Failures:
1) helloworld
Failure/Error: it { should include_class('helloworld') }
Puppet::Error:
Error converting value for param 'deviceconfig': Could not find
value for $confdir on node puppet-demo
# ./spec/classes/helloworld_spec.rb:8
Thiss error pops up for any test I try.
I wasn't able to find a solution yet. Can you please give me any advice?
Thank you.
--
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/-/LjuS6r4Q0DEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Service Resources and Selinux
On Tuesday, October 9, 2012 10:02:26 AM UTC-5, Tom B. wrote: Hi list, I've got an issue at the moment, which isn't really a big problem, but an untidy annoyance really, and I'd just like to understand what the best practice might be when dealing with the issue. As a really quick summary, the issue is that Puppet is starting up the mysqld service for the first time as unconfined_u, and then when MySQL goes and creates a load of its initial files also as unconfined_u, Puppet goes and resets them all to system_u which is what they should be when checking matchpathcon: Unless you configure it differently, Puppet uses the system's normal service management commands to control services. It is the responsibility of that tool (e.g. /sbin/service) to start the service in the correct way, including SELinux context, based on whatever criteria it uses to choose such things. Among other things, this means that you will get the same result if Puppet starts the service as you would if the system initialization program starts it at boot. To the extent that your services' behaviors depend on system resources such as configuration files or certain directories, it is your responsibility to describe those dependencies to Puppet (supposing you managing them via Puppet). If you do, then Puppet will manage those resources in the a sequence consistent with those dependencies. The question, therefore, is not so much about how Puppet starts the service, but rather about how to configure the service's SELinux context. The thing is, because the service is started as unconfined_u, any databases/tables that are created are going to inherit that, and puppet is going to be resetting them. Puppet can be instructed to restart the service if resources on which it depends are modified (by Puppet). For some more detail, I've written something which will set the mysqld_db_t selinux file_context on my data directories which are in /home, and I have a notify which will go and check and re-set the selinux file_context if there are any changes in these directories. They're set to recurse, so to stop Puppet changing things from unconfined_u to system_u on a regular basis, and sending refresh notices to my Exec resources, I've set selinux_ignore_defaults to true in my File resources. This strikes me as a bit of a dirty way of doing things, and I was wondering if anyone had any better ideas of how to manage this. It strikes me as a backwards way of doing things. You are trying to clean up the effects of a service misconfiguration instead of configuring the service correctly in the first place. Please find below a sample of the relevant code - because I'm sure my verbose description is probably leaving some people scratching their heads! :) I was going to make the file_context stuff much more re-usable, but want to get my head around the best practices first - as I'm not that experiened with all of this stuff to be honest! I'm afraid your code still leaves me scratching my head. I get the feeling that you're doing a lot of work you don't need to be doing, but I'm not conversant enough with MySQL SELinux configuration to know what you should be doing instead. John -- 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/-/ojA1Ycp4YkkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Service Resources and Selinux
On Wednesday, October 10, 2012 7:08:21 AM UTC-5, Sean Millichamp wrote: Tom, It seems like having that as a parameter in the service type might be a good idea worthy of at least some further discussion. [T]hat refers to an SELinux context in which the service management commands are supposed to be executed? Want to open a feature request in Redmine to track it? I might (eventually) take a stab at adding support for it. As you might infer from my other response, I think that's altogether the wrong approach. Puppet should not provide such a parameter, because it invites users to misconfigure their systems (by using the proposed parameter as a workaround). Services' configuration and the system tools should control services' runtime parameters, including their SELinux context. Otherwise, the service cannot be started properly during system initialization, and it can easily be (re)started incorrectly during manual administration. John -- 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/-/EpH0O46rKWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet client not listening on port 8139
On 2012-10-10 02:35, Pondy wrote:
Hi everyone,
Please help, I have built a new server and installed puppet (2.6.17)
running on RHEL 6.3. It seems that it is not listening on port 8139.
By default, puppet listens on 8140, not 8139. And your configuration
doesn't seem to be specifying an alternative port.
maybe that's what you ought to looking for?
tcp0 0 0.0.0.0:81400.0.0.0:*
LISTEN 18794/ruby1.8
iptables -L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
/etc/puppet/puppet.conf:
[main]
# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet
# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet
# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl
[agent]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion. Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt
# Where puppetd caches the local configuration. An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig
listen = true
server = mypuppet server.fqdn
/etc/puppet/namespaceauth.conf:
[puppetmaster]
allow mypuppet server.fqdn
/etc/puppet/auth.conf:
# This is an example auth.conf file, it mimics the puppetmasterd defaults
#
# The ACL are checked in order of appearance in this file.
#
# Supported syntax:
# This file supports two different syntax depending on how
# you want to express the ACL.
#
# Path syntax (the one used below):
# -
# path /path/to/resource
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The path is matched as a prefix. That is /file match at
# the same time /file_metadat and /file_content.
#
# Regex syntax:
# -
# This one is differenciated from the path one by a '~'
#
# path ~ regex
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The regex syntax is the same as ruby ones.
#
# Ex:
# path ~ .pp$
# will match every resource ending in .pp (manifests files for instance)
#
# path ~ ^/path/to/resource
# is essentially equivalent to path /path/to/resource
#
# environment:: restrict an ACL to a specific set of environments
# method:: restrict an ACL to a specific set of methods
# auth:: restrict an ACL to an authenticated or unauthenticated request
# the default when unspecified is to restrict the ACL to authenticated
requests
# (ie exactly as if auth yes was present).
#
### Authenticated ACL - those applies only when the client
### has a valid certificate and is thus authenticated
# allow nodes to retrieve their own catalog (ie their configuration)
path ~ ^/catalog/([^/]+)$
method find
allow $1
# allow all nodes to access the certificates services
path /certificate_revocation_list/ca
method find
allow *
# allow all nodes to store their reports
path /report
method save
allow *
# Puppetrun settings
path /run
allow mypuppet server fqdn
# inconditionnally allow access to all files services
# which means in practice that fileserver.conf will
# still be used
path /file
allow *
### Unauthenticated ACL, for clients for which the current master doesn't
### have a valid certificate
# allow access to the master CA
path /certificate/ca
auth no
method find
allow *
path /certificate/
auth no
method find
allow *
path /certificate_request
auth no
method find, save
allow *
# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any
It seems as though the puppet is running:
4074 ?Ss 0:00 /usr/bin/ruby /usr/sbin/puppetd
--server=mypuppetserver.fqdn --logdest=/var/log/puppet/puppet.log
But I cant even telnet to port 8139 on the localhost to test that the
port is open.
Can any one please help?
Any suggestions welcome, I have copied the /etc/puppet/*.conf files from
another working server.
Please Help!
--
Gabriel Filion
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Open Source to Enterprise migration?
Hi, Can any users of Puppet tell me about experiences in upgrading a Puppet Open Source environment to Enterprise? We're evaluating what our options are in getting started with our new infrastructure deployment and we'd love a sense of how painful will it be if we start with OS and later decide to spring for commercial. Obviously experiences with more recent versions are good, but I'm all ears. Things like You know, the PE upgrade tool basically just works or Turned out to be 2 days of downtime with a lot of tears and editing config files are things I want to hear, either way. :D Cheers, --Shawn -- 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/-/rjGuyNHLSNEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 3 and ENC deploy ... nothing
Hi Thomas, On Wed, Oct 10, 2012 at 2:48 AM, Thomas Bendler thomas.bend...@gmail.com wrote: Hi @all, I have a problem with my Puppet setup after upgrading to Puppet 3 (OS: SL6.3). I use a puppetmaster with ENC (foreman) to provide classes to my clients. On the master, everything looks good as far as I can tell: $ cat /etc/puppet/puppet.conf ### /etc/puppet/puppet.conf # # Puppet configuration file # [main] # Non-default locations logdir = /var/log/puppet rundir = /var/run/puppet ssldir = /var/lib/puppet/ssl # Report to master puppet server report = true report_server = puppet.int.domain.local reports = log,foreman # Fact synchronisation pluginsync = true [agent] # Non-default locations classfile = /var/lib/puppet/classes.txt localconfig = /var/lib/puppet/localconfig # Interval and master runinterval = 3600 server = puppet.int.domain.local # Report actions report = true graph = true [master] # Settings for local database used by puppetmaster storeconfigs = true dbadapter = mysql dbuser = puppet dbpassword = dbserver = localhost dbsocket = /var/lib/mysql/mysql.sock # Syslog settings syslogfacility = user # The server through which to send email reports. smtpserver = mail.int.domain.local # Settings for reporting rrdgraph = true # Fix SSL settings ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY # Manage Puppet nodes configuration with Foreman external_nodes = /etc/puppet/node.rb node_terminus = exec $ /etc/puppet/node.rb wiki.int.domain.local --- parameters: root_pw: XX hostgroup: web mac: XX:XX:XX:XX:XX:XX foreman_env: production owner_email: XX comment: Mediawiki Server ip: XXX.XXX.XXX.XX owner_name: Thomas Bendler puppetmaster: domainname: int.domain.local (Unknown) classes: backup::bacula::client: mail::ssmtp: custom: backup::bacula: security: virtual: management: common: monitor: environment: production $ So far, so good. When I exceute the puppet agent on the client side it also looks good: $ puppet agent --test Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Caching catalog for wiki.int.domain.local Info: Applying configuration version '1349862242' Finished catalog run in 0.16 seconds $ But when I check the classes that are applied on this box I see only: $ cat /var/lib/puppet/classes.txt settings $ So it look like that not even one class is deployed on this box. This also applies to all other systems and when I change things in my current classes there is also nothing deployed to the clients. Any hints? Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. There is an issue with ENCs when using storeconfigs. See http://projects.puppetlabs.com/issues/16698 -- Josh Cooper Developer, Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Looking for a way to balance the contents of services (like DNS, LDAP, NIS)
I'm looking for a way to balance out services when insuring the content of configuration files. Example is how to do this with /etc/yp.conf: ## domain example.com server 192.168.1.2 domain example.com server 192.168.1.3 domain example.com server 192.168.1.4 ## I'd like to *change the order of the entries *in a random or rotating fashion so that multiple machines would get a *different *order so that we can scale the services without having to invest in a load balancer. Obviously, we wouldn't want the contents to continually change on every machine, so the tests would need to be appropriate. Any ideas? Thanks. -- 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/-/4GzGrjJgRtQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Scalability and performance
It's a very good question and, yes, as far as I know, it is single threaded. However, testing demonstrates a direct correlation between service and exec statements and examining the code indicates that they use the same routines to call out to the shell. Also, I found that the translation of a brain dead simple exec could, in most cases, change it from a =1s runtime to a =0.01s runtime. Why this happens.I'll let the PL guys answerbecause I stopped going down that rabbit hole when I figured out how. The bad news is that services are just slow on the base OS so no help there if you're managing a lot of them. Trevor On Wed, Oct 10, 2012 at 10:09 AM, jcbollinger john.bollin...@stjude.org wrote: On Wednesday, October 10, 2012 6:48:20 AM UTC-5, Trevor Vaughan wrote: Also, be aware that (unless this changed in 3.0), Exec statements and Service statements in Puppet stack into some sort of queue. Moving all Execs to simple native types will increase your performance dramatically and there are good examples of how to do this in the Puppet Labs stdlib module. I posted about this before but I'm not sure if there was a resolution. As far as I know, the Puppet agent is single-threaded and serializes application of all resources of all types. I understood that to be an invariant of the execution model (i.e. intentional). Is that not / no longer true? John -- 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/-/KbSPhSZtFFkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Extra options for the diff program ?
How do I send in extra options to the diff program that runs when puppet shows the diff between files. I'm looking to get the sdiff kind of output. Can't seem to remember the option. Any help -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
I haven't seen this specific issue yet. How did you upgrade from 2.6 to 3.0.0? A common problem when upgrading from source or with rubygems is having multiple copies of puppet installed. This can cause issues loading code from both versions of Puppet into the same process. -Jeff On Wed, Oct 10, 2012 at 5:25 AM, David Campos noymn.the.archan...@gmail.com wrote: Nobody has found this issue? On Monday, October 8, 2012 5:08:33 PM UTC+2, David Campos wrote: Hi all, I'm trying to migrate our configuration from puppet 2.6.7 to 3.0.0 but I am having a strange issue whilst applying the catalog. Error: Could not retrieve catalog from remote server: Could not intern from yaml: allocator undefined for Proc /usr/lib/ruby/1.8/yaml.rb:133:in `transfer' /usr/lib/ruby/1.8/yaml.rb:133:in `node_import' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/1.8/yaml.rb:133:in `load' /usr/lib/ruby/site_ruby/1.8/puppet/network/formats.rb:7:in `intern' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:12:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:12:in `protect' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:26:in `intern' /usr/lib/ruby/site_ruby/1.8/puppet/network/format_handler.rb:108:in `convert_from' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:61:in `deserialize' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:121:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:244:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:348:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:347:in `thinmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:243:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:67:in `retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:107:in `prepare_and_retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:159:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:119:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:42:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:84:in `run_in_fork' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:41:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:175:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:338:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:311:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:76:in `execute' /usr/bin/puppet:10 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Debug: report supports formats: b64_zlib_yaml raw yaml; using yaml I only find references to an old 2010 bug but nothing helps me to solve this an apply the catalog. The catalog works on 2.x nodes by the way. Puppet master: 3.0.0 Puppet agent: either 2.6.7 or 3.0.0 -- 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/-/JFVXsYEsx1EJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Extra options for the diff program ?
On Wed, Oct 10, 2012 at 9:35 AM, kish realmai...@gmail.com wrote: How do I send in extra options to the diff program that runs when puppet shows the diff between files. I'm looking to get the sdiff kind of output. Can't seem to remember the option. I think you're looking for these options, settable in puppet.conf: # Which arguments to pass to the diff command when printing differences between # files. The command to use can be chosen with the `diff` setting. # The default value is '-u'. # diff_args = -u # Which diff command to use when printing differences between files. This setting # has no default value on Windows, as standard `diff` is not available, but Puppet can use many # third-party diff tools. # The default value is 'diff'. # diff = diff # Whether to log and report a contextual diff when files are being replaced. This causes # partial file contents to pass through Puppet's normal logging and reporting system, so this setting # should be used with caution if you are sending Puppet's reports to an insecure destination. # This feature currently requires the `diff/lcs` Ruby library. # show_diff = false -Jeff -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Extra options for the diff program ?
On Wed, Oct 10, 2012 at 10:13 PM, Jeff McCune j...@puppetlabs.com wrote: On Wed, Oct 10, 2012 at 9:35 AM, kish realmai...@gmail.com wrote: How do I send in extra options to the diff program that runs when puppet shows the diff between files. I'm looking to get the sdiff kind of output. Can't seem to remember the option. I think you're looking for these options, settable in puppet.conf: # Which arguments to pass to the diff command when printing differences between # files. The command to use can be chosen with the `diff` setting. # The default value is '-u'. # diff_args = -u Ah, thanks. Just found it by running genconfig. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] The Future of Puppet Dashboard
(This mail has been sent to puppet-users, but bcc’d to puppet-dev and puppet-announce to try and keep the conversation in one place.) Summary: * We are stopping investment in Dashboard * Most Dashboard functionality will be replaced by two new open source services * Some Dashboard functionality will be replaced by a proprietary application * The Dashboard will continue to be open source and we're happy to help people take over maintenance * If we don't get a new maintainer, we will announce a date to EOL Dashboard Details: If you’ve been following the development of Puppet Dashboard over the last year or so, you’ve almost certainly noticed that it hasn’t been getting much love from Puppet Labs. We’ve been thinking about this for a while, and we’ve decided that we’re not going to invest more in the Dashboard. It will get security patches and some minor improvements over the next few months, but we’re treating it as an evolutionary dead end. We were planning to have some code ready for the replacement services before making this announcement, but after questions at PuppetConf and after the recent Dashboard update, we’ve realized that being transparent is the right approach. We’re generally moving the Puppet platform in a direction that is more aligned with service-oriented-architecture, with standalone services for specific functionality that own their own data. Monolithic apps like the Dashboard that store a variety of data types don’t fit well into this world. You’ve seen the first moves of this with PuppetDB, where we have a standalone, open source service with great APIs that is dedicated to catalog and fact storage. The ENC functionality in the Dashboard will be replaced by an open source, standalone service. The report storage and basic report viewing functionality from Dashboard will become part of PuppetDB, and will be open source, just as the rest of PuppetDB is. Work has recently started on both of these projects. We will be working on data migration scripts from Dashboard to these new services. We will also be working on a new graphical application that provides an interface to these services, but one more focused on workflows and advanced use cases, and this application will be proprietary. This is the model Puppet Labs is looking to follow from now on. Open source services, with great APIs and simple GUIs just like PuppetDB, and proprietary graphical applications that are more opinionated in terms of workflows. We believe this is a simple line that brings a lot of clarity to the difference between our open source and proprietary applications. We’re still in the business of making Puppet a great open source platform, and that’s not going to change. We will not be creating any secret APIs that are just for use by Puppet Labs. We will be building our proprietary apps on exactly the same APIs as everyone else has available to them. We believe this keeps us honest in terms of keeping the open source platform strong and functional, as well as Puppet Labs being fair and equitable to the rest of the ecosystem compared to the applications we’re building a sustainable company around. We are not taking the Dashboard code base closed source. Even though it’s never really attracted a development community around it in the same way that Puppet and MCollective have, if there are people who are committed to its existence, we’re more than happy to help people take on the maintenance role. We do think that it ultimately will need to be completely rewritten to take advantage of the new ENC and PuppetDB report storage, and it needs a general update to a newer version of Rails, but just as with *any* other open source application that builds upon our platform, we will help anyone who wants to take this on. We don’t have firm dates for when the replacement services will be ready, but we expect their first releases to be out by the end of the year. Once both of these are ready, and we have migration scripts for your data, we’ll announce a complete end of life date for Dashboard unless we have replacement maintainers. Again, if you love Dashboard enough to want to maintain it, this is your chance. I encourage and expect public discussion about this topic, but if you wish to convey your thoughts privately, you can always contact myself or Luke at: Nigel, CTO email/jabber: ni...@puppetlabs.com IRC : nigelk Luke, CEO email: l...@puppetlabs.com phone: +1-615-594-8199. IRC: lak cheers, Nigel Kersten -- Nigel Kersten | http://puppetlabs.com | @nigelkersten Schedule Meetings at: http://tungle.me/nigelkersten -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] expiry attribut of users applied every time
On Wed, Oct 10, 2012 at 1:39 AM, digrouz nicolas.digrego...@gmail.com wrote: Hello, I have class users with manage some user accounts. for some of them i have set the expiry attribut in the past '2012-01-01' to disable the account. The problem is that puppet set this expiration date at every run: ... /Stage[main]/Users/User[x]/expiry: defined 'expiry' as '2012-01-01' ... What operating system is this on? I'd like to try and reproduce the issue. A common issue is that the input string doesn't match the string Puppet is getting back from the system so Puppet always thinks there is a mis-match. In these cases, it might help to use the `puppet resource user foo` command to see what value for expiry Puppet is receiving from the system. -Jeff -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Please review this node check script
Hi,
The attached script is made for those who have one node per file and want
to catch if something have been made global by being outside on the node
block.
Example:
node xxx { ... }
package{...}
if ... { ... }
which should have been
node xxx { ...
package{...}
if ... { ... }
}
Adjust the path in brackets.sh to your needs and in puppet.conf add
prerun_command = /path/to/brackets.sh
The script is READ ONLY, and doesn't change any of your files.
Please test it on your node pp files, and report any bugs =)
Hugs,
Sandra
--
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/-/iQZoA0somJ0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
#!/usr/bin/perl
use strict;
#use warnings;
#use Data::Dumper;
my $b;
my $ok;
my $node;
open (FILE, '', $ARGV[0]) || die Unable to open $ARGV[0]\n;
while (defined (my $line = FILE)) {
next if ($line =~ /^#/); # allow comments before the node block
if ($line =~ /^node/) {
$node = 1;
}
unless ($node) {
print ERROR: $ARGV[0] is not a valid node file. No node block found.\n;
exit 1;
}
# remove everything betweenand ' '
# these can contain # which would ruin the comment removal
$line =~ s/[^]*[^]*//g;
$line =~ s/'[^']*[^']*'//g;
my @chars = split(//, $line);
while ($line =~ /(.)/g) { # . is never a newline here
if($1 eq #) {last;} # found a comment. skip rest of the line
elsif ($1 eq {) {$b .= {}
elsif ($1 eq }) {$b .= }}
}
# a node file must end with a } and optional spaces and newlines afterwards
if ($line =~ /}\s*$/) {
$ok = 1;
} else {
undef $ok unless ($line =~ /^\s*$/);
}
}
close FILE;
# remove first { and last } which in a valid case should belong to node xxx {}
$b = substr($b,1);
$b = substr($b,0,length($b)-1);
while (length($b) 2 || $b eq {}) {
$b = join , (split (/{}/, $b));
}
if ($b eq $ok) {
exit 0;
} elsif ($b eq !$ok) {
print ERROR: $ARGV[0] have atleast one line after the node {} block.\n;
exit 1;
} else {
print ERROR: $ARGV[0] have a {} block after the node {} block. Not allowed.\n;
exit 1;
}
#!/bin/bash
for f in /etc/puppet/nodes/*.pp; do
/etc/puppet/nodes/brackets.pl $f
done
Re: [Puppet Users] Possible to disable global definition outside of nodes?
Afaik, there is no way to make puppet tell you about this. Puppet is a powerful tool and you got what you asked for :-) I have now written a script that will check for this, and posted it in Please review this node check script =) What you can do is to write Rspec tests for your catalogs and use that as a regression test. Sounds very interesting! Will have to look at Rspec. -- 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/-/FfM_2Sb1DwkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
2012/10/10 Jeff McCune j...@puppetlabs.com I haven't seen this specific issue yet. [...] I saw this issue after an upgrade to 3.0.0 when I used manifests with a package/service definition inside. Unfortunately I didn't had the time to investigate this issue, so no solution from my side ... currently. But maybe some logic around these types has changed. Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: activerecord and puppet-3.0.0
On Tue, Oct 9, 2012 at 9:59 AM, Joe Hillenbrand joehil...@gmail.com wrote: Same story here. Started with puppet 2.7 on Ubuntu 10.04, did apt-get upgrade, then it broke. I have since switched from storedconfig to PuppetDB, which I highly recommend to anyone else having this issue. On Tue, Oct 9, 2012 at 9:54 AM, Jonathan Gazeley jonathan.gaze...@bristol.ac.uk wrote: My version of puppet 2.7 was installed on CentOS 6 from the puppetlabs RPM repo with yum install puppet. When puppet 3 was released, I did a yum update to get the latest. The issue does not occur with a blank CentOS box starting out with puppet 3. Want me to add this information to the tracked issue? Don't want to add unwanted noise to the issue unnecessarily :) Cheers, Jonathan On 09/10/12 16:53, Josh Cooper wrote: Jonathan and Luca, How did you install puppet (from source, gem, apt-get, ...)? In the cases that fail, is it always that you installed 2.7.x and upgraded from there? If so, how did you update? We are tracking this issue at http://projects.puppetlabs.com/issues/16770 Josh On Tue, Oct 9, 2012 at 7:30 AM, Luca Gioppo lucagio...@gmail.com wrote: Same problem for me: here is the trace: Error: Cached catalog for backup.cortile.cloudlabcsi.local failed: Could not autoload puppet/indirector/catalog/active_record: uninitialized constant ActiveRecord /usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:75:in `load_file' /usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:208:in `load' /usr/lib/ruby/site_ruby/1.8/puppet/util/instance_loader.rb:68:in `loaded_instance' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/terminus.rb:108:in `terminus_class' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:313:in `make_terminus' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:126:in `terminus' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/store_configs.rb:6:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:316:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:316:in `make_terminus' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:126:in `terminus' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:47:in `cache' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:217:in `find_in_cache' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:186:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:108:in `do_find' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `process' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:33:in `listen' /usr/lib/ruby/1.8/webrick/server.rb:173:in `call' /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib/ruby/1.8/webrick/server.rb:92:in `each' /usr/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib/ruby/1.8/webrick/server.rb:82:in `start' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:30:in `listen' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `initialize' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `new' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `listen' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:26:in `listen' /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:92:in `listen' /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:104:in `start' /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:136:in `start' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:199:in `main' /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:148:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:438:in `plugin_hook' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:500:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:346:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:76:in `execute' /usr/bin/puppet:10 and gem list *** LOCAL GEMS *** json (1.5.1) rake (0.8.7) stomp (1.2.2) Il giorno mercoledě 3 ottobre 2012 11:26:42 UTC+2, Jonathan Gazeley ha scritto: Yesterday my puppetmaster and nodes got upgraded to puppet-3.0.0. Since then, all puppet runs have been failing with this error: Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Re: [Puppet Users] expiry attribut of users applied every time
I'm experencing this issue on both Red Hat 5 and 6. I'll post the output of the puppet resource user foo tomorrow when i'll be at work. it seems that this is an active bug: http://projects.puppetlabs.com/issues/11675#change-73099 -- 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/-/bNO__HRT_ZgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet client not listening on port 8139
On Oct 9, 2012, at 11:35 PM, Pondy wrote: Please help, I have built a new server and installed puppet (2.6.17) running on RHEL 6.3. It seems that it is not listening on port 8139. ... It seems as though the puppet is running: 4074 ?Ss 0:00 /usr/bin/ruby /usr/sbin/puppetd --server=mypuppetserver.fqdn --logdest=/var/log/puppet/puppet.log That's the puppet client. You want to start the puppetmaster with service puppetmaster start to get the server. As per the other replier, default port is 8140 unless you've changed it in the config. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 3 and ENC deploy ... nothing
Hi Josh, 2012/10/10 Josh Cooper j...@puppetlabs.com [...] There is an issue with ENCs when using storeconfigs. See http://projects.puppetlabs.com/issues/16698 [...] thanks for the hint, after disabling storeconfig, ENC seem to work again but now I hit the issue that David already reported: https://groups.google.com/forum/#!msg/puppet-users/2qQRYpCGP6o/gQbeNRi6ljsJ I will spend some time on this issue on Friday. Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] PuppetConf Videos Are Available Now
I wanted to let everyone know that the videos from PuppetConf are available at http://puppetlabs.com/community/videos/puppetconf/ Here are a few of my personal favorites: CERN: http://youtu.be/-Ykb2j2ojYU Discovering and creating great Puppet Modules: http://youtu.be/aWqktlD62ks (talk actually starts at 4:45 min into video) State of the Community http://youtu.be/0_u_5RkVymE (I'm biased, since my job is Community) :) Logging: Logstash and other things: http://youtu.be/RuUFnog29M4 (should also win the best logo / mascot award) Note: I also cross-posted this (Bcc) to puppet-announce and puppet-dev, but if you have any questions or comments, let's keep those here in puppet-users. Thanks, Dawn -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] The Future of Puppet Dashboard
I always saw Dashboard as the beginning point, not a valuable item today. The ENC functionality was certainly too limited to use. I look forward to the PuppetDB replacement for report viewing. On Oct 10, 2012, at 10:02 AM, Nigel Kersten wrote: (This mail has been sent to puppet-users, but bcc’d to puppet-dev and puppet-announce to try and keep the conversation in one place.) Summary: * We are stopping investment in Dashboard * Most Dashboard functionality will be replaced by two new open source services * Some Dashboard functionality will be replaced by a proprietary application * The Dashboard will continue to be open source and we're happy to help people take over maintenance * If we don't get a new maintainer, we will announce a date to EOL Dashboard Details: If you’ve been following the development of Puppet Dashboard over the last year or so, you’ve almost certainly noticed that it hasn’t been getting much love from Puppet Labs. We’ve been thinking about this for a while, and we’ve decided that we’re not going to invest more in the Dashboard. It will get security patches and some minor improvements over the next few months, but we’re treating it as an evolutionary dead end. We were planning to have some code ready for the replacement services before making this announcement, but after questions at PuppetConf and after the recent Dashboard update, we’ve realized that being transparent is the right approach. We’re generally moving the Puppet platform in a direction that is more aligned with service-oriented-architecture, with standalone services for specific functionality that own their own data. Monolithic apps like the Dashboard that store a variety of data types don’t fit well into this world. You’ve seen the first moves of this with PuppetDB, where we have a standalone, open source service with great APIs that is dedicated to catalog and fact storage. The ENC functionality in the Dashboard will be replaced by an open source, standalone service. The report storage and basic report viewing functionality from Dashboard will become part of PuppetDB, and will be open source, just as the rest of PuppetDB is. Work has recently started on both of these projects. We will be working on data migration scripts from Dashboard to these new services. We will also be working on a new graphical application that provides an interface to these services, but one more focused on workflows and advanced use cases, and this application will be proprietary. This is the model Puppet Labs is looking to follow from now on. Open source services, with great APIs and simple GUIs just like PuppetDB, and proprietary graphical applications that are more opinionated in terms of workflows. We believe this is a simple line that brings a lot of clarity to the difference between our open source and proprietary applications. We’re still in the business of making Puppet a great open source platform, and that’s not going to change. We will not be creating any secret APIs that are just for use by Puppet Labs. We will be building our proprietary apps on exactly the same APIs as everyone else has available to them. We believe this keeps us honest in terms of keeping the open source platform strong and functional, as well as Puppet Labs being fair and equitable to the rest of the ecosystem compared to the applications we’re building a sustainable company around. We are not taking the Dashboard code base closed source. Even though it’s never really attracted a development community around it in the same way that Puppet and MCollective have, if there are people who are committed to its existence, we’re more than happy to help people take on the maintenance role. We do think that it ultimately will need to be completely rewritten to take advantage of the new ENC and PuppetDB report storage, and it needs a general update to a newer version of Rails, but just as with *any* other open source application that builds upon our platform, we will help anyone who wants to take this on. We don’t have firm dates for when the replacement services will be ready, but we expect their first releases to be out by the end of the year. Once both of these are ready, and we have migration scripts for your data, we’ll announce a complete end of life date for Dashboard unless we have replacement maintainers. Again, if you love Dashboard enough to want to maintain it, this is your chance. I encourage and expect public discussion about this topic, but if you wish to convey your thoughts privately, you can always contact myself or Luke at: Nigel, CTO email/jabber: ni...@puppetlabs.com IRC : nigelk Luke, CEO email: l...@puppetlabs.com phone: +1-615-594-8199. IRC: lak cheers, Nigel Kersten -- Nigel Kersten | http://puppetlabs.com | @nigelkersten Schedule Meetings at:
Re: [Puppet Users] Puppet caught TERM; calling stop - error
Hi Garrett, I ended up using mod_passenger with Apache for *:8140 to address the database connection and load issue. I no longer see that particular error. However, there is still that pesky Caught TERM; calling stop error, which seems to be related to the recent kernel upgrade. Any thoughts? On Wednesday, October 10, 2012 6:06:48 AM UTC-7, Garrett Honeycutt wrote: On 10/4/12 8:32 AM, Will S. G. wrote: Wed Oct 03 23:26:55 -0700 2012 Puppet (err): Could not retrieve catalog from remote server: Error 400 on SERVER: could not obtain a database connection within 5 seconds. The max pool size is currently 5; consider increasing it. The puppet master is attempting to connect to a database to get information needed to compile the catalog and is timing out. Try setting playing around with setting dbconnections = some_positive_integer in your puppet.conf. If you are still having issues, post your puppet.conf in your reply. Regards, -g -- Garrett Honeycutt 206.414.8658 http://puppetlabs.com -- 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/-/NFozGi2p1z0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
On Wed, Oct 10, 2012 at 10:42 AM, Thomas Bendler
thomas.bend...@gmail.com wrote:
2012/10/10 Jeff McCune j...@puppetlabs.com
I haven't seen this specific issue yet.
[...]
I saw this issue after an upgrade to 3.0.0 when I used manifests with a
package/service definition inside. Unfortunately I didn't had the time to
investigate this issue, so no solution from my side ... currently. But maybe
some logic around these types has changed.
Regards, Thomas
--
Linux ... enjoy the ride!
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Can add the following to lib/puppet/indirector/rest.rb:61
Puppet.debug(content_type)
Puppet.debug(body.inspect)
Then run puppet agent --test --debug, and you should see output like:
Debug: text/pson
Debug:
{\data\:{\classes\:[\settings\],\environment\:\production\,\name\:\sirrus.puppetlabs.lan\,\edges\:[{\target\:\Class[Settings]\,\source\:\Stage[main]\},{\target\:\Class[main]\,\source\:\Stage[main]\}],\tags\:[\settings\],\version\:1349894170,\resources\:[{\exported\:false,\title\:\Settings\,\tags\:[\class\,\settings\],\type\:\Class\},{\exported\:false,\title\:\main\,\parameters\:{\name\:\main\},\tags\:[\class\],\type\:\Class\},{\exported\:false,\title\:\main\,\parameters\:{\name\:\main\},\tags\:[\stage\],\type\:\Stage\}]},\metadata\:{\api_version\:1},\document_type\:\Catalog\}
I think puppet agent is expecting yaml, and is either receiving json
or otherwise can't parse the yaml it's receiving. We made performance
improvements in Puppet 3 relating to yaml parsing, so perhaps that is
the issue.
Can you post your output and puppet.conf as gists?
Josh
--
Josh Cooper
Developer, Puppet Labs
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet caught TERM; calling stop - error
On Oct 10, 2012, at 11:37 AM, Will S. G. wrote: However, there is still that pesky Caught TERM; calling stop error, which seems to be related to the recent kernel upgrade. Any thoughts? Look for resources which would notify = Service['puppet']. Run puppet with --debug and you'll see what resource triggered it. (or whatever service is restarting, if its not puppet) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] updating puppetlabs-firewall forge module to line up with whats in the github repo?
Hi there! Is there a timeline on when the puppetlabs-firewall forge module will be updated (not necessarily to 1.0) ? the github version has the firewallchain type (as well as other nifty) that the forge version seems to be lacking, but it's not clear from my perusing that the two are different. They both appear to be the same version superficially*…. The github version points to the forge version for documentation, so I sillily grabbed the forge version, then noticed that it was missing stuff I was expecting to be there. My expectation could be the problem here, but I didn't think it would hurt to ask. W *to be fair, I didn't look that hard. I could just be blind, and missed something sooper obvious. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Set a windows environment variable from manifest
I want to setup java jdk and maven and need to set some environment variables that stick around after reboot. I also need to add to values to the path variable so I can call via the command line. What's the best way to set permanent environment variables for windows via the manifest? Is there a custom type for this? Corey -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Set a windows environment variable from manifest
Hi Corey, On Wed, Oct 10, 2012 at 12:34 PM, Corey Osman co...@logicminds.biz wrote: I want to setup java jdk and maven and need to set some environment variables that stick around after reboot. I also need to add to values to the path variable so I can call via the command line. What's the best way to set permanent environment variables for windows via the manifest? Is there a custom type for this? Corey -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. I think Jeff Sussna has something. I've also started writing a type/provider for this, but have been too busy with other things. https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/68ebrAEUzgQ Josh -- Josh Cooper Developer, Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Looking for a way to balance the contents of services (like DNS, LDAP, NIS)
On Wednesday, October 10, 2012 11:10:32 AM UTC-5, trevman wrote: I'm looking for a way to balance out services when insuring the content of configuration files. Example is how to do this with /etc/yp.conf: ## domain example.com server 192.168.1.2 domain example.com server 192.168.1.3 domain example.com server 192.168.1.4 ## I'd like to *change the order of the entries *in a random or rotating fashion so that multiple machines would get a *different *order so that we can scale the services without having to invest in a load balancer. Obviously, we wouldn't want the contents to continually change on every machine, so the tests would need to be appropriate. Any ideas? There are lots of ways you could do this, but the the ready-built fqdn_rotate() function in Puppetlabs's add-in stdlib module (https://github.com/puppetlabs/puppetlabs-stdlib) would probably serve as a good foundation. Put the NIS server IPs in an array, shuffle it with fqdn_rand(), and read the results out into your yp.conf template. Each node will have a consistent order as long as its FQDN does not change. John -- 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/-/Q_WmB-vH70UJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
Hi Josh, 2012/10/10 Josh Cooper j...@puppetlabs.com [...] I think puppet agent is expecting yaml, and is either receiving json or otherwise can't parse the yaml it's receiving. We made performance improvements in Puppet 3 relating to yaml parsing, so perhaps that is the issue. you are the man! I had several performance and other tweaks in my standard puppet.conf. One of them was preferred_serialization_format = b64_zlib_yaml or preferred_serialization_format = yaml which seem to cause the error. I've removed most of the tweaks and started with a more standard like puppet.conf and which seem to work as expected. Now I can focus on bugfix all the remaining issues occuring within the upgrade. Thanks a lot! Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Service Resources and Selinux
On 10/10/12 16:09, jcbollinger wrote: On Tuesday, October 9, 2012 10:02:26 AM UTC-5, Tom B. wrote: Hi list, I've got an issue at the moment, which isn't really a big problem, but an untidy annoyance really, and I'd just like to understand what the best practice might be when dealing with the issue. As a really quick summary, the issue is that Puppet is starting up the mysqld service for the first time as unconfined_u, and then when MySQL goes and creates a load of its initial files also as unconfined_u, Puppet goes and resets them all to system_u which is what they should be when checking matchpathcon: Unless you configure it differently, Puppet uses the system's normal service management commands to control services. It is the responsibility of that tool (e.g. /sbin/service) to start the service in the correct way, including SELinux context, based on whatever criteria it uses to choose such things. Among other things, this means that you will get the same result if Puppet starts the service as you would if the system initialization program starts it at boot. by using runcon or run_init you are starting the service in the same context that it will be started with at system boot by init. /sbin/service is not the correct way to start an selinux confined service technically, although practically it makes little difference because user contexts are not heavily used in the targeted selinux policy, unless users themselves are confined, which they usually aren't. Perhaps there should be an selinux aware provider for services! To the extent that your services' behaviors depend on system resources such as configuration files or certain directories, it is your responsibility to describe those dependencies to Puppet (supposing you managing them via Puppet). If you do, then Puppet will manage those resources in the a sequence consistent with those dependencies. The question, therefore, is not so much about how Puppet starts the service, but rather about how to configure the service's SELinux context. The thing is, because the service is started as unconfined_u, any databases/tables that are created are going to inherit that, and puppet is going to be resetting them. Puppet can be instructed to restart the service if resources on which it depends are modified (by Puppet). I don't want the service restarted, mysql doesn't care about the user context itself, but puppet cares when it sees files being labelled as unconfined_u instead of system_u (because matchpathcon tells it that it's incorrect, rightly so) For some more detail, I've written something which will set the mysqld_db_t selinux file_context on my data directories which are in /home, and I have a notify which will go and check and re-set the selinux file_context if there are any changes in these directories. They're set to recurse, so to stop Puppet changing things from unconfined_u to system_u on a regular basis, and sending refresh notices to my Exec resources, I've set selinux_ignore_defaults to true in my File resources. This strikes me as a bit of a dirty way of doing things, and I was wondering if anyone had any better ideas of how to manage this. It strikes me as a backwards way of doing things. You are trying to clean up the effects of a service misconfiguration instead of configuring the service correctly in the first place. Please find below a sample of the relevant code - because I'm sure my verbose description is probably leaving some people scratching their heads! :) I was going to make the file_context stuff much more re-usable, but want to get my head around the best practices first - as I'm not that experiened with all of this stuff to be honest! I'm afraid your code still leaves me scratching my head. I get the feeling that you're doing a lot of work you don't need to be doing, but I'm not conversant enough with MySQL SELinux configuration to know what you should be doing instead. It's a learning exercise :) John -- 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/-/ojA1Ycp4YkkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. Thanks for getting back to me! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Help- Parsing data from a yaml file using puppet 3.0 and hiera
Hello Everybody, Can anybody please provide an example about how to read an array using hiera in puppet 3.0. Right now the agents are giving the following error when connecting to the master Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item users in any Hiera data file and no default supplied . Following is the structure of hiera.yaml --- :backend: - yaml :hierarchy: - global :puppet: :datasource: data :yaml: # datadir is empty here, so hiera uses its defaults # When specifying a datadir, make sure the path of the datadir exists :datadir: /etc/puppet/hiera/data Followin is the structure of global.yaml file:- --- users: - 'seventeen' - 'eighteen' Following is the code where am trying to use it in site.pp $declared_users=hiera_array(users) I am not getting, if I am missing something obvious here or is there any problem with hiera inside puppet. Thanks, Nishant -- 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/-/DdS7dqv_trkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Exec resource and environment parameter
I'm trying to use the environment parameter on Exec but it is not working.
Any idea what's wrong ?
exec { 'test':
path=
'/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
environment = [HOME=test, HOME2=test2],
command= echo $HOME /tmp/key,
user= 'root',
group = 'root',
}
I'm using Puppet 3.0
Thanks,
Felipe
--
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/-/2F-pxT-TA2wJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Announce: Puppet Enterprise 2.6.1 Available
Dear Puppet Enterprise Users, Puppet Enterprise 2.6.1 is now available. This is a maintenance release of PE with bug fixes and security updates. All users of Puppet Enterprise 2.5 and later are strongly encouraged to upgrade when possible to Puppet Enterprise 2.6.1. Puppet Enterprise 2.6.1 includes fixes to address CVE-2012-5158, which stems from a bug in how the Puppet Enterprise console handles sessions. For more information, please visit http://puppetlabs.com/security, or visit http://puppetlabs.com/security/cve/cve-2012-5158 As a current Puppet Enterprise user, you can upgrade to this new version as part of your annual subscription. If upgrading, it is recommended to upgrade your master and console servers first. For a detailed list of what's new in 2.6.1 see http://docs.puppetlabs.com/pe/2.6/overview_whats_new.html We want to hear about your experiences with Puppet Enterprise. If you have any questions about installing or upgrading, be sure to get in touch with Puppet Labs Support. Cheers, Matthaus Owens Release Manager, Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Announce: PuppetDB 1.0.1 Available
PuppetDB 1.0.1 is now available for download! This is a bug-fix release of PuppetDB. # Downloads == Available in native package format at: http://yum.puppetlabs.com and http://apt.puppetlabs.com Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb Source (same license as Puppet): http://github.com/puppetlabs/puppetdb/ Available for use with Puppet Enterprise 2.5.1 and later at http://yum-enterprise.puppetlabs.com/ and http://apt-enterprise.puppetlabs.com/ # Documentation (including how to install): http://docs.puppetlabs.com/puppetdb # Issues can be filed at: http://projects.puppetlabs.com/projects/puppetdb/issues # See our development board on Trello: http://links.puppetlabs.com/puppetdb-trello # 1.0.1 Changelog == Many thanks to the following people who contributed patches to this release: Deepak Giridharagopal Nick Lewis Matthaus Litteken Chris Price Fixes: (#16180) Properly handle edges between exported resources This was previously failing when an edge referred to an exported resource which was also collected, because it was incorrectly assuming collected resources would always be marked as NOT exported. However, in the case of a node collecting a resource which it also exports, the resource is still marked exported. In that case, it can be distinguished from a purely exported resource by whether it's virtual. Purely virtual, non-exported resources never appear in the catalog. Virtual, exported resources are not collected, whereas non-virtual, exported resources are. The former will eventually be removed from the catalog before being sent to the agent, and thus aren't eligible for participation in a relationship. We now check whether the resource is virtual rather than exported, for correct behavior. (#16535) Properly find edges that point at an exec by an alias During namevar aliasing, we end up changing the :alias parameter to 'alias' and using that for the duration (to distinguish our aliases form the original aliases). However, in the case of exec, we were bailing out early because execs aren't isomorphic, and not adding 'alias'. Now we will always change :alias to 'alias', and just won't add the namevar alias for execs. (#16407) Handle trailing slashes when creating edges for file resources We were failing to create relationships (edges) to File resources if the relationship was specified with a different number of trailing slashes in the title than the title of the original resource. (#16652) Replace dir with specific files for terminus package Previously, the files section claimed ownership of Puppet's libdir, which confuses rpm when both packages are installed. This commit breaks out all of the files and only owns one directory, which clearly belongs to puppetdb. This will allow rpm to correctly identify files which belong to puppet vs puppetdb-terminus. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Migration from Puppet 2.6.7 to 3.0.0 issues
Hi Thomas, On Wed, Oct 10, 2012 at 1:13 PM, Thomas Bendler thomas.bend...@gmail.com wrote: Hi Josh, 2012/10/10 Josh Cooper j...@puppetlabs.com [...] I think puppet agent is expecting yaml, and is either receiving json or otherwise can't parse the yaml it's receiving. We made performance improvements in Puppet 3 relating to yaml parsing, so perhaps that is the issue. you are the man! I had several performance and other tweaks in my standard puppet.conf. One of them was preferred_serialization_format = b64_zlib_yaml or preferred_serialization_format = yaml which seem to cause the error. I've removed most of the tweaks and started with a more standard like puppet.conf and which seem to work as expected. Now I can focus on bugfix all the remaining issues occuring within the upgrade. Thanks a lot! Regards, Thomas -- Linux ... enjoy the ride! -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. See also http://projects.puppetlabs.com/issues/16922 Josh -- Josh Cooper Developer, Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Open Source to Enterprise migration?
On Wed, Oct 10, 2012 at 9:01 AM, Shawn Knight shawnkni...@gmail.com wrote: Hi, Can any users of Puppet tell me about experiences in upgrading a Puppet Open Source environment to Enterprise? Hi Shawn, We went through this with Puppet 2.6 and PE 2.0. It wasn't particularly painful, though we did have Puppet Labs PS on site to help. For a standalone installation of Puppet I wouldn't consider that necessary, but if you want to add HA, multiple masters, or other complex configs you may want to consider it. It depends on whether you've already done those things in your existing Puppet install. At a basic level we configured our CA's, had our old Puppet Masters configure the clients to use the PE Masters, then had the PE Masters install the PE Agent. It was easier than running the PE Installer everywhere. If your existing Puppet infrastructure is too new you may not be able to go this route since the agents can't be newer than the master. Planning elements: if you're not using the Puppet Dashboard already you'll want to think about whether the MySQL server and PE Console services need to be HA. If you're going to use the PE Console as an ENC then I'd vote yes, since the ENC becomes a single point of failure regardless of how many Masters you have. You'll also want to read up on the Puppet Certificate Authority since you'll be dealing with your existing certificates one way or another. If you're not using MCollective it's one of the nice things about PE since it comes pre-configured and you don't have to learn how to configure ActiveMQ and friends right away. Unfortunately it doesn't run arbitrary programs so in order to extend it to do new things you'll have to read up on a little bit of Ruby. All-in-all the complexity of it mostly depends upon the complexity of your existing environment. As far as downtime goes, you can easily run them side-by-side (managing different clients obviously) so you shouldn't need to worry about having completely unmanaged systems. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet client not listening on port 8139
Hi All, thanks for your input. So, I am talking about the puppet client. The puppet master server and all other clients seem to be working ok. I am also unable to telnet locally to port 8139 or 8140. On Thursday, 11 October 2012 04:30:21 UTC+10, Jo wrote: On Oct 9, 2012, at 11:35 PM, Pondy wrote: Please help, I have built a new server and installed puppet (2.6.17) running on RHEL 6.3. It seems that it is not listening on port 8139. ... It seems as though the puppet is running: 4074 ?Ss 0:00 /usr/bin/ruby /usr/sbin/puppetd --server=mypuppetserver.fqdn --logdest=/var/log/puppet/puppet.log That's the puppet client. You want to start the puppetmaster with service puppetmaster start to get the server. As per the other replier, default port is 8140 unless you've changed it in the config. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- 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/-/skdRN9Ej2uwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet client not listening on port 8139
On 2012-10-10 18:37, Pondy wrote: Hi All, thanks for your input. So, I am talking about the puppet client. ah oops sorry, I'm not used to dealing with this option :\ my bad The puppet master server and all other clients seem to be working ok. I am also unable to telnet locally to port 8139 or 8140. hmm this is weird. in your original post you showed us that there were no iptables rules, and you do have listen = true in your puppet.conf. do you see the port as open and listening with netstat? -- Gabriel Filion signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Puppet client not listening on port 8139
Hi Gabrielle, Yes, I have listen = true and I cannot see that port open with netstat... I am truly confused, theres not much showing in the logs either. Thanks! On Thursday, 11 October 2012 09:46:31 UTC+10, Lelutin wrote: On 2012-10-10 18:37, Pondy wrote: Hi All, thanks for your input. So, I am talking about the puppet client. ah oops sorry, I'm not used to dealing with this option :\ my bad The puppet master server and all other clients seem to be working ok. I am also unable to telnet locally to port 8139 or 8140. hmm this is weird. in your original post you showed us that there were no iptables rules, and you do have listen = true in your puppet.conf. do you see the port as open and listening with netstat? -- Gabriel Filion -- 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/-/idS-uhlhCSMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Scalability and performance
Hi, I've never used CFEngine and don't have input on those benchmarks other than they seem silly. But, fwiw... - scaling Puppet masters seems to be straighforward and well documented (there are chapters in books on it) - Performance in Puppet 3 is much better. Check out this presentation from PuppetConf - http://www.youtube.com/watch?v=8h2PbdFi0OU - The key bottleneck of a Puppet Master is cpu usage when compiling catalogs. How long catalogs take to compile varies widely depending on your usage. I currently manage over 600 Windows nodes on a single, small, ec2 instance (one core) that has no problem keeping up. Most of the nodes run every 4 hours and we use splay settings to randomize the run intervals. We also currently have very small catalogs for these nodes (unlike our Linux server nodes handled by a separate master) that compile extremely fast. - Puppet ships with a rarely mentioned load testing tool. Google this and try it out. See how it will handle your volume. Eventually how big of a server/cluster you need becomes a simple math problem. - Also, really, how important is paying more for a bigger server to you when considering usability/features/community/momentum/etc differences? Regards, Adam On Tuesday, October 9, 2012 6:56:55 PM UTC-5, Robjon wrote: Hi guys, I am pretty new to this space, playing around with a few tools. I am trying to read up on how I would scale Puppet (or other tools) up in my installation, and came across this blog post comparing Puppet and CFEngine: http://www.blogcompiler.com/2012/09/30/scalability-of-cfengine-and-puppet-2/ The numbers presented here are pretty extreme: CFEngine agents running 166 times faster than Puppet agents in a small installation - and the difference is increasing? Also, it seems to be the case that Puppet is more centralized which results in everything slowing down: as the master gets more loaded, all the Puppet agents run slower. Is this correct? Could some of you with more experience please comment on this? Thanks. -- 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/-/JpxZ_vk76tcJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: PuppetConf Videos Are Available Now
A huge thanks to Puppet Labs for these videos. It was so hard to decide which presentations to go to at times. The conference kicked so much ass! Adam On Wednesday, October 10, 2012 1:33:08 PM UTC-5, Dawn Foster wrote: I wanted to let everyone know that the videos from PuppetConf are available at http://puppetlabs.com/community/videos/puppetconf/ Here are a few of my personal favorites: CERN: http://youtu.be/-Ykb2j2ojYU Discovering and creating great Puppet Modules: http://youtu.be/aWqktlD62ks (talk actually starts at 4:45 min into video) State of the Community http://youtu.be/0_u_5RkVymE (I'm biased, since my job is Community) :) Logging: Logstash and other things: http://youtu.be/RuUFnog29M4 (should also win the best logo / mascot award) Note: I also cross-posted this (Bcc) to puppet-announce and puppet-dev, but if you have any questions or comments, let's keep those here in puppet-users. Thanks, Dawn -- 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/-/DcjYkc7v5D8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
