Re: [Puppet Users] puppet with init.d script fails to update
Hi. On 02/09/2011 03:08 AM, Liberty Young wrote: All, In my test bed, i've noticed that the init.d script as present in the git source (puppet-2.6.4/conf/redhat) doesn't seem to work. Puppet fails to periodically update its configuration cached, reporting in var/log/message puppet-agent[7621]: Run of Puppet configuration client already in progress; skipping This is happens every 30 minutes (the default for run-time interval). This also happens when I invoke the script with a start command. The initscript in and of itself is working, as an agent is started. when i send a SIGUSR1 to the running daemon, it also fails with the above. When I start the puppet client by hand, it successfully updates its self. This is weird. Otherwise, my guess would have been that you have an orphaned lock lying around. We've seen this in different situations. Try puppet agent --enable and watch the logs - the agent may now work correctly. Where should I be looking next on how to resolve this issue? Inspect /var/lib/puppet/ and try to find out what's keeping your agent from performing its run. HTH, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet in the DMZ
On Thu, Feb 10, 2011 at 22:25, John Warburton jwarbur...@gmail.com wrote: Does anyone have any experiences with puppet in the DMZ they can share? We looked at how to integrate puppet into a network that needed medical-in-confidence certification back in Australia, which is probably about the same level of security control that most business DMZ deployments realistically need. In the end I elected that the best path was to have our security plan permit inbound connectivity from the DMZ for log traffic (via SSL) and puppet agent to master communication. While it was a risk we could reasonably bound and manage the security requirements, and the folks we worked with for audit preparation were happy that this was an acceptable risk when tightly controlled. [...] I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. How do people get around the common rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? If I couldn't have the DMZ talk to my central master then, yes, I would deploy a second master to the DMZ and use that to manage things. (Depending on how you architect the DMZ you might find it attractive to use as the sole master, or not. We had the capability to DMZ any machine to a VLAN, so there was no reduction in cross-host security for doing this. :) We found that the utility of dynamic updates and facts, plus stored configuration, was worth the risk; overall they made it much easier to control, manage, and secure the systems, and so meet our overall security goals. You might ask, if there are concerns, what security analysis is required to get approval for puppet from the security teams. Typically this turns out to be pretty easy, in my experience. Regards, Daniel Now you tell us that you have a SECRET network, of course, and I sympathise and think of transparent ducting. ;) -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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] Variable doesn't expand properly
the background. However, (per orig post) the result of no quotes: ... require = Package[$packagelist], ... was the following : warning: Not using cache on failed catalog ... and the somewhat obscure: warning: Configuration could not be instantiated: wrong number of arguments (3 for 2) I'll keep working with it, meanwhile I've bypassed using an array just to get it going... Hi, while this won't be of much help, I'd just like to add that those requires are spurious. To create a symlink, all puppet requires is the parent directory (/etc/rc.d/init.d/ is present in any case). So from my perspective, it doesn't seem like puppet needs to process the packages or even the link target file before it creates the link. You can safely drop the require parameter. Concerning the original problem - I would be interested whether Package[$packagelist, mimedefang] works better. Regards, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] facter to display all active networks
On Thu, Feb 10, 2011 at 12:59, Forrie for...@gmail.com wrote: Facter will display the values associated with network_* specific settings. Shouldn't there be a way to display all connected (active) networks in one command? For example: FWIW, I would say the answer is best: not while facter only returns strings. This is rich data, and something that stringifies it will introduce pain that we need to support for a long, long time. Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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: user authorized_keys with wrong perms
4 drwx-- 2 neuroadm neuro 4096 Feb 3 21:02 . 4 drwx-- 3 neuroadm neuro 4096 Feb 3 21:02 .. 4 -rw--- 1 root root 578 Feb 3 21:02 authorized_keys So Puppet is sometimes failing with a permission failure while attempting to synchronize the authorized_keys resource. Supposing that the agent is running as root, there aren't very many things that could cause it to be denied permission to access or change a file. Here's my short list: Ah, not quite - puppet drops it privileges when installing authorized keys and does it as the target user. There is an interesting bug in 0.25.5 that will keep puppet from filebucketing and thus installing keys because of this behaviour, but I digress. It's normal for puppet to be unable to install the key in this situation. The question is, how and why are the permissions broken? You may succeed by having puppet fix the permissions prior to installing keys using a file resource. HTH, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet in the DMZ
Hi, On Feb 11, 2011, at 07:25, John Warburton wrote: Does anyone have any experiences with puppet in the DMZ they can share? At my puppet master training (Hi Hunter), it was mentioned some people compile their catalogs inside, then ship them out to servers in the DMZ to be applied. I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. How do people get around the common rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? Another approach is to use SSH tunnels. Use autossh to initiate SSH connections from your puppetmaster to each client. The SSH tunnels open port 8140 on localhost on the client, allowing puppet on the client to tunnel back to the master. Not the most efficient approach, but easier to implement than a slave master. I have about 50 DMZ clients running this way. The gist of the autossh startup would be something like this monitorport=2 foreach clientname in $DMZclients; do /usr/bin/autossh -M $monitorport -f -R localhost:8140:localhost:8140 -N -n -x $clientname monitorport=`expr $monitorport + 10` done Pointing your clients at localhost:8140 can be done in either puppet.conf or by adding an entry to /etc/hosts. Cheers, -Thorsten -- 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] force the file name of a yumrepo created file
Hi list, Before I raise a feature request, is there a way to force the name of the .repo file a yumrepo is created in? By default if no existing repo exists, the file name that gets created for it is $name.repo. It would be nice if you could specify the file name, for example on CentOS systems you could force the filename of the [base] and [updates] repo to be CentOS-Base.repo. This only becomes a problem if say Puppet was repairing missing Yum repos and recreated [base] as /etc/yum.repos.d/base.repo. Update the RPM centos-release and now you've got two repositories named [base]. Thanks, -Luke -- 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: user authorized_keys with wrong perms
On Feb 11, 2:24 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Ah, not quite - puppet drops it privileges when installing authorized keys and does it as the target user. There is an interesting bug in 0.25.5 that will keep puppet from filebucketing and thus installing keys because of this behaviour, but I digress. Hmm. I obviously wasn't considering that. The question is, how and why are the permissions broken? You may succeed by having puppet fix the permissions prior to installing keys using a file resource. And that's indeed a good question. If Puppet is responsible, then the ownership change must happen at a time when the agent has full privileges. Therefore, either a) the agent is failing to drop privileges and assume the user's identity before managing the keys, or b) the agent is changing file ownership elsewhere (probably through management of a recursive directory resource (/home ?)), or c) something outside Puppet is doing it. I'd guess it's (b), but only the OP can judge the likelihood of (c). I don't think (a) is likely to be the problem. You may succeed by having puppet fix the permissions prior to installing keys using a file resource. I'd really want to verify at least that Puppet is responsible for the breakage in the first place. If something else is doing it then Puppet can fix it as needed, but that won't prevent temporary service outage occurring between Puppet runs. If Puppet *is* doing it, and is doing so because of some other resource (alternative (b), above), then that probably signals a manifest design problem, which at minimum I would want to document. It should indeed be possible to fix it via a file resource. Either a resource for that particular file should work, or the OP's existing ssh_neuroadm could do it if it were made recursive (in that case, its mode property should be set to 600; Puppet will add the execute bit for the directory itself). Any way around, the Ssh_authorized_key resource needs to declare a dependency on the appropriate File resource. Sometimes happens and sometimes not is a pretty good indication that dependencies are under- specified. John -- 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 in the DMZ
You can put a puppet server in the DMZ that you deploy puppet manifest changes to via SSH, then only allow 8140 access to the dmz boxes. I would say shipping catalogs out there is sort of overkill. You can also make this master use a separate CA, etc. I think a few simple measures like this would make it as secure as trying to do some esoteric 'ultra-secure' techniques. On 02/11/2011 01:25 AM, John Warburton wrote: Curse GW Bush and his 'Axis of Evil' - my google searches are contaminated with hits to Korea, and other such fun... Does anyone have any experiences with puppet in the DMZ they can share? At my puppet master training (Hi Hunter), it was mentioned some people compile their catalogs inside, then ship them out to servers in the DMZ to be applied. I understand that fine, but we use facts quite a bit to get state information, so the traditional part of the client server/model where facts are shipped back from the client to the puppet server is missing. How do people get around the common rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? Thanks John -- 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. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode When the going gets weird, the weird turn pro. -- 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] Check package version in order to proceed with installation (err: Could not update: package is already installed)
Hi *,
we have plans to handle the update process of puppet related packages by
our local update server. However, for now we need do deal with the
situation by fetching the respective rpms to the client and install them
by using the rpm provider.
So in order to proceed with the installation I would like to check if
the latest version is already installed before puppet tries to
install/update it, to get rid of the following error log message:
node # puppetd -o --server puppet.domain.tld --waitforcert 60 --test
[...]
err: /Stage[main]/Puppet::Client::Rollout/Package[puppet]/ensure: change
from 2.6.4-27.1 to Header-V3 failed: Could not update: Execution of
'/bin/rpm -U --oldpackage /tmp/puppet-2.6.4-27.1.x86_64.rpm' returned 1:
warning: /tmp/puppet-2.6.4-27.1.x86_64.rpm: Header V3 DSA signature:
NOKEY, key ID 5c43a8d9
package puppet-2.6.4-27.1.x86_64 is already installed
at /etc/puppet/manifests/classes/puppet.pp:42
[...]
This error occurs anytime if the latest version of the package is
already installed. I tried to use the onlyif and unless parameters
but according to the latest type reference under
http://docs.puppetlabs.com/references/latest/type.html; these seem to
be not supported, neither by the resource type file nor by resource
type package.
/etc/puppet/manifests/classes/puppet.pp
class puppet {
class client {
class rollout {
$mypuppetversion = 2.6.4-27.1
$myfacterversion = 1.5.8-6.1
$myrshadowversion = 1.4.1-4.1
file {
/tmp/facter-$myfacterversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/facter-$myfacterversion.x86_64.rpm;
/tmp/puppet-$mypuppetversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/puppet-$mypuppetversion.x86_64.rpm;
/tmp/ruby-shadow-$myrshadowversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/ruby-shadow-$myrshadowversion.x86_64.rpm;
}
package {
facter:
ensure = latest,
name = facter,
provider = rpm,
source = /tmp/facter-$myfacterversion.x86_64.rpm,
require = file[/tmp/facter-$myfacterversion.x86_64.rpm];
puppet:
ensure = latest,
name = puppet,
provider = rpm,
source = /tmp/puppet-$mypuppetversion.x86_64.rpm,
require = file[/tmp/puppet-$mypuppetversion.x86_64.rpm];
ruby-shadow:
ensure = latest,
name = ruby-shadow,
provider = rpm,
source = /tmp/ruby-shadow-$myrshadowversion.x86_64.rpm,
require =
file[/tmp/ruby-shadow-$myrshadowversion.x86_64.rpm];
}
service {
puppet:
enable = true,
ensure = running,
restart = true,
name = puppet;
}
}
}
}
I hope that somebody got the point because as every time I'm totally
sure that I missed some peace of documentation and of course there is
always a better way to handle such situations? :)
Thanks in advance
Jan
--
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] Defines, Realization and Variables
Hi all,
I'm running puppet 0.25.5 and I'm running into an issue with virtual
defines for setting up my NGinx Vhosts.
The define is as follows:
class nginx{
...
# Setup a resource to create the configuration files
define nginx_vhost($website_listen_port = 80,$ssl_enabled = false){
$website_hostname = $title
# Setup the config file with the appropriate name from the template
file{/etc/nginx/conf.d/${title}.conf:
ensure = file,
content = template(nginx/nginx_vhost.conf.erb)
}
if $ssl_enabled != false {
$website_listen_port = 443
file{/etc/nginx/conf.d/${website_hostname}.ssl.conf:
ensure = file,
content = template(nginx/nginx_vhost.conf.erb)
}
}
}
...
}
What I want to be able to do is the following in my classes:
# Set the websites to be hosted on this server as an array
$websites = ['testing.domain.com','test2.domain.com']
# realize the websites
@nginx::nginx_vhost($websites:)
realize(Nginx::Nginx_vhost[$websites])
The issue that I am running into is that I do not appear to be able to
set the values for website_liste_port or ssl_enabled through using
this methodology.
Is the a way to pass the domain *and* the values for
website_listen_port/ssl_enabled to the define at the point of
realization?
Thanks,
Matt
--
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: high 500 error rate on file metadata operations
I've completed rolling out 2.6.3 and it's completely resolved our issues. Thanks for the help, Jason On Wed, Feb 9, 2011 at 12:18 PM, Jason Wright jwri...@google.com wrote: I rolled out 2.6.3 to four puppetmasters yesterday as part of a canary and while it's been less than 24 hours, there are already encouraging signs. The servers participating in the canary logged just short of 600 500 errors yesterday and have logged 0 so far today. For further comparison, the remainder of our puppetmaster fleet has logged over 1000 500 errors in just twelve hours today. Jason -- His face disappeared. If someone has no face left, you know it's serious. -- 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] Making dependencies work with variable resource names
I'm having an issue solving dependencies inside defines, where the paths to
various resources are variable. It seems like puppet isn't expanding all of
the variables when it constructs the catalog, so it's unable to find the
resources necessary to build things in the right order.
I've constructed a simple proof of concept to demonstrate the problem. I'm
hoping someone can provide some advice on how this case should be handled,
because clearly I've misunderstood how puppet is intended to be used to handle
this sort of case.
Here is my site.pp, with a single machine loading up the module that builds a
standard service. Each instance of the service has its own homedir with its
own data, logs, etc.
node puppet-bsd2.virtual {
include service
service::app {
first:
service_num = 1;
second:
service_num = 2;
}
}
Here's the init.pp manifest for the 'service' module. It includes the
'devices' module which is used for creating device files in a chroot
environment, and sets up the homedir for each instance of the service.
include devices
class service {
file {
/opt:
ensure = directory,
owner = root,
group = wheel,
mode = 755;
/opt/home:
ensure = directory,
owner = root,
group = wheel,
mode = 755;
}
define app (
$homedir = /opt/home,
$service_num
) {
file {
$homedir/${service_num}:
ensure = directory,
owner = root,
group = wheel,
mode= 0750;
$homedir/${service_num}/dev:
ensure = directory,
owner = root,
group = wheel,
mode= 0750;
}
devices::device_node {
${homedir}/${service_num}/dev/null:
dir = $homedir/${service_num}/dev/;
${homedir}/${service_num}/dev/random:
dir = $homedir/${service_num}/dev/;
}
}
}
And finally, the devices module.
class devices {
define device_node (
$dir
) {
exec {
create-device-${name}:
creates = ${name},
cwd = ${dir},
command = /usr/bin/touch ${name},
}
}
}
The problem is one of order of operations. With the above manifests, puppet
always tries to write the device files before it creates the 'var' directory
that contains them. According to the 'require' documentation, 'cwd' inside an
exec clause should auto-require the directory referenced. This wasn't working,
and so I tried to change the 'cwd' to a 'require = File...' in order to make
it more explicit. This is what exposed the real problem to me:
Feb 11 17:18:40 puppet-bsd2 puppet-agent[68963]: Could not run Puppet
configuration client: Could not find dependency File[/opt/home/2/dev/] for
Exec[create-device-/opt/home/2/dev/null] at
/usr/local/etc/puppet/production/modules/devices/manifests/init.pp:12
How do other people deal with these sorts of dependencies, where the files and
directories being created have variable paths based on the arguments passed to
a definition? Is there a better way to get where I'm trying to go with this?
Any clue is highly appreciated.
--
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: high 500 error rate on file metadata operations
On Fri, Feb 11, 2011 at 9:06 AM, Jason Wright jwri...@google.com wrote: I've completed rolling out 2.6.3 and it's completely resolved our issues. Thanks for the help, Wahoo! That's awesome to hear Jason. It might be worth starting canarying 2.6.5rc2, as you're doing report submissions, and we've got a fix in there for larger report submission problems. Jason On Wed, Feb 9, 2011 at 12:18 PM, Jason Wright jwri...@google.com wrote: I rolled out 2.6.3 to four puppetmasters yesterday as part of a canary and while it's been less than 24 hours, there are already encouraging signs. The servers participating in the canary logged just short of 600 500 errors yesterday and have logged 0 so far today. For further comparison, the remainder of our puppetmaster fleet has logged over 1000 500 errors in just twelve hours today. Jason -- His face disappeared. If someone has no face left, you know it's serious. -- 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.
Re: [Puppet Users] Migrating from 0.25.4 to 2.6
On Thu, Feb 3, 2011 at 7:53 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 02/03/2011 04:46 PM, Matthew Macdonald-Wallace wrote: OK, thanks, that answers the question about whether we can go backwards (we can't, we're using Regexes and a few other things!) Anyone know if a Puppet 2.6.2 client can talk to a 0.25.4 puppet master? Newer masters will entertain older clients. Do *not* use 0.24.x under any circumstances. Rolling 0.25.4 (or, while you're at it, 0.25.5) packages for debian is rather straight-forward. If you can spare a couple hours, you may find this to be the least painful road. Yep. If you get the debian repo from here: git://git.debian.org/git/pkg-puppet/puppet.git and you've worked with git-buildpackage before, it's relatively easy to get it built. -- 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: Problem with file serving and envrionments.
Finally figured it out, Maybe this is a bug I am not sure. But I was setting the environment only from the external_nodes script. I was not making any changes to the client config. When I add the environment to the puppet.conf on the client everything now works as expected. Not exactly the way it seems it should work, if you can specify the environment with ext_nodes then the client shouldn't need to configured to point to it; should it? Thanks, Trey On Feb 10, 1:16 pm, trey85stang trey85st...@gmail.com wrote: one more thing to note. If I turn off all the evironments, restart puppetmaster and then everything works fine; and just one more clairification it's only new modules being created that have the problem. On Feb 10, 10:23 am, trey85stang trey85st...@gmail.com wrote: Hey all, Im still new to puppet so I may be doing something wrong. The problem I am having is I have setup multiple environments. Going from one environment. To get started with testing that I copied my manifests directory and modules dirctories into a handful of different directories to setup the environments. The I made the changes to my puppet.conf which is below: [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl manifest = /etc/puppet/environments/production/manifests/site.pp modulepath = /etc/puppet/environments/production/modules external_nodes = /etc/puppet/ext_node.sh node_terminus = exec [agent] classfile = $vardir/classes.txt localconfig = $vardir/localconfig [master] environments=production,development,testing,beta,pilot [production] manifest = /etc/puppet/environements/production/manifests/site.pp modulepath = /etc/puppet/environments/production/modules [development] manifest = /etc/puppet/environments/development/manifests/site.pp modulepath = /etc/puppet/environments/development/modules [testing] manifest = /etc/puppet/environments/testing/manifests/site.pp modulepath = /etc/puppet/environments/testing/modules [beta] manifest = /etc/puppet/environments/beta/manifests/site.pp modulepath = /etc/puppet/environments/beta/modules [pilot] manifest = /etc/puppet/environments/pilot/manifests/site.pp modulepath = /etc/puppet/environments/pilot/modules This all works perfectly, until I add a new module to one of the environemtns to push a file out, after which my clients will receive the following message: Feb 10 10:06:31 mynode1 puppet-agent[28932]: (/Stage[main]/Environment/ File[/etc/pupdev]) Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/environment/pupdev Could not retrieve file metadata for puppet:///environment/pupdev: Error 400 on SERVER: Not authorized to call find on /file_metadata/environment/ pupdev at /etc/puppet/environments/development/modules/environment/ manifests/init.pp:7 The message on the server is: Feb 10 10:05:02 puppetserver puppet-master[5377]: Not authorized to call find on /file_metadata/environment/pupdev I've seen a few posts mentioning that the fileserver.conf file needs to be updated. I have added allow * to it as suggested in a few other palces but all that does is keeps puppetmaster from restarting. Does anyone have any ideas as to what the problem is? -- 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: Problem with file serving and envrionments.
On Feb 11, 2011 10:30 AM, trey85stang trey85st...@gmail.com wrote: Finally figured it out, Maybe this is a bug I am not sure. But I was setting the environment only from the external_nodes script. I was not making any changes to the client config. When I add the environment to the puppet.conf on the client everything now works as expected. It isn't clear what the right behaviour is - we argue about that internally, but it is clear that the current behaviour is a bug. You need to update the client environment, since currently catalogs use the ENC idea of environment, but files use the client idea of environment, which is a total mess. Sorry you got bitten by that too. Most people end up templating the client config, and make their environment value sticky through that. Regards, Daniel -- Puppet Labs Developer –http://puppetlabs.com Daniel Pittman dan...@puppetlabs.com Contact me via gtalk, email, or phone: +1 (877) 575-9775 Sent from a mobile device. Please forgive me if this is briefer than usual. -- 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: high 500 error rate on file metadata operations
On 11/02/11 18:06, Jason Wright wrote: I've completed rolling out 2.6.3 and it's completely resolved our issues. That's terriffic! Thanks for sharing this good news. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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] Check package version in order to proceed with installation (err: Could not update: package is already installed)
On Feb 11, 2011, at 3:31 AM, Jan wrote:
Hi *,
we have plans to handle the update process of puppet related packages by
our local update server. However, for now we need do deal with the
situation by fetching the respective rpms to the client and install them
by using the rpm provider.
So in order to proceed with the installation I would like to check if
the latest version is already installed before puppet tries to
install/update it, to get rid of the following error log message:
node # puppetd -o --server puppet.domain.tld --waitforcert 60 --test
[...]
err: /Stage[main]/Puppet::Client::Rollout/Package[puppet]/ensure: change
from 2.6.4-27.1 to Header-V3 failed: Could not update: Execution of
'/bin/rpm -U --oldpackage /tmp/puppet-2.6.4-27.1.x86_64.rpm' returned 1:
warning: /tmp/puppet-2.6.4-27.1.x86_64.rpm: Header V3 DSA signature:
NOKEY, key ID 5c43a8d9
package puppet-2.6.4-27.1.x86_64 is already installed
at /etc/puppet/manifests/classes/puppet.pp:42
[...]
This error occurs anytime if the latest version of the package is
already installed. I tried to use the onlyif and unless parameters
but according to the latest type reference under
http://docs.puppetlabs.com/references/latest/type.html; these seem to
be not supported, neither by the resource type file nor by resource
type package.
Well, it wouldn't help you with the file since the problem is in the Package.
1) So, just some random advice. If you're using the same server to serve files
and catalogs, you can skip listing the server and just use 3 slashes like this:
puppet:///files/rpm-sles11sp1/ruby-shadow-$myrshadowversion.x86_64.rpm
2) You sure it's not easier to just create a repository right now instead?
3) What if you try using ensure = installed in the package? Does that work?
4) I assume you're getting one of those errors for every package. Is that true?
/etc/puppet/manifests/classes/puppet.pp
class puppet {
class client {
class rollout {
$mypuppetversion = 2.6.4-27.1
$myfacterversion = 1.5.8-6.1
$myrshadowversion = 1.4.1-4.1
file {
/tmp/facter-$myfacterversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/facter-$myfacterversion.x86_64.rpm;
/tmp/puppet-$mypuppetversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/puppet-$mypuppetversion.x86_64.rpm;
/tmp/ruby-shadow-$myrshadowversion.x86_64.rpm:
source =
puppet://puppet.domain.tld/files/rpm-sles11sp1/ruby-shadow-$myrshadowversion.x86_64.rpm;
}
package {
facter:
ensure = latest,
name = facter,
provider = rpm,
source = /tmp/facter-$myfacterversion.x86_64.rpm,
require = file[/tmp/facter-$myfacterversion.x86_64.rpm];
puppet:
ensure = latest,
name = puppet,
provider = rpm,
source = /tmp/puppet-$mypuppetversion.x86_64.rpm,
require = file[/tmp/puppet-$mypuppetversion.x86_64.rpm];
ruby-shadow:
ensure = latest,
name = ruby-shadow,
provider = rpm,
source = /tmp/ruby-shadow-$myrshadowversion.x86_64.rpm,
require =
file[/tmp/ruby-shadow-$myrshadowversion.x86_64.rpm];
}
service {
puppet:
enable = true,
ensure = running,
restart = true,
name = puppet;
}
}
}
}
I hope that somebody got the point because as every time I'm totally
sure that I missed some peace of documentation and of course there is
always a better way to handle such situations? :)
Thanks in advance
Jan
--
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.
Re: [Puppet Users] Puppet in the DMZ
On Fri, Feb 11, 2011 at 00:40, Thorsten Biel thorsten.b...@porsche.de wrote: On Feb 11, 2011, at 07:25, John Warburton wrote: Does anyone have any experiences with puppet in the DMZ they can share? […] How do people get around the common rule that DMZ servers should not initiate network connections back to the internal network? Should we have a puppet server in the DMZ? Another approach is to use SSH tunnels. Use autossh to initiate SSH connections from your puppetmaster to each client. The SSH tunnels open port 8140 on localhost on the client, allowing puppet on the client to tunnel back to the master. Not the most efficient approach, but easier to implement than a slave master. I have about 50 DMZ clients running this way. I am rather surprised: wouldn't your network security folks and auditors go absolutely ape when they discovered that you had punched a hole through their firewall to allow connections from the DMZ to a secure network without going through the appropriate security analysis process? Anyway, I guess my point is that while this would probably work I can't really see why it would bring any benefit compared to just punching the hole through the firewall directly: Puppet uses SSL secured communication, and validates the identity at both ends, so you have no more or less exposure than with this mechanism, so far as I can see? Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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] force the file name of a yumrepo created file
On Fri, Feb 11, 2011 at 01:34, luke.bigum luke.bi...@fasthosts.co.uk wrote: Before I raise a feature request, is there a way to force the name of the .repo file a yumrepo is created in? Nope, sorry. The code doesn't support that at this time. Fixing it wouldn't be terribly hard, and as long as the default behaviour was identical to today you should be OK, I think. You would have to supply appropriate tests, though, to make sure that multiple repos with the same filename worked as desired. Personally, we took the approach of explicitly defining the repos we wanted the puppet way, and using the trick of putting a recursive file overlay on the repos.d directory, from an empty directory, and removing anything that wasn't managed by puppet. That gets you what you expect, and prevents package updates tromping all over your careful configuration. Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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: Problem with file serving and envrionments.
On Fri, Feb 11, 2011 at 10:30 AM, trey85stang trey85st...@gmail.com wrote: Finally figured it out, Maybe this is a bug I am not sure. But I was setting the environment only from the external_nodes script. I was not making any changes to the client config. When I add the environment to the puppet.conf on the client everything now works as expected. Not exactly the way it seems it should work, if you can specify the environment with ext_nodes then the client shouldn't need to configured to point to it; should it? Ah, you're becoming familiar with 3910 my old dear friend. https://projects.puppetlabs.com/issues/3910 time to devote some more cycles to this one... -- 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] puppetrun :: HTTP-Error: 500 Internal Server Error (w/ Passenger)
I'm running puppetmaster with passenger and it's breaking my puppetrun capabilities. If run puppetrun running from webbrick it runs, if I run it with apache/passenger, it gives me an error. bash-3.2# /usr/sbin/puppetrun --host client.dev.domain.com Triggering client.dev.domain.com warning: peer certificate won't be verified in this SSL session Host client.dev.domain.com failed: HTTP-Error: 500 Internal Server Error client.dev.domain.com finished with exit code 2 Failed: client.dev.domain.com puppetmaster manifests $ nc -v client 8139 Connection to client 8139 port [tcp/*] succeeded! puppetmaster manifests $ (client / Server ) namespaceauth.conf: [fileserver] allow * [puppetmaster] allow * [puppetrunner] allow * puppetmaster manifests $ sudo /usr/sbin/puppetrun --trace --debug --host=client.dev.domain.com Triggering client.dev.domain.com warning: peer certificate won't be verified in this SSL session /usr/lib/ruby/1.8/xmlrpc/client.rb:546:in `do_rpc' /usr/lib/ruby/1.8/xmlrpc/client.rb:420:in `call2' /usr/lib/ruby/1.8/xmlrpc/client.rb:410:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/network/xmlrpc/client.rb:146:in `make_rpc_call' /usr/lib/ruby/site_ruby/1.8/puppet/network/xmlrpc/client.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/network/client/proxy.rb:15:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/network/client/proxy.rb:15:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/puppetrun.rb:122:in `run_for_host' /usr/lib/ruby/site_ruby/1.8/puppet/application/puppetrun.rb:70:in `main' /usr/lib/ruby/site_ruby/1.8/puppet/application/puppetrun.rb:69:in `fork' /usr/lib/ruby/site_ruby/1.8/puppet/application/puppetrun.rb:69:in `main' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/sbin/puppetrun:129 Host client.dev.domain.com failed: HTTP-Error: 500 Internal Server Error client.dev.domain.com finished with exit code 2 Failed: client.dev.domain.com Has anyone seen this before? Thanks, -- 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: puppetrun :: HTTP-Error: 500 Internal Server Error (w/ Passenger)
BTW: I'm using puppet 0.25.5 -- 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] Active Directory join, stages, and AD accounts issues
I have a mostly working set of modules to replace our kickstart and about a dozen scripts. I am having issues with attempting to populate my AD account-owned user folders in the initial puppet run. The machines i am testing with are all CentOS 5.5 so far. I have defined 3 additional stages, Stage [init] - Stage [pre] - Stage [main] - Stage [post] to attempt to fix this to no avail. I have my Samba class defined in pre, with my make ad prod user folders class defined in post. I am also managing my ldap.conf, system-auth-ac, nsswitch.conf all in the initial stages. I have an exec in my samba module to join the new servers to the domain, a simple net ads join -U adminaccount. I see during --test runs, that the joindomain exec is scheduled to run after the smb and krb5 files are puppettized. Then way at the end of my run I see puppet attempting to create my user folders, but it is giving errors stating that the users do not exist. However, as soon as the catalog run finishes, the AD users are indeed recognized by id username. A second run of puppet completes with no issues. What am I missing to make sure that the AD user folders class is not attempted before the join has happened? Thanks, Jim Goddard -- 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] Active Directory join, stages, and AD accounts issues
On Fri, Feb 11, 2011 at 11:52 AM, Monkeys Typing monkeys.typ...@gmail.com wrote: I have a mostly working set of modules to replace our kickstart and about a dozen scripts. I am having issues with attempting to populate my AD account-owned user folders in the initial puppet run. The machines i am testing with are all CentOS 5.5 so far. I have defined 3 additional stages, Stage [init] - Stage [pre] - Stage [main] - Stage [post] to attempt to fix this to no avail. I have my Samba class defined in pre, with my make ad prod user folders class defined in post. I am also managing my ldap.conf, system-auth-ac, nsswitch.conf all in the initial stages. I have an exec in my samba module to join the new servers to the domain, a simple net ads join -U adminaccount. I see during --test runs, that the joindomain exec is scheduled to run after the smb and krb5 files are puppettized. Then way at the end of my run I see puppet attempting to create my user folders, but it is giving errors stating that the users do not exist. However, as soon as the catalog run finishes, the AD users are indeed recognized by id username. A second run of puppet completes with no issues. What am I missing to make sure that the AD user folders class is not attempted before the join has happened? One thing that wasn't quite clear was whether in the logs you've verified that the exec is actually run after the user folders class. ie whether this is a puppet ordering problem, or a lag on the node between joining and the users being accessible. Thanks, Jim Goddard -- 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: Problem with file serving and envrionments.
Thanks for the 411, Looks like I will just deal with the config file on the client. I can't say that would be my preferred way but I can deal with that. Thanks for the reponses and it's not a big deal. I can't complain too much when my work load is going to be decreasing greatly when I get this deployed. On Feb 11, 1:27 pm, Nigel Kersten ni...@puppetlabs.com wrote: On Fri, Feb 11, 2011 at 10:30 AM, trey85stang trey85st...@gmail.com wrote: Finally figured it out, Maybe this is a bug I am not sure. But I was setting the environment only from the external_nodes script. I was not making any changes to the client config. When I add the environment to the puppet.conf on the client everything now works as expected. Not exactly the way it seems it should work, if you can specify the environment with ext_nodes then the client shouldn't need to configured to point to it; should it? Ah, you're becoming familiar with 3910 my old dear friend. https://projects.puppetlabs.com/issues/3910 time to devote some more cycles to this one... -- 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] ANNOUNCE: Puppet 2.6.5 - Release Candidate 2 available!
Jacob Helwig wrote: We're back with a maintenance release: 2.6.5. This release addresses a number of bugs in the 2.6.x branch and adds a handful of features and documentation updates. For those using Fedora or RHEL/CentOS, I've updated the yum repos at: http://tmz.fedorapeople.org/repo/puppet/ Packages for EL 4 - 6 and Fedora 13 - 14 are available for testing. Add the puppet.repo file from either the epel or fedora directories to /etc/yum.repos.d to enable. If you find problems with the packaging, please let me know. If you find other bugs, please file them in redmine: http://projects.puppetlabs.com/projects/puppet/issues I'm particularly interested in anyone updating from 0.25.x to 2.6.x and whether you run into regressions or other issues that would make this an unsuitable update to push into the stable Fedora and EPEL repositories. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Optimist, n.: A proponent of the doctrine that black is white. -- Ambrose Bierce, The Devil's Dictionary pgp0jsHLjY8GN.pgp Description: PGP signature
Re: [Puppet Users] Check package version in order to proceed with installation (err: Could not update: package is already installed)
Hi Patrick, On 02/11/2011 07:40 PM, Patrick wrote: [...] 1) So, just some random advice. If you're using the same server to serve files and catalogs, you can skip listing the server and just use 3 slashes like this: puppet:///files/rpm-sles11sp1/ruby-shadow-$myrshadowversion.x86_64.rpm I see but I've just added this during the debugging procedure of our nameservers, anyhow your advice is welcome :) 2) You sure it's not easier to just create a repository right now instead? Of course and I would really like to but for the moment we're facing some serious issues which won't fix in time. Thats the major reason for me searching a temporary solution. 3) What if you try using ensure = installed in the package? Does that work? This won't work because puppet (as of version 0.24.x) is already installed on all nodes. That's the reason why I want puppet to upgrade the package _only_ if a newer version is available. When using ensure = installed the package won't be upgraded because some version is already installed. However, I haven't checked it by myself but I think that the same error message will be thrown if using ensure = latest on other packages, right? If yes, would you say that its a bug or a feature? ;) I want to get rid of that error message to keep the log files clean maybe to let them be checked on errors by our monitoring agent at a later time. The rest of the manifest seems to work just fine also with this error message coming up. 4) I assume you're getting one of those errors for every package. Is that true? Yes, that's correct. Jan -- 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] Puppet T-shirt contest
Hi all, Our Puppet t-shirts are due for a redesign: http://www.puppetlabs.com/blog/tshirt-contest/ Be sure you submit cool tagline for our new shirts and enter for a chance to win an Ar.drone ( http://store.apple.com/us/product/H1991ZM/A?fnode=MTY1NDA3NAmco=MjA1MTA3MzY ) and a ticket to Puppet Camp(http://www.puppetlabs.com/community/puppet-camp/ ) -- 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.
