Re: [Puppet Users] Re: Updating node's configuration
El Miércoles, 14 de Julio de 2010 23:22:54, David Ward escribió: > What I would suggest is to change the puppetd from a daemon to a cron > job and add the argument of --tags. This way you can stipulate which > classes to run on the cronjob run, which can run every 15mins or so. > > eg > 15 * * * * pupetd -t --tags sysconfig_class --report Wouldn't it be possible to start puppet daemon mode with those options anyway? 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] ANNOUNCE: Puppet 2.6.0 - Release Candidate 1 available!
Hi: On Saturday 10 July 2010 19:11:12 Patrick Mohr wrote: > On Jul 10, 2010, at 7:57 AM, Peter Meier wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/10/2010 04:54 PM, Patrick Mohr wrote: > >> On Jul 9, 2010, at 11:58 PM, James Turnbull wrote: > >>> Certificates cleaned with puppetca (or puppet cert) are now also > >>> revoked. > >> > >> Is there some way to clean a cert (using puppet cert) without > >> revoking it? Something like "puppet cert --clean hostname.domain > >> --no-revoke". > > > > afaik, not. But could be a feature request. On the other hand, what's > > the use case? > > This isn't my usecase so I don't care, but since you ask... > > Suppose you have machines that: > *) Don't get any sensitive information through puppet. > *) Are re-imaged often using PXE+preseeding or PXE+kickstart > *) All the computers have names in the form of "lab-client-*.domainname" > > Someone said that in this case you can put "puppetca --clean > lab-client-*.domainname" as a cron job, and put "lab-client-*.domainname" > in autosign.conf. > > Again, I don't do this, so don't do it for me. I don't see that to be a use case in need of a "no-revoke" option. Once you delete the old machine and re-image it with "PXE+preseeding or PXE+kickstart" it won't get the old certkey so it'll need to be resigned anyway: to all practical purposes it's a new machine, so no benefit on not revoking the old one. 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] Re: ldap node attributes containing dash ( - )
On Friday 07 May 2010 19:54:18 donavan wrote:
> On May 6, 4:31 pm, donavan wrote:
> > Am I missing some clever way to use variables containing a dash in the
> > name?
> >
> > We're using LDAP nodes I may have a node like this example:
>
> ..
>
> > And I'd like to access 'console-port' as a variable in a manifest.
>
> Reading over I realize this may not be clear to people not using
> LdapNodes[1]. "All attributes on the LDAP nodes are assigned as
> variables in the Puppet configuration". This gives you puppet
> variables like $ipHostNumber for free.
>
> I have an LDAP attribute I need to check from inside my manifest. The
> issue is the attribute name contains a dash. So I can't use the
> regular semantics of $ to access it. Any way to get
> this attribute without a hacky function/template?
Won't use the ${variable-name} version do the trick?
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] ANNOUNCE: Puppet 0.25.5 - Release Candidate 2 available!
Hi, James: On Sunday 02 May 2010 10:25:13 James Turnbull wrote: > Welcome back to the Puppet release cycle for the second outing of > 0.25.5 - release candidate number 2. > > The 0.25.5 release is a maintenance release in the > 0.25.x branch. It contains a number of bug fixes but also > performance enhancements including speed-ups to Puppet's graphing. [...] > RELEASE NOTES > > The default location for Puppet's dynamic files, the $vardir option, > has changed from /var/puppet to /var/lib/puppet. This is already the > default for the Fedora EPEL and Debian/Ubuntu packages and brings > Puppet into FHS compliance. [...] > The default factpath is now $vardir/lib/facter/. Does this mean a default for /var/lib/puppet/lib/facter/ instead of /var/lib/puppet/facter/? Seems a bit weird, doesn't it? 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] Refresh an exec only if another file changes
Hi, Patrick:
On Wednesday 28 April 2010 23:42:38 Patrick wrote:
> On Apr 28, 2010, at 1:10 PM, Jesús M. Navarro wrote:
> > Hi, list:
> >
> > I'm trying to add a Debian-based Xen Dom0 server to puppet management.
[...]
> I won't call this way elegant, but there is an easy way to do it.
>
>
> file {
> "/boot/grub/server_menu.lst":
> mode => "0644",
> owner => root,
> group => root,
> notify => Exec["updated_menu.lst"],
> source => "puppet:///s_virtualcluster/menu.lst";
> }
>
> exec { "cp -p /boot/grub/server_menu.lst /boot/grub/menu.lst":
> path=> "/usr/bin:/usr/sbin:/bin",
> alias => "updated_menu.lst",
> refreshonly => true,
> notify => Exec["update-grub"],
> }
>
> exec { "update-grub":
> path=> "/usr/bin:/usr/sbin:/bin",
> refreshonly => true,
> }
First of all, thanks for your help. I think your idea covers the first part
of the equation but unless I misunderstood, it won't cope with the second
part.
>From what I see, yours will cope with the case where I update menu.lst
server-side, but what if somebody changes the client's copy
of /boot/grub/menu.lst? It seems puppet won't notice it so won't recover
the "proper" contents (as per the puppetmaster idea of it). Am I right?
Cheers and thank you for your interest.
--
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] Refresh an exec only if another file changes
Hi, list:
I'm trying to add a Debian-based Xen Dom0 server to puppet management.
One of the files I want to consider is /boot/grub/menu.lst since it contains
some Xen-related options.
When managing it by hand I'd produce a skeleton for menu.lst and then I'd
execute update-grub, which would look for avaliable kernels and would add
related configs to the menu.lst contents.
My first idea came in the lines of (within a class):
file {
"/boot/grub/menu.lst":
mode => "0644",
owner => root,
group => root,
notify => Exec["update-grub"],
source => "puppet:///s_virtualcluster/menu.lst";
}
exec { "update-grub":
path=> "/usr/bin:/usr/sbin:/bin",
refreshonly => true,
}
But since update-grub changes /boot/grub/menu.lst itself, the menu.lst
template gets downloaded and update-grub triggered each time puppet runs.
Is there an ellegant manner to deal with it? (like downloading menu.lst to a
different path, and then run update-grub only if md5sum of the real menu.lst
has changed from previous puppet run or if the server version from menu.lst
has changed?
TIA.
--
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] read-only 'ensure' for File resource?
Hi, Eric:
On Saturday 24 April 2010 00:47:20 Eric Sorenson wrote:
> rlpowell mentioned this earlier on irc and i find myself in a similar boat
> - I need to express a condition that doesn't fit neatly into the
> class/parameter model and I'm not quite sure how to do it. i'd like to add
> a cron entry IFF a particular file (not managed through puppet) exists.
> Seems like the natural thing would be to do:
>
> cron { "myjob":
> command => "/run/this/script.sh",
> user => roleacct,
> minute => [0,30],
> require => File["/run/this/script.sh"]
> }
>
> file { "/run/this/script.sh":
> ensure => XXX
> }
>
> where XXX is some value that would not cause any changes to the file but
> merely mark the resource as passing or failing depending on the stat().
Since the job execution depends on a resource not already managed by puppet,
why you don't delegate the decision to the cron job itself?
I mean, make sure the cron job is always present and then let it test for the
file as in:
if [ -x /run/this/script.sh ]; then
/run/this/script.sh
fi
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] Odd behavior for clients with trailing dot in their FQDN
I Bliss: On Wednesday 21 April 2010 20:33:26 Bill Weiss wrote: > All, > > I'm just getting started with puppet, so excuse any lack of vocabulary > in this email. > > I've got a server (CentOS 5.4) running with a little more than the > example puppet configuration. Importantly, I'm using the supplied > auth.conf, and the relevant portion looks like this: > path ~ ^/catalog/([^/]+)$ > method find > allow $1 > > I just created a new VM as a puppet client (also CentOS 5.4), which > calls itself ib3stage.domainI. (with trailing dot). While probably on the verge of bein technically correct (after all the ending dot is the mark for the root domain) is quite extrange ending FQDNs with the dot outside declarations on DNSs. May I ask why such a extrange host name (why not just ib3stage.domainI)? 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] Re: Default Gateway facter problems
Hi all: El Miércoles, 21 de Abril de 2010 06:55:29, Daniel Pittman escribió: > donavan writes: [...] > > When I made up my sites broadcast fact I solved it in a manner like > > interfaces.rb. Essentially there are multiple "broadcast_$interface" > > facts, and while creating these the interface associated with > > "ipaddress" also sets the "broadcast" fact as primary. > > What do you do about an interface like this: > > 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:30:48:97:59:ae brd ff:ff:ff:ff:ff:ff > inet 192.168.10.11/24 brd 192.168.10.255 scope global eth0 > inet 192.168.10.130/24 brd 192.168.10.255 scope global secondary eth0:0 > inet 192.168.10.131/24 brd 192.168.10.255 scope global secondary eth0:1 > inet 192.168.10.132/24 brd 192.168.10.255 scope global secondary eth0:2 > > (Actually, that one is easy as all the extra addresses are in the same > segment. We have other machines where they are not...) > > > Moving on to the gateway fact; I think a trivial solution is to use > > your array of gateways to create a series of "gateway_$n"[1] facts. > > ...by "gateway" do you mean "default route", or just "gateway" — we have > hosts that have a dozen different routes, and sometimes no default route at > all, that act inside the network. *Or* even multiple default gateways since a "default gateway" is nothing but one that allows routing to 0/0. When more that one is defined, provided they have the same metric, the first one is always used unless fail is detected in which case the second one is tried in turn, etc. 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.
[Puppet Users] Strange order dependency
Hi, list:
I'm a rookie on his first tests with Puppet and I found something that it's
probably obvious but that still don't understand.
I have some modules that manage some files under /etc/
(say, /etc/resolv.conf, /etc/ntp.conf, etc.) and then, since I "inherited"
quite a lot of files managed by hand under Subversion, a lot of files that go
directly under the "private" resource in order to be moved 'as is' from the
puppetmaster to its clients.
The thing is that if I have a client that calls any module that "touches" any
file under /etc, the "private" resource seems to go unnoticed unless I first
run the puppetd client without any module so the client "notices" the files
under "private". Once the client "sees" once the "private" section
everything goes OK from there on.
An example: let's say I have a "node" definition like this:
node "somehost.example.com" inherits myCompanyBasic {
file { "/etc":
recurse => "true",
source => "puppet:///private/etc";
}
}
...where "private" is defined within fileserver.conf as...
[private]
path /etc/puppet/private/%d/%h
..and there exists within the puppetmaster a file like:
/etc/puppet/private/example.com/somehost/etc/foo/bar
...and myCompanyBasic is defined like this:
node myCompanyBasic {
# NTP client
include ntp::client
}
All that ntp::client does is this (the parent ntp class is just a "noop" by
now):
class client inherits ntp {
File["/etc/ntp.conf"] {
source => "puppet:///ntp/ntp-client.conf",
}
}
The file "ntp-client.conf" is properly sent to the client as /etc/ntp.conf but
neither /etc/foo/bar is sent to the client nor the logs show nothing (even
when running as puppetd --no-daemonize --debug).
I can tell that /etc/puppet/example.com/somehost/etc is somehow managed since
if I delete it on the server I'll get a client-side error:
(//Node[somehost.example.com]/File[/etc]) Failed to retrieve current state of
resource: No specified source was found from puppet:///private/etc
...although if /etc/puppet/example.com/somehost/etc exists on the server no
file within it will be sent to the client.
Now, if I change my host definition *not* to depend on the global class, like
this (see there's no "inherits myCompanyBasic" here):
node "somehost.example.com" {
file { "/etc":
recurse => "true",
source => "puppet:///private/etc";
}
}
Then /etc/puppet/example.com/somehost/etc/foo/bar is properly sent to the
client as /etc/foo/bar and if I make a change
to /etc/puppet/example.com/somehost/etc/foo/bar on puppetmaster it will be
properly managed *even* if I return afterwards to the original definition for
somehost.example.com inheriting myCompanyBasic and I restart both
puppetmaster and puppetd: it will then and afterwards properly manage *both*
the files (and templates) managed by modules and those from the "private"
resource.
Is this a known bug, something I misunderstood or what?
I'm using puppet 0.24.5 from Debian Stable ("Lenny") both on server and
client.
TIA.
--
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] Do not edit above this line policy
Hi, list: I'm on my first steps using Puppet. Now that the easiest parts are somehow tamed more and more questions do arise. But let's go one by one. For some computers/services we delegate some parts of their administration (i.e. development environments). I'll take an easy example on the /etc/hosts file: There should be a '127.0.0.1 localhost' stanza and then one pointing the host's public IP to its FQDN. But then, the "end user" should have to be free to add other entries as needed. I'm aware that I could go the path of forcing presence on a line by line fashion but is there any easier procedure for a "do not edit above this line" policy so puppet can manage by means of a template part of the file and then allow for hand-made modifications on the end part of it? TIA. -- 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] Adding System Account
Hi, Thomas:
On Tuesday 30 March 2010 09:47:18 Thomas Mueller wrote:
> Am Mon, 29 Mar 2010 18:23:04 -0300 schrieb Darvin Denmian:
> > What option I need to use to create a system account with "Puppet"? Like
> > the bellow command:
> >
> > useradd -r nagios -s /sbin/nologin -d /var/lib/nagios -m nagios
> >
> > Sorry for this newbie question, I'm new in Puppet configuration :)
> >
> > Thanks !
>
> User {
> "nagios":
> gid => "nagios",
> shell => "/sbin/nologin",
> home => "/var/lib/nagios",
> }
No, that won't do the trick. Useradd -r will honour SYS_UID_MIN-SYS_UID_MAX;
whithout it UID_MIN-UID_MAX will cut it. In general, a "-r" account will get
an UID somewhere between 100 and 499 while without it, it will go above 500.
--
Jesús M. Navarro
Ándago Ingeniería - www.andago.com
Teléfono: +34 916 011 373 (ext. 29)
Móvil: +34 666 431 088
e-mail: jesus.nava...@andago.com
C/Alcalde Ángel Arroyo n.º10 2.ªPl. (28904) Getafe, Madrid
*Parque Tecnológico de Bizkaia:*
c/ Kanala Bidea, Edificio 103, Planta 1ª Izqda.
48170 Zamudio, Bizkaia
--
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.
