I am currently consulting for an installation where the change
management process does not allow changed to be automated. They are,
however, using puppet, but the puppet agent is executed manually.
They are preparing to move away from this modus and would like to have
a cron job that will allow hourly puppet agent runs in certain time
slots (such as tuesday morning 0300-0600), so that people know when
changes are going to happen automatically and look at the reports.
Currently, I am controlling this via parameters attached to the host
group.
The hourly cron job logs in to foreman with a set of credentials and
downloads the host data via curl http://foreman/api/hosts/#{fqdn_s}.
Of course, this way any host can download any host's data, and while
the foreman account being used here has not many privileges, I am not
comfortable with this solution.
I would prefer to have the host use its puppet certificate to download
the catalog and then evaluate the catalog for the parameters that
might be useful to control whether an actual puppet agent should be
invoked or not. If this is not possible, I'd prefer having a small
network service on the foreman host that verfies a callign client with
its puppet certificate and then return the list of relevant parameters
so that the client can decide whether to do an actual puppet run or not.
Has this already been done? Is there a less ugly solution?
Greetings
Marc
···
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Use Puppet to configure the cron? Also I strongly advise against having all
the Puppet agents running at the same time, depending on the scale you will
likely see performance issues on the foreman server/proxy.
I have an example using the hostname to create a random number and using
that to create a cron at [1]. but you could use a parameter there instead.
[1]
···
On Mon, Dec 19, 2016 at 4:06 PM, Marc Haber wrote:
Hi,
I am currently consulting for an installation where the change
management process does not allow changed to be automated. They are,
however, using puppet, but the puppet agent is executed manually.
They are preparing to move away from this modus and would like to have
a cron job that will allow hourly puppet agent runs in certain time
slots (such as tuesday morning 0300-0600), so that people know when
changes are going to happen automatically and look at the reports.
Currently, I am controlling this via parameters attached to the host
group.
The hourly cron job logs in to foreman with a set of credentials and
downloads the host data via curl http://foreman/api/hosts/#{fqdn_s}.
Of course, this way any host can download any host’s data, and while
the foreman account being used here has not many privileges, I am not
comfortable with this solution.
I would prefer to have the host use its puppet certificate to download
the catalog and then evaluate the catalog for the parameters that
might be useful to control whether an actual puppet agent should be
invoked or not. If this is not possible, I’d prefer having a small
network service on the foreman host that verfies a callign client with
its puppet certificate and then return the list of relevant parameters
so that the client can decide whether to do an actual puppet run or not.
Has this already been done? Is there a less ugly solution?
Greetings
Marc
–
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things.” Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
That's the naive approach, which won't work if there are no puppet
runs at all on a host. Any host will only pick up configuation changes
on a puppet run, so when I want to increase a host's puppet run
frequency, I'd either have to invoke a puppet run manually or to wait
for the next run according to the old schedule.
We rejected that idea.
> Also I strongly advise against having all the Puppet agents running at
> the same time, depending on the scale you will likely see performance
> issues on the foreman server/proxy.
Guaranteed, that's why our puppet cron job has a semi-random
component.
> I have an example using the hostname to create a random number and using
> that to create a cron at [1]. but you could use a parameter there instead.
We use the MAC address for that.
Greetings
Marc
···
On Wed, Dec 21, 2016 at 07:33:18PM +0000, Sean O'Keeffe wrote:
–
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things.” Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
We do similar things, where Foreman holds data about a host that's not
necessarily related to a puppet run. Luckily, Puppet allows the host to
retrieve its ENC data at any time. Here is a simple function that you could
utilize to retrieve Foreman ENC data about a host:
query_puppetmaster() {
NODE_DATA=$(mktemp)
> trap "rm -f $NODE_DATA" exit
>
> # temporarily silence STDERR
> exec 3>&2 2> /dev/null
>
> PUPPETMASTER=$(puppet config print --section agent server)
> CERTNAME=$(puppet config print --section agent certname)
> CERTFILE=$(puppet config print --section agent hostcert)
> PRIVKEY=$(puppet config print --section agent hostprivkey)
> CACERT=$(puppet config print --section agent localcacert)
> ENVIRONMENT=$(puppet config print --section agent environment)
>
> # unsilence STDERR
> exec 2>&3
>
> # validate this host has a signed Puppet certificate
> [ ! -f "$CERTFILE" ] && error "doesn't look like this host is
> registered via Puppet" && exit 1
>
> # retrieve node data via Puppetmaster REST API
> curl -H "Accept: pson"
> https://:8140$PUPPETMASTER/$ENVIRONMENT/node/$CERTNAME
> --cert $CERTFILE --key $PRIVKEY --cacert $CACERT --silent --fail >
> $NODE_DATA
>
> [ $? -ne 0 ] && error 'failed to retrieve node configuration' && exit 1
>
> # If statement is because puppet changed their response format between
> puppet3 and puppet4 and we're
> # in the process of upgrading our to puppet4
> DATA=$(cat $NODE_DATA | jq -r .parameters.${KEY})
> [ $DATA == 'null' ] && DATA=$(cat $NODE_DATA | jq -r
> .data.parameters.${KEY})
>
> echo $DATA
> }
>
we've wrapped this function into a script we aptly call "get-foreman-data"
which takes the KEY as a parameter.
···
On Thursday, December 22, 2016 at 2:10:26 AM UTC-5, Marc Haber wrote:
>
> Hi Sean,
>
> On Wed, Dec 21, 2016 at 07:33:18PM +0000, Sean O'Keeffe wrote:
> > Use Puppet to configure the cron?
>
> That's the naive approach, which won't work if there are no puppet
> runs at all on a host. Any host will only pick up configuation changes
> on a puppet run, so when I want to increase a host's puppet run
> frequency, I'd either have to invoke a puppet run manually or to wait
> for the next run according to the _old_ schedule.
>
> We rejected that idea.
>
> > Also I strongly advise against having all the Puppet agents running at
> > the same time, depending on the scale you will likely see performance
> > issues on the foreman server/proxy.
>
> Guaranteed, that's why our puppet cron job has a semi-random
> component.
>
> > I have an example using the hostname to create a random number and using
> > that to create a cron at [1]. but you could use a parameter there
> instead.
>
> We use the MAC address for that.
>
> Greetings
> Marc
>
> --
> -----------------------------------------------------------------------------
>
> Marc Haber | "I don't trust Computers. They | Mailadresse im
> Header
> Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224
> 1600402
> Nordisch by Nature | How to make an American Quilt | Fax: *49 6224
> 1600421
>
