Puppet: maintaining apt sources.list

aptpuppet

I'm using puppet to maintain a growing pile of debian machines. These will be maintained from their initialization onwards. This means that one step will be setting the apt 'sources.list' file and then updating it.

There are other modules that rely on this list being up to date and will fail if apt-get update hasn't been called. What I'm wondering is should I introduce some sort of ordering process (using stages or similar) to ensure that the package list is updated before attempting to install apps or just assume that it will likely fail on the first run but work on subsequent runs once the list is updated?

The ethos of puppet seems to be declaring a 'final state' rather than a process. This leads me to believe that letting the errors occur is probably the way to go.

Best Answer

You can use an exec resource with refreshonly => true that gets notified when the sources.list file changes. And have the class containing both the file management resource and the exec resource be a require from the package resources that need them.

The way I'd recommend approaching this in a simpler way would be to manage the sources through the apt::source resource type in the apt module from Puppet Labs, which handles the update as well.

Related Solutions

Debian – apt sources.list ssh:// with custom port

I'd have expected the port setting to work — the behavior you describe sounds like a bug. But you don't need apt's cooperation here, you can use .ssh/config instead. Create an alias for the apt repository machine and put the options you want:

Host my-apt-repository
HostName 1.1.1.1
User user
Port 12345
IdentityFile /path/to/private_key.id_rsa

Depending on your method for gaining root permission, you might need to put this in /root/.ssh/config as well as ~/.ssh/config.

Specifying prerequisites for Puppet custom facts

As far as I know, you can't. Either let it fail, or detect and fail gracefully. I have a number of plugins that only work on Debian that fail on Red Hat without consequence.

Also, please note that it is IMPOSSIBLE to have a fact evaluated AFTER some configuration went in. The architecture just doesn't support it:

Client                               Server
Compute facts
Ask for catalog passing facts =>     Receive Catalog request
                                     Compute catalog using facts
                              <=     Return Catalog
Based on the dependency tree,
  For each configuration with satisfied dependencies
    Apply configuration
    Mark (or not) dependency as satisfied
Send report, if configured so

So, you see, the configuration is only applied long, long after the facts were processed, and there's no way of going back. What may happen is that the next run will now be able to generate that fact.

See also the trick used by the Common module to handle the lack of lsbrelease on Debian without producing fatal errors.

Best Answer

Related Solutions

Debian – apt sources.list ssh:// with custom port

Specifying prerequisites for Puppet custom facts

Related Topic