On 9/14/10 8:55 AM, "no-re...@cfengine.com" <no-re...@cfengine.com> wrote:
> Forum: Cfengine Help
> Subject: Cfengine2 and diskless cluster
> Author: rpoyner
> Link to topic: https://cfengine.com/forum/read.php?3,18229,18229#msg-18229
>
> I have a couple of small clusters (~20 nodes each) that I manage, that I'd
> like to add to my cfengine2 setup. I've hesitated because I was unsure of the
> implications of having a bunch of machines running cfengine against the same
> nfs mounted root file system.
>
> Since all of the nodes use the same / they will all run cfengine once it's
> installed. My idea was to have only 1 or 2 of them actually do any management,
> and use classes to prevent the others from making any changes.
>
> Something like:
> no_run_node = ( )
>
> any.!no_run_node::
> configure me!
>
> I suspect there is a smarter way to do this based on the fact that / is
> mounted nfs. But what is it?
We have a handful of netboot clusters (we are generally moving away from it
for scalability reasons, but it is really nice for certain use cases). We
have a couple hosts which do management as well, and the others can not
write to anything but /var and /tmp. InfoSec loves it.
We had to come up with an easy way to define the notion of a "management
host" vs "a normal node". We originally used /etc/classes/* stuff and
FileExists for this purpose (in combination with hostname to identify the
management hosts). We then moved to "tags" in our inventory management
database, but the idea is really the same... A class that gets turned on
which represents "read-only /". Once the netboot class is defined, you can
just markup desired actions (or [not] import entire policies) based upon it.
The important concept is that you will have certain types of actions (like
processes and shellcommands) firing on the nodes (and possibly within your
netboot images), and others (like copy and files) only firing within the
images (on your management hosts with read-write access). We have a cron
which runs on the managemnet host, chroots into each managed image, and runs
cfengine there with a special read-write class. That, in conjunction with
the image name (which also gets turned into a class) gives us the required
control to turn policy actions on/off based upon image name and whether we
are in a read-write or read-only environment. Without this granular
control, you'll end up with "can't write to read-only" spam, runaway process
checks, etc.
--
Mike Hoskins : micho...@cisco.com : +1 (415) 506-UNIX (8649)
He knows not how to know who knows not also how to unknow.
-- Sir Richard Burton
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
