Il giorno 23/ago/08, alle ore 14:06, Krzysztof A. Adamski ha scritto:
First of all, the ebuilds. I'd like to refine them a little.
I'd split the overlord and minion setups with a USE flag. I think it
is correct to assume that only the overlord has a runtime dependency
on certmaster while the minions don't need it. Also, I see that the
source contains overlord/ and minion/ directories. Can the overlord/
one be safely removed from a minion setup?
No, certmaster is not only a daemon but also set of modules that
are used by BOTH minion and overlord. You need certmaster on both
of them.
I found it out the hard way :)
It needs to be installed on both, I saw import certmaster.something
stuff in the func source.
Now I should have it right: the certmaster daemon needs to be running
only on one system, the certmaster server, which usually is the
overlord but needs not to. And the funcd daemon needs to be running
only on the minions and not on the overlord, even if usually the
overlord system can also be a minion (and thus run funcd).
Of course we must not forget about the possibility of making local
calls to modules, which I'm discussing with you on irc while I write
this email :)
You can remove overlord/ directory from the minion (or at least it
should be possible.. if it's not, report bugs:)).
It's the next thing on my agenda for the ebuilds, I'll let you know.
After I sort that out I think the ebuilds will be ready for a first
public posting.
Yes, minion modules (and all others in the current GIT tree) are
loaded dynamically from proper directories on the filesystem. If
you remove the file it won't be loaded, that's all.
I already have this one in the ebuild. The only thing is that I have
to remove them _after_ "install" (portage installs in a temp
directory anyway before the actual merge) otherwise the setup will
complain. That's caused by the modules subdirectories, like (from
setup.py):
# FIXME if there's a clean/easy way to
recursively
# find modules then by all means do it,
for now
# this will work.
"%s/minion/modules.netapp" % NAME,
"%s/minion/modules.netapp.vol" % NAME,
"%s/minion/modules.iptables" % NAME
But removing them after install works out nicely. Now I conditionally
install these modules and their correct dependencies based on USE flags:
hardware.py (sys-apps/hal)
iptables (net-firewall/iptables)
nagios-check.py (net-analyzer/nagios-plugins)
smart.py (sys-apps/smartmontools)
snmp.py (net-analyzer/net-snmp)
this way I won't get modules on my system without their dependencies
in place.
For example, I think it would be good for func to detect the
system type at startup (eg., fedora/gentoo/bsd/solaris/whatever)
and store that in a variable, modules would use that info to
select correct defaults / behaviors.
There is no existing code for that so far. We have something like
modules configuration files that could be used to specify/tweak
some of the modules behavior. I haven't yet written any
documentation about that but it's quite simple. Not sure if it's
enough however.
this one seems better suited for a global minion config (could just
be a runtime variable - a thing like this should be autodetected and
not provided by the user) since it would be the same information for
all modules...
--
Luca Lesinigo
--
Luca Lesinigo
_______________________________________________
Func-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/func-list
