Module therevmj/software 0.0.3
| Download |
|
Module description
The package providers in puppet can be cumbersome why you have to manage multiple platforms becuase package names are not consistent between providers and probably never will be. Additionally, on some platforms (solaris and opensolaris most notably) you end up using multiple package providers out of necessity. This makes writing puppet modules more painful because every time you want to include a a package, you have to figure out what package provider has the software you want (possibly more than one) and what the package name is. Let’s consider installing a apache. Here is the package name under some different os/provider combinations:
- Ubunty w/ apt: apache2
- Solaris w/ sun: SUNWapch2
- OpenSolaris w/ pkg: web/server/apache-22
- Solaris or OpenSolaris w/ blastwave: CSWapache2
- Solaris or OpenSolaris w/ sunfreeware: apache
To deal with this, you can write a manifest that understands all of the different naming conventions and will use the one that is appropriate to your platform. However, what happens when you want to remove the package? Now you need another manifest that will remove the package.
This modules makes all of this easier. To add a package such as apache, you simply say:
software { “apache2”: }
If you want to remove it, use:
software { “apache2”: ensure => “absent” }
It doesn’t matter what platform or package provider you are using, it works the same way everywhere.
Keep in mind this isn’t magic and this is a new project. I’ve only added the config manifests for a handful of packages and I’m not going to promise they all work out of the box. However, the config manifests are very simplistic and what I’ve provided should give you a clear example of how to configure create more of them. As you do, please contact me and I will add them into my repository so that others can benefit from your work as well.
Release notes for version 0.0.3
Modifed to function for package that do not have a config manifest associated with them. This allows you to use the ‘software{ “package”: }’ symantics for all packages. This way you can gain the benefit where it exists, and as additional config manifests are create, things will continue to work without further change.