Clarify the differences between ensure file and ensure directory
Evan Hisey
all new things first). Thsi tells me I need to correct some apparent
confusion in my head about ensure => file and ensure => directory and
how they place nice or not nice with recurse => true. Recurse is used
to copy a whole directory of file from the puppet fileserver to the
puppet client. The problem occurs when adding in the ensure resource.
Do you need ensure => directory to copy over an whole directory?
That seems to tell puppet to take total contorl over the directory and
set owner, mode, and group for everything in the directory whether
puppet moved it or not. I did not contect the fact that puppet only
handles resources it is told to with telling it to handle a directory
meant it would handle everything in the directory.
Can the same be done with ensure => file? If you can indeed move
a whole directory with ensure => file and recurse =>true will puppet
take control of the directories it crosses?
Evan
P.S. James, ordered my copy of Pulling Strings today. I suspect that
will be faster and safer than some of my experimenting :)
Luke Kanies
> Okay, I have happily hosed an entire /etc (this is why we test
> all new things first). Thsi tells me I need to correct some apparent
> confusion in my head about ensure => file and ensure => directory and
> how they place nice or not nice with recurse => true. Recurse is used
> to copy a whole directory of file from the puppet fileserver to the
> puppet client. The problem occurs when adding in the ensure resource.
Just don't do this. I have been trying to hammer out bugs in this for
a long time, but here's a simple rule: Don't ever specify 'ensure'
when you are using 'source' or 'recurse'.
If you're specifying a 'source', then you're relying on the remote
system to determine the value of 'ensure'. If you're specifying
'recurse', then you cannot possibly specify a valid value unless
you're expecting that everything is a directory.
--
Real freedom lies in wildness, not in civilization.
-- Charles Lindbergh
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Evan Hisey
>
> On Apr 4, 2008, at 12:22 PM, Evan Hisey wrote:
>
> > Okay, I have happily hosed an entire /etc (this is why we test
> > all new things first). Thsi tells me I need to correct some apparent
> > confusion in my head about ensure => file and ensure => directory and
> > how they place nice or not nice with recurse => true. Recurse is used
> > to copy a whole directory of file from the puppet fileserver to the
> > puppet client. The problem occurs when adding in the ensure resource.
>
> Just don't do this. I have been trying to hammer out bugs in this for
> a long time, but here's a simple rule: Don't ever specify 'ensure'
> when you are using 'source' or 'recurse'.
>
> If you're specifying a 'source', then you're relying on the remote
> system to determine the value of 'ensure'. If you're specifying
> 'recurse', then you cannot possibly specify a valid value unless
> you're expecting that everything is a directory.
>
Got this part. I am still having a problem with puppet trashing owner
and group setting on directories and and files that share the
directory and dir. tree that contains files and dir branches that
puppet is not handling. A short example of what I am dealing with ;
usr
`-- share
|-- applications
| `-- labview82.desktop
|-- applnk
| `-- Applications
| `-- LabVIEW.kdelnk
|-- config
| `-- kdeglobals
<snipped>
This the stuff that has to be moved in to /usr/share ( there are 10
more dir. of this mess). The class looks like this:
file{"/usr/share/":
owner => root,
group => root,
recurse => true,
source => "puppet://puppet/usr/share",
}
The problem is this then starts to run off and stomp around in /usr/share/doc.
Evan
Paul Lathrop
> Got this part. I am still having a problem with puppet trashing owner
> and group setting on directories and and files that share the
> directory and dir. tree that contains files and dir branches that
> puppet is not handling. A short example of what I am dealing with ;
>
> usr
> `-- share
> |-- applications
> | `-- labview82.desktop
> |-- applnk
> | `-- Applications
> | `-- LabVIEW.kdelnk
> |-- config
> | `-- kdeglobals
> <snipped>
>
> This the stuff that has to be moved in to /usr/share ( there are 10
> more dir. of this mess). The class looks like this:
> file{"/usr/share/":
> owner => root,
> group => root,
> recurse => true,
> source => "puppet://puppet/usr/share",
> }
>
> The problem is this then starts to run off and stomp around in /usr/share/doc.
Puppet is doing exactly what you told it to do. You are saying "make
sure that /usr/share/ is owned by root:root and apply this recursively
to everything you find under /usr/share/"
The best way I can think of to do what you want is to roll your own
package for this software to install it into the correct locations.
--Paul
Evan Hisey
> >
> > The problem is this then starts to run off and stomp around in /usr/share/doc.
>
> Puppet is doing exactly what you told it to do. You are saying "make
> sure that /usr/share/ is owned by root:root and apply this recursively
> to everything you find under /usr/share/"
>
> The best way I can think of to do what you want is to roll your own
> package for this software to install it into the correct locations.
>
> --Paul
Ugh, I was afraid of that. I had seen some information in the mailling
list that lead me to think puppet would only effect files under it's
direct control, thus I was hopping to get something like a basic cp
-rap ( which is what I was using in the old custom SCM setup). It
would be so much easier if Natist would just write a proper installer
for their software.
Evan
David Schmitt
Hash: SHA1
On Tuesday 08 April 2008, Evan Hisey wrote:
> On Mon, Apr 7, 2008 at 6:17 PM, Paul Lathrop <pa...@tertiusfamily.net> wrote:
> > > The problem is this then starts to run off and stomp around in
> > > /usr/share/doc.
> >
> > Puppet is doing exactly what you told it to do. You are saying "make
> > sure that /usr/share/ is owned by root:root and apply this recursively
> > to everything you find under /usr/share/"
> >
> > The best way I can think of to do what you want is to roll your own
> > package for this software to install it into the correct locations.
> >
> > --Paul
>
> Ugh, I was afraid of that. I had seen some information in the mailling
> list that lead me to think puppet would only effect files under it's
> direct control, thus I was hopping to get something like a basic cp
> -rap ( which is what I was using in the old custom SCM setup).
You can do cp -rap with puppet too, by using Exec directly. Of course, puppet
will not know about the copied files then.
You might want to look into ad-hoc packagemanagement like stow, which
automates basic packaging funtionality for unmanaged software.
> It
> would be so much easier if Natist would just write a proper installer
> for their software.
Judging from the quality of other "ISV"'s packaging, no.
Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH+wqj/Pp1N6Uzh0URAgJ6AJoDP0aL/KELYsoPCGfopNV6vTLjnwCgilUn
RpPxka+3vrZic/aJcYKDzmk=
=FPf/
-----END PGP SIGNATURE-----
Mike Renfro
> On Mon, Apr 7, 2008 at 6:17 PM, Paul Lathrop <pa...@tertiusfamily.net> wrote:
>> The best way I can think of to do what you want is to roll your own
>> package for this software to install it into the correct locations.
> Ugh, I was afraid of that.
If you've on a Debian-derived system, you might be able to use some of
the things I wrote up at
http://blogs.cae.tntech.edu/mwr/2007/05/28/making-debian-packages-from-commercial-software/
If not, then maybe you can use it as a starting point for whatever
package format you need. Eventually, I'll have to do something similar
for Solaris.
And if you decide to go with stow, then I've got something else useful
at
http://blogs.cae.tntech.edu/mwr/2008/02/01/the-autostow-is-dead-long-live-stowedpackage/
--
Mike Renfro / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University
Evan Hisey
> > Ugh, I was afraid of that.
>
> If you've on a Debian-derived system, you might be able to use some of
> the things I wrote up at
> http://blogs.cae.tntech.edu/mwr/2007/05/28/making-debian-packages-from-commercial-software/
>
> If not, then maybe you can use it as a starting point for whatever
> package format you need. Eventually, I'll have to do something similar
> for Solaris.
>
> And if you decide to go with stow, then I've got something else useful
> at
> http://blogs.cae.tntech.edu/mwr/2008/02/01/the-autostow-is-dead-long-live-stowedpackage/
>
You have some of the exact same pita software I am dealing with. If
you don't mind I'll contact you of list about your solutions to a few
of those apps.
Evan
Jean-Baptiste Quenot
>
> Just don't do this. I have been trying to hammer out bugs in this for
> a long time, but here's a simple rule: Don't ever specify 'ensure'
> when you are using 'source' or 'recurse'.
Hey Luke,
This is a pretty important bit of information. I removed all
ensure=>present in my configuration when source is specified, and it
works. And it might well get rid of some strange corruption (actually
emptying files) issues I had.
I tried to also remove ensure=>present when 'content' is specified, it
works but a warning is logged:
warning: //Node[default]/File[/etc/apt/apt.conf.d/aze]/checksum: File
/etc/apt/apt.conf.d/aze does not exist -- cannot checksum
notice: //Node[default]/File[/etc/apt/apt.conf.d/aze]/checksum:
defined 'checksum' as '{md5}2efe9a512bdb07557c8a916ac8b95675'
notice: //Node[default]/File[/etc/apt/apt.conf.d/aze]/content: created
file with contents {md5}2efe9a512bdb07557c8a916ac8b95675
If we can come up with a good explanation, it might be worth adding to
the documentation.
Cheers,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/blog/
Luke Kanies
Hrm, that shouldn't be a warning. I think it's only a warning because
I replaced some code with a new abstract class, and I didn't test that
particular integration.
Anyone feel like trying to fix it?
Either way, though, content should work fine with 'ensure', and is
probably recommended.
Source is *very* different from content -- it copies *all* of a file's
properties, whereas content just manages, um, the file's content.
--
Ours is the age that is proud of machines that think and suspicious of
men who try to. -- H. Mumford Jones
Evan Hisey
> Either way, though, content should work fine with 'ensure', and is
> probably recommended.
>
> Source is *very* different from content -- it copies *all* of a file's
> properties, whereas content just manages, um, the file's content.
>
> --
That probable should be obvious, but you know it did not even register
till you said that. This probable needs to also go in the docs on the
file type resource. This does provide a total unsecure solution to my
fiel copy problem.To bad files in the filesserver have to be set ot
either puppet.puppet or world readable for puppet to find them.
Otherwise this would eliminate so many headaches.
Evan
David Schmitt
Hash: SHA1
On Tuesday 08 April 2008, Luke Kanies wrote:
> Source is *very* different from content -- it copies *all* of a file's
> properties, whereas content just manages, um, the file's content.
This opens up the question, whether it wouldn't be more consistent then to
specify the source as argument to "ensure", like the symlink target.
Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH/F+J/Pp1N6Uzh0URAmHYAJ9r/ND5C/HQX8VzX1/zWhANzrTdewCePDFZ
Vb+6JjuxCDE0YBpkse1Takg=
=GB0+
-----END PGP SIGNATURE-----
Luke Kanies
> This opens up the question, whether it wouldn't be more consistent
> then to
> specify the source as argument to "ensure", like the symlink target.
Considering the problems we've had specifying the symlink target this
way (usability problems, I mean), I'd prefer not to do that.
Instead, Puppet should just throw an exception or something.
--
It is better to sleep on things beforehand than lie awake about them
afterward. -- Baltasar Gracian