Re: [Puppet Users] template troubles
Me info...@gmail.com writes:
The nodes file:
node /dns[0-9]+/ inherits globals {
$dns_role = $hostname ? { # needs to be either master or slave
/dns01/ = [ master ], # the 01 box is always the
master by convention
default = [ slave ],
}
include defaults
include host2dns
}
Oh. You're not setting $dns_role to the string master or slave.
You're setting $dns_role to an *array*, whose only member is master or
slave. That array is never going to equal a string (but as it turns
out, it will stringify into the string value you expect).
Change that to:
$dns_role = $hostname ? {
/dns01/ = 'master',
default = 'slave',
}
instead, and I bet it will start working.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet SSL Ciphers
Nigel Kersten ni...@puppetlabs.com writes: We actually had a feature request in about this recently that shouldn't be too hard to find if you do a search. More people caring about this will lead us to prioritize it more, however... You really should move away from Webrick for production for several reasons, including this one. It's not suggested for production use. Webrick is very nice for the Puppet CA if one wants to run it on a separate system that doesn't otherwise need a full web server. It allows the CA to run as a nicely stand-alone service, and the CA is not particularly performance-critical and doesn't suffer from the performance issues of Webrick. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] EC2 with puppet bootstrap notes and scripts
Nigel Kersten ni...@puppetlabs.com writes: Honestly, you should be discovering such missing requires in your testing process. It's not good practice to simply run another one just in case in my opinion. That's easy to say in theory, but extremely difficult to test in practice, since order is non-deterministic and therefore you may not notice a missing requires unless you get lucky, even in test. You need multiple iterations in test to probabilistically find all missing requires, which quickly becomes more trouble than it's worth when the only drawback is requiring multiple Puppet runs. We too consider this to be a bug, but it's a low-priority bug that we fix when we notice it, which can take a while. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet hangs
kit efossv...@gmail.com writes: we have one puppet server managing approx servers, all FreeBSD. The problem is that the puppet clients all hangs, one by one, eventually. They will run for anything between an hour up to a week. But eventually the all hang. The Debian project is similarly seeing lots of instability in Puppet in the Debian kfreebsd ports, which are Debian userspaces with the FreeBSD kernel. Our suspicion so far has been Ruby bugginess with FreeBSD. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] node inheritance, variable scope, and pain.
Daniel Pittman dan...@rimspace.net writes:
It was, until yesterday, my naive expectation that this would work:
node default{ include broken }
node krosp inherits default { $value = not }
class broken{ notice(This is ${value}broken) }
Specifically, I expected this would output 'This is not broken', but instead
we get the counter-intuitive and *very* annoying 'This is broken'.
As far as I can tell this is because puppet treats $value as out of scope to
the classes included from default: the order of processing is:
- node 'default', or any other inherited node.
- any classes included are processed.
- node $hostname is processed.
This means our practice of included universal features into the default
node, then inheriting that into other nodes, also makes it impossible
for us to do things like configure features of those universal classes.
I really do *NOT* want to go down the path of having to repeat the same
set of classes in every node; that invites disaster, by forcing me to
repeat myself.
Our rule of thumb is that any time one is tempted to set variables and use
those values in included and inherited classes, that's a red flag that you
actually wanted a define instead. If you had instead written this as:
node default { broken { message: value = } }
node krosp inherits default { Broken[message] { value = not } }
define broken($value) { notice(This is ${value}broken) }
I'm pretty sure you'd get the behavior you expected.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] best way to disable a class
Christopher Johnston chjoh...@gmail.com writes: Say I have two classes: package::stable -- installs a specific version of a pkg package::devel -- installs the latest version in the repo The class package::stable would be specific for 90% of my machines in my environment, but on occasion we have to override the package version we want to install to grab the latest version. Is there a way to disable the package::stable class if say package::devel is assigned to a node? I may be misunderstanding, but it sounds like package::devel should be inheriting from package::stable and overriding the ensure type (to latest instead of present). If you do that, you don't need to disable package::stable. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Pushing a file only if another does not exist.
Douglas Garstang doug.garst...@gmail.com writes:
I am trying to write a module for tripwire. I need to push out the
twcfg.txt and twpol.txt files only if the tw.cfg and tw.pol files do not
currently exist.
How can do I this with File{}? I'm can't seem to find a way to do it.
In general times, how can you deploy file A only when file B does not
exist?
And... tripwire... what a mess. I am trying to use push out the site
key, then use several Exec{}'s to generate the local key, and encrypt
tw.cfg from twcfg.txt and tw.pol from twpol.txt. Hence the need to only
deploy the source files only if the encrypted files are gone.
I think that if you're installing Tripwire policy files on local disk, I
would take a step back and see if you have a better design available.
Tripwire is the poster child for something that really wants a read-only
network file system. You want to only be able to update the files in one
place that requires secure access, and then have all your systems read the
signed database files from that one place but not have the ability to
change them.
You can simulate most of the protection that you get from that by having
Puppet actively monitor things like the local keys and warn you if the
attacker just changes keys so that they can initialize a new database, but
I think it's easier to just put it on a network file system in the first
place.
Doing Tripwire properly is generally hard anyway, since you need a way of
doing the system verification run that the attacker can't just replace
with a cron job that mails you a copy of a clean report, although to some
extent you can rely on lazy attackers who don't find things like that.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Pushing a file only if another does not exist.
Douglas Garstang doug.garst...@gmail.com writes: On Sat, Apr 24, 2010 at 4:27 PM, Russ Allbery r...@stanford.edu wrote: I think that if you're installing Tripwire policy files on local disk, I would take a step back and see if you have a better design available. Tripwire is the poster child for something that really wants a read-only network file system. You want to only be able to update the files in one place that requires secure access, and then have all your systems read the signed database files from that one place but not have the ability to change them. A read-only network file system... Well, all I can think of there that would be appropriate would be sshfs. Having never implemented it, I'm not sure what's involved in that. I'm not sure why a read-only file system is required though. What's wrong with puppet managing the files? If I'm an attacker, and I want to fool Tripwire once I've taken over the system, I change the Tripwire keys and then reinitialize the database. Tada, now there are clean Tripwire reports. Of course, you may have other ways of detecting that Puppet isn't running regularly if the attacker stops it, in which case Puppet has a chance of detecting that the keys have been changed (although even that can be a bit tricky). If the database is in a location that's read-only from the perspective of the system running Tripwire, then there isn't any way to just quietly update the database without your knowledge. This is why the Tripwire documentation recommends a write-protected floppy disk. I find a network file system like a read-only NFS export to be a lot easier to manage than read-only floppy disks. Of course, I'm spoiled by having AFS available everywhere, and if you don't already have any network file system handy, setting one up may be more trouble than it's worth. PCI compliance doesn't go into details. The whole thing is a crock of shit really. Installation of tripwire was one of the requirements on the list of 10,000 or so, so that's what I am trying to implement. Then again, so was anti-virus software on Linux... Welcome to the wonderful world of PCI. Have fun with password lockout! I love security standards that require you to turn an unsuccessful compromise attempt into a successful denial of service attack. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Pushing a file only if another does not exist.
Douglas Garstang doug.garst...@gmail.com writes: What about the script that mounts the file system? That could be compromised. This seems somewhat like security via obscurity to me. Your security is only as good as it's weakest link, and the script that runs every day would be the weakest link. Therefore, there doesn't seem to be much point in going into an extra level of effort to secure other parts of tripwire if the script is still a vulnerability. I was assuming you'd leave the file system mounted all the time. And... this doesn't help with my key issue anyway. Lets say that the client system mounts /etc/tripwire every day so that it can run it's check. This means that puppet has to put the client side key on the network file server, which means it's still not running on the same machine as the puppet master, which is essentially the same configuration in the first place. Right, but you're only putting it on one system that has write access to it, namely the file server, and you can lock that system down much more completely. That one system holds all the keys for all your Tripwire databases, server and site. At that point, it's not clear that you need to use Puppet to manage the database and keys on the file server, since they're just data that lives in one place at that point. (Well, you might want a backup.) Of course, if you want to treat them as configuration, then yes, you have a Puppet issue still -- I didn't mean to say it's not a reasonable question. But I think you're in a better spot for the client systems. But yes, you need to ensure that the attacker can't just unmount the file system and replace it with local directories with a new database, etc. The normal way that one does this is that one puts the checking binary on the network file system as well, compiles a cryptographic key into the checking binary, and then has the binary checksum itself and then sign its report with that key. You then need infrastructure to check that the report is signed with a valid key, and also that you get a report every day, and that it's not a replay of the previous day's. Samhain does some stuff like this. In practice, most people stop some point short of this, since after all, a sophisticated attacker may be able to load a kernel module that will prevent Tripwire from seeing that binaries have changed. It's all just moving the problem, and it's a question of how much you want to defend against. I just like network file systems for this stuff because if you have them handy, it's an easy way to make the database part more robust. (For the record, we put our Tripwire databases in AFS so that they're read-only and put the Tripwire binary in AFS, run it from cron on each server, mail the results to a central collection point, and check for servers that aren't sending reports. We don't defend against replacing the cron job with just mailing out a clean report, and we don't use cryptographically signed binaries, although we keep thinking about a project to do both of those.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Request to make changes to stable Goobuntu Puppet configs
Ohad Levy ohadl...@gmail.com writes: While its not for the public, I do have a question in the matter, what do most people do with id tags? I do have this annoying problem that the id changes every now and then (e.g. because of the protocol used to checkout the files) hence changing the file. We used to use them in Subversion since it was nice to know when a file changed, but we stripped them all out when we switched to Git and haven't missed them. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 100% CPU usage
Thomas Mueller tho...@chaschperli.ch writes: Am Fri, 12 Mar 2010 03:30:59 -0800 schrieb DieterVDW: On Mar 12, 11:21 am, Patrick kc7...@gmail.com wrote: Puppet doesn't handle a folder with lots of files well. It handles large files even worse. The standard advice is Try putting the files in a package and distributing them using apt. Another common answer is to try combining exec and rsync. I ended up using apt. Here are the tutorials I used: The problem is, I -am- using apt! Those files are downloaded and installed using apt, I just want puppet to make sure they are owned by a certain user and group. That's the only thing puppet needs to do. if the files are installed by apt and do not have the permissions you need, you may need to have a look at dpkg-statoverride (man dpkg- statoverride). Under most circumstances, though, all you need to do is ensure that the files have the correct ownership in the *.deb when you create it and then dpkg will do the correct thing when installing the package. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Git vs SVN?
SyRenity stas.os...@gmail.com writes: Is there any advantage of using Git vs SVN when using puppet? We just finished switching from Subversion to Git because we wanted Git's merging and cherry-pick support for maintaining separate production and development branches of our manifests. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] New Puppet Documentation Site
Nigel Kersten nig...@google.com writes: Andrew Schulman google-groups-and...@sneakemail.com wrote: There seems to be a glitch in http://docs.reductivelabs.com/guides/introduction.html#functions . I really like it, but the font size is too big for documentation imho. I'm finding myself zooming out, which I rarely do. Chrome and Safari on OS X. Wow, with Firefox on Linux, the font is still too small, although it's closer to being large enough than most web sites. screen #0: dimensions:1600x1200 pixels (411x311 millimeters) resolution:99x98 dots per inch -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] continues puppet run in production
berber webersi...@gmail.com writes: Puppet runs every hour or so on our production servers and makes sure they stick to the manifest. I'm curious to know if this is advised for production. In theory, if something breaks in puppet for whatever reason, all of our production servers may be hurt simultaneously. We do it as well. You have to be fairly paranoid about what you change in the Puppet manifests, but we like the constant consistency check that all is as it should be. We do run Puppet in --noop mode and require manual intervention to run it on our Kerberos KDCs. We've only gotten bitten by this once, when there was a bug in Puppet that occasionally caused it to overwrite managed files with their own checksums. That bug was fixed a long time ago, but it was pretty bad while it was present. But you'll notice it wasn't enough to keep us from continuing the policy of running Puppet in production. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Multiple Environments
Douglas Garstang doug.garst...@gmail.com writes: I'd like to be able to split out my puppet production and test environments so that I can continue to develop puppet modules/manifests without breaking production. How are people doing this? Puppet environments may be one way. I guess I'd have a main(prod) environment and a test one. When I was finished with testing, I could rsync the files over to the prod environment. Is this how others are doing it? Our plan is to do basically that but with Git branches rather than rsync. We currently already have our entire Puppet configuration in a version control system (currently Subversion), and will be converting it to Git and then using Git branches to maintain the separate environments. The advantage of Git branches is that we can much more easily merge or cherry-pick changes between the environments. For example, changes that must be made in production can be made there and then merged into test, so that test stays in sync easily but can maintain separate changes. Our intention is to then cut a new production branch from test every three months and retain two production branches, cutting each production server from the old branch over to the new branch on a quarterly cycle according to the requirements of that production environment. That way, all servers benefit from general architectural changes, but those changes are thoroughly tested first in the test/dev environments (which will all point to the master branch). -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Debian preseed values for puppet deb package
Joe McDonagh joseph.e.mcdon...@gmail.com writes: Because FAI is deprecated. By whom? You can preseed nearly all necessart values via the debian-installer, and LVM can be done in the late-command. I think you'd be way better off using FAI. It really makes handling things like this much easier rather than relying on debian-installer and all packages to support the preseeds that you want. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Debian preseed values for puppet deb package
Joe McDonagh joseph.e.mcdon...@gmail.com writes: It would be nice if we could preseed the puppet installation package with some values. This way during boot up, preseeding debian-installer, I could also preseed the puppet package to start in a certain environment. Beyond that you could preseed certname, server, etc. This e-mail is to basically gather thoughts and see if it's worth filing a debian bug to get this functionality into the .deb. Out of curiosity, why not use FAI? -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: facter inconsistent results
Andrew Schulman google-groups-and...@sneakemail.com writes: Hi. I'm running facter 1.5.1 in Ubuntu Jaunty. facter is giving me inconsistent results for the operatingsystem fact: $ facter operatingsystem Debian $ facter | grep operatingsystem operatingsystem = Ubuntu operatingsystemrelease = 9.04 Is this a known problem? Possibly fixed in a more recent release? I searched the list for it and didn't see any reports of this. This sort of thing is a common problem with facter caused by the fact that facter doesn't load all plugins unless you run it without options. I think there may have been some subsequent work to improve this, but I'm not sure. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: facter inconsistent results
Nigel Kersten nig...@google.com writes: Ugh. This is particularly sucky, and I vote this fact needs to be fixed for this irrespective of the plugin loading issue. The problem is: if Facter.value(:lsbdistid) == Ubuntu Ubuntu elsif FileTest.exists?(/etc/debian_version) Debian the first invocation doesn't fill lsbdistid, so it falls through to Debian when /etc/debian_version exists on Ubuntu. Inside Puppet, this works fine, since Puppet always loads all plugins. It really only affects the command-line invocation (although I don't know what happens if you use facter in a different Ruby program). -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: facter inconsistent results
James Turnbull ja...@lovedthanlost.net writes: Andrew Schulman wrote: This has nothing to do with grep. facter should report a single consistent value for 'operatingsystem' when invoked in either of these ways. Maybe I am jumping in too late but do you have lsb installed on that host (lsb-base package from memory I think)? Because if you don't then Facter won't return Ubuntu. Yeah, I bet that's more likely than my explanation, given that it's also not working inside Puppet (which doesn't have the plugin problem). Although that doesn't explain why running facter with grep works -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: user::virtual and selectivly removing users
Christopher chris...@pricegrabber.com writes:
From what I remember (and after looking at the RH docs on users) , UIDs
from 1-499 are for system users, and UIDs from 500 and up are for
regular users.
Luke, James, et al.:
Is it a bug that the code uses less than or equal to 500? I would think
it should be less than 500 ( no equal ). I could use resources { user:
purge = true , unless_system_user = 499 } , but IMHO , 'less than'
in the puppet code would be better.
yes? no? maybe?
Yup, that looks like a bug to me too.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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: user::virtual and selectivly removing users
Christopher chris...@pricegrabber.com writes:
I have an existing puppet infrastructure, part of which manages adding
and removing users from our servers. Now I would like to manage users
in a way similar to the best practices
http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice#managing-users
guide, with different combinations of users on different servers.
something like; admins, managers, dba, developers, qa. On different
server types like; restricted, database, general, web, mail, etc.
Now my problem is that I currently have every user on every server (for
legacy reasons) and need to either add or remove users based on the
above classifications.
If you turn on purging for user resources, any users not explicitly added
to that server will be automatically deleted by Puppet unless they're in
the UID range for system users.
resources { user: purge = true }
Then you don't have to generate removal rules for users, just make sure
that you have all the users defined that you want.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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: managing debian alternatives
lluis ll...@ingent.net writes:
there any reason not to configure debian alternatives this way?
file {
/etc/alternatives/java:
ensure = /usr/lib/jvm/java-6-sun/jre/bin/java;
}
Yes, you won't modify any slaved alternatives, such as the man page. You
should always use update-alternatives rather than manipulating the file
system to change alternative selections.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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: apache2-prefork-dev and apache2-threaded-dev
Asif Iqbal vad...@gmail.com writes: I am using puppet 0.24.8 with passenger 2.2.2. and apache2 on ubuntu 9.04 I notice http://github.com/reductivelabs/puppet/tree/master/ext/rack 's manifest.pp suggests to install `apache2-threaded-dev' for puppet 0.25. Can I install it as well while running puppet 0.24.8? If yes, ubuntu forces to remove `apache2-prefork-dev' . apache2-threaded-dev is the standard Apache development package on Ubuntu. I forget the story behind apache2-prefork-dev, only remember that in general you don't want to use it. I have few FIN_WAIT2 status on port 8140. Will `apache2-threaded-dev' fix those network status hang issues as well? No. That package is purely the development environment and libraries for building Apache modules and has nothing to do with the running server. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: how do I dictate order?
Jeremy Hansen jer...@skidrow.la writes: How do I dictate the order of how things get executed? Right now it's installing the package first, then doing a usermod/groupmod to set the uid/gid and it's trying to run the init commands before the package is installed, etc. You can do it from either direction, but the way that we've found makes the most sense to us is to make the thing that should go second require the thing that should go first. You do that with the require parameter on the Puppet resource. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: /etc/init.d/puppet on debian
Gary Law gary@gmail.com writes:
The init script is clearly trying to make the pid file appear in
/var/run/puppet... so I've little idea why this is happening.
from the init script:
start_puppet() {
start-stop-daemon --start --quiet --pidfile
/var/run/puppet/$NAME.pid \
--startas $DAEMON -- $DAEMON_OPTS
}
That flag doesn't say where to write the PID file. It tells
start-stop-daemon where puppetd *will* write the PID file. You still
have to configure puppetd elsewhere (in puppet.conf, specifically) to
put the PID file there.
Everyone seems to get confused about what the --pidfile option to
start-stop-daemon does. It doesn't create anything at all. It just
says where to find something that the daemon is creating.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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: Licensing and Copyright
Luke Kanies l...@madstop.com writes: 2) Stick to a viral/reciprocal license (probably AGPLv3) but require Sun-style copyright contribution (which provides the project a non- exclusive license to the copyright). This provides a single organization with a license for all copyright, and allows that license holder (Reductive Labs) to protect against license infringement, provide patent indemnity (which I've already been asked about by others but cannot currently offer), relicense Puppet (and produce commercial software that integrates with that relicensed product), and probably more. AGPL is a little controversial, to warn. So far, I think it's likely that organizations such as Debian will continue to consider it sufficiently free, but it's a bit odd in its requirements and depending on how one reads it, some people think that it's onerous for a developer who wanted to make private modifications. I'm not sure it's a big enough problem to warrant not using it, but it's something to be aware of. It makes people more nervous than the GPL does. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: /etc/init.d/puppet on debian
Nigel Kersten nig...@google.com writes: Keith, can you make sure you bug report this on bugs.debian.org ? A few of us have joined in to help the Debian Puppet packaging project, and we're going to start churning through the reported bugs next week. That's excellent news -- thank you very much for doing this! -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: Installing 0.24.8 as gem (or deb?) on Debian
Ryan Steele ryan.g.ste...@gmail.com writes: I'm happy to do this for Ubuntu, if I have Luke's blessing. I'll talk to my employer and see if they're willing to host a PPA that can be linked to from the Puppet wiki. Please join the pkg-puppet group and help them prepare the packages rather than doing this. Otherwise, you're just duplicating effort. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: Installing 0.24.8 as gem on Debian
Graham Stratton grah...@mocomedia.net writes: I have just tried to install puppet 0.24.8 as a gem on a clean Debian Lenny system. The puppetd script is not added to my path. Is this a bug or have I made a mistake? Gem and real distribution packages collide in unfortunate ways that make it hard to support gems within distribution packaging and maintain the guarantees of distribution packaging in sane ways (such as everything in /usr/bin is owned by a package). I suspect that you're encountering one of those problems. It's generally better, on Debian systems, to use the standard Puppet packages. There isn't a 0.24.8 package yet, but I suspect there will be fairly quickly. Once there is, although it will be uploaded for Debian sid, you can download it from packages.debian.org and install it on an older Debian system. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: lsb_release misleading..
Steve Wray steve.w...@cwa.co.nz writes: I understand we have a variable $lsbdistcodename which gets its info from the output of the lsb_release command but I've just found that this is not very reliable. I have several Debian Etch servers for which lsb_release reports that they are running sarge :( So far I've been unable to find out how to correct this or where to start in correcting it! Any ideas? Make sure that you really have the etch version of base-files installed. The lsb_release information is based on the contents of /etc/debian_version, which is shipped in base-files. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: Experiences with RHN Satellite?
PeterBurkholder pburkhol...@gmail.com writes: My boss has RedHat coming in on Tuesday to give a spiel on RHN Satellite. I'm dubious, as it seems mostly like a web UI wrapped around a Yum repository system and a half-baked configuration management system. I'm of the opinion that our time and money would be better spent getting off of RHN for package distribution, setting up our own Yum repositories, getting a good start on Puppet, and bringing in Luke Kanies for a week to bring the Puppet installation to up to snuff. FWIW, we'll be looking about 50 systems that need to be managed, and we may not have to pay for server itself ($13.5K) just for the system subscriptions ($200 each). After spending a completely unproductive six months trying to get the Satellite to work for us, we did pretty much exactly what you said above and had considerably more success. In our experience, the Satellite is buggy, limited, and opaque, and basically unsupported by Red Hat in any meaningful way. (I think the icing on that cake was when the Red Hat on-site engineer proved incapable of installing his own product.) I do, however, know other people who have had considerably better luck with it and swear by it. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: Are version 0.24.1 and 0.24.4 good enough?
Kyle Cordes kyle.cor...@gmail.com writes: At the risk of being too far offtopic here on the Puppet list: I wonder if there are, or will be, any wide-use distributions that work differently, that update incrementally rather than a whole release at a time. I imagine a world where I installed once and never upgraded a distro release, but rather got new versions of everything a bit at time. This could easily create more trouble than it solves, obviously. If you wanted that behavior with Debian, you can actually get it: that's what Debian unstable does. However, there's a reason why it's called unstable. :) Debian testing is a bit less aggressive by forcing packages to wait for a bit to be sure that there aren't serious issues, but the security support is not quite as active as it is for Debian stable. (I run Debian unstable on nearly all of my personal systems, Debian testing on my primary desktop, and Debian stable on my personal servers.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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: How dangerous is...
dd-b [EMAIL PROTECTED] writes:
package { something: ensure = latest } ?
Do people mostly use it, mostly not use it, is it highly in dispute,
or is there consensus?
We don't use it because we don't tightly control when things go into our
repository and sometimes upload things we don't want to deploy yet. We
also like to stage and carefully control when packages are upgraded.
It's not an unreasonable thing to do for test/dev environments, but I'd be
nervous about using it in production. I like to know when packages are
being upgraded and to watch. Puppet can't prompt an administrator, so if
something goes wrong with the package installation, things can be left in
a half-installed state.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-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
-~--~~~~--~~--~--~---
