Re: cfengine 3: FHS regression

[Neil Watson]

I've often wondered why cf's configs were separated from the /etc. I
think the reasoning behind this is that by separating cf from /etc it
makes it more resilient in case of the loss of some of /etc. Assuming
this is true I think there are other ways to do this while still
adhering to FHS. I could be entirely wrong. Hopefully Mark will shed
some light on this.

--
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca

[Guillaume Rousse]

Hello list.

I just tried to update official mandriva package to cfengine 3.0.1.
However, I'm quite disapointed that some of the mecanisms that were
available in cfengine 2 to achieve FHS compliance are now inefficient.

cfengine insists to have all its configuration stored in its working
directory, which default to /var/cfengine/inputs [1], whereas FHS
mandates configuration to be located under /etc. With cfengine 2, the
CFINPUTS environement variable made possible to use another directory
for this, but it does't work anymore [2]. It was also possible to use
symlinks, such as /var/cfengine/inputs -> /etc/cfengine. But cfengine 3
detects it, and rename the symlink immediatly...

Second, cf-agent doesn't run without checking its input through
cf-promises, and wants this last one under cfengine work directory
again, meaning /var/cfengine/bin/cf-promises. Once again, symlinking
/var/cfengine/bin/cf-promises -> /usr/sbin/cf-promises doesn't work.

I won't go in the trouble of explaining the interest of FHS, and the
rationales of the various Unix directories. Anyone interested can read
them from official FHS site [3]. Software authors may perfectly ignore
them, and use a windows-like setup 'every file under a single top-level
private directory'. But that's very harmful for this new version of
cfengine to prevent other people to achieve compliance, intentionaly or
not. In particular, it will will restrict linux distributions who cares
about standards to package it.

Can we hope those constraints to relax a little bit in future versions ?

1: which itself is not FHS-compliant, but easy to fix though
--with-workdir compile-time option

2: BTW, the documentation is very unclear here:
The environment variable CFINPUTS still overrides this default location,
as before, but in its absence or when called from the scheduler, this
becomes the location of trusted files.
Unlike cfengine 2, cfengine 3 does not recognize the CFINPUTS
environment variable.

3: http://www.pathname.com/fhs/

--
BOFH excuse #155:

Dumb terminal

[Mark Burgess]

Guillaume,

let me try to respond to this pragmatically and in good humour.

In general I think standards are useful and important, and unless
there is a compelling reason not to, one should try to keep to standards.

In the case of cfengine, the practice of using /var/cfengine as
cfengine cache/private data was established long before linux was a
twinkle in anyone's eye. It is based on cross-platform pragmatism, not
on Linux ideas - since cfengine has to run on all operating systems.

Anyone can set up their config files in /etc and their binaries in
/bin if they want to -- cfengine doesn't care. But, in order to have
seamless updating and operational resilience in the case of
filesystems that might be network mounted, cfengine wants to *cache*
everything in /var -- indeed it requires it.

You should think of /var/cfengine as analogous to /var/mail or
/var/cron -- what happens there is none of the OS's business. But you
cannot remove these locations without breaking the system -- and
indeed you shouldn't. (As with cfengine, both of these programs
pre-date Linux.) Indeed, you are actually doing the user a dis-service
by forcing the Linux bureaucracy onto users. Symbolic links are a
fragile mechanism, never recommended for something mission critical.

One can try to argue that now that we have a nice standard everyone
should change - unfortunately the compelling reasons to have this
cache are still there. The Linux standard is not a standard; moreover
/bin and /etc are not cross-platform guaranteeable locations. The
cfengine practice started in the days on diskless workstations - then
it seems they had gone away forever, and back they came as thin
clients. I approach this from the perspective that cfengine is part of
basic infrastructure and it just has to work -- it is not like
changing the location of X11R6 (also pretty non-standard). Moreover,
it is better to have a fixed location on all systems than a different
location on every OS (take heed Debian bureaucrats).

A change in cfengine modus operandi would affect millions of
installations, so it is not something to do lightly. I suspect that
there is no good reason to do so other than the desire to promite
bureaucracy over reason. It is like asking the British to drive on the
right, or America to go metric (or use international paper sizes!) --
it would cause too much disruption for too little gain.

