UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer
Hi,

The attached archive is take 3 of an update of sysutils/cfengine to version
3.4.2. This version explicitly disables libvirt because when libvirt was
installed it was build with libvirt.

I've chosen to disable libvirt because, to my knowledge, OpenBSD can't be
used as a (production) host for virtual machines. As Jirib suggested, it
can be used to remote control KVM via libvirtd, but the cfengine way would
be to install cfengine on the host that runs KVM and not to remote control
it. So there's no use for libvirt capabilities in cfengine on OpenBSD.

If there're no further objections, please commit so other people can also
start testing it.

Kind regards,


Martijn Rijkeboer

cfengine-take3.tgz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Todd T. Fries-2
Penned by Martijn Rijkeboer on 20130316  8:20.50, we have:
| Hi,
|
| The attached archive is take 3 of an update of sysutils/cfengine to version
| 3.4.2. This version explicitly disables libvirt because when libvirt was
| installed it was build with libvirt.
|
| I've chosen to disable libvirt because, to my knowledge, OpenBSD can't be
| used as a (production) host for virtual machines. As Jirib suggested, it
| can be used to remote control KVM via libvirtd, but the cfengine way would
| be to install cfengine on the host that runs KVM and not to remote control
| it. So there's no use for libvirt capabilities in cfengine on OpenBSD.
|
| If there're no further objections, please commit so other people can also
| start testing it.
|
| Kind regards,
|
|
| Martijn Rijkeboer

As I pointed out to the libvirt maintainer, libvirt should be enabled to use
the qemu engine that does work on OpenBSD.

Sure it is slower than real hardware, and because of this it makes little sense
to use for more than testing, but personally I find having a test network of
qemu instances useful to bring up now and then for various testing scenarios.

If libvirtd could make life easier for this, why would cfengine not be able to
help making sure the virtual network is virtually easy to maintain?

Point being, if it costs us nothing to enable libvirt support, why would we
disable it?

Thanks,
--
Todd Fries .. [hidden email]

 ____________________________________________
|                                            \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com            \  1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113      \  sip:[hidden email]
| "..in support of free software solutions." \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Jiri B-2
On Mon, Mar 18, 2013 at 09:33:55AM -0500, Todd T. Fries wrote:

> As I pointed out to the libvirt maintainer, libvirt should be enabled to use
> the qemu engine that does work on OpenBSD.
>
> Sure it is slower than real hardware, and because of this it makes little sense
> to use for more than testing, but personally I find having a test network of
> qemu instances useful to bring up now and then for various testing scenarios.
>
> If libvirtd could make life easier for this, why would cfengine not be able to
> help making sure the virtual network is virtually easy to maintain?
>
> Point being, if it costs us nothing to enable libvirt support, why would we
> disable it?

I'm for libvirt flavor but I think we should cooperate with
libvirt maintainer to have some libvirt-minimal without python
and other crazy things..., because cfengine then depends on huge
list of libs like avahi...

jirib


Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer
>> As I pointed out to the libvirt maintainer, libvirt should be enabled to
>> use the qemu engine that does work on OpenBSD.
>>
>> Sure it is slower than real hardware, and because of this it makes
>> little sense to use for more than testing, but personally I find
>> having a test network of qemu instances useful to bring up now and then
>> for various testing scenarios.
>>
>> If libvirtd could make life easier for this, why would cfengine not be
>> able to help making sure the virtual network is virtually easy to
>> maintain?
>>
>> Point being, if it costs us nothing to enable libvirt support, why would
>> we disable it?

By enabling libvirt support we add a lot of dependencies that are not
needed on almost all servers. I don't like to have python installed just
to be able to manage my servers with cfengine.


> I'm for libvirt flavor but I think we should cooperate with
> libvirt maintainer to have some libvirt-minimal without python
> and other crazy things..., because cfengine then depends on huge
> list of libs like avahi...

I don't mind having a libvirt flavor. I'll try to create a "take 4" version
with a libvirt flavor. Of course it would be nice to have a minimal libvirt
that doesn't depend on python but my time is limited so I'm not going to
push for that.

Kind regards,


