Re: Porting func on gentoo

[Luca Lesinigo <luca@xxxxxxxxxxxxx>]

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
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list