So, I'm sorry for your disappointment, but as the EU itself has been
discovering lately, solid traditions are difficult to replace with
modern rules and regulations. I will keep your thoughts in mind, but I
wouldn't hold your breath for any changes. I propose, as other have
pointed out, that resilience and simplicity are more important than
conformity in this case.

Mark

Mark Burgess

-------------------------------------------------
Professor of Network and System Administration
Oslo University College, Norway

Personal Web: http://www.iu.hio.no/~mark
Office Telf : +47 22453272
-------------------------------------------------

[Edward F. Brown]

Mark,

The first line of the FHS is: "This standard consists of a set of
requirements and guidelines for file and directory placement under
UNIX-like operating systems." According to the "Background" section of
the document, the focus has been UNIX-like systems, not just linux, since
1995. (Not AS long-lived as cfengine, but still, dating from the last
century! ;-) )

It's interesting that of the two example /var directories you mention as
being absolutely necessary, /var/cron is only listed as a "reserved"
directory name, for historical or local use reasons, and /var/mail is
"optional". (On one "unix-like system" I just checked, the first doesn't
exist, the second is an [os-installed] symlink to /var/spool/mail.)

My point is just that I'm not too sure anything is "guaranteed". The
entire filesystem might reside on a SAN, in the case of a virtual server
for example. So I just wonder if building hard path requirements into
cfengine is really more "resilient", or if it could also be viewed as a
kind of enforced "conformity"?

Guillaume makes a good point. It's not in cfengine's best interest if it
can't be built/packaged/installed according to applicable standards.

-Ed

> _______________________________________________
> Help-cfengine mailing list
> Help-c...@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine
>

[Bas van der Vlies]

Mark,



I agree with Ed and Guillaume, why not let the package maintainer decide
where configuration and binaries are stored with the ''--with-workdir''
option and if you do not specifiy this option you will get the default
locations. So you do not beak anything.


PS)
symlinks can be very useful :-D

> Guillaume makes a good point. It's not in cfengine's best interest if it
> can't be built/packaged/installed according to applicable standards.
>

--
********************************************************************
* Bas van der Vlies e-mail: ba...@sara.nl *
* SARA - Academic Computing Services Amsterdam, The Netherlands *
********************************************************************

[Mark Burgess]

I don't understand all this criticism. Nothing has changed except the
absence of CFINPUTS variable. The package maintainer still decides
with the workdir location.

Nothing has changed?? You are stressing me out for no reason ;-)

M

Bas van der Vlies wrote:
> Mark,
>
>
>
> I agree with Ed and Guillaume, why not let the package maintainer decide
> where configuration and binaries are stored with the ''--with-workdir''
> option and if you do not specifiy this option you will get the default
> locations. So you do not beak anything.
>
>
> PS)
> symlinks can be very useful :-D
>
>> Guillaume makes a good point. It's not in cfengine's best interest if it
>> can't be built/packaged/installed according to applicable standards.
>>
>
>
>

--

[Bas van der Vlies]

Mark Burgess wrote:
> I don't understand all this criticism. Nothing has changed except the
> absence of CFINPUTS variable. The package maintainer still decides
> with the workdir location.
>
> Nothing has changed?? You are stressing me out for no reason ;-)
>

My apologies ;-) My impression was that the --with-workdir was gone.

> M
>
> Bas van der Vlies wrote:
>> Mark,
>>
>>
>>
>> I agree with Ed and Guillaume, why not let the package maintainer decide
>> where configuration and binaries are stored with the ''--with-workdir''
>> option and if you do not specifiy this option you will get the default
>> locations. So you do not beak anything.
>>
>>
>> PS)
>> symlinks can be very useful :-D
>>
>>> Guillaume makes a good point. It's not in cfengine's best interest if it
>>> can't be built/packaged/installed according to applicable standards.
>>>
>>
>>
>


--

[Guillaume Rousse]

Mark Burgess a �crit :

> I don't understand all this criticism. Nothing has changed except the
> absence of CFINPUTS variable. The package maintainer still decides
> with the workdir location.
>
> Nothing has changed?? You are stressing me out for no reason ;-)

It has changed, as stated in my mail...

Point 1: if $workdir/input is a symlink, cf-agent will rename it first
to $workdir/inputs.cf-moved, then complains it does not found its
configuration:

