Michael Potter <[email protected]> writes: > I would suggest you approach the problem this way: > > bundle common hostinfo { > > vars: > > hati:: > "ip" string => "192.168.1.2"; > > srv1:: > "ip" string => "192.168.1.3"; > } > > bundle agent test > { > classes: > "ok" expression => "any"; > > reports: > > ok:: > "$(hostinfo.ip)"; > }
Thanks, but I want to use cfengine as a configuration database and avoid
dublication of information.
My use case is: the DNS master of foo.example.net will generate its zone
file from informations stored in cfengine policy.
With storing one host information in one file under a host/ directory, I
can generate a list of hosts (/bin/ls -1 host/*).
Then, I want to iterate over that list to build my zone file for my DNS
master.
With this, I would just need manage one file per host in a directory, every
services[1] which need to access large amount of informations could use them.
I want to split my cfengine policy in two parts:
- an information database, host-centric
- an engine to apply it.
To manage a new service, I want to create a new "bundle agent
service_foo" like this:
bundle agent service_foo {
vars:
FooService::
listen_addresses slist => $($(sys.host)_ip),
comment => "Map the 'current' host ip list";
[...] # Manage the service
}
Then, I add the class definition to every host on which the service must
be configured.
To add a new host, I just need to create a new file, with all the
informations needed. I can look at a service bundle to see what variables
must I declare to configure this particular service if I don't remenber.
Are my intentions clearer?
Do they look insane?
Regards.
Footnotes:
[1] Like DNS, Nagios, cacti
--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1
pgpKOYG7453XN.pgp
Description: PGP signature
_______________________________________________ Help-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/help-cfengine
