Wow, that is almost identical to the setup that I am using right now. The
only difference is that I added a post-commit hook to the Subversion
repository that does an ssh into the master cfengine server and an "svn
update" of it's repository, along with a "cfrun". That way, my config gets
pushed out whenever I update it and do an "svn commit".
Anyway, the way I implemented singlecopy was to call out each file
individually, like so:
control:
singlecopy = ( on ) # Only match one possible role
DefaultCopyType = ( checksum ) # Only copy files if updated
dr = ( /etc/cfengine ) # Our global repository
fs = ( cfserver ) # The fileserver it is served from
AllowRedefinitionOf = ( role ) # Establish roles for all servers
any:: role = ( nevermatch )
ldap:: role = ( ldap ) # Server is an LDAP server
loghost:: role = ( loghost ) # Server is a syslog server
copy:
### /etc/profile (role specific) ###
$(dr)/etc/profile.$(host) server=$(fs) dest=/etc/profile
o=root g=root mode=755 timestamps=preserve
encrypt=true backup=true inform=true
$(dr)/etc/profile.$(role) server=$(fs) dest=/etc/profile
o=root g=root mode=755 timestamps=preserve
encrypt=true backup=true inform=true
$(dr)/etc/profile server=$(fs) dest=/etc/profile
o=root g=root mode=755 timestamps=preserve
encrypt=true backup=true inform=true
The above section simply copies the file if the checksum has changed, and
finds the most specific file, based on hostname first, if not hostname then
role, and if not role, then it uses the generic profile.
The advantage to this approach is that it only copies the file if the
checksum has changed, and it keeps permissions, ownership, and timestamps
intact.
The disadvantage to this approach is that it takes a lot of time to setup
because you have to do this for every single config file on the server.
BTW, if you want a copy of my post-commit hook script for Subversion, I
could share that as well.
Cheers,
Luke
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Josh Lothian
Sent: Monday, May 09, 2005 2:38 PM
To: help-cfengine@gnu.org
Subject: cfengine and revision control
Greetings all,
At my previous employer, we kept all the files cfengine distributed in
a Subversion repository. Each admin worked on his own checked out
copy of the repo, and the master cfengine server also had it's own
working copy. This worked very well, except Subversion, like most other
revision control systems, doesn't respect file permissions well.
That wouldn't normally be a problem when using files: to call out each
file individually, but we used the SingleCopy functionality to copy from
different trees depending on os, architecture, etc. For example:
control:
SingleCopy = ( on )
copy:
$(cfdir)/linux/redhat/etc dest=/etc recurse=inf
$(cfdir)/linux/etc dest=/etc recurse=inf
$(cfdir)/generic/etc dest=/etc recurse=inf
So, it was very easy to override any of the files with a more specific
version. But since the files are all just copied recursively, there's
no chance to set specific permissions on them, so cfengine just uses
the current permissions on the file. The problem comes up when someone
updated the repository, and maybe $(cfdir)/linux/etc/passwd became 0400.
Then that gets copied out with the bogus permissions...
I solved that by creating a wrapper around the SVN update process.
The repo would be updated from SVN on the master server, and then cfengine
would run a script that verified all the permissions under $(cfdir).
That worked pretty well, except when we added a new file under $(cfdir)
we also had to remember to update the permissions-fixing script.
I realize it would be pretty easy to add something like:
files:
/etc/passwd mode=644 action=fixall
However, there is that slight delay between the time the files are copied
and the time the permissions are fixed. That worries me.
Has anyone come up with a more elegant solution to this problem? I'd like
to implement something similar at my present employer. I really
like the recursive copying approach rather than the one listed
on http://cfwiki.org/cfwiki/index.php/Singlecopy_Nirvana because it
doesn't require any changes to the cfengine configs to add new files to
be distributed.
sorry for the long-windedness, I do that sometimes,
-jkl
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
