[Puppet Users] run bash script from puppet
Cathal O Mul writes:
i am new to puppet
I want to run a file called remove
This file removes a file
File remove
rm test101
How do i get puppet to run this file ?
In this specific case it would probably be better to use a Puppet file
resource to perform the removal of the file:
file { /path/to/test101:
ensure = absent,
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/21474.33190.922645.244953%40shell.uoregon.edu.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] scripts
Cathal O Mul writes:
I have a file call pr.sh it is a scrip I would like puppet to run it
how would I go about doing this
This is what Puppet exec resources are for, although one should use
those sparingly and only if what you want to accomplish can't be done
using some other resource type. In particular unless you specify the
exec carefully, Puppet may run the exec multiple times, even within
the same Puppet agent invocation, so the script should be written to
handle that case cleanly.
So you would start with something like:
exec { /path/to/pr.sh:
}
And then add one or more attributes to ensure the script is run only
when the necessary conditions apply. These might include:
refreshonly = true,
# run the exec when the specified file resource is updated
subscribe = File[/some/input/file],
# alternatively the file resource can have
# notify = Exec[/path/to/pr.sh],
# run another command and do this exec only if it exits successfully
onlyif = ...
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/21474.33509.1048.226555%40shell.uoregon.edu.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] roll back update
Jason Antman writes: There's nothing existing that I know of that works in the GUI-based way you seem to be talking about. Because, well, we *nix people usually don't do that. I've really only worked on RPM-based systems, so I'm not sure if this is still applicable in the debian world... Debian-based distributions have interactive tools like aptitude (curses-based) or synaptic (GNOME GUI) that can let you do selective package installation and upgrades on a host, in addition to the command-line apt-get and dpkg utilties. These don't really offer centralized management of a group of hosts, though. In the RPM world there's Spacewalk (or the Red Hat Satellite Server commercial product based on it) for doing centralized package management. There's probably some equivalent in the Debian world but I'm not aware of what that is. Setting up a local repository mirror can let you control what packages are visible to hosts so you can control package versions for installation and upgrades (in fact, I've seen people set up multiple mirrors visible to different environments so they can do things like staged upgrade testing). There are 2 types of updates I do 1) updating one package or a set of packages (like, updating Puppet from 3.1.0 to 3.4.1) which I do with the ensure parameter on the Package type. Some stuff is wrapped up in classes, and this can be done through an ENC (parameterized classes, or global params if need be) or Hiera. I'll change the version on one node, test it, then an environment, test it, and eventually apply it everywhere. If you need to downgrade/roll back, that *can* work... might work better in the apt/deb world than it does in yum/rpm. 2) Full system updates/upgrades, what RHEL-derivatives term as distribution upgrades, i.e. updating all packages from CentOS 6.3 to 6.4. I rebuild the box. No reason to mess with doing this through the distro, I just shut it down, clean the cert in puppet, do a fresh PXE boot (and kickstart) and let Puppet do its thing. This has the added benefit of reducing entropy, and even providing a nice DR test (like if you just log in and poweroff immediately...) -Jason On 01/22/2014 09:31 AM, Muhammad Yousuf Khan wrote: Hello All, i have seen so many apt modules on puppet forge website. they are more like changing source list path defining. HTTP proxy blah blah but what i want is a bit more. is there any apt module which can help me to update only selective updates (like in Microsoft Wsus does, it list down all the updates and people can select and apply those patches on selective nodes and if they find it problematic then can remotely uninstall it too.i want this to be done on my Debian server farm and and i also want to roll back as needed (for example if any securety or OS update creating problem of some kind i can roll it back with puppet live management/manual run). i dont know how practical it is. however as i have already got the concept of Wsus therefore my mind is trying to think of wsus like puppet module. Please help. thanks, MYK -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/21216.19881.358352.250354%40shell.uoregon.edu. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet calls the ENC twice for some nodes.
pierra mathieu writes: Hi everyone, I have an issue setting up Puppet with an ENC. For some nodes, puppet calls my ENC twice with a 2 sec interval. Why is that a problem? Your ENC should always return the same data for the same node, and it should be efficient enough that it can be called for every node in your system (even twice). -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Selector within a resource -- location syntax
root writes:
Can anyone tell me why this is legal:
file { /etc/cron.d:
owner = root,
group = root,
mode = $operatingsystem ? {
'Solaris' = 0755,
default = 0700,
}
}
...And yet if I have any resource attributes below the mode selector
statement, it will not parse?
No comma after the conditional? Like this:
mode = $operatingsystem ? {
'Solaris' = 0755,
default = 0700,
},
All resource attributes use comma as a separator. You can optionally
leave off the final comma (although style recommendations suggest you
should always end an attribute specification with a comma, mainly so
that you don't have to remember to add it if you add additional
attribute specifications).
(Am I doing the right thing by having a selector in my file resource? I
have a large amount of files to validate, and attributes change for many of
the files, depending on the OS.)
That is certainly one way to manage the OS-specific differences in your
resources. If you have a lot of things that are always mode 755 in one
OS and mode 700 in another, it may be somewhat more concise to declare a
variable and use that:
$dirmode = $operatingsystem ? {
Solaris = 0755,
default = 0700,
}
...
file { /etc/cron.d:
owner = root,
group = root,
mode = $dirmode,
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] tweaking emacs puppet mode ?
Philip Brown writes:
I enjoy the puppet mode that comes with emacs by default.
However... people in our organization prefer a slightly different formating
standard.
Would anyone be able to tell me what tweaks I could put in my .emacs file,
to make it so that code gets autoformatted as
class foo {
TAB line here
TAB line here
}
So, one to change the tabstops thing, and one to make the closing brace
outdent?
You might look at the customization group for puppet, since that
should list all the variables intended for controlling its behavior (and
let you automatically change and save settings in your .emacs). I find
puppet-mode doesn't always auto-indent the closing brace the way you
(and I also) want, but if I move the closing brace back to where I want
it, puppet-mode will leave it there.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] tweaking emacs puppet mode ?
Philip Brown writes: On Monday, December 17, 2012 1:02:20 PM UTC-8, Steven VanDevender wrote: Philip Brown writes: ... So, one to change the tabstops thing, and one to make the closing brace outdent? You might look at the customization group for puppet, since that should list all the variables intended for controlling its behavior (and let you automatically change and save settings in your .emacs). I find puppet-mode doesn't always auto-indent the closing brace the way you (and I also) want, but if I move the closing brace back to where I want it, puppet-mode will leave it there. Thanks for the reply. I'm not actually an emacs expert.. so I dont understand what customization group is. I did notice that if I move the brace, it stays.. but reformatting Every Single Closing Brace manually, is really annoying. Try M-x customize-group and answer the prompt with puppet. Sadly not much is documented there and there aren't a whole lot of control variables. I suspect in this case you'd either have to mess with the Emacs Lisp source (or at least have your own modified version of the indentation functions). puppet-mode is kind of rudimentary but I know the author and he would probably be amenable to improving it, if you allow him some time. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] New to Puppet -- why the puppet user
Jerald Sheets writes: Because standard systems administration practice is to rarely if ever run anything at all as root. This practice, generally speaking, will not pass ITIL, SOX, HIPAA, or PCI compliance auditing, and if something like Puppet (which has complete run of your system) ran as root, you could easily demolish not only one but thousands of machines with a single keystroke... well, Root is just a bad idea, then One gathers you're not really a practicing sysadmin. What you cite are a bunch of good reasons one should avoid running daemons and applications as root. But you can't create and manage the mechanisms that are used to avoid running things as root without root access. A sysadmin avoids doing things as root that aren't necessary, but is otherwise obligated to use root access (carefully) on a constant basis. Puppet runs as root because it should be used to do a lot of the things that have to to be done as root. Proper standards for security should say that root access should be carefully regulated and monitored, not that it must never be allowed for remote access. If used well Puppet should actually improve your security because it can enforce site-wide standards automatically and provide better auditing of changes than haphazard manual practices. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] New to Puppet -- why the puppet user
Aaron Grewell writes: To answer OP's question, the Puppet Master runs as user/group puppet. The agent runs as root. Which is, of course, entirely desirable. puppetmaster needs access only to a limited set of files, which it needs only to serve to agents, and hence is best run in a dedicated user/group. The agents, however, need root access to do their jobs. Unfortunately I failed to notice that was a top-posted reply. Sorry. On Mon, Nov 26, 2012 at 3:41 PM, Steven VanDevender ste...@uoregon.eduwrote: Jerald Sheets writes: Because standard systems administration practice is to rarely if ever run anything at all as root. This practice, generally speaking, will not pass ITIL, SOX, HIPAA, or PCI compliance auditing, and if something like Puppet (which has complete run of your system) ran as root, you could easily demolish not only one but thousands of machines with a single keystroke... well, Root is just a bad idea, then One gathers you're not really a practicing sysadmin. What you cite are a bunch of good reasons one should avoid running daemons and applications as root. But you can't create and manage the mechanisms that are used to avoid running things as root without root access. A sysadmin avoids doing things as root that aren't necessary, but is otherwise obligated to use root access (carefully) on a constant basis. Puppet runs as root because it should be used to do a lot of the things that have to to be done as root. Proper standards for security should say that root access should be carefully regulated and monitored, not that it must never be allowed for remote access. If used well Puppet should actually improve your security because it can enforce site-wide standards automatically and provide better auditing of changes than haphazard manual practices. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Yum questions
Sam Roza writes:
So I use createrepo to make a local repo somewhere-for instance, the puppet
server-and then use that to do the install?
If you are reluctant to create a local yum repository (maybe you don't
have many custom packages) you can just source a package from a web
server or the like:
package { mypackage:
source = http://my.package.server/rpms/mypackage-1.0.0-1.i386.rpm;,
ensure = installed,
before = needsmypackage,
}
Why doesn't puppet support all of yum features?
Puppet supports not just yum but a number of other package providers in
different OSes and OS distributions. It supports the yum features
needed to implement its package management mode.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Mounting Swap
Douglas Garstang writes:
All,
Trying to mount swap. Using:
mount {
'swap':
device = '/dev/xvdq1',
atboot = true,
ensure = mounted,
fstype = 'swap',
options = 'defaults';
}
This is giving me:
(/Stage[main]/Oracle::Common/Mount[swap]) Could not evaluate:
Execution of '/bin/mount -o defaults swap' returned 32: mount: mount
point swap does not exist
What do I have wrong?
You can't activate swap using mount(8), and hence the Puppet mount
provider is not going to cope properly with it. It typically has to be
activated with swapon(8) in Linux. Yes, the swap entry is in
/etc/fstab, but that doesn't mean it gets mounted like a filesystem.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Updating /etc/puppet ?
Aaron Grewell writes: Technically true, but administratively confusing IMHO. We put our all our Puppet data (but not the puppetmaster config) in a Subversion repository. Everyone does editing in their own working copy checked out from that Subversion repository. Commits to the repository trigger a post-commit hook that checks out the new version on the puppetmaster, updating files only under /etc/puppet/manifests and /etc/puppet/modules (the main puppet config files in /etc/puppet itself are not touched). The puppetmaster then picks up the changes so that clients will pull updated manifests and resources on their next check. No one is ever to edit files directly under /etc/puppet/manifests or /etc/puppet/modules on the puppetmaster hosts; those files are essentially just another working copy from Subversion's point of view, but edits there would just produce checkout conflicts. We also have an /etc/puppet/development subdirectory containing a development branch of the Puppet files that can be applied to hosts in the development environment. This is all quite straightforward and easily allows multiple people to work concurrently on (non-conflicting) Puppet updates. Conflicts are detected and resolved with Subversion checkins rather than when a checkout is made on the puppetmaster. We're doing this with over 200 nodes and 150 modules. On Thu, Sep 1, 2011 at 1:08 PM, Scott Smith sc...@ohlol.net wrote: A directory is a directory. That a directory has a parent directory in which other files exist is pretty moot. On Thu, Sep 1, 2011 at 12:13 PM, Aaron Grewell aaron.grew...@gmail.comwrote: We don't put our manifests under /etc/puppet at all. It's convenient for small installations but as we scaled up I found mixing configs (local, managed by Puppet) and manifests (kept under version control) to be problematic. On Sep 1, 2011 11:58 AM, Russell Van Tassell russel...@gmail.com wrote: I'm currently in the same position, and the solution I've proposed (and am currently working on) involves using a central repository (likely git). The puppet client (running on the master) simply checks the current master branch on the remote repository -- if the revisions are not the same, it just pulls a new copy. While I've not implemented this, yet ... I'm guessing it should work. Anyone have any better ideas -- perhaps a check-in hook to trigger at export? Regards, Russell On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang doug.garst...@gmail.comwrote: I have a real-world, best practices, procedural question. How do you manage the he puppet master, under /etc/puppet, where multiple people may be editing files? The /etc/puppet directory is a working copy, and each user has read access to files created by other users. However, if one person adds a module directory to svn, the lock files that are created by svn are owned by that person, and the next person that comes along can't do svn updates etc. Similarly I can't write to files created by a different user. Yes, sure, the 'right way' to do this may be to have all the files owned by the puppet user, and users don't edit files directly in /etc/puppet, and a script is responsible for performing the svn update, but we're not there yet. Ideas? Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this
Re: [Puppet Users] Updating /etc/puppet ?
Douglas Garstang writes: Was that in reply to my original post, or a subsequent reply? You did see where I said /etc/puppet was a working copy, right? It sounds like you need to get to the point where no one does their edits under /etc/puppet on the puppetmaster, because you're obviously running into the problems that result when people edit there rather than in local working copies. Once you actually start using the features of a distributed version control system in the way it's intended to work, you won't have those problems. Doug. On Thu, Sep 1, 2011 at 1:09 PM, Scott Smith sc...@ohlol.net wrote: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang doug.garst...@gmail.com wrote: I have a real-world, best practices, procedural question. How do you manage the he puppet master, under /etc/puppet, where multiple people may be editing files? The /etc/puppet directory is a working copy, and each user has read access to files created by other users. However, if one person adds a module directory to svn, the lock files that are created by svn are owned by that person, and the next person that comes along can't do svn updates etc. Similarly I can't write to files created by a different user. Yes, sure, the 'right way' to do this may be to have all the files owned by the puppet user, and users don't edit files directly in /etc/puppet, and a script is responsible for performing the svn update, but we're not there yet. Ideas? Doug. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garst...@gmail.com Cell: +1-805-340-5627 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Bind9 Ubuntu Lucid
Craig White writes:
Seems that every cycle, puppet thinks that bind9 service is stopped and
wants to restart...
info: Applying configuration version '1314822598'
notice: /Stage[main]/Bind::Service/Service[bind9]/ensure: ensure changed
'stopped' to 'running'
notice: Finished catalog run in 3.70 seconds
But it's running and from the logs, puppet doesn't appear to have any impact
at all (bind9 was running, continues to run and is not restarted by the
puppet cycle).
# /etc/init.d/bind9 status
* bind9 is running
What's the exit status of /etc/init.d/bind9 status? That's what
Puppet is checking if hasstatus = true is set for the service
(usually the default). Give the command echo $? immediately after
running that; if the value is not 0, then the init script is kind of
broken and you should set hasstatus = false for the service.
# update-rc.d -n bind9 defaults
System start/stop links for /etc/init.d/bind9 already exist.
# ps aux | grep `cat /var/run/named/named.pid`|grep -v grep
bind 21856 0.0 0.2 326644 39664 ?Ssl Aug26 0:17
/usr/sbin/named -u bind
Extremely simple class...
class bind::service {
service { bind9:
ensure = running,
require = Class[bind::install],
}
}
???
--
Craig White ~ craig.wh...@ttiltd.com
1.800.869.6908 ~~ www.ttiassessments.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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: best way of handling source installs
Dr. Ed Morbius writes: While you're considering providers, another case we encounter fairly frequently are just general crap ISV or HW vendor-provided blob shell installers. Usually a self-unpacking shell script, which may itself include various internal packaging formats (tarballs, RPMs, etc.). Dell, VMWare, Oracle, and others. What we have done is to turn such blob installers into OS packages for installation via Puppet, rather than try to manage the direct installation of the blob installer via a convoluted set of execs and such. Overall it is still much easier to manage OS package installation, even with the overhead of having to create the custom package. So as one example, we get the blob into the Mock RPM build environment, unpack it, feed canned input to its configuration script, and then wrap up the finished file tree as an RPM, then get that RPM installed on the hosts that need it. I haven't put deep thought into a puppet solution, but the generalized method would be for the installer script / binary / ISO image, a configuration script (or arbitrary shell arguments and ancillary file list(s)), and some arbitrary post-installation test providing some level of assurance that what you wanted to have installed was actually installed. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: best way of handling source installs
Dr. Ed Morbius writes: In the specific pathological case I'm thinking of (Dell's iSCSI management tools), the net end result is rather poorly defined and spans a significant chunk of the filesystem -- mostly under /opt/dell, but some stray (and largely undocumented) bits, mostly under /etc, with bits under /usr/src. I'd probably have to compare filesystem snapshots to identify these cleanly. At least the Mock RPM-building tool handles this for you; when building packages it uses a chrooted environment and tracks what files get put where so they can be rolled up into a package. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? Because there's stuff that isn't packaged in RPM/DEB, and there aren't enough hours in the day. I'm not convinced this is a /good/ idea. It is, however, an idea. Figure folks can kick it around (or ignore it) and see what interest or other suggestions there are. Seriously, package systems are designed to handle dependency management, *un*installation, and upgrading in ways that are extremely hard to deal with if you insist on doing traditional source-based (or your vendor insists on doing blob-based) installation methods. Yes, you have to create and learn how to use a package-building system, although you might be surprised how easy it is to build custom packages once you're over the initial effort of setting up the package build system. But you get far better and more consistent results if you do. It's an investment that will pay off in the future. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: best way of handling source installs
russell.fulton writes:
I know this and agree with it in principle. It is just that at the
moment I am extremely hard
pressed and really don't have the time to work my way through figuring
out how to build rpms
from scratch. The package Daniel pointed out looks very promising in
this respect adn I will certainly
look at it.
I'll repeat the question from my previous post: Is there a straight
forward way to have a local rpm
repository on the puppet server rather than relying on yum and the RHE
channels?
You can just source packages from an HTTP server rather than implicitly
from configured package repositories.
package { foo:
source = http://my.web.server/packages/foo-1.0-1.i386.rpm;,
ensure = installed,
}
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] First boot with Puppet
Michal Ludvig writes: Hi guys, I'm installing Puppet on RHEL5 systems using KickStart but struggle with the first boot. Here's my situation: 1) kickstart installs the system, including puppet from our local repo 2) after reboot I have to login and set the hostname and IP 3) then run puppet, register it with the server and bring in the config 4) configure puppet for automatic start I have to configure the hostname before running puppet for the first time, otherwise it makes its certificate with a wrong name (either 'localhost' or something supplied by dhcp). I'm aware this is not really a Puppet question but how do you guys do this? How do you (semi-)automatically configure the hostname before running puppet for the first time? We're using Cobbler (which uses Kickstart to do the basic system installation) and it easily allows us to create per-host kickstart profiles that set the hostname and configure network interfaces. That information is actually something you can put directly into a Kickstart profile but it means you'd have to create per-host profiles rather than use one master profile for everything. I'm not our local Cobbler/Kickstart expert, but the guy who created our Cobbler installation even figured out how to script a new host's initial registration with the puppetmaster (I believe the key idea is that there is a command-locked ssh identity key that allows the host to get in to the puppetmaster and issue the right puppetca command). I'd have to do some digging to look up the specifics. Thanks M. -- 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] which is more efficient?
Marcus, Allan B writes:
We need to put a script into /usr/local/bin. Which is more efficient,
put the text into a variable and use content =, or put the file on
the puppetmaster server and use source =
Why do you care about the efficiency of this? It's more important to
make things easier to maintain than more efficient in most cases.
However, I suspect using file { source = ... } will be both more
efficient and easier to maintain.
--
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] More External Nodes
Douglas Garstang writes: On Thu, May 20, 2010 at 10:06 PM, Paul Lathrop p...@tertiusfamily.net wrote: If you don't see a use, don't use the feature. However, when you have an issue and people suggest external nodes is the answer, you might consider listening. Paul, I initially asked about a way to parse nodes files such that I could update them programatically. Various people suggested external nodes. And, here we are. Thanks for your reply. I am listening, but I missed where you suggested a solution to my question. Therefore, I will pose it again. How do I set parameters in external nodes such that I don't have to pass a plethora of qualified global variables to my modules? You have to put that complicated information somewhere if you need to use Puppet to manage a complicated environment. You don't necessarily have to put it in an external node classifier. Your question seems to be based on what appears to be a very cursory understanding of what a Puppet external node classifer does and some possibly misguided preconceptions about how to implement this complicated instance management scheme you want. If you have a lot of service instances that you want to run on a single machine that have lots of individual quirks (like substantially different software versions and configurations) then you may be better off encapsulating each instance in a class that handles all the quirks. With enough commonality among those service instances you could use class inheritance and put the common parts in a superclass. Then you could use an external node classifier to associate the desired set of classes with a node, and not use variable settings in the classifier at all. Or you could use a more traditional nodes file scheme to list the classes for each node; it's not like you have to do this with an external node classifier. Generally you use an external node classifier if you have an external database of system information that you want to be able to access from within Puppet. When the puppetmaster is compiling catalogs and is configured to use an external node classifier, it passes each node name into your classifer program, which can do absolutely anything it wants (pull a record from a database, make an HTTP query, break out components from a standard naming scheme) as long as it ultimately generates YAML-formatted lists of classes and parameters, which are then used with that node. You could presumably accomplish the same thing by using that external source to generate Puppet manifests, but it probably wouldn't be as simple or convenient. Or you could just edit a bunch of Puppet manifests by hand if you don't have that external source and don't see a reason to create one. -- 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: External Nodes
Douglas Garstang writes:
On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop paul.lath...@gmail.com wrote:
You are getting a bunch of misguided answers to this. I'm also
perplexed by your assertion that external nodes requires you to write
custom scripts to parse node manifests.
No, you cannot put resources directly into nodes when you are using
external nodes. In practice, this hasn't mattered; you wrap your
resources in a class, done.
Sorry, but I really don't follow this. It isn't until you drill down
to the node level that you get to the level of detail necessary. For
example, software A requires version X on server A, and software A
requires version Y on server B. The only way I can see to do that it
is to define it at the node level. Defining it at the class level is
too far up the chain.
You're not really talking about defining resources here. You can
specify node-specific variables when using an external node classifier,
and so you could use those to indicate node-specific requirements like
software versions.
Ultimately an external node classifier has to provide these bits of YAML
to Puppet for each node:
classes: [ Puppet class names go here ]
parameters: { arbitrary variable=value settings go here }
So if you need different Apache versions on two different nodes, your
node classifier could supply this for node1:
classes: [ apache-server ]
parameters: { apache_version=2.0.63 }
and this for node2:
classes: [ apache-server ]
parameters: { apache_version=2.2.15 }
And then in each node $apache_version would indicate which version to
install, which you could use in a package resource or whatever.
--
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: External Nodes
Douglas Garstang writes:
classes: [ Puppet class names go here ]
parameters: { arbitrary variable=value settings go here }
So if you need different Apache versions on two different nodes, your
node classifier could supply this for node1:
classes: [ apache-server ]
parameters: { apache_version=2.0.63 }
and this for node2:
classes: [ apache-server ]
parameters: { apache_version=2.2.15 }
And then in each node $apache_version would indicate which version to
install, which you could use in a package resource or whatever.
Steven,
Trying to understand this, but let's say we had multiple instances of
Apache running on each server (we actually have multiple instances of
JBOSS and Tomcat running, but lets stick with Apache for the analogy).
How would defining variables work then? I mean, your example above has:
parameters: { apache_version=2.2.15 }
Extending this, we'd end up using:
parameters: { apache1_version=2.2.15, apache2_version=2.2.16,
apache3_version=2.2.16, apache4_version=2.2.17 }
and so on, depending on what the syntax is:
HOWEVER, we also define a number of different parameters for each
instance of software, which makes the whole set of parameters even
more complicated. Do external nodes work in this case?
You could use separate classes to manage the separate instances, or if
there's enough common infrastructure, you could use class inheritance or
variable settings and conditionals to avoid excessive duplication of
common information. From what you describe I think you'd have to use
some mixture of techniques, because you appear to have a big fat mess on
your hands. I don't think I'd try to use variables the way you are
describing, as you probably would be better off using separate classes
to manage those separate instances.
External nodes should be able to do what you need either way. If you
have a particularly complicated environment then you're likely to have
to stuff more information into the external node database.
--
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] mount order
ed-rfmd writes:
Is there a way to control the order of the mounts?
We have a few second level directories in /a that need to mount after /
a is mounted but it appears that /a is being mounted after /a/1 and /a/
2. If I do a manual mount -a everything is accessible.
Sounds like you need some requires.
mount { /a:
}
mount { /a/1:
require = Mount[/a],
}
mount { /a/2:
require = Mount[/a],
}
--
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] is puppet the right tool for me?
Daniel Pittman writes: Dmitry V'yal akam...@gmail.com writes: Evan Hisey wrote: You forgot a biggy bonus of puppet, no matter what size you support. I have several small ( as in 1-3) groups of very different machines, and with puppet I can rebuild them very quickly on when they need to be replaced or upgraded. doing it by hand takes most of a day or 2. That's great! And what to do with various passwords, private keys and so on? Should I put them in manifest? That is a hard call, and there is probably no single answer. For what it is worth, we decided that this was an acceptable security risk in some places (database passwords containing unclassified data only), and unacceptable in others (SSL certificate private keys). We presently distribute the later set, the keys, only through manual action, although you can use puppet-specific restrictions to serve them up safely from external files. What we decided to do at our site was create a separate version control repository for secure data (passwords, certificate keys, private ssh keys) that is not network-accessible and resides only on the puppetmaster host. The repository is checked out under /etc/puppet/secure and mounted as a separate module in fileserver.conf, so that manifests can refer to files using specifications like puppet:///secure/foo.key. Then Puppet can automatically distribute the security-sensitive files but they don't live in the main repository which is widely distributed (working copies live on all the admin workstations, for example). The minor disadvantage is that you have to log in to the puppetmaster host to actually change anything in the secure repository, but things don't change in there very often. -- 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] Replacing a puppet server
LOhit writes: Hi, Since puppet doesn't have HA/fail over capabilities as of now. How does one mitigate a puppet master failure( Ex. Hardware). When you replace the server and configure the Puppet masterd, the clients may no longer be able to communicate with the server, since the server's SSL certificates would have changed. Back up your puppetmaster SSL keys and certificates and reinstall them if you should ever have to resurrect your puppetmaster for the dead. There is absolutely no reason you should have to create a new puppetmaster certificate if you already have one. But you shouldn't have to totally reinstall your puppetmaster if you back it up properly, why reinstall when you could just restore the backup? You can perfectly well use standard HA techniques to make your puppetmaster a high-availability service. You could have a standby node with a duplicate puppetmaster installation ready to activate, or even use standard load-balancing to have multiple puppetmasters. BTW, I am using puppet to manage about 700+ hosts, I am beginning to worry about the scenario as mentioned above. I definitely don't want to login to each host to clear the ssl directory to make it request new certificate. Thanks, -- LOhit -- 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] Inline include
Douglas Garstang writes: Thanks, but for the simple reason you can't revision control external nodes, they are just not feasible. Wait, what? You can totally implement an external node classifier that takes its data from a version-controlled source. -- 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] Quiesce Puppet?
Douglas Garstang writes: On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks aspa...@doublesparks.net wrote: Douglas Garstang wrote: Is there a way to quiesce the puppet daemon, such that it stays running, but does not run updates, until instructed again to do so? We have puppet deploying our software, and would like to quiesce puppetd so that it doesn't restart services etc until after the upgrade is done. Use puppetd --disable and puppetd --enable. I... guess... that will do. Not ideal though as it stops puppet from running new updates by making it think it's already running. It also doesn't log to syslog that it's currently disabled, so it makes it tough to see if it's been running for a long time and is completely borked, or just locked for an upgrade. Why not have the service require something that will only be present once the upgrade is complete? -- 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] Quiesce Puppet?
Douglas Garstang writes: On Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender ste...@uoregon.edu wrote: Douglas Garstang writes: On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks aspa...@doublesparks.net wrote: Douglas Garstang wrote: Is there a way to quiesce the puppet daemon, such that it stays running, but does not run updates, until instructed again to do so? We have puppet deploying our software, and would like to quiesce puppetd so that it doesn't restart services etc until after the upgrade is done. Use puppetd --disable and puppetd --enable. I... guess... that will do. Not ideal though as it stops puppet from running new updates by making it think it's already running. It also doesn't log to syslog that it's currently disabled, so it makes it tough to see if it's been running for a long time and is completely borked, or just locked for an upgrade. Why not have the service require something that will only be present once the upgrade is complete? I'm not sure, but how would we get puppet to stop the service, run a database upgrade script (and maybe some other stuff), and then restart the service all in the same puppet run? I'm not sure how you'd do that all in the same puppet run, or whether that would even be desirable. But you can certainly use require to ensure that things happen in a particular order, even if it takes multiple Puppet runs to work through all the steps. -- 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] troubleshooting quiet puppet client
chalex writes: # puppetmasterd --version 0.24.7 # puppetd --version 0.25.4 Just upgraded that puppetd client, and now it doesn't do anything: Upgrade the puppetmaster before upgrading any puppet clients. -- 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] exec - creates question
Pete Emerson writes:
If you don't care about the contents of the file, just whether it's
there or not:
unless = /usr/bin/file MYFILE
or
unless = /usr/bin/stat MYFILE
or
unless = /bin/ls MYFILE
should all be pretty lightweight
Actually, if all unless looks at is the return code of the command I
would probably go with
unless = test -e MYFILE
If you use test you could also do more sophisticated things like
require the presence of a real file with -f and combine other tests for
permissions or ownership.
On Thu, Mar 4, 2010 at 12:06 PM, Patrick kc7...@gmail.com wrote:
On Mar 4, 2010, at 7:29 AM, Allan Marcus wrote:
A file that this command creates. If this
parameter is provided, then the command will only be run
if the specified file does not exist::
exec { \tar xf /my/tar/file.tar\:
cwd = \/var/tmp\,
creates = \/var/tmp/myfile\,
path = [\/usr/bin\, \/usr/sbin\]
}
Is there a way to set the content of this file (/var/tmp/myfile) using
some additional parameter in the above syntax?
This isn't the right way to do it, and you may have performance issues
depending on the size of the file, but you can always combine grep with
unless.
If you want to re-extract the file if the file doesn't contain
testString this should work.
exec { tar xf /my/tar/file.tar:
cwd = /var/tmp,
creates = /var/tmp/myfile,
path = [/usr/bin, /usr/sbin],
unless = grep testString myfile,
}
--
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.
--
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.
--
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] capacity planning with puppet.
R P Herrold writes: On Thu, 18 Feb 2010, Nigel Kersten wrote: How, if at all, do any of you do capacity planning with Puppet? somewhat orthogonal to the question, but after reading this piece: http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf at http://www.usenix.org/publications/login/2010-02/index.html ... doing capacity planning for puppet presently may represent a 'premature optimization' The seeming speed and scaling differences between CFengine and puppet are dramatic, and one has to ask if puppet is the right tool to bet on, in its present form -- Russ herrold I think the only real conclusion one can draw from that article is that Ruby is slower than C. Doing capacity planning for Puppet is hardly premature; at most you have to plan to allow more resource usage for Puppet. -- 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] Configuring Networking
Douglas Garstang writes: On Tue, Dec 15, 2009 at 3:47 PM, Peter Meier peter.me...@immerda.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First question... are definitions executed in the order they appear? puppet doesn't execute anything. it manages resources and defines are resources as well. Fine. Does puppet manages resources and defines in the order they appear? Ordering is indeterminate unless require or before are used in resource definitions, which then produce the declared ordering relationship. -- 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] Timestamps need to be in sync on all puppetmasters?
Tony G. writes: They are supposed to have GMT: In these modern times UTC is generally a better universal standard than GMT. But the timezone file in */etc/localtime* is the same on them: md5sum /usr/share/zoneinfo/* 2/dev/null|grep $(md5sum /etc/localtime|cut -d -f1) fcccbcf95c718cf2fdee557763e460be /usr/share/zoneinfo/GMT fcccbcf95c718cf2fdee557763e460be /usr/share/zoneinfo/GMT0 fcccbcf95c718cf2fdee557763e460be /usr/share/zoneinfo/GMT-0 fcccbcf95c718cf2fdee557763e460be /usr/share/zoneinfo/GMT+0 fcccbcf95c718cf2fdee557763e460be /usr/share/zoneinfo/Greenwich Could the /etc/sysconfig/clock file cause this? UNIX time is based on the number of seconds since January 1, 1970 00:00 UTC. This is converted to local time for display based on the TZ environment variable, with /etc/localtime specifying the default local time conversions rule (and usually a copy or link to a corresponding rule file in /usr/share/zoneinfo). /etc/sysconfig/clock has only to do with management of the hardware clock. The ZONE setting in combination with the UTC boolean determine whether the hardware clock is treated as local time or UTC when the hardware clock is set from the UNIX clock during shutdown. For most server configurations it is advisable to manage the hardware clock in UTC (UTC=true). In particular this can avoid some problems with reboots around daylight savings time changes introducing 1 hour offsets. -- 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] Module Execution Order
Michael T. Halligan writes: I think what Doug is trying to ask is, how the hell do we make sure that resources get applied in a predictable order? Use require or before. That's why they're in Puppet. -- 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] Module Execution Order
Paul Lathrop writes: 2) Why does puppet manage dependencies the way it does? 3) How can I keep dependencies manageable? The answer to #2 is more complicated, and has been hashed over before on the list, but I'll comment that some people just don't like the dependency model in puppet. There are other tools out there that use a different model - personally I prefer Puppet's way. Ultimately I think Puppet's way makes the most sense -- when you need to enforce dependencies they're explicitly documented in the manifests, not implicitly dependent to something like declaration order. It helps you to remember them if you move a resource from one place to another. #3 can be answered the same as you would in object-oriented development - develop good abstractions and minimize your crossing of abstraction boundaries. It sounds like Doug's manifests don't follow these guidelines, as he says Within the bootstrapped modules currently I have a horrible mess of unmaintainable requires = statements, that are just going to get harder to maintain as times goes on. I'm afraid to touch it now, for fear of what will break. Refactoring is in order. There are cases where you have a lot of dependencies and ordering requirements and this tends to provoke a reaction of dependency management is HAAARRRD. But those are the cases where it's also the most important. If you want to create something maintainable under those circumstances, you're going to have to work out the proper dependency relationships sooner or later. Unfortunately I don't know of any configuration management tool that figures out dependencies for you; the best you can hope for right now is to have one that lets you express them clearly. -- 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] Best Practices Rewrite - First Draft
Julian Simpson writes: I swear people who use Puppet are more fertile. Congratulations, Paul! Or at least using Puppet frees up time for side projects. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] external nodes and environments
I'd like to extend our Puppet installation to support split production and development environments. We're using Subversion to manage Puppet configurations and already have the recommended /etc/puppet layout to handle a separate development branch. What I'd like to do is have a centralized source of information (that is, not having to edit individual puppet.conf files on clients) to indicate which hosts are in the development environment, which seems to lead me to setting up an external node classifier. However, what I'd really prefer to do is use the external node classifier only to supply the setting of the Puppet environment variable, and leave all of the class membership details in our existing nodes.pp (included from site.pp). The documentation suggests this should probably work, but also says things like If you specify any nodes in your site.pp, you must specify all nodes in site.pp, even those that are looked up via the external nodes script. What exactly does that mean? We currently have a number of Puppet clients that just use a default template without having an explicit node definition; would those have to have explicit entries in our nodes.pp rather than falling into the node default? We're also starting to use Cobbler for automated installation, and I've looked at the configuration management hooks in Cobbler that can be used with an external node classifier in Puppet. These are somewhat appealing, but again I'd rather not have to migrate all the class membership information into Cobbler, and only use the kickstart metadata field in a host profile to specify whether a host is in the development environment. Also, since using Cobbler as an external node classifier requires fetching URLs out of the Cobbler web interface to get the host data, I am nervous about causing problems for Puppet if Cobbler happens to be down. If anyone else is using Cobbler for their Puppet external node classifier, do you just have to keep Cobbler up all the time, or do you have a way to keep the external node classifier working even when Cobbler isn't up at the time? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] exec : creates parameter does not create the file
Swati Tiwari writes:
Hello guys,
I am facing this problem. I have an exec resource which has a create
parameter. The catalog runs properly but the file is not created, has anyone
faced such a problem?
My manifest is
class example
{
exec { sources:
command = /usr/bin/sudo /usr/bin/gem sources -a
http://gems.github.com;,
creates = /tmp/githubadded
}
}
The command runs fine but it does not create /tmp/githubadded file.
Then why do you have 'creates = /tmp/githubadded' in your class? If
the command /usr/sbin/sudo /usr/bin/gem sources -a
http;//gems.github.com doesn't create the file /tmp/githubadded, then
Puppet will run the command over and over.
Normally you use creates in an exec if you want the exec to run if
some specified file or directory doesn't exist, and the command run by
the exec needs to create the file or directory you name with creates.
I also have write permission on this directory.
Note also that it is common for /tmp to be cleared out every time you
reboot a system, so if you are trying to use this to install software
for later use, this may attempt a reinstall when it is unnecessary to do
so.
Any help would be appreciated. Thanks!
I also have to wonder why you use sudo in the command, since the
Puppet client normally runs as root, and if not run as root sudo
normally prompts for a password.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Environment variable access inside an exec
Brandon Whalen writes:
I've spent some time looking at the example recipes and reading the docs on
a problem, but I'm still stumped. I'm trying to add some options to my fstab
and am finding some problems. I'm using the environment option to create an
environment variable MNT_OPTS that I then reference as part of a sed call.
I'm finding that MNT_OPTS is empty when I reference it. My exact code is
below.
#nosuid, nodev, and acl on /home
exec { sed -i 's/\( \/home.*${MNT_OPTS}\)/\1,nosuid,nodev,acl/'
/etc/fstab:
onlyif = test `grep ' \/home ' /etc/fstab | grep -c nosuid` -eq 0,
environment = MNT_OPTS=`grep ' \/home ' /etc/fstab | awk '{print
$4}'`;
}
AUGH! THIS IS INSANE! I AM INSANE NOW!
Could someone tell me what I'm doing wrong and tell me what I need to do to
fix it or point me at some examples.
I strongly suggest that you look at the mount resource type. This
thing you are doing with 'sed' is nasty and dangerous.
Regards,
Brandon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] puppet 0.24.6 conf/redhat/client.init broken in RHEL versions 5
The conf/redhat/client.init script (installed in /etc/init.d) in 0.24.6 has this status method: status) status -p $pidfile $puppetd RETVAL=$? ;; Unfortunately the '-p $pidfile' option is available in Red Hat Server 5 but not earlier versions, where it produces an error: $ cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 7) $ /etc/init.d/puppet status pidof: invalid options on command line! pidof: invalid options on command line! -p is stopped $ We were using a standard cron job /etc/init.d/puppet status || /etc/init.d/puppet restart on our hosts to ensure Puppet stayed running; now it restarts Puppet every time the cron job runs (until I changed the cron job to use a different check for the existence of puppetd). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Anyone attending LISA 08 next week...?
Juri Rischel Jensen writes: Hi All Luke and I are attending LISA08 in San Diego next week. Are there any other Puppeteers who are attending? Or living in the area and interested in a meet-up with me and Luke...? I'll be at LISA. Is Luke planning on running a Puppet BOF as he has in past years? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Install configs initially then stop managing those files
TomTom writes: Hello All, I am trying to build up some dev boxes. These boxes are obviously very different from our other production/QA environments. I have a need to allow developers to configure certain config files such as httpd.conf. What I need to do is have puppet push out the config file at installation and then allow the dev users to configure it there after. Does anyone have a suggestion on how to implement this? If you're not going to use Puppet for ongoing management of a file, there's probably not much point to using Puppet to install the file in the first place. There are potentially a number of good arguments you could use to encourage your developers to also use Puppet and version control software as part of their development process. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
