Is it possible for puppet to exec puppetrun?

I have a case where I want an event to force an update on a few systems.
So, I'm trying to get puppet to exec puppetrun, but it is not working.

I can run the exact puppetrun command manually and it works. But when
puppet runs it, it claims it executed it successfully, but the remote
system is not triggered.

Is it possible for puppetd to exec puppetrun? Or do I have some other
issue?

    case $hostname {
        "admin4012": {$cmd = "puppetrun --host admin4001 --host
admin2001" }
        "admin1016": {$cmd = "puppetrun --host admin1001" }
    }
    if $cmd {
        exec { puppetrun:
            command => $cmd,
            path => ["/usr/bin", "/usr/sbin"],
            # Run if the file has changed in the last 20 minutes
            unless => "test $(expr `date +'%s'` - `date +'%s' -r
/etc/puppet/templates/aliases.erb`) -gt 1200"
         }
    }

Thanks,

Steven

Re: Is it possible for puppet to exec puppetrun?

Never mind.
For some reason the path is not sufficient. The full path must be part
of the command. Change the commands to "/usr/bin/puppetrun ..." then it
works.

> -----Original Message-----
> From: puppet-users-bounces <at> madstop.com [mailto:puppet-users-
> bounces <at> madstop.com] On Behalf Of Steven Nemetz
> Sent: Friday, November 30, 2007 4:03 PM
> To: Puppet User Discussion
> Subject: [Puppet-users] Is it possible for puppet to exec puppetrun?
> 
> I have a case where I want an event to force an update on a few
systems.
> So, I'm trying to get puppet to exec puppetrun, but it is not working.
> 
> I can run the exact puppetrun command manually and it works. But when
> puppet runs it, it claims it executed it successfully, but the remote
> system is not triggered.
> 
> Is it possible for puppetd to exec puppetrun? Or do I have some other
> issue?
> 
>     case $hostname {
>         "admin4012": {$cmd = "puppetrun --host admin4001 --host
> admin2001" }
>         "admin1016": {$cmd = "puppetrun --host admin1001" }
>     }
>     if $cmd {
>         exec { puppetrun:

Re: Provider error with FreeBSD 7 beta 3

Giorgio Valoti wrote:
> On 29/nov/07, at 23:27, Russell Jackson wrote:
> 
>>> […]
>> The error is correct. There is no FreeBSD service provider in the  
>> current release. I've
>> opened a ticket with a patch for a basic one that supports enabling.
>> […]
>> You'll have to add '/usr/local/etc/rc.d' to the search path:
>>
>> Service { path => [ '/etc/rc.d', '/usr/local/etc/rc.d' ] }
> 
> It works! But now I’m puzzled again. If I add:
> 
> ensure => false

That should stop it. You may need to have hasstatus => true.

> 
> shouldn’t apache get stopped?
> I also haven’t found a way to enable apache at the /etc/rc.conf level.  
> My “solution” was something like this:
> file { "rc-conf": … }
> service {
> 	apache2: subscribe => File[rc-conf]
> 	…
> }
> But it seems far from ideal because, every time I edit rc.conf, apache  
> gets restarted. Am I right?
> 

Building files from snippets

_______________________________________________
Puppet-users mailing list
Puppet-users <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

conf directory

Hi,

I have noticed that in the conf directory of the puppet gem there are a 
bunch of files such as:

- init.d scripts for starting/stopping puppetd
- sysconfig files for redhat
- logrotate files
.. etc

Is there some automatic way of using these files or are they just 
example config files that we can install ourselves.

thanks, Iain.

--

-- 
Iain Pople
Systems Interface Technical Lead
University of Melbourne

Re: conf directory

Iain Pople wrote:
> Hi,
> 
> I have noticed that in the conf directory of the puppet gem there are a 
> bunch of files such as:
> 
> - init.d scripts for starting/stopping puppetd
> - sysconfig files for redhat
> - logrotate files
> .. etc
> 
> Is there some automatic way of using these files or are they just 
> example config files that we can install ourselves.

These are examples.  There is no automatic way of using them.

Regards

James Turnbull

--

-- 
James Turnbull <james <at> lovedthanlost.net>
---
Author of Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)

Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)

_______________________________________________
Puppet-users mailing list
Puppet-users <at> madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Re: Provider error with FreeBSD 7 beta 3

On 01/dic/07, at 03:02, Russell Jackson wrote:

> Giorgio Valoti wrote:
>> On 29/nov/07, at 23:27, Russell Jackson wrote:
>>
>>>> […]
>>
>> It works! But now I’m puzzled again. If I add:
>>
>> ensure => false
>
> That should stop it. You may need to have hasstatus => true.

Now it works fine.

>
>>
>> […]
>>
>
> Like I said before, the release version of puppet doesn't have a  
> freebsd specific service
> provider, so it uses the basic init provider which doesn't support  
> enabling the service
> (see http://reductivelabs.com/trac/puppet/ticket/880)
>
> You can work around this limitation with something like:
>
> file { "/etc/rc.conf.d": ensure => directory }
>
> file { "/etc/rc.conf.d/apache20":
>  ensure => present,
>  content => "apache20_enable=\"YES\""
> }
>
> This way puppet doesn't interfere with the rest of /etc/rc.conf.
>
> Remember, under the FreeBSD init system, the <service>_enable="YES"  
> line must be present
> in order to start _OR_ stop the service. So, if you remove the  
> enable line first, and then
> try '/usr/local/etc/rc.d/apache20 stop', nothing will happen. You  
> can use onestart/onestop
> to get around that too, but then you'll have to override the stop  
> and start commands in
> all your service definitions; hence, the patch in ticket #880 .

You’re right. I’ll take a look at your patch to see how it works.

Thank you
--
Giorgio Valoti

Re: Building files from snippets

On Saturday 01 December 2007, José González Gómez wrote:
> Hi there,
>
> I'm facing a problem that I think it's common enough to be solved directly
> by puppet or at least have a best practice recommended: building a config
> file from snippets. I'm thinking for example about a dns zone and hosts
> inside that zone, ldap server and ldap databases, samba server and samba
> shares, a firewall config and firewall rules,... The first part of the list
> (ldap server, samba server, firewall config) seems to map to the concept of
> class in puppet, while the second part (DNS host, ldap database, samba
> share, firewall rule) seems to map to puppet types or definitions related
> to the first group.
>
> I've searched a bit, and have found that people use to solve this creating
> a set of files on disk and concatenating them using some script [1] or even
> having a definition that takes care of this stuff [2].
>
> The questions are: Is there any best practice regarding this or any other
> way to do it? Do you think puppet should provide direct support for this?
>
> Best regards
> Jose
>
> [1] http://snurl.com/1uh2o
> [2] http://snurl.com/1uh2n

Using concatenated_file from [2] works very well for me. Being the author of 
that Define, I might be biased though. 

The "best practice" of course would be to model the contents of each config 
file as Resources and create a native ParsedFile provided Type handling the 
format in question. 

Regards, David
--

-- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
-- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking

certificate issue with Branch Testing

Hello All,

I'm using the "Branch Testing" approach documented at 
https://reductivelabs.com/trac/puppet/wiki/BranchTesting and am seeing 
an issue with certificates.

On all clients, I can run puppetd --masterport=8141 successfully but see 
the following error when I run against the default (8140) port:

err: Could not retrieve configuration: Certificates were not trusted: 
certificate verify failed

If anyone could explain what's happening with the certificates here, I'd 
really appreciate it.

All the best,
Adam Kosmin

Re: certificate issue with Branch Testing

On Dec 3, 2007, at 10:30 AM, Adam Kosmin wrote:
> On all clients, I can run puppetd --masterport=8141 successfully but  
> see
> the following error when I run against the default (8140) port:
>
> err: Could not retrieve configuration: Certificates were not trusted:
> certificate verify failed
>
> If anyone could explain what's happening with the certificates here,  
> I'd
> really appreciate it.

Do the two different puppetmaster servers have their SSL certificates  
signed by the same CA?  If not, then the client will only work with  
the server it initially receives it's signed certificate from.

Cheers,
--
Jeff McCune
Systems Manager
The Ohio State University
Department of Mathematics