[root@oberkampf ~]# ls -l /var/lib/cfengine
total 36
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 bin/
lrwxrwxrwx 1 root root 13 2009-05-21 00:54 inputs -> /etc/cfengine/
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 lastseen/
drwx------ 2 root root 4096 2009-05-21 00:53 modules/
drwx------ 2 root root 4096 2009-05-21 00:53 outputs/
drwx------ 2 root root 4096 2009-05-21 00:53 ppkeys/
-rw-r--r-- 1 root root 1024 2009-05-21 00:53 randseed
drwx------ 2 root root 4096 2009-05-21 00:53 rpc_in/
drwx------ 2 root root 4096 2009-05-21 00:53 rpc_out/
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 state/

[root@oberkampf ~]# cf-agent
cf-promises needs to be installed in /var/lib/cfengine/bin for
pre-validation of full configuration
cf-agent was not able to get confirmation of promises from cf-promises,
so going to failsafe
Can't stat file /var/lib/cfengine/inputs/failsafe.cf for parsing
(stat: No such file or directory)

[root@oberkampf ~]# ls -l /var/lib/cfengine
total 40
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 bin/
drwx------ 2 root root 4096 2009-05-21 00:54 inputs/
lrwxrwxrwx 1 root root 13 2009-05-21 00:54 inputs.cf-moved ->
/etc/cfengine/
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 lastseen/
drwx------ 2 root root 4096 2009-05-21 00:53 modules/
drwx------ 2 root root 4096 2009-05-21 00:53 outputs/
drwx------ 2 root root 4096 2009-05-21 00:53 ppkeys/
-rw-r--r-- 1 root root 1024 2009-05-21 00:53 randseed
drwx------ 2 root root 4096 2009-05-21 00:53 rpc_in/
drwx------ 2 root root 4096 2009-05-21 00:53 rpc_out/
drwxr-xr-x 2 root root 4096 2009-05-21 00:53 state/

Point 2: cf-agent insist to find cf-promises in $workdir/bin, despite it
being installed under $sbindir (cf src/Makefile.am):
[root@oberkampf ~]# cf-agent -v
...
cf3 cf-promises needs to be installed in /var/lib/cfengine/bin for
pre-validation of full configuration
cf3 cf-agent was not able to get confirmation of promises from
cf-promises, so going to failsafe
cf3 > Parsing file /var/lib/cfengine/inputs/failsafe.cf
cf3 Initiate variable convergence...
...

I don't complain cfengine doesn't follow FHS by default, just that it
prevent to achieve it (point 1), and that its installation doesn't match
expected setup (point 2).

[Mark Burgess]

You are suggesting that cfengine is not allowed to have private
workspace. Renaming or linking anything inside cfengine's private
workspace is your fault. If you have made a symlink of
/var/cfengine/inputs then this is contrary to cfengine's programmed
behaviour -- it breaks the fault tolerance design, and you deserve
what you get. If you want to modify your personal copy of the code to
change this, you are free to do so, but please don't ask me to condone
it. It is a terrible idea.

The design has not changed one iota, only the implementation has
changed to make cfengine work more easily out of the box.

Placing cf-promises in the workdir is a security strategy. Since we
don't know where it is installed in general you would have to rely on
a path, which is less fault tolerant and secure. So it's up to you to
place an authorized copy there. The workdir is the only path that
*has* to be hard coded.

You can put the binaries and master configurations whereever you like,
in compliant places, but cfengine wants to cache these things in a
cross-platform place. Indeed, cfengine installs into /usr/local/sbin
by default, with /usr/share policies etc. This is all compliant.

Like I said, if you are going to argue "rightiousness", it will only
bring out the worst in me, so let's stop this here. Cfengine is not
out of compliance, you are trying to apply an irrelevant model to its
private workspace.

M

[Guillaume Rousse]

Mark Burgess a �crit :

> You are suggesting that cfengine is not allowed to have private
> workspace.

Currently, that's rather cfengine which is not allowing me to do
something than the opposite...

[..]

> You can put the binaries and master configurations whereever you like,
> in compliant places, but cfengine wants to cache these things in a
> cross-platform place. Indeed, cfengine installs into /usr/local/sbin
> by default, with /usr/share policies etc. This is all compliant.

