Re: [Puppet Users] autosign
Autosign works, but not as you're expecting: it will sign new certificates, but not overwrite existing ones. At least, that's my experience here :) -- Bill Weiss Backstop Solutions Group On 2012/4/24 3:34 AM, "C R Ritson" wrote: >Does autosign work? I have a scratch workstation that may be rebuilt >frequently and will therefore acquire a new client certificate. I was >hoping that adding its certificate name to /etc/puppet/autosign.conf on >the puppetmaster would allow just this one client to have its new >certificates autosigned. This doesn't appear to work and I can find no >logged errors telling me what is wrong. Can someone suggest where to >look, please? > > >Chris Ritson (Computing Officer and School Safety Officer) > >Room 707, Claremont Tower,EMAIL: c.r.rit...@ncl.ac.uk >School of Computing Science, PHONE: +44 191 222 8175 >Newcastle University, FAX : +44 191 222 8232 >Newcastle upon Tyne, UK NE1 7RU. WEB : http://www.cs.ncl.ac.uk/ > >-- >You received this message because you are subscribed to the Google Groups >"Puppet Users" group. >To post to this group, send email to puppet-users@googlegroups.com. >To unsubscribe from this group, send email to >puppet-users+unsubscr...@googlegroups.com. >For more options, visit this group at >http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to use Puppet to ensure the Sun JDK is installed on CentOS-5.5
On 2011/4/12 2:55 PM, "Shi" wrote:
>Hi there,
>
>I am new to Puppet and am writing my first module to manage our
>cluster. So far, it worked out reasonably well. I can add yum
>repositories and install packages with Puppet automatically.
>However, one package requires the use of Sun JDK, not the openjdk
>coming with CentOS.
>The only way to do this is to download the jdk-6u24-linux-x64-rpm.bin
>file and run it.
>
>I figure I might be able to use something like
>
>package {jdk:
>source="/mnt/share/jdk-6u24-linux-x64-rpm.bin",
>ensure => installed;
> }
>
>I guess I could put the file under the shared NFS /mnt/share. But
>there is no way I can tell puppet to simply run the source as an
>executable. All the PROVIDER options are for a particular format, such
>as RPM or DEB. I guess I could run the file once on one machine, and
>it will extract the rpms. I could then just use the rpms, but that is
>less than ideal.
>
>Also, if I don't want to pre-mount the NFS share, is there any way to
>scp the file from the master node? Do I then have to set up ssh
>without password for the root?
It's easier than you think! :)
If you run that .bin with -x on the command line, it will extract an RPM
for you to use. I do that once per new JDK and put it in our local yum
repository.
--
Bill Weiss
Backstop Solutions Group
--
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] gems, ruby installs, and paths
> -Original Message- > From: Nigel Kersten [mailto:ni...@puppetlabs.com] > Sent: Saturday, April 02, 2011 7:05 PM > To: puppet-users@googlegroups.com > Cc: Bill Weiss > Subject: Re: [Puppet Users] gems, ruby installs, and paths > > On Sat, Apr 2, 2011 at 4:29 PM, Bill Weiss > wrote: > > > In a similar situation (ruby-1.8.x and REE installed on a server), I > found that mangling the PATH to point at the appropriate ruby did it. > That only works if your entire puppet config (including puppet > itself?) works with that ruby, of course. > > > > Otherwise, I think the exec is it. Unless someone (one of us?) > patches the gem provider to take a PATH? I don't know if that's useful > for anything other than the sad case of too many rubys (rubies?) being > installed at once, or if this is a common problem. > > The gem package provider doesn't specify a given PATH for the gem > command. > > If you construct your PATH for the puppet process such that the > desired gem is found first, that will work, but doesn't solve the > problem some people have with wanting to use several different gem > executables within the same puppet run. Right. I meant the OS PATH, not the PATH inside of Puppet. Thanks for the clarification, Nigel. -- Bill Weiss Backstop Solutions Group -- 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] gems, ruby installs, and paths
> -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Robin Lee Powell > Sent: Friday, April 01, 2011 4:40 AM > To: Puppet Users > Subject: [Puppet Users] gems, ruby installs, and paths > > > I'm working on a system (not created by me, I swear) that has > something like 5 different versions of ruby installed, including a > couple of versions of jruby. > > I need to install a gem, but I need to use /opt/jruby/bin/gem (or > jgem) to do it. > > Unfortunately, I can't see any way to modify puppet's path to help > it find this little "gem" (ha ha). > > Is path modification like this possible? > > Is there another/better way to handle this issue? > > Of course I could use an "exec", but I try to avoid those whenever > at all possible since it rather defeats the purpose of using puppet > (see > http://utcc.utoronto.ca/~cks/space/blog/programming/ConfiguringInRealLa > nguage > ) In a similar situation (ruby-1.8.x and REE installed on a server), I found that mangling the PATH to point at the appropriate ruby did it. That only works if your entire puppet config (including puppet itself?) works with that ruby, of course. Otherwise, I think the exec is it. Unless someone (one of us?) patches the gem provider to take a PATH? I don't know if that's useful for anything other than the sad case of too many rubys (rubies?) being installed at once, or if this is a common problem. -- Bill Weiss Backstop Solutions Group -- 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] Looking for a Linux sysadmin in Chicago
Hello all, Backstop Solutions Group is looking for a Linux System Administrator to work in our downtown Chicago office running our production environment along with some dev and QA space. We're buzzword compliant (SaaS products, some Ruby on Rails, etc), pretty DevOps-y (getting more so all the time) and won't make you do Windows unless you want to. We run Puppet for our automation, Oracle for our databases, and CentOS/RHEL for our servers. We're small enough that you can know everyone by name, even the sales people, but large enough that you don't have to buy your own furniture. I'll save you the full pitch. If you're interested, come take a look at http://www.backstopsolutions.com/company/jobs/sys_admin.shtml . We've got a big-HR system to apply to, but don't let that scare you off: I'll personally read your resume if it comes through there. I'm the manager of the position so please email me any questions you have. Thanks! Feel free, of course, to forward this to any of your friends who could use something new to do. I'll buy you a beer or two if you refer someone good :) (Our friendly hosts said this was ok to post here. Thanks guys!) -- Bill Weiss Backstop Solutions Group -- 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] do X if package Y is installed?
> -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Daniel Pittman > Sent: Wednesday, June 02, 2010 1:36 AM > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] do X if package Y is installed? > > Bill Weiss writes: > > > Sorry if this is a FAQ that I’ve missed. A pointer to TFM would be > > appreciated if so. > > > > I’m looking for a conditional include of sorts. In module X, I’d > like to > > frob a file if the httpd package is installed. If it’s not, I want > to just > > skip it. Is there a simple way to do this? > > Other people pointed you to writing a custom fact. Let me instead tell > you > why this isn't the best strategy, and suggest another approach that > might work > better in the long run: > > Generally speaking, the more decisions you make in your code the harder > it is > to understand. For example, module foo might do something or might not > based > on module bar being included — in this case, module bar is the HTTPD > package > being installed. > > > A better approach, and one that is simpler, is to specify policy: > > Any host that needs a web server has httpd installed and this file > frobbed. > > Any host that doesn't need a web server does not have httpd > installed. > > Then, code that up in your manifests without the decision: > > In X, install httpd[1] and frob the file. In Y, don't do either. > > Daniel > > Footnotes: > [1] Probably best done by include a httpd class rather than directly > writing > out the 'package' stanza, so other modules can also add the httpd > service. Sorry for raising my thread from the past here. My problem is, in this case, there are machines that need X but not Y, Y but not X, X and Y, or neither. I can obviously write all of those cases out separately, but that means duplication of code for setting up the parts of X and Y that aren't dependant. Custom facts are probably the best way for me to do this, but I'd love to hear that there's a simpler way. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] do X if package Y is installed?
All, Sorry if this is a FAQ that I’ve missed. A pointer to TFM would be appreciated if so. I’m looking for a conditional include of sorts. In module X, I’d like to frob a file if the httpd package is installed. If it’s not, I want to just skip it. Is there a simple way to do this? Thanks. -- Bill Weiss Backstop Solutions Group -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Odd behavior for clients with trailing dot in their FQDN
2010/4/21 Jesús M. Navarro : > I Bliss: > > On Wednesday 21 April 2010 20:33:26 Bill Weiss wrote: >> All, >> >> I'm just getting started with puppet, so excuse any lack of vocabulary >> in this email. >> >> I've got a server (CentOS 5.4) running with a little more than the >> example puppet configuration. Importantly, I'm using the supplied >> auth.conf, and the relevant portion looks like this: >> path ~ ^/catalog/([^/]+)$ >> method find >> allow $1 >> >> I just created a new VM as a puppet client (also CentOS 5.4), which >> calls itself ib3stage.domainI. (with trailing dot). > > While probably on the verge of bein technically correct (after all the ending > dot is the mark for the root domain) is quite extrange ending FQDNs with the > dot outside declarations on DNSs. May I ask why such a extrange host name > (why not just ib3stage.domainI)? Because my company owns domainI.com. , and uses domainI. internally. So, to disambiguate, I use domainI. for internal systems. I'm pretty sure that I can change this machine to not be rooted, but software that handles FQDNs should accept rooted domains. How it's handled could be up to debate (though it seems simple to me), but just dropping it on the floor doesn't seem right. -- Bill Weiss ^[:wq -- 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] Odd behavior for clients with trailing dot in their FQDN
All, I'm just getting started with puppet, so excuse any lack of vocabulary in this email. I've got a server (CentOS 5.4) running with a little more than the example puppet configuration. Importantly, I'm using the supplied auth.conf, and the relevant portion looks like this: path ~ ^/catalog/([^/]+)$ method find allow $1 I just created a new VM as a puppet client (also CentOS 5.4), which calls itself ib3stage.domainI. (with trailing dot). When it tries to sync for the first time, I get this on the client: -bash-3.2# puppetd --waitforcert 60 --test --server puppet.domainB. err: Could not retrieve catalog from remote server: Error 403 on SERVER: Forbidden request: ib3stage.domainI.(10.0.12.15) access to / catalog/ib3stage.domainI. [find] authenticated at line 0 warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run The server shows this: info: access[^/catalog/([^/]+)$]: allowing 'method' find info: access[^/catalog/([^/]+)$]: allowing $1 access info: access[/certificate_revocation_list/ca]: allowing 'method' find info: access[/certificate_revocation_list/ca]: allowing * access info: access[/report]: allowing 'method' save info: access[/report]: allowing * access info: access[/file]: allowing * access info: access[/certificate/ca]: adding authentication no info: access[/certificate/ca]: allowing 'method' find info: access[/certificate/ca]: allowing * access info: access[/certificate/]: adding authentication no info: access[/certificate/]: allowing 'method' find info: access[/certificate/]: allowing * access info: access[/certificate_request]: adding authentication no info: access[/certificate_request]: allowing 'method' find info: access[/certificate_request]: allowing 'method' save info: access[/certificate_request]: allowing * access info: access[/]: adding authentication any info: access[^/catalog/([^/]+)$]: defaulting to no access for ib3stage.domainB. warning: Denying access: Forbidden request: ib3stage.domainI. (10.0.12.15) access to /catalog/ib3stage.domainI. [find] authenticated at line 52 err: Forbidden request: ib3stage.domainI.(10.0.12.15) access to / catalog/ib3stage.domainI. [find] authenticated at line 52 If I convince the client that it is "ib3stage.domainI" (no dot), everything works as expected. Likewise, if I change the third line of my auth.conf stanza from above to "allow*", it works, though I don't want to continue to run like that. Can any of you reproduce this? Discussion in IRC was that this seemed like a bug, but I'd like a sanity check before I file one. It was suggested that a fix to facter could help with this (to strip trailing dot?), but I would guess that this is a server-side thing. Thank you. -- 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.
