I''m having a hard time shipping off complete puppet manifests/facts/files within a single versioned container to end nodes because of how strict puppet is about not allowing relative paths, even with runtime command line options. (I can not use the puppet/puppetmaster client/server model because of company policies, organization divisions and personnel issues.) When I export a complete set of puppet files from subversion, I want to be able to run/test that set of files no matter where on a system''s filesystem they are stored. (Such as /tmp/puppet-conf-revisionXXX/ rather than /etc/puppet/manifests/) Let me explain the organization model: I am storing all puppet manifests, facts and system config files in a subversion repository. For each type or "role" of server, there is a primary puppet manifest that imports common manifests and includes classes as needed. All of the common manifests, facts and files (source => "file..") are brought as subdirectories into a svn working copy or svn export of the role''s primary directory via the svn property "svn:externals." This svn:externals property is version just like the primary manifest file, so I can included specific revisions of the common files, facts and manifests as needed for each specific role. (If someone in a far-flung department makes a change to the common manifests, that does not affect the role I manage until I explicitly update my svn:externals to point at their new revision.) For example: Common files that are re-used by many different roles are organized in their own hierarchy -- /common/manifests/services/ntp/ /common/manifests/services/ldap/ /common/facts/... /common/files/... Then a specific role uses svn:externals to include specific revisions of common/ as needed -- /role/qmailcluster/ (where qmailcluster is the "role", or type of server that this set of manifests is intended to maintain) /role/qmailcluster/main.pp <-- main manifest that imports/includes common files as needed, besides having role-specific settings /role/qmailcluster/facts/ <-- non-common facts, specific to this role /role/qmailcluster/common/files <-- a svn:externals svn property, pointing to revision X of /common/files/... /role/qmailcluster/common/manifests/services/ntp/ <-- a svn:externals svn property, pointing to revision X of /common/manifests/services/ntp/ /role/qmailcluster/common/facts <-- a svn:externals property, pointing to revision X of /common/facts/ To test a role, I svn export its specific base role path to a test server instance, and then apply that exact revision of manifests, facts and files. Like this -- svn export -r X https://subversion/puppet/trunk/role/qmailcluster//tmp/qmailcluster-puppet-revisionX cd /tmp/qmailcluster-puppet-revisionX puppet -v -d --factpath ./common/facts/ --factpath ./facts/ main.pp I could live with each source file URL having to be absolute (source => file://), but only if I have some way of calling a facter that stores the current working directory in a variable ($base_path) that can be used to adjust file URLs. (source => file://$base_path/common/files/...) Does this make any sense at all? I think that adding a command line option that would allow relative paths to be specified for config/command line options would be easy to do. As-is I can just comment out the relative path check, but that''s probably dangerous for other reasons? Thanks all for your time, Abe _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jun 8, 2007, at 8:06 PM, aberoham@gmail.com wrote:> [...] > I think that adding a command line option that would allow relative > paths to be specified for config/command line options would be easy > to do. As-is I can just comment out the relative path check, but > that''s probably dangerous for other reasons?Are you aware of the ''path'' option to exec? It looks like these are all things you''re doing with exec, and you can specify a search path to it and rely on that. Is that not sufficient? -- The remarkable thing about Shakespeare is that he really is very good, in spite of all the people who say he is very good. -- Robert Graves --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi Luke. I''m not using exec. I wasn''t aware of it, but I
don''t think using
it could help with the specific puppet manifest, fact and file organization
I am aiming for.
I don''t want to have manifests in /etc/puppet while facts are somewhere
within /var/lib/puppet. (And I don''t want to have files coming from
puppetmaster). I want to have *everything* in one directory hierarchy that I
can easily point puppet at. If I can get everything relative to one base
directory, its easy to fit the complete hierarchy into a version control
system. And then I can export different revisions of everything to different
directories on a test node and not worry about clobbering prior exports or
working copies of puppet manifests, facts and related files. (Nor do I have
to worry about exporting a specific revision of config files to a separate
puppetmaster server.)
Right now I have a fact called base_path.rb that sets $base_path. For any
puppet resource type that has a ''source'' attribute/param, such
as ''file'', I
prefix the ''source'' path with the variable set by that fact.
common/facts/base_path.rb --
# base_path.rb
Facter.add("base_path") do
setcode do
%x{/bin/pwd}.chomp
end
end
common/manifests/services/ntp/ntp.pp ---
file { stepTicker:
name => "/etc/ntp/step-tickers",
source => "${base_path}/common/files/etc/ntp/step-tickers",
}
I would like to call puppet like this, but without commenting out
puppet''s
path separator/absolute path check, puppet fails to load
./common/facts/base_path.rb, telling me that "File paths must be fully
qualified" --
$ cd /tmp/complete_manifest_fact_and_file_export_base/
$ puppet -v -d --factpath ./common/facts/ --factpath ./facts/ main.pp
[...]
info: Loading fact base_path
err: Could not create ./common/facts: Parameter path failed: File paths must
be fully qualified
err: Parameter path failed: File paths must be fully qualified
[...]
puppet/type/pfile.rb, with File::SEPARATOR check commented out, works, but
is dangerous ---
[...]
newparam(:path) do
desc "The path to the file to manage. Must be fully
qualified."
isnamevar
validate do |value|
#unless value =~ /^#{File::SEPARATOR}/
#raise Puppet::Error, "File paths must be fully
qualified"
#end
end
end
[...]
Abe
On 6/9/07, Luke Kanies <luke@madstop.com> wrote:>
> On Jun 8, 2007, at 8:06 PM, aberoham@gmail.com wrote:
> > [...]
> > I think that adding a command line option that would allow relative
> > paths to be specified for config/command line options would be easy
> > to do. As-is I can just comment out the relative path check, but
> > that''s probably dangerous for other reasons?
>
> Are you aware of the ''path'' option to exec? It looks
like these are
> all things you''re doing with exec, and you can specify a search
path
> to it and rely on that.
>
> Is that not sufficient?
>
> --
> The remarkable thing about Shakespeare is that he really is very good,
> in spite of all the people who say he is very good. -- Robert Graves
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 10 June 2007, aberoham@gmail.com wrote:> Hi Luke. I'm not using exec. I wasn't aware of it, but I don't think using > it could help with the specific puppet manifest, fact and file organization > I am aiming for. > > I don't want to have manifests in /etc/puppet while facts are somewhere > within /var/lib/puppet. (And I don't want to have files coming from > puppetmaster). I want to have *everything* in one directory hierarchy that > I can easily point puppet at. If I can get everything relative to one base > directory, its easy to fit the complete hierarchy into a version control > system. And then I can export different revisions of everything to > different directories on a test node and not worry about clobbering prior > exports or working copies of puppet manifests, facts and related files. > (Nor do I have to worry about exporting a specific revision of config files > to a separate puppetmaster server.) >You might want to take a look at PuppetModules on the wiki. This is alread a step into the Root-independent direction. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGdwDO/Pp1N6Uzh0URAl7ZAKCTfJyAmRsuXbkXpJEeBCOv1c67dQCfXrkv 7g8DPDEMLQx64X10Qflt1sw=5lpf -----END PGP SIGNATURE----- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jun 10, 2007, at 1:47 AM, aberoham@gmail.com wrote:> Hi Luke. I''m not using exec. I wasn''t aware of it, but I don''t > think using it could help with the specific puppet manifest, fact > and file organization I am aiming for. > > I don''t want to have manifests in /etc/puppet while facts are > somewhere within /var/lib/puppet. (And I don''t want to have files > coming from puppetmaster). I want to have *everything* in one > directory hierarchy that I can easily point puppet at. If I can get > everything relative to one base directory, its easy to fit the > complete hierarchy into a version control system. And then I can > export different revisions of everything to different directories > on a test node and not worry about clobbering prior exports or > working copies of puppet manifests, facts and related files. (Nor > do I have to worry about exporting a specific revision of config > files to a separate puppetmaster server.) > > Right now I have a fact called base_path.rb that sets $base_path. > For any puppet resource type that has a ''source'' attribute/param, > such as ''file'', I prefix the ''source'' path with the variable set by > that fact.As David said, modules are most of the way there; combined with the flexible configuration parameters, you shouldn''t have much trouble. There''s pretty much nothing at all hard-coded in Puppet, and almost every single directory keys directly off of either the vardir or the confidir. If you set those two explicitly, then Puppet will look in them for absolutely everything. I think the only exceptions are the rundir (because systems expect the pid files to be in a certain place) and the module path, which includes /usr/share/puppet/modules by default but can be overridden not to. Any place you can''t provide that level of indirection is probably worth considering to be a bug. -- I don''t always know what I''m talking about, but I''m always pretty much convinced that I''m right. -- musician Mojo Nixon --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com