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

[Florian Thießen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

thanks for your summary.
I'm wondering if we want to separate radar and monitoring url-wise.
I agree those shouldn't be thought of as the same, but I think we should
provide them on the same website.

Florian T.

Pedro Melo schrieb:
> 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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoxO7MACgkQaeqoWtiIdZIPbgCeK+5ca0wqcCxktnNceHrUes4+
My0An3H0Y9MWJKJUm/W8dVYqkEMF/Upt
=c35E
-----END PGP SIGNATURE-----