Puppet users - Nov 2008 - onlyif functionality for the File type

i need to copy a file into a directory if that directory exists.

simple enough to instantiate the file type.. put this file there..

and if the path doesn''t exist the ensure fails.. but with an error.

it would be great if the File type supported an onlyif parameter
similar to Exec so that the copy would not be attempted if the target
directory did not exist ie.
onlyif => "test -d /my/path"

i thought i could find a way to use the require metaparameter by first
declaring the target directory:

file { "/my/path" : alias => target }
file { "/my/path/file" : ..etc.., require => File[target] }

but this just kicks out the same kind of error but on the first File
since i don''t want to explicitly create the directory (ensure =>
directory)

can anyone propose a solution for copying a file to a puppet client
system only if the target exists without generating errors ?

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Benjamin,

Why are you doing this? This kind of situation usually indicates a
need to adjust one''s mindset in order to work within the Puppet model
rather than fighting against it.

That said, I think you could do this a couple ways:

1) An Exec resource with ''onlyif'' and make the File resource
depend on it.
2) A custom fact that checks for the existence of the directory,
combined with ''if'' statements around the File resource.

Still, I think you''ll get more mileage out of telling us what problem
you are trying to solve so we can help you figure out the best way to
solve that problem within the Puppet model.

--Paul

On Fri, Nov 14, 2008 at 9:14 AM, benjamin <bendsu@gmail.com>
wrote:
>
> i need to copy a file into a directory if that directory exists.
>
> simple enough to instantiate the file type.. put this file there..
>
> and if the path doesn''t exist the ensure fails.. but with an
error.
>
> it would be great if the File type supported an onlyif parameter
> similar to Exec so that the copy would not be attempted if the target
> directory did not exist ie.
> onlyif => "test -d /my/path"
>
> i thought i could find a way to use the require metaparameter by first
> declaring the target directory:
>
> file { "/my/path" : alias => target }
> file { "/my/path/file" : ..etc.., require => File[target] }
>
> but this just kicks out the same kind of error but on the first File
> since i don''t want to explicitly create the directory (ensure
=>
> directory)
>
> can anyone propose a solution for copying a file to a puppet client
> system only if the target exists without generating errors ?
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

paul@tertiusfamily.net ("Paul Lathrop") writes:
> Why are you doing this? This kind of situation usually indicates a
> need to adjust one''s mindset in order to work within the Puppet
model
> rather than fighting against it.
>
> That said, I think you could do this a couple ways:
>
> 1) An Exec resource with ''onlyif'' and make the File
resource depend on it.
> 2) A custom fact that checks for the existence of the directory,
> combined with ''if'' statements around the File resource.
>
> Still, I think you''ll get more mileage out of telling us what
problem
> you are trying to solve so we can help you figure out the best way to
> solve that problem within the Puppet model.
I posted almost exactly the same problem a couple of days ago:

- you want to install via a custom installer an application, so you
  need to do the following:
  1. copy the file and installer over
  2. run installer and cleanup

Step 1 above needs to be done ONLY IF the installation has NOT been
completed. (check for some final installation file/directory)
Step 2 depends on step 1 so only takes place if the files are copied.

So as I suggested in my posting a few days ago an onlyif option would
be very nice. I phrased it in my posting as unless ".... some
condition", which is just the negative condition of the onlyif
condition.

My guess the poster wants to do the same thing.

Simon

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Nov 17, 2008 at 3:17 PM, Simon J Mudd <sjmudd@pobox.com>
wrote:
> paul@tertiusfamily.net ("Paul Lathrop") writes:
>> Still, I think you''ll get more mileage out of telling us what
problem
>> you are trying to solve so we can help you figure out the best way to
>> solve that problem within the Puppet model.
> I posted almost exactly the same problem a couple of days ago:
>
> - you want to install via a custom installer an application, so you
>  need to do the following:
>  1. copy the file and installer over
>  2. run installer and cleanup
Well, myself I''d package the application in the native package format,
but I''m a bit crazy.
> Step 1 above needs to be done ONLY IF the installation has NOT been
> completed. (check for some final installation file/directory)
> Step 2 depends on step 1 so only takes place if the files are copied.
In your situation, assuming the application was impossible to package
(anything that builds with Maven seems impossible to Debian package
for example) I''d implement this as an Exec; in my head we are trying
to model a series of actions, not a File here. So it would be a simple
script that did the work, with Exec to run it and a lovely onlyif
parameter.
> So as I suggested in my posting a few days ago an onlyif option would
> be very nice. I phrased it in my posting as unless ".... some
> condition", which is just the negative condition of the onlyif
> condition.
I can see why you''d want onlyif to be a metaparameter. I''m not
against it.
> My guess the poster wants to do the same thing.
Something about his post made you think he wants to install an
application using a custom installer? Or you think they''d like it if
''onlyif'' was available for File resources? I''m not
sure I follow.

