What I am looking for is something like the exec/onlyif parameter that I can use to conditionally replace a file.
Any thoughts ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
There is more than one way to do this. What kind of conditions woud you
be testing for?
--
Bruce
A problem shared brings the consolation that someone else is now
feeling as miserable as you.
Thanks for responding. Nice tag line.
OK, more details:
In my users class, I want to be able to push out custom dot-files when the user account is first created.
Unfortunately, if one sets user:managehome => true, the dotfiles are created by default and the custom file is not pushed out unless you set file:replace => yes.
The downside of this is that the dot-files would then have to be managed from the puppet-master, which, in this case, I would prefer to avoid. I want to push the custom dot-files out the first time only.
My though was to place a flag line in the file to search for ("Created by Puppet") and then replace the file if I do not find my flag line.
Does that clarify ?
You realise that this is being done by Unix (Linux?), not Puppet? If
you use puppet to replace the system's default dotfiles (on Linux,
they'll be in /etc/skel) *before* creating any users, you'll get
precisely what you want. Just set up the users so that they depend on
the file resources which place the right files in /etc/skel and this
will guarantee the files are in there before the users are created
(assuming they didn't exist already). The Unix user creation tools
will copy the /etc/skel files into the right place when Puppet invokes
them.
This only fails if you need different dotfiles (differing by content
and/or name) for different users. If you don't, simple win
--
Bruce
Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.
Thanks for responding.
I agree, globally customizing the defaults is one way to go, but I am shooting for the second option.
If you do not want the gobal defaults copied why are you using
managehome => true?
If you really have to go this awkward path you can create a conditional
exec resoure that removes the dotfiles if they are equal to the skel files
so puppet will copy the correct files again. (fileresources with replace
=> false)
A second solution is to create a custom fact that tells you if puppet
should manage the dotfiles and wrap your fileresources in an if-clause
(fileresources with replace => true)
-Stefan
>> Thanks for responding.
>> I agree, globally customizing the defaults is one way to go, but I am shooting for the second option.
>>
>
> If you do not want the gobal defaults copied why are you using
> managehome => true?
>
> If you really have to go this awkward path you can create a conditional
> exec resoure that removes the dotfiles if they are equal to the skel files
> so puppet will copy the correct files again. (fileresources with replace
> => false)
>
> A second solution is to create a custom fact that tells you if puppet
> should manage the dotfiles and wrap your fileresources in an if-clause
> (fileresources with replace => true)
>
> -Stefan
We have another usecase for conditional file replacement:
if a developer would like to forbid any puppet changes on a certain file he creates a flagfile $name.nopuppet
instead of normal file resource we use a parameterized define:
define configfile ($source) {
exec { "check_${name}":
command => '/usr/bin/true',
unless => "/usr/bin/test -e ${name}.nopuppet",
}
file { "$name":
source => $source,
requires => Exec["check_${name}"],
}
}
we then use this define on certain files.
e.g.
configfile { "/etc/apache2/apache2.conf": source => "puppet:///modules/apache2/apache2.conf" }
This path is going to cause you nothing but pain. Instead of allowing
conditional opt-out based on the machine, you should rather prefer to
have the central authority own that - if the developer needs their
machine to have a custom HTTP setup, don't try and manage it on that
machine. Record that fact in your central configuration system.
If you really need that control to be allowed on a per-user or
per-machine basis, invest in an ENC and provide an interface to that
which allows the developers to exclude their machine from this
management.
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
On 2011-11-28 16:01, Dan White wrote:
> In my users class, I want to be able to push out custom dot-files when
> the user account is first created.
> Unfortunately, if one sets user:managehome => true, the dotfiles are
> created by default and the custom file is not pushed out unless you set
> file:replace => yes.
>
> The downside of this is that the dot-files would then have to be managed
> from the puppet-master, which, in this case, I would prefer to avoid. I
> want to push the custom dot-files out the first time only.
(Late answer, I know, but anyway.)
So, make useradd(8) not copy out those files you want to manage. Assuming
you want to give your users a specific .emacs file, something like this:
class no_skel_dot_emacs
{
file {
'/etc/skel/.emacs':
ensure => absent,
# We want this to happen *after* the /etc/skel/.emacs file
# is installed by the Emacs package...
require => Package['emacs-common'];
}
}
define myuser($uid, $gecos)
{
include no_skel_dot_emacs
user {
$name:
ensure => present, uid => $uid, $comment => $gecos,
managehome => true,
require => Class[no_skel_dot_emacs];
}
file {
"/home/${name}/.emacs":
ensure => file, replace => no,
content => template('.../dot-emacs.erb'),
owner => $name, group => $name, mode => 0644;
}
}
If /etc/skel/.emacs doesn't exist when useradd is run, it won't be copied
out to the user's home directory, and you won't have a conflict.
/Bellman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk8EdTEACgkQDGpP8Cv3aqLCJQCfVwdX2zSzhaIxschELYv7xzY8
MpsAoIIbhO60x+AuZdats8cFIKlOdR8S
=5COp
-----END PGP SIGNATURE-----
A recursive file resource is "less specific" than a file resource
managing an individual file.
If you install those two configuration files with `file {
".../no_replace1.cfg": ensure => present, ... }`, Puppet will put them
in place if they are missing, but otherwise ignore their content. It
will also prevent the recurse from overwriting them.
--
Daniel Pittman