Server diagnostics implemented

[chris coleman]

========Stefan wrote:=======================================


Hi all,
I implemented a new command "diagnostics" which outputs a summary of
your configuration and server details and exits. I believe this could be
handy for e.g. bug reporting. For now it outputs: Repository names, type,
host name, port, ssl. It reports whether a user could successfully
authenticate, and outputs IMAP server capabilities, as well as the imap
server welcome string giving us the server type and version.

Finally, it outputs a list of folders that offlineimap considers for
syncing and it reports to which folder it would sync if you have
nametrans enabled. (in my example below you would see that I have
nametrans= lambda x: 'INBOX.' + x and indeed it reports 'blla -> INBOX.blla')

Would this be useful for debugging and error reporting?
Sebastian

E.g. a run with my Gmail and IMAP server looks like this:
-----------------------------------------------------------------------------
./offlineimap.py diagnostics -a test
OfflineIMAP 6.3.4-rc2
Copyright (C) 2002 - 2010 John Goerzen <john at complete.org>

This software comes with ABSOLUTELY NO WARRANTY; see the file
COPYING for details.  This is free software, and you are welcome
to distribute it under the conditions laid out in COPYING.
Remote repository 'Remote-test': type 'Gmail'
Host: imap.gmail.com Port: 993 SSL: 1
Establishing connection to imap.gmail.com:993.
Server welcome string: * OK Gimap ready for requests from 62.48.118.215 a12if2762735faw.75
Server capabilities: ('IMAP4REV1', 'UNSELECT', 'IDLE', 'NAMESPACE', 'QUOTA', 'ID', 'XLIST', 'CHILDREN', 'X-GM-EXT-1', 'XYZZY', 'SASL-IR', 'AUTH=XOAUTH')

nametrans= lambda x: 'INBOX.' + x

Folderlist: ['INBOX -> INBOX.INBOX', 'Uni -> INBOX.Uni', '[Gmail]/All Mail -> INBOX.[Gmail]/All Mail', '[Gmail]/Drafts -> INBOX.[Gmail]/Drafts', '[Gmail]/Sent Mail -> INBOX.[Gmail]/Sent Mail', '[Gmail]/Spam -> INBOX.[Gmail]/Spam', '[Gmail]/Starred -> INBOX.[Gmail]/Starred', '[Gmail]/Trash -> INBOX.[Gmail]/Trash', 'blla -> INBOX.blla']


Local repository 'Local-test': type 'MappedIMAP'
Host: sub3.mail.dreamhost.com Port: None SSL: True
Establishing connection to sub3.mail.dreamhost.com:993.
Server welcome string: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE STARTTLS] Courier-IMAP ready. Copyright 1998-2008 Double Precision, Inc.  See COPYING for distribution information.
Server capabilities: ('IMAP4REV1', 'UIDPLUS', 'CHILDREN', 'NAMESPACE', 'THREAD=ORDEREDSUBJECT', 'THREAD=REFERENCES', 'SORT', 'QUOTA', 'IDLE', 'STARTTLS')

Folderlist: ['INBOX', 'INBOX.Bulk Mail', 'INBOX.Draft', 'INBOX.Drafts', 'INBOX.INBOX', 'INBOX.Inbox', 'INBOX.Sent', 'INBOX.Trash', 'INBOX.Trash.GMAIL.Spam', 'INBOX.Trash.GMAIL.Starred', 'INBOX.Trash.GMAIL.Trash', 'INBOX.Trash.INBOX', 'INBOX.Uni', 'INBOX.[Gmail].All Mail', 'INBOX.[Gmail].Drafts', 'INBOX.[Gmail].Sent Mail', 'INBOX.[Gmail].Spam', 'INBOX.[Gmail].Starred', 'INBOX.[Gmail].Trash', 'INBOX.blla', 'INBOX.old-messages']


Status repository 'Local-test': type 'LocalStatus'

===================================================


@Stefan, Very good idea to do this.  This should definitely be helpful for troubleshooting.  It would be a good idea to automatically include this diagnostics output when the user runs the -d debug command line option, so they don't have to run 2 debug commands when they have to submit the log file.

Already it's obvious that the Gmail capabilities is not showing uidplus, so it's working.

This is such a good idea that it makes you think, is it possible to get this diagnostics to produce more information, with just a few more method calls.  I'd be against writing any code more than just simple calls to existing methods because you want to be calling the same code that you run with.

Are there methods already written that could, for example, match up the remote/local folderlists, and show which folders would not get processed at all, and which folders will be created on the local or remote sides.

A method to match the remote and local capabilities, and say which are matching as expected, and also say if it's forced to fallback to an inefficient technique to do a particular operation on moving messages.

Detect and output mail server type and version, and generate a Rating based on capabilities and age of the release, and flag that so the user can see if their mailserver is outdated and should be upgraded.

Counts of messages, seen, deleted, other flags, in each folder of all the folderlists.  The date of the newest and oldest messages.  Whatever can be done to show a minimum expected amount of messages to be sync'd.

Anything else that the code can easily output, to indicate what it's intending to do, and if it's expected success, without actually changing any data on either server.


Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110630/969aad7f/attachment-0003.html>