0142 – Workgroups
This is for sending messages to roles. Several entities may join a Workgroup queue, and other entities may request chats with the workgroup (which then routes to the different entities when the chat is accepted by one of them). So, for alerting, we can send to the “alerting” workgroup, which will route to an appropriate AlertAgentBot.

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.

Two bits of news from Open-ILS, the uber-cool project aiming to create a distributed, open-source library automation system.

Yesterday they posted an article on using jabber as their communication system:

I’d like to share a word on communication. We’ve decided to start with Jabber (www.jabber.org) as the communication layer between the various components. Jabber is great because it can be as simple as you want while allowing for practically limitless expansion. Given the open nature of Jabber, for example, we could write our own server components that ‘plug in’ to the jabber server and perform additional tasks on messages besides simply routing them through the messaging network.

Today they posted their November Executive Committee Report, which is a “where we’re at” report. The “Teaching a Programmer” section is fun.

It’s bigger than this, actually, but it’s a start.

Jeremy Bowers (author of iRights) is doing great work on connecting Jabber to Radio. Lots of mind bombs here. Most of the IM crowd can’t see beyond simple chat etc., but the real gold is in making connections possible. Connecting desktop Web apps is the future of Jabber. [John Robb's Radio Weblog]

We’re actually going to hook lots of non-web apps together, too. Jabber is what DCE, CORBA, RMI, etc., could have been if they were open, simple, and had a natural ability to span firewalls, yet still be secure.

Now, IM is a way that we get our platform promulgated, but it’s also a key feature that other application-integration approaches don’t have. If users are running an application to chat with their friends, and tell if their friends are online, applications can use the same services to interact with users…

Jabber brings users and applications together with applications and users.

Jabber Documents:
* Email is too hard. Let’s junk it.
* Let’s get rid of electronic mail, once and for all
* P2P smuggled in under cover of darkness
* Publish-Subscribe Framework for Jabber
* RPC over Jabber

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

You can add <x> elements to presence stanzas!
Ths means you can have the <show> and <status> tags human readable, and pass machine parsable information around via additional <x> stanzas. We could definitely use Presence for system montitoring.

POE XMPP code:

POE::Lego, put a small POE::Lego stub at the edge, with enough logic to pull down the modules from a server bot. edit all modules centrally. pubsub would be hott.

  1. Agent connects
  2. Agents disco’s a “lego-server”
  3. Agent pubsubs to lego-server.. (something to catch future published updates).. Disconnected operation though…
  4. Cache it locally
  5. and then pubsub for updates
  6. which redo an eval

Here are the four challenges I see to writing this Jabber Monitoring System…

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

Okay, so the idea is that Jabber could be used as a platform for all sorts of distributed system management functions, first and foremost, local machine monitoring, and statistics delivery.

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.

Success/Failure report
Size of backup report