Howdy,
Found out about this project while looking for via ONLamp''s FreeBSD
build system article. After finding cfengine a tad arcane, this project
seems like a good fit for my setup. I''m still at the tinkering phase,
but I envision this thing bootstrapping and maintaining several FreeBSD
installs which have different CPU''s and packages.
The Good News:
I''ve written the required ingredients for a FreeBSD port, both for
puppet (0.20.1) and facter (1.3.5). I guessed the port category to be
"sysutils" and "ruby" for both, but "net-mgmt"
might be a good one for
puppet instead of sysutils.
While my ports work fine (for me), I haven''t pushed them up to the
FreeBSD guys yet. I''d like it to install the puppet ./examples to the
right place and maybe modify some rc.<*> first. Plus if a new version
is coming out, I''ll get it to use that before releasing the port...
Bad News:
----- Client Error ------
tester# puppetd --test --server puppet
err: Could not find type "/etc/profile" in file
/etc/puppet/manifests/classes/base.pp at line 6
------ The Puppetmaster: ./classes/base.pp -----
class bash {
package { bash:
source =>
"/usr/ports/packages/i386/All/bash-3.1.17.tbz",
ensure => installed,
subscribe =>
[''/etc/profile'',''/etc/profile.d/'',''/etc/bash/'']
}
remotefile{ "/etc/profile":
mode => 664,
source => "apps/bash/etc/profile"
}
remotefile { "/etc/profile.d/":
mode => 664,
source => "apps/bash/etc/profile.d/"
}
remotefile { "/etc/bash/":
mode => 664,
source => "apps/bash/etc/bash/"
}
}
------ The Puppetmaster: ./functions.pp -----
define remotefile(
$owner = root,
$server = puppet,
$group = wheel,
$mode = 644,
$source,
$backup = false,
$recurse = true) {
file {
$name:
mode => $mode,
owner => $owner,
group => $group,
backup => $backup,
source => "puppet://$server/configs/$source"
}
}
Any ideas on what I''m missing?
Is there better way to handle a list of files and "bind" them to a
package (in this case, "bash")? Is there a way to make my package
definitions less ghetto and hardcoded, say wiring in a higher level
package tool like portupgrade that doesn''t seem to care about package
vs
port (and than forcing an install of that package for any real work)?
...Still learning, so forgive me if these questions seem simple. If
I''ve miss-RTFM, let me know where to look :-)
Thanks!!!
Notes:
- FreeBSD 6.1-RELEASE FreeBSD 6.1-RELEASE #0
- ruby 1.8.5 (2006-08-25) [i386-freebsd6]
- puppet 0.20.1
--
Cory R. King
XLAN, Inc.
On Dec 13, 2006, at 12:25 PM, Cory R. King wrote:> Howdy, > > Found out about this project while looking for via ONLamp''s FreeBSD > build system article. After finding cfengine a tad arcane, this > project > seems like a good fit for my setup. I''m still at the tinkering phase, > but I envision this thing bootstrapping and maintaining several > FreeBSD > installs which have different CPU''s and packages. > > The Good News: > I''ve written the required ingredients for a FreeBSD port, both for > puppet (0.20.1) and facter (1.3.5). I guessed the port category to be > "sysutils" and "ruby" for both, but "net-mgmt" might be a good one for > puppet instead of sysutils. > > While my ports work fine (for me), I haven''t pushed them up to the > FreeBSD guys yet. I''d like it to install the puppet ./examples to the > right place and maybe modify some rc.<*> first. Plus if a new version > is coming out, I''ll get it to use that before releasing the port...This is great news, thanks!> Bad News: > > ----- Client Error ------ > tester# puppetd --test --server puppet > err: Could not find type "/etc/profile" in file > /etc/puppet/manifests/classes/base.pp at line 6 > > > ------ The Puppetmaster: ./classes/base.pp ----- > class bash { > package { bash: > source => "/usr/ports/packages/i386/All/ > bash-3.1.17.tbz", > ensure => installed, > subscribe => > [''/etc/profile'',''/etc/profile.d/'',''/etc/bash/''] > }You have to specify the type to which to subscribe here. E.g.: package { bash: subscribe => [File[''/etc/profile''], File[''/etc/profile.d''], File [''/etc/bash'']] } We''re working on a syntax that would allow you to specify multiple names within the [], something like: package { bash: subscribe => File[''/etc/profile'', ''/etc/profile.d'', ''/etc/bash''] } But it''s not there yet.> remotefile{ "/etc/profile": > mode => 664, > source => "apps/bash/etc/profile" > } > remotefile { "/etc/profile.d/": > mode => 664, > source => "apps/bash/etc/profile.d/" > } > remotefile { "/etc/bash/": > mode => 664, > source => "apps/bash/etc/bash/" > } > }It looks like you''re actually doing the opposite of what you want here. My guess is that you''re replacing the default install of these files with your own version; in that case, you should have the package come before the files, not after: class bash { # Default to all files in this class coming after the package File { require => Package[bash] } package { bash: ... } remotefile { "/etc/profile": ...; "/etc/bash":...; ... } }> > Is there better way to handle a list of files and "bind" them to a > package (in this case, "bash")? Is there a way to make my package > definitions less ghetto and hardcoded, say wiring in a higher level > package tool like portupgrade that doesn''t seem to care about > package vs > port (and than forcing an install of that package for any real work)?There are many providers available for packages[1], one of which is ''ports'', which should be the default provider for freebsd. As far as I understand it, multiple people are using this provider without significant difficulty, although it''s not implemented all that well because of the difficulty of really automating the commands. There are plans afoot to rewrite the provider to use the ruby libs instead, but no progress has been made on that at this point.> ...Still learning, so forgive me if these questions seem simple. If > I''ve miss-RTFM, let me know where to look :-)Simple questions are how I find out what''s difficult and what''s not documented well, so they''re always appreciated. Cheers. 1 - http://reductivelabs.com/projects/puppet/documentation/reference/ typedocs.html#package -- I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are ''obviously'' no deficiencies and the other way is to make it so complicated that there are no ''obvious'' deficiencies. -- C.A.R. Hoare, Turing Lecture "The Emperor''s Old Clothes" CACM February 1981, pp. 75-83. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Sorry to bother, I''m not sure why mailman does this, but it likes to add a meta tag that keeps google and friends from indexing the archives. No google = no search, rendering archives everywhere useless. Dunno why this is default behavior as you''d think they want to encourage the whole "check the archives before asking a question" which last I checked was common mail-list etiquette. Anyhow... <...pathtomailman...>/templates/en/archidxhead.html take out: <META NAME="robots" CONTENT="noindex,follow"> There is probably a couple other files in there with that tag... -- Cory R. King XLAN, Inc.
On Dec 13, 2006, at 2:12 PM, Cory R. King wrote:> Sorry to bother, > > I''m not sure why mailman does this, but it likes to add a meta tag > that > keeps google and friends from indexing the archives. No google = no > search, rendering archives everywhere useless. Dunno why this is > default behavior as you''d think they want to encourage the whole > "check > the archives before asking a question" which last I checked was common > mail-list etiquette. > > Anyhow... > <...pathtomailman...>/templates/en/archidxhead.html > > take out: > <META NAME="robots" CONTENT="noindex,follow"> > > There is probably a couple other files in there with that tag...Cool, thanks. I fixed this. Weirdly, I''ve seen puppet mails in the google indexes. -- Good judgment comes from experience, and experience comes from bad judgment. --Barry LePatner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com