[Operators] Notes from the 2009/06/09 Monthly meeting

[Pedro Melo]

Hi,

Some pre-meeting ideas where sent to the mailing list:

* http://mail.jabber.org/pipermail/operators/2009-May/000584.html
* http://mail.jabber.org/pipermail/operators/2009-June/000601.html


1. Radar

The idea of having a site that lists domains that have a XMPP service,  
and associated stats

(Ed: during the discussion the notion of radar and monitoring service  
seemed to merge, not sure if it should merge)

Domains could be added by anybody or by any means to the radar DB, the  
information collected is publicly available on a web site.

Mickael is worried about spam, if the database is available publicly  
or if the service allows listing of domains. The issue of database  
ownership was raised but not discussed.

Current consensus is:

* collect information from all domains found: how to find new domains  
was not discussed though;
* publish information on the radar site, but allow for opt-out:  
methods for opt-out where not discussed.

=> Possible next steps:

*  gather suggestions about how to collect new domains;
* methods to opt-out.

The radar should have some way to include information (description,  
URLs, logo) in the domain/service page. There where some discussion on  
how to do this, the consensus seems to be that a pubsub node @domain  
with a well known node would work. A IQ based fallback was also  
mentioned.

=> Possible next steps:

* specify types of payload: Articles (atom entries?) and "vcard" for  
the domain (meta data like contact address, URL, description) were  
mentioned as possible payloads.

A second method for radar metadata maintenance was discussed: domain/ 
service ops should be able to use a HTML form at the radar site to  
update the information.

The admins could authorize themselves to the radar web interface with  
a simple token sent with a <message> to the domain/service. After  
that, the ops can use the radar web interface to publish  
announcements, updates and other tweaks. Useful for downtimes.

A protocol using <presence> of the xmpp at domain jid to update the  
status of the domain/service was mentioned as a simple alternative to  
keep server status flowing.

There where some discussion about what is federation and if we can  
connect to the s2s port uninvited just because you have S2S DNS  
records. No clear consensus.

Current Radar examples:

* http://imtrends.com/
* http://74.125.155.132/search?q=cache:VuFw301LIFUJ:www.jabberes.org/servers/%3Fsort%3Dhas_pep%26order%3Ddesc+jabberes+list&cd=2&hl=en&ct=clnk&gl=us
* http://coccinella.im/servers/servers.html
* http://coccinella.im/servers/servers_by_pubsub_pep.html


2. Domain for the radar

Several proposals:

* radar.xmpp.net;
* xmpp-services.org;
* monitor.im;
* up.im;
* imradar.com / imradar.org (Ed: it seems that monitor and radar are  
the same project? I don't think they are.);
* uptime.im.


3. Monitoring

A service to monitor servers uptime was also discussed. Tobias is  
working on something like that. His current interface is at http://monitor.ayena.de 
.

The consensus seems to be that the monitoring should be done  
distributed, and reports would be send to a collector agent that would  
correlate the information.

Some (stpeter, melo) would like to see the Server Roster XEP used for  
monitoring, for example, having each server monitor all the servers in  
his roster.

Some domains where suggested to host this service:

* yourstatus.org;
* viewstatus.org;
* whatsup.im;
* bigbrother.im;

=> Possible next actions:

* ??;


4. Robots

robots.txt for xmpp: a version of the HTTP ad-hoc protocol for crawler  
control was discussed.

Several options for implementation - a new <feature> in disco#info.  
The robots.txt file would be available with a iq-based protocol or on  
a well known pubsub node on the server. the server vcard was also  
mentioned as a possible place for this

no further talk about what this robots.txt would contain. It was  
suggested to use the same format as HTTP but no discussion about if  
that is appropriate or workable....

=> Possible next actions:

* define a "robots.txt" format for XMPP use;



5. Domain admins

The topic of which JIDs should be accepted as domain admins was  
present through out the conversation. The xmpp at domain and owner at domain  
hard-coded addresses where noted, as was XEP-0157.

A disco#items method for discovering admin JIDs (using a well-known  
node value like 'urn:xmpp:valid-admins' for example) was also floated.  
Using a well known pubsub node @domain was also presented as an  
alternative.

There was no clear consensus but several people (Mickael, bear, melo)  
prefered a pubsub-based approach.


6. Other topics

A brave attempt by JMcA to bring the subject of a standard server  
configuration file format to ease the pain of switching servers.


Best regards,