In regard to: Re: [Puppet Users] Have Class Only Perform Actions When There...:
On Friday, October 26, 2012 2:31:56 PM UTC-4, Tim Mooney wrote:
In regard to: [Puppet Users] Have Class Only Perform Actions When There
Is...:
I would highly recommend you just package your custom python and install
it using a package management system, rather than doing what you're doing.
Depending on what host OS you're using, it's not too difficult, and it
works a lot better with puppet *and* you get all the benefits of having
the package installed through a more coherent means.
As you're discovering, these kind of exec chains, where the first part
of the chain involves temporary files, don't really fit into the puppet
paradigm very well. About the best you can do is something like
exec { '/usr/local/sbin/install-python-if-necessary.sh':
source => '
http://your_module/install-python-if-necessary.sh',
creates => '/your/python/lib/dir',
}
and then bury all the fetch/extract/configure/compile/install logic
in the shell script, which puppet will make certain is always present
on the system. It will only execute it if /your/python/lib/dir is not
present.
But if you're going to build fetch/extract/configure/compile/install logic
into a shell script, you're probably 85% of the way to packaging the
software appropriately anyway.
Interesting. It sounds like you're actually advocating _for_ the bash
script approach.
Absolutely not. I think the package management system is definitely the
way to go. If you're bound and determined to not do it that way, and
you want to avoid having the pre-cursor exec's fire in your
fetch/extract/compile chain, then the shell script is really your
best option.
Otherwise, the wget fetch will fire any time that
/tmp/Python-${version}.tgz is not present. That won't be present if
your /tmp cleaner gets rid of it. Ditto for the extract step.
I'm assuming that none of these systems are multi-user systems, where you
might have less-than-trustworthy people with local access on the system.
If that's not the case, I definitely wouldn't be having the first step
of a multi-exec chain depend on a file in /tmp.
I wanted to avoid package management systems only because
they are way more complicated than a basic install of python requires:
wget python.tgz
tar -xzvf python.tgz
cd python
./configure --prefix=/install/path
make
make test
make install
I wanted to make (I have made?) a simple "python" class that accepts a
python version number, downloads it, and runs those steps, irrespective of
the base Linux flavor. I don't know much of anything about deb or rpm files
other than that they are more complicated than that; and I don't want to
have to package up and maintain several different python versions for
several different package managers.
You don't have to create your package from whole cloth, though. You
download the source format for the package management system, extract
the recipe file, make a couple of changes for your local install, and
then build the package.
In the case of an RPM, that means starting with the source RPM (.srpm) for
the python that comes from your CentOS/RHEL/RHEL-derived vendor. You
would extract the "spec" file (the recipe), tweak the %_prefix, the
Version, and probably not much else.
If you're still against packaging it, there's external repos you might
consider, to get packages that someone else has created. That might not
meet your needs, though.
Ultimately, use puppet however it works best for your organization. Just
be advised that some things fit better into the puppet paradigm than
others.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