--Paul

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

>> - you want to install via a custom installer an application, so you
>>  need to do the following:
>>  1. copy the file and installer over
>>  2. run installer and cleanup
>
>Well, myself I''d package the application in the native package
format,
>but I''m a bit crazy.
Take another example, then.

I''ve got Glassfish.  I want to configure an application domain.  As
part
of the configuration, I want to configure a JDBC connection.

Not being totally mad, I want to not leave the database password lying
around in plain text, so I use Glassfish''s handy feature of
"password
aliases".  Unfortunately, these need a seed file, a plaintext file that
looks like:

    AS_ADMIN_ALIASPASSWORD=my_secret_password

So, I copy that over from my puppet server:

    file { 
	"$glassfish::GF/jdbc_secret_password.txt":
	    source => ...
    }

And then I run asadmin to create the alias:

    exec {
	"$glassfish::GF/bin/asadmin create-password-alias 
	    --passwordfile $glassfish::GF/jdbc_secret_password.txt 
		jdbc_secret_password":
	    alias => "create_jdbc_password_alias",
	    unless => "$glassfish::GF/bin/asadmin list-password-aliases | 
		grep -q jdbc_secret_password",
	    require => [File["$glassfish::GF/jdbc_secret_password.txt"],
			Exec["gf_create_instance"]]
    }

Unfortunately, this leaves the seed file, required only for the command
to run, lying around on disk.  Now, I can protect the file with mode
0400, or I can tidy it with a dependency on the exec command, but what
I really want is something like "refreshonly" for files; only copy the
file over if something is being evaluated that explicitly requires it.

Otherwise, I''ll get the file appearing and disappearing again, which is
rather a waste of time.

    -- michael.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Tue, Nov 18, 2008 at 5:22 PM,  <michael@livia.co.nz>
wrote:
>
>>> - you want to install via a custom installer an application, so you
>>>  need to do the following:
>>>  1. copy the file and installer over
>>>  2. run installer and cleanup
>>
>>Well, myself I''d package the application in the native package
format,
>>but I''m a bit crazy.
>
> Take another example, then.
>
> I''ve got Glassfish.  I want to configure an application domain. 
As part
> of the configuration, I want to configure a JDBC connection.
>
> Not being totally mad, I want to not leave the database password lying
> around in plain text, so I use Glassfish''s handy feature of
"password
> aliases".  Unfortunately, these need a seed file, a plaintext file
that
> looks like:
>
>    AS_ADMIN_ALIASPASSWORD=my_secret_password
>
> So, I copy that over from my puppet server:
>
>    file {
>        "$glassfish::GF/jdbc_secret_password.txt":
>            source => ...
>    }
>
> And then I run asadmin to create the alias:
>
>    exec {
>        "$glassfish::GF/bin/asadmin create-password-alias
>            --passwordfile $glassfish::GF/jdbc_secret_password.txt
>                jdbc_secret_password":
>            alias => "create_jdbc_password_alias",
>            unless => "$glassfish::GF/bin/asadmin
list-password-aliases |
>                grep -q jdbc_secret_password",
>            require =>
[File["$glassfish::GF/jdbc_secret_password.txt"],
>                        Exec["gf_create_instance"]]
>    }
>
> Unfortunately, this leaves the seed file, required only for the command
> to run, lying around on disk.  Now, I can protect the file with mode
> 0400, or I can tidy it with a dependency on the exec command, but what
> I really want is something like "refreshonly" for files; only
copy the
> file over if something is being evaluated that explicitly requires it.
>
> Otherwise, I''ll get the file appearing and disappearing again,
which is
> rather a waste of time.
>
>    -- michael.
Michael,

I''m not sure you understand that I''m not arguing *against*
''onlyif'' as
a metaparameter. I''m focusing on how to do what you want, now, with
Puppet as it is today. I do think it is slightly odd the way people
choose to model things, but flexibility is one of Puppet''s strong
points.

