Dubot? What the heck it is?

dubot means Dial-Up Bot.

dubot is a glue between PPP over buggy phone line (even phone line by night can be noisy and modem can resign at its own; trust me, that happens to me) and pack of sending and retriving agents on the other side. dubot doesn't provide those agents, it only interfaces with them.

Formal description:

a.: Bring the transport up; the transport (it's supposed to be PPP, you know) is checked all the time.
b.: Then all agents that send something out are launched; limited number of agents run concurently.
c.: Those agents are waited to complete;
d.: When all outgoing agents complete, then agents that retrieve something are launced; the concurency of those agents is limited too.
e.: Now that pack of agents is waited;
f.: As soon as those agents complete, then transport is terminated happily;
g.: dubot terminates too.

While waiting for agents of push and pull groups, the agents of base group are monitored (IOW, default route should be present). In case network disappears, then the configuration of agents running is remembered, they are stopped, and transport is restarted. When network recovers, all agents that was stopped are SIGCONTed. Sounds nice?

Don't belive it! With current version that functionality has been broken. What is worse, I think this is impossible to recover. Look, agents by itself won't wait forever for link to appear --- they will timeout, you know. Currently, that will be noted, agents discarded, and if there is something to do yet, then activity will continue. That somewhat strange attitude will be changed in some later release.

Sounds nice, but does it do ...

dubot isn't an agent combine --- it doesn't provide all the services what waste bandwidth; it's purpose is ensuring the presence of transport and react if it disappears.

dubot depends on cron --- it doesn't know when to start and how long to last. In some future release dubot will feature internal scheduler, then, I hope, it will be easier to operate.

How it works.

dubot is supposed to be a cron-job. It even wouldn't need root permissions to run --- just ability to start pppd. However it need to launch some agents (mail queue clearer, mail retriever, etc.) with UID changed; that requires sudo and/or super set-up properly. Or run it as root, and use su (don't do it; one mustn't believe dubot to be security star; I stress, it's not). (In some upcoming version dubot will be nice, secure guy, then it can do those UID changes by itself).

dubot is full of XML magic. To monitor all services there 2 ways:

dubot does it by itself --- then dubot becomes one big and fat junk that swaps to and fro every couple of seconds... It's awful.
dubot uses some kind of helper; dubot goes second.

Here is one more fork:

helpers are static --- they must parse configuration files by itself, choose apropriate executables to run, they must be secure, etc... It's awful.
or those helpers would be genereted each time. dubot goes the 2nd (exciting) way.

There are 3 helpers (currently?); all of them are in Perl; after creating helpers are checked for syntax and taintles. There're two points about those checks:

any data retrieved from configuration file or acli library is written into and used by helper directly (no evaluation) --- that assures taintles;
OTOH, dubot doesn't sanitizes its input (pretty unsecure, egh?); That will be fixed sometime later.

Key helper's (named monit) duty is to assure that all requested aclis (of base group) are OK. monit knows 4 types:

process: those are waitpid(2)'ed; however, current design of monit isn't robust --- process type agents are checked when ticks happen;
demon: PID for demons are retrieved from *.pid or *.lock (whatever configured), then monit checks the PID to be present; however, there should be a bit of luck, monit even doesn't try to check the relations of pidfiles and demons;
host: hosts are ping(8)'ed;
file: directories are files --- you know.

The dependencies are missing (will be in upcoming). When monit finds that all aclis are OK, then dubot is SIGUSR1'ed; then 'monit' keeps on; if any acli terminate, then dubot is SIGUSR2'ed (that's darn unsecure) and monit restarts missing. That brain dead activity is continued until monit is SIGKILL'ed. That monit is such a bastard; all that signal ping-pong will turn into IPC of any kind, I promise.

Two other helpers (named push and pull) knows only two types: process and demon. They function other way; first of all: demons are waitpid(2)'ed (how? it's easy: helper launches small cycling monitor what dies when demon disapeares); in contrary with monit those two helpers wait until any acli terminates; then next one would be started; ``anyone'' means that at any time (almost up to the end of the run) some (hardcoded) number of aclis runs simultanously.

So what's the parpose of dubot itself? You should remember that dubot (as a package) is a glue, right? dubot as a command brews that glue. It reads configuration file and acli library (those all are in XML); then recreates helpers, checks them and start monit helper; then it waits for SIGUSR1, and immediatily starts push helper; as soon as the latter completes pull helpers follows; when pull helper exits, then everybody is happy.

Hmm... That's all.

And why I must pay for that crap!!!?

You don't. For any executable (even if one is a script, even if I forget to mention that clearly) --- license is GNU GPLv2, ``you know the drill''. For Dubot::* --- GNU LGPLv2 (drop me an email, if you find any use out of them, just a courisity). The license of documentation is unclear for me (I know some rumors that DGPL isn't free, in some sense); I'll do some investigation about that and mark that clearly later.

Author

Me. Almost everything is written from scratch. A bit of code was borrowed from Module::Build::Base (that code is marked as such). If I unintentionaly and blindly reused someone other's code --- I would like to know which and what. Eric Pozharski <whynot@ln.ua>

I admit, that the whole design was greatly influenced by monit package. Actually, dubot was born in attempts to get monit work as an agent shifting engine. Those attempts had failed, because monit doesn't fit in dubot's needs, because monit is designed with another circumstances in mind. Anyway,.. monit people! I apreciate time spent with (or against) your package (even if that means nothing for you). Thanks!

Let's Perl bless your network.

That html is awful :(

So what? it's lynx-friendly! :D

placeholder for logo (under constraction)

Produced with Website Meta Language