Re: [Puppet Users] puppet-module-apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi These are the ones I know about: http://github.com/camptocamp/puppet-apache http://github.com/wesabe/puppet-apache2 http://github.com/puppet-modules/puppet-apache http://github.com/simpsonjulian/puppet-apache-ubuntu http://github.com/ohlol/puppet-apache or the one at https://labs.riseup.net/code/projects/shared-apache which is developed by several people, works on Centos, Debian and OpenBSD and can even setup itk-specific things and in combination with other modules such as the webhosting [1], you have the possibility to create a whole webhosting account with only a few lines of puppet code. More modules can be found at [2]. cheers pete. [1] https://labs.riseup.net/code/projects/shared-webhosting [2] https://labs.riseup.net/code/projects/sharedpuppetmodules -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqXC8ACgkQbwltcAfKi3/f+ACeJ4LDKFGJX2ncOwWIwazMFBPX 7w0AoLRCtyZavAXY4rnGMR+hTJDgzmsQ =k9Ib -END PGP SIGNATURE- -- 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] multiple OS support conventions?
On Tuesday 11 May 2010, ext Dick Davies wrote:
I've been using Puppet very happily for the last 6 months
or so to manage our CentOS and RHEL servers.
Over the summer I want to knock things up a notch bam /,
and part of that is going to be supporting a wider range of OSes.
First on the hit list are likely to be Solaris 10 and Suse
(SLES).
I know a lot of people do support multiple OSes, just wondered
what sort of approach you've found works best?
I've been doing it like this, for an example module
named baselayout:
modules/baselayout/manifests/init.pp:
import *
class baselayout {
case $operatingsystem {
Darwin: { include baselayout::mac }
OpenSuSE: { include baselayout::suse }
}
}
modules/baselayout/manifests/mac.pp:
class baselayout::mac {
...
}
modules/baselayout/manifests/suse.pp:
class baselayout::suse {
...
}
... etc. I've just started, so there could be problems with this I
haven't hit yet.
--
Rohan
--
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] puppet-module-apache
http://github.com/camptocamp/puppet-apache http://github.com/wesabe/puppet-apache2 http://github.com/puppet-modules/puppet-apache http://github.com/simpsonjulian/puppet-apache-ubuntu http://github.com/ohlol/puppet-apache I'd be delighted to see my apache module be made redundant. Every module I tried either: - had assumptions that I didn't like (e.g. one depended on augeas and I'm not a fan of machine-edited files), - had baked-in things like file locations from RedHat-style distros (cough *extlookup*) - only worked on Puppet 0.25 for no discernible reason If we agree on some features that we'd all like, then we could describe those in a cucumber spec. And then test it on the matrix of operating systems and Puppet versions - which Hudson ought to do nicely. J. -- 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] puppet-module-apache
- Julian Simpson simpsonjul...@gmail.com wrote: - only worked on Puppet 0.25 for no discernible reason I'd consider this a feature at this point. We dont want to be the next php4. -- R.I.Pienaar -- 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] puppet-module-apache
I've open-sources Digg's apache module: http://github.com/plathrop/puppet-module-apache I know this isn't much more advanced than what I've seen a lot of people using. Here's my proposition, though. Let's get all the disparate apache modules out there merged together into One Awesome Module. What do you think? One module to rule them all One module to find them One module to bring them all And via Puppet bind them. Excellent initiative ! Things I see missing in most of the apache modules found out there and which we worked on in ours (http://github.com/camptocamp/puppet-apache) include: - abstraction of debian/ubuntu - redhat/centos differences (I agree by debianizing the way apache works on redhat) - management of ssl certificates - selinux support for redhat/centos Furthermore, I'd like to drive your attention to the fact that augeas has experimental support for apache-like configuration files. Maybe would it be an idea to use this to edit config files shipped by the distribution instead of overwriting them with files/templates from the module ? Marc -- 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: Disabling exec type output
How can I stop the returns successfully messages from the exec {}
type unless their is a failure? Don't really want to see it. Using
logoutput = on_failure with exec doesn't seem to work (as this person
says
herehttp://unimpressed.org/post/93835992/disabling-puppets-executed-succe...).
I also tried that however, with:
exec {
dummy-passwd-${name}:
command = cat /etc/passwd | grep \^${name}\
/var/sftp/chroot/${name}/etc/passwd,
onlyif = test /var/sftp/chroot/${name}/etc,
logoutput = on_failure,
tag = bitbucket;
}
Use 'unless' instead of 'onlyif' ... you want to run the command
_unless_ the test returns positive (ie. the file exists). In your
case, its running each time so the behaviour is correct (but not as
you expect). You could also use 'creates' instead:
exec {dummy-password-${name}:
command = cat /etc/passwd | grep \^${name}\ /var/sftp/chroot/$
{name}/etc/passwd,
creates = /var/sftp/chroot/${name}/etc
}
Consult the reference docs for all the parameters and behaviour for
exec: http://docs.puppetlabs.com/references/stable/type.html#exec
ken.
--
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: multiple OS support conventions?
My approach to manage different OS is similar to the ones suggested
before.
With these basic buidelines:
- When differences among OS are rather substancial, include specific
subclasses:
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
- When differences are just packages names, config file paths and so
on, managge differences in a specific params subclass where interla
variables are defined accoring to the OS:
class apache::params {
# Basic settings
$packagename = $operatingsystem ? {
freebsd = apache20,
debian = apache2,
ubuntu = apache2,
default = httpd,
}
$servicename = $operatingsystem ? {
debian = apache2,
ubuntu = apache2,
default = httpd,
}
$username = $operatingsystem ? {
debian = www-data,
ubuntu = www-data,
default = apache,
}
$configfile = $operatingsystem ?{
freebsd = /usr/local/etc/apache20/httpd.conf,
ubuntu = /etc/apache2/apache2.conf,
debian = /etc/apache2/apache2.conf,
default = /etc/httpd/conf/httpd.conf,
}
$configdir = $operatingsystem ?{
freebsd = /usr/local/etc/apache20,
ubuntu = /etc/apache2,
debian = /etc/apache2,
default = /etc/httpd/conf,
}
$documentroot = $operatingsystem ?{
debian = /var/www,
ubuntu = /var/www,
suse= /srv/www,
default = /var/www/html,
}
}
...
In the above examples my default is RedHat/Centos, but it should be
better to explicitely define them.
- Classic Package-Service-ConfigFiles cases are manage in an unique
class:
class apache {
require apache::params
package { apache:
name = ${apache::params::packagename},
ensure = present,
}
service { apache:
name = ${apache::params::servicename},
ensure = running,
enable = true,
pattern = ${apache::params::servicepattern},
hasrestart = true,
hasstatus = true,
require = Package[apache],
subscribe = File[httpd.conf],
}
file { httpd.conf:
# mode = 644, owner = root, group = root,
require = Package[apache],
ensure = present,
path = ${apache::params::configfile},
}
case $operatingsystem {
debian: { include apache::debian }
ubuntu: { include apache::debian }
default: { }
}
if $backup == yes { include apache::backup }
if $monitor == yes { include apache::monitor }
if $firewall == yes { include apache::firewall }
}
- Generally I prefer to avoid defining / setting owners/permissions on
files I leave them to the standards provided byy the relevant
packakes...
My 2c
Al
--
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] Modules in SVN/Git repositories - How are they organised?
I would just like to ask the question if you have any links for publicly
available modules that are source controlled - can you forward them to
me please? Or post them to the list. I'd like to check them out and see
how module development is done.
I've also heard whispers of some people getting together to share
modules and classes. Anyone involved in that, can you please also
forward me some info, make contact etc. I've been trying to get into
puppet for a few months now, but I've only begun to take it very
seriously in the last few weeks.
The first hurdle I noticed, was not the installation, or finding help
with regards to the installation, it was beginning to configure the
puppet master. I know what I want to do, I'm used to doing it every day
anyway, but what a lot of sysadmins may find, (and read SYSADMINS, not
ruby coders, or perl coders, or anyone with coding skill but system
admins!), is that it seems you have to go back to the beginning and do
everything you've already learnt and know, in a new way. I have no
problem with that, but as a sysadmin, time is something we don't have.
Being able to check out a module I know works, and has been tested by
the community, and do the following.
node 'freshserver.mydomain.com' {
include postfix_relay
include ftp_public
include firewall
include http
include ban_list
}
... and adding some variables like domain name means that I have system
up, running, and configured in a set way for each and every box I setup
is a dream that I think is worth working towards.
Seeing as so much of the work has already been done either behind closed
doors, or in test environments, I see no reason why we are all
duplicating effort. After all, is that not the reason all the top
distros have repositories, and certain people making sure the code is
good for everyone?
Maybe we should manage puppet modules and classes like packages in a
repository, like a 'distro'. Feel free to voice your opinions, I'm sorry
if I'm causing waves, and I know I'm new here, but I love the concept of
puppet, and we should run with this as far as we can!
The Puppet Apprentice :- http://puppetnewbie.blogspot.com/
Follow me on twitter:- http://twitter.com/mritguru
Puppet #tag on twitter :- #puppet
IRC :- itguru ON irc.freenode.org (feel free
to say hi!)
--
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: Modules in SVN/Git repositories - How are they organised?
I would just like to ask the question if you have any links for publicly available modules that are source controlled - can you forward them to me please? Or post them to the list. I'd like to check them out and see how module development is done. David Schmidt has written some wicked plugins: http://git.black.co.at/ There are a shed-load of individual content that people have written and hosted on github: http://github.com. A search for 'puppet' will show these. For example the camptocamp guys have written a few tasty ones: http://github.com/camptocamp And other puppetlab developers: http://github.com/bruce http://github.com/bodepd http://github.com/lak I believe Puppetlabs are working on a solution for user contributed modules. Not sure what the status is - perhaps Michael DeHaan (product manager for puppet) can provide some information. ken. -- 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] Provisioning VM in Xen via Puppet - Howto??
On 05/11/10 21:48, Gabriel - IP Guys wrote:
I've finally managed to get xen installed on a remote system via puppet
http://puppetnewbie.blogspot.com/2010/05/installing-xen-instance.html
I was about to create my test machines manually, when it occurred to me,
that I should be doing this via puppet. Hence my question in the
subject. I was given some advice on the irc channel, but it didn't
really sink in very much.
If anyone has any ideas, please feel free to send me a note, I'll be
working on this privately, and post my findings and ideas, back to the
list. The way I have installed xen is noted in my blog if you would like
to reference it.
First of all, I have a definition for creating Xen config files.
It is part of my 'nsc-puppet-utils' module, which you can clone
from http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git. You
use it like this:
xen_domu {
myguest:
cpus = 2, memory = 4096,
interfaces = [ 00:16:3E:10:20:30, 00:16:3E:10:20:30 ],
disk = [ /dev/vghost/vm-myguest.system,
/dev/vghost/vm-myguest.homes ],
ensure = running, autoboot = true;
}
There are more parameters available, but the above are perhaps
the most important. It is fairly generic, and tries to impose as
little policy as possible.
I then have another definition, which sets parameters the way I
want them to be. For each virtual guest, I actually create two
Xen config files; one for booting the guest the normal way, and
one for booting the CentOS installer with a kickstart file. To
install OS onto the disk image I do:
# xm create -c myguest-install
and let it run. To boot the machine after OS has been installed,
I do:
# xm create myguest
I use LVM logical volumes for disk images, using a consistent
naming for them, and my definition makes it easy to use that
convention. I use that definition like this:
nsc_vm_guest {
mail:
memory = 3072, cpus = 3,
disk = [ +postfix, +spoolmail, +home, +mailman ],
interfaces = [ 00:16:3E:10:20:30 ];
}
The +foo disk names is shorthand for /dev/vgbar/vm-mail.foo,
where bar is the name of the dom0 machine hosting the guest, so
I have less to type when defining my guests. nsc_vm_guest will
also automatically add a disk image for the system file systems
(/, /var and swap).
I don't create the logical volumes automatically, nor do I
partition or create filesystems on them automatically, to lessen
the risk of destroying important data. Except for /, /var and
swap, which my kickstart config creates; I make sure to keep
persistent data on separate filesystem from the OS filesystems,
so I can re-install machines with very little hesitation.
I'm attaching the nsc_vm_guest definition I use, and the
kickstart template I use. There is some documentation as
comments in there. If you use them, you will probably want
to customize them to your liking. Git clone the URL above
to get the nsc-puppet-utils module; hopefully it is generic
enough to not need any customization (but if you find that
you do, please tell me how it can be made better).
/Bellman
--
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.
$centos_srcdir = //mirror.nsc.liu.se/CentOS/5/os/${architecture}
$xen_anaconda_dir = /var/lib/xen/anaconda
$xen_kickstart_dir = /var/lib/xen/kickstart
/*
* Define a virtualization guest the NSC way.
*
* This is a first prototype. Currently, it defines the VM as a
* Xen domU. It creates to configurations for each guest, one
* named $name for running normally, and one named $name-install
* which will boot a kickstarted CentOS installer.
*
*
* PARAMETERS
*
* - ensure::
*Tells if the VM guest should be installed or not. Possible
*values are installed (default) and absent. The values
*started and stopped that xen_domu handles are forbidden
*here. Note though that absent will still destroy a running
*guest with this name.
*
* - autoboot::
*If the guest should be started automatically when the VM host
*boots. Possible values are true (default) and false. This
*parameter only applies to the normal configuration for the
*guest; the -install configuration is never autobooted.
*
* - disk::
*List of disk images to export to the guest, starting with xvdb.
*The image for the system disk, xvda, will be automatically
*prepended to this list, using /dev/vg$hostname/vm-$name.system,
*where $hostname is the name of the VM host (dom0), and $name
*is the name of the guest. That image must currently already
*be partitioned into / (xvda1), /var (xvda2) and swap (xvda3).
*
Re: [Puppet Users] Have I found a bug with variables in nodes?
On 05/12/10 00:31, Dan Bode wrote: you guys don't use an external node classifier? Is there a reason you prefer to declare nodes? Why *should* I use an external node classifier? I would just need to invent a description language for describing my nodes, when there already is an existing one in Puppet. External node classifiers can only specify variables and classes, not resources. Big limitation. And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. And so far I haven't found any big reason to use an external node classifier even if the two problems above were solved. /Bellman -- 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] Have I found a bug with variables in nodes?
On Wed, May 12, 2010 at 11:47 PM, Thomas Bellman bell...@nsc.liu.se wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). my 2 cents, Ohad -- 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: Have I found a bug with variables in nodes?
External node classifiers can only specify variables and classes, not resources. Big limitation. I personally like the separation. In our case we want to provide a 'model/data only' approach at that layer - and hide 'code logic'. Of course parameterized classes (coming in rowlf I believe) will make things look nicer as well so I can avoid the global vars. Why *should* I use an external node classifier? I would just need to invent a description language for describing my nodes, when there already is an existing one in Puppet. I'm guessing you've seen puppet-dashboard right? It avoids the need to develop your own thing if you don't want to. ken. -- 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] Have I found a bug with variables in nodes?
On Thu, 13 May 2010, Ohad Levy wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). Really? Did feature #2834 get implemented while I wasn't paying attention? --apb (Alan Barrett) -- 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] Have I found a bug with variables in nodes?
On Wed, May 12, 2010 at 9:25 AM, Alan Barrett a...@cequrux.com wrote: On Thu, 13 May 2010, Ohad Levy wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). Really? Did feature #2834 get implemented while I wasn't paying attention? there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;) --apb (Alan Barrett) -- 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.compuppet-users%2bunsubscr...@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-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] Have I found a bug with variables in nodes?
On Wed, May 12, 2010 at 9:35 AM, Dan Bode d...@puppetlabs.com wrote: On Wed, May 12, 2010 at 9:25 AM, Alan Barrett a...@cequrux.com wrote: On Thu, 13 May 2010, Ohad Levy wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). Really? Did feature #2834 get implemented while I wasn't paying attention? there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;) Assuming the client has puppeted at least once against that server. This won't work for bootstrapping a client though will it? I'd love it if facts were available to the external node classifier. I'm thinking of a flow like: * new client runs puppet, has no facts * external node classifier supplies a bootstrap environment with bootstrap facts * client submits evaluated facts to external node classifier again, it can now make decisions with full data about the client. --apb (Alan Barrett) -- 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.compuppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- nigel -- 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] Have I found a bug with variables in nodes?
On Wed, May 12, 2010 at 9:55 AM, Nigel Kersten nig...@google.com wrote: On Wed, May 12, 2010 at 9:35 AM, Dan Bode d...@puppetlabs.com wrote: On Wed, May 12, 2010 at 9:25 AM, Alan Barrett a...@cequrux.com wrote: On Thu, 13 May 2010, Ohad Levy wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). Really? Did feature #2834 get implemented while I wasn't paying attention? there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;) Assuming the client has puppeted at least once against that server. This won't work for bootstrapping a client though will it? it does, the facts yaml file is created before the external node classifier is called ;) I'd love it if facts were available to the external node classifier. I'm thinking of a flow like: * new client runs puppet, has no facts * external node classifier supplies a bootstrap environment with bootstrap facts * client submits evaluated facts to external node classifier again, it can now make decisions with full data about the client. --apb (Alan Barrett) -- 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.compuppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- nigel -- 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.compuppet-users%2bunsubscr...@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-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] Have I found a bug with variables in nodes?
On Wed, 12 May 2010, Dan Bode wrote: The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;) it does, the facts yaml file is created before the external node classifier is called ;) Excellent! I'll change my node classifier to use that information. --apb (Alan Barrett) -- 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: puppet-module-apache
http://github.com/camptocamp/puppet-apache http://github.com/wesabe/puppet-apache2 http://github.com/puppet-modules/puppet-apache http://github.com/simpsonjulian/puppet-apache-ubuntu http://github.com/ohlol/puppet-apache or the one athttps://labs.riseup.net/code/projects/shared-apache For sake of completeness I'd add my own module to the list: http://git.example42.com/?p=example42modules/.git;a=tree;f=apache It's not the most complete or evoluted of the bunch but it has its own points, IMHO. In any case what I find most important is to define a common naming for defines that create virtualhosts and general .conf files so that, whatever the apache module used, there's a common way to manage its configuration's fragments. Apache is the typical module that is often referenced by other modules, right in the definition of a configuration piece that provides the web access information for an application. Since I'm almost convinced that people will keep on doing their own apache modules and there will hardlly be a monstre module good for every use (I personally find, for example, totally unfit to debianize the apache setup on a not debian breed: IMHO a puppet module should strictly follow the OS guidelines, directory's structure and practices) I would concentrate the efforts in defining common interfaces so that in an application module I can use always the same syntax to manage its apache configuration file. my2c al -- 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] puppet-module-apache
On May 12, 2010, at 3:16 AM, Julian Simpson wrote: http://github.com/camptocamp/puppet-apache http://github.com/wesabe/puppet-apache2 http://github.com/puppet-modules/puppet-apache http://github.com/simpsonjulian/puppet-apache-ubuntu http://github.com/ohlol/puppet-apache I'd be delighted to see my apache module be made redundant. Every module I tried either: - had assumptions that I didn't like (e.g. one depended on augeas and I'm not a fan of machine-edited files), - had baked-in things like file locations from RedHat-style distros (cough *extlookup*) - only worked on Puppet 0.25 for no discernible reason Meaning that it doesn't work on 0.24.x, or it doesn't work on rwolf. (The next puppet.) If we agree on some features that we'd all like, then we could describe those in a cucumber spec. And then test it on the matrix of operating systems and Puppet versions - which Hudson ought to do nicely. -- 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] Cannot make autosign works
Hi Folks, I'm a first time user of puppet and I'm playing around with it using Amazone EC2 instances in order to learn it. The OS is Ubuntu 10.04 server and puppet version is 0.25.4. Right now I'm facing a hard time to make autosign feature work. I'd like to make the master autosign any client from amazon AWS. For that I create an /etc/puppet/autosign.conf file with only one line containing *.compute-1.internal and the started the puppetmaster using sudo puppetmasterd -v --no-daemonize . The client connects to the server but no signed certificate is delivered. At the serve I got a message saying: info: Could not find certificate for 'domu-12-31-38-04- b0-28.compute-1.internal' I also tried adding autosign=true and autosign=/etc/puppet/ autosign.conf under [puppetmasterd] section in /etc/puppet/ puppet.conf, but no luck so far. What am I doing wrong here? One think I was considering is that at some point I might messed up with the server certificate. Not sure. Does a sudo puppetca --clean -- all remove the master certificate? Best regards, Cheers, -- 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] Cannot make autosign works
On Wed, May 12, 2010 at 7:35 PM, Eric epaschoal...@gmail.com wrote: Hi Folks, I'm a first time user of puppet and I'm playing around with it using Amazone EC2 instances in order to learn it. The OS is Ubuntu 10.04 server and puppet version is 0.25.4. Right now I'm facing a hard time to make autosign feature work. I'd like to make the master autosign any client from amazon AWS. For that I create an /etc/puppet/autosign.conf file with only one line containing *.compute-1.internal and the started the puppetmaster using sudo puppetmasterd -v --no-daemonize . The client connects to the server but no signed certificate is delivered. At the serve I got a message saying: info: Could not find certificate for 'domu-12-31-38-04- b0-28.compute-1.internal' I also tried adding autosign=true and autosign=/etc/puppet/ autosign.conf under [puppetmasterd] section in /etc/puppet/ puppet.conf, but no luck so far. What am I doing wrong here? One think I was considering is that at some point I might messed up with the server certificate. Not sure. Does a sudo puppetca --clean -- all remove the master certificate? that will remove the masters ssl certs, as well as any client ssl certs if you messed up with the client certs, you sometimes have to wipe them out with rm (on the client) you can also try puppetca --list to see the pending certs to be signed and puppetca --list --all to see all signed and unsigned certs. Best regards, Cheers, -- 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.compuppet-users%2bunsubscr...@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-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: Cannot make autosign works
Hi Dan, In the case that I messed up with the master ssl, how could I fix it? Since I have no client signed yet, can I just generate a cert for the master fqdn hostname (ie: puppetca --generate $(uname -f))? puppetca --list outputs an empty line while puppetca --list --all outputs the master fqdn preceded by + sign, like this: r...@domu-12-31-39-00-65-47:~# puppetca --list --all + domu-12-31-39-00-65-47.compute-1.internal r...@domu-12-31-39-00-65-47:~# puppetca --list r...@domu-12-31-39-00-65-47:~# Any hints? thanks for the help. On May 12, 11:56 pm, Dan Bode d...@puppetlabs.com wrote: On Wed, May 12, 2010 at 7:35 PM, Eric epaschoal...@gmail.com wrote: Hi Folks, that will remove the masters ssl certs, as well as any client ssl certs if you messed up with the client certs, you sometimes have to wipe them out with rm (on the client) you can also try puppetca --list to see the pending certs to be signed and puppetca --list --all to see all signed and unsigned certs. Best regards, Cheers, -- 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.compuppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group athttp://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-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: Cannot make autosign works
On Wed, May 12, 2010 at 8:18 PM, Eric epaschoal...@gmail.com wrote: Hi Dan, In the case that I messed up with the master ssl, how could I fix it? Since I have no client signed yet, can I just generate a cert for the master fqdn hostname (ie: puppetca --generate $(uname -f))? I would just wipe out the ssldir on the server and run: #puppetmasterd --no-daemonize --verbose This is the easiest way to start over from scratch. this will create new CA and SSL certs for the master. puppetca --list outputs an empty line while puppetca --list --all outputs the master fqdn preceded by + sign, like this: r...@domu-12-31-39-00-65-47:~# puppetca --list --all + domu-12-31-39-00-65-47.compute-1.internal r...@domu-12-31-39-00-65-47:~# puppetca --list r...@domu-12-31-39-00-65-47:~# Any hints? thanks for the help. On May 12, 11:56 pm, Dan Bode d...@puppetlabs.com wrote: On Wed, May 12, 2010 at 7:35 PM, Eric epaschoal...@gmail.com wrote: Hi Folks, that will remove the masters ssl certs, as well as any client ssl certs if you messed up with the client certs, you sometimes have to wipe them out with rm (on the client) you can also try puppetca --list to see the pending certs to be signed and puppetca --list --all to see all signed and unsigned certs. Best regards, Cheers, -- 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.compuppet-users%2bunsubscr...@googlegroups.com puppet-users%2bunsubscr...@googlegroups.compuppet-users%252bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group athttp:// 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@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-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] Could not match '}'
Please help me:
what would be the cause of this error: puppetmasterd 0.24.4
define apache::apache_files($owner = root, $group = root, $mode = 644,
$source, $backup = false, $recurse = false, $ensure = file) {
file { $name:
mode= $mode,
owner = $owner,
group = $group,
backup = $backup,
recurse = $recurse,
ensure = $ensure,
require = Package[httpd],
source = puppet:///apache/$source
}
}
This gives error:Could not retrieve catalog: Could not match '}' at
/etc/puppet/modules/apache/manifests/apache_files.pp:1 on node example.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.