Absolutly. I just wonder why you install binaries by default in one
place, and then ask the user to move/symlink them somewhere else
thereafter. You might as well install them directly there. But that's a
minor issue.

> Like I said, if you are going to argue "rightiousness", it will only
> bring out the worst in me, so let's stop this here. Cfengine is not
> out of compliance, you are trying to apply an irrelevant model to its
> private workspace.

I don't argue "rightiousness", I argue about 'let me choose how I want
to setup my system instead of deciding for me, as I usually know better
what I need', which is slightly different. I perfectly understand the
interest to achieve a consistent setup about various heterogeneous
hosts. But whereas it was already possible to achieve this by cfengine
configuration in previous version, this is more and more hardcoded in
the binaries, and far less flexible. As a consequence, people with
different but perfectly legitimate usage context (for instance, cluster
with all systems identical) have more difficulties to adapt it to their
specific needs.

Would a patch reintroducing CFINPUTS or adding a --relax-symlink-check
option be considered for inclusion ?
--
BOFH excuse #55:

Plumber mistook routing panel for decorative wall fixture

[Mark Burgess]

>
>> Like I said, if you are going to argue "rightiousness", it will only
>> bring out the worst in me, so let's stop this here. Cfengine is not
>> out of compliance, you are trying to apply an irrelevant model to its
>> private workspace.
> I don't argue "rightiousness", I argue about 'let me choose how I want
> to setup my system instead of deciding for me, as I usually know better
> what I need', which is slightly different. I perfectly understand the
> interest to achieve a consistent setup about various heterogeneous
> hosts. But whereas it was already possible to achieve this by cfengine
> configuration in previous version, this is more and more hardcoded in
> the binaries, and far less flexible. As a consequence, people with
> different but perfectly legitimate usage context (for instance, cluster
> with all systems identical) have more difficulties to adapt it to their
> specific needs.
>
> Would a patch reintroducing CFINPUTS or adding a --relax-symlink-check
> option be considered for inclusion ?

I don't really buy this, but I'll think about how it can be done.

I don't want to bring back the environment variable.

Any suggestions from others?

[Matt Richards]

When I was changing the default directory to be LSB compliant, I
patched the code to re-introduced the BINDIR variable. I believe that
this existed in very early versions of cf2 (maybe even cf1) where
BINDIR replaced WORKDIR in a few spots in the code. I believe I still
have the patches for cf3 if you are interested. The BINDIR was defined
in the configure process.

I agree with Mark, cfengine has every right to be in /var/cfengine.
It has been around long enough to be a standard.



On May 21, 2009, at 5:00 AM, Mark Burgess <Mark.B...@iu.hio.no>
wrote:

[Antonio Radici]

Hi,
we also like to package cfengine3 on Debian but this regression has badly bitten
us; let me make this clear: I agree with the fact that cfengine is designed
to be as cross-compatible as possible and I don't have any problem if you think
that cfengine should be self-contained in /var/cfengine; it is probably a good
choice and there are lot of reasons supporting it.

It would be great if the strictness of some behaviors were configurable, for
example that fact that you override the /var/cfengine/bin and
/var/cfengine/inputs symlinks or the fact that cf-promises(8) *must* be in
/var/cfengine/bin; it's not really a preference for me: having a binary outside
/usr/[local]/[s]bin is against the Debian policy and if I package cfengine3 as
is, the package will be rejected.

So, it is clear that on my side I have to work out a patch not to enforce the
strictness of the behaviors described above, it would help me, and other
maintainers of distributions where FHS is a requirement, if there were an option
to relax these checks.

It would be great to know from you if you think that this is feasible, it is a
great pain for us to work out patches and then refresh them every time there is
a new release.

Thanks for your time.

Cheers
Antonio

[Antonio Radici]

Hi Brendan,
thanks a lot for your quick response, I've put some of my thoughts inline

Brendan Strejcek wrote:
> Hi Antonio,
>
> I think you are misunderstanding the cfengine design. There is no
> reason for the package to install anything in /var/cfengine. That
> area, the workdir, is a *cache*, not an install directory. Part of the
> install script could to a copy of /usr/sbin/cf-* to /var/cfengine/bin.
> If the package does not do that, then the user policy probably should.
> I would probably lean towards having the package do as little as
> possible in postinst, so as to not get in the way of user's that might
> do things differently. A cf-key run is probably enough.

