On 03/12/2010 11:37 PM, Stephen John Smoogen wrote:
On Fri, Mar 12, 2010 at 2:47 PM, Dennis
> I just installed a new machine in our infrastructure but I can't get the
> puppet package to work. I see it has recently been updated to 0.25.4 while
> the previous version i EPEL was 0.24.8. The other machines that are still
> running 0.24.8 are all doing fine but on the one with the new puppet version
> I just get a "Reopening log files" in the syslog. On the other machines
> is followed by "Starting Puppet client version 0.24.8" but on the new one
> nothing happens.
A bad part of this our fault. We need to send out FLAG days on certain
packages (puppet being one of them) when an update goes into testing
and when it goes into production.
A second bad part is we do not keep many old versions of our packages
around due to limits on resources on our part.
I don't know about many versions but it would be good to have at least the
previous version around for a potential rollback.
Part of this is due to how puppet upstream works. Puppet only gives
partial guarantee for backwards compatibility between 'major' version
upgrades (and only on the server), and the puppet recommended way of
upgrades is always:
Upgrade the server first, Upgrade the clients next.
Should this 'major' update have been put into EPEL at all if there are
known backwards compatibility issues? That seems to be quite a risky policy
for a distribution which most people expect to be mostly free from any
surprises (as opposed to the faster moving desktop distros like Fedora).
Would a backup of /var/lib/puppet and /etc/puppet be sufficient when I
attempt to update the server? I manage 50+ machines with puppet and it
would be extremely painful to not be able to go back to a known working
setup if 0.25.4 shows problems.