Hi all,
[Please CC me in replies, I am not subscribed to this list.]
First of all, thanks for puppet! It is a very nice tool and I''m in the
(slow)
process of using it to manage my new Xen-based virtual server farm with it.
Most of the "simple" tasks worked well so far, and I may be able to
add a few
recipies to the Wiki when I find time to do so.
However, is there any way to expand wildcards in the puppet config syntax?
I''d
like to do something like
class xen-dom0-config {
package { ["xen-tools",
"xen-hypervisor-3.0.3-1-i386-pae"]:
provider => aptitude,
ensure => installed
}
remotefile {
"/etc/xen/xend-config.sxp":
source => "apps/xen/dom0/xend-config.sxp",
mode => 444, require => Package[xen-tools];
"/etc/xen/*.cfg":
source => "apps/xen/dom0/*.cfg",
mode => 444, require => Package[xen-tools];
}
}
which of course fails because the "*.cfg" is interpreted as a literal
config
file name. On the other hand, if I specified /etc/xen to be managed as a
whole (I suppose with "recurse => true", although I
haven''t managed to get a
whole directory from the puppet fileserver recursively yet), then other files
(not fitting the *.cfg pattern) that I''d not like to touch would be
overwritten (or removed?) as well.
What is the proper way to deal with something like this without enumerating
all *.cfg files?
with best regards,
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Rene! Hi list! On Monday 26 February 2007 00:24, Rene Mayrhofer wrote:> [Please CC me in replies, I am not subscribed to this list.] > > First of all, thanks for puppet! It is a very nice tool and I'm in the > (slow) process of using it to manage my new Xen-based virtual server farm > with it. Most of the "simple" tasks worked well so far, and I may be able > to add a few recipies to the Wiki when I find time to do so. > > However, is there any way to expand wildcards in the puppet config syntax? > I'd like to do something like > > class xen-dom0-config { > package { ["xen-tools", "xen-hypervisor-3.0.3-1-i386-pae"]: > provider => aptitude, > ensure => installed > } > > remotefile { > "/etc/xen/xend-config.sxp": > source => "apps/xen/dom0/xend-config.sxp", > mode => 444, require => Package[xen-tools]; > "/etc/xen/*.cfg": > source => "apps/xen/dom0/*.cfg", > mode => 444, require => Package[xen-tools]; > } > } > > which of course fails because the "*.cfg" is interpreted as a literal > config file name. On the other hand, if I specified /etc/xen to be managed > as a whole (I suppose with "recurse => true", although I haven't managed to > get a whole directory from the puppet fileserver recursively yet), then > other files (not fitting the *.cfg pattern) that I'd not like to touch > would be overwritten (or removed?) as well. > > What is the proper way to deal with something like this without enumerating > all *.cfg files?Using "recurse => true" a kind of overlay is created. Only by specifying "purge => true", unmanaged files are deleted. See the Type Reference at [1]. So you were on the right path with trying to recursivly copy a directory. This should work: file { "/etc/xen": source => "puppet://puppet/files/xen/", recurse => true, mode => 644, owner => root, group => root, } Also note, that for directories the executable bits are set wherever the readable bit is set, so that "mode => 644" works out to "mode => 755" for directories. Regards, David [1] http://www.reductivelabs.com/projects/puppet/reference/typedocs.html#file - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF4rDR/Pp1N6Uzh0URAiwpAJ9SxdbnwABTJ2rVBioib0/rtsph0gCfasDm 0CdNP/6faFZfrV/vOJo8nCo=fP9Y -----END PGP SIGNATURE----- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Hallo David, Hi list, [Please CC me in replies, I am not subscribed to this list.] Thanks for the quick reply! Am Montag, 26. Februar 2007 10:04 schrieben Sie:> > What is the proper way to deal with something like this without > > enumerating all *.cfg files? > > Using "recurse => true" a kind of overlay is created. Only by > specifying "purge => true", unmanaged files are deleted. See the Type > Reference at [1]. So you were on the right path with trying to recursivly > copy a directory. > > This should work: > file { "/etc/xen": > source => "puppet://puppet/files/xen/", > recurse => true, > mode => 644, owner => root, group => root, > }Thanks for confirming that it should work this way, which motivated me to look for why it didn''t. And the cause was really silly - I copied the "remotefile" definition from somewhere (to include the source prefixes for copying files from the fileserver) and this definition just failed to pass on its "recurse" parameter - ouch ;-)> Also note, that for directories the executable bits are set wherever the > readable bit is set, so that "mode => 644" works out to "mode => 755" for > directories.Thanks for highlighting that - I assumed it would work somehow like that, but didn''t know for sure. I only have a minor problem left now: my puppet config tree on the server is managed via subversion, and the "recurse => true" therefore copies the .svn directory as well. Is there the possibility to exclude files/directories from recursion? with best regards, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/ _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 26, 2007, at 8:08 AM, Rene Mayrhofer wrote:> > I only have a minor problem left now: my puppet config tree on the > server is > managed via subversion, and the "recurse => true" therefore copies > the .svn > directory as well. Is there the possibility to exclude files/ > directories from > recursion?ignore => ".svn" -- When all you have is a nailgun, every problem looks like a messiah. -- Iain Chalmers, ASR --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Am Dienstag, 27. Februar 2007 16:52 schrieben Sie:> ignore => ".svn"Ah, thanks, I was always looking for "exclude" and seem to have skipped "ignore" in the type reference. Does this take an array with multiple ignore patterns as well? PS: puppetd seems to be crashing about once a day on most of my machines. Do you have any idea what may be causing this? May that be related to the (unsolved) Debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385230 ? Thanks, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/ _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 27, 2007, at 12:27 PM, Rene Mayrhofer wrote:> Am Dienstag, 27. Februar 2007 16:52 schrieben Sie: >> ignore => ".svn" > Ah, thanks, I was always looking for "exclude" and seem to have > skipped "ignore" in the type reference. Does this take an array > with multiple > ignore patterns as well?Yes, it does. Note that this works like (from what I remember) cfengine''s exclude: Puppet won''t descend into that directory at all.> PS: puppetd seems to be crashing about once a day on most of my > machines. Do > you have any idea what may be causing this? May that be related to the > (unsolved) Debian bug report at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385230 ?It''s essentially impossible to say without more information. Does it only happen on Debian machines? Is it the same machine every day, all machines once a day, some subset, etc? If it''s happening consistently on at least one machine, then leave that machine''s puppetd running with --verbose --trace and wait for it to die. It should give you some reason for the death. I definitely want to resolve all known cases of this, but I need a lot more information to help me do so. -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Am Dienstag, 27. Februar 2007 19:21 schrieb Luke Kanies:> On Feb 27, 2007, at 12:27 PM, Rene Mayrhofer wrote: > > Am Dienstag, 27. Februar 2007 16:52 schrieben Sie: > >> ignore => ".svn" > > > > Ah, thanks, I was always looking for "exclude" and seem to have > > skipped "ignore" in the type reference. Does this take an array > > with multiple > > ignore patterns as well? > > Yes, it does. Note that this works like (from what I remember) > cfengine''s exclude: Puppet won''t descend into that directory at all.Thanks! It works now.> > PS: puppetd seems to be crashing about once a day on most of my > > machines. Do > > you have any idea what may be causing this? May that be related to the > > (unsolved) Debian bug report at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385230 ? > > It''s essentially impossible to say without more information.I know and am sorry for the bad bug report - it was only a (long) shot at something reported earlier to see if there was a know solution.> Does it > only happen on Debian machines?I only have Debian machines under puppet control, but it happens both for xen dom0 and for domU domains (same binary kernel though).> Is it the same machine every day, > all machines once a day, some subset, etc?They are all on the same subnet, and it happens to most (all? not sure...) machines in the cluster. I would assume it to be at least once a day, but can not (yet) go into more detail because I manually need to restart puppetd. One minor detail is that /var/run/puppetd.pid is left there, so I need to clean it up before restarting.> If it''s happening consistently on at least one machine, then leave > that machine''s puppetd running with --verbose --trace and wait for it > to die. It should give you some reason for the death.I will let it run with these parameters on one of the machines where it kept crashing and report back when I have the trace.> I definitely want to resolve all known cases of this, but I need a > lot more information to help me do so.I will try to provide all the information I can, the next piece will probably be the trace. Thanks for your great support! Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/ _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users