0095 – Stream Initiation
For setting up a binary stream between two entities. This is cool because it could let us push all system checks to the nodes over the JabberNet. So we have a core stub ManagementAgent on each managed node, and it just logs on, and bootstraps itself.

0137 – Publishing SI Requests
For publishing available binary streams (using pubsub). So now our binary distribution nodes can publish available code, and our ManagementAgent stub can see what’s available for pulling.

0135 – File Sharing
Provides a way for entities to publish files to other entities. This looks kinda like what 0137 does, except farther evolved.

Combined, a bootstrap would be something like:
* Agent starts
* Agent checks local cache for code, loading what’s necessary.
* Agent receives pubsub list of available code
* Agent downloads (and caches) what it needs.

0136 – Message Archiving
For using the Jabber server as a persistent message store. Provides a method of adding, updating , and removing items from the store. This could be used as an audit log for the Agents.

Patch Check Advanced makes it less painful– even pleasant.

It’ll automatically download the patch list from Sun, correlate it against what you have on your system, and present you with a list of what needs to happen. You can tell it to install all recommended patches, all security patches, or all the patches that don’t require a reboot (saving those for special occasions).

Extremely cool tool.

When people create RRDs, why do they try to cram as many DEFs into a single RRD as possible? Why not just give the RRD file a descriptive name, and store a single value named, perhaps, “value” ?

Why are people so stingy with the datapoints? Storing a whole year of data at 5 minute intervals is only a 3MB RRD.

Among them:
* Kitten’s Spaminator, which combines tarpitting (making multiple comments from the same source take longer and longer to post, in order to slow down bots), and a “three strikes” method, where the spammers IP is blocked after three spams.

• Kittens Spam Words, which gives you a “delete as spam” option, which automatically adds the email address, URL, and IP address to your Spam Words File.

• Laughing Lizard’s Comment Preview, just requires the user to click an extra button to post. Spambots aren’t smart enough to do that.

Not listed, but also VERY useful:
* URI Blocklist, which checks the URLs in your comments to see if they advertise known spammer sites.

In particular, is this bit of coolness: SoapBox. This is an LD_PRELOAD wrapper that monitors and records what changes an application makes to the filesystem. I’ve been looking for something like this for forever. It looks like you can place limits on what the user is allowed to do, too, making this a handy intermediary between a DAC system and going to a full MAC system.

DWall is a shorewall-like iptables front-end. This might be a replacement for shorewall in UMLazi.

DStat is kind of a cross between sar and vmstat/iostat. Might be easier to modify than sar.

Jabber Server Bits:
* Jabber::mod_perl – Mess with jabberd internals using perl
* ejabberd – A clusterable Jabber server written in erlang
* Jabber::RPC::HTTPgate – An HTTP/Jabber Gateway
* Jabber Notification Plugin for Nagios

Symbian OS Jabber Clients:
* IM+
* TipicME
* AgileMessenger

First: disconnected operation. What happens to messages if my clients aren’t able to contact the server?
Second: message formatting. How do I format these messages so they’ll be machine readable on the other side?

Third: guaranteed order. I want messages to be processed in a certain order.

Fourth: Receiving and processing the messages. How do we route the messages to the correct place? How do we write programs to deal with the incoming messages?

For monitoring, what do you think of Machines publishing a list of current statuses, and the monitoring server subscribing to those publications?

One TCP connection per agent. Interface to allow shell scripts to use it.

It would be nice to make this an extendable perl package that can reload itself dynamically (ala geektalk). We could then add system checks dynamically. ..Which we could push over Jabber!

Machines advertise their state via “Presence”. A PHP Jabber page can query all that presence and tell us how they are.

now, regarding XML-RPC messages… I think they should age out
Use Disco
Design Goal: Must be able to do 10K on off the shelf hardware.
Design Goal: Must not be heavy on the host agent.

Netmon: Have the MonitorBot write to the status database directly.

AdminBot: Converts natural language commands into JabberBot::RPC calls, also converts Agent responses into human readable text.

the would then subscribe to pubsub published sources, each agent would be the owner of it’s own pubsub published source.

• The Agent would disco announce itself as an “alertpublisher”.
• Alertbots would then disco search for all alertpublishers.
• they would then subscribe to pubsub published sources, each agent would be the owner of it’s own pubsub published source.
• in this way, the central alertbot would be aggressively discovering and subscribing, the agent would merely be announcing it’s disco and registering its published source with pubsub
• ..And when it actually had something to say, it would be publishing a single message, and the server would be responsible for disseminating it..
• ,..And the multiple alertbots could each subscribe to All or a Subset of agents.
• so a collection of pubsub and disco with the agent as the publisher

http://www.lambda-computing.com/projects/dnotify/
fake: provides IP-address takeover

Use Presence to determine if a system is up?
Notification of config changes.

When monitoring systems, create a spamassassin like scoring system to classify badness.

http://punjab.jabberstudio.org/ – Jabber over HTTP gateway

Send logs over Jabber. Watch logs and send interesting events over Jabber?

Have a jabberbot attach use DNotify to warn a central source of changes.

Backups:
Success/Failure report
Size of backup report