Re: [Puppet Users] Crontab overwritten by Puppet
On Tue, Jul 10, 2012 at 10:41 PM, Kmbu wrote: > Hi, > > Thanks for supporting. We've been running this environment of around 1000 > servers for at least 5 years and have never seen a crontab suddenly > disappear before. We've only had Puppet in place for a month or so. > > Regards, Unfortunately, I've seen the same issue occur. I posted to the list about it a while back and had some others say they'd seen similiar. I've only seen this happen on Solaris so far but seeing it happen once was enough for me to pull the plug on using puppet to manage users crontab files on all our boxes, solaris and rhel. On RHEL I've worked around the issue by dropping crontab files in /etc/cron.d/ but on solaris I have no viable work-around at the moment. Others have mentioned that I should just manage the whole crontab file in puppet... but this isn't really an option for me at the moment. On solaris at least the issue seemed to be related to facter hanging (due to the picld daemon hanging). Not that this really solves your problem but if your on a *nix that supports it you might want to look at converting to dropping cron files in /etc/cron.d/ or similar. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet-dashboard with SELinux enforced - anyone frpm PuppetLab care to comment?
On Tue, May 29, 2012 at 1:39 PM, Sans wrote: > > Thanks nseagoon! But that didn't help. I already did that. And I'm still > trying to understand the audit log. > Does any one have any other suggestion(s) for me? Cheers!! It may be useful for you to install the 'setroubleshoot' package (that's what it's called on RHEL anyway). This allows you to run commands like this: audit2why -a /var/log/messages audit2allow -a /var/log/messages or audit2why -a /var/log/audit/audit.log audit2allow -a /var/log/audit/audit.log to see what selinux settings you may have to change to allow Dashboard to run. Likely, you'll have to create a custom selinux policy to allow it to run properly. I found this page helpful on creating custom policies: http://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index.html Good luck! Romeo > > > > On Monday, May 28, 2012 3:48:03 AM UTC+1, nseagoon wrote: >> >> If you're running puppet as a daemon with selinux in enforcing mode, I >> think you may need to run: >> >> setsebool puppetmaster_use_db on >> >> In the current state and presuming that the audit daemon is running, >> /var/log/audit/audit.log should be reporting which aspect of selinux is >> preventing the access request. >> >> On 27 May 2012 19:52, Sans wrote: >>> >>> Thanks Brian! >>> I'm still trying to find out how to make it work, with no such joy so >>> far. Anyone from PuppetLab care to comment? >>> >>> Cheers!! >>> >>> >>> On Monday, May 14, 2012 1:08:38 PM UTC+1, Brian Gupta wrote: I've run into permission errors like this if apparmor is enabled, and not configured for the app I am trying to run. http://en.wikipedia.org/wiki/AppArmor I'm guessing you need to tell selinux that /usr/share/puppet-dashboard/* is a valid path. (Never used selinux, but my understanding is that apparmor and selinux have similarities.) -Brian On Sun, May 13, 2012 at 9:07 PM, Sans wrote: > > Dear all, > > Can anyone please tell me why Ruby on Rails application is not > starting, when SELinux is on. This is the errors reporting on the browser: > > >> The application has exited during startup (i.e. during the evaluation >> of config/environment.rb). The error message can be found below. To solve >> this problem, please follow any instructions in the error message. >> >> Error message: >> Rails Error: Unable to access log file. Please ensure that >> /usr/share/puppet-dashboard/log/production.log exists and is chmod 0666. >> The >> log level has been raised to WARN and the output directed to STDERR until >> the problem is fixed. Database isn't the current migration version: >> expected >> 20120112195235, got 0 You must either run 'rake db:migrate' or set >> environmental variable NO_MIGRATION_CHECK > > > > Any idea what am I doing wrong? Cheers!! > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/qXoLkbcvsy8J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Users" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/puppet-users/-/pSNLov7u4-4J. >>> To post to this group, send email to puppet-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/uoo-ZBRn-v8J. > > 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. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Sites. Your thoughts?
On Thu, May 10, 2012 at 6:44 AM, Daniel Sauble wrote: > Hey all, > > I've been designing a new feature for Puppet, and wanted to get some > kick-back from the community to see if you think this is needed or not. The > feature is called Puppet Sites, and meets some specific goals by means of a > few tasks. > > Securely add nodes to your deployment without manually signing certificates > on the CA... > > ...so that you can have the advantages of autosigning without its security > problems. > > Get a list of all the nodes in your deployment... > > ...so that a single command can give you what previously you had to trawl > multiple services (ENCs, CAs, etc...) on each Puppet master in your > deployment to retrieve. > > Store connection information for Puppet services in a central location > (accessible from manifests, puppet.conf, and defaults.rb)... > > ...so that you don't have to manage puppet.conf files on each node in your > population > ...so that agent/master/CA configuration stays consistent across your > deployment > ...so that you can update your config and fetch a new catalog in a single > operation. > > Thanks in advance for the feedback! > - Daniel Hi Daniel, thanks for dropping a note to get some feedback on this. While these features sound very nice I personally would find it interesting and might have more to add if you went into a bit of detail about how you plan to implement these features. Thanks, -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch
On Tue, May 1, 2012 at 10:35 AM, Russell Van Tassell wrote: > On Tue, May 1, 2012 at 12:45 PM, Romeo Theriault > wrote: >> >> Unfortunately, solaris >> doesn't have a cron.d directory where we can drop crontab files >> either. > > > Are you talking about /var/spool/cron/crontab on Solaris? (think that's the > right path) > > It won't reload them without being kicked. But, you can play tricks with it > by dropping the file there, then reload it by invoking "crontab" and feeding > it the new file. You might have to massage it to get things to work > properly, but it should be possible (ie. I've done it this way, manually, in > a previous life). I was referring to something like the /etc/cron.d/ directory on linux where you can drop in new files that have specific entries. Are you suggesting that you can drop in new "files" into the /var/spool/cron/crontabs dir on solaris and it will pick them up after being reloaded? How would it know which user to run this crontab as if it's not the actual users crontab file itself? See, I don't want to manage the whole file. I'd like to just be able to manage individual entries by placing new files into the dir. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch
On Tue, May 1, 2012 at 03:14, Kent wrote: > I don't think it's issue #5752, I opened that issue and provided a > patch to resolve it. > When I build new versions of Puppet for my Solaris hosts I apply that > patch each time via my build script and I'm still having some hosts > where the crontab gets "eaten" and it always seems to correspond with > 'prtdiag' issues or timeouts. > > Facter has a timeout built in for prtdiag and then does a kill routine > if it needs to clean up. > I wonder if it's being overly agressive and accidentally killing some > or all of the Puppet run in turn causing this issue? I agree, that I think this is probably what is happening. I've since stopped using puppet to manage our solaris crontab files since we can't currently fully puppetize our crontabs. Unfortunately, solaris doesn't have a cron.d directory where we can drop crontab files either. Romeo > On Mar 13, 5:31 pm, Greg wrote: >> Have seen similar. Quite often when prtdiag fails to complete, I've >> found that restarting svc:/system/picl:default returns everything back >> to normal... >> >> Hopefully all your root cron jobs are in Puppet and will be rebuilt on >> the next run... >> >> Greg >> >> On Mar 14, 9:26 am, John Warburton wrote: >> >> >> >> >> >> >> >> > On 14 March 2012 09:16, Romeo Theriault wrote: >> >> > > Here are the logs the solaris 10 box returns after it's crontab gets >> > > destroyed: >> >> > > ERR Puppet Could not prefetch cron provider 'crontab': Could not >> > > read >> > > crontab for root: No child processes >> > > NOTICE /Stage[main]/Puppet/Cron[puppet]/ensure created >> > > NOTICE Puppet Finished catalog run in 2.52 seconds >> >> > > After this the only thing that exists in the crontab is the entry we >> > > have puppet adding. >> >> > > I found this bug: >> >> > >http://projects.puppetlabs.com/issues/1672 >> >> > > which says there was a fix and it was merged but we're still seeing >> > > this issue... >> >> > > puppet agent v. 2.7.9 >> > > facter v. 1.6.5 >> >> > It could be this bug -https://projects.puppetlabs.com/issues/5752 >> >> > That andhttps://projects.puppetlabs.com/issues/9854arekeeping me from >> > pushing migrating to 2.7 up my priority list >> >> > Indeed, there are 5 issues marked Urgent in the 2.7.x bucket >> >> > 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-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. > -- Romeo -- 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] fqdn changes on client and connection to master fails
I have a situation where some of my puppet client machines fqdn's change. After this happens they fail to connect to the puppet master due to an untrusted certificate. It looks like manually setting a "certname" in the client puppet.conf file will work around this issue of the certname relying on the fqdn of the machine. Is this correct? Are there any gotcha's that I should be aware of before setting the certname setting in the client puppet.conf? (I realize I'll have to resign and certs where the newly set certname is different than the current certname.) Thanks, -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet eating solaris 10 crontab for lunch
Ugh, this isn't a nice bug to find out about. Just found out that on a few of our Solaris 10 global zones, puppet is destroying the crontab entry of the root user. It seems to be related to a hang in facter. I'm not 100% sure, but it seems the issue is occurring when facter runs 'prtdiag' on the hosts and prtdiag hangs midway (prtdiag is hanging due to the picld daemon being in a funky state and not returning the sensor data). It seems that this in turn puts puppet in a funky state, not sure how or why though. Here are the logs the solaris 10 box returns after it's crontab gets destroyed: ERR Puppet Could not prefetch cron provider 'crontab': Could not read crontab for root: No child processes NOTICE /Stage[main]/Puppet/Cron[puppet]/ensure created NOTICE Puppet Finished catalog run in 2.52 seconds After this the only thing that exists in the crontab is the entry we have puppet adding. I found this bug: http://projects.puppetlabs.com/issues/1672 which says there was a fix and it was merged but we're still seeing this issue... puppet agent v. 2.7.9 facter v. 1.6.5 Any suggestions or work-arounds short of not using the cron provider or completely managing the hosts crontab's centrally? Neither of which are ideal for us at the moment. Puppet should be returning the original crontab file should there be any failure. This is not comforting. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to fully remove a node from Puppet Dashboard (v1.2.4)
On Sun, Mar 11, 2012 at 08:09, Stefan Heijmans wrote: > Looks likes this bug at > http://projects.puppetlabs.com/issues/11210 Thanks, That indeed seems to be the same issue. I was going to leave a comment on the issue to say that even after I do a: puppet node clean on the puppet master the node still shows up. But, alas, I can't get my login to work on the puppet redmine ticket site. I reset the password and it still tells me I'm entering the wrong username or password. Bah... Oh well, at least there's a ticket for it already. Romeo > > Op zaterdag 10 maart 2012 03:39:31 UTC+1 schreef Romeo Theriault het > volgende: >> >> On Fri, Mar 9, 2012 at 12:05, Jeff McCune wrote: >> > On Wed, Mar 7, 2012 at 8:22 PM, Romeo Theriault >> > >> > wrote: >> >> >> >> I can delete a node in dashboard fine, but when I do a search with the >> >> Inventory Search the node shows up again and also then shows up under >> >> "Unreported". Any way to get rid of all references to the node? >> > >> > >> > Hi Romeo, >> > >> > I think this is a bug. Could you file a ticket describing what you'd >> > expect >> > to happen and what's actually happening when you delete a node at: >> > >> > http://projects.puppetlabs.com/projects/dashboard/issues/new >> >> Sure, I'll do this when I get back to work on Sunday. Thanks for the >> reply. >> >> -- >> Romeo > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/fMQuM3IiCQAJ. > > 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. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to fully remove a node from Puppet Dashboard (v1.2.4)
On Fri, Mar 9, 2012 at 12:05, Jeff McCune wrote: > On Wed, Mar 7, 2012 at 8:22 PM, Romeo Theriault > wrote: >> >> I can delete a node in dashboard fine, but when I do a search with the >> Inventory Search the node shows up again and also then shows up under >> "Unreported". Any way to get rid of all references to the node? > > > Hi Romeo, > > I think this is a bug. Could you file a ticket describing what you'd expect > to happen and what's actually happening when you delete a node at: > > http://projects.puppetlabs.com/projects/dashboard/issues/new Sure, I'll do this when I get back to work on Sunday. Thanks for the reply. -- Romeo -- 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] How to fully remove a node from Puppet Dashboard (v1.2.4)
I can delete a node in dashboard fine, but when I do a search with the Inventory Search the node shows up again and also then shows up under "Unreported". Any way to get rid of all references to the node? Thanks, -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Best practices for excluding certain modules from certain nodes
Thank you both for your great replies. They've both given me a great lead on which direction to head in. I haven't had the time to fully flesh out how I'm going to handle this yet but I know I'll be trying to stay away from parametrized classes for the time being. I'll also be trying to use hiera as much as possible to handle external data and determining which classes get applied to which nodes. Thanks again for the help. Romeo On Mon, Mar 5, 2012 at 04:24, jcbollinger wrote: > > > On Mar 2, 2:12 pm, Romeo Theriault wrote: >> On Fri, Mar 2, 2012 at 08:56, Romeo Theriault >> wrote: >> > [...] one item I can't seem to find a clean way of dealing >> > with is one-off nodes. For example, let's say I want to apply a class >> > called zabbix::agent to my whole infrastructure, so I put it in >> > common.yaml. But then I find out there are a few nodes that for >> > whatever reason I can't apply this class to. Short of just not >> > inheriting anything from common.yaml is there a clean way to say >> > "inherit everything from common except zabbix::agent"? >> >> > How are people dealing with the slight variations in their >> > infrastructure? I realize it's possible to code some logic into the >> > classes for these specific one-off hosts but that seems really hackish >> > and brittle. >> >> After a bit more googling I found this informative puppet-users thread: >> >> http://groups.google.com/group/puppet-users/browse_thread/thread/6b59... >> >> which talks about creating special "disabled" classes which inherit >> the widely used class and set certain values to 'undef'. This seems >> like it's probably the way to go since it's the best method I've >> seen/heard of so far to deal with this. > > > That is one of the standard approaches to the kind of problem you > describe, and it is simultaneously one of the few appropriate uses for > class inheritance. The post you referenced provides a rather specific > solution, however, and your description of it suggests that you may > not yet see how that generalizes. > > In particular, > 1) Overriding resource properties is the entire purpose of class > inheritance. > 2) A subclass can override resource properties to any value, not just > undef. In fact, I think overriding to undef is unusual. > 3) Although setting a resource property to undef generally means that > *property* is unmanaged, that's a very different thing from making the > entire resource be unmanaged. > 4) Not managing a resource (or property) is very different from > managing it to an atypical state. Either might be what you want. > > >> Anyone else dealing with this in a different way? > > > Not I, but I can offer some alternatives anyway. Hiera provides > several: > > A) Put an if block in Class['zabbix-agent'] around everything else in > the class body. Use hiera to look up the value controlling whether > the condition is satisfied. That provides an opt-out that any node > can be made to use simply by setting an appropriate value in its hiera > data. > > B) As I recall (but have not used), hiera provides an ENC-like > function whereby you can cause it to declare classes for your nodes > based on class names it looks up in your data. You could use that to > decide whether to apply Class['zabbix-agent'] instead of declaring it > in a class / node declaration that every node uses. Leverage hiera's > hierarchical structure. > > C) Instead of overriding certain resource properties in a subclass, > have the erstwhile parent class use hiera to look up the wanted > property values in the first place. This is a general-purpose > alternative to class inheritance. > > > 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-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. > -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Best practices for excluding certain modules from certain nodes
On Fri, Mar 2, 2012 at 08:56, Romeo Theriault wrote:
> Hi, I'm just getting started with puppet and am looking for some best
> practices on how to handle node and module inheritance issues. I'm
> planning to start using heira so want to plan my implementation around
> hiera specifics.
>
> Specifically, one item I can't seem to find a clean way of dealing
> with is one-off nodes. For example, let's say I want to apply a class
> called zabbix::agent to my whole infrastructure, so I put it in
> common.yaml. But then I find out there are a few nodes that for
> whatever reason I can't apply this class to. Short of just not
> inheriting anything from common.yaml is there a clean way to say
> "inherit everything from common except zabbix::agent"?
>
> How are people dealing with the slight variations in their
> infrastructure? I realize it's possible to code some logic into the
> classes for these specific one-off hosts but that seems really hackish
> and brittle.
After a bit more googling I found this informative puppet-users thread:
http://groups.google.com/group/puppet-users/browse_thread/thread/6b59ae2470acfa14/810eb8671a5b3cdd
which talks about creating special "disabled" classes which inherit
the widely used class and set certain values to 'undef'. This seems
like it's probably the way to go since it's the best method I've
seen/heard of so far to deal with this.
> I think a lot of shops do this by creating special "disabling" classes
> for those one-off systems. To use your puppetmaster example (untested
> pseudocode ahead):
> class puppet::client {
> file { '/etc/puppet/puppet.conf':
> ensure => present,
> source => 'puppet:///puppet/configfile',
> }
> }
> class puppet::client::disabled inherits puppet::client {
> File['/etc/puppet/puppet.conf'] {
> ensure => undef,
> source => undef,
> }
> }
> class puppet::server {
> include puppet::client::disabled
> }
> Now it's safe to apply puppet::client to all your nodes, including
> your puppetmaster, because the ::disabled class will override the
> management of puppet.conf on the puppetmaster (which presumably
> includes the puppet::server class).
Anyone else dealing with this in a different way?
Thanks,
Romeo
--
Romeo
--
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] Best practices for excluding certain modules from certain nodes
Hi, I'm just getting started with puppet and am looking for some best practices on how to handle node and module inheritance issues. I'm planning to start using heira so want to plan my implementation around hiera specifics. Specifically, one item I can't seem to find a clean way of dealing with is one-off nodes. For example, let's say I want to apply a class called zabbix::agent to my whole infrastructure, so I put it in common.yaml. But then I find out there are a few nodes that for whatever reason I can't apply this class to. Short of just not inheriting anything from common.yaml is there a clean way to say "inherit everything from common except zabbix::agent"? How are people dealing with the slight variations in their infrastructure? I realize it's possible to code some logic into the classes for these specific one-off hosts but that seems really hackish and brittle. Thanks for any insight! -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Dashboard, node classes, what do they do part 2
On Fri, Mar 2, 2012 at 04:12, Peter Berghold wrote: > > > On Fri, Mar 2, 2012 at 12:55 AM, Romeo Theriault > wrote: >> >> >> In the Dashboard, when they say "classes" they really mean "module". >> > > > > This begs a follow-on question: > > if classes == modules in Dashboard then maybe I need to take a second look > here. Actually, after I sent this I started thinking about it a bit more. I'm just getting started with Dashboard and it's been working for me to just put in the "module" name in the Dashboard and not the class-name. But I'm not sure if this is because my "class" name up till now has always been same as the module name and it has up till now always resided inside of the init.pp in the module. So, I guess what I'm saying is that I'm not so sure if classes == modules in Dashboard. It may be that if you have other classes in the module you may be able to call them directly with "modulename::classname" (?) but I'm not really sure. I'd just test it out for a while to figure it out. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Dashboard, node classes, what do they do part 2
On Thu, Mar 1, 2012 at 11:51, Peter Berghold wrote: > Hi folks, > > Went back and did some more reading and found the intriguing entry in the > Dashboard documentation > > "The classes the console knows about are a subset of the classes in your > puppet master’s collection of modules. You must add classes to the console > manually if you want to assign them to any nodes or groups." > > OK fair enough. I have a class (just picking one) defined in a module > called postfix::inbound which I defined on the console and added it to a > host group of which a brand new clean server. For now the class is written > just to notify that it is being invoked. > > When I run the puppet agent I don't see the class being applied. > > Am I hoping for too much? Maybe :) In the Dashboard, when they say "classes" they really mean "module". Add "postfix::inbound" instead of the actual class inside of the module to the Dashboard and it should work just fine for you. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Change user password only on systems where they exist
On Sun, Feb 26, 2012 at 05:05, bel wrote:
> You might want to change the regex used in the grep line to:
>
> '^${user}:' # Adding the colon
>
> This would prevent false-positives when, for e.g., you are looking for
> user "joe" in a system where it doesn't exist but "joep" does.
Thanks! Good point, I'll definitely do that.
--
Romeo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Change user password only on systems where they exist
On Thu, Feb 23, 2012 at 04:04, jcbollinger wrote: > Do you want merely to reset the password and then ignore subsequent > changes, or do you intend to keep the password fixed to the new > value? If the former then Puppet isn't the right tool for the job. > Instead, you want MCollective or another product in that vein. Hi John, thanks for the reply. Yes we just want to reset it and ignore it. I realize this isn't the best (or intended) way of using puppet but it works :) and we don't have mcollective right now. Hopefully someday will have mcollective but from what I've read Solaris support is still weak and I don't have the time at the moment into trying to get it working on solaris. I also realize that solaris support is in the PE version of puppet/mcollective but I've first got to "sell" puppet to management before we start talking about purchasing PE. Also, point well taken on the NIS/LDAP central authentication, but at this point that big of an infrastructure change is not in the cards. -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Change user password only on systems where they exist
On Wed, Feb 22, 2012 at 21:30, Steve Shipway wrote:
> We have a system here that automatically resets the root password (amongst
> others) when they are >60 days old, and stores the >new password in a central
> encrypted location. To do this, we have a custom fact that identifies the
> age of users, and a custom >function that returns if a user exists and, if
> so, the age of their password. Another custom function creates a new
> passowrd, and a >final one does the update i nthe central encrypted database.
> An Exec resource takes care of the actual password change on the >puppet
> agent.
>
> Is this similar to what you're looking for? If you take a look in the Puppet
> Forge website for the 'ss' module then you can see how > we do it there, else
> contact me off-list.
Hi, thanks for the reply. At this point we're looking for something
much more simple. We basically want to be able to change a users
password across all of the systems that they currently exist on. I
took a look at your 'ss' module (thanks for pointing it out) and found
your Exec which does the actual password changing. I kinda wanted to
stay away from having to install the chgpasswd utility across all of
our Solaris boxes though, so I sat on it a while longer, thinking
about it and came up with this Exec which seems to do what I want with
puppet itself. I've got to test it a bit more first though.
define change_passwd($user,$passwd) {
exec { "/usr/bin/puppet apply -v -e \'user { \"${user}\": password
=> \"${passwd}\" }\'":
onlyif => "/bin/grep -c ^${user} /etc/shadow"
}
}
--
Romeo
--
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] Change user password only on systems where they exist
Hi, We're just getting started with puppet and one of the things we'd
like to automate across a mix of Solaris and RHEL boxes is resetting a
users password. But we only want to reset the users password on the
boxes they already exist on. We don't want to have their account
created on all the boxes. We also don't want to modify any of their
settings like shells, etc...
I've used puppet to create users across all our boxes and that was
straight forward but I'm not sure the best way to conditionally change
a users password is. If it was just RHEL I'd be tempted to check for
the users homedir and then do an exec { " usermod -p" }, but
solaris doesn't support the usermod -p (for password) option. Is there
a more "puppet" way to pull this off?
Thank you,
Any suggestions would be appreciated.
--
Romeo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet syntax check for Komodo Edit
On Sat, Feb 18, 2012 at 10:01, Mister IT Guru wrote: > Hi All, > > Please forgive me for jumping on this thread, but I'm a bit shocked - Syntax > highlighting for puppet? Sorry for being slow on this one, I have been > cracking my eyes using nano, and basic text editors - It never crossed my > mind to use an IDE!! > > Feel free to shame me as you see fit - I think I deserve punishment for > missing a trick here! I've seen two recommendations for OSX users, Komodo > Edit, and Eclipse. I think I'll download them now, I'm open for other > suggestions! Vim has some good syntax highlighting. https://github.com/vim-scripts/Puppet-Syntax-Highlighting -- Romeo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] SSL Errors - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B
Hi Felix, thanks for your response to my question. It's taken me a while to get back to this issue but I finally figured it out tonight. I had a old puppetd process running in the background (I'd since moved to using cron to call puppet) that must have been holding open it's old cert files, etc... After I killed the old puppetd process everyting is working as it should. (i.e. no more errors and the correct puppet process is still running as it should). Thanks, Romeo On Mon, Jan 30, 2012 at 07:55, Felix Frank wrote: > Hi, > > concerning your question why everything seems to work pretty well: > > On 01/27/2012 04:59 AM, Romeo Theriault wrote: >> Jan 26 17:09:41 ppt01 puppet-agent[27357]: Using cached catalog > > Your agent is using a cached catalog. > > puppet agent --test should fail. Also, changing the manifest for this > node should not have any effect until you resolve this problem. > > My guess is that the agent has an old master certificate stored or > somesuch. For some reason it regards your current master cert as invalid. > > The simplest approach may be to scrutinize the local /var/lib/puppet/ssl > for certificates that match your master's FQDN (perhaps "puppet"). If > you find several, use "openssl x509" to find out how they differ. > > HTH, > Felix > > -- > 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. > -- Romeo -- 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] SSL Errors - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B
Hello, I'm new to puppet and am getting a puppet server setup with puppet dashboard. I have the puppet server and puppet dashboard (Apache/Passenger) setup and working well with 60+ test nodes working as expected. Only problem is that I have this one error in the logs which I can't figure out. Jan 26 17:09:41 ppt01 puppet-agent[27357]: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client Jan 26 17:09:41 ppt01 puppet-agent[27357]: Using cached catalog Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/File[run_puppet.sh]) Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client Could not retrieve file metadata for puppet:///modules/puppet/run_puppet.sh: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client at /etc/puppet/modules/puppet/manifests/init.pp:67 Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/Cron[puppet]) Dependency File[run_puppet.sh] has failures: true Jan 26 17:09:42 ppt01 puppet-agent[27357]: (/Stage[main]/Puppet/Cron[puppet]) Skipping because of failed dependencies Jan 26 17:09:42 ppt01 puppet-agent[27357]: Finished catalog run in 0.21 seconds Jan 26 17:09:42 ppt01 puppet-agent[27357]: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client These errors are from the puppet agent that is running on the puppet-master server. The odd thing is if I run it manually everything works as it should. I also have a cron job that runs it every 30 minutes and this works fine as well. I have no idea how the puppet agent is getting called during this failed run. It happens reliably every 30 minutes but outside of the time that my cron job runs... Does anyone have any idea what might be calling this failed run? Something with the dashboard I'm guessing but I'm unable to find anything. Next odd thing is that this failed run also doesn't appear to be affecting anything. All the Dashboard (and puppet master) functionality is working as it should, including reporting, filebucketing and inventory. All clients are getting their catalogs, etc... so I'm really not sure where this is originating from. I should note that I did change the hostname the puppet server is using but updated every (I think) to reflect the new hostname, including regenerating the server and client certs. I've found this page: http://docs.puppetlabs.com/pe/2.0/maint_common_config_errors.html#do-agents-trust-the-masters-certificate which covers these errors but they don't seem to be my issue. It's obviously not a time issue considering the agent that is complaining in on the master. I've `puppet cert clean`-ed, re-re-created and re-signed the client certs against the new master certs and the puppet agent runs are working from my cron calls and when run manually. Any help in determining where this is getting called from and how I can clear it up would be greatly appreciated. Here is my puppet.conf on my master. I'd be happy to provide any other info that my be helpful. [agent] server = host.pvt.domain.com report = true [master] ssldir = $vardir/ssl certname = host.pvt.domain.com # For the Inventory service facts_terminus = inventory_active_record dbadapter = mysql dbname = puppet_inventory dbuser = puppet dbpassword = super-secret dbserver = localhost dbsocket = /var/lib/mysql/mysql.sock # For reports reports = store, http reporturl = http://host.pvt.domain.com/reports/upload # For puppet dashboards external node classification. node_terminus = exec external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=http://puppet:80 /usr/share/puppet-dashboard/bin/external_node Thank you, -- Romeo -- 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.
