Re: [Puppet Users] Live near Oslo? Want to work with Puppet?
Hi Lars, I would be interested, could you send me further details please. Best Regards Martin Wheldon On Mon, Feb 1, 2010 at 4:00 PM, Lars Tobias Børsting lars.tobias.borst...@gmail.com wrote: We're hiring personnel with sysadmin experience in UNIX based systems. We want someone who has heard of puppet and likes automation! Must haves: * UNIX experience (One or more of Linux, BSD, Solaris et.al.). * Heard of Puppet and like automation. * Good social skills. * Live near Oslo or willing to move. If you are interested, send me an email to larst...@arrive.no and I'll send you more info about the job! -- Sincerely yours, Lars Tobias Børsting Tjeneste-/sikkerhetsansvarlig, Systemdrift, Arrive A/S E-post: larst...@arrive.no -- 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] Re: Make puppet indifferent to package
On Feb 1, 8:55 am, Doug Warner d...@warner.fm wrote:
Since it's part of my base node that every box inherits, it's pretty painful
to just ignore this one class. And as Dan said, this type of thing should be
easily doable.
I'm not sure I follow that response. I think you're saying you don't
want to comment out the include, because you want it applied to other
hosts. Fine, but what about the other alternative I suggested: using
an if to selectively disable the class. Like this:
node base {
# ...
if $hostname != excludeme {
include PkgGroup::InstallPkg
}
}
Quick and dirty. Recommended for short-term use only. Offer not
valid where prohibited by law.
John
--
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] cron jobs in extra files
Hi, is there a way to manage cron jobs by puppet with the builtin cron ressource in extra files? I use to manage my cron jobs below /etc/cron.d and a service own name, for example /etc/cron.d/apache (which can contain many jobs). If I remove my service apache from the system or migrate it to another machine I have exactly one cron dependency so it is very easy to manage. I know, puppet manages my jobs but I like it that the system has the same structure as without puppet (for example if I had to remove puppet for some reason). I don't see a way to do that in puppet but maybe I don't understand the documentation. regards Oli signature.asc Description: This is a digitally signed message part.
[Puppet Users] Forced service start/stop/restart using puppetrun?
Hi, we use puppetrun to manage our servers and one thing is missing that would make my life much easier. Is there a way to start/stop/restart services directly with puppetrun? I made some experiments but nothing really worked out. I'm looking for something like this: # puppetrun --host abcd --host efgh --tag restart_my_service It's easy to create a class to restart services but it then get applied anytime i use puppetrun. Thanks, Daniel -- 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: cron jobs in extra files
I use the same layout and the only way it works for me was to create file resources and distribute the files directly. After distribution i call check_system_crontabs to rebuild the crontab based on cron scripts in /etc/cron.d ... afaik there's no way to use the cron type to accomplish this layout On Feb 2, 3:15 pm, Oliver Schad pup...@oschad.de wrote: Hi, is there a way to manage cron jobs by puppet with the builtin cron ressource in extra files? I use to manage my cron jobs below /etc/cron.d and a service own name, for example /etc/cron.d/apache (which can contain many jobs). If I remove my service apache from the system or migrate it to another machine I have exactly one cron dependency so it is very easy to manage. I know, puppet manages my jobs but I like it that the system has the same structure as without puppet (for example if I had to remove puppet for some reason). I don't see a way to do that in puppet but maybe I don't understand the documentation. regards Oli signature.asc 1KViewDownload -- 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] Patching Solaris with Puppet?
Hi: The pup...@sun case study recently posted to the RL blog [1] says they use Puppet to make security patching easier. Anybody know how they do that? Is there some magic in Puppet which makes patching Solaris easier? Thanks! Footnotes: [1] http://reductivelabs.com/2010/01/26/case-study-sun-microsystems-uses-puppet-to-accelerate-system-updates-and-ensure-consistent-configurations-across-their-web-server-architecture/ -- 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] cron jobs in extra files
Please ignore, sorry for the double posting signature.asc Description: This is a digitally signed message part.
Re: [Puppet Users] Forced service start/stop/restart using puppetrun?
# puppetrun --host abcd --host efgh --tag restart_my_service It's easy to create a class to restart services but it then get applied anytime i use puppetrun. puppet's idea is to ensure that your system is in a certain state, and if not do anything to achieve this state. However just executing commands is not really the idea. If you are looking for something to executes commands on demand on certain systems have a look at func [1] or mcollective [2]. cheers pete [1] https://fedorahosted.org/func/ [2] http://code.google.com/p/mcollective/ -- 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: cron jobs in extra files
Am Tuesday 02 February 2010 schrieb mir Daniel Kerwin: I use the same layout and the only way it works for me was to create file resources and distribute the files directly. After distribution i call check_system_crontabs to rebuild the crontab based on cron scripts in /etc/cron.d ... afaik there's no way to use the cron type to accomplish this layout Ok, so maybe we could make a feature request - I think it is a very common cron job design. regards Oli signature.asc Description: This is a digitally signed message part.
Re: [Puppet Users] Re: cron jobs in extra files
Zitat von Oliver Schad pup...@oschad.de: Am Tuesday 02 February 2010 schrieb mir Daniel Kerwin: I use the same layout and the only way it works for me was to create file resources and distribute the files directly. After distribution i call check_system_crontabs to rebuild the crontab based on cron scripts in /etc/cron.d ... afaik there's no way to use the cron type to accomplish this layout Ok, so maybe we could make a feature request - I think it is a very common cron job design. don't hesitate to open one. cheers pete -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cannot seem to turn off the CA
On Mon, Feb 1, 2010 at 8:53 PM, Scott Smith sc...@ohlol.net wrote: On 2/1/10 8:10 PM, nicholas wrote: Trying to manage my certs sanely, upgrading from 0.24.8 - 0.25.3 I setup one host as the CA and have all my clients point to that. Then I have several puppetmaster's running on other hosts. Problem is, puppetmasterd seems to be hardcoded to be a cert authority Even if I set the 'ca' flag to false. It keeps trying to create the ca.pem file and use that, even though I have one and it should use that instead. How are you running puppet? Are you using Passenger? I found ca = false didn't work in the .conf file with Passenger, and I instead had to add --no-ca to the args. Is there a reason that the puppetmasterd has to be a CA? How can I get puppetmasterd to use the ca.pem file I provide for it? Are you putting the PEM in the right place? This is what my Puppetmasterd ssl dir looks like: -bash-3.2$ find . . ./certs ./certs/ca.pem ./certs/puppet.domain.com.pem ./crl.pem ./private_keys ./private_keys/puppet.domain.com.pem ./public_keys ./public_keys/puppet.domain.com.pem ./certificate_requests ./private ./ca ./ca/private ./ca/requests ./ca/signed -scott -- 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. -- nigel -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Make puppet indifferent to package
On 02/02/2010 09:05 AM, jcbollinger wrote:
I'm not sure I follow that response. I think you're saying you don't
want to comment out the include, because you want it applied to other
hosts. Fine, but what about the other alternative I suggested: using
an if to selectively disable the class. Like this:
node base {
# ...
if $hostname != excludeme {
include PkgGroup::InstallPkg
}
}
Quick and dirty. Recommended for short-term use only. Offer not
valid where prohibited by law.
That would probably be fine for this situation. I was finally able to confirm
that ensure = absent in the ::disabled class *was* working as expected, so
it's not like we ran into any bugs, just some possible testing process problems.
Thanks for all the ideas!
-Doug
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Re: Distributing Facts to client.
So this is what you need:
1. Put your fact into a module - let's call it custom.
$ mkdir -p /etc/puppet/modules/custom/{manifests,lib}
$ mkdir -p /etc/puppet/modules/custom/lib/facter
$ touch /etc/puppet/modules/custom/manifests/init.pp
2. Copy your fact into /etc/puppet/modules/custom/lib/facter
3. Check fileserver.conf to make sure the [plugins] mount is there
but has NO path statement - something like:
[plugins]
allow *.lovedthanlost.net
4. Configure puppet.conf
[main]
pluginsync = true
factpath = $vardir/lib/facter
And that's it.
Can you let me know how that goes?
Regards
James Turnbull
That worked like a champ! Thank you very much, that was getting very
frustrating.
--
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: Distributing Facts to client.
So this is what you need:
1. Put your fact into a module - let's call it custom.
$ mkdir -p /etc/puppet/modules/custom/{manifests,lib}
$ mkdir -p /etc/puppet/modules/custom/lib/facter
$ touch /etc/puppet/modules/custom/manifests/init.pp
2. Copy your fact into /etc/puppet/modules/custom/lib/facter
3. Check fileserver.conf to make sure the [plugins] mount is there
but has NO path statement - something like:
[plugins]
allow *.lovedthanlost.net
4. Configure puppet.conf
[main]
pluginsync = true
factpath = $vardir/lib/facter
And that's it.
Can you let me know how that goes?
Regards
James Turnbull
That worked like a champ! Thank you very much, that was getting very
frustrating.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cannot seem to turn off the CA
On 2/2/10 7:04 AM, Nigel Kersten wrote: How are you running puppet? Are you using Passenger? I found ca = false didn't work in the .conf file with Passenger, and I instead had to add --no-ca to the args. Weird, what version of Passenger are you using? I've got 2.2.5 and don't have to do that. -scott -- 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] cfengine like groups
Great explanation. Thank you very much.
On Tue, Feb 2, 2010 at 10:12 AM, Bruce Richardson itsbr...@workshy.orgwrote:
On Mon, Feb 01, 2010 at 05:30:47PM -0600, Anchi Zhang wrote:
Greetings,
CFEngine 2 (not sure about 3) allows groups definitions such as
groups:
ntp = { ntpserv1 ntpserv2 }
and the ability to negate such as
links:
!ntp::
/etc/inet/ntp.conf - /etc/inet/ntp.client
I was wondering how I would accomplish something like it in Puppet.
Puppet really works very differently from cfengine and you have to think
in different ways. CFEngine allows you to define arbitary classes
(which means something different in puppet ;) ) based on any logical
combination of already defined classes and to associate actions with
classes. Puppet works with dependencies and it doesn't do groups (which
in CFengine are actually just classes which are true if the hostname
matches one of the strings in the given list).
For the simple example you give above, you'd define an ntp class (puppet
style) which created the link (and any other ntp configuration you
require) and then in the node declaration for that host you would
include the ntp class. You can still think of the ntp class as being a
group, if you like, but you declare in the node which groups a host is
in.
There are a number of ways to implement group behaviour, though. One is
to use case statements
http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#case-statement
The problem is where to place such a case statement within your
manifests; if it is included outside of a node declaration then it
doesn't have any access to the variables and classes memberships
declared in the node config. But if you put it in the node declaration,
you have to make sure it is included in every node declaration
(cumbersome, error prone and ever so slightly defeating the point).
Another way is to use an External Node service.
http://reductivelabs.com/trac/puppet/wiki/ExternalNodes
This lets you store your host data in, for example, a Directory service
like LDAP. Most such services will let you define groups where you can
specify a list of nodes and when you then interogate the Directory
service for details of an individual host (which is how Puppet needs the
data), it'll give you back the group memberships as part of that. So
you need to map groups in your directory onto classes in your Puppet
config.
This isn't exactly a lightweight solution either and is a lot of work if
you didn't need this feature for anything else.
There are other ways to do it, but they do mean working against puppet's
design and it can be painful.
FWIW, I really don't like the way nodes work in puppet and have been
trying to work round that every since I started using it.
--
Bruce
What would Edward Woodward do?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Patching Solaris with Puppet?
Mark, On Feb 2, 3:39 pm, Mark Plaksin ha...@usg.edu wrote: The pup...@sun case study recently posted to the RL blog [1] says they use Puppet to make security patching easier. Anybody know how they do that? Is there some magic in Puppet which makes patching Solaris easier? since I'm the one who said it I think I should answer :) The way that puppet makes it easier for us to patch is that when there is a security issue, we can usually start by deploying a mitigation, e.g. disable the service, or update the ipfilter config to block the service in question, or some other kind of action. Then we can schedule normal downtime and patch in an orderly fashion, instead of scrambling to patch 650 systems at once. We have also used a custom facts to gather info from all systems, and report back if they are vulnerable to a specific issue or not. Let me know if you have more questions... cheers, /Martin -- 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] Combining our experience into a larger, common module repo
Hi List! So I was talking with several folks on IRC this morning, and we came up with an idea. One of the strengths of Puppet is it has a very large community with tons of systems administration experience.This is huge. I'd like to unite that experience more closely, so that this power is immediately available and obvious to new and existing users. Currently we have a large collection of repos, some containing one module, some containing many, but they are fragmented: http://www.reductivelabs.com/trac/puppet/wiki/PuppetModules What I'd like to do initially is start getting these together in one giant curated repo, hosted on our github space, that makes it easier for all Puppet users to contribute to. Now this immediately starts the question of what other things people will like to make this easier. Package management capability. Metadata. Standards. New language features. Whoa, horsie! I'm thinking let's avoid going there right now, and see what we can accomplish for the current installed versions of Puppet, and in the process of doing this, we'll see what we actually need and have a framework in which to test them.I'm sure this will point to all sorts of questions about how cross-OS modules should be, what metadata is required, what the interoperability challenges may be, etc. Though, even short term, it will provide a really good reference full of examples for new and existing Puppet users to go to.And by sharing, we can make sure the modules become the best they can possibly be. I think we need to start small, and identify some basic concepts we need a collection of namespaced modules to have, in order to work together well. If this takes off, we may want to create a seperate list for development of the common modules -- TBD -- but we could use puppet-users for now. This way, by having all the repos in one place, and one common place to talk about them, it would be easier for everyone to contribute -- whether or not they had a github account -- and we can commonly work on codifying our own best practices and tools. Existing folks are welcome to contain their own repos, though hopefully we'll see a trend of more folks just creating github forks of the main branch set, from which we can respond to merge requests. Thoughts? --Michael -- 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] Forced service start/stop/restart using puppetrun?
Peter Meier wrote: # puppetrun --host abcd --host efgh --tag restart_my_service It's easy to create a class to restart services but it then get applied anytime i use puppetrun. puppet's idea is to ensure that your system is in a certain state, and if not do anything to achieve this state. However just executing commands is not really the idea. If you are looking for something to executes commands on demand on certain systems have a look at func [1] or mcollective [2]. cheers pete [1] https://fedorahosted.org/func/ [2] http://code.google.com/p/mcollective/ Yeah, as I was at least partly responsible for Func, I'll say in general I think you want to *avoid* doing that, if possible, and if there's a use case where that is required, I want it to be doable through puppet end-to-end in a puppety way if at all possible. That's not all doable now, true, but I want to look into it. Other than starting/stopping services, what would you be looking for? And what are the reasons for wanting to start/restart the services in those cases? As Pete wrote, in the current system, you'd have the service subscribe to the configuration file -- meaning that if the configuration file changes, Puppet is smart enough to know it should restart the service.This is the way to go, as you are describing your system in language, and have a written model of the way it works. Doing things outside that model doesn't break the model, but it loses the benefits and power of it a little. I think that gets a little tricky when you're dealing with events that span systems, so more data about what kinds of things you are trying to do like this would be extremely valuable. Let me know! --Michael -- 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] Running multiple instances of a puppetmaster on one server
Hey, I've been trying to figure out how to run multiple puppetmasterd instances on one machine - perhaps on separate ports. Can anyone advise me if this is a bad idea, or if not, how to go about doing this? I'm trying to maintain puppet on an existing set of machines while refactoring the same manifests on a new set of machines, so ideally I'd like entirely separate puppet manifests, modules, and files. Thanks for any help! -- 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] commercial support
Is there an option to purchase support for Puppet ? -ALF -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cannot seem to turn off the CA
On Tue, Feb 2, 2010 at 8:03 AM, Scott Smith sc...@ohlol.net wrote: On 2/2/10 7:04 AM, Nigel Kersten wrote: How are you running puppet? Are you using Passenger? I found ca = false didn't work in the .conf file with Passenger, and I instead had to add --no-ca to the args. Weird, what version of Passenger are you using? I've got 2.2.5 and don't have to do that. I had to do it with the earlier versions at least, 2.2.1 I think? I'll double check again today. I thought ca = false was working until I actually verified that it wasn't operating as a CA. This is with puppet 0.24.8 btw. -scott -- 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. -- nigel -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Making the new users experience easier
Just one more email and I'll let you go for a few hours :) One of the things I like to see in apps is that they are immediately intuitive and easy to use for new users. I think Puppet is really good here, but there's opportunity to make everything better. We want everyone to love Puppet from their first few minutes using it, all the way through to datacenter nirvana. With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? One of the ideas I had from cobbler was cobbler check which was a tool you could run to identify some of these problems. I'm not sure if it makes sense for Puppet, but it may do some things like say you appear to have DNS problems resolving this, you should try... and so forth. What else might there be? Obviously one of the things I'm going to be looking for are what questions keep coming up on IRC ... Are there mainly questions around puppetca? Should scaling be easier to set up out of the box and in the default configuration (right after RPM or deb install)? Are there easy additions or changes to the software we can make to make error messages clearer and self-resolving? Obvious things in the documentation/manpages we can clean up?(Aside: I think Puppet Dashboard has a LOT of opportunity to help with this too, so watch this space!) I'm going to be looking into this myself, but I'd love to hear from you. Any and all data is welcome. (If you'd prefer to reply personally or talk over IRC, that's fine too.) Thanks! --Michael -- 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] Running multiple instances of a puppetmaster on one server
I've been trying to figure out how to run multiple puppetmasterd instances on one machine - perhaps on separate ports. Can anyone advise me if this is a bad idea, or if not, how to go about doing this? I'm trying to maintain puppet on an existing set of machines while refactoring the same manifests on a new set of machines, so ideally I'd like entirely separate puppet manifests, modules, and files. as long as they listen on different ports there won't be any problem with it. cheers pete -- 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] commercial support
Zitat von Angelo Fazzina 96ssimp...@gmail.com: Is there an option to purchase support for Puppet ? yeah, ask reductivelabs. cheers pete -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cannot seem to turn off the CA
On 2/2/10 9:06 AM, Nigel Kersten wrote: I thought ca = false was working until I actually verified that it wasn't operating as a CA. This is with puppet 0.24.8 btw. Ahhh, I'm using 0.25.x -scott -- 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] commercial support
Angelo Fazzina wrote: Is there an option to purchase support for Puppet ? -ALF Absolutely!We also provide training and consulting around Puppet. Start here -- http://reductivelabs.com/services/ -- fill out the contact form and we'll get back to you very quickly. Thanks! --Michael -- 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] commercial support
On Feb 2, 2010, at 8:24 AM, Angelo Fazzina wrote: Is there an option to purchase support for Puppet ? There definitely is - Reductive Labs (the company I founded when I started the Puppet project) provides support, training, and other professional services around Puppet. One of our favorite services is custom development -- customers have paid for Puppet's environment support, the queueing support, and much more. You can always email me directly for questions, or you can email our VP of sales, Scott Campbell, at sc...@reductivelabs.com, with questions. We're happy to provide customer references. -- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein - Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 -- 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: Running multiple instances of a puppetmaster on one server
Basically, you set up a web proxy with your web server of choice to handle SSL connections, and then you can start as many puppetmasterd instances as you need. See one of the following: http://reductivelabs.com/trac/puppet/wiki/UsingMongrel http://reductivelabs.com/trac/puppet/wiki/UsingMongrelNginx http://reductivelabs.com/trac/puppet/wiki/UsingMongrelPound Also, see http://reductivelabs.com/trac/puppet/wiki/PuppetScalability for info on splitting off the fileserver. You probably won't need to do this if you are running a proxy with multiple puppetmaster instances though. -- 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] Making the new users experience easier
With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? * ssl * ssl * dns * ssl certificates * language details * the whole puppet-doesn't-execute-things-philosophy * getting an idea where to start * did I mention ssl? One of the ideas I had from cobbler was cobbler check which was a tool you could run to identify some of these problems. I'm not sure if it makes sense for Puppet, but it may do some things like say you appear to have DNS problems resolving this, you should try... and so forth. something like that would be a great idea. especially for things like dns and ssl certs. It could provide errors if something is obvious wrong and warnings if something is not aligned to the conventions but could work if you set certain config options, like the master cert doesn't contain puppet.$domain and so on. What else might there be? James already did a great job in providing first steps examples, like the recent write your own fact. However something that people like is to have something to start with, like a first distribute your ssh-auth key. And then what maybe might also be nice is to provide standalone-manifests (which require no master) which would configure the master in a certain manner. Like the manifests to configure puppetmaster as a rack application. So something like master_webrick.pp, master_mongrel_nginx.pp, master_mongrel_passenger.pp and so on. These would configure the master in a standard way that works. If still people like to tweak (destroy?) the config, they can do it, but most people could have a safe environment with that to start. It would also be nice to have something like: puppet_master_standalone.pp, which would configure the master for a desktop try and test setup, where a /etc/hosts entry for puppet would be created and so on. Simply that people don't have to crawl through documentation if they missed something during setup. Oh and for sure the obvious ::destroy classes to remove things again. Actually the setup of puppet is more or less already quite straightforward, however there are some corner points which shouldn't be missed. People however still often miss them and as they are required to get puppet successfully running, they fail and might get frustrated. In combination with puppetcheck this might help to nail down the remaining bootstraping problems. cheers pete -- 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] Running multiple instances of a puppetmaster on one server
Thomas wrote: Hey, I've been trying to figure out how to run multiple puppetmasterd instances on one machine - perhaps on separate ports. Can anyone Why bother fussing with ports when you can just use another interface? -scott -- 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: Declarative style and processes
On Feb 2, 10:38 am, Michael DeHaan mich...@reductivelabs.com wrote: What do you think? Please forgive me, but I am apprehensive about some of those ideas. One of the reasons Puppet is great is that it is organized around a compact goal and consistent operating and design principles. Its goal is to achieve and maintain system state, and among its key operating principles is Puppet chooses how to do it. I am concerned that Puppet will become less reliable, harder to use, and harder to develop and maintain if it is extended in directions that are inconsistent with its core goals, operating principles, and design principles. It seems a natural extension to enable Puppet to manage the collective state of an entire network, which I hope you find a fair characterization of your class (A). I think there are some significant practical problems with doing that, however, large among them that of assessing the collective state of a whole network in the first place. The framework extensions needed to support this extension could easily dwarf all the rest of Puppet. Looking at it another way, a generic solution to this class of problems would essentially be a business process orchestration framework for system configuration. Google business process orchestration if you don't appreciate the size and complexity of systems that do that. As for your class (B), to the extent Puppet doesn't already support it via Exec, just no. At the risk of being pedantic, asking to Be able to run tasks [...] of *any* kind via Puppet already runs counter to the Puppet paradigm. The Exec type notwithstanding, Puppet is not a task runner. I don't think Puppet is the right tool for that job, and I would prefer that its operating principles not be compromised to make it the right tool. With all that said, if you think puppetd provides a good foundation for some of these things then nothing prevents you from building on it. Puppet is fairly easy to extend with new resource types, and nothing prevents you from hooking puppetd up to a process orchestration suite. I am sure you would have an interested audience for such work. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Cannot seem to turn off the CA
So I have 0.25.3 I found this in the code puppet/ssl/certificate_authority.rb class Puppet::SSL::CertificateAuthority def self.ca? return false unless Puppet[:ca] return false unless Puppet[:name] == puppetmasterd return true end end Basically I read this as, if this class is used inside of puppetmasterd, then turn on the certificate authority. Always. Anyone know if that is intended? On Feb 2, 9:15 am, Scott Smith sc...@ohlol.net wrote: On 2/2/10 9:06 AM, Nigel Kersten wrote: I thought ca = false was working until I actually verified that it wasn't operating as a CA. This is with puppet 0.24.8 btw. Ahhh, I'm using 0.25.x -scott -- 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: Patching Solaris with Puppet?
+-- | On 2010-02-02 08:22:40, Martin Englund wrote: | | We have also used a custom facts to gather info from all systems, and | report back if they are vulnerable to a specific issue or not. I wouldn't mind seeing the facts. Cheers. -- bda cyberpunk is dead. long live cyberpunk. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Cannot seem to turn off the CA
Hi, We have several puppetmasters running with ca= false and passenger. They are currently 0.25.3 but were at some point 0.24.8. Basically, once you have setup your ca, in a node intended to be puppetmaster, run the client FIRST with ca_server pointing to your ca. The client generates the certificates and get the ca ceertificate. Then you can run the puppetmaster with ca = false. Our non-ca puppetmasters' puppet.conf looks like this: # file managed by puppet [main] logdir = /var/log/puppet vardir = /var/lib/puppet ssldir = /var/lib/puppet/ssl rundir = /var/run/puppet factpath = $vardir/lib/facter pluginsync = true manifest = /etc/puppet/manifests/site.pp modulepath = /etc/puppet/modules templatedir = /etc/puppet/templates [puppetmasterd] # CA ca = false ca_server = puppeteer.domain.com syslogfacility = info # Enable Foreman reports reports=log, foreman # for Passenger ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY # Use Foreman node_terminus=exec external_nodes=/etc/puppet/scripts/node.rb [puppetd] server = puppeteer.domain.com report = true Hope this helps. Cheers, Atha On Feb 2, 2010, at 17:14 , nicholas wrote: So I have 0.25.3 I found this in the code puppet/ssl/certificate_authority.rb class Puppet::SSL::CertificateAuthority def self.ca? return false unless Puppet[:ca] return false unless Puppet[:name] == puppetmasterd return true end end Basically I read this as, if this class is used inside of puppetmasterd, then turn on the certificate authority. Always. Anyone know if that is intended? On Feb 2, 9:15 am, Scott Smith sc...@ohlol.net wrote: On 2/2/10 9:06 AM, Nigel Kersten wrote: I thought ca = false was working until I actually verified that it wasn't operating as a CA. This is with puppet 0.24.8 btw. Ahhh, I'm using 0.25.x -scott -- 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.
Re: [Puppet Users] Making the new users experience easier
Peter Meier wrote: With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? * ssl * ssl * dns * ssl certificates Definitely understand this whole confusion point. Bad DNS experiences equated for a lot of the confusion with previous projects I've worked on, and also in trying Puppet.I think there are probably ways to make this more clearer to the user and more troubleshootable, though if anyone has suggestions on that, please pass them along. * language details * the whole puppet-doesn't-execute-things-philosophy * getting an idea where to start Absolutely.This is one of the big things I want to address, making sure we make that argument very obviously and that there's a clear learning tree to total mastery that doesn't drown you in information initially or give you too many rabbit holes to chase down. Part of that start is a simple writeup outlining our approach and why we think it is the way to go. I think there's a lot of good work in cleaning up the docs too, and you'll see alot more of that going forward. Part of the where to start can also be influenced by having a more common library of examples, and yes, more tips about migrating to Puppet on the site. Thanks! * did I mention ssl? I think you did! One of the ideas I had from cobbler was cobbler check which was a tool you could run to identify some of these problems. I'm not sure if it makes sense for Puppet, but it may do some things like say you appear to have DNS problems resolving this, you should try... and so forth. something like that would be a great idea. especially for things like dns and ssl certs. It could provide errors if something is obvious wrong and warnings if something is not aligned to the conventions but could work if you set certain config options, like the master cert doesn't contain puppet.$domain and so on. What else might there be? James already did a great job in providing first steps examples, like the recent write your own fact. However something that people like is to have something to start with, like a first distribute your ssh-auth key. And then what maybe might also be nice is to provide standalone-manifests (which require no master) which would configure the master in a certain manner. Like the manifests to configure puppetmaster as a rack application. One of the things I definitely want to do is make the scaled scenarios (ex: rack, passenger, etc) work better out of the box. I really like this idea. Presumably we'd want to start with just the most popular cases and tend to suggest which ones to try -- I don't think all users of a puppetmaster want to be an expert in Ruby webserver internals and how to choose the right one. So something like master_webrick.pp, master_mongrel_nginx.pp, master_mongrel_passenger.pp and so on. These would configure the master in a standard way that works. If still people like to tweak (destroy?) the config, they can do it, but most people could have a safe environment with that to start. It would also be nice to have something like: puppet_master_standalone.pp, which would configure the master for a desktop try and test setup, where a /etc/hosts entry for puppet would be created and so on. Simply that people don't have to crawl through documentation if they missed something during setup. Oh and for sure the obvious ::destroy classes to remove things again. Actually the setup of puppet is more or less already quite straightforward, however there are some corner points which shouldn't be missed. People however still often miss them and as they are required to get puppet successfully running, they fail and might get frustrated. In combination with puppetcheck this might help to nail down the remaining bootstraping problems. Right, exactly the point of all of this -- thanks very much for the feedback. If anyone else has any such pointers, please share. There's obviously a fair amount in the archives and so forth about this as well, but I'm very open to ideas on how to make it all even smoother (like the web server setup examples). cheers pete Yep. Thanks very much! --Michael -- 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] Combining our experience into a larger, common module repo
I'd love to see this get off the ground. There have been a couple of attempts at it - and you can see some background at: +1. I'd love to see better platform support for the modules that we have. J. -- Julian Simpson Software Build and Deployment http://www.build-doctor.com http://twitter.com/builddoctor -- 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] Making the new users experience easier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/02/10 10:03 AM, Peter Meier wrote: * did I mention ssl? I think you did! +1 SSL although I wonder how this could be implemented? Time/NTP. Regards James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS2ixryFa/lDkFHAyAQI4Uwf8C661+5tH5/NcTSrhmQidNEI0OWsCpVCI Dv4yRGThMMd/xfNCMVIPR/BO6Jx1rgkt3AHdFFXyyYgR9FMLQUu0E1KnjN9YVHVi 1LdNs4VJVPhIMfa0anGteDdDfdbEw3Cx2a7MDymplVTeNTOs9ct0QBKKH3lKjbml 0orEza7fk7NuAwosVaXe5w5aDyYrQD8Hd+d+BdEkdNeyLfJeGpUDL4+7ai7c4nGB cuZXeTdyLPtNi11Ww2Q65t0bkI9VSeIhRIeSRo0faZKuwZSFKGvFcPGgCmQtYBa9 4t6zU09DEerKBqFqkn84X55IqdNc0VeScSUezcJA01ILyMAPFuHMcw== =L8j3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Declarative style and processes
I think some really interesting things could be done around a much more
flexible require = infrastructure that would allow various things such as
global requires, requires that trigger tests in some fashion on other hosts.
I could conceive of some kind of functionality whereby test{} exists in
modules and provides a method by which you can check some functionality is
working. You would then be able to trigger a test{} on another host and get
back true/false with which puppet could decide if it should skip some action
on the original node. I guess there are many more flexible and undoubtedly
better ways to do this but it would seem to be closest to the puppet way
that would allow you to test and rely on other functionality being in place.
On Tue, Feb 2, 2010 at 11:38 AM, Michael DeHaan
mich...@reductivelabs.comwrote:
Oliver Schad wrote:
Hi,
I know puppet allow me to describe the target state of my system and
changes the state automatically to that description.
In some situations you want to describe a process how things should go
maybe dependent on other systems where the order is important and maybe you
need some checks after doing a step and maybe has to wait for other systems.
Think about a process like a network wide transition, where one system do
something, wait for some events from other systems and continues the process
or decide something on that events - same on other systems.
What I want is to program network wide jobs (not one job that runs on the
all hosts - you see the difference?).
What I like in puppet is, that puppet uses its own communication channel
besides ssh. Tools like capistrano don't do that, so you need SSH access
(that means you need in many situations at least a SSH gateway - I don't
like it cause of an extra service on an extra host open to the internet).
And I would of course use my host definitions from puppet (what I could
achive, if I use something like LDAP to store my host definitions and use it
side by side with puppet instead through puppet).
Is there a tool outside where I can use puppet descriptions to program
such jobs? Or is there a tool outside you know, that allows me to program
network wide jobs without puppet where I could built in the usage of my LDAP
tree?
Hi Oliver,
There have been various things like this, though I think what I really
would like to do is understand what the types of use cases are for these
various things, so we can figure out how to teach puppet to do them best in
a way that fits in well with puppet.
For instance, this is pretty much why I created Func a while back -- for
the one-off tasks that weren't Puppety -- though Func has some major
limitations (namely, a very weak module library, so it is mainly used to
just run shell commands and replace SSH loops). MCollective is doing
similar things as Func, though with a message bus. (Aside: having Puppet
optionally grok message buses is something we should probably look into).
There seems to be two different classes of things we'd like to do:
(A) Have the orders for a recipe wait until a condition on another host
meets some certain state... for example, installation of a service requires
that first a database setup is fulfilled on another host.
(B) Be able to run tasks that are not neccessarily declarative, such as
power off these machines now / network go into emergency off mode now /
etc. These kinds of things aren't exactly what you would store in the
recipe, but puppetd is well suited to enable these sort of tasks.
Do you have other specific examples?
I think building something like this into the core makes good sense, so
that you don't have to set up yet another program.
Can you share more examples of what you'd want to do in these kind of cases
so we can talk about it? Right now I'm familiar with the cases of shut
this off, or perhaps creating a build system out of the tool, though I'd
like to know more.
I also see the case of this can't go forward until this other remote
condition is true as being something we'll want to make a lot easier... I
think we understand that one better and can do that fairly easily ...
possible use cases include load balancer setup, database setup, etc.
What do you think?
--Michael
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
Re: [Puppet Users] Declarative style and processes
Ashley Penney wrote:
I think some really interesting things could be done around a much
more flexible require = infrastructure that would allow various
things such as global requires, requires that trigger tests in some
fashion on other hosts. I could conceive of some kind of
functionality whereby test{} exists in modules and provides a method
by which you can check some functionality is working. You would then
be able to trigger a test{} on another host and get back true/false
with which puppet could decide if it should skip some action on the
original node. I guess there are many more flexible and undoubtedly
better ways to do this but it would seem to be closest to the puppet
way that would allow you to test and rely on other functionality being
in place.
I like the idea of being able to support arbitrary tests for
redlight-greenlight type status (could be very nice for dashboard,
too... lightweight monitoring!).
I'm not entirely sure yet whether that requires requires [sic] though,
or tests should cause automated behavior.
Testing could just be a separately triggered system.
Teyo has pointed out before there's something a bit odd about using
Puppet to test Puppet, but in this case, we're using puppet's existing
(and solved) secure communications system to extend it into monitoring
territory.
I like this.
If you've got more info on what tests might trigger, I'd be interested
in hearing that.
--
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: Declarative style and processes
jcbollinger wrote: On Feb 2, 10:38 am, Michael DeHaan mich...@reductivelabs.com wrote: What do you think? Please forgive me, but I am apprehensive about some of those ideas. One of the reasons Puppet is great is that it is organized around a compact goal and consistent operating and design principles. Its goal is to achieve and maintain system state, and among its key operating principles is Puppet chooses how to do it. I am concerned that Puppet will become less reliable, harder to use, and harder to develop and maintain if it is extended in directions that are inconsistent with its core goals, operating principles, and design principles. *nod* Not proposing that. I'm just curious as to what tasks fit outside the model, per se. Those things are kind of the outliers, the things that a declarative system can't do. Yes, you're right, the system is good because it's a system, and we don't want to encourage Puppet to ever reduce things to being an SSH loop replacement. However, occasionally... rarely... you want that. BIOS upgrades, system reboots, power management, kicking off a 'koan --replace-self' on a node (if you speak Cobbler), etc. These seem like simple things to do. It seems a natural extension to enable Puppet to manage the collective state of an entire network, which I hope you find a fair characterization of your class (A). I think there are some significant practical problems with doing that, however, large among them that of assessing the collective state of a whole network in the first place. The framework extensions needed to support this extension could easily dwarf all the rest of Puppet. Looking at it another way, a generic solution to this class of problems would essentially be a business process orchestration framework for system configuration. Google business process orchestration if you don't appreciate the size and complexity of systems that do that. Different problem :) Next thing you know we'll need a rules engine and an artificial intelligence. Yeah, we don't want to go there. But multinode deployment? Yes, we want to go there. Keeping it simple is important. As for your class (B), to the extent Puppet doesn't already support it via Exec, just no. At the risk of being pedantic, asking to Be able to run tasks [...] of *any* kind via Puppet already runs counter to the Puppet paradigm. The Exec type notwithstanding, Puppet is not a task runner. I don't think Puppet is the right tool for that job, and I would prefer that its operating principles not be compromised to make it the right tool. Puppet is a tool, yes, but also think of the greater potential ecosystem. puppetd. puppetca.These are installed and in-place. With dashboard, we will have a nice console. I think there is room to do more. If you're worried about bloatware, I assure you, it's not in my DNA. It's not in Reductive's DNA... puppet and it's model will be the core around what we'll do. Always. With all that said, if you think puppetd provides a good foundation for some of these things then nothing prevents you from building on it. Puppet is fairly easy to extend with new resource types, and nothing prevents you from hooking puppetd up to a process orchestration suite. I am sure you would have an interested audience for such work. Yeah, part of the reason of discussing it here. If it proves *not* interesting, we're less likely to go down those roads. Which makes it interesting to hear what orchestration problems, if any, people are having trying to do things with the existing model today. Push actions aren't neccessarily the solution to those -- that's a seperate problem -- but probably one we also may want to touch upon. Multi-machine deployments are closer to the orchestration end, and I think there are simple logical extensions to teach Puppet about those, without changing the way the model works -- and we definitely like the way the model works :) --Michael -- 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] Making the new users experience easier
On Tue, 02 Feb 2010 12:08:29 -0500, Michael DeHaan mich...@reductivelabs.com wrote: With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? First and foremost on my list is the ability to trigger puppet runs manually. In a lot of environments, you don't want puppet updating things automatically in the middle of the day. In our company (and many like it), there are strict change management rules dictating when things can be run. It'd be nice if puppet didn't assume that I wanted it to run immediately upon startup. As is, we've created a schedule called never, and we use --ignore-schedules to force updates. I've found the puppetrun utility to be very lacking, in many ways, and have resorted to my own scripts to trigger runs. This script runs using ssh to hit servers, which is unfortunately not ideal right now since it operates in a serial fashion, and it creates a chicken/egg problem (puppet is used to deploy the user/sudoers/ssh key...). The issues I have with puppetrun are: 1) LDAP support is required for triggering individual servers. Why? 2) Doesn't pass all options on to the remote server (--noop is ignored, for instance) 3) Probably others, but I haven't messed with it in a while so I've forgotten them If either #1 or #2 has been resolved lately, my apologies and I'll plan to upgrade soon :) Another issue I've found is that many of the directories in /var/lib/puppet aren't created until puppetd is started in daemon mode at least once, so when we're building new systems we have to start the service and then immediately stop it, just so we can run puppetd manually. Again, if there's a work around for that, I'd appreciate hearing it. Those have been my primary stumbling blocks, if I think of any others I'll let you know. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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] Making the new users experience easier
On Tue, Feb 2, 2010 at 9:02 PM, Ohad Levy ohadl...@gmail.com wrote: On Wed, Feb 3, 2010 at 9:27 AM, James Cammarata j...@sngx.net wrote: I've found the puppetrun utility to be very lacking, in many ways, and have resorted to my own scripts to trigger runs. This script runs using ssh to hit servers, which is unfortunately not ideal right now since it operates in a serial fashion, and it creates a chicken/egg problem (puppet is used to deploy the user/sudoers/ssh key...). You might want to have a look at puppetlist/puppetrun in the ext directory, it could provide some of the functionality you are looking for. As an aside -- I see puppetd and /usr/sbin/puppet share many common options, but not quite all of them. Possibly these could be unified. Some evolution of puppetrun should be in the main distribution, IMHO, as part of puppetmaster.We've talked a little bit about staged (timed) rollouts of new manifests and so forth, and environments, and I can see that playing a role. This is another conversation we should have too -- how to roll all the scripts (in ext, or in the community on git somewhere, like the ones you have created) into the main core, versus having folks have to learn about it the hard way :) --Michael -- 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] Making the new users experience easier
On 2/2/10 7:57 PM, James Turnbull wrote: The plan is to unify all the binaries (in fact I think the code is written and is planned for Rowlf) in the style of git so, $ puppet ca $ puppet master $ puppet client $ puppet doc etc, etc (So puppt check fits). Obviously existing binaries will continue for a while but ultimately be deprecated. How about symlinks? puppetd - puppet puppetdoc - puppet etc..? -scott -- 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] Making the new users experience easier
On Tue, 02 Feb 2010 20:14:50 -0800, Scott Smith sc...@ohlol.net wrote: On 2/2/10 7:57 PM, James Turnbull wrote: The plan is to unify all the binaries (in fact I think the code is written and is planned for Rowlf) in the style of git so, $ puppet ca $ puppet master $ puppet client $ puppet doc etc, etc (So puppt check fits). Obviously existing binaries will continue for a while but ultimately be deprecated. How about symlinks? puppetd - puppet puppetdoc - puppet etc..? -scott Symlinks wouldn't work, I'd just make them shell scripts. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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] Making the new users experience easier
On 2/2/10 8:18 PM, James Cammarata wrote: Symlinks wouldn't work, I'd just make them shell scripts. Wait, what? Checking $0 and loading client, server or doc code would work just fine. :) -scott -- 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] Making the new users experience easier
On 3 February 2010 15:14, Scott Smith sc...@ohlol.net wrote: On 2/2/10 7:57 PM, James Turnbull wrote: The plan is to unify all the binaries (in fact I think the code is written and is planned for Rowlf) in the style of git so, $ puppet ca $ puppet master $ puppet client $ puppet doc etc, etc (So puppt check fits). Obviously existing binaries will continue for a while but ultimately be deprecated. How about symlinks? puppetd - puppet puppetdoc - puppet etc..? Sure - doesn't matter to me overly much how it's done. Regards James Turnbull -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- 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.
