On 10/13/2010 08:43 AM, Bron Gondwana wrote:
>
> Or you could do:
>
> stop cyrus
> ctl_mboxlist -d> mailbox_list.txt
> mv $confdir/mailboxes.db $confdir/mailboxes.db.unsorted
> add "improved_mboxlist_sort: 1" to /etc/imapd.conf
> ctl_mboxlist -u< mailbox_list.txt
> start cyrus
>
Thanks! This worked perfectly, and the messages (in mailboxes for which
they were inexplicably hidden) are now visible. It's still unclear how
the out-of-order sorting in mailboxes.db would trigger this.
This brings back the issue of a safe, canonical procedure for moving a
(single server) cyrus mail system to a new server. Since particularly
new users frequently have problems with this (including me, when I first
started using cyrus).
I'm thinking something like this. Suppose there were a command, say
called ctl_cyrusdb2, which offered the same features as ctl_mboxlist,
but could be used on any cyrus db file, e.g.
ctl_cyrusdb2 -d cyrus_db
dumps the cyrus_db database.. (The following also assumes ssh
authorized_keys have been set.)
On the old_cyrus_server:
-----------------------
stop cyrus
for i in `cat /var/lib/cyrus/cyrus_db_list`
do
ctl_cyrusdb2 -d $i | ssh new_server "cd /var/lib/cyrus &&
ctl_cyrusdb2 -u -"
done
(cd /var/spool/cyrus; tar cf - .) | ssh new_server "cd
/var/spool/cyrus && tar xpf - "
-----------------------
start cyrus on new_server and you're done -- a total of 4
command-line commands (viewing the for as a single command).
There are a few problems with this in addition to the absence of a
ctl_cyrusdb2, namely it's still unclear what cyrus db files are created
and why. On my system, I have:
annotations.db deliver.db mailboxes.db tls_sessions.db
but also have
db:
__db.001 __db.002 __db.003 __db.004 __db.005 __db.006
log.0000000001 skipstamp
and
user/[a-z]/{user_name.seen, user_name.sub}
Are the contents of db important for migration? And why isn't the stuff
in /var/lib/cyrus/user stored in the appropriate location in
/var/spool/cyrus? From the file names, this seems like important
metadata that users would want to see preserved. I suppose all this
could be handled with no extra knowledge on the admin user's part by
populating the /var/lib/cyrus/cyrus_db_list file only with the database
names necessary for successful replication of metadata.
Finally, I see many instances of the following error message in
/var/log/syslog:
Oct 14 16:33:01 www cyrus/imap[32001]: IOERROR: opening
/var/lib/cyrus/user_deny.db: No such file or directory
Apparently
touch /var/lib/cyrus/user_deny.db
is not a solution, either:
http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39304.html
2 questions about this:
1.
I have rsyslog configured to log all mail stuff to /var/log/mail.*; e.g.
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail.none,news.none -/var/log/messages
So why is anything from cyrus being written to syslog at all? This
message should be going to /var/log/mail.err, as far as I can tell. Is
this a compile-time error?
2.
Under any circumstance, shouldn't this error message be written to the
log files only when cyrus is started?
--
Patrick Goetz