Information about your Cyrus installation
Bron Gondwana
brong at fastmail.fm
Tue Feb 2 07:55:36 EST 2010
On Tue, Feb 02, 2010 at 02:13:45PM +0200, Jukka Huhta wrote:
> Sorry to answer off-list, but...
Taking it back to the list, because it's not secret - I'm pretty sure I've
posted most of it in bits and pieces before...
> On Thu, 28 Jan 2010, Bron Gondwana wrote:
>
> > * weekly "checkreplication" run that logs in as every single user on each
> > store and runs queries to ensure that exactly the same information is
> > presented via IMAP by both the master and replica. Has been very useful
> > for tracking down replication bugs, and is a good overall guarantee that
> > things are consistent!
>
> ...do you happen to be able to share that code, at least the main part
> of it?
Yep :)
> I would also be interested to check the consistency of the replica
> (we're taking backups there), but not very eager to invent the wheel
> again.
Sounds like a good plan!
> Of course, this kind of tool would be nice to be included in the tools
> or contrib dir of the main cyrus distribution tarball, but I'm not
> asking you to do that.
I fully intend to do that actually. The sticking points are:
1) we use Mail::IMAPTalk - in fact, we use ME::Mailbox, which is a wrapper
for Mail::IMAPTalk - in fact, we just get a list of users that we BELIEVE
are on the server and use $User->Mailbox() and $User->ReplicaMailbox()
on each one...
2) ... because, you have to log in as each user to actually see THEIR seen
state dammit.
The underlying reason for all this was to actually check the data as presented
to the user via IMAP - and this is a good thing because it's helped us to
debug some statuscache issues.
But - it's not ideal as a general tool because there's no general way to get
a listing of all users except to log in as admin - and if you do everything
as admin the poor admin user winds up with a VERY LARGE .seen file.
I'm thinking that the ideal might actually be to extend sync_server with the
bits I need to get a full internal view of what's going on. This also means
that I don't _need_ the FETCH DIGEST.SHA1 patch to be in the cyrus servers to
check that files are identical at both ends (corruption checking rocks)
Given an extended sync_server, it would probably be possible (if annoying...)
to write this thing in C and have it able to be run without needing too many
bits of extra information. That would be nice.
Bron ( maybe I just will write it in Perl though, because writing stuff to
do text manipulation in C gives me "doing it all by hand" headaches! )
More information about the Info-cyrus
mailing list