Re: [Puppet Users] how to link items together -- all happen together?
On 2011-12-08 11:07 , Jo Rhett wrote:
I've found some problems due to the extremely random ordering puppet
does. It is necessary for some of these items to all happen together,
with no other random resources executed in between. Is there some way
to arrange this with puppet?
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and
other randomness
Have you tried specifying the dependencies between your resources?
package { 'foo':
ensure = installed,
}
file { '/etc/foo.conf':
ensure = file,
source = 'puppet:///module/foo/foo.conf',
require = Package['foo'],
}
service { 'foo':
ensure = running,
subscribe = File['/etc/foo/foo.conf'], Package['foo'],
}
Both subscribe and require will setup ordering between resources.
--
Jacob Helwig
http://technosorcery.net/about/me
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] puppetlabs-firewall: source param as array
On 2011-11-29 13:05 , Mohamed Lrhazi wrote:
Hi,
am trying this rule:
firewall { '100 allow ssh from GUNET':
proto = 'tcp',
dport = '22',
source = ['10.0.0.0/8','192.168.0.0/16',],
action = accept,
}
and it only seems to add a rule for the first subnet. The second is
silently ignored.
is my syntax incorrect?
Thanks,
Mohamed.
The type doesn't appear to be written to handle accepting arrays in the
source property, so given how it's written it's expected behavior,
though sounds like it's rather undesirable.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] is_virtual fact
On 2011-11-23 12:49 , Matt Zagrabelny wrote:
Hi,
I've got a question regarding a fact. I'm trying to use the
'is_virtual' fact in a class manifest:
class io_scheduler {
if $is_virtual {
file { /etc/default/grub:
owner = root,
group = root,
mode= 0644,
source = puppet:///modules/io_scheduler/etc/default/grub,
}
}
}
However, on one of my physical systems:
$ facter | grep is_virtual
is_virtual = false
The file mentioned above gets installed:
Nov 23 14:22:50 hostname puppet-agent[1838]:
(/Stage[main]/Io_scheduler::Config/File[/etc/default/grub]/content)
content changed '{md5}01de0bd1b00e2ca04ebb873ace6f20fe' to
'{md5}a882618adcb31667cbab22731f8f16e2'
Any ideas what is wrong here?
Thanks for the help!
-matt zagrabelny
Facter facts are all strings, not true booleans. You'll need to check
for whether or not $is_virtual == 'true'.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet Windows: scheduled_task : TypeError
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
Another question I have is how do I schedule for every 30 minutes? or
every one hour?
Thanks a lot,
Mohamed.
Since the scheduled_task type uses the v1 Windows API, being able to set
repetitions at resolutions more fine grained than the daily level isn't
possible, without creating multiple triggers to create the within a day
repetition manually.
If you know of a good Ruby interface to the newer Task Scheduler APIs,
which support this, then it would be possible for someone to write
another provider that supported this.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet Windows: scheduled_task : TypeError
On 2011-11-23 15:53 , Mohamed Lrhazi wrote:
Thanks JacobDid that answer my TypeError as well?
No, a stack trace would help for that.
--
Jacob Helwig
http://about.me/jhelwig
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig ja...@puppetlabs.com wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet Windows: msi packages removal
On 2011-11-22 07:10 , Mohamed Lrhazi wrote: I noticed that is if I uninstall an MSI that was installed by Puppet, Puppet does not notice. Looking at the source I see it might be checking for a state file to know whether a package is installed or not: C:\ProgramData\PuppetLabs\puppet\var\db\package\msi\SplunkForwarder.yml So one has to rememebr to delete that too Is this design not a problem? Thanks, Mohamed. It's certainly a limitation, and not ideal. This is currently how the appdmg provider behaves on OS X, so it's not entirely unexpected behavior (for people that are used to how Puppet works on systems without centralized package management systems). An alternative would be to create a parameter along the lines of exec's 'creates' where you would need to specify a file that would only exist iff the 'package' had been successfully installed. When we were investigating things initially I believe that the reason we had to rule out things like checking the registry was that there were too many ways for an installer to misbehave that would break any of the detection that we would need to do. I don't know whether or not a 'creates' parameter would end up being more problematic or not, but I certainly welcome discussion from people who are actually doing real systems management using Puppet on Windows. -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Puppet not picking up new configs
On 2011-11-20 16:08 , Michal Ludvig wrote: Hi all, I've got a Puppet 2.6.8 setup on RHEL 5.6 with nodes.pp containing a simple import nodes/*.pp and per-node configs in nodes/hostname.pp Occasionally puppet master misses new nodes' files, simply ignores them and the subsequent puppet agent run on the node fails with Could not find default node or by name with All that is needed in such a case is /etc/init.d/puppetmaster restart but it's clearly not an optimal fix. It doesn't happen all the time, in most cases the new node's file is correctly recognised, but in the last case the file was sitting there for 4 days unnoticed and only after puppetmaster restart it was read in. Any idea what's causing it? Is there anything we can do to prevent this from happening again and again? Thanks! Michal Pretty sure you're just running into the normal behavior of the caching that puppet does: Since puppet caches successfully compiled files until it notices that they've changed, it won't go back to re-compile the nodes.pp (and pick up the new nodes/hostname.pp files) until nodes.pp itself needs a recompile. -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Installing puppet agent on Windows XP
On 2011-11-21 12:50 , Jeff Sussna wrote: Trying to get Puppet 2.7.6/Facter 1.6.2 running on Windows XP SP3. Followed the install instructions carefully, got no errors. facter and puppet both hang no matter what I try. The only things that don't hang are: facter operatingsystem (or any other individual facter query) facter --version facter --debug hangs, as does puppet --version or any other puppet command, including 'puppet config print all'. Anyone have success getting puppet running on XP? Right now, Puppet Facter are only supported on Server 2003 Server 2008, since those are the only platforms we tested against when working on the Windows support. If come up with patches to get past the hangs on XP we'd love to see them. Which install instructions were you following? If it didn't clearly call out which platforms are currently supported, we'll need to update the instructions. -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] struggling with vcsrepo, git, latest
On 2011-11-21 22:00 , jwag wrote:
I am working with 2.7.3, latest vcsrepo from github. Trying to get a
git workarea kept up to date (latest).
The call:
vcsrepo { puppetm:git:co:
ensure = latest,
provider = git,
path = $srcdir,
source = g...@github.com:/xxx.git,
owner = puppet,
group = puppet,
identity = $puppetm::puppethomedir/.ssh/
$puppetm::pkeyname,
}
I added some debugging (the warnings) to git.rb to try and figure out
what is going on... but am stumped:
warning: git with identity fetch--tagsorigin
warning: git with identity rev-parseHEAD
warning: git with identity branch-a
warning: git with identity fetchorigin
warning: git with identity fetch--tagsorigin
warning: git with identity rev-parseorigin/HEAD
warning: get_revision ff9625bad45d398573bd664a5fdf7ab2cfa4c185
warning: git with identity fetch--tagsorigin
warning: git with identity branch-a
warning: git with identity fetchorigin
warning: git with identity fetch--tagsorigin
warning: git with identity rev-parseorigin/HEAD
warning: get_revision ff9625bad45d398573bd664a5fdf7ab2cfa4c185
notice: /Stage[main]/Puppetm/Puppetm::Checkout[puppetm:cloudops]/
Vcsrepo[puppetm:git:co]/ensure: Updating to latest
'ff9625bad45d398573bd664a5fdf7ab2cfa4c185' revision
warning: git with identity branch-a
warning: git with identity tag-l
warning: git with identity branch-a
warning: remote_branch remotes/origin/HEAD - origin/masterremotes/
origin/devremotes/origin/masterremotes/origin/mvn_projremotes/origin/
tectonic_move
warning: git with identity checkout-
bff9625bad45d398573bd664a5fdf7ab2cfa4c185--trackorigin/
ff9625bad45d398573bd664a5fdf7ab2cfa4c185
err: /Stage[main]/Puppetm/Puppetm::Checkout[puppetm:cloudops]/
Vcsrepo[puppetm:git:co]/ensure: change from present to latest failed:
Execution of '/usr/bin/git checkout -b
ff9625bad45d398573bd664a5fdf7ab2cfa4c185 --track origin/
ff9625bad45d398573bd664a5fdf7ab2cfa4c185' returned 128: fatal: git
checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/
ff9625bad45d398573bd664a5fdf7ab2cfa4c185' which can not be resolved as
commit?
basically - it looks like it properly figured out the latest commit
SHA - but then goes and does a git checkout -b SHAxxx --track origin/
SHAxxx
but of course there is no remote branch named origin/SHAxxx
standard git setup (I think):
-bash-4.1$ git branch -a
* master
remotes/origin/HEAD - origin/master
remotes/origin/dev
remotes/origin/master
remotes/origin/mvn_proj
I have tried setting revision = HEAD - but that results in no
updates - possibly since it thinks that means the local HEAD rather
than the remote.
ideas?
Unfortunately, last I checked the vcsrepo type was just broken when it
comes to what it does with Git repos. I started trying to clean it up
in my spare time[0], but don't have anything actually ready to merge
back into the main repo yet.
[0] https://github.com/jhelwig/puppet-vcsrepo/tree/rework-git-provider
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Using regex to ensure package version
On 2011-11-18 08:37 , Matt wrote:
I'm trying to use something like this...
package { blah: ensure = 1.2.3* }
...and I know that doesn't work because it looks for a package
literally with that value 1.2.3*. What I want is to say, install
the latest package in the 1.2.3 branch but don't automatically upgrade
to anything later than that.
e.g. 1.2.3-01, 1.2.3-05 are fine if I find them in the REPObut not
1.2.4 or later.
I'm sure there's a way to do this with a regex or something, but I've
not been able to find any examples in my searches so far.
Thanks,
Matt
Puppet doesn't have a way to do that. The way the package type
providers are setup they will always compare literal strings.
Typically how people have handled this is by ensuring 'latest', but
managing the repository that the machine will pull the packages from so
that it will only ever contain something in the 1.2.3 series.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] puppet agent 2.7 on windows
On 2011-11-18 09:15 , Ravi wrote: Hi Team, Tried following the steps here http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows for deploying an agent on windows (windows server 2008 r2) but really finding it hard to make it work (the agent deployment itself went fine after following the steps). I have a working puppet-server on RH 6 and have tested few RH clients which work fine. The very first hurdle is that i don't find a default puppet.conf in c: \programdata\puppetlabs\puppet\etc folder. Only auth.conf is present in this folder. Secondly from the command line when i run puppet config print all , i get a lot of settings. I am really not sure on where it is fetching these settings from ? Basically i need to provide the puppet-server name to the client for it to communicate and register. (In RH this is done in /etc/puppet/ puppet.conf). Tried copying this puppet.conf file to windows server but doesn't work. Any guidance will be very helpful. Cheers, Ravi A (relatively) quick way to get started would be to put the output of 'puppet agent --genconfig' into the file output by 'puppet agent --configprint config', and modifying to taste. The 'puppet config print all' is getting the settings from the internal defaults of Puppet itself, so it's not really fetching them from anywhere. -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
[Puppet Users] Open Source Team update 2011-11-17
We have been working on going through the list of submitted patches in Patchwork[0], and the open pull requests in GitHub[1][2][3]. There has been activity on a number of them, but not all with activity have resulted in merged changes. We also recently finished work on a fix for the problem of using Puppet to install the requirements for types modules that are shipped to the agent via pluginsync (#6907). This has not been merged yet, but is ready for wider testing, and review[4]. Merged changes in Puppet: Merritt Krakowitzer provided the base fix for updating the lastchg shadow file field on Solaris when changing a user's password (#6371). This has been merged into the 2.7.x, and master branches, and is in the current 2.7.7 RC. Merged changes in Facter: Jason Gill provided support for Parallels Server Bare Metal (#10233). This has been merged into the 1.6.x, and master branches, and released in 1.6.3. Jason Gill provided support for retrieving information about block devices on Linux (#10238). This has been merged into the master branch. Jeff Palmer provided support for Ascendos (#10228). This has been merged into the 1.6.x, and master branches, and released in 1.6.3. Stefan Schulte provied a fix for the macaddress fact incorrectly handling the case where no macaddress was found (#10490). This mas been merged into the 1.6.x branch. [0] https://patchwork.puppetlabs.com [1] https://github.com/puppetlabs/puppet/pulls [2] https://github.com/puppetlabs/facter/pulls [3] https://github.com/puppetlabs/puppet-dashboard/pulls [4] https://github.com/puppetlabs/puppet/pull/223 Current backlog: * #6907 - Ensure providers can be used in the same puppet run that their prerequisites are delivered in * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - Overriding parameters on included inherited classes * #3741 - Custom facts loaded multiple times * #4916 - Plugins should not be able to override core functionality. * #7788 - Puppet should allow rubygems to deliver new functionality * #3910 - Server is not authoritative over client environment when specified in an ENC * #3534 - Dashboard should support ability to set variables as arrays in the ENC * #2247 - enablerepo and disablerepo for yum type -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Rounding in variable expressions
On 2011-11-15 07:24 , Tom Hall wrote: Hi, Can you round in variable assignment expressions? I would like to be able to set $my_var = floor(::processorcount * 0.8) Cheers, Tom That should work just fine as long as you define an rvalue function called 'floor'. There should be a bunch of good examples of how to do this in the stdlib[0] repo in lib/puppet/parser/functions. [0] https://github.com/puppetlabs/puppetlabs-stdlib/ -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] WinXP Agent SSL issue/Increase TLS timeout on Puppet Master?
On 2011-11-09 12:51 , Andrew Ring wrote: Greetings, While using puppet 2.7.6-266 on a very old Windows XP system (I know WinXP is not supported by puppet), I have run into an error when running Puppet Agent: err: Could not request certificate: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A My install procedure is that from the Puppet Labs site: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows Watching the transaction via wireshark, communication is and is killed very shortly after it starts, just over 0.1 seconds between the first Syn and the last Rst. The Puppet Master receives the client's certificate. I am also able to sign the certificate, which does not alter the behavior of puppet on the client. I can not confirm it, but it took several times running the Puppet Agent for the system's SSL certificate to reach the point where puppetca --list would display it. The Puppet Master is running Puppet version 2.6.2-5. I have a second, new Windows 7 system, using the same software versions, has no issue connecting to the Puppet Master. In a thread titled SSH port forwarding from 28 March 2011(?) (http://comments.gmane.org/gmane.comp.sysutils.puppet.user/29632) it was mentioned that the Puppet Master has a TLS timeout of 0.1 seconds. Is this a general issue with Puppet and Windows XP? Is there a way to increase the TLS timeout on the Puppet Master? Alternatively, is there a method to confirm that the TLS timeout is my problem? Thank you, Andrew Upgrade your master. It sounds like you're running into #4762[0], which was fixed in 2.7.3. Also, you should be running a version of the master that is = the version of your newest agent. [0] http://projects.puppetlabs.com/issues/4762 -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Starting out with puppet and capistrano
On 2011-11-09 13:38 , Tim Uckun wrote:
Hey guys.
I am starting out with puppet and am in the process of writing a
bootstrap script for the clients and a capistrano recipe for the
server. I have the client bootstrap done which installs ruby, puppet,
sets a host name, and then points the client at the puppet server and
now I am in the process of setting up the puppet server.
My first attempt was to set up a git project for puppet, an admin user
on the server and then use capistrano to deploy my puppet config and
all manifests into a directory in the admin users home. Basically this
would be the contents of the /etc/puppet directory. The idea was that
I would deploy to /home/admin_user/infrastructure and then symlink
that directory or /etc/puppet. This didn't work because puppet blows
away the symlink and sets up a blank directory in /etc/puppet.
So I am wondering what to do next. Some options...
1. I could use rsync after deploy to copy the contents to /etc/puppet
but I noticed that the manifests directory are owned by the user
puppet so I don't know how well that would work.
2. I could manually set up a /etc/puppet/puppet.conf which points to
the manifests in the /home/admin directory and manage the puppet conf
with puppet.
3. I could use something other than capistrano. I am familiar with
capistrano so I would prefer to stay with it but I am willing to learn
something else if it would be better.
I also have a question as to whether the ssl directory should be
managed by puppet itself or me. I kind of presumed everything in
/etc/puppet would be managed by me and everything in /var/lib/puppet
would be managed by puppet is that right?
So does anybody have a nice capistrano config.rb for puppet?
Dunno if it's the best way, but I went with #2 for my setup. It's very
basic, and has been working great for me. Full setup below for the
benefit of those that aren't familiar with Capistrano.
Sorry for the line wrapping in the puppet.conf, but I haven't gotten
Thunderbird fully trained yet.
/etc/puppet/puppet.conf:
[master]
manifestdir = /u/apps/puppet-manifest/current/manifests
modulepath =
/u/apps/puppet-manifest/current/modules:/usr/share/puppet/modules
config_version = 'cat /u/apps/puppet-manifest/current/REVISION'
Capfile:
require 'rubygems'
require 'railsless-deploy'
load 'deploy' if respond_to?(:namespace) # cap2 differentiator
Dir[
'vendor/gems/*/recipes/*.rb',
'vendor/plugins/*/recipes/*.rb'
].each do |plugin|
load(plugin)
end
load 'config/deploy'
config/deploy.rb:
set :application, puppet-manifest
set :repository, repo-here
set :scm, :git
set :branch, 'master'
set :deploy_via, :remote_cache
# Needed to deploy vcsrepo (submodule)
set :git_enable_submodules, true
role :app, puppet master's hostname
set :user, 'app'
set :use_sudo, false
default_run_options[:pty] = true
ssh_options[:forward_agent] = true
# this tells capistrano what to do when you deploy
namespace :deploy do
desc -DESC
A macro-task that updates the code and fixes the symlink.
DESC
task :default do
transaction do
update_code
symlink
end
end
task :update_code, :except = { :no_release = true } do
on_rollback { run rm -rf #{release_path}; true }
strategy.deploy!
end
after :deploy, 'deploy:cleanup'
end
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Starting out with puppet and capistrano
On 2011-11-09 14:42 , Tim Uckun wrote: Oh what about the SSL directory? Should I attempt to manage that or just let puppet manage it. Also does it make more sense to keep that in /etc/puppet or /var/lib/puppet? Cheers. I just left it alone at the defaults, and let Puppet take care of it. -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] puppet facter timeout
On 2011-11-07 05:50 , raffis wrote:
I have a problem with a new Ubuntu server (2.6.32-33-server) and
facter.
Facter Version 1.5.6
root@web002:~# facter
/usr/lib/ruby/1.8/timeout.rb:60:in `open': execution expired
(Timeout::Error)
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout'
from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout'
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect'
from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start'
from /usr/lib/ruby/1.8/net/http.rb:542:in `start'
from /usr/lib/ruby/1.8/open-uri.rb:242:in `open_http'
from /usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open'
from /usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `catch'
from /usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop'
from /usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri'
from /usr/lib/ruby/1.8/open-uri.rb:518:in `open'
from /usr/lib/ruby/1.8/open-uri.rb:30:in `open'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:10:in `can_connect?'
from /usr/lib/ruby/1.8/facter/ec2.rb:33
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load'
from /usr/lib/ruby/1.8/facter/util/loader.rb:72:in `load_file'
from /usr/lib/ruby/1.8/facter/util/loader.rb:38:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:33:in `load_all'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `each'
from /usr/lib/ruby/1.8/facter/util/loader.rb:30:in `load_all'
from /usr/lib/ruby/1.8/facter/util/collection.rb:94:in `load_all'
from /usr/lib/ruby/1.8/facter.rb:91:in `to_hash'
from /usr/bin/facter:138
facter with strace:
It stops 1-2s, thats the output of strace.
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(169.254.169.254)}, 16) = -1 EINPROGRESS
(Operation now in progress)
select(5, [], [3], [3], {1, 969055}^C unfinished ...
Puppet says, there is a problem with local facts, and I'm sure thats
the facter problem ;)
And there is no problem with dns, all other servers with the same
version of facter and puppet have no problems... The only thing I did
on this server is an upgrade with apt-get, but facter and puppet are
the same version as they are on the other servers
Thanks for your help
You'll want to keep an eye on the Ubuntu bug for this[0].
[0] https://bugs.launchpad.net/ubuntu/+source/facter/+bug/885998
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] upgrade puppet Ubuntu 10.04
On 2011-11-03 02:17 , Dominique Servelle wrote: the 10/31/2011 ubuntu upgrade facter from facter_1.5.6-2ubuntu2.1_all.deb facter_1.5.6-2ubuntu2.2_all.deb. Since nothing work and I've got a message : Could not run Puppet configuration client: Could not retrieve local facts: execution expired All the clients and the server are running the last version of puppet and puppetmaster (puppet_0.25.4-2ubuntu6.5_all and puppetmaster_0.25.4-2ubuntu6.5_all) I can't fix this, do you have an idea ? Can you contact ubuntu packagers to fix this ? Thanx a lot for my 100 desktops Your best bet is to contact the Ubuntu package maintainers directly using their bug system[0][1] or on the ubuntu-server mailing list[2]. It looks like you're running Facter out of one of the proposed repositories though. I'm pretty sure that facter_1.5.6-2ubuntu2.2_all.deb was put into the proposed repo to address #876130[3], #732953[4], and nothing else. If it breaks things for you, then you should definitely comment on one of those tickets with more details about your setup (at the very least which version of Ubuntu you're using). [0] https://bugs.launchpad.net/ubuntu/+source/facter [1] https://bugs.launchpad.net/ubuntu/+source/puppet [2] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server [3] https://bugs.launchpad.net/ubuntu/lucid/+source/facter/+bug/876130 [4] https://bugs.launchpad.net/ubuntu/lucid/+source/facter/+bug/732953 -- Jacob Helwig http://about.me/jhelwig signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] 2.7.6 yumrepo not working
It's the dashes at the end of variable names problem. Try
...${operatingsystem}-${operatingsystemrelease}-${architecture} instead.
On 2011-11-01 09:07 , Len Rugen wrote:
You probably need to escape some of this, part of ours-
.repo/\$releasever/\$basearch
puppet/factor shouldn't resolve these variables, they go to the repo
file and are resolved by yum or whatever.
On Tue, Nov 1, 2011 at 10:45 AM, Christopher Johnston
chjoh...@gmail.com mailto:chjoh...@gmail.com wrote:
Just upgraded to 2.7.6 and the yumrepo type does not write out our
yum configs correctly, anyone experiencing this? Documentation
hasn't changed from what I can tell for this type.
# facter -version
1.6.2
# puppetd --version
2.7.6
# facter architecture
x86_64
# facter operatingsystem
Fedora
# facter operatingsystemrelease
14
My manifest
yumrepo {
'EWT-Base':
descr= 'Base Repository',
baseurl =
http://repo:80/$operatingsystem-$operatingsystemrelease-$architecture;,
gpgcheck = 0,
enabled = 1,
priority = 1;
= What gets written out
[Base]
name=Base Repository
baseurl=http://repo:80/x86_64
enabled=1
gpgcheck=0
priority=1
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] 2.7.6 yumrepo not working
There was a change in 2.7 to allow dashes in variable names. There's an
issue open in Redmine around this very issue[0]
[0] http://projects.puppetlabs.com/issues/10146
On 2011-11-01 10:29 , Christopher Johnston wrote:
That worked, for some reason back referencing did not. My foolishness I
was overlooking normal variable semantic (like in shell). Strange thing
my prior setup worked fine in 2.6, 2.7 broke it.
-Chris
On Tue, Nov 1, 2011 at 12:40 PM, Jacob Helwig ja...@puppetlabs.com
mailto:ja...@puppetlabs.com wrote:
It's the dashes at the end of variable names problem. Try
...${operatingsystem}-${operatingsystemrelease}-${architecture}
instead.
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Passing a variable to exec?
Change your single quotes to double quotes and it should just work.
On Thu, Oct 20, 2011 at 16:42, Parker Johnson pjoh...@yahoo.com wrote:
I am trying to grow a logical volume on AIX depending on the size of
the running kernel. I've got all of the custom facts setup. Now I
just need to exec on that variable. Having a heck of a time trying to
figure out how to do this. Is it possible?
Here is a snippet of my manifest:
#don't worry about this so much
$addtodumplv = ((( $needump_kbsize - $pridumplv_kbsize ) /
$pridumplv_ppsize ) + 1 )
exec { 'extendlv hd6 $addtodumplv': # here
is my problem. How do I call $addtodumplv from here?
path = [/usr/sbin, /opt/freeware/bin],
}
--
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] Type reference, Puppet versions
On Fri, 14 Oct 2011 10:04:19 -0700, Nigel Kersten wrote: On Fri, Oct 14, 2011 at 7:05 AM, Martijn Grendelman mart...@iphion.nlwrote: Hi, I have no idea if this has come up before, I didn't bother to check the archives or anything, but I was wondering if it would be possible to have Puppet's documentation reflect the version in which a certain feature was added. For example, I just added a user to my catalog using the 'system' parameter, as per http://docs.puppetlabs.com/references/latest/type.html#user: system Whether the user is a system user with lower UID. Valid values are true, false. And now all my 2.6.3 nodes are complaining: Invalid parameter system at /etc/puppet/manifests/... A little digging into the source revealed to me, that this feature is not present in 2.6.3, but it is in 2.7.5. I have no idea in what version it was introduced. It would be nice if the type reference would contain that information. If you go to the Quick Nav menu, you can get to the docs for other versions: http://docs.puppetlabs.com/references/ Then: http://docs.puppetlabs.com/references/2.6.11/type.html should contain what you need I believe ? I think he wants something more along the lines of the since sections you can create with newer versions of YARD when documenting methods. For for example: http://rubydoc.info/gems/octocat_herder/0.1.1/OctocatHerder/PullRequest#diff_text-instance_method -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] how to check if a hash/array is empty or not in puppet .pp/module (not in template)?
On Thu, 13 Oct 2011 10:01:49 -0700, midair77 wrote:
Dear all,
I have a parameterized class and one of the args is a hash or an array
and I would like to check if they are empty or not?
I tried with
class test($hash, $array){
if $hash.empty? == true
{
}
if $array.empty? == true
{
}
}
but when I just
puppet parser validate init.pp
I would get this error: Could not parse for environment production:
Syntax error at '.'; expected '}' at.
Please help as this is important to know how to do this type of check.
Thank you in advance.
The cleanest way to do this would be to write a custom rvalue function
that does the Ruby check for you. You can't call ruby directly from the
puppet language, so you need to use functions or inline templates. I
definitely recommend going the function route, since it's much easier to
write tests for those, and your manifests end up looking much cleaner.
http://docs.puppetlabs.com/guides/custom_functions.html
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] Re: Problem with custom function returning array
Did you topo part of the function definition, or does it actually have
'returnsources' at the end of the newfunction block?
You should have 'return sources', 'sources', or just leave that bit off,
since 'sources puppet:///files/common/#{filename}' will return the
value of sources.
--
Jacob Helwig
On Thu, 13 Oct 2011 13:44:14 -0700, Nate wrote:
Anybody have any thoughts on this?
On Oct 7, 8:50 am, Nate nathan.schum...@gmail.com wrote:
Hi,
I'm trying create acustomfunctionthat willreturnanarrayof file
paths for the file type source. Instead of defining the followingarrayfor
source for each file type:
file: { some_file:
source = [ puppet:///file/$hostname/path, puppet:///file/$role/
$mode/path, puppet:///file/$role/path, puppet:///file/common/
path, ],
...
}
I've created acustomfunctiontoreturnthe generatedarraysimilar
to the following:
file: { some_file:
source = find_file(path),
...
}
I'm getting the following message on the client:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER:Function'find_file' does notreturna value at /etc/puppet/
manifests/class/sudo.pp:12 on node tnfs01
Thefunctionis located at /var/lib/puppet/lib/puppet/parser/functions/
find_file.rb.
Function:
module Puppet::Parser::Functions
newfunction(:find_file, :type = :rvalue) do |args|
filename = args[0]
hostname = lookupvar('hostname')
role = lookupvar('role')
mode = lookupvar('mode')
sources =Array.new
sources puppet:///files/#{hostname}/#{filename}
sources puppet:///files/#{role}/#{mode}/#{filename}
sources puppet:///files/#{role}/#{filename}
sources puppet:///files/common/#{filename}
returnsources
end
end
Not sure what I'm doing wrong here. Any help would be greatly
appreciated. Also, if there's already a built-in way to do this in
Puppet I'd gladly ditch thecustomfunction, although I'd still like
to figure out the problem for future reference.
Thanks,
Nate
signature.asc
Description: Digital signature
Re: [Puppet Users] Python yaml help
On Wed, 12 Oct 2011 11:01:28 -0400, Mohamed Lrhazi wrote: Sorry for being off topic. am trying the following and yaml fails to construct the object: The inventory document, from Puppet dashboard inventory service, looks like: --- !ruby/object:Puppet::Node::Facts name: pirates.uis.example.com values: productname: VMware Virtual Platform kernelmajversion: 2.6 My code: class PuppetFacts(yaml.YAMLObject): yaml_tag = u'!ruby/object:Puppet::Node::Facts' def __init__(self, name, values): self.name = name self.values = values The attempt to load the doc results in: ConstructorError: could not determine a constructor for the tag '!ruby/object:Puppet::Node::Facts' in byte string, line 1, column 5 Thanks a lot, Mohamed. Hm. Looks like you're doing exactly what was suggested in a couple of older threads[0][1] about exactly this kind of issue. Could it be a loading issue where your class isn't actually getting loaded? [0] https://groups.google.com/d/topic/puppet-dev/bWMaEHZIBNg/discussion [1] https://groups.google.com/forum/#!topic/puppet-users/7e2modoyywA -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Python yaml help
On Wed, 12 Oct 2011 17:13:36 -0400, Mohamed Lrhazi wrote: On Wed, Oct 12, 2011 at 5:04 PM, Jacob Helwig ja...@puppetlabs.com wrote: On Wed, 12 Oct 2011 11:01:28 -0400, Mohamed Lrhazi wrote: Sorry for being off topic. am trying the following and yaml fails to construct the object: The inventory document, from Puppet dashboard inventory service, looks like: --- !ruby/object:Puppet::Node::Facts name: pirates.uis.example.com values: productname: VMware Virtual Platform kernelmajversion: 2.6 My code: class PuppetFacts(yaml.YAMLObject): yaml_tag = u'!ruby/object:Puppet::Node::Facts' def __init__(self, name, values): self.name = name self.values = values The attempt to load the doc results in: ConstructorError: could not determine a constructor for the tag '!ruby/object:Puppet::Node::Facts' in byte string, line 1, column 5 Thanks a lot, Mohamed. Hm. Looks like you're doing exactly what was suggested in a couple of older threads[0][1] about exactly this kind of issue. Could it be a loading issue where your class isn't actually getting loaded? [0] https://groups.google.com/d/topic/puppet-dev/bWMaEHZIBNg/discussion [1] https://groups.google.com/forum/#!topic/puppet-users/7e2modoyywA -- Jacob Helwig It does sound like it... am have not used the python yaml lib before... Here is an entire script reproducing the issue: http://paste.ubuntu.com/706994/ Thanks a lot, Mohamed. With everything in the same file, it shouldn't be the kind of loading issue I was thinking about. It's been so long since I've done any Python that I don't think I'll be much help. Hopefully someone with Python skills sharper than my extremely rusty ones will chime in. -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] file server not right directory?
On Wed, 12 Oct 2011 14:33:47 -0700, John Bower wrote:
Hello,
I'm trying to share a file between the client and the server.
On the server the file is located at: /etc/puppet/modules/mysql-server/
files/my.cnf
the code that references to this file is as follows:
file { /etc/mysql/my.cnf:
source = puppet:///modules/mysql-server/my.cnf,
owner = mysql, group = mysql,
mode = 644,
notify = Service[mysql],
}
Essentially, I want the client to store the my.cnf file to /etc/mysq/
my.cnf
However i keep getting this error:
err: /Stage[main]/Mysql-server/File[/etc/mysql/my.cnf]/ensure: change
from absent to file failed: Could not set 'file on ensure: No such
file or directory - /etc/mysql/my.cnf.puppettmp_9888 at /etc/puppet/
modules/mysql-server/manifests/init.pp:15
i tried setting source = puppet:///modules/mysql-server/files/
my.cnf,
But that did not make a difference. Please help.
Does /etc/mysql exist on the client machine?
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] file server not right directory?
On Wed, 12 Oct 2011 17:49:20 -0400, olympus stance wrote:
Hi Jacob,
My init.pp file is a symbolic link to the mysql-server.pp in the classes
directory. It looks like this:
---
class mysql-server {
package { mysql-server: ensure = installed }
package { mysql-client: ensure = installed }
service { mysql:
enable = false,
require = Package[mysql-server],
}
file { /etc/mysql/my.cnf:
source = puppet:///modules/mysql-server/my.cnf,
owner = mysql, group = mysql,
mode = 644,
notify = Service[mysql],
}
exec { run-mysqld:
path = [/bin, /usr/sbin],
command = /usr/sbin/mysqld ,
}
exec { set-mysql-password:
path = [/bin, /usr/bin],
command = mysqladmin -uroot password secret,
}
exec { set-nagios-password:
path = [/bin, /usr/bin],
command = /usr/bin/mysql -u root -e \CREATE USER 'nagios'@'%'
IDENTIFIED BY 'secret';\,
}
}
---
It looks like it does indeed try to create the my.cnf file before mysql gets
installed. How can i rectify that
Thanks!!
You'll need to add a 'require = ...' to the /etc/mysql/my.cnf
file resource. Either to another file resource that creates /etc/mysql,
or to the mysql-server package resource.
File resources don't automatically create the parent directories of the
things they manage.
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] Issues switching over to using environments
The layout should look something more like this:
/etc/puppet/prod/modules/$module_name/files/generic_node/etc/ssh/sshd_config
With the source lines looking like:
puppet://lou1/modules/$module_name/generic_node/etc/ssh/sshd_config
If you wanted 'generic_node' to be the name of the module, then you'd
have the layout as
/etc/puppet/prod/modules/generic_node/files/etc/ssh/sshd_config
and the source line as
puppet://lou1/modules/generic_node/etc/ssh/sshd_config
--
Jacob Helwig
On Tue, 11 Oct 2011 15:26:16 -0400, Deven Phillips wrote:
Date: Tue, 11 Oct 2011 15:26:16 -0400
From: Deven Phillips deven.phill...@gmail.com
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] Issues switching over to using environments
Message-ID:
cajw+4nd2kwpgc5-mre1k23of_ym9equbaa+09xmukzkou-o...@mail.gmail.com
The manifest which calls this looks like:
file {/etc/ssh/sshd_config:
owner = root,
group = root,
mode= 0644,
ensure = present,
source =
puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config,
require = Package['openssh'],
notify = Service['ssh'],
}
And the current error on the agent node shows:
err: /Stage[main]/Secureshell/File[/etc/ssh/sshd_config]: Could not
evaluate: Could not retrieve information from environment production
source(s) puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config
at /etc/puppet/prod/manifests/classes/ssh.pp:55
TIA,
Deven
On Tue, Oct 11, 2011 at 3:23 PM, Deven Phillips
deven.phill...@gmail.com wrote:
Nope, that didn't seem to help the way I tried it... So, here's my layout:
/etc/puppet/
prod/
modules/
files/
generic_node/
etc/
ssh/
sshd_config
From a machine which is using production as it's environment, and
production points to prod/modules for it's modules; I still get
errors trying to get the sshd_config file.
TIA!!
Deven
signature.asc
Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-10-07
- Puppet should allow rubygems to deliver new functionality * #3910 - Server is not authoritative over client environment when specified in an ENC * #3534 - Dashboard should support ability to set variables as arrays in the ENC * #2247 - enablerepo and disablerepo for yum type -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Review of new type provider
On Tue, 20 Sep 2011 23:19:36 -0700, James Turnbull wrote: Jesse Peterson wrote: Hello, I'm new to both Ruby and Puppet. Puppet is fantastic - loving it so far. I created a new type provider (of parsed file type) for modifying newsyslog.conf files and am hoping some folks would be willing to review it to make sure there are no glaring mistakes or perhaps some shortcuts or language features I've missed since I'm new to both. Any input would be welcome. Either email directly or just comment on the gist if it gets to be off topic: https://gist.github.com/1230749 Looks okay to me - I'd recommend writing some tests for it - ParsedFile providers are notorious for subtle bugs and small changes causing odd effects. How often do new types/providers make it into the base system? Should one pursue that avenue (or perhaps the puppet modules project?). We're trying to keep the core lean and mean. So I'd recommend creating and adding a module to the Forge (http://forge.puppetlabs.com) with your new type and provider. Regards James I'd definitely recommend writing tests for it, as well. If you're looking for some examples of tests around parsed file based types, you might want to take a look at some of the work that was done to split out the mount type into two separate types[1]. The only tricky part of copying the test setup from the split mount types is that you'll need to have the puppet and facter source trees in addition to your new type's source tree, and make sure that it's available to ruby when you run the tests. I've been achieving this by running the tests with the following: RUBYLIB=`pwd`/../puppet/lib:`pwd`/../facter/lib rspec spec We should really go back and create a README with this info for the split mount type repo. [1] https://github.com/puppetlabs/puppetlabs-mount-providers -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Announcing a new committer, plans for adding committers, and new mailing list.
One of the things we're doing to try and increase the community involvement in developing, and guiding Puppet, Facter, and Puppet Dashboard is adding committers that fall under the category of people that don't work for Puppet Labs. Please welcome Stefan Schulte as our newest committer to Puppet! Stefan has consistently provided great feedback and work on both the implementation details, and higher-level design of many, many things both on the mailing lists, and in the Redmine ticketing system. We're very happy that he has decided to become a committer for the open source projects. We plan on increasing the number of people that don't work for Puppet Labs committers as time progresses (hopefully they'll end up the majority), but this will be a little slow to happen at first, since we're not currently setup to add very many new committers and get them all up to speed very quickly. As the committer pool increases, this should be less and less of an issue, and we should be able to better accommodate making sure new committers get any support they need. In addition to reviewing and commenting on code (which we encourage everyone to do, whether or not they are a committer), committers are able to merge the code that they have reviewed into the official repositories. All committers (including those employed by Puppet Labs) are still required to submit their own code as a pull request to have it reviewed and merged by another committer. In addition to adding Stefan as a committer to the open source projects, we've also setup a puppet-ci Google Group[1]. This group is setup to receive the test-suite notifications from out Jenkins instance[2]. I imagine that this list will mainly be of interest to committers, but anyone is welcome to subscribe and post to this list. [1] https://groups.google.com/group/puppet-ci [2] https://jenkins.puppetlabs.com -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-09-19
Getting setting permissions on Windows now works (#9186). For full details on how this works, please see the commit that introduces the functionality[1]. Patch provided by Josh Cooper. This has been merged into the 2.7.x branch. Pluginsync will now only load Ruby files (#4135). Pluginsync will still sync all files, but will only attempt to load files ending in '.rb'. Patch provided by Nan Liu. This is particularly notable since this was the first merge from Stefan Schulte, our newest committer (there will be a separate annoucement about this and a few other details in the very near future). This has been merged into the 2.7.x branch. puppet device now resets all cached attributes (#7982). Since not ppall caches were being reset appropriately, there was some odd behavior such as the wrong SSL certificate being used for a device. Patch provided by Brice Figureau. This has been merged into the 2.7.x branch. - is now allowed in device certificate names (#9164). Patch provided by Brice Figureau. This has been merged into the 2.7.x branch. [1] https://github.com/puppetlabs/puppet/commit/42c998233ba188d94f4b903f802f075ffe87f0d6 Completed items: * #9186 - Windows file security support * #4135 - pluginsync tries to parse readme files * #7982 - puppet device fails on second device * #9164 - The certname in /etc/puppet/device.conf may not include a - Current backlog: * #9329 - (Review) Puppet agent daemonize option doesn't work on Windows * #9435 - (Review) Log destinations are broken on Windows * #9458 - (Review) Puppet fails to run when no subcommand specified * #9459 - (Review) Puppet fails to create user when groups are specified * #9326 - (Review) Password management on windows * #8414 - Task scheduler type/provider for Windows * #8411 - File type working on Windows * #9460 - Puppet agent fails if the PuppetLabs/puppet directory doesn't exist on Windows * #9461 - Puppet resource package fails on Windows * #9328 - Retrieve user and group SIDs on windows * #9190 - Windows documentation * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - Overriding parameters on included inherited classes * #3741 - Custom facts loaded multiple times * #4916 - Plugins should not be able to override core functionality. -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-09-12
install.rb now provides a more helpful error message when the
win32-dir gem is missing (#9174). The sys-admin, win32-process,
win32-dir, and win32-service gems are required to run Puppet on
Windows, and win32-dir is required for install.rb. This was merged
into the 2.7.x branch.
MSI packages can now be installed and managed on Windows (#8412).
In addition to installing via MSI files, any parameters that would
have been specified on the command-line to msiexec.exe can be
specified in an install_options hash on the package resource. For
example:
package { 'mysql':
provider = msi,
source = 'E:\mysql.msi',
ensure = installed,
install_options = { 'INSTALLDIR' = 'C:\mysql' },
}
This was merged into the 2.7.x branch.
Places that were hard coded to use ':' as a path separator have been
updated to use File::PATH_SEPARATOR (#8489). By using
File::PATH_SEPARATOR Windows is now properly handled, since its
default path separator is ';'. This was merged into the 2.7.x branch.
Checking for elevated privileges on Windows now better handles the
differences between Windows 2003, 2003 R2, and 2008 (#8662).
Previously the error message from the API call was used to determine
if UAC was supported, or if we were not running with elevated
privileges. This updates the code to only use the API call on
platforms where it is expected to fail due to non-elevated privileges.
This was merged into the 2.7.x branch.
Windows will now properly clean up its PID file (#8413). Windows will
raise a different exception if the PID in question is not found, and
this is now also looked for if the exception class is defined. This
was merged into the 2.7.x branch.
Facter fact support has been fleshed out on Windows (#8439). This
includes updates to the macaddress, ps, ipaddress6, processor
information, and interface-specific IP facts. This was merged into
the master branch of Facter.
Completed items:
* #9174 - Improve puppet installer error message on Windows
* #8412 - MSI package provider for Windows
* #8489 - Puppet does not consistently use File::PATH_SEPARATOR
* #8662 - Puppet.features.root? always returns true on Windows
* #8413 - Ability to run Puppet as an agent on Windows
* #8439 - Basic facter on Windows
Current backlog:
* #8414 - Task scheduler type/provider for Windows
* #8411 - File type working on Windows
* #9186 - Windows file security support
* #9189 - File provider on Windows
* #7316 - puppet applications delivered via pluginsync don't work.
* #5517 - Overriding parameters on included inherited classes
* #3741 - Custom facts loaded multiple times
* #4916 - Plugins should not be able to override core functionality.
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
Re: [Puppet Users] Using Puppet to reset admin passwords on Windows
On Wed, 07 Sep 2011 13:54:53 -0700, M. Hand wrote: Please bare with me as I have VERY limited experience with this: I need to find a way to be able to reset administrator passwords on our network. Most of our network is Linux, however we are looking into the Windows side. Any help would be appreciated. Puppet only recently gained the ability to manage local users (though not yet passwords) on Windows, though it's only in the latest development versions of 2.7.x. We're planning on adding support for managing passwords for local users, though we're still looking for a good way to do this that doesn't require specifying the password in plain-text in the Puppet manifest. -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] What came first, the user or the group?
On Thu, 01 Sep 2011 12:14:51 -0400, Guy Matz wrote: Hi, I have inherited some code to create users that doesn't work when removing users . . . it's listed below. It works for adding users, but when it comes to removing users I get: err: /Stage[main]/Common/Common::Mkuser[oshi.apen]/Group[oshi.apen]/ensure: change from present to absent failed: Could not delete group oshi.apen: Execution of '/usr/sbin/groupdel oshi.apen' returned 8: groupdel: cannot remove the primary group of user 'oshi.apen' User requires the Group to be defined, which, again, works for adding users, but not removing. My instinct is to have a condition test for remove/add and set the dependencies from there, but that seems klunky and inelegant. Anyone have any better code for adding/removing users? A suggestion? Thanks a lot, Guy Don't really have anything to help you directly right now, but this kind of problem isn't just limited to users groups, though it's certainly the most common. The problem is that Puppet really only has one way to specify a dependency (resource A must come before resource B). We do have plans to address this, but it's a little ways off (months, not years). The idea is to add above below style relationships (think building blocks). When applying resources that are building/creating you need to go from the bottom up, and when applying resources that are destroying/removing, you need to go from the top down. It's currently listed as the Above/below relationships item in the Open Source Team's roadmap[1]. [1] http://projects.puppetlabs.com/projects/puppet/wiki/Road_map -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-08-26
Puppet.features.root? will now correctly report whether Puppet is running with elevated administrative privileges on Windows, instead of always returning true (#8662). Management of permissions and ownership of Puppet's internal files was also disabled as part of this change until the general problem of managing file ownership, and permissions has been addressed. This has been merged into the 2.7.x branch, and should be available in the next 2.7.x release after 2.7.3. The exec type now works on Windows (#8410). This also includes some refactoring around how Puppet determines whether a path is absolute or not, which is a step towards a larger refactor in this area. This has been merged into the 2.7.x branch, and should be available in the next 2.7.x release after 2.7.3. Jeff Blane provided a fix for a debug message (01df2375), which has been merged into the master branch, and will be available in Telly. Completed items: * #8662 - Puppet.features.root? always returns true on Windows * #8410 - Exec provider for Windows * Remove spurious exec from a debug string Current backlog: * #8439 - Basic facter on Windows * #8414 - Task scheduler type/provider for Windows * #8411 - File type working on Windows * #9186 - Windows file security support * #9189 - File provider on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - Overriding parameters on included inherited classes * #3741 - Custom facts loaded multiple times * #4916 - Plugins should not be able to override core functionality. -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Circular RPM dependencies...
On Tue, 23 Aug 2011 12:05:30 +0200, Jakov Sosic wrote:
On 08/22/2011 06:29 PM, Mike Lococo wrote:
This is a long-standing bug, and one that I consider fairly major but
has been hard to get puppetlabs focused on.
- The circular deps bug was reported 2 years ago.
http://projects.puppetlabs.com/issues/1935
- A few months later a patch is submitted to batch rpm transactions.
This solves the circular-deps issue and also has significant
performance benefits during puppet runs with many package installs.
http://projects.puppetlabs.com/issues/2198
This comes up periodically and inevitably someone proposes that the
architecturally correct solution is for RedHat not to employ circular
deps, which shuts down discussion of a potential solution for another
3-6 months:
http://groups.google.com/group/puppet-users/browse_thread/thread/8a083899386909d5/
http://groups.google.com/group/puppet-users/browse_thread/thread/9cbeadad62741b0a/
I could incorporate that patch into RPM's... ensure = purged is
obviously not a good idea after all (although it works).
I have another question about packages...
What if I define something like this:
package {'httpd': ensure = absent, }
package {'mod_ssl': ensure = latest, }
It is obvious that httpd is a dependency of mod_ssl. What will happen in
this case?!
I'm asking because I have a template for all my machines with minimal
package requirements, and I do that with lots of ensure=absent.
But if some package requires some of the absent pacakges, what happens
then?
I would expect Puppet to end up installing and uninstalling packages
every run, since it has no knowledge of the package dependencies.
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
Re: [Puppet Users] dashboard 1.1.1 with filebucket doesn't show contents of the new file
On Sun, 21 Aug 2011 08:39:31 -0700, Stefan Heijmans wrote:
Am using dashboard 1.1.1 with the use_file_bucket_diffs option.
When clicking on the links within a report it will show the old md5
file (on the left) but not the new md5 file (on the right)
like;
content content changed '{md5}26a3112822d01f2ce6b3f052bf2809de' to
'{md5}dd97364ab0559344d73231f517951595'
26a3112822d01f2ce6b3f052bf2809de == is displayed normally
dd97364ab0559344d73231f517951595 == We're sorry, but something went
wrong.
puppet-dashboard log shows;
Processing FilesController#show (for 192.168.20.20 at 2011-08-21
17:37:49) [GET]
Parameters: {action=show, controller=files,
file=26a3112822d01f2ce6b3f052bf2809de}
Completed in 22ms (View: 0, DB: 0) | 200 OK [http://192.168.20.100/
files/show?file=26a3112822d01f2ce6b3f052bf2809de]
Processing FilesController#show (for 192.168.20.20 at 2011-08-21
17:37:52) [GET]
Parameters: {action=show, controller=files,
file=dd97364ab0559344d73231f517951595}
Net::HTTPServerException (404 Not Found):
/usr/lib/ruby/1.8/net/http.rb:2097:in `error!'
lib/puppet_https.rb:34:in `get'
app/controllers/files_controller.rb:23:in `show'
haml (3.0.13) [v] rails/./lib/sass/plugin/rack.rb:41:in `call'
passenger (3.0.8) lib/phusion_passenger/rack/request_handler.rb:
96:in `process_request'
passenger (3.0.8) lib/phusion_passenger/abstract_request_handler.rb:
513:in `accept_and_process_next_request'
passenger (3.0.8) lib/phusion_passenger/abstract_request_handler.rb:
274:in `main_loop'
passenger (3.0.8) lib/phusion_passenger/classic_rails/
application_spawner.rb:321:in `start_request_handler'
passenger (3.0.8) lib/phusion_passenger/classic_rails/
application_spawner.rb:275:in `send'
passenger (3.0.8) lib/phusion_passenger/classic_rails/
application_spawner.rb:275:in `handle_spawn_application'
passenger (3.0.8) lib/phusion_passenger/utils.rb:479:in `safe_fork'
passenger (3.0.8) lib/phusion_passenger/classic_rails/
application_spawner.rb:270:in `handle_spawn_application'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:357:in
`__send__'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:357:in
`server_main_loop'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:206:in
`start_synchronously'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:180:in
`start'
passenger (3.0.8) lib/phusion_passenger/classic_rails/
application_spawner.rb:149:in `start'
passenger (3.0.8) lib/phusion_passenger/spawn_manager.rb:219:in
`spawn_rails_application'
passenger (3.0.8) lib/phusion_passenger/
abstract_server_collection.rb:132:in `lookup_or_add'
passenger (3.0.8) lib/phusion_passenger/spawn_manager.rb:214:in
`spawn_rails_application'
passenger (3.0.8) lib/phusion_passenger/
abstract_server_collection.rb:82:in `synchronize'
passenger (3.0.8) lib/phusion_passenger/
abstract_server_collection.rb:79:in `synchronize'
passenger (3.0.8) lib/phusion_passenger/spawn_manager.rb:213:in
`spawn_rails_application'
passenger (3.0.8) lib/phusion_passenger/spawn_manager.rb:132:in
`spawn_application'
passenger (3.0.8) lib/phusion_passenger/spawn_manager.rb:275:in
`handle_spawn_application'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:357:in
`__send__'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:357:in
`server_main_loop'
passenger (3.0.8) lib/phusion_passenger/abstract_server.rb:206:in
`start_synchronously'
passenger (3.0.8) helper-scripts/passenger-spawn-server:99
Rendering /usr/share/puppet-dashboard/public/500.html (500 Internal
Server Error)
Is this because the new file is not in the filebucket yet?
any ideas anyone?
Stefan
You are correct: It is because the new file is not yet in the
filebucket. With what is currently the most common usage of Puppet
Dashboard, the new files will never be in the filebucket.
You might want to have a look at #7934[1], which is a ticket around
this. The new file's md5 will no longer be linked once this gets
released.
[1] https://projects.puppetlabs.com/issues/7934
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-08-19
We ended up addressing a number of order dependent test failures in both the 2.7.x, and master branches. The Augeas command documentation has been updated to clarify existing commands, and add documentation for new commands (#9039). This patch was provided by Dominic Cleal. This has been merged into the 2.7.x and master branches, and will be included in the next 2.7 release after the current RC, as well as Telly. We have also finished porting the work done so far on supporting Windows to the 2.7.x branch. We also pulled a number of Rails security updates into Puppet Dashboard[1]. Completed items: * #9039 - Augeas commands documentation out of date * Pull Windows work into 2.7.x * Rails security updates for Puppet Dashboard Current backlog: * #8439 - Basic facter on Windows * #8414 - Task scheduler type/provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - Overriding parameters on included inherited classes [1] https://github.com/puppetlabs/puppet-dashboard/pull/16 -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] ANNOUNCE: Puppet 2.7.3
It's not just you. Unfortunately, it's down right now. Seems to be a
hosting issue, so hopefully they'll get things sorted out quickly.
On Tue, Aug 16, 2011 at 16:16, David L Ballenger
d...@davidlballenger.comwrote:
Okay, I'll file a bug report on this later today. I seem to be having
problems contacting the bug tracker right now.
On Aug 16, 2011, at 4:08 PM, Nigel Kersten wrote:
On Tue, Aug 16, 2011 at 4:00 PM, David L Ballenger
d...@davidlballenger.com wrote:
On Aug 16, 2011, at 10:48 AM, Nigel Kersten wrote:
On Mon, Aug 15, 2011 at 6:22 PM, David L Ballenger
d...@davidlballenger.com wrote:
Since upgrading for Puppet 2.7.1 to 2.7.3 I have been getting the
following error whenever a Puppet agent runs:
err: Failed to apply catalog: Parameter options failed: Options must be
provided as an array, not a comma separated list
Can you generate a catalog with the older version and the newer and
compare them?
Does --debug --trace add any more info ?
Thanks for the suggestion about --trace, I didn't see that in the puppet
help info.
With --trace on I got:
/Library/Ruby/Gems/1.8/gems/puppet-2.7.3/lib/puppet/type/ssh_authorized_key.rb:95:in
`unsafe_validate'
..
followed by more trace info. So it looks like I am having an issue with
the ssh_authorized_key option parameter. When I looked at the line
specified in the trace I found:
validate do |value|
raise Puppet::Error, Options must be provided as an array, not a comma
separated list if value != :absent and
value.include?(',')
end
I think the value.Include?(',') is a little too inclusive. It is
catching a comma within a string that is part of a from option for the
ssh_authorized_key to limit the systems from which the key will allow
connections. For example:
from=\a.b.com,x.y.org\
I also tried 'from=a.b.com,x.y.org' with the same results.
This was working in 2.7.1.
Ugh. I can't see an obvious test to distinguish this from a comma-separated
string. Maybe if an = exists as well? I wonder what other options would
pass/fail that test
We definitely have enough for a bug report here if you wouldn't mind filing
one, and we may have to abandon whatever it was that led us to have to
implement that check.
--
Nigel Kersten
Product Manager, Puppet Labs
*Join us for **PuppetConf *
http://www.bit.ly/puppetconfsig
Sept 22/23 Portland, Oregon, USA.
*
*
--
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] Open Source Team iteration planning summary 2011-08-14
Augeas resources will now fail when they are unable to save their changes (#8808). This patch was provided by Dominic Cleal, and fixes a regression. This has been merged into the 2.7.x, and master branches, and will be included in the next 2.7 release after the current RC, as well as Telly. Windows now has providers for the user, and group types for managing local users and groups. This has been merged into the master branch, and will be available in Telly. The content of /augeas//error is now included when running puppet with the --debug flag (#5606). This should reduce the need to replicate what the puppet run was doing by running augtool directly. This patch was provided by Dominic Cleal. This has been merged into the master branch, and will be available in Telly. fqnd_rand now works with Ruby 1.9.2 (#8814). This patch was provided by Nan Liu. It has been merged into the master branch, and will be available in Telly. 'puppet resource file' will no longer throw an exception with things other than regular files, directories, or links in the root of the filesystem (#8740). This has been merged into the 2.6.x branch, and will be available in the next 2.6 release. Puppet now correctly drops privileges on Mac OS X (#8770). This has been merged into the 2.6.x branch, and will be available in the next 2.6 release. Completed items: * #8808 - No error when an Augeas resource cannot be saved * #5606 - augeas needs more detailed error printing * #8814 - fqdn_rand() causes can't convert String into Integer error * #8770 - Puppetmaster does not drop privileges on Mac OS X * #8740 - Puppet resource file is broken * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows Current backlog: * #8439 - Basic facter on Windows * #8414 - Task scheduler type/provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - Overriding parameters on included inherited classes -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Upgrading 0.25.5 to 2.7.1
On Wed, 27 Jul 2011 13:58:25 -0700, Douglas Garstang wrote: All, I'm upgrading puppet clients from 0.25.5 to 2.7.1. I've rolled an RPM for the new version, and I'm: 1. Stopping puppet 2. Upgrading RPM 3. Change the puppet master on the client to point to a new puppet master running 2.7.1. 3. Starting puppet I am seeing this in the log files on the client: Could not evaluate: certificate verify failed Could not retrieve file metadata for puppet://hprov01.h.xxx.com/plugins: certificate verify failed Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not retrieve catalog from remote server: certificate verify failed Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Using cached catalog Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not send report: certificate verify failed Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not run Puppet configuration client: interning empty string After stopping puppet again, removing /var/lib/puppet/ssl and restarting puppet, all is ok. Why do I need to blow away the client side certs? I recently upgraded 0.25.5 to 2.6.8, and I don't believe I had to do this. I have a couple of hundred servers to upgrade, and I don't want to have to remove all the client side ssl directories as part of the upgrade process. Doug. It sounds like you have a new server with 2.7.1, in addition to your old server. Did you copy over the master certificates to the new 2.7.1 master from the old one? If the new 2.7.1 master had generated a new certificate, I would expect to get the errors you're seeing. -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-07-27
We completed a refactor of the places using Puppet::Util::Cacher, which resulted in a net deletion of 360 lines of code, simplified the interaction between several areas of the code base, and removed some of the inconsistent cacher behavior we were seeing on Windows. This is slated for Telly. We merged in a change from Ben Hughes (#6857) to bring failed, and --noop password change messages in line with successful change messages in regards to information leaking. We now no longer display the pasword hashes used, and instead output '[old password hash redacted]' or '[new password hash redacted]'. This is slated for 2.6.10, 2.7.3, and Telly. install.rb wasn't properly generating the puppet.bat wrapper script for Windows from the internal template. We now regex escape the discovered paths we will be substituting into the template, so that paths like 'C:\Ruby\187' will work properly. This is slated for Telly. We have merged in the service provider for Windows. This adds a new 'enabled' value of 'manual' which is only available on Windows. This provider uses the simple service name, to refer to services. The provider is able to start a service that is set to disabled before the puppet run, but the behavior depends on what 'ensure', and 'enable' are set to in the manifest. Please see update 6[1] on #8272 for the full details around this. This is slated for Telly. We have merged in a fix for #8596, which now prevents accidentally managing the same file on disk by having different resource titles (though not strictly limited to the file type). We have merged in a patch series from Brice Figureau which addresses #5777, #5010, and #6026. This means that that the following will now work in the auth.conf, namespaceauth.conf, and fileserver.conf files: CIDR notation, leading and trailing whitespace, and comments at the end of a line. This is slated for 2.7.3, and Telly. Completed items: * #6857 - Password disclosure when changing a user's password (Planned for: 2.6.10, 2.7.3, Telly) * #8272 - Windows Services Management (Planned for: Telly) * #8596 - Title and name must be unique within a given resource. (Planned for: 2.6.10, 2.7.3, Telly) * #5777 - It would be nice if auth.conf supported subnets (Planned for: 2.7.3, Telly) * #5010 - Trailing whitespace is not allowed in auth.conf files (Planned for: 2.7.3, Telly) * #6026 - Config files don't allow for comments at the end of a line anymore (Planned for: 2.7.3, Telly) Current backlog: * Disable tests exclusive to master functionality on Windows * All Puppet tests passing on Windows * #8322 - Facter should return as much info as Windows SystemInfo * #8414 - Task scheduler type/provider for Windows * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows [1] http://projects.puppetlabs.com/issues/8272#note-6 -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Puppet/facter and update reporting
On Fri, 22 Jul 2011 19:28:37 -0700, Khoury wrote: Hi All, Does anyone have any experience with debian/ubuntu and or OS X with regard to reporting on updates? I'm interested in getting update (specifically security) states for compliance (SOX, PCI, etc) purposes. I know there's spacewalk for things like this, but I'm kind of hoping to avoid going the centos/redhat route for my servers. I'm thinking of using unattended-upgrade --debug --dry-run on Debian/ Ubuntu and maybe softwareupdate on OS X to build custom facts. Thanks in advance. Best, Khoury Sounds like you want the collection functionality that you get with MCollective. I'm afraid I haven't played around with it as much as I'd like, but I'm sure others can chime in with details. -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] So, what happened to the old Open Source Team backlog anyway?
Well, I can definitely let you know that. I apologize. It seems I didn't explain what was going on well enough when I sent out the Open Source Team update for 2011-07-06. The items that were on our back log still are. They've just been bumped behind the basic Windows agent support we're currently focusing on. I haven't been listing them with the other things we've been focusing on in an effort to keep the update messages from getting overly long. The full backlog (old one starts at #7316): * Disable tests exclusive to master functionality on Windows * All Puppet tests passing on Windows * #8322 - Facter should return as much info as Windows SystemInfo * #8272 - Windows Services Management * #8414 - Task scheduler type/provider for Windows * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - behavior change within 2.6 makes it impossible to override class parameters of included parametrized classes * #3741 - Custom facts loaded multiple times * #3669 - Make puppet honor DNS SRV records * #4916 - Plugins should not be able to override core functionality. * #7788 - Puppet should allow rubygems to deliver new functionality * #3910 - Server is not authoritative over client environment when specified in an ENC * #2247 - enablerepo and disablerepo for yum type * #3534 - Dashboard should support ability to set variables as arrays in the ENC -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-07-20
We currently have the majority of the tests passing, marked as known failures due to missing providers or other yet unwritten code, or confined to not run on windows since they are testing functionality that we do not plan to support (running a master, for example). We've got a Work in Progress branch with a service provider for Windows that supports managing the Start Type (enabled), and whether the service is currently running (ensure) up on GitHub[1]. Currently, the provider does not work when transitioning a service from stopped with a start type of disabled to running with a start type of automatic, or manual. The problem is that the ResourceHarness always syncs ensure first, before syncing everything else, and Windows (understandably) refuses to start a disabled service. Stalled items: * #8341 - Puppet loading facts repeatedly Completed items: * #8301 - Red Hat Spec file in 2.7.2rc1 isn't quite right Current backlog: * Disable tests exclusive to master functionality on Windows * All Puppet tests passing on Windows * #8322 - Facter should return as much info as Windows SystemInfo * #8272 - Windows Services Management * #8414 - Task scheduler type/provider for Windows * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows [1] https://github.com/ChaseMotorman/puppet/tree/win32-discovery -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] tolower()??
On Thu, 21 Jul 2011 16:10:02 -0400, David Kavanagh wrote:
I need to convert a value from facter to lower case for inclusion in a
path. Is there a built-in function for that?
David
Hm...doesn't actually look like there is.
% ls -1 lib/puppet/parser/functions
create_resources.rb
defined.rb
extlookup.rb
fail.rb
file.rb
fqdn_rand.rb
generate.rb
include.rb
inline_template.rb
md5.rb
realize.rb
regsubst.rb
require.rb
search.rb
sha1.rb
shellquote.rb
split.rb
sprintf.rb
tagged.rb
tag.rb
template.rb
versioncmp.rb
It would be pretty easy to add a custom function that does this (and we
really should have to_lower, and to_upper functions that are available
out of the box).
In the meantime, you should be able to do this with something like
(replacing upcase with downcase):
file { /tmp/bar:
ensure = file,
content = inline_template(%= hostname.upcase %)
}
This was only tested against the current master branch of Puppet, so
your mileage may vary.
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
Re: [Puppet Users] tolower()??
On Thu, 21 Jul 2011 16:31:39 -0400, Nan Liu wrote: On Thu, Jul 21, 2011 at 4:10 PM, David Kavanagh dkavan...@gmail.com wrote: I need to convert a value from facter to lower case for inclusion in a path. Is there a built-in function for that? Not builtin, but you can use this: https://github.com/puppetlabs/puppetlabs-functions/blob/master/lib/puppet/parser/functions/downcase.rb Nan So, why don't we have downcase in core Puppet? :-\ -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Re: Puppet 2.6.x fate
On Thu, 14 Jul 2011 09:53:36 -0700, PBWebGuy wrote: Hi Mike, I wanted to comment on bug http://projects.puppetlabs.com/issues/7680 which is a regression introduced in 2.6.8. I recently ran into this issue and had to downgrade to 2.6.7 from 2.6.8. When I discovered the issue I tried upgrading to 2.6.9 and it was still an issue. The problem is simply that if the source points to a symlinked file, the md5 calculation fails. This bug has prevented me from moving forward and would love to see it get fixed. I wanted to vote on the bug but I have not figured out how to get some level of access to the bug tracking system. I also have a few other bugs that I would like to report but the process is not clearly documented. Thanks, John You should be able to vote on the issue once you've logged in. It shouldn't require any special permissions. I'm guessing you've already created an account on the Redmine instance[1]? As far as reporting other bugs: Once you've logged in, you should be able to click the New Issue link[2] when you're viewing the appropriate project. There isn't really much process around it. We appreciate if you check for a pre-existing ticket before filing a new one, but it's not like we'll get angry if you don't spot that it's duplicate. [1] https://projects.puppetlabs.com/account/register [2] https://projects.puppetlabs.com/projects/puppet/issues/new -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-07-13
We've made some good progress on getting Facter Puppet running on Windows. Currently, we have Facter installable and running through install.rb, with all tests passing on Windows Server 2008 R2. We also have Puppet installable through install.rb, and are currently working on getting the code and tests to a passing state. We have explicitly disabled running the master under Windows with an appropriate message stating that it is not supported. We may re-visit this at some point, but for now we're just concerned with getting puppet agent, and puppet apply working on Windows. We've been adding sub-tasks to the meta-ticket (#8268). If you're following along at home, please feel free to bring up any issues you may find on the parent, or any of the appropriate sub-tickets. Completed backlog items: * Explicitly disable master on Windows. * Facter installs on Windows * Facter tests passing on Windows * Puppet installs on Windows * #8356 - Default value of :color should be false on Windows * #7581 - Provide more detailed error message when missing gems on Windows Current backlog: * #8341 - Puppet loading facts repeatedly * Disable tests exclusive to master functionality on Windows * All Puppet tests passing on Windows * #8322 - Facter should return as much info as Windows SystemInfo * #8272 - Windows Services Management * #8414 - Task scheduler type/provider for Windows * #8301 - Red Hat Spec file in 2.7.2rc1 isn't quite right * #8408 - Local user provider for Windows * #8409 - Local group provider for Windows * #8410 - Exec provider for Windows * #8411 - File type working on Windows * #8412 - MSI package provider for Windows * #8413 - Ability to run Puppet as an agent on Windows -- Jacob Helwig , | Join us for PuppetConf, September 22nd and 23rd in Portland, OR | http://bit.ly/puppetconfsig ` signature.asc Description: Digital signature
Re: [Puppet Users] Re: all classes applied to every node
Zach zachary.g.armstr...@gmail.com wrote:
You guys got me on the right track... Turns out I was running into
this:
One of THE MOST DIFFICULT concepts to understand for puppet newbies
is that these two things are identical:
include foo
class { 'foo': }
In my case, I was declaring things like:
class { nagios::webserver:stage = post }
at the very top of the site.pp
Is there a better way to declare what stage a class belongs to within
the class declaration itself?
Right now, I am doing something like this:
node webserver01...12 inherits default {
class { nagios::webserver:stage = post }
include apache::apache_security
include apache::php_security
include apache::apache_conf_webserver
}
It's pretty ugly to have to keep declaring the stage in every node
group (I have webservers, app servers, etc)
On Jul 12, 9:21 am, jcbollinger john.bollin...@stjude.org wrote:
On Jul 11, 10:52 am, Zach zachary.g.armstr...@gmail.com wrote:
Hi all,
I'm noticing that all classes I have created are being applied to
every node, even ones that don't specifically include them. There
is no inheritance occurring that would allow this to happen. I've
been reading docs and couldn't find anything about this... Am I
missing something obvious? Let me know if you need more info
The problem is far more likely to be in your manifests than to be in
Puppet, but without seeing the manifests we can only speculate. My
best guess is that you have top-level include statements in one or
more of your manifests, perhaps where you meant import instead. It
may also be that some of your classes are including others, with the
result that all classes get pulled in even though some are not
explicitly included at node level.
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.
You should be able to set the default stage just like any other parameter.
Jesse and I fixed that a while back. Forget which version it's fixed in though.
--
Sent from my phone. Please excuse my brevity.
--
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] Possible bug? Can't remove and then put back a file?
On Tue, 12 Jul 2011 08:41:24 -0700, Haitao Jiang wrote:
This happens to Puppet 2.7.1 (both master and client). I have a file
resource that I set to ensure = absent, Puppet removed it correctly
with info line that it has a duplicate entry in the filebucket. I then
changed the ensure = present, the agent run gave me following error:
/usr/bin/puppet:19
err:
/Stage[main]/Emb/File[/opt/jetty-distribution-7.4.2.v20110526.tar.gz]/ensure:
change from absent to file failed: Could not rename temporary file
/opt/jetty-distribution-7.4.2.v20110526.tar.gz.puppettmp_7809 to
/opt/jetty-distribution-7.4.2.v20110526.tar.gz: File written to disk
did not match checksum; discarding changes
({md5lite}3dc95fb231fdabbe161d8773e2a10457 vs
{md5lite}a3f7372d40abae273d2680b650ca4715) at
/etc/puppet/modules/emb/manifests/init.pp:38 at
/etc/puppet/modules/emb/manifests/init.pp:38
I have
file { /opt/jetty-distribution-7.4.2.v20110526.tar.gz:
ensure = present,
checksum = md5lite,
source = puppet:///emb/jetty-distribution-7.4.2.v20110526.tar.gz,
}
Is this a bug?
Thanks
Haitao
There certainly shouldn't be any problem with going from ensuring absent
to ensuring present. Not sure if it's a bug though, since that kind of
behavior could also be caused by problems with the filesystem on the
agent.
If you have direct access to the
jetty-distribution-7.4.2.v20110526.tar.gz from your emb module, could
you run the following ruby script to get what its md5lite checksum is?
#!/usr/bin/env ruby
require 'digest/md5'
path_to_jetty_distribution = 'jetty-distribution-7.4.2.v20110526.tar.gz'
puts Digest::MD5.hexdigest(File.read(path_to_jetty_distribution)[0..511])
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] Possible bug? Can't remove and then put back a file?
Well, it turns out that it's definitely a puppet bug.
The streaming checksumming that's used doesn't actually only look at the
first 512 characters like the static checksumming that's used for
verifying the file on disk does.
http://projects.puppetlabs.com/issues/8385
--
Jacob Helwig
On Tue, 12 Jul 2011 11:04:09 -0700, Haitao Jiang wrote:
Jacob
Thanks. I did that, the checksum is a3f7372d40abae273d2680b650ca4715.
This is the second checksum in the error, what did 1st checksum came
from? The file itself never changed during my tests.
What is the next step?
Thanks
Haitao
On Tue, Jul 12, 2011 at 9:53 AM, Jacob Helwig ja...@puppetlabs.com wrote:
On Tue, 12 Jul 2011 08:41:24 -0700, Haitao Jiang wrote:
This happens to Puppet 2.7.1 (both master and client). I have a file
resource that I set to ensure = absent, Puppet removed it correctly
with info line that it has a duplicate entry in the filebucket. I then
changed the ensure = present, the agent run gave me following error:
/usr/bin/puppet:19
err:
/Stage[main]/Emb/File[/opt/jetty-distribution-7.4.2.v20110526.tar.gz]/ensure:
change from absent to file failed: Could not rename temporary file
/opt/jetty-distribution-7.4.2.v20110526.tar.gz.puppettmp_7809 to
/opt/jetty-distribution-7.4.2.v20110526.tar.gz: File written to disk
did not match checksum; discarding changes
({md5lite}3dc95fb231fdabbe161d8773e2a10457 vs
{md5lite}a3f7372d40abae273d2680b650ca4715) at
/etc/puppet/modules/emb/manifests/init.pp:38 at
/etc/puppet/modules/emb/manifests/init.pp:38
I have
file { /opt/jetty-distribution-7.4.2.v20110526.tar.gz:
ensure = present,
checksum = md5lite,
source =
puppet:///emb/jetty-distribution-7.4.2.v20110526.tar.gz,
}
Is this a bug?
Thanks
Haitao
There certainly shouldn't be any problem with going from ensuring absent
to ensuring present. Not sure if it's a bug though, since that kind of
behavior could also be caused by problems with the filesystem on the
agent.
If you have direct access to the
jetty-distribution-7.4.2.v20110526.tar.gz from your emb module, could
you run the following ruby script to get what its md5lite checksum is?
#!/usr/bin/env ruby
require 'digest/md5'
path_to_jetty_distribution = 'jetty-distribution-7.4.2.v20110526.tar.gz'
puts Digest::MD5.hexdigest(File.read(path_to_jetty_distribution)[0..511])
--
Jacob Helwig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQGcBAEBAgAGBQJOHHwlAAoJEHJabXWGiqEBZqAMALH6/sBAGSJ5zOThN4fvDMKB
pbpHbb3sfA9796DKp+WndQxbM9oLi9RlB0fA3cOEmL4G7g+7W1QY+2q47fw19cTo
cfS3TbibB6PsVlLFSjLJz5nxkq/Rw1TUosPKZdgEr+E0A5Z65Y+vIy3TeJTd2bl9
tFXaNLQtgd5CrAdphwrA9VzGY86rthvUqhK8O7SaKoH81JiZL5ooJ7mXh96Ih52n
u6k6vue2g2s72PRtLxLMWQB0hC1I/j/JWr1TLzBQ+noJ5V+OG4P0BSRv+Azk43GI
pnlA0UjteMH80KVfQTcehdjrWutty9/uvvuFLEeP1o/7scE2llovwvGj55aAZSAr
d91N8U3mpguv3sWoH3QDdW52NE630zygU2mRgzjt20JA2qteDvKyvmvgt4rtA1TD
VGmesHOd8fo2Tfan8vzrQwd44KSdzw1797Snb9yxZ+Z5aGm7YeW5n884oF3s7Z7/
Aie5mPf8Qk0/vubfoSIoT9D9s8g9165CxnON+pE/dQ==
=Fp0N
-END PGP SIGNATURE-
signature.asc
Description: Digital signature
Re: [Puppet Users] Run this only once!!
On Tue, 12 Jul 2011 13:19:34 -0700, vella1tj wrote:
Hi, I am trying run a package once and when it completes I want my
manifest to create a touch file and from that file being placed there
it will not run again. I have this so far, but have been running into
syntax problems/invalid parameters.
#Package to install
package { 'Bindscript20100601.dmg':
provider= pkgdmg,
ensure = installed,
source = 'temp/location/rightnow/Bindscript20100601.dmg',
notify = [Exec['blahblah']],
onlyif = test -e /var/db/.bindscript,
}
exec {'blahblah':
command ='touch /var/db/.bindscript',
path=['/usr/bin']
}
If you need more information please ask.
Couple of things.
onlyif is only valid on exec resources.
This shouldn't actually be necessary. The pkgdmg provider should keep
track of which things it's installed, so it won't keep trying to install
the .dmg on every run.
Is the following resource definition not working for you?
package { 'Bindscript20100601.dmg':
provider = pkgdmg,
ensure = installed,
source = 'temp/location/rightnow/Bindscript20100601.dmg',
}
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
Re: [Puppet Users] Run this only once!!
On Tue, 12 Jul 2011 13:43:45 -0700, vella1tj wrote:
package { 'Bindscript20100601.dmg':
provider = pkgdmg,
ensure = installed,
source = 'temp/location/rightnow/Bindscript20100601.dmg',
}
Seems to work fine I return this once it runs notice:
//Package[Bindscript20100601.pkg.dmg]/ensure: created
So it will only run once on the machine?
Correct. As long as the file that Nigel pointed out remains there, it
won't try to install the .dmg again.
--
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`
signature.asc
Description: Digital signature
Re: [Puppet Users] Bizarre errors from puppetmaster 2.7.1
That does look an awful lot like the storedconfig bug (#4487). The fix prevented this from happening on new records, and would prevent further YAML encapsulation of existing rows, but the existing (broken) rows still needed to be cleaned up by hand. -- Please excuse my brevity; sent from my mobile device. On Jul 10, 2011, at 2:10 AM, Patrick kc7...@gmail.com wrote: On Jul 9, 2011, at 6:35 PM, Michael Halligan wrote: Periodically after restarting the master (which uses puppet-dashboard as a reporting server and ENC), when an agent tries to run, the agent isn't given any classes, and exits without error, then the master spews out this message: Jul 10 01:32:12 localhost puppet-master[15757]: Compiled catalog for ip-10-36-34-207.ec2.internal in environment --- --- \--- \\\--- \\\--- \\\--- \\\--- \\\--- \\\--- \\\--- \\\--- \\ Any ideas? There's a Millions of slashes storedconfigs bug. On the surface this looks a little similar. -- 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] Re: add lines to /etc/hosts on client
On Fri, 08 Jul 2011 11:18:57 -0700, newguy wrote:
class haproxy::init {
file { /etc/init.d/haproxy:
ensure = present,
owner = 'root',
group = 'root',
mode = 0600,
source = puppet:///modules/haproxy/haroxy,
Got a typo in the source URI here. Should be 'haproxy', instead of
'haroxy' at the end.
--
Jacob Helwig
signature.asc
Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-07-06
Sorry for the long delay in sending these out. For the last few weeks we've had an unusually high number of people out due to vacations and conferences, with the rest helping to meet a project deadline. Now that we're back to full strength we're ready to dive back into things. There's a big shift in what our backlog looks like right now, but this really boils down to us bumping something to the front of the queue to take advantage of the skills of our newest team member. Cameron Thomas has just joined us as a contractor (we're hoping he'll decide to join us at the end of the contract), and he brings a wealth of experience developing for Windows (as well as plenty of experience with Linux, and mobile development). The current backlog is Basic Puppet agent support on Windows. Currently this is a little nebulous, and primarily consists of things to research. We're planning on adding things we discover, and more concrete work we'll be doing as sub-tasks of the meta-ticket we currently have (#8268). As always, please don't be shy about watching commenting on that ticket (or any of the sub-tickets that end up being created). Ready for testing backlog items: * #3669 - Support DNS SRV records I'd like to thank Andrew Forgue for doing a large part of the work on this feature, and getting the ball rolling to get this into Puppet. This is currently only available in a topic branch in my repository[1], and I would definitely appreciate any and all testing anyone cares to do with this feature. This adds two new configuration variables: * use_srv_records: Will attempt to lookup SRV records for hostname found in srv_record (default: true) * srv_domain: The domain that will be queried for SRV records, (default: $domain) If use_srv_records is set to true, then Puppet will attempt to find the list of servers to use from SRV records on the domain specified via srv_domain. The CA, report, and file servers can all be specified via independent SRV records from the SRV records to use for looking up the catalog server. The SRV records must be for hosts in the form: _x-puppet._tcp.$srv_domain _x-puppet-ca._tcp.$srv_domain _x-puppet-report._tcp.$srv_domain _x-puppet-fileserver._tcp.$srv_domain If no records are found for the _x-puppet-ca, _x-puppet-report, or _x-puppet-fileserver services , then the SRV records for the _x-puppet service. However, if records exist for any of the more specific services, Puppet will not attempt to use the _x-puppet service to find an applicable server. If Puppet is unable to connect to any of the servers specified in the SRV records, then it will attempt to connect to the normal servers settable via puppet.conf. [1] https://github.com/jhelwig/puppet/tree/ticket/master/3669-make-puppet-honor-DNS-SRV-records -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Rack issue with puppet-dashboard
On Thu, 07 Jul 2011 16:05:03 -0700, Haitao Jiang wrote: I was following the instructions and was having trouble running sudo apt-get install puppet-dashboard I think it tries to start up the dashboard in the end but failed - any idea how to get it going? PS: I did try to install rack manually wget http://rubyforge.org/frs/download.php/71197/rack-1.2.0.tar.gz tar zxf rack-1.2.0.tar.gz gem install rack still the same error Thanks a lot Haitao =error= Gem::SourceIndex#add_spec called from /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91. /usr/local/lib/site_ruby/1.8/rubygems/dependency.rb:247:in `to_specs': Could not find rack (~ 1.0.1) amongst [facter-1.5.9, facter-1.5.7, puppet-2.6.8, rack-1.3.0] (Gem::LoadError) from /usr/local/lib/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' from /usr/local/lib/site_ruby/1.8/rubygems.rb:1182:in `gem' from /usr/share/puppet-dashboard/vendor/rails/actionpack/lib/action_controller.rb:34 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /usr/share/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require' from /usr/share/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in `new_constants_in' from /usr/share/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require' from /usr/share/puppet-dashboard/vendor/rails/railties/lib/commands/server.rb:2 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /usr/share/puppet-dashboard/script/server:3 * Puppet Dashboard is not running ...fail! invoke-rc.d: initscript puppet-dashboard, action start failed. dpkg: error processing puppet-dashboard (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: puppet-dashboard E: Sub-process /usr/bin/dpkg returned an error code (1) Looks like you've got the wrong version of rack installed. It's looking for rack (~ 1.0.1), which means it can use anything = 1.0.1 and 1.1.0. ~ is explained in more detail on the Ruby Gems site[1] under Pessimistic Version Constraint. [1] http://docs.rubygems.org/read/chapter/16 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Puppet Dashboard without MySQL
On Mon, 27 Jun 2011 10:24:38 -0700, Douglas Garstang wrote: All, Can puppet dashboard be used WITHOUT MySQL? Can't find it documented here: http://docs.puppetlabs.com/guides/installing_dashboard.html#external_node_classification Doug. There are some MySQLisms in the currently released versions of Dashboard that we're working on getting rid of, but right now Dashboard does need MySQL to work properly. If all you're interested is external node classification (and not the report collection) then you might be able to get away with using something else, as long as you don't mind certain pages blowing up. I haven't actually tried this though, and I'm fairly certain that the main page is one of the ones that will blow up. -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Turn off client autoupdate
On Fri, 24 Jun 2011 01:47:56 -0700, Sergey V. Arlashin wrote: By default puppet node connects to server periodically and looks if there is something execute. I'm wondering is it possible to make puppet clients not connect to server themselves? So that it would be possible to update a node only with puppetrun nodename. --- WBR, Sergey You'd probably be interested in #4411[1] and #3313[2]. Specifically, it looks like the way you should be able to do this is by specifying listen=true and client=false, but there appears to be a bug with the agent that makes client=false not actually work, but (--no-client on the command line does work). :-/ [1] http://projects.puppetlabs.com/issues/4411 [2] http://projects.puppetlabs.com/issues/3313 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Rake failing to create puppet dashboard database on RHEL6
On Mon, 20 Jun 2011 09:21:04 -0700, Pheran wrote:
Hi folks,
I'm trying to install puppet dashboard 1.1.1 on RHEL6 (following some
instructions in the excellent Pro Puppet book) but the rake command is
failing to create the database like so:
# rake RAILS_ENV=production db:create
(in /usr/share/puppet-dashboard)
Couldn't create database for {encoding=utf8, adapter=mysql,
username=dashboard, database=dashboard,
password=mypassword}, charset: utf8, collation: utf8_unicode_ci
(if you set the charset manually, make sure you have a matching
collation)
In the database.yml I have:
production:
database: dashboard
username: dashboard
password: mypassword
encoding: utf8
adapter: mysql
Any ideas? Thanks.
It looks like the dashboard MySQL user doesn't have CREATE DATABASE
permissions.
This is a pretty reasonable restriction to have on the user, so you may
need to create the database manually using a more privileged user, and
skip the db:create step.
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] confused about file ensure/require
On Mon, 20 Jun 2011 15:11:09 -0700, Craig White wrote:
Date: Mon, 20 Jun 2011 15:11:09 -0700
From: Craig White craig.wh...@ttiltd.com
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] confused about file ensure/require
X-Mailer: Apple Mail (2.1084)
Message-Id: 290592db-a4cd-4982-9eb0-4c5d09d2e...@ttiltd.com
On Jun 20, 2011, at 2:35 PM, Jacob Helwig wrote:
On Mon, 20 Jun 2011 14:17:46 -0700, Craig White wrote:
my base/default includes this ntp manifest
# cat modules/ntp/manifests/ntp.pp
# ntp.pp
class ntp {
case $operatingsystem {
centos, redhat: {
$service_name = 'ntpd'
$conf_file = 'ntp.conf.el'
}
debian, ubuntu: {
$service_name = 'ntp'
$conf_file = 'ntp.conf.debian'
}
}
package { 'ntp':
ensure = installed,
}
service { 'ntp':
name = $service_name,
ensure = running,
enable = true,
subscribe = File['ntp.conf'],
}
file { 'ntp.conf':
path = '/etc/ntp.conf',
ensure = file,
require = Package['ntp'],
source = puppet:///ntp/files/${conf_file},
}
}
# class {'ntp': }
So my questions...
1. I tested this by moving /etc/ntp.conf on my test client but it doesn't
seem to replace the file though it clearly says 'ensure = file'
Is my understanding wrong?
That should replace the file. What output are you getting (if
anything)?
% cat ../test.pp
file { 'blab':
path= '/tmp/blab.txt',
ensure = 'file',
content = 'asdf',
}
% puppet apply ../test.pp
notice: /Stage[main]//File[blab]/ensure: defined content as
'{md5}912ec803b2ce49e4a541068d495ab570'
notice: Finished catalog run in 0.06 seconds
% rm /tmp/blab.txt
% puppet apply ../test.pp
notice: /Stage[main]//File[blab]/ensure: defined content as
'{md5}912ec803b2ce49e4a541068d495ab570'
notice: Finished catalog run in 0.06 seconds
% puppet apply ../test.pp
notice: Finished catalog run in 0.04 seconds
2. Files ntp.conf.el ntp.conf.debian are located in
/etc/puppet/modules/ntp/files - source =
'puppet://puppet:///ntp/files/${conf_file} is this correct?
You should include 'modules' in the 'puppet://' URI, since the form
without it has been deprecated for a while. IIRC it should look
something like:
puppet:///modules/ntp/files/${conf_file}
-
I sort of think it should just work but it doesn't
# mv /etc/ntp.conf /root/
root@ubuntu:/var/www/puppet-dashboard# puppet agent --test --verbose --server
ubuntu.ttinet
info: Retrieving plugin
info: Caching catalog for ubuntu.ttinet
info: Applying configuration version '1308606646'
notice: Finished catalog run in 0.14 seconds
still no /etc/ntp.conf
root@ubuntu:/var/www/puppet-dashboard# puppet apply
/etc/puppet/modules/ntp/manifests/ntp.pp
notice: Finished catalog run in 0.01 seconds
above is what I got from the 'puppet apply' command and before from puppet
agent command, neither replaced /etc/ntp.conf and neither indicated an error.
root@ubuntu:/var/www/puppet-dashboard# ls -l /etc/ntp.conf
ls: cannot access /etc/ntp.conf: No such file or directory
and this was after I changed the source as you indicated...
# tail -n 5 /etc/puppet/modules/ntp/manifests/ntp.pp
source = puppet:///modules/ntp/files/${conf_file},
}
}
# class {'ntp': }
Craig
Doesn't look like you're including the ntp class?
The line that would do it is commented out in
/etc/puppet/modules/ntp/manifests/ntp.pp, if you're going to apply
/etc/puppet/modules/ntp/manifests/ntp.pp directly.
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] is ruby code allowed in puppet manifest?
On Thu, 16 Jun 2011 11:56:59 -0400, Guy Matz wrote:
Hi,
I'm trying to get the following to work:
class cluster {
$cluster_name = hostname.slice(0..-2)
.
.
} # class
hoping that if I have a server called appfarmserver1 (obtained from facter,
can I use a fact like this!?), cluster_name will get set to appfarmserver .
. .
puppet --parseonly init.pp says:
err: Could not parse for environment production: Syntax error at '.';
expected '}'
Is there some way to get this to work? Is there a better, more puppetty way
to do what I want to do, i.e. based on the hostname from fatcer, set the
variable cluster_name for use in a template.
Thanks so much,
Guy Matz
The most puppety way to do it is to create a custom fact that will
return this for you, instead of doing it in the manifest.
You could do it in the manifest using an inline ERB template, but it's
rather hacky.
I definitely recommend going the custom fact route instead.
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] puppet CA expired
On Tue, 14 Jun 2011 17:01:20 +0200, j...@squirk.org wrote: hi, my puppet CA expired. Anyone knows how to solve the problem and extend the validity of the CA ? I mean without recreating one and going on each node to change the certs (that is what puppet is made to prevent, going to each node ^^) regards, Jean. Pretty sure you can't actually extend the validity of the CA cert. Unfortunately, I don't think there's much that can be done at this point without touching each node. I did open up #7962[1] so we can work out exactly what the safety net should look like to help prevent this from happening to other people. [1] http://projects.puppetlabs.com/issues/7962 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] puppet CA expired
5 years, IIRC. -- Jacob Helwig On Thu, 16 Jun 2011 11:03:49 -0700, Nathan Clemons wrote: What's the length of time on the CA cert? On Thu, Jun 16, 2011 at 10:40 AM, Jacob Helwig ja...@puppetlabs.com wrote: On Tue, 14 Jun 2011 17:01:20 +0200, j...@squirk.org wrote: hi, my puppet CA expired. Anyone knows how to solve the problem and extend the validity of the CA ? I mean without recreating one and going on each node to change the certs (that is what puppet is made to prevent, going to each node ^^) Pretty sure you can't actually extend the validity of the CA cert. Unfortunately, I don't think there's much that can be done at this point without touching each node. I did open up #7962[1] so we can work out exactly what the safety net should look like to help prevent this from happening to other people. [1] http://projects.puppetlabs.com/issues/7962 signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-06-15
Just a heads-up that we won't have as much time to work on our normal backlog go through submitted patches over the next week or so due to several of us being out for conferences and other travel obligations. Finished backlog items: * #4416 - Resources cannot be used on the run where they are synced This has been merged into the 2.6.x branch, and is planned for release in 2.6.9. Occasionally, when delivering a new provider to the agent via pluginsync, the provider would be loaded before the type. When this happened the provider would cause the type to be loaded, but the type was still in the list of things to be loaded. When the autoloader would get to loading the type, this would cause the type to effectively forget that it had a provider that was loaded before. Now, the type explicitly checks for already loaded providers whenever it is loaded. This isn't an ideal fix, since the type is still needlessly loaded multiple times, however a more robust solution around how the autoloader behaves, and is used is planned for Telly (#3741). * #7127 - prerun_command don't stop puppet on error This has been merged into the 2.6.x branch, and is planned for release in 2.6.9. Previously, the prerun command wouldn't actually halt a puppet run when it exited non-zero. The pre postrun commands have been updated so that if the prerun command fails: * The catalog will not be applied. * The prerun command errors will be included in the report. * The report status will not be altered. * The report is sent out. * The agent apply will exit 1 where appropriate. If the postrun command fails: * Include the postrun command errors in the report. * The report status will not be altered. * The report is sent out. * The agent apply will exit 1 where appropriate. This brings the behavior of the pre postrun commands in line with what their documented behavior was. This also involved some additional refactoring around report handling in the transaction which means that pluginsync errors would be included in the uploaded report. * #7224 - Bad english: hostname was not match with the server certificate This has been merged into the 2.7.x branch, and is planned for release in 2.7.1. Previously, when connecting to a master using a name that wasn't part of its certificate (From either certname, or certdnsnames), then the agent would report hostname was not match with the server certificate. The REST API handling has been updated to catch these kinds of SSL errors, and replace them with a message that is hopefully much more informative. The new message is in the following form, where 'localhost' is the name used to connect to the master, and 'foobar', 'one_cert', 'two_cert', 'red_cert', 'blue_cert' are the expected possible host names from certdnsnames: Server hostname 'localhost' did not match server certificate; expected one of foobar, one_cert, two_cert, red_cert, blue_cert Removed backlog items: These have been re-prioritized according to the road map that we published earlier in the week: http://projects.puppetlabs.com/projects/puppet/wiki/Road_map * #7742 - Package type V2 - apt * #7743 - Package type V2 - dpkg * #7744 - Package type V2 - aptitude New backlog items: * #7316 - puppet applications delivered via pluginsync don't work. * #4916 - Plugins should not be able to override core functionality. * #7788 - Puppet should allow rubygems to deliver new functionality * #3910 - Server is not authoritative over client environment when specified in an ENC * #2247 - enablerepo and disablerepo for yum type * #3534 - Dashboard should support ability to set variables as arrays in the ENC Current backlog: * #7316 - puppet applications delivered via pluginsync don't work. * #5517 - behavior change within 2.6 makes it impossible to override class parameters of included parametrized classes * #3741 - Custom facts loaded multiple times * #3669 - Make puppet honor DNS SRV records * #4916 - Plugins should not be able to override core functionality. * #7788 - Puppet should allow rubygems to deliver new functionality * #3910 - Server is not authoritative over client environment when specified in an ENC * #2247 - enablerepo and disablerepo for yum type * #3534 - Dashboard should support ability to set variables as arrays in the ENC -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Has anyone noticed this - mount resource type and Solaris
On Thu, 16 Jun 2011 09:31:06 +1000, Jonathan Elliott wrote: Hi, I've been having trouble with this resource type on Solaris using the packages from the OpenCSW repository. Delving into the code, I've found that the operatingsystem fact isn't being retrieved correctly by the parsed.rb code for the resource type. This results in the default fields being used to populate /etc/vfstab and this causes mounts to fail owing to incorrectly formatted lines. My workaround has been to change the following code fragment: case Facter[operatingsystem] when Solaris @fields = [:device, :blockdevice, :name, :fstype, :pass, :atboot, :options] else (blah blah blah) to case Facter.value(:operatingsystem) when Solaris @fields = [:device, :blockdevice, :name, :fstype, :pass, :atboot, :options] else And everything seems to work just fine. My questions are as follows: 1. Is this a known issue? 2. If so, is it a problem with Puppet 2.6.x, all Puppet versions (I don't recall having issues with 0.25.x, for example) or just the OpenCSW packages? 3. How do I raise a bug report if it turns out that I have some kind of clue? Note that I do _not_ speak Ruby and what I've done has been based on a combination of some tactical use of Google and educated guesswork. I fully expect to be told that I've got this whole issue completely wrong. If that's the case, I'd appreciate any pointers as to where my error(s) lies/lie. 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. We've started work on reworking the the whole mount type into it's component pieces (the fstab active mounts) as a plugin[1][2]. We also started with Solaris support, and it would be great to get more eyes on it to test it out. It currently has a few limitations (can't specify the fstype on the mountpoint type, and mountpoint resources really won't work without a proper entry in the vfstab), but it should be usable for most cases. As far as the questions you directly asked: 1) Not really sure off hand. Unfortunately, the mount type has a whole slew of issues (which is one of the motivating forces behind breaking up that monolithic beast). 2) I doubt it's specific to the OpenCSW packages, but I'm not sure off hand if it's 2.6 specific or not. 3) Pop on over to the redmine instance[3], and file a bug report. Doesn't hurt to mention that you've done so on here. [1] https://github.com/puppetlabs/puppetlabs-mount-providers [2] http://projects.puppetlabs.com/issues/7188 [3] http://projects.puppetlabs.com -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Managing local + LDAP users and groups
On Tue, 14 Jun 2011 07:45:44 -0700, bradejr wrote: Our environment (mostly RHEL) uses LDAP for user and group administration. Unfortunately, we have some cases where (broken) software insists on local users and groups. I'm guessing it's checking the files directly instead of using the proper system calls. Our current process is to create the local user/group matching the LDAP entries. How are people handling this case? Puppet won't create the user locally, as it sees the user as already existing. We are currently using exec to call the local versions of the commands (luseradd, lusermod, etc), but that's something of a hack and makes for more complex classes. Does anyone have a graceful way to handle this in puppet? Thanks, Rob Seems like it would be reasonable to make an luseradd provider for the user type along the same lines as the existing useradd one. Thanks for already opening a ticket for this! http://projects.puppetlabs.com/issues/7911 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] RFC: Adding implicit stages to Puppet
Chris Phillips ch...@untrepid.com wrote: On 10 June 2011 02:50, Jacob Helwig ja...@puppetlabs.com wrote: On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/7697 One problem people producing modules that make use of stages are hitting is that it's difficult to create something reusable that integrates seamlessly into existing setups. This feature request is to add several more implicit stages to Puppet so we have: bootstrap pre main post existing by default, making it easier for authors to specify stages in their modules. Thoughts? Seems like a very good idea to me. What about these stages relating to being able regenerate facts after a stage possibly? A thread the other day about nagios configs meant delivering a new fact file and then going back on the next run to retrieve the facts. I think this required two runs, can't swear to it right now though, but a formal re-evaluation of facts after a bootstrap could be good. You could be real confusing and have a proper POST section too, right at the start, BIOS style. Not to be confused with the post stage of course! ;-) The answer to question Which comes first, 'bootstrap' or 'pre'? seems awfully ambiguous from just the names. I would see that a bootstrap stage would be for modules fundamental to puppet itself, e.g. if puppet.conf is updated. And pre would be normal run stuff that just needs to happen early on in the run itself. What's the reason for separating it out? For the reasons he already described... Thanks Chris -- 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. The question was specifically about splitting out pre and bootstrap. All the rest made sense, especially with all the talk that's been going on about prerun and postrun commands. -- Sent from my phone. Please excuse my brevity. -- 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] RFC: Adding implicit stages to Puppet
On Thu, 09 Jun 2011 18:42:54 -0700, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/7697 One problem people producing modules that make use of stages are hitting is that it's difficult to create something reusable that integrates seamlessly into existing setups. This feature request is to add several more implicit stages to Puppet so we have: bootstrap pre main post existing by default, making it easier for authors to specify stages in their modules. Thoughts? The answer to question Which comes first, 'bootstrap' or 'pre'? seems awfully ambiguous from just the names. What's the reason for separating it out? -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Open Source Team iteration planning summary 2011-06-08
Finished backlog items: * #2128 - Allow arbitrary fact as node_name identifier There are now two new (mutually exclusive) configuration options on the agent in the 2.6.x branch to allow setting the node's name separately from the node's certificate name. node_name_value: This defaults to the value of the certname setting. node_name_fact: This is not set by default. When set, the agent will use the value of this fact as the node name when checking in with the master for uploading facts, retrieving catalogs and all other operations. In order to take advantage of these new settings you will need to modify the default auth.conf to include a section similar to the one below before the default path ~ ^/catalog/([^/]+)$ block. path ~ /catalog/ec2_node_.+ allow * This will allow any authenticated agent (one making a request with a signed certificate) to upload facts, and request the catalog for any node that has a name starting with 'ec2_node_'. This is required since the node name that will be used in the request will not likely match the certificate name used to authenticate with the master. These new options also affect the node name used in reports sent back to the master. * #650 - puppet replaces configuration directories when they are symlinks This has been merged into the 2.6.x branch. Puppet will no longer replace the confdir (or other directory settings) with real directories when they currently exist on disk as a symlink to a real directory. Puppet will still replace the symlink with a real directory if the target doesn't exist, or is something other than a file. This is known behavior around managing files directories through symlinks, and is captured in #4394[1] The new backlog items this week are: * #3741 - Custom facts loaded multiple times * #3669 - Make puppet honor DNS SRV records Current backlog: * #7127 - prerun_command don't stop puppet on error * #4416 - Resources cannot be used on the run where they are synced * #7742 - Package type V2 - apt * #5517 - behavior change within 2.6 makes it impossible to override class parameters of included parametrized classes * #7743 - Package type V2 - dpkg * #7744 - Package type V2 - aptitude * #3741 - Custom facts loaded multiple times * #3669 - Make puppet honor DNS SRV records [1] http://projects.puppetlabs.com/issues/4394#note-2 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Changes on master applied only on second run on nodes
On Tue, 07 Jun 2011 00:19:07 -0700, Maxim Ivanov wrote: Hi! If I change manifest on master and then immediately run puppet agent --no-daemonize --report --pluginsync --onetime then it still uses old version of manifest. When I run it second time it sees changes and applies them. Why is it like that? Is it intended to be so? There is an adjustable quiet period where the master will not pick up changes to the manifest after having loaded a new manifest. This is controlled by the filetimeout setting, which defaults to 15 seconds. If immediately doesn't actually mean immediately, but after the file timeout, then you may be running into #5318[1], which should be fixed in the next version of 2.6, and in 2.7 when it comes out. http://projects.puppetlabs.com/issues/5318 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] logging output at err level, success as just a notice?
On Tue, 07 Jun 2011 10:29:12 -0500, Jennings, Jared L CTR USAF AFMC 46 SK/CCI
wrote:
Helwig:
Unfortunately, the documentation is just plain wrong. loglevel is the
only one that supports any legal log level. logoutput really does
only support true, false, and on_failure.
Is pwck exiting non-zero when there is output? That should be
sufficient to trigger the behavior it seems like you're looking for if
you have 'logoutput = on_failure' in the exec.
pwck indeed behaves nicely with its exitcodes - the problem is I want
the output to be an err, not a notice:
notice: /Stage[main]/User::Valid/Exec[pwck]/returns: user 'foo':
directory '/home/foo' does not exist
notice: /Stage[main]/User::Valid/Exec[pwck]/returns: pwck: no changes
err: /Stage[main]/User::Valid/Exec[pwck]/returns: change from notrun to
0 failed: /usr/sbin/pwck -r returned 2 instead of one of [0] at
/etc/puppet/modules/user/manifests/valid.pp:11
If I set loglevel = err, that makes the output purple, but if pwck is
happy, the loglevel setting also makes the ran successfully message an
err.
Hm...yeah, sorry. I hadn't noticed that the actual output was notice,
and not err when the command fails. I was just testing around with
echo, and setting returns = 1 to get it to fail, but I guess I just
wasn't looking closely enough.
You can kind of hack Puppet to do this now, but only if the command
you're running is purely checking things, and does not have any
side-effects.
exec { 'pwck -r':
path = '/usr/bin:/bin:/usr/sbin:/sbin',
logoutput = on_failure,
loglevel = err,
unless= 'pwck -r',
}
By doing the unless = 'pwck -r', the resource won't even show up as
having been run if 'pwck -r' returns 0. Having to run the command twice
is a hack, but it's the best I can think of at the moment.
Seems reasonable that when logoutput = on_failure the actual output
should be logged as an err, instead of a notice. Would you mind filing
a feature request on the issue tracker[1]?
[1] http://projects.puppetlabs.com
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] ! $is_virtual
On Tue, 07 Jun 2011 11:09:32 -0700, Douglas Garstang wrote:
All,
Running this on a bare metal server. Package doesn't get installed,
therefore condition is false. Why?
if ! ($is_virtual) {
package {
'vlock':
ensure = installed;
}
}
[pax] app01 ~:# facter | grep is_virtual
is_virtual = false
Oh... don't tell me that 'false' isn't false?
Doug.
Nope, it's not. It's the string false.
I've heard some talk about Facter supporting richer/structured data
eventually[1], but we haven't had much time to move forward on that
front. Hopefully as things ramp up with our recent Open Source Team,
and as we increase community involvement in development of
Puppet/Facter/Dashboard/etc some progress will be able to made towards
that end.
[1]
http://groups.google.com/group/puppet-dev/browse_thread/thread/7c2139b05f96d218/e5a70336f43e6c7d
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] logging output at err level, success as just a notice?
On Mon, 06 Jun 2011 09:37:48 -0500, Jennings, Jared L CTR USAF AFMC 46 SK/CCI
wrote:
I'm trying to run pwck with Puppet 2.6.4. pwck checks the passwd file
and makes sure that, for example, each user's home directory exists.
(And other stuff.) When everything is OK, it doesn't say anything. So if
it says something, I want to know it, and I want it to stand out from
other exec output.
So I have
exec { pwck:
command = /usr/sbin/pwck -r,
logoutput = true,
loglevel = err,
}
If pwck gives any output, it shows up at the err loglevel. But if
everything is OK, I get:
err: /Stage[main]/User::Valid/Exec[pwck]/returns: executed successfully
(in purple, of course). I don't want an err message when everything is
fine.
The documentation for the exec resource type
(http://docs.puppetlabs.com/references/latest/type.html) says, about
logoutput, Values are true, false, on_failure, and any legal log level.
Valid values are true, false, on_failure. (Take a second and read that
again.) So I tried setting logoutput = err and no loglevel, and got:
'err: Could not run Puppet configuration client: Parameter logoutput
failed: Invalid value err. Valid values are true, false, on_failure.'
How can I make executed successfully a notice, and any output from
pwck an err?
If logoutput can indeed be set to any legal log level, does anyone know
in what version of Puppet this works?
Unfortunately, the documentation is just plain wrong. loglevel is the
only one that supports any legal log level. logoutput really does
only support true, false, and on_failure.
Is pwck exiting non-zero when there is output? That should be
sufficient to trigger the behavior it seems like you're looking for if
you have 'logoutput = on_failure' in the exec.
I tried running 'pwck -r' on my Ubuntu machine, and it exited 2 with a
bunch of warnings. I presume it would have exited 0 had there not been
any warnings.
--
Jacob Helwig
signature.asc
Description: Digital signature
[Puppet Users] Package type: enable/disable repo vs options (#2247 vs #4113)
We currently have to feature requests to add similar (or at least overlapping) functionality to the Package type. #2247[1] - enablerepo and disablerepo for yum type #4113[2] - Provide a generic options-style parameter for packages. It seems like having #4113 would remove the need for having #2247, but I wanted to get some wider opinions to make sure I wasn't ignoring some use-case that would make this not the case. Personally, I think we should move forward on #4113 instead of #2247, since #4113 seems like the more general solution, and isn't tied directly to the yum provider. #2247 does currently have some code submitted for it, however it requires a signed CLA before we can accept it. While no code has been written for #4113 yet, it doesn't look like it would actually be that much work to do. Thoughts? Opinions? Comments? [1] http://projects.puppetlabs.com/issues/2247 [2] http://projects.puppetlabs.com/issues/4113 -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] How do I enable repositories and install packages
If you want to enable the repositories on a per-package basis as was shown in the examples (with the --enablerepo flag), then you'll definitely want to watch vote for #4113[1]. If you want to have the repositories always enabled, then you should be able to do that through the yum configuration. I'm not all that familiar with the details though since I've tended not to use the RPM based systems. [1] http://projects.puppetlabs.com/issues/4113 -- Jacob Helwig On Wed, 01 Jun 2011 09:31:51 -0700, Nathan Clemons wrote: The package resource type will allow you to install packages via Yum, but does not (last I checked) support specifying repos to enable/disable (which I'd dearly love if it was added). Which means you either get to write your own extension to package to add that functionality, or use exec. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Wed, Jun 1, 2011 at 9:19 AM, hyzhang hyzh...@jcvi.org wrote: Hi, My shell script is as below. How do I translate them to puppet language? I think I can use exec directly. But is there a better way? /usr/bin/yum clean all /bin/echo -e \n/usr/bin/yum -y --enablerepo=base,rpmforge install mplayer mplayer-skins /usr/bin/yum -y --enablerepo=base,rpmforge install mplayer mplayer- skins /usr/bin/yum clean all /bin/echo -e \n/usr/bin/yum -y --nogpgcheck install RealPlayer AdobeReader_enu flash-plugin /usr/bin/yum -y --nogpgcheck install RealPlayer AdobeReader_enu flash- plugin /usr/bin/yum clean all /bin/echo -e \n/usr/bin/yum -y --enablerepo=base install pidgin /usr/bin/yum -y --enablerepo=base install pidgin Thanks, -Haiyan signature.asc Description: Digital signature
Re: [Puppet Users] Puppet 2.6.8 agent slow execution
On Wed, 01 Jun 2011 23:58:24 +0400, Pavel Shevaev wrote: Mitigation for 4: 1) If the combined size of the files are small, you can try using content instead of source for the files. Wow, that did the trick Thanks a lot! Deployment time is now 10-12 seconds. I'm a puppet newbie and don't quite understand why it worked but it's great :) So, the big difference there is that by using 'content', the file contents are shipped down to the agent as part of the catalog. With 'source', the agent will have to make a new HTTP request per file to get the content when it attempts to manage the resource. You end up saving a potentially large number of HTTP round-trips, which adds up. -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Open Source Team planning meeting summary 2011-06-1
Thanks to everyone that provided their feedback on what they would like to see worked on. We've gone through the suggestions, and re-prioritized our back-log to take into account the various suggestions, and the state of each of the tickets. Next week, I don't plan on directly soliciting with a call for tickets like I did this week, but I definitely wish to encourage everyone to comment on these if they have anything they would like to bring up. The main reason for not having a call for tickets next week is that I'd like to encourage everyone to take advantage of the voting functionality of the ticketing system to help us figure out what the most important things are. I've created a public saved search[1] to easily see what the current top voted issues are, in case you're interested in what that list looks like. There are a few suggestions that aren't listed here, but we haven't forgotten about them. We just didn't want to end up trying to stuff a ton of things into our backlog, when we already knew we wouldn't be able to get to everything this week. The current Open Source Team backlog: * #2128 - Allow arbitrary fact as node_name identifier * #7127 - prerun_command don't stop puppet on error * #650 - puppet replaces configuration directories when they are symlinks * #4416 - Resources cannot be used on the run where they are synced * #7742 - Package type V2 - apt * #7224 - Bad english: hostname was not match with the server certificate * #5517 - behavior change within 2.6 makes it impossible to override class parameters of included parametrized classes * #7743 - Package type V2 - dpkg * #7744 - Package type V2 - aptitude [1] http://projects.puppetlabs.com/projects/puppet/issues?query_id=147 -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Re: Open Source Team planning meeting summary
On Thu, 26 May 2011 09:38:28 -0700, Jacob Helwig wrote: As promised yesterday, here are the results of our first planning meeting. Right now, we're loosely following a Scrum style of development. With the current one-week iteration's backlog outlined below. * #2128 - Allow arbitrary fact as node_name identifier * #7224 - Bad english: hostname was not match with the server certificate * #4416 - Resources cannot be used on the run where they are synced * Package type V2 (apt) * Package type V2 (dpkg) * Package type V2 (aptitude) We're trying to work on things that we know have annoyed people using Puppet. We are very open to any suggestions on what to add to the following iterations, so please vote on tickets in Redmine[1], and comment on these updates. The Package type V2 items don't currently have any tickets in Redmine, but the goal will be to clean up the current package type in the hopes of having a clean, modern and well tested type, and set of providers that people can use as a reference when writing their own. If the experiment in refactoring the package type, and the apt, aptitude, and dpkg providers goes well, we plan on continuing on to the rest of the providers. In addition to the iteration backlog, #7670 and #7681 have become priorities that we will be addressing as soon as we can. * #7670 - operatingsystem fact incorrect after clear on Ubuntu * #7681 - Regression, arrays and variables [1] http://projects.puppetlabs.com Just a quick reminder that we're going to have our planning meeting tomorrow. If you'd like to influence what we end up prioritizing for ourselves for the coming week, please speak up. #7670, and #7681 have both been fixed, and merged into the appropriate branches to be released. I've had one suggestion of working on #650 (Puppet replaces conf directories when they are symlinks). Right now, the back-log looks the same as it did last wednesday due to the two blockers popping up, and the long holiday weekend here in the States. -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Re: Open Source Team planning meeting summary
On Tue, 31 May 2011 20:56:47 -0600, Alan Sparks wrote: On Tue, May 31, 2011 at 5:08 PM, Jacob Helwig ja...@puppetlabs.com mailto:ja...@puppetlabs.com wrote: Just a quick reminder that we're going to have our planning meeting tomorrow. If you'd like to influence what we end up prioritizing for ourselves for the coming week, please speak up. Apologize for not having a bug number for this, but I recall that web-of-trust (intermediate CAs) did not work with Puppet as is. If that's true, that's a long-standing one I'd like to see fixed... -Alan I think you're talking about #3143. http://projects.puppetlabs.com/issues/3143 -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Puppet should correctly support CA trust chains (#3143)
On Tue, 31 May 2011 22:01:15 -0600, Alan Sparks wrote: On 5/31/2011 9:07 PM, Jacob Helwig wrote: On Tue, 31 May 2011 20:56:47 -0600, Alan Sparks wrote: On Tue, May 31, 2011 at 5:08 PM, Jacob Helwig ja...@puppetlabs.com mailto:ja...@puppetlabs.com wrote: Just a quick reminder that we're going to have our planning meeting tomorrow. If you'd like to influence what we end up prioritizing for ourselves for the coming week, please speak up. Apologize for not having a bug number for this, but I recall that web-of-trust (intermediate CAs) did not work with Puppet as is. If that's true, that's a long-standing one I'd like to see fixed... -Alan I think you're talking about #3143. http://projects.puppetlabs.com/issues/3143 Looks right... we need that where I work, is a killer if that has to wait for a 2.7ish.mumble release... -Alan Mind elaborating? I have no idea which version we'll end up targeting for #3143 when we do end up working on it. -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Schedule resource oddities (#7639)
The schedule resource has some behavior that comes across as a little...strange. For example: * If you specify a range of 02:00:00 - 01:00:00, Puppet will fail with Parameter range failed: Invalid range 02:00:00 - 01:00:00; ranges cannot span days.. * If you specify 01:30:00 - 01:00:00, then it is allowed and you get an info message stating Assuming upper limit should be that time the next day. These seem completely contradictory (and the auto-conversion doesn't seem very useful given it looks like it will end up with a schedule that will _always_ allow application). There's another oddity in that if you don't specify the minutes/seconds then they will default to whatever the _current_ minutes/seconds are on the master. It seems like they should default to zero, instead. Given these things, it seems like we should remove the Assuming upper limit should be that time the next day behavior entirely, and defaulting the missing time components to zero instead of to whatever the current value is for the server. If these changes would break how you're using schedules, please let us know (here, or on the related ticket[1]) and please let us know why. [1] http://projects.puppetlabs.com/issues/7639 -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Re: Changing up some things around Puppet Labs's Open Source Software
On Wed, 25 May 2011 18:14:28 -0700, Jacob Helwig wrote: One of the largest challenges we've continually faced at Puppet labs is trying to find a good balance in splitting the development team's time between the (currently small amount of) commercial software, and the (much larger amount of) open source software. This balancing act has, unfortunately, affected being able to get a number of the excellent contributions from people outside of Puppet Labs the attention that they deserve, and also affected being able to give the internal commercial development the attention it deserves to further Puppet Labs as a business. As a step towards simplifying the decision towards how to divide our time, we're dividing our responsibilities instead. We're splitting the team to form one dedicated to owning the open source projects, focused on their quality, frequency of delivery, and ease of contribution. This team's long-term goal is to build outside contribution, and generally ensure that we have a healthy and active open source community. One of the short-term effects of this is that it will be much clearer who will be responsible to the community for making sure that you get the interactions you're looking for, and that the things you care about are making their way into the various open source projects. Right now this Open Source team consists of Josh Cooper, Nick Lewis, and myself. As the Open Source team, we're planning on sending periodic updates to the puppet-dev mailing list (and possibly user) with the results of our planning meeting (what we roughly plan on working on over the coming iteration), and with information similar to Git's What's Cooking updates[1] (what's in the repository pending release). We haven't figured out with what frequency to send these updates (other than the results of the iteration planning meeting). If you have any thoughts on how frequently you think this information would be useful, we'd love the input. We're also toying around with some ideas on how to get better visibility into the daily stand-ups we have. We haven't had time to think about this one too much, but so far we've got three rough proposals. * Have each person do their stand-up check-in on the puppet-dev mailing list. * Have someone send a stand-up summary to the mailing list after each stand-up. * Do something akin to the Pivotal Labs stand-up summary blog posts[2]. Again, if you have any ideas, we'd love to hear them. This isn't exactly a change (we've just been forgetting to mention it), but you can see what the current community patch backlog looks like by going to our Patchwork instance[3]. We've been using Patchwork for a while to keep track of the patches that go through the dev mailing list, to try and prevent them from slipping through the cracks. One of our goals is to get this backlog down to zero, and keep it as close to that as possible. Another long-term change that has been mentioned in passing, but hasn't really been fleshed out is moving the other teams to be just normal contributors. Having them go through the same contribution process as everyone outside of Puppet Labs (though with the ability to walk over or holler, instead of having to email if they need something). We'll likely be making more changes in the future to further achieve the goal of having a strong/vibrant/healthy open source community, though we haven't figured any of this out yet. If you have any ideas for things you'd like to see, or comments/suggestions/questions about anything I've mentioned please feel free to bring them up here, or contact me personally. [1] http://article.gmane.org/gmane.comp.version-control.git/171013 [2] http://pivotallabs.com/blabs/categories/standup [3] https://patchwork.puppetlabs.com/ -- Jacob Helwig It was brought to my attention that we may not have made an aspect of things quite as clear as we had intended. The commercial team will continue to work on features bugs in both the open source and commercial projects. (Puppet Labs does have support contracts and paying customers after all.) The open source team will work on the open source projects with the goal of furthering them as open source software. The primary goals of the team will always be encouraging outside contributions to the open source codebases, and making the open source software better on its own merits. -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Open Source Team planning meeting summary
As promised yesterday, here are the results of our first planning meeting. Right now, we're loosely following a Scrum style of development. With the current one-week iteration's backlog outlined below. * #2128 - Allow arbitrary fact as node_name identifier * #7224 - Bad english: hostname was not match with the server certificate * #4416 - Resources cannot be used on the run where they are synced * Package type V2 (apt) * Package type V2 (dpkg) * Package type V2 (aptitude) We're trying to work on things that we know have annoyed people using Puppet. We are very open to any suggestions on what to add to the following iterations, so please vote on tickets in Redmine[1], and comment on these updates. The Package type V2 items don't currently have any tickets in Redmine, but the goal will be to clean up the current package type in the hopes of having a clean, modern and well tested type, and set of providers that people can use as a reference when writing their own. If the experiment in refactoring the package type, and the apt, aptitude, and dpkg providers goes well, we plan on continuing on to the rest of the providers. In addition to the iteration backlog, #7670 and #7681 have become priorities that we will be addressing as soon as we can. * #7670 - operatingsystem fact incorrect after clear on Ubuntu * #7681 - Regression, arrays and variables [1] http://projects.puppetlabs.com -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Problem with Facter 1.5.9 on Ubuntu
It looks like there's a fairly critical bug with Facter 1.5.9, when it comes to Ubuntu[1]. Facter ends up reporting the wrong value for 'operatingsystem', which can cause problems with the manifest. If you're dependent on being able to switch in your manifests based on Ubuntu vs Debian, then you shouldn't upgrade to Facter 1.5.9. [1] https://projects.puppetlabs.com/issues/7670 -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] Changing up some things around Puppet Labs's Open Source Software
One of the largest challenges we've continually faced at Puppet labs is trying to find a good balance in splitting the development team's time between the (currently small amount of) commercial software, and the (much larger amount of) open source software. This balancing act has, unfortunately, affected being able to get a number of the excellent contributions from people outside of Puppet Labs the attention that they deserve, and also affected being able to give the internal commercial development the attention it deserves to further Puppet Labs as a business. As a step towards simplifying the decision towards how to divide our time, we're dividing our responsibilities instead. We're splitting the team to form one dedicated to owning the open source projects, focused on their quality, frequency of delivery, and ease of contribution. This team's long-term goal is to build outside contribution, and generally ensure that we have a healthy and active open source community. One of the short-term effects of this is that it will be much clearer who will be responsible to the community for making sure that you get the interactions you're looking for, and that the things you care about are making their way into the various open source projects. Right now this Open Source team consists of Josh Cooper, Nick Lewis, and myself. As the Open Source team, we're planning on sending periodic updates to the puppet-dev mailing list (and possibly user) with the results of our planning meeting (what we roughly plan on working on over the coming iteration), and with information similar to Git's What's Cooking updates[1] (what's in the repository pending release). We haven't figured out with what frequency to send these updates (other than the results of the iteration planning meeting). If you have any thoughts on how frequently you think this information would be useful, we'd love the input. We're also toying around with some ideas on how to get better visibility into the daily stand-ups we have. We haven't had time to think about this one too much, but so far we've got three rough proposals. * Have each person do their stand-up check-in on the puppet-dev mailing list. * Have someone send a stand-up summary to the mailing list after each stand-up. * Do something akin to the Pivotal Labs stand-up summary blog posts[2]. Again, if you have any ideas, we'd love to hear them. This isn't exactly a change (we've just been forgetting to mention it), but you can see what the current community patch backlog looks like by going to our Patchwork instance[3]. We've been using Patchwork for a while to keep track of the patches that go through the dev mailing list, to try and prevent them from slipping through the cracks. One of our goals is to get this backlog down to zero, and keep it as close to that as possible. Another long-term change that has been mentioned in passing, but hasn't really been fleshed out is moving the other teams to be just normal contributors. Having them go through the same contribution process as everyone outside of Puppet Labs (though with the ability to walk over or holler, instead of having to email if they need something). We'll likely be making more changes in the future to further achieve the goal of having a strong/vibrant/healthy open source community, though we haven't figured any of this out yet. If you have any ideas for things you'd like to see, or comments/suggestions/questions about anything I've mentioned please feel free to bring them up here, or contact me personally. [1] http://article.gmane.org/gmane.comp.version-control.git/171013 [2] http://pivotallabs.com/blabs/categories/standup [3] https://patchwork.puppetlabs.com/ -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Re: Does the puppet module tool work with ruby1.9.2?
On Tue, 24 May 2011 14:12:50 -0700, Kevin Beckford wrote: I need some sort of login to post this bug there, one which I do not have. The bug tracker does require an account to file issues, but registering an account is free, and (relatively) simple. I created a bug report from your initial email[1]. If you have any additional details you think might help please add them (though you'll still need to register an account to do so). [1] http://projects.puppetlabs.com/issues/7648 Thanks for taking the time to send us the output you were getting with Ruby 1.9. -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] ANNOUNCE: Facter 1.5.9 Final!
to report in milliseconds instead of seconds 1f387a5 [#4552] Apply patch from Dean Wilson 244d2f1 Better fix for Bug 4569: Uptime Fact is incorrect on Windows 11544c1 [#4289] operatingsystemrelease fact for oel, ovs e6bfdf9 Fix for bug #4569 8c4d0cd (#4558) Fail with message on --help errors 7210429 [#4558] Refactor facter binary using optparse b5c85de [#4563] Add a --trace option to the binary ebcb81b [#4558] Refactor facter binary using optparse b8b7123 (#4567) Remove unnecessary or non-portable redirects 7ecba71 (#4567) Retain detached HEAD state 1125e1e Make sure FreeBSD spec also works on systems that have /proc/cpuinfo. 889e150 Sync rpm spec file from Fedora/EPEL 725dce0 Rename Reductive Labs to Puppet Labs ff473ef Updated signing rake task a85f2b0 [#2865] Fix reporting of virtual facts f67ec05 [#4567] Add ext/facter-diff to compare output of 2 versions 4050acc Removing stupid .DS_Store files :( 016cf03 [#3703] Fix macaddress fact for Darwin -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Negative checkin time
On Thu, 19 May 2011 13:48:06 -0400, Gabriel Filion wrote: Hi, I'm using puppet 0.25.5 and a puppetlast script [1]. [1] : http://humangenomeinfo.com.ar/1.txt/usr/share/puppet/ext/puppetlast I get a negative checkin time from one node.. UNKNOWN: somenode.fqdn checked in -16 minutes ago how is that possible? The timestamp for the checkin time is taken from node.values[:_timestamp]. Is this timestamp based on the remote node's clock? It is. It looks like you've got clock drift between the machines. -- Jacob Helwig signature.asc Description: Digital signature
Re: 530 million backslashes (was Re: [Puppet Users] So, clientconfigs.sqlite3 is pretty big)
On Sun, 15 May 2011 15:33:56 +, Nigel Kersten wrote: On Sun, May 15, 2011 at 2:39 AM, Robin Lee Powell rlpow...@digitalkingdom.org wrote: On Sat, May 14, 2011 at 01:35:51PM +0200, Stefan Schulte wrote: On Fri, May 13, 2011 at 09:04:35PM -0700, Robin Lee Powell wrote: I only have like 15 hosts, and the only stuff I'm aware that I'm saving via | |/@@ is ssh keys. It's 600 MiB. That seems really large? Should I just delete it every once in a while? -Robin You are talking about stored configuration right? Do you use thin_storeconfigs[1]? I do, in fact, use thin_storeconfigs. I seem to have hit something of a rather nasty bug here. I opened up the database and did a dump and discovered this: INSERT INTO hosts VALUES(2, 'tools01.c44031.blueboxgrid.com', '67.214.208.43', '--- --- \--- \\\--- \\\--- \\\ --- \\\--- \\\--- \\\ --- \\\ --- \\\ --- \\\ This goes on. For some time: [rlpowell@test02 ~]$ wc /tmp/dump 511 5877 536988618 /tmp/dump [rlpowell@test02 ~]$ cat /tmp/dump | tr '\\' '\n' | wc 536920329 5988 536988618 This means my database has 530 *MILLION* backslashes in it. Which strikes me as maybe not the best thing. This looks to be the issue that you're hitting: http://projects.puppetlabs.com/issues/4487 It definitely looks like you're hitting 4487, as Nigel said. Right now the fix for that isn't yet available in a released version of Puppet. If you're comfortable running a pre-release version, the fix is in the 2.6.x branch of the git repository. It will be in the next point release of the 2.6.x series, if you don't feel comfortable running a pre-release version of Puppet. -- Jacob Helwig signature.asc Description: Digital signature
Re: 530 million backslashes (was Re: [Puppet Users] So, clientconfigs.sqlite3 is pretty big)
On Sun, 15 May 2011 15:56:01 -0700, Robin Lee Powell wrote: On Sun, May 15, 2011 at 09:57:29AM -0700, Jacob Helwig wrote: On Sun, 15 May 2011 15:33:56 +, Nigel Kersten wrote: This looks to be the issue that you're hitting: http://projects.puppetlabs.com/issues/4487 It definitely looks like you're hitting 4487, as Nigel said. Right now the fix for that isn't yet available in a released version of Puppet. If you're comfortable running a pre-release version, the fix is in the 2.6.x branch of the git repository. It will be in the next point release of the 2.6.x series, if you don't feel comfortable running a pre-release version of Puppet. Great stuff, thanks. Can I run current git on just the master to fix this? -Robin That should do it. It was a completely server-side fix. -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Puppet 2.6.8 -- Thanks
On Wed, 11 May 2011 13:52:32 -0500, David Klann wrote: I'm not sure exactly which bug was fixed, but 2.6.8 has corrected the operation of my users module, which I've been struggling with for several days. I'm new to puppet, and I've been trying to get a small installation running. I was having trouble with SSH authorized_keys. The puppet agent running on a remote server was trying to create an authorized_keys file for a user different than the one specified in the manifest. I upgraded to 2.6.8 and restarted the agent daemon and all seems to be working as I expect. It may have simply been the daemon restart that corrected the behaviour, but in any event it is now working as I would expect. Thanks for all your on-going work to improve and extend Puppet! ~dklann Thank you! As someone working on the Puppet code-base, it means a lot to hear this kind of unsolicited positive feedback. It's far too easy to get bogged down in bug reports, and unexpected behavior, and forget that people have actually chosen to use Puppet, and that there are people that are happy using it. Thank you! -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] ANNOUNCE: Puppet 2.6.8 final available!
This release addresses issues with the Puppet 2.6.x series. Bug #4884: Shell exec provider that executes code as a raw shell script Bug #5670: Failed resources don't improperly trigger a refresh Feature #2331: New macports provider You can find the full release notes for Puppet at: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes This release is available for download at: http://puppetlabs.com/downloads/puppet/puppet-2.6.8.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 2.6.8: http://projects.puppetlabs.com/projects/puppet/ CHANGELOG: 2.6.8 = c1edcb2 add test for ticket 7101 db26326 Move tests from puppet-acceptance repo bee1ef7 Updated CHANGELOG for 2.6.8rc1 8b7444d (#2331) Remove darwinports pkg provider, replace with rewritten macports provider 65c4e14 Fixed #7082 - Added system support for groups b7f4ff7 (#7018) Give more context on the service type's assumptions. Wording tweaks. bb19dea (#7018) explain internals better in service provider documentation 23c9663 maint: Fix sqlite3 require to really be optional 4b73d41 maint: Fix sporadic sqlite error 54b9f5d (#6818) Stop from getting Rails 3 named_scope deprecation warning e493f8a (#6856) Copy dangling symlinks with 'links = manage' File resource. 1e4968e (maint) Indentation fixes 99d78f2 (#6490) Add plugin initialization callback system to core 5d1cb02 Fix #4339 - Locally save the last report to $lastrunreport 306aa30 Fix #4339 - Save a last run report summary to $statedir/last_run_summary.yaml 9bb3018 Fixed #3127 - removed legacy debug code d2bacd3 Fixed #3127 - Fixed gem selection regex 1b66c28 (#5437) Invalidate cached TypeCollection when there was an error parsing 0675c9a (#6937) Adjust formatting of recurse's desc 2cdadf9 (#6937) Document the recurse parameter of File type. 647a640 (#6893) Document the cron type in the case of specials. 87ca313 (#5670) Don't trigger refresh from a failed resource f5aabf5 (#5908) Add support for new update-rc.d disable API 37f9ca0 (#6862) Add a default subject for the mail_patches rake task 9a4de12 Fixed #6256 - Creation of rrd directory. 7c60db5 (#5477) Allow watch_file to watch non-existent files, especially site.pp 7761acb (#5221) Add test for fix to fileset with trailing separator 357514c (#5221) Fix fileset path absoluteness checking with trailing slash f8941b8 (#4769) Fix negative timeout support for newer rubies a29c7fd Fixed #6562 - Minor kick documentation fix df20513 (#6658) Propagate ENC connection errors to the agent 08115c0 (#4884) Remove typo from spec test f2c771b (#4884) Modify tests to pass on non-OS X systems ec1aa19 (#4884) Revise new exec tests, add a few more 196294a (4576) - if ENC declares invalid class, it is logged at warning. 0d2d6f3 (#4884) Add an shell provider for execs d2e911a (#4884) Fix Test::Unit exec tests fa0cfc6 (#4884) Break the exec type out to have a posix provider c86a980 (#4884) Add consistent path validation and behavior 77fbf7f (#4884) Add expand_path to requiring the spec_helper 7ec9057 (#4884) Autorequire shared behaviors and method to silence warnings acc99ba (#4884) Fix whitespace 6a4d291 (#4884) Get rid of open3 require since it wasn't being used 3e7ebbb Fixed #6554 - Missing $haveftool if/else conditional in install.rb breaking Ruby 1.9 fddc165 (#5814) Improved cron type specs f2dfee6 (#5814) cron_spec shouldn't depend on cron provider -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Custom data embedded in Puppet SSL Certs...
On Mon, 25 Apr 2011 19:10:35 -0700, Matt Wise wrote: I'm working out some security issues here and wanted to throw something out there... I'll be digging in tonight to see whether something like this is possible, so I'd appreciate feedback quickly if anyone happens to know if this is possible. Imagine a scenario where our individual hosts actually tell the puppet server which 'config' they want. This is our environment, and its not changeable. (The short explanation — its done this way because we provision nodes in several clouds where hostnames are not known until after a host has booted). For now, our nodes actually check in and say I want XYZ class. I'd like to have our nodes able to do this ONCE ... only when they generate their CSR. After that, I'd like their 'base_class' to be embedded in the CSR (And subsequently the CERT), so that a client cannot later change its mind about what kind of host it is. Essentially I'm thinking the process would be something like this: Client: -) fill in 'base_class' somewhere (puppet.conf?) -) run puppet... host generates private key, and csr, and submits it to the puppet ca master Server: -) process signs CSR and provides Cert back to host (this is automated in our case, but not with autosign.conf) Client: -) begin actual puppet run.. request real configuration Server: -) read 'base_class' from certificate, and fill in $base_class with that data .. Thoughts? Any ideas on a good way to work this out? (my alternative method is going to involve a back-end Amazon SimpleDB script that dumps a nodes base_class into the database the first time ti runs, and then forever-after pulls from SimpleDB to fill in the base_class variable. I dont like this though, as its slow and it adds another service dependency.) I know you've stated that this is your configuration, and it's not changeable, but I'm still confused about what lead you to this setup. I assume that you can trust the puppet master(s). Given that you can generate certificates for arbitrary cert names, how does not knowing the host name of a node until after it boots matter? It seems like just generating cert names that weren't the same as the host name would give you all the security you're looking for, and would solve the classification problem since the 'node name' would be known before-hand (manifests match on cert name not host name, they're just usually the same). Is there something about the provisioning process that prevents pre-generating the certs, and placing the cert an appropriate puppet.conf on the machine before first boot? (This would definitely explain why this approach would be un-workable.) -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] ANNOUNCE: Facter 1.5.9rc5
Facter 1.5.9rc5 is a maintenance release containing fixes and updates. This release candidate addresses an issue with EC2 facts. This ensures that ARP facts are only returned for EC2 hosts. (#6976) As always, please let us know if you run into any problems with any of the release candidates. This release is available for download at: http://puppetlabs.com/downloads/facter/facter-1.5.9rc5.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.5.9rc5: http://projects.puppetlabs.com/projects/facter/ CHANGELOG: 1.5.9rc5 acf0bb2 Ensures that ARP facts are returned only on EC2 hosts -- Jacob Helwig signature.asc Description: Digital signature
[Puppet Users] ANNOUNCE: Puppet Dashbard 1.1.0 Final!
and cleanup whitespace e3010ac (#4401) Modified status query to use the Rails time zone 6b2143f (#4601) Fixes table rendering on group/class/node pages 6605aea (#4661) Fix broken specs for shared behaviors ad7a1c1 (#4661) Classes/groups/nodes are now sorted appropriately c0080fe (#4605) Renamed date_format setting to datetime_format and added separate date_format. 11e883a (#4475) Fixed documentation for passing environment variables to the external node script 66207f4 maint: Fix setting dependent spec d2b37e4 (#4605) Fix timezone issues with chart grouping and start 0db778d (#4605) Allow date_format to be set in settings.yml bc12011 (#4605) Tests for the time_zone setting 047510b (#4605) Added Time zone setting to settings.yml. 8748389 (#3435) Fix broken migration 3f5b59f (#5278) Settings will now individually fallback to values in settings.yml.example faf7612 (#5278) Remove unused arguments to SettingsReader.read a00b741 (#5278) Rename settings-sample.yml to setting.yml.example 3d9dda0 (#5278) Add specs for existing settings functionality 47c88f5 Refine #4475 Add environment variables for all external_node settings 1b9639a Feature #4475 Configurable URL in external_node script fa14898 (#4881) Added daily_run_history_length setting 080912a (#4881) Add a spec for the daily run history partial 3805872 (#3435) Add Node model stub to make migration safer 7f0ab7b (#4474) Add setting to disable node classification 7f4d692 Maint: Move Local-branch: info below --- 37218fb (#4874) Add setting for no_longer_reporting_cutoff 1cff89c (#3435) Reports now have changed/unchanged as statuses 07ccbc4 Maint: add Local-branch: info to mails sent by rake mail_patches 506190f (#4345) Modified README to include workaround for Puppet bug #5244. 6dc4b0c maint: require activesupport from config/environment.rb 806aa69 (#4553) Add log rotation to config/environment.rb 44f27c6 (#4620) Never reported nodes are not considered failing 3b4a218 (#5104) Failed catalog compiles now report as failed 2fd983a (#4636) Add file/line to log and event messages ba91e32 (#4514) Add table of resource events to report view 3b6061c (#4514) Support total time for 2.6 reports b9cf649 (#4514) Support config retrieval time for 2.6 reports 5e1ec78 (#4688) Update README to explain SSL configuration f145e31 (#4688) Add HTTPS support to bin/external_node 5aeb60f maint: rename cert rake tasks to be in the cert namespace fe2cc2b (#4688) Include example SSL settings for apache 4f45405 Maint: Remove delegation from PuppetHttps to Settings c0cf881 (#4688) Get CA cert and CRL list as part of cert rake tasks 254397f (#3531) Moved node/group methods to NodeGroupGraph ba93b70 (#3531) Rename list methods and remove unused methods/files cadccc4 (#3531) Don't leave source for params/groups/classes blank d831eaf (#3531) Remove unused NodeGroupCycleError file 854b7e2 (#3531) Show sources for nodes/group/classes/parameters 7322d79 (#3531) Add helper methods for dealing with the node group graph 35042e0 (#5199) Add setting to disable the inventory service features 1c1c097 (#5133) Document auth.conf security for inventory service c1e6b88 (#2986) Add node search based on facts 8391463 (#2933) Add missing partial for facts 62409a3 (#2933) Add table of facts to node pages 053319e Tightened up permissions on the public/private key pair that is used to contact the master. 263f2b0 (#4604) Dashboard now has a place for site-specific settings e193f9f (#5133) Made Dashboard able to fetch node facts from inventory REST API. a196fd2 (#5149) Added rake tasks to manage certificate and public/private key pair dfb7b1b (#4880) Fixed validation of new reports 1e43615 [#4541] Route to nodes using id instead of name. -- Jacob Helwig signature.asc Description: Digital signature
Re: [Puppet Users] Possible bug in configure script (torque 2.5.5)
On Wed, 30 Mar 2011 18:24:50 +0200, Arnau Bria wrote:
Hi all,
it comes from another issue where David Beer is helping me, but
I faced a configure related issue when applying his solution:
I should build torque 2.5.5 with :
--with-tcp-retry-limit=2
After doing so, I should have a define in pbs_config.h, but
it isn't:
# grep -r TCP_RETRY_LIMIT src/*|grep define
#
I'm not bash expert and maybe I'm assuming something wrong, but looking
at configure script:
# Check whether --with-tcp_retry_limit or --without-tcp_retry_limit was given.
if test ${with_tcp_retry_limit+set} = set; then
withval=$with_tcp_retry_limit
TCP_RETRY_LIMIT=${withval}
else
TCP_RETRY_LIMIT=0
fi;
cat confdefs.h _ACEOF
#define TCP_RETRY_LIMIT ${TCP_RETRY_LIMIT}
_ACEOF
TCP_RETRY_LIMIT define should ALWAYS have be defined and with some
value ( 0 or own specified value).
So, I think this is a bug in configure because:
1.-) If the param should NOT be written always, there's a bug when
enabling it.
2.-) If the param should be written always, there's a bug when writing
.h files.
Find config.log attached.
Cheers,
Arnau
Wrong mailing list?
--
Jacob Helwig
signature.asc
Description: Digital signature