Martijn Rijkeboer

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Todd T. Fries-2
Penned by Martijn Rijkeboer on 20130318 13:12.18, we have:
| >> As I pointed out to the libvirt maintainer, libvirt should be enabled to
| >> use the qemu engine that does work on OpenBSD.
| >>
| >> Sure it is slower than real hardware, and because of this it makes
| >> little sense to use for more than testing, but personally I find
| >> having a test network of qemu instances useful to bring up now and then
| >> for various testing scenarios.
| >>
| >> If libvirtd could make life easier for this, why would cfengine not be
| >> able to help making sure the virtual network is virtually easy to
| >> maintain?
| >>
| >> Point being, if it costs us nothing to enable libvirt support, why would
| >> we disable it?
|
| By enabling libvirt support we add a lot of dependencies that are not
| needed on almost all servers. I don't like to have python installed just
| to be able to manage my servers with cfengine.
|
|
| > I'm for libvirt flavor but I think we should cooperate with
| > libvirt maintainer to have some libvirt-minimal without python
| > and other crazy things..., because cfengine then depends on huge
| > list of libs like avahi...
|
| I don't mind having a libvirt flavor. I'll try to create a "take 4" version
| with a libvirt flavor. Of course it would be nice to have a minimal libvirt
| that doesn't depend on python but my time is limited so I'm not going to
| push for that.
|
| Kind regards,
|
|
| Martijn Rijkeboer

Given the dependency issue I hadn't thought of (sorry!) I think it makes
sense to work on the libvirt flavor after what you have submitted is in the
tree, given the lack of excitement for the concept, to avoid delaying your
work further ;-)

My $.02 ;-)
--
Todd Fries .. [hidden email]

 ____________________________________________
|                                            \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com            \  1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113      \  sip:[hidden email]
| "..in support of free software solutions." \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer
In reply to this post by Martijn Rijkeboer
> cfengine does not run after installation, either copy some basic
> policy files or provide real README.

Attached is a new version of the README is this what you meant?


