headers
Luke Kanies | 27 Aug 2006 20:17
Gravatar

Re: "Overruling" files from different darfts

On Aug 27, 2006, at 8:56 AM, Thorsten Sandfuchs wrote:

> hio,
> I'm trying to build a "master"-directory (general) with some base- 
> files to
> spread, and a host/class-based directory-structure to override the  
> defaults,
> if necessary. If a file only is present in the general-section, it  
> shouldn't
> harm the setup, if it's only present in the host/class-section, it  
> should work
> and if present in both, all of them, I would like to use the  
> "latest" line, in
> the .pp-file as the valid one.

Puppet is not very good at doing this style of full-directory  
overlay, and it's somewhat intentional.  Its development is much more  
focused on managing elements, rather than whole files -- for  
instance, for apt sources I would specify each source which would  
then generate the file, rather than specifying the whole file.

I have done what I could to make some aspects of file-based  
management possible, but I don't think you'll ever get the behaviour  
you want out of doing full directory overlays like it looks like  
you're trying to do.  In fact, Puppet's parser specifically forbids  
the duplication you've got in your example -- you can't have two  
objects named '/etc', because that is considered a conflict that  
Puppet doesn't know how to resolve.

You can specify multiple file sources for individual file, and the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Kanies | 27 Aug 2006 20:21
Gravatar

Re: preseeding files only on reinstall

On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote:

> hio,
> me again :)
>
> In Debian, there is a mechanism to preseed debconf (configuration- 
> database for
> the system) with decisions, before installing a package. Debconf  
> mussn't ask
> the user then. I wrote this pp for preseeding-support:
[snip]

Very cool.  Seems like that's something that should be supported  
within Puppet's Apt support.

> and it works like a charm. The algorithm fetches the files, I like  
> to preseed
> from my server and fills the database, after a
>
>         preseed { ldap-preseed:
>                 file => "ldap",
>                 classname => ldap
>         }
>
> Now I can install a "package" as desired. Buf if the package is  
> installed, the
> preseeding never stopps... It preseeds the information on every  
> puppet-run...
>
> Is there a way to only trigger the "preseed" if the package is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kostas Georgiou | 27 Aug 2006 21:36
Picon
Gravatar

Re: "Overruling" files from different darfts

On Sun, Aug 27, 2006 at 05:56:31PM +0200, Thorsten Sandfuchs wrote:

> hio,
> I'm trying to build a "master"-directory (general) with some base-files to
> spread, and a host/class-based directory-structure to override the defaults,
> if necessary. If a file only is present in the general-section, it shouldn't
> harm the setup, if it's only present in the host/class-section, it should work
> and if present in both, all of them, I would like to use the "latest" line, in
> the .pp-file as the valid one.

It might not be exactly what you want but I wonder if the new %h,%H functionality
in the fileserver can be extended to do something close to this.

A change to the fileserver to return [export]/file when [export]/hostname/file
doesn't exist will allow you to override files without touching any of the manifests.

Kostas
Permalink | Reply | 1 comment |
headers
Luke Kanies | 27 Aug 2006 22:06
Gravatar

Re: "Overruling" files from different darfts

On Aug 27, 2006, at 12:36 PM, Kostas Georgiou wrote:
>
> It might not be exactly what you want but I wonder if the new %h,%H  
> functionality
> in the fileserver can be extended to do something close to this.
>
> A change to the fileserver to return [export]/file when [export]/ 
> hostname/file
> doesn't exist will allow you to override files without touching any  
> of the manifests.

I've also been thinking about extending Puppet a little bit along the  
lines of bcfg2, even though I think it's going a bit in the wrong  
direction.

Bcfg2 works by creating file generators; the simplest one just copies  
a whole file, but you can also write custom generators that create a  
file based on arbitrary mechanisms.  It'd be easy to add something  
like Puppet's templating support to do something similar here -- you  
specify a generator, instead of a template.

I'm just starting to think about this, though, and like I said I  
think it's the wrong direction, because only the server knows how  
these things can work -- you couldn't do any introspection on the  
client, and you can't see that modeling through the XMLRPC interface.

It might, however, make getting the right file to the right host a  
bit easier, in those cases where you don't want to go through the  
effort of modeling.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Palmer | 27 Aug 2006 23:14
Favicon
Gravatar

Re: preseeding files only on reinstall

On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote:
> On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote:
> > me again :)
> >
> > In Debian, there is a mechanism to preseed debconf (configuration- 
> > database for
> > the system) with decisions, before installing a package. Debconf  
> > mussn't ask
> > the user then. I wrote this pp for preseeding-support:
> [snip]
> 
> Very cool.  Seems like that's something that should be supported  
> within Puppet's Apt support.

Isn't there a bug in the Trac for that already?

> > Is there a way to only trigger the "preseed" if the package is
> > upgraded/installed?
> 
> Hmm; this is the first time I know of that someone has had to run a  
> command *before* an object gets changed, but I can see how it might  
> be necessary in more cases than this.  At this point, there's no way  
> to do this, but I think it would be great to find a way.

