Package Details: cfengine 3.15.2-1

Git Clone URL: https://aur.archlinux.org/cfengine.git (read-only, click to copy)
Package Base: cfengine
Description: Automated suite of programs for configuring and maintaining Unix-like computers.
Upstream URL: https://cfengine.com
Licenses: GPL3
Submitter: None
Maintainer: bidulock (Lex-2008)
Last Packager: bidulock
Votes: 20
Popularity: 0.000000
First Submitted: 2008-10-25 17:55 (UTC)
Last Updated: 2021-05-25 02:39 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

ektich commented on 2016-02-20 14:46 (UTC)

3.7.2-1: CFEngine 3.7 LTS branch, now using lmdb instead of qdbm.

ektich commented on 2016-02-07 11:10 (UTC)

I've prepared git pull request (https://github.com/zizzfizzix/pkgbuilds/pull/8) that switches to lmdb, but the version there is still 3.6.5. I'll try to prepare a new pull request for building 3.7.2 LTS version during the week.

andreas_baumann commented on 2016-02-07 10:49 (UTC)

Latest versions are 3.7.2 LTS or 3.8.1.

andreas_baumann commented on 2016-02-07 10:46 (UTC)

qdbm no longer exists as package or AUR package?

zizzfizzix commented on 2014-04-07 21:30 (UTC)

@ektich Thanks for your patches. As to your issue if I understand it correctly you're just doing it wrong not using systemctl in the first place in your policies. Here's an example how to do this: https://groups.google.com/forum/#!msg/help-cfengine/BGMrLuWb79k/E31PL5FtgXgJ If you drop any "manual" service activation there won't be any clashes with systemctl, and since it's a specialized tool you can't do any better anyway ;)

ektich commented on 2014-03-12 17:56 (UTC)

I've pushed my changes to some of files to https://github.com/ektich/pkgbuilds. Please review and let me know what you think. One issue (probably site-specific): after successful cf-agent --bootstrap, once client receives policy files from the server cf-execd is started automatically. Within 5 minutes cf-serverd and cf-monitord are started as well. Of course systemctl fails to notice them and starts another set of executables if it is executed with "enable" followed by "start" commands. But without enabling at least cf-execd with systemctl client will stop running CFEngine after a reboot. Maybe a README file documenting this should be included with this package?

ektich commented on 2014-03-11 17:59 (UTC)

Not sure if this is a right place to discuss issues, but I haven't found any better place. I run a Debian-based cfengine server, and I need to add few Arch-based clients to it. After downloading this PKGBUILD, building and installing it I ran into two problems, while running cf-agent -B master-servers.name: 1) "error: needs to be installed in /var/lib/cfengine/bin for pre-validation of full configuration". this is easily fixable by creating a symbolic link from /usr/bin/cf-promises 2) the cf-agent -B re-generates inputs/failsafe.cf file with hard-coded path to the promises on the master server (/var/lib/cfengine/masterfiles) and then fails to copy them from the server. On the server side (installed from debian package provided by cfengine) those files are in /var/cfengine/masterfiles. changing PKGBUILD to compile cfengine with --with-workdir=/var/${pkgname} fixes this issue. third issue appears once cfengine is installed in /var/cfengine: cf-agent -B master-server tries to start cf-execd once policy files are copied, but it expects to find cf-execd binary in /var/cfengine/bin (same as cf-promises). Again, can be fixed by simple ln -s They might not be issues, depends how you look at them. But, if this is the proper place to discuss them, wouldn't it be logical to follow CFengine's "way"? (installing everything in /var/cfengine instead of /var/lib/cfengine, and making sure cf-promises and at least cf-execd exist in /var/cfengine/bin, maybe soft-linked)? I need to read up on PKGBUILD etc but I'll try and prepare a version that does all that for your review.

zizzfizzix commented on 2013-11-14 20:38 (UTC)

I have made quite a lot of changes, so be sure to review them while updating

andreas_baumann commented on 2013-06-20 10:51 (UTC)

You are absolutely right, fixed, thanks.. :-)

« First ‹ Previous 1 2 3 4 5 6 Next › Last »