Why not wrap the process of fetching the seed file, generating the
"password alias", and then securely deleting the seed file into a
script, which you would then put in your exec with an appropriate
''onlyif''?

--Paul

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

"Paul Lathrop" writes:
>> Unfortunately, this leaves the seed file, required only for the command
>> to run, lying around on disk.  Now, I can protect the file with mode
>> 0400, or I can tidy it with a dependency on the exec command, but what
>> I really want is something like "refreshonly" for files; only
copy the
>> file over if something is being evaluated that explicitly requires it.
Note that I haven''t actually tried the "tidy" approach, and
it may meet
my needs.  Just before we go further.  I only thought of it as I was
writing my previous email.
>I''m not sure you understand that I''m not arguing *against*
''onlyif'' as
>a metaparameter. I''m focusing on how to do what you want, now, with
>Puppet as it is today. I do think it is slightly odd the way people
>choose to model things, but flexibility is one of Puppet''s strong
>points.
:)  Yes, understood.
>Why not wrap the process of fetching the seed file, generating the
>"password alias", and then securely deleting the seed file into a
>script, which you would then put in your exec with an appropriate
>''onlyif''?
That''s an excellent question.

I think the reason I don''t want to do that is twofold:

    1. That Puppet gives me idempotency for free; if my script gets
    interrupted in the middle, I have to have recovery logic (not
    complicated in this case, admittedly, but I believe still obscures
    what I''m trying to do for maintenance coders, and sets a
"bad"
    precedent).  There''s a natural barrier to going "outside"
the tool,
    if you like.

    2. Puppet has secure file transfer, and setting up a secure rsync
    between puppet server and client hasn''t been required so far.
    This objection could be easily overcome if there was a way of
    accessing Puppet file transfer from "outside" Puppet.  Is there?

For another example of where this pattern of behaviour
(dealing with small files containing sensitive data, where
you don''t want to inline the data into your manifest), see
http://reductivelabs.com/trac/puppet/wiki/Recipes/FirmwarePassword.

    -- michael.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

How about (for this specific situation) leaving an empty file? You could do:

file { "/tmp/secret":
  replace => false,
}

exec { "do-the-install":
  command => do the install,
  onlyif => only do the install if some condition met or unmet,
  notify => Exec["cleanup"],
  require => File["/tmp/secret"],
}

exec { "cleanup":
  command => "echo '''' > /tmp/secret",
  refreshonly => true,
}


Thijs

On Wed, Nov 19, 2008 at 2:51 AM,  <michael@livia.co.nz>
wrote:
>
> "Paul Lathrop" writes:
>>> Unfortunately, this leaves the seed file, required only for the
command
>>> to run, lying around on disk.  Now, I can protect the file with
mode
>>> 0400, or I can tidy it with a dependency on the exec command, but
what
>>> I really want is something like "refreshonly" for files;
only copy the
>>> file over if something is being evaluated that explicitly requires
it.
>
> Note that I haven''t actually tried the "tidy" approach,
and it may meet
> my needs.  Just before we go further.  I only thought of it as I was
> writing my previous email.
>
>>I''m not sure you understand that I''m not arguing
*against* ''onlyif'' as
>>a metaparameter. I''m focusing on how to do what you want, now,
with
>>Puppet as it is today. I do think it is slightly odd the way people
>>choose to model things, but flexibility is one of Puppet''s
strong
>>points.
>
> :)  Yes, understood.
>
>>Why not wrap the process of fetching the seed file, generating the
>>"password alias", and then securely deleting the seed file
into a
>>script, which you would then put in your exec with an appropriate
>>''onlyif''?
>
> That''s an excellent question.
>
> I think the reason I don''t want to do that is twofold:
>
>    1. That Puppet gives me idempotency for free; if my script gets
>    interrupted in the middle, I have to have recovery logic (not
>    complicated in this case, admittedly, but I believe still obscures
>    what I''m trying to do for maintenance coders, and sets a
"bad"
>    precedent).  There''s a natural barrier to going
"outside" the tool,
>    if you like.
>
>    2. Puppet has secure file transfer, and setting up a secure rsync
>    between puppet server and client hasn''t been required so far.
>    This objection could be easily overcome if there was a way of
>    accessing Puppet file transfer from "outside" Puppet.  Is
there?
>
> For another example of where this pattern of behaviour
> (dealing with small files containing sensitive data, where
> you don''t want to inline the data into your manifest), see
> http://reductivelabs.com/trac/puppet/wiki/Recipes/FirmwarePassword.
>
>    -- michael.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> Why are you doing this? This kind of situation usually indicates a
> need to adjust one''s mindset in order to work within the Puppet
model
> rather than fighting against it.
you caught me. i''m writing .ssh directory and authorized_keys files
for a few users to multiple servers. i guess i would use the
ssh_authorized_key type if i were drinking the puppet coolaid. (trying
to !). but i''m hesitant to do this because all user access is auth
against AD via pam and krb5. hence user home folders will only be
present on the servers the user accesses. since a user directory is
either present or not present without puppet server involvement there
isn''t anything to tie to.