For myself, I've never been really comfortable with the term 'subscribe' for
"tell me when this other object changes" -- although it describes the
operation well enough once you know what you're doing, it doesn't seem at
all obvious (and was one of my big mental hurdles when I was starting with
Puppet).  It seems to me like it would nice if you could specify pre/post
actions, like so:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Palmer | 27 Aug 2006 23:00
Favicon
Gravatar

Re: preseeding files only on reinstall

On Sun, Aug 27, 2006 at 06:55:14PM +0200, Thorsten Sandfuchs wrote:
> --------
> define preseed (file, classname, section = "classes"){
>         file {  
>                 "/tmp/$file":
>                     mode => 600,
>                     source =>
> "puppet://$servername/config/$section/$classname/preseed/$file"
>         }
>         exec {  
>                 ["cat /tmp/$file | debconf-set-selections",
> 		"if [ -f /tmp/$file ]; then rm /tmp/$file; fi"]:
>                 cwd => "/",
>                 path => "/usr/bin/:/usr/sbin/:/bin"
>         }
> }

I'd be inclined to split that exec into multiple parts, and put a "require =>
file["/tmp/$file"]" on the first one and a "require => exec["first-one"]" on
the second.

> Now I can install a "package" as desired. Buf if the package is installed, the
> preseeding never stopps... It preseeds the information on every puppet-run... 
> 
> Is there a way to only trigger the "preseed" if the package is
> upgraded/installed?

Not that I can think of at the moment, although you could perhaps put an
unless into the important exec object that checks whether a relevant config
item is present in the Debconf database, but that would require you to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Palmer | 28 Aug 2006 02:17
Favicon
Gravatar

Re: preseeding files only on reinstall

On Mon, Aug 28, 2006 at 01:37:09AM +0200, Thorsten Sandfuchs wrote:
> On Mon, Aug 28, 2006 at 07:14:08AM +1000, Matthew Palmer wrote:
> > On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote:
> > > On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote:
> > I think keeping the refreshonly semantics is nice, although I wonder if, in
> > the wider context, 'refreshonly' is the best term for it.
> 
> well if it basically just "restarts" why don't name it "restartonly" or are
> there other situation, I can't think of right now, where there actually is a
> "refresh"-action.

The semantics of "refreshonly" aren't limited to restarting services -- I
use it for rebuilding hash tables from (eg) aliases and access maps in
Postfix.

- Matt
Permalink | Reply | 0 comments |
headers
Luke Kanies | 28 Aug 2006 07:41
Gravatar

Templates and arrays

I'm in the process of documenting templates right now, and I figured  
I should see what happens when you use them with arrays:

$ cat ~/bin/test.pp
$values = [this, is, an, array, of, values]

$content = template("/tmp/templates/testing.erb")

file { "/tmp/temtest": content => $content }

$ cat /tmp/templates/testing.erb
<% values.each do |val| %>
     I got <%= val %> from you!
<% end %>

$ puppet -v ~/bin/test.pp
notice: //file=/tmp/temtest/content: synced

$ cat /tmp/temtest

     I got this from you!

     I got is from you!

     I got an from you!

     I got array from you!

     I got of from you!
(Continue reading)

Permalink | Reply | 10 comments |
headers
Luke Kanies | 28 Aug 2006 07:45
Gravatar

Re: "Overruling" files from different darfts

On Aug 27, 2006, at 4:19 PM, Thorsten Sandfuchs wrote:
> I couldn't find a propper way to do this, yet.
>
> With the "content"-directive, I can't "add" text, with the "source"- 
> directive
> neither, and I think "just adding" lines, can leed to serious  
> problems with
> some files, which are more complex, than a sources.list. :)

Here's a relatively simple custom definition I wrote for managing  
mail aliases:

define alias(ensure, file = "/etc/postfix/aliases") {
     $pattern = "'^$name'"
     case $ensure {
         absent: {
             exec { "rm-alias-$name":
                 command => "/usr/bin/sed -i -e '/^$name/d' $file",
                 onlyif => "/usr/bin/grep $pattern $file"
             }
         }
         default: {
             $line = "$name: $ensure"
             exec { "add-alias-$name":
                 command => "/bin/echo '$line' >> $file",
                 unless => "/usr/bin/grep $pattern $file"
             }
             exec { "fix-alias-$name":
                 command => "/usr/bin/sed -i -e 's/^$name:..*\$/ 
$line/' $file",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Kanies | 28 Aug 2006 09:03
Gravatar

Provider documentation

One of the *big* benefits of providers is that it is now easy to  
document the different backends available to you.  Puppet will  
automatically collect all of the docs for your providers and stick  
them in the autogenerated docs page.  For instance, check out the  
package docs:

http://reductivelabs.com/projects/puppet/documentation/ 
typedocs.html#package

I'm also adding what the providers know about required binaries, so  
that should make things a bit clearer.  Not all of the providers are  
as clear as they could be on what binaries are required, and binaries  
will sometimes be unqualified when the docs are generated, but it's a  
good start, anyway.

--

-- 
Luke Kanies
http://madstop.com | http://reductivelabs.com | 615-594-8199
Permalink | Reply | 0 comments |

Gmane