Re: [Puppet Users] EC2 with puppet bootstrap notes and scripts
On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote: On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory chris...@gmail.com wrote: Hello... # the hostname data is added via something like: # shell ec2-run-instances ... --user-data myservername ami-123abc # by definition, the first line MUST be the hostname # potentially in the future there could be more data curl --silent http://169.254.169.254/2008-02-01/user-data | head -n 1 /etc/hostname hostname --file /etc/hostname # yes, thrice /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com Why do you have to do it three times? I would like to know why you do it too. I've needed to do that because: 1a) This bug http://projects.puppetlabs.com/issues/3561 1b) Sets options in /etc/puppet/puppet.conf 2) Full run (Will be much shorter because lots of stuff was already done in the first run) 3) One last chance just in case something didn't work, timed out, or I forgot a require. (Finishes in seconds for me) Also, I'd advise running puppet with --verbose --debug and then logging the output somewhere. Mostly because if the second run doesn't work, you can see it and have a chance at fixing it.. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet-dashboard
Does puppet-dashboard support something like 'default' node? I want to assign base classes to 'default' node, for applying for all nodes. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: updating kernel in centos shows failure
That only speaks to the initial install. Let's say in 6 months, I update my local mirror to a yet newer version of the kernel. I'm in the same boat. The point of using a tool like Puppet, isn't just to automate your installs, but also upgrades. I'm surprised that this bug is this old, but it seems that it is targeted for the 'Statler' release. Of course, that assignment was 4 months ago so looks like I'll just take a wait and see approach. Steve On Nov 5, 4:37 pm, R P Herrold herr...@owlriver.com wrote: On Fri, 5 Nov 2010, Trevor Hemsley wrote: Steve Hoffman wrote: .../Package[kernel]/ensure) change from 2.6.18-194.el5 to 2.6.18-194.17.4.el5 failed: Could not update: Failed to update to version 2.6.18-194.17.4.el5, got version 2.6.18-194.el5 instead at ... # rpm -qa | grep kernel kernel-2.6.18-194.el5 kernel-2.6.18-194.17.4.el5 This is a long standing bug that currently seems to have no action scheduled for it. https://projects.puppetlabs.com/issues/1720 gee -- a two year old bug This 'issue' is readily solveable by a person running their mirror locally of the desired content -- Upstreams retire content. If you are counting on being able to access a specific version, run a mirror -- Russ herrold herrold at centos dot org -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
When a generic EC2 instance is started it has a hostname of
localhost.localdomain (or something like ip-10-111-222-33), a
searchdomain of ec2.internal, and only the loopback address
in /etc/hosts. To get a puppet client to bootstrap correctly all three
of these things need to be changed. The searchdomain
in /etc/resolv.conf is reset on each boot by the dhcp client. To 'fix'
this you can add 'supersede domain-name example.com;'
to /etc/dhcp3/dhclient.conf. and add 'server.ip.addr.ess
puppetmaster.example.com' to /etc/hosts. To get the hostname changed
without generating custom AMIs for each server I used a small script
called by rc.local to set the hostname, then startup the puppet client.
My complete setup is a little more complicated, but to just do these
three things looks something like the following.
This is precisely why I set the contents of /etc/puppet/certname to
the hostname I want the box to have. In /etc/cron.d/puppet and the
Puppet master's config.ru, I set the --certname parameter to the
contents of that file, thus Puppet never has to deal with the
worthless IP-based hostnames assigned by EC2.
In /etc/cron.d/puppet:
puppet agent --certname=$(cat /etc/puppet/certname) --no-daemonize --onetime
In config.ru:
ARGV --certname=#{File.read(/etc/puppet/certname).chomp}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
Hi, Excerpts from Christopher McCrory's message of Sun Nov 07 12:52:48 -0500 2010: I wanted to be able to startup an EC2 instance with one command and have a fully functioning server without having to shell into each new instance and configure the bits to allow puppet to finish the configuration. Here are some notes I came up with for bootstrapping an ec2 instance with puppet using Ubuntu 10.04. On the same topic I've outlined in a series of blog posts [1] how Ubuntu 10.04 images can be bootstrapped and managed in EC2 and UEC. [1]: https://ubuntumathiaz.wordpress.com/category/puppet/ Once the puppetmaster is up and running starting a new instance is just a matter of running one command: start_instance.py webserver start_instance.py proxyserver It uses the native support for puppet provided in cloud-init so that the standard Ubuntu AMI is used. The puppet master isn't using auto-signing as S3 is used to store legitimate puppet clients. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] Default ownership for static files
- Markus Falb markus.f...@fasel.at wrote:
Hi,
I try to serve a file
file { /root/test3.txt:
ensure = file,
source = puppet:///yum/test.txt,
}
On the puppetmaster this files look like this
#$ ls -n test.txt
-rw-r--r-- 1 502 301 4 8 Nov 16:25 test.txt
Finally, here is my question: What ownership may I expect on the
resulting file ?
Do not rely on this behavior, specify the owner and mode in your file{}
resources.
That is the only reliable way.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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: Prevent users from creating new accounts
* Bruce Richardson itsbruce at workshy.org [2010/11/05 09:01]: [...] If developers, then there is always a way round - sudo, fakeroot, giving them virtual hosts to play with. I'd like to second the virtual host suggestion -- throwaway VMs (or zones, in solaris) work really well for this kind of situation. Additionally, they reinforce repeatability, automation, and encapsulation, qualities that sysadmins desire but developers tend to be ignorant of. -- If history teaches us anything, it's that everyone will be part of the problem, but not everyone will be part of the solution. -- Larry Wall -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] agent needs to make two runs before master compiles new catalog
Hi all, I'm a new puppet user and new to the forum. I just switched my Puppetmaster to running inside Apache (via Passenger). When I make a change to a resource on the master, it sometimes takes a given node TWO runs before the master will realize the resource has changed and recompile a new catalog version for the node. For example, say my puppetmaster is serving configuration version '123' to a node. I change the file permissions for a file resource that's part of that catalog and then do a puppet run on the node. If I'm running with Passenger, the master serves config version '123' one more time (the agent makes no changes). The next time I run the node's agent, the master compiles new catalog version '456' and the agent makes the permission change. A few items of note: 1. This is not a problem with all changes to puppet module content. For example, if I change the source contents of a file in the 'files' directory of a module, the master will notice this immediately and the puppet agent on the node will grab the new file on the first run following the change on the master. 2. At first I thought maybe this was a timing issue (e.g. I was doing the puppet run too quickly after making the resource change) but it's not; whether I wait 5 seconds or 5 minutes before making the first puppet run, the master still doesn't notice the change. I set the 'filetimeout' setting in /etc/puppet/puppet.conf to 0 and it didn't help. Any ideas on what's going on here? (thanks in advance for your help) -Kent -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] file_exists function
I am still new to the ruby language and I figured I'd share my file_exists
function to see if it is the correct approach and to offer it out there for
people who may have the same issue. We build our vhosts based off a template
and have come across the need to add in items for specific customers in
their vhost. The problem is if you file() and the file does not exist puppet
throws an error and does not continue to run that manifest. The solution was
to add in a file_exists function to allow us to bypass that issue.
require 'puppet'
module Puppet::Parser::Functions
newfunction(:file_exists, :type = :rvalue) do |args|
if File.exists?(args[0])
return 1
else
return 0
end
end
end
define customer::vhost($env, $url = , $aliases = ) {
if file_exists(customers/$name/$env/web/httpd.conf) == 1 {
$extra = file(customers/$name/$env/web/httpd.conf)
}
file { $name.conf:
path = /etc/httpd/conf.d/$name.conf,
owner = root,
group = root,
mode = 644,
require = Package[httpd],
content = template(customers/cust-vhost.erb),
}
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] Question about refreshonly
I have inherited some puppet configurations; there is an exec resource
that looks like this:
exec { force-reload-httpd:
command = /etc/rc.d/init.d/httpd force-reload,
refreshonly = true,
}
Should this be paired with a subscribe or notify somewhere?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Question about refreshonly
Refreshonly will execute when it is either notified or the subscribe
resource changes. If there is none of those definition then that Exec
will never execute.
On Nov 8, 9:49 am, Sean Carolan scaro...@gmail.com wrote:
I have inherited some puppet configurations; there is an exec resource
that looks like this:
exec { force-reload-httpd:
command = /etc/rc.d/init.d/httpd force-reload,
refreshonly = true,
}
Should this be paired with a subscribe or notify somewhere?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: file_exists function
Oops I guess that'll teach me for trying to use a shortcut for
posting.
On Nov 8, 11:57 am, Matthew Black mjbl...@gmail.com wrote:
I am still new to the ruby language and I figured I'd share my file_exists
function to see if it is the correct approach and to offer it out there for
people who may have the same issue. We build our vhosts based off a template
and have come across the need to add in items for specific customers in
their vhost. The problem is if you file() and the file does not exist puppet
throws an error and does not continue to run that manifest. The solution was
to add in a file_exists function to allow us to bypass that issue.
require 'puppet'
module Puppet::Parser::Functions
newfunction(:file_exists, :type = :rvalue) do |args|
if File.exists?(args[0])
return 1
else
return 0
end
end
end
define customer::vhost($env, $url = , $aliases = ) {
if file_exists(customers/$name/$env/web/httpd.conf) == 1 {
$extra = file(customers/$name/$env/web/httpd.conf)
}
file { $name.conf:
path = /etc/httpd/conf.d/$name.conf,
owner = root,
group = root,
mode = 644,
require = Package[httpd],
content = template(customers/cust-vhost.erb),
}
}- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] Default ownership for static files
On 08.11.10 17:03, R.I.Pienaar wrote:
- Markus Falb markus.f...@fasel.at wrote:
Hi,
I try to serve a file
file { /root/test3.txt:
ensure = file,
source = puppet:///yum/test.txt,
}
On the puppetmaster this files look like this
#$ ls -n test.txt
-rw-r--r-- 1 502 301 4 8 Nov 16:25 test.txt
Finally, here is my question: What ownership may I expect on the
resulting file ?
Do not rely on this behavior, specify the owner and mode in your file{}
resources.
That is the only reliable way.
It seems so, but do we want things this way ? I knew that I can specify
owner explicitly, instead I wanted to question the defaults.
When puppetd runs as root and without defined otherwise files should be
created with owner root in my opinion. Why should one assume that uids
on puppetmaster and client are synchronised ? Forget to define one
ownership in your manifests and possibly unrelated users on the client
can access these files unintentionally.
I think thats a security flaw. I would like to rely on reasonable
defaults. I think about opening a ticket for this.
I try in other words: A file on puppetmaster belongs to user x with uid
y and it is created on the client with uid y whatever user this
translates to. Is this intended ?
--
Best Regards,
Markus Falb
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] EC2 with puppet bootstrap notes and scripts
On Mon, Nov 8, 2010 at 2:17 AM, Patrick kc7...@gmail.com wrote: On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote: On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory # yes, thrice /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com Why do you have to do it three times? I would like to know why you do it too. I've needed to do that because: 1a) This bug http://projects.puppetlabs.com/issues/3561 That's a legitimate reason, but there are ways to avoid this. 1b) Sets options in /etc/puppet/puppet.conf ? Why isn't this just a templated config file? Then you just need to supply appropriate arguments on your first bootstrapping invocation. 2) Full run (Will be much shorter because lots of stuff was already done in the first run) 3) One last chance just in case something didn't work, timed out, or I forgot a require. (Finishes in seconds for me) Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] Question about refreshonly
On Mon, Nov 8, 2010 at 6:49 AM, Sean Carolan scaro...@gmail.com wrote:
I have inherited some puppet configurations; there is an exec resource
that looks like this:
exec { force-reload-httpd:
command = /etc/rc.d/init.d/httpd force-reload,
refreshonly = true,
}
Should this be paired with a subscribe or notify somewhere?
The easiest way to locate the dependency is to generate a .dot file
with the option --graph. You can either check the output visually or
grep for Exec[force-reload-httpd] and see if it has any relationship
(which would be - to some other resource).
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] stages and modules
I am trying to implement stages in 2.6.2 (both client and server)
site.pp
stage { [baseos, pre, post, brsoft]: }
class runstages { Stage[baseos] - Stage[pre] - Stage[main] -
Stage[post] - Stage[brsoft] }
node default {
include runstages
include debian::base_packages
}
end
packages.pp
class debian::base_packages {
include debian::apt
package { lsof: ensure = installed }
SNIP
}
class {debian::base_packages: stage = baseos }
end
But when I run the agent with noop:
notice: /Stage[main]/Debian::Base_packages/Package[lsof]/ensure: is
purged, should be present (noop)
The stage still shows as main.
What am I overlooking?
Thank you.
(sorry if this is a duplicate.)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote: On Mon, Nov 8, 2010 at 2:17 AM, Patrick kc7...@gmail.com wrote: On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote: On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory # yes, thrice /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com /usr/sbin/puppetd --no-daemonize --onetime --server puppetmaster.example.com Why do you have to do it three times? I would like to know why you do it too. I've needed to do that because: 1a) This bug http://projects.puppetlabs.com/issues/3561 That's a legitimate reason, but there are ways to avoid this. 1b) Sets options in /etc/puppet/puppet.conf ? Why isn't this just a templated config file? Then you just need to supply appropriate arguments on your first bootstrapping invocation. I'm not quite sure what you mean. My puppet.conf is a templated config file and I copy it in place using puppet during the first run. 2) Full run (Will be much shorter because lots of stuff was already done in the first run) 3) One last chance just in case something didn't work, timed out, or I forgot a require. (Finishes in seconds for me) Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. But because of the randomness, I don't always discover missing requires during testing. I do look over the log file though and if the last run did something, I can then look into it and fix it. It theory this might mean I need more testing. In practice, the order randomization makes it impossible to ever be sure there are no missing requires that will cause a run to fail. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] Default ownership for static files
On Nov 8, 2010, at 9:36 AM, Markus Falb wrote:
On 08.11.10 17:03, R.I.Pienaar wrote:
- Markus Falb markus.f...@fasel.at wrote:
Hi,
I try to serve a file
file { /root/test3.txt:
ensure = file,
source = puppet:///yum/test.txt,
}
On the puppetmaster this files look like this
#$ ls -n test.txt
-rw-r--r-- 1 502 301 4 8 Nov 16:25 test.txt
Finally, here is my question: What ownership may I expect on the
resulting file ?
Do not rely on this behavior, specify the owner and mode in your file{}
resources.
That is the only reliable way.
It seems so, but do we want things this way ? I knew that I can specify
owner explicitly, instead I wanted to question the defaults.
When puppetd runs as root and without defined otherwise files should be
created with owner root in my opinion. Why should one assume that uids
on puppetmaster and client are synchronised ? Forget to define one
ownership in your manifests and possibly unrelated users on the client
can access these files unintentionally.
I think thats a security flaw. I would like to rely on reasonable
defaults. I think about opening a ticket for this.
I try in other words: A file on puppetmaster belongs to user x with uid
y and it is created on the client with uid y whatever user this
translates to. Is this intended ?
I'm pretty sure it was intended because I don't think that would happen by
accident. Someone would have needed to write the code to do that.
Now, is it a good idea? I con't help you there.
If you think it's a problem, I would consider filing a bug.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] agent needs to make two runs before master compiles new catalog
On Nov 8, 2010, at 9:10 AM, Kent wrote: Hi all, I'm a new puppet user and new to the forum. I just switched my Puppetmaster to running inside Apache (via Passenger). When I make a change to a resource on the master, it sometimes takes a given node TWO runs before the master will realize the resource has changed and recompile a new catalog version for the node. For example, say my puppetmaster is serving configuration version '123' to a node. I change the file permissions for a file resource that's part of that catalog and then do a puppet run on the node. If I'm running with Passenger, the master serves config version '123' one more time (the agent makes no changes). The next time I run the node's agent, the master compiles new catalog version '456' and the agent makes the permission change. A few items of note: 1. This is not a problem with all changes to puppet module content. For example, if I change the source contents of a file in the 'files' directory of a module, the master will notice this immediately and the puppet agent on the node will grab the new file on the first run following the change on the master. Fact: Files sent using source aren't part of the catalog. Instead, the client asks the server for them while the client is using the catalog and not during the compilation done on the server. Speculation: I would guess this is because the problem you are having is happening during the compilation on the server. 2. At first I thought maybe this was a timing issue (e.g. I was doing the puppet run too quickly after making the resource change) but it's not; whether I wait 5 seconds or 5 minutes before making the first puppet run, the master still doesn't notice the change. I set the 'filetimeout' setting in /etc/puppet/puppet.conf to 0 and it didn't help. Any ideas on what's going on here? (thanks in advance for your help) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] file_exists function
Going to post this again as I posted by accident in another thread..
I am still new to the ruby language and I figured I'd share my
file_exists
function to see if it is the correct approach and to offer it out
there for
people who may have the same issue. We build our vhosts based off a
template
and have come across the need to add in items for specific customers
in
their vhost. The problem is if you file() and the file does not exist
puppet
throws an error and does not continue to build that manifest. The
solution was
to add in a file_exists function to allow us to bypass that issue.
require 'puppet'
module Puppet::Parser::Functions
newfunction(:file_exists, :type = :rvalue) do |args|
if File.exists?(args[0])
return 1
else
return 0
end
end
end
define customer::vhost($env, $url = , $aliases = ) {
if file_exists(customers/$name/$env/web/httpd.conf) == 1 {
$extra = file(customers/$name/$env/web/httpd.conf)
}
file { $name.conf:
path = /etc/httpd/conf.d/$name.conf,
owner = root,
group = root,
mode = 644,
require = Package[httpd],
content = template(customers/cust-vhost.erb),
}
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
On Mon, Nov 8, 2010 at 10:51 AM, Patrick kc7...@gmail.com wrote:
On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
On Mon, Nov 8, 2010 at 2:17 AM, Patrick kc7...@gmail.com wrote:
On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
# yes, thrice
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
Why do you have to do it three times?
I would like to know why you do it too. I've needed to do that because:
1a) This bug http://projects.puppetlabs.com/issues/3561
That's a legitimate reason, but there are ways to avoid this.
1b) Sets options in /etc/puppet/puppet.conf
? Why isn't this just a templated config file? Then you just need to supply
appropriate arguments on your first bootstrapping invocation.
I'm not quite sure what you mean. My puppet.conf is a templated config file
and I copy it in place using puppet during the first run.
Perhaps I'm confused by your 1b) notation? Is this within the first
run? If so, then we're in agreement.
2) Full run (Will be much shorter because lots of stuff was already done
in the first run)
3) One last chance just in case something didn't work, timed out, or I
forgot a require. (Finishes in seconds for me)
Honestly, you should be discovering such missing requires in your testing
process. It's not good practice to simply run another one just in case in
my opinion.
But because of the randomness, I don't always discover missing requires
during testing. I do look over the log file though and if the last run did
something, I can then look into it and fix it.
It theory this might mean I need more testing. In practice, the order
randomization makes it impossible to ever be sure there are no missing
requires that will cause a run to fail.
What would make debugging and discovering these situations easier for you then?
I have some simple rules that honestly removed most these problems for me.
Specify relationships within a class at the resource level.
Specify relationships across classes at the class level.
e.g.
class foo {
file { foofile:
require = Package[foopkg],
}
package { foopkg:
...
}
}
class bar {
file {barfile:
require = Class[foo],
}
}
but I'm still interested to hear ideas about how we could make
discovering these issues easier.
Have you tried generating a --graph dot output? I've found that simply
visualizing the catalog like this can display obvious problems.
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] stages and modules
On Nov 8, 2010, at 10:27 AM, chris mague wrote: I am trying to implement stages in 2.6.2 (both client and server) Chris / kekai? Are you back to doing sysadmin work? Good to see you man. I haven't made the leap to 2.6 yet so I can't help with your question but wanted to say hi. (Assuming I haven't got the wrong guy, sorry if so) -=Eric -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] stages and modules
Ack, sorry list. That was obviously meant to be unicast. Reply-To Considered Harmful. http://marc.merlins.org/netrants/reply-to-harmful.html -=Eric -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
3) One last chance just in case something didn't work, timed out, or I forgot a require. (Finishes in seconds for me) Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. +1. Catalogs that need to converge or are anything but a no-op on their second run should be considered broken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
On Nov 8, 2010, at 12:12 PM, Richard Crowley wrote: 3) One last chance just in case something didn't work, timed out, or I forgot a require. (Finishes in seconds for me) Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. +1. Catalogs that need to converge or are anything but a no-op on their second run should be considered broken. *) My philosophy is this puppet.conf should be managed by puppet. *) Sometimes a run won't be completed correctly unless puppet.conf is up to date at the start of a run. Which of these do you disagree with? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
On Nov 8, 2010, at 11:10 AM, Nigel Kersten wrote:
On Mon, Nov 8, 2010 at 10:51 AM, Patrick kc7...@gmail.com wrote:
On Nov 8, 2010, at 9:54 AM, Nigel Kersten wrote:
On Mon, Nov 8, 2010 at 2:17 AM, Patrick kc7...@gmail.com wrote:
On Nov 7, 2010, at 10:45 PM, Nigel Kersten wrote:
On Sun, Nov 7, 2010 at 9:52 AM, Christopher McCrory
# yes, thrice
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
/usr/sbin/puppetd --no-daemonize --onetime --server
puppetmaster.example.com
Why do you have to do it three times?
I would like to know why you do it too. I've needed to do that because:
1a) This bug http://projects.puppetlabs.com/issues/3561
That's a legitimate reason, but there are ways to avoid this.
1b) Sets options in /etc/puppet/puppet.conf
? Why isn't this just a templated config file? Then you just need to supply
appropriate arguments on your first bootstrapping invocation.
I'm not quite sure what you mean. My puppet.conf is a templated config file
and I copy it in place using puppet during the first run.
Perhaps I'm confused by your 1b) notation? Is this within the first
run? If so, then we're in agreement.
Yes. These are both the same run. I just meant that is what happens that
really matters.
2) Full run (Will be much shorter because lots of stuff was already done
in the first run)
3) One last chance just in case something didn't work, timed out, or I
forgot a require. (Finishes in seconds for me)
Honestly, you should be discovering such missing requires in your testing
process. It's not good practice to simply run another one just in case in
my opinion.
But because of the randomness, I don't always discover missing requires
during testing. I do look over the log file though and if the last run did
something, I can then look into it and fix it.
It theory this might mean I need more testing. In practice, the order
randomization makes it impossible to ever be sure there are no missing
requires that will cause a run to fail.
What would make debugging and discovering these situations easier for you
then?
I have some simple rules that honestly removed most these problems for me.
Specify relationships within a class at the resource level.
Specify relationships across classes at the class level.
e.g.
class foo {
file { foofile:
require = Package[foopkg],
}
package { foopkg:
...
}
}
class bar {
file {barfile:
require = Class[foo],
}
}
but I'm still interested to hear ideas about how we could make
discovering these issues easier.
The only ordering problems I've missed are ones between execs and files in the
same class, but every few months I miss one.
This third run, which normally functions the same as --noop, is just a last
check just in case. The only reason I don't make it a --noop is because if I
screw up, I want the problem to be automatically be fixed, as well as reported
to me.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] How can I reload environment variable file using puppet?
Hi I'm trying to setting http_proxy environment variable by adding it
to the /etc/environment file.
I was wondering how I can force puppet to reload this file whenever
the file changes.
I have tried a few things and none of them have worked,
1.)
exec { source_environment:
command = source /etc/environment,
subscribe = File[/etc/environment],
refreshonly = true
}
2.)
exec { source /etc/environment:
subscribe = File[/etc/environment],
refreshonly = true
}
3.)
exec { export http_proxy=http://localhost:3128:
subscribe = File[/etc/environment],
refreshonly = true
}
Is there a better way to do this? I just need to ensure that the
environment var http_proxy is globally set.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
+1. Catalogs that need to converge or are anything but a no-op on their second run should be considered broken. *) My philosophy is this puppet.conf should be managed by puppet. *) Sometimes a run won't be completed correctly unless puppet.conf is up to date at the start of a run. Which of these do you disagree with? In practice, I disagree with the first. My /etc/puppet/puppet.conf isn't managed by Puppet. On masters, all of /etc/puppet is deployed via Capistrano. On agents, /etc/puppet/puppet.conf is written by a bootstrap.sh program when the server comes up for the first time. My puppet.conf is only 5 lines long and has never changed. I may be in the extreme minority here. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] How can I reload environment variable file using puppet?
Hi I'm trying to setting http_proxy environment variable by adding it
to the /etc/environment file.
I was wondering how I can force puppet to reload this file whenever
the file changes.
I have tried a few things and none of them have worked,
1.)
exec { source_environment:
command = source /etc/environment,
subscribe = File[/etc/environment],
refreshonly = true
}
2.)
exec { source /etc/environment:
subscribe = File[/etc/environment],
refreshonly = true
}
3.)
exec { export http_proxy=http://localhost:3128:
subscribe = File[/etc/environment],
refreshonly = true
}
Is there a better way to do this? I just need to ensure that the
environment var http_proxy is globally set.
No subshell will be able to modify the parent's environment, which is
what you're after. Try setting environment variables in the Puppet
process's environment:
rcrow...@wd-40:~$ puppet apply test.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Exec[sh -c 'echo $HOOAH /tmp/foo']/returns:
executed successfully
rcrow...@wd-40:~$ cat /tmp/foo
rcrow...@wd-40:~$ HOOAH=hooah puppet apply test.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Exec[sh -c 'echo $HOOAH /tmp/foo']/returns:
executed successfully
rcrow...@wd-40:~$ cat /tmp/foo
hooah
rcrow...@wd-40:~$
Setting values in /etc/environment will probably work provided you
restart the Puppet process in question after the contents of that file
have been set.
Hope that helps,
Richard
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How can I reload environment variable file using puppet?
Thanks for you help.
Does that mean that there is no way to do it from inside of a puppet
module?
On Nov 8, 5:11 pm, Richard Crowley r...@rcrowley.org wrote:
Hi I'm trying to setting http_proxy environment variable by adding it
to the /etc/environment file.
I was wondering how I can force puppet to reload this file whenever
the file changes.
I have tried a few things and none of them have worked,
1.)
exec { source_environment:
command = source /etc/environment,
subscribe = File[/etc/environment],
refreshonly = true
}
2.)
exec { source /etc/environment:
subscribe = File[/etc/environment],
refreshonly = true
}
3.)
exec { export http_proxy=http://localhost:3128:
subscribe = File[/etc/environment],
refreshonly = true
}
Is there a better way to do this? I just need to ensure that the
environment var http_proxy is globally set.
No subshell will be able to modify the parent's environment, which is
what you're after. Try setting environment variables in the Puppet
process's environment:
rcrow...@wd-40:~$ puppet apply test.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Exec[sh -c 'echo $HOOAH /tmp/foo']/returns:
executed successfully
rcrow...@wd-40:~$ cat /tmp/foo
rcrow...@wd-40:~$ HOOAH=hooah puppet apply test.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Exec[sh -c 'echo $HOOAH /tmp/foo']/returns:
executed successfully
rcrow...@wd-40:~$ cat /tmp/foo
hooah
rcrow...@wd-40:~$
Setting values in /etc/environment will probably work provided you
restart the Puppet process in question after the contents of that file
have been set.
Hope that helps,
Richard
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
On Nov 8, 2010, at 2:03 PM, Richard Crowley wrote: +1. Catalogs that need to converge or are anything but a no-op on their second run should be considered broken. *) My philosophy is this puppet.conf should be managed by puppet. *) Sometimes a run won't be completed correctly unless puppet.conf is up to date at the start of a run. Which of these do you disagree with? On agents, /etc/puppet/puppet.conf is written by a bootstrap.sh program when the server comes up for the first time. My puppet.conf is only 5 lines long and has never changed. I may be in the extreme minority here. I used to do this, but then I wanted to turn on reporting on the clients and at that point I started pushing out puppet's config so that I wouldn't need to change puppet.conf on each computer individually. Later I changed it again to turn on pluginsync. By that time I got tired of managing puppet.conf in two places so I just manage it using puppet now. Why would you use Capistrano to manage puppet.conf on your masters? Does it give you some advantage over just using puppet to manage itself? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
Nigel Kersten ni...@puppetlabs.com writes: Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. That's easy to say in theory, but extremely difficult to test in practice, since order is non-deterministic and therefore you may not notice a missing requires unless you get lucky, even in test. You need multiple iterations in test to probabilistically find all missing requires, which quickly becomes more trouble than it's worth when the only drawback is requiring multiple Puppet runs. We too consider this to be a bug, but it's a low-priority bug that we fix when we notice it, which can take a while. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] extraneous messages/multiple fact loads
On Mon, Nov 8, 2010 at 3:14 PM, Derek Yarnell de...@umiacs.umd.edu wrote: For a long time now when we run puppetd --test I get the following double output on our custom facts, Anyone seen this behavior? Yes there's a bug filed with this issue: http://projects.puppetlabs.com/issues/3741 Please append any additional info regarding this issue to that ticket. Thanks, Nan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] EC2 with puppet bootstrap notes and scripts
Why would you use Capistrano to manage puppet.conf on your masters? Does it give you some advantage over just using puppet to manage itself? We have about half a dozen different web applications that we deploy, all via git-archive(1) and Capistrano. The Puppet master is one of those and is deployed that way for consistency. When I built it this seemed completely reasonable and a nice way out of chicken-and-egg problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] question about custom facts and environmental variables
I am having a great deal of trouble using a custom fact in a module and I am
hoping someone can help me out.
I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are
really old versions.
The custom fact is defined using an environmental variable
export FACTER_VERTICAL=dev fit
and I can see the fact in the output of facter
[x ~]# facter | grep -i vertical
vertical = dev fit
In the module I am trying to use the fact in the following way
file{ /etc/yum.repos.d/env32-envision.repo:
ensure = present,
mode = 0664,
owner= root,
group= root,
content = $vertical ? {
dev fit =
template(ads_yum2/env32-dev-fit.repo.erb),
default =
template(ads_yum2/env32-dev-staging.repo.erb),
require = File[/etc/yum.repos.d/base_os.repo],
}
}
When I restart puppet the output is the default option instead of the dev
fit option. If I run puppet interactively puppetd --debug --test I get
the correct output based on the custom fact. I understand that puppet will
not inherent environmental variables but since the fact is present I thought
this approach would work. Am I wrong?
I have been banging my head against the wall over this for some time. I
appreciate any input.
Thanks
Ed
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: client won't use remote file bucket
Hi James.
Could you tell if you found a resolution to this problem? I seem to
experience it as well.
Thanks in advance,
Regards,
Roman
On Oct 20, 2:31 am, luke.bigum luke.bi...@fasthosts.co.uk wrote:
Hi all,
I'm having a stupid moment getting a remote file bucket working. My
client only file buckets locally, not remotely.
I have this site.pp:
*
filebucket { main: server = puppet }
File { backup = main }
node 'default' {
include test}
*
and this test module:
*
class test {
file { /etc/sudoers:
source = puppet:///modules/test/sudoers,
owner = root,
group = root,
mode = 0440,
ensure = present,
backup = main,
}}
*
$ puppetd --test --environment testing
...
info: FileBucket adding /etc/sudoers as {md5}
fee30f6b0672f6c174709249f37380d4
info: /Stage[main]/Test/File[/etc/sudoers]: Filebucketed /etc/sudoers
to main with sum fee30f6b0672f6c174709249f37380d4
notice: Finished catalog run in 0.49 seconds
According to the Apache logs (I use Passenger) the only PUT request
it's doing is for it's report:
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] GET /testing/
catalog/... 200 1439 - -
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] GET /testing/
file_metadata/modules/test/sudoers HTTP/1.1 200 307 - -
10.44.222.42 - - [19/Oct/2010:16:18:26 +0100] GET /testing/
file_content/modules/test/sudoers HTTP/1.1 200 1421 - -
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] GET /testing/
file_content/modules/test/sudoers HTTP/1.1 200 1421 - -
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] GET /testing/
file_metadata/modules/test/sudoers HTTP/1.1 200 307 - -
10.44.222.42 - - [19/Oct/2010:16:18:27 +0100] PUT /testing/report/
puppet-test.fasthosts.net.uk HTTP/1.1 200 35 - -
I've also stopped Apache and started up the Webrick Puppet Master,
same result, no file bucketed to the server.
Can someone point out what I've missed?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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.