> Event it is declared to be built statically it is not, thus it
> cannot run from /var/cfengine without /usr/local mounted. Which
> is quite ridiculous... :) I haven't been successful how to built
> it statically correctly :(

I didn't succeed either and since the official binaries are not statically
linked I don't think it will work.


> 1. patch for configure is useless, drop it
> 2. add FAKE_FLAGS += examplesdir="${PREFIX}/share/examples/cfengine
>    to meet OpenBSD standards

OK

Kind regards,


Martijn Rijkeboer

README (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Stuart Henderson
On 2013/03/18 22:42, Martijn Rijkeboer wrote:

> > cfengine does not run after installation, either copy some basic
> > policy files or provide real README.
>
> Attached is a new version of the README is this what you meant?
>
>
> > Event it is declared to be built statically it is not, thus it
> > cannot run from /var/cfengine without /usr/local mounted. Which
> > is quite ridiculous... :) I haven't been successful how to built
> > it statically correctly :(
>
> I didn't succeed either and since the official binaries are not statically
> linked I don't think it will work.
>
>
> > 1. patch for configure is useless, drop it
> > 2. add FAKE_FLAGS += examplesdir="${PREFIX}/share/examples/cfengine
> >    to meet OpenBSD standards
>
> OK
>
> Kind regards,
>
>
> Martijn Rijkeboer


| 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?



| 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.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer
> | 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.


> | 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.

Kind regards,


Martijn Rijkeboer

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Stuart Henderson
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").
...

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Jiri B-2
Updated to 3.4.4...

@sample files based on NetBSD port, mandatory is promises.cf,
failsafe.cf if promises.cf not found. promises.cf tries to
load other files... This is OK for local agent.

     1  @sample ${CFENGINE_BASE}/
     2  @sample ${CFENGINE_BASE}/masterfiles/
     3  @sample ${SYSCONFDIR}/cfengine/
     4  @sample ${SYSCONFDIR}/cfengine/cf-sketch-runfile.cf
     5  @sample ${SYSCONFDIR}/cfengine/controls/
     6  @sample ${SYSCONFDIR}/cfengine/controls/cf_agent.cf
     7  @sample ${SYSCONFDIR}/cfengine/controls/cf_execd.cf
     8  @sample ${SYSCONFDIR}/cfengine/controls/cf_monitord.cf
     9  @sample ${SYSCONFDIR}/cfengine/controls/cf_report.cf
    10  @sample ${SYSCONFDIR}/cfengine/controls/cf_runagent.cf
    11  @sample ${SYSCONFDIR}/cfengine/controls/cf_serverd.cf
    12  @sample ${SYSCONFDIR}/cfengine/def.cf
    13  @sample ${SYSCONFDIR}/cfengine/failsafe.cf
    14  @sample ${SYSCONFDIR}/cfengine/libraries/
    15  @sample ${SYSCONFDIR}/cfengine/libraries/cfengine_stdlib.cf
    16  @sample ${SYSCONFDIR}/cfengine/promises.cf
    17  @sample ${SYSCONFDIR}/cfengine/services/
    18  @sample ${SYSCONFDIR}/cfengine/services/init_msg.cf
    19  @sample ${SYSCONFDIR}/cfengine/update.cf

symlinks based on NetBSD port (we are not building it statically
anyway...).

# find /var/cfengine/ -type l -ls
   257    0 lrwxr-xr-x    1 root     wheel          15 Mar 20 02:17 /var/cfengine/bin -> /usr/local/sbin
   258    0 lrwxr-xr-x    1 root     wheel          13 Mar 20 02:17 /var/cfengine/inputs -> /etc/cfengine

removing some crap like (Free|Net)BSD ports...

post-extract:
        perl -i -pe \
                's|^sbin_PROGRAMS.*rpmvercmp||;' \
                ${WRKDIST}/ext/Makefile.in

I have no idea why these warning appear:

$ head -n3 pkg/PLIST
@comment $OpenBSD$
@extraunexec rm -rf ${SYSCONFDIR}/cfengine
@extraunexec rm -rf ${CFENGINE_BASE}

# pkg_delete -c cfengine                                                                                                                                              
cfengine-3.4.4: ok
Read shared items: ok
--- -cfengine-3.4.4 -------------------
File /etc/cfengine/cf-sketch-runfile.cf does not exist
File /etc/cfengine/controls/cf_agent.cf does not exist
File /etc/cfengine/controls/cf_execd.cf does not exist
File /etc/cfengine/controls/cf_monitord.cf does not exist
File /etc/cfengine/controls/cf_report.cf does not exist
File /etc/cfengine/controls/cf_runagent.cf does not exist
File /etc/cfengine/controls/cf_serverd.cf does not exist
File /etc/cfengine/def.cf does not exist
File /etc/cfengine/libraries/cfengine_stdlib.cf does not exist
File /etc/cfengine/promises.cf does not exist
File /etc/cfengine/services/init_msg.cf does not exist
File /etc/cfengine/update.cf does not exist
File /etc/cfengine/failsafe.cf does not exist
Error deleting directory /var/cfengine/masterfiles: No such file or directory
Error deleting directory /var/cfengine: No such file or directory
Error deleting directory /etc/cfengine/services: No such file or directory
Error deleting directory /etc/cfengine/libraries: No such file or directory
Error deleting directory /etc/cfengine/controls: No such file or directory
Error deleting directory /etc/cfengine: No such file or directory

And this is normal?

# /etc/rc.d/cfengine -d start
doing rc_read_runfile
usage: /etc/rc.d/cf_execd [-df] {start|check|reload|restart|stop}
doing rc_read_runfile
usage: /etc/rc.d/cf_serverd [-df] {start|check|reload|restart|stop}
doing rc_read_runfile
usage: /etc/rc.d/cf_monitord [-df] {start|check|reload|restart|stop}

TODO:
- logging to /var/log/cfengine, we can check Debian patch
- reame about bootstrapping from policy server
- mode for 'masterfiles'?

jirib

cfengine-3.4.4.tgz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Jiri B-2
In reply to this post by Stuart Henderson
On Tue, Mar 19, 2013 at 11:46:06AM +0000, Stuart Henderson wrote:

> > > | 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").

First of all, I'm not native English speaker :D What about this one?
Partly based on Debian package.

$OpenBSD$

+-----------------------------------------------------------------------
| Running ${FULLPKGNAME} on OpenBSD
+-----------------------------------------------------------------------

OpenBSD cfengine port has some tweaks differenting from standard cfengine
community installation.

As cfengine on OpenBSD is not built statically and depends on libraries
in ${LOCALBASE}, this questions auto-repairing funcionality of cfengine
itself which usually (as it is for cfengine enterprise edition) it is built
statically and runs self-governingly from /var/cfengine.

For upstream compability cfengine on OpenBSD has following symlinks:

    /var/cfengine/inputs -> ${SYSCONFDIR}/cfengine
    /var/cfengine/bin -> ${LOCALBASE}/sbin

During installation cfengine key was generated in ${CFENGINE_BASE}/ppkeys
and sample configuration files places in ${SYSCONFDIR}/cfengine to offer
a user quick start-up with cfengine.

In most of your installations you will only need the cfagent with a proper
configuration file which would connect to policy hub for its up-to-date
policies.

For more info you should have a look at the reference manual and the relevant
docs:

        http://www.cfengine.org/manuals/cf3-reference.html

cf-report process could be limited by maximum number of openfiles defined in
daemon class, thus consider bumping the openfiles-cur to at least 256 in
login.conf(5).

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer

> First of all, I'm not native English speaker :D What about this one?
> Partly based on Debian package.

I'm also not a native English speaker...



> $OpenBSD$
>
> +-----------------------------------------------------------------------
> | Running ${FULLPKGNAME} on OpenBSD
> +-----------------------------------------------------------------------
>
> OpenBSD cfengine port has some tweaks differenting from standard cfengine
> community installation.
>
> As cfengine on OpenBSD is not built statically and depends on libraries
> in ${LOCALBASE}, this questions auto-repairing funcionality of cfengine
> itself which usually (as it is for cfengine enterprise edition) it is
> built
> statically and runs self-governingly from /var/cfengine.
>
> For upstream compability cfengine on OpenBSD has following symlinks:
>
>     /var/cfengine/inputs -> ${SYSCONFDIR}/cfengine
>     /var/cfengine/bin -> ${LOCALBASE}/sbin
>
> During installation cfengine key was generated in ${CFENGINE_BASE}/ppkeys
> and sample configuration files places in ${SYSCONFDIR}/cfengine to offer
> a user quick start-up with cfengine.
>
> In most of your installations you will only need the cfagent with a proper
> configuration file which would connect to policy hub for its up-to-date
> policies.
>
> For more info you should have a look at the reference manual and the
> relevant
> docs:
>
>         http://www.cfengine.org/manuals/cf3-reference.html
>
> cf-report process could be limited by maximum number of openfiles defined
> in
> daemon class, thus consider bumping the openfiles-cur to at least 256 in
> login.conf(5).

Looks nice, this is definitely better than mine..


Kind regards,


Martijn Rijkeboer

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Stuart Henderson
On 2013/03/23 14:10, Martijn Rijkeboer wrote:
>
> > First of all, I'm not native English speaker :D What about this one?
> > Partly based on Debian package.
>
> I'm also not a native English speaker...

Here's an updated diff including a reworked README.

I removed cf_serverd from the cfengine rc script so that the typical
case of client machines can use the script, and just add cf_serverd
where needed.

Other tweaks, reordered @sample so the directories are near the
files (at first it looked like the directory @sample's were
missing..) and on the @extraunexec rm -rf lines, try a bit harder
to avoid deleting @sample'd directories (add /* to the end),
it will still hit some, but not as many.

Don't create symlinks via @exec-add, they do not get properly
registered in the PLIST. (This was a big problem with texlive and
we have a nasty workaround in the quirks package as a result).
I have moved them to post-install so they can be included in the
package properly. Also I am only linking the relevant programs
inside /var/cfengine/bin/ rather than linking the whole directory
(this helps pkg_add if we ever move to static binaries in
/var/cfengine/bin in the future).

The shared library version numbers *must* be controlled by the
ports infrastructure. I have changed the version to 0.0, as we do
by convention for a new library (partly done to prove that
controlling the version number does actually work). However this
does not currently work; cfengine's build will need to be patched
to get this fixed.


Big caveat:  I have been looking at this from a porter's point
of view, and the perspective of trying to get the README usable
by somebody who has not come across cfengine before. I have
*not* tried running it yet and my understanding of how things work
in the README might not be entirely correct, so my changes here
need checking. :)

Still to-do:

The key file added in @exec either needs to get registered
properly in the plist, or just avoid running this automatically
and tell people to do it in README instead (probably easier).


cfengine.diff (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Martijn Rijkeboer
After quite some discussion here's take 4 of the update of
sysutils/cfengine. This version is based on Stuart's version which was
based on Jiri B's version.

Notable differences with Stuart's version:
- Remove @sample for failsafe.cf in PLIST: Modern versions of cfengine use
  update.cf instead of failsafe.cf (there's an internal failsafe.cf).
- Remove @exec for cfkey in PLIST: The keys are not generated when
  installing (as suggested by Stuart), but a remark how to generate them
  is added to the README.
- Remove @sample for masterfiles in PLIST: This directory will be created
  by cfagent.
- Fix @mode for @sample files: Make configuration files 0600.
- Replace inputs symlink with directory: When /var/cfengine/inputs is a
  symlink bootstrapping won't work.
- Remove mysql flavor from FLAVORS: The mysql flavor currently won't build
  due to a bug in mysql.
- Patch /var/cfengine/inputs/update.cf: Remove creation of symlinks from
  /usr/local/sbin to /var/cfengine/bin/cf-*.
- Update README: Add instructions on how to create key pair and fix
  notable changes section.

Please commit so other people can start testing it.

Kind regards,


Martijn Rijkeboer

cfengine-3.4.4-take4.tgz (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.2 (take 3)

Martijn Rijkeboer
In reply to this post by Jiri B-2
> And this is normal?
>
> # /etc/rc.d/cfengine -d start
> doing rc_read_runfile
> usage: /etc/rc.d/cf_execd [-df] {start|check|reload|restart|stop}
> doing rc_read_runfile
> usage: /etc/rc.d/cf_serverd [-df] {start|check|reload|restart|stop}
> doing rc_read_runfile
> usage: /etc/rc.d/cf_monitord [-df] {start|check|reload|restart|stop}

Yes, if you don't specify the -d option the daemons are started.

Kind regards,


Martijn Rijkeboer

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Jiri B
In reply to this post by Martijn Rijkeboer
On Sat, Mar 23, 2013 at 09:44:09PM +0100, Martijn Rijkeboer wrote:
> Please commit so other people can start testing it.

It does not even build because of libpromises mentioned by Stuart.

--- src/Makefile.in.orig        Sat Mar 23 22:22:13 2013
+++ src/Makefile.in     Sat Mar 23 22:22:28 2013
@@ -526,7 +526,7 @@ LDADD = libpromises.la
 
 # libpromises
 projlib_LTLIBRARIES = libpromises.la
-libpromises_la_LDFLAGS = -version-info 1:0:0 -no-undefined
+libpromises_la_LDFLAGS = -version-info 0:0:0 -no-undefined
 libpromises_la_LIBADD = ../pub/libcfpub.la $(NOVA_LDADD)
 libpromises_la_CFLAGS = $(AM_CFLAGS)

Questions:

* we do not want configuration files in /etc/cfengine like NetBSD,
  and Linux distros do?

  I am for symlink.

  I wanted to submit RFE upstream not to override ppkeys symlink,
  as I've thought it could be symlinked to /etc/cfengine too, as
  it is "configuration".

* There are some dirs in fake directory which are not part of PLIST.

* This is stupid output one gets with pkg_delete -c cfengine right
  after installation and running cf-key.

  See partial-cfengine... LOL. I really don't know how to solve
  this.

# pkg_delete -c cfengine                                                                                                                                              
Bogus symlink: /var/cfengine/bin/cf-agent
Bogus symlink: /var/cfengine/bin/cf-execd
Bogus symlink: /var/cfengine/bin/cf-key
Bogus symlink: /var/cfengine/bin/cf-monitord
Bogus symlink: /var/cfengine/bin/cf-promises
Bogus symlink: /var/cfengine/bin/cf-report
Bogus symlink: /var/cfengine/bin/cf-runagent
Bogus symlink: /var/cfengine/bin/cf-serverd
cfengine-3.4.4: ok
Read shared items: ok
--- -cfengine-3.4.4 -------------------
File /var/cfengine/inputs/cf-sketch-runfile.cf does not exist
File /var/cfengine/inputs/controls/cf_agent.cf does not exist
File /var/cfengine/inputs/controls/cf_execd.cf does not exist
File /var/cfengine/inputs/controls/cf_monitord.cf does not exist
File /var/cfengine/inputs/controls/cf_report.cf does not exist
File /var/cfengine/inputs/controls/cf_runagent.cf does not exist
File /var/cfengine/inputs/controls/cf_serverd.cf does not exist
File /var/cfengine/inputs/def.cf does not exist
File /var/cfengine/inputs/libraries/cfengine_stdlib.cf does not exist
File /var/cfengine/inputs/promises.cf does not exist
File /var/cfengine/inputs/services/init_msg.cf does not exist
File /var/cfengine/inputs/update.cf does not exist
Files kept as partial-cfengine-3.4.4 package
Error deleting directory /var/cfengine/inputs/services: No such file or directory
Error deleting directory /var/cfengine/inputs/libraries: No such file or directory
Error deleting directory /var/cfengine/inputs/controls: No such file or directory
Error deleting directory /var/cfengine/inputs: No such file or directory
Error deleting directory /var/cfengine/bin: No such file or directory

jirib

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Stuart Henderson
[trimmed cc's]

On 2013/03/23 18:49, Jiri B wrote:

> On Sat, Mar 23, 2013 at 09:44:09PM +0100, Martijn Rijkeboer wrote:
> > Please commit so other people can start testing it.
>
> It does not even build because of libpromises mentioned by Stuart.
>
> --- src/Makefile.in.orig        Sat Mar 23 22:22:13 2013
> +++ src/Makefile.in     Sat Mar 23 22:22:28 2013
> @@ -526,7 +526,7 @@ LDADD = libpromises.la
>  
>  # libpromises
>  projlib_LTLIBRARIES = libpromises.la
> -libpromises_la_LDFLAGS = -version-info 1:0:0 -no-undefined
> +libpromises_la_LDFLAGS = -version-info 0:0:0 -no-undefined

this needs to be under control of the port i.e. pass in the version from the makefile

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Martijn Rijkeboer
In reply to this post by Jiri B

>> Please commit so other people can start testing it.
>
> It does not even build because of libpromises mentioned by Stuart.

I must have done something wrong since the submitted version is running
on my machine for the last 24 hours without problems. Anyway, sorry for
submitting something that doesn't even build, my bad.


> * we do not want configuration files in /etc/cfengine like NetBSD,
>   and Linux distros do?
>
>   I am for symlink.

As stated in my mail, bootstrapping didn't work with the symlinked inputs
directory. This could be an issue with my policy or a general issue. In
the end I would rather stick to what cfengine.com is doing than to adopt
something because Linux and NetBSD are doing it that way. Mark Burgess,
the author of Cfengine, is a very smart guy and designed it this way with
good reasons...


>   I wanted to submit RFE upstream not to override ppkeys symlink,
>   as I've thought it could be symlinked to /etc/cfengine too, as
>   it is "configuration".

I don't mind having the ppkeys in /var/cfengine, but I also don't mind
having them in /etc/cfengine either as long as it doesn't create more
porting work.


> * This is stupid output one gets with pkg_delete -c cfengine right
>   after installation and running cf-key.
>
>   See partial-cfengine... LOL. I really don't know how to solve
>   this.

Before I saw Stuart's mail I was working on @exec-add the directories and
than @sample the configuration files to prevent these errors. But since
Stuart is way more knowledgeable in this area, I went with his setup.

Besides the @exec-add option we could also opt for something like the
following in the README and don't install anything in /var/cfengine.

  Getting started
  ===============
  During installation sample configuration files are placed in
  ${LOCALBASE}share/examples/cfengine/CoreBase/. Before you can use
  Cfengine you need to create a public and private key pair by executing
  cf-key as root. You should also copy the sample configuration files to
  /var/cfengine/inputs/ and edit them to suit your needs.

When the user runs cf-key the needed directories will be created by
cf-key with the right permissions.

Kind regards,


Martijn Rijkeboer

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Timo Myyrä-4
In reply to this post by Martijn Rijkeboer
"Martijn Rijkeboer" <[hidden email]> writes:

> After quite some discussion here's take 4 of the update of
> sysutils/cfengine. This version is based on Stuart's version which was
> based on Jiri B's version.
>
> Notable differences with Stuart's version:
> - Remove @sample for failsafe.cf in PLIST: Modern versions of cfengine use
>   update.cf instead of failsafe.cf (there's an internal failsafe.cf).
> - Remove @exec for cfkey in PLIST: The keys are not generated when
>   installing (as suggested by Stuart), but a remark how to generate them
>   is added to the README.
> - Remove @sample for masterfiles in PLIST: This directory will be created
>   by cfagent.
> - Fix @mode for @sample files: Make configuration files 0600.
> - Replace inputs symlink with directory: When /var/cfengine/inputs is a
>   symlink bootstrapping won't work.
> - Remove mysql flavor from FLAVORS: The mysql flavor currently won't build
>   due to a bug in mysql.
> - Patch /var/cfengine/inputs/update.cf: Remove creation of symlinks from
>   /usr/local/sbin to /var/cfengine/bin/cf-*.
> - Update README: Add instructions on how to create key pair and fix
>   notable changes section.
>
> Please commit so other people can start testing it.
>
> Kind regards,
>
>
> Martijn Rijkeboer

Hi,

I just started learning cfengine and tested this port.
I tried the motd.cf from cfengine samples and it didn't get all the values on
OpenBSD. It worked fine on Linux. After checking the code it seems cfengine uses
/proc to gather its data which should be patched to use sysctl.

I patched the cpu detection bit of the motd example but it still lists my
interfaces as "$(interfaces_str)" instead with their name. It gets the interface
address though. I haven't found where does it assign the interfaces_str values.

Welcome to mandrake.wickedbsd.net!
This system is managed by CFEngine.
The policy was last updated on Wed Apr 24 19:05:10 2013.
The system has 4 cpus.
Network interfaces on this system are $(interfaces_str),
and the ip-addresses assigned are 10.0.0.3.


Here's patch to get the cpu count:
$ cat /usr/ports/mystyff/sysutils/cfengine/patches/patch-src_sysinfo_c
$OpenBSD$
--- src/sysinfo.c.orig Wed Apr 24 22:22:58 2013
+++ src/sysinfo.c Wed Apr 24 22:26:09 2013
@@ -36,6 +36,12 @@
 # include <zone.h>
 #endif

+#if (__OpenBSD__)
+#include <sys/param.h>
+#include <sys/sysctl.h>
+#include <err.h>
+#endif
+
 void CalculateDomainName(const char *nodename, const char *dnsname, char *fqname, char *uqname, char *domain);

 #ifdef LINUX
@@ -2100,6 +2106,17 @@ const char *GetWorkDir(void)

 static void GetCPUInfo()
 {
+#if defined(__OpenBSD)
+    int mib[2], count;
+    size_t len;
+    char buf[CF_BUFSIZE];
+
+    mib[0] = CTL_HW;
+    mib[1] = HW_NCPU;
+    len = sizeof(count);
+    if (sysctl(mib, 2, &count, &len, NULL, 0) == -1)
+        err(1, "sysctl");
+#else
     FILE *fp;
     char buf[CF_BUFSIZE];
     int count = 0;
@@ -2123,7 +2140,7 @@ static void GetCPUInfo()

     fclose(fp);
     count--;
-
+#endif
     if (count < 1)
     {
         CfOut(cf_verbose, "", " !! CPU detection makes no sense: got %d\n", count);

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: sysutils/cfengine 2.2.10 -> 3.4.4 (take 4)

Stuart Henderson
> "Martijn Rijkeboer" <[hidden email]> writes:
>
> > After quite some discussion here's take 4 of the update of
> > sysutils/cfengine. This version is based on Stuart's version which was
> > based on Jiri B's version.
..
> > Please commit so other people can start testing it.

Okan, these diffs change MAINTAINER to you but I haven't seen much
activity in the recent list posts, are you still interested in this?

On 2013/04/25 07:29, Timo Myyrä wrote:
>
>  #ifdef LINUX
> @@ -2100,6 +2106,17 @@ const char *GetWorkDir(void)
>
>  static void GetCPUInfo()
>  {
> +#if defined(__OpenBSD)

This one should be __OpenBSD__, however it would probably be better
to use sysconf(_SC_NPROCESSORS_CONF) for this if available; it's more
portable and should be easier to feed upstream. sysconf(3) itself is
POSIX; _SC_NPROCESSORS_CONF is not POSIX but is fairly common.

> +    int mib[2], count;
> +    size_t len;
> +    char buf[CF_BUFSIZE];
> +
> +    mib[0] = CTL_HW;
> +    mib[1] = HW_NCPU;
> +    len = sizeof(count);
> +    if (sysctl(mib, 2, &count, &len, NULL, 0) == -1)
> +        err(1, "sysctl");
> +#else
>      FILE *fp;
>      char buf[CF_BUFSIZE];
>      int count = 0;

12