back from a week vacation last week. great to find a healthy
discussion happening here.
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Nov 26, 2008 at 12:37 PM, benjamin <bendsu@gmail.com>
wrote:
>
>> Why are you doing this? This kind of situation usually indicates a
>> need to adjust one''s mindset in order to work within the
Puppet model
>> rather than fighting against it.
>
> you caught me. i''m writing .ssh directory and authorized_keys
files
> for a few users to multiple servers. i guess i would use the
> ssh_authorized_key type if i were drinking the puppet coolaid. (trying
> to !). but i''m hesitant to do this because all user access is auth
> against AD via pam and krb5. hence user home folders will only be
> present on the servers the user accesses. since a user directory is
> either present or not present without puppet server involvement there
> isn''t anything to tie to.
Oh! This is a fun one!

Do the home directories get created when the user first logs in, then?
That''s actually how we do it. We then use pam to run a script at logon
that populates their authorized_keys file from LDAP. This works
reasonably well. Here are a couple other approaches:

* If you are tolerant of seeing "errors" in your Puppet logs, you
could go ahead and define the keys; Puppet won''t put them in place if
the directories aren''t there. I don''t advocate this approach,
but it
is one I''ve seen used.

* If the users are *allowed* to log in to the servers in question, and
the directory would be created on first login, go ahead an
pre-populate it with Puppet instead. It doesn''t cause any harm and
saves you some headaches since you won''t be fighting your tools.
Seriously, what are you trying to save here?

* This is only a vaguely formed idea, but you could populate a set of
<username>_homedir_exists custom facts that basically check if the
home directory exists. Then you could declare all of these
ssh_authorized_key resources dependent on those facts... I haven''t
totally thought that through, but it could work.

--Paul

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

2008/11/26 benjamin <bendsu@gmail.com>:
> you caught me. i''m writing .ssh directory and authorized_keys
files
> for a few users to multiple servers.
Another option, which may be valid, is that SSH supports moving the
user''s SSH authorized_keys files out of the user''s home
directories.
If you''re already managing the SSH daemon with puppet this is pretty
simple to do.

You can set something like:
AuthorizedKeysFile /etc/ssh/user-authorized-keys/%u

See the ''AuthorizedKeysFile'' parameter in the sshd_config(5)
manpage
for more information.

- A.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> Do the home directories get created when the user first logs in, then?
thats right. pam_mkhomedir.so
> * If you are tolerant of seeing "errors" in your Puppet logs, you
> could go ahead and define the keys; Puppet won''t put them in place
if
> the directories aren''t there. I don''t advocate this
approach, but it
> is one I''ve seen used.
this has been the state of things for a while. error spam has gotten a
little out of hand.
> * If the users are *allowed* to log in to the servers in question, and
> the directory would be created on first login, go ahead an
> pre-populate it with Puppet instead. It doesn''t cause any harm and
> saves you some headaches since you won''t be fighting your tools.
> Seriously, what are you trying to save here?
i''ll think about this approach.
> * This is only a vaguely formed idea, but you could populate a set of
> <username>_homedir_exists custom facts that basically check if the
> home directory exists. Then you could declare all of these
> ssh_authorized_key resources dependent on those facts... I haven''t
> totally thought that through, but it could work.
don''t know how i would make a File depend on a fact. think i''d
end up
approaching a problem similar to the one i''m trying to solve.
> --Paul
> Another option, which may be valid, is that SSH supports moving the
> user''s SSH authorized_keys files out of the user''s home
directories.
> If you''re already managing the SSH daemon with puppet this is
pretty
> simple to do.
this is a really good idea !
> - A.
benjamin
- wishing File supported refresh
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---