On 2013/03/19 12:22, Martijn Rijkeboer wrote:
> > | Setup policy hub/server
> > | =======================
> > |
> > | To setup a policy hub/server execute the following commands as root:
> > |
> > | # mkdir /var/cfengine/masterfiles
> > | # cp -pR ${LOCALBASE}/share/cfengine/CoreBase/*
> > /var/cfengine/masterfiles
> > | # cf-agent --bootstrap --policy-server <own IP-address>
> >
> >
> > Would it be appropriate to @sample these in the PLIST?
>
> No because they're only needed on the policy hub and not on the policy
> clients and most systems will be policy clients.
I would @sample the directory, at least - it's one less step for users
to do, and it means that permissions/ownership will be consistent.
It's also missing @extraunexec for pkg_delete -c (note that the
commands are processed in order; so to avoid spurious errors, the
@extraunexec line to remove remove files inside a directory should
happen before the @sample line creating that directory).
>
> > | Edit login.conf
> > | ===============
> > |
> > | Consider bumping the openfiles-cur to at least 256 in login.conf(5) for
> > | the daemon class.
> >
> > I don't know cfengine at all but if this is for something running
> > as a daemon, better to provide an rc.d script and tell people to
> > add a dedicated class (see example in mysql readme). rc.d scripts
> > ensure that the correct class is used, whereas otherwise somebody
> > starting from a command line via sudo could easily end up using
> > another class.
>
> It's not used for one of the daemon, but for cf-report.
"daemon" wouldn't be the right class then.. maybe something like this?:
...
Open file limits for cf-report
==============================
Users running cf-report may need to raise "openfiles" limits for the
relevant class in login.conf, or in their shell (e.g. "ulimit -n 256"
or "limit openfiles 256").
...
