Puppet Trouble Shooting Tips

| Comments

Overview

Below are some tips and tricks for trouble shooting puppet.

Manually Running Puppet Agent

You can manually execute puppet on a remote node and see the output. This needs to be run from the puppet.arin.net server

1
sudo puppet agent --test

Puppet Agent takes a long time to complete

This has happened a few times where executing the puppet agent will take a long period to complete ( The average is 5-10 sec ). To determine what is taking a long time with applying the catalog you can use —summarize to a summary of change and times to complete.

1
sudo puppet agent --test --summarize
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
notice: Finished catalog run in 3.57 seconds
Changes:
 Total: 2
Events:
 Total: 2
 Success: 2
Resources:
 Total: 114
 Out of sync: 2
 Changed: 2
 Skipped: 6
Time:
 Filebucket: 0.00
 Package: 0.00
 Yumrepo: 0.00
 Exec: 0.01
 Group: 0.01
 Ssh authorized key: 0.03
 User: 0.03
 File: 0.23
 Last run: 1334583207
 Service: 2.34
 Config retrieval: 2.90
 Total: 5.56
Version:
 Config: 1334581806
 Puppet: 2.7.12

You can also see the evaluation commands and changes being executed by adding the —evaltrace switch

1
sudo puppet agent --test --summarize --evaltrace

Modify Default OctoPress List Outdenting

| Comments

By default OctoPress outdents list items, both OL and UL. To correct this you can simply add the following to the sass/custom/_styles.scss

1
2
3
4
5
article {
  ol, ul {
    padding-left: 3em;
  }
}

Building and Siging Sun Java JDK With JPackage Modified

| Comments

In our environment we sign all RPMs that are in our local production repository. After building the RPMs from Sun from the rpm.bin file they post we were unable to sign the JDK RPM.

After a little research I found an article that shed some light on the issue. It turns out that Sun is building their RPMs with a VERY old version of RPM (3.0.6). This is due to the fact that 3.0.x is so long ago, and technical feature has been added to RPM and due to that, it won’t work properly.

Here is a more detailed answer

There is a deep design issue underlying this mess.

RPM has been mired between header+payload and header-only signatures for many
years now.

In order to preserve header+payload MD5 as a universal invariant independent of
what is implemented in rpm when resigning, the legacy header which is part
of the header+payload MD5 digest cannot be changed.

In order to support header-only signatures on an immutable region,
markers are added to the header to identify the immutable header-only region
blob that is signed.

The conclusion is that header-only signature/digest should not be attempted
when resigning legacy packages. Any other scheme will either add Yet Another
Package format special case, or otherwise change the invariant header+payload
MD5 digest.

And the right “fix” is to dump header+payload signatures entirely. There is a deep design issue underlying this mess.

RPM has been mired between header+payload and header-only signatures for many
years now.

In order to preserve header+payload MD5 as a universal invariant independent of
what is implemented in rpm when resigning, the legacy header which is part
of the header+payload MD5 digest cannot be changed.

In order to support header-only signatures on an immutable region,
markers are added to the header to identify the immutable header-only region
blob that is signed.

The conclusion is that header-only signature/digest should not be attempted
when resigning legacy packages. Any other scheme will either add Yet Another
Package format special case, or otherwise change the invariant header+payload
MD5 digest.

And the right “fix” is to dump header+payload signatures entirely.

There are other payload complications that need solving to preserve
header+paload md5 invariance (for true legacy compatibility) as well.
E.g. invariance assumes that zlib never changes what is written to
a resigned package for all rpm implementations.

I’d suggest that the one line patch to handle the region marker change
in the signature header, and living with the accurate (because legacy headers
are invariant all versions of rpm afaik) but mysterious (essential elements to
compute a header-only signature/digest are not present in the definition
of the header, perhaps something other than NOKEY to be returned)
Header V3 DSA signature: NOKEY, key ID 831ffbca
is the only sane path forward.

But feel free to do whatever you want, patches cheerfully accepted!

Above are the comments from Jeff Johnson in Red Hat’s Bugzilla #127113

To check which version of RPM was used to sign rpm;

1
2
rpm -q --qf '%{RPMVERSION}' -p jdk-1.6.0_18-fcs.x86_64.rpm
3.0.6

The fix ?

Resign the pkg with rpm 3.0.x which is Red Hat 6.2 which I don’t think anyone would see it as an answer

or

Rebuild the RPMs with a modified package. After some more research I stumbled across another article, that explains building the latest Sun Java 1.6u31 with a modified JPackage process.

I’ve created a streamlined/condensed article on building Java 1.6 u31 (This needs updated to a newer build).