What we are doing is copying over the binaries to /usr/sbin and symlinking /var/cfengine/bin to
/usr/sbin, what cfengine3 does is renaming the symlink to bin.cf-moved and creating a new empty
/var/cfengine/bin. If I'm reading this correctly I should only *copy* the binaries to /usr/sbin and
leave what is in /var/cfengine/bin *as-is*. Ok, I will do so.

Still, if I run cf-envd, if I'm not wrong, it will ask for a /var/cfengine/bin/cf-promises; I can still
leave a cached copy but don't you think that we should have an option to relax this check?

> Also, the previous Debian way of creating a symlink from
> /var/cfengine/inputs to /etc is wrong. Policy files are *not*
> configuration files. They are working data cached from a trusted peer.
> Perhaps the configuration for cf-serverd deserves configuration file
> status, but really nothing else does. Exported policy files probably
> belong under /srv to fit the FHS.

I agree, I knew that there was some discussion about this with cfengine2 when it had a previus
maintainer (I've taken over the package since some months); we can keep /var/cfengine/inputs as data
and since they are just copied over from a server it is surely the right decision. I agree with the
fact that the cf-serverd configuration should be considered as a configuration file, so it probably
deserves to be placed in /etc, but I can work around this.

> Please let me know if you have any questions. I would be glad to help
> you package cfengine so that it adheres to both Debian policy and
> cfengine philosophy. There is really no conflict between the two
> (other than maybe the substitution of /var/lib/cfengine{,2,3} for
> /var/cfengine, which is fine). I am intimately familiar with both
> worlds, and I would be glad to help.

Thanks a lot for help Brendan, it is really appreciated. I hope to get cfengine3 into NEW within
this month.

Cheers
Antonio

[Mark Burgess]

You are number 2 to request some workaround for this.

I will come up with a solution for allowing/tolerating the links,
without commenting on what I think of the practice, or the arguments
involved ;-)

It will get done some time in the next few weeks. I am currently very
busy with priority stuff.

M

> _______________________________________________
> Help-cfengine mailing list
> Help-c...@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine

[Brendan Strejcek]

Hi Antonio,

I think you are misunderstanding the cfengine design. There is no
reason for the package to install anything in /var/cfengine. That
area, the workdir, is a *cache*, not an install directory. Part of the
install script could to a copy of /usr/sbin/cf-* to /var/cfengine/bin.
If the package does not do that, then the user policy probably should.
I would probably lean towards having the package do as little as
possible in postinst, so as to not get in the way of user's that might
do things differently. A cf-key run is probably enough.

Also, the previous Debian way of creating a symlink from
/var/cfengine/inputs to /etc is wrong. Policy files are *not*
configuration files. They are working data cached from a trusted peer.
Perhaps the configuration for cf-serverd deserves configuration file
status, but really nothing else does. Exported policy files probably
belong under /srv to fit the FHS.

Please let me know if you have any questions. I would be glad to help
you package cfengine so that it adheres to both Debian policy and
cfengine philosophy. There is really no conflict between the two
(other than maybe the substitution of /var/lib/cfengine{,2,3} for
/var/cfengine, which is fine). I am intimately familiar with both
worlds, and I would be glad to help.

Best,
Brendan

[Wes Hardin]

Not to stir the pot up any further, but this thread has made me take a closer look at my Cfengine installation at my site and wonder if I'm doing something wrong.

I use Cfengine2 in a mostly RHEL4 environment with a few Ubuntu machines thrown in for some flavor, but most of my experience is from the RHEL side. I am evaluating an upgrade to Cfengine 3, but haven't gotten much beyond reading a few articles and some packaging tests. I was not heavily involved in the initial setup of Cfengine at my site, but since the responsible admin has moved on, I picked up responsibility for maintaining it. I use RPMS from RPMForge on RHEL and the standard Ubuntu DEBs. It was when I first tried to integrate my Ubuntu machines into my environment that I encountered troubles trying to deal with differing paths for my policy files and configurations.

Now Mark and Brendan have both stressed the fact that /var/cfengine (or /var/lib/cfengine2) is supposed to be a cache or working directory. (Kind of makes me want to move it to /var/cache/cfengine, but that is a separate matter.) This got me thinking about how cache-like my /var/cfengine *isn't.* I don't think I'm alone in this view, but a cache or workspace is generally seen as disposable and can be rebuilt if needed. Examples would be a web browser's cache or a working directory of your SCM of choice. If I destroy my web browser's cache, my web browser doesn't stop working. If I lose a SCM workspace, through the software, I can rebuild a new one, usually pretty easily. If I clean out /var/cfengine, Cfengine stops working.

Now maybe this is a fault of my own setup or the packages I use, but without /var/cfengine:
- cfservd will create a new, "blank" /var/cfengine, but be essentially useless due to missing configuration
- cfagent can't do anything useful because the configuration files it looks for are missing
- I don't use cfexecd or cfenvd, so I don't know the effect on them

It really seems to me that some very important configuration files were lost with this supposed cache. Is it possible to store and use of the *.conf files outside the /var/cfengine cache without symlinks? Is that a build time configuration I'm unfamiliar with since I've mostly used 3rd party packages? Reading this thread and the cf3 docs, it doesn't sound like this is easily accomplished. I do agree that the current Debian/Ubuntu methodology of symlinking /etc/cfengine into the cache is "not right" since you then put variable policy data into what is supposed to be a fairly static tree. It seems to me that a configurable separation between static configuration files (even if you want to cache them before execution) and truly variable policy and Cfengine data files would go a long way to help those wishing to comply with FHS.

In my current configuration, all new clients and those whose caches have been destroyed have to be "bootstrapped," which is basically just copying over my policy files and some host keys. After I copy these files into the Cfengine cache, I fire up Cfengine and kind of just forget about it. Part of my Cfengine policy (and I think this is fairly standard) is to have Cfengine update this cache via the update.conf. Reading through the Cfengine3 docs recently, I ran across this seemingly innocuous statement:

"It is up to the user to keep this cache updated, on each host."

Now normally this isn't an issue for me, because when Cfengine is working, it's keeping this cache up to date. If the cache is destroyed, manual intervention is required (or additional automation outside Cfengine). Perhaps this is inline with Cfengine's design goals (or maybe my configuration is horribly twisted), but this definitely falls short of my expectations. Cfengine should be able to rebuild it's own cache. Something as simple as destroying a cache should not stop Cfengine from working. Or is there supposed to be another outside process which maintains Cfengine's cache and keeps it working. Another layer of management isn't all that appealing to me. Or should we just stop calling it a cache and claiming FHS compliance since it obviously contains critical configuration files?

How am I wrong here?

--
/* Wes Hardin */

________________________________________
From: help-cfengine-bounces+wes.hardin=maxim-...@cfengine.org [help-cfengine-bounces+wes.hardin=maxim-...@cfengine.org] On Behalf Of Brendan Strejcek [stre...@gmail.com]
Sent: Sunday, June 07, 2009 09:24 PM
To: Antonio Radici
Cc: help-c...@cfengine.org
Subject: Re: FHS regression

[Neil Watson]

I have cf backup important parts of /var/cfengine. Keys, update.cf and
binaries are all backed up to elsewhere. I have a shell script that
restores them if the agent fails to run. Thereafter the agent restores
the rest through normal runs.

[Mark Burgess]

This is also how we do it at cfengine. With Nova, there is even a
default failsafe so that all you need to know is the IP of the policy
server and everything else will reconstruct.

Matt Richards wrote:
> In the configuration I have, what I have on the client is irrelevant.
> As long as the failsafe exists, it will recover. If the failsafe
> doesn't exist, plop a new one in and it will rebuild itself. All the
> configuration comes from the server.

> _______________________________________________
> Help-cfengine mailing list
> Help-c...@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine

[Matt Richards]

[Matt Richards]

This is a difficult subject to broach. For some time I would patch the
code to be FHS compliant. Basically adding a BINDIR define to replace
some WORKDIR defines. However, recently I re-adopted the monolithic /
var/cfengine install and I never looked back. It make sense to me and
it is easier to install and maintain.

But that doesn't help you at all in you FHS dilema without patching
the code for each release. So this mail is basically a push. Sorry.



On May 9, 2009, at 4:52 PM, Guillaume Rousse