[Dovecot] Better flagging of errors on logs?
Last night dovecot died because of time changed backward. I noticed that the line from dovecot read Oct 9 01:00:44 mailstore16 dovecot: Time just moved backwards by 132 seconds. This might cause a lot of problems, so I'll just kill myself now. Shouldn't such lines have the word Error or Fatal? If I set the log_path = to a file, will syslog messages still be generated?
Re: [Dovecot] Replication plans
Troy Benjegerdes writes: But that's currently not *really* replicated. The real question I guess is why not use a cluster/distributed/san filesystem like AFS, GFS, Because those distribute filesystems may be more difficult to setup, more difficult to maintain and may be less portable than a dovecot solution. For example Gluster sounds really like a great distributed filesystem, but it currently does not work in FreeBSD. If the company I work for wanted to use Gluster we would need to either learn Linux or hire someone to setup and maintain the linux boxes for us. I'd suggest that multi-master replication be implemented on a per-mailbox basis I suggest we forget about multi-master for now. :-) Some of us would rather see something sooner rather than later. I like the idea of dovecot having a built-in proxy/redirect ability so a cluster can be done with plain old round-robin DNS. Round-robin DNS is ok for a small setup, but not good enough for larger setups. most cases, if there's a dead server in the round-robin DNS pool, most clients will retry automatically, or the user will get an error And you will get dozens of calls of users asking what is going on, and why are things slow, etc. etc... and there goes half your morning/afternoon. Even with a small TTL outlook is so flaky that often times after a brief problem outlook needs to be rebooted. Where I work we may have a 15 minute problem that takes us 2 hours of calls to handle.. in large part because of outlook or people just wanted to know what happened.. and expecting a call back with an explanation. Failover needs to be seemless and without error. Either have a proxy from dovecot in front or a load balancer.
Re: [Dovecot] Getting rid of the common newbie problems
Timo Sirainen writes: 1) Split the config files, so the less used settings are separate files I think that would be good. Specially if you could have a tool chain that would produce both files from one source. 2) Remove some of the settings completely from dovecot-example.conf, although they could still exist (mail_cache_fields, mail_never_cache_fields at least) Are these settings only needed for debugging? Would they be documented anywhere? 3) Make the comments smaller and add more pointers to docs/wiki/ files. Good.
Re: [Dovecot] Replication plans
Timo Sirainen writes: Then there are also people who would want to run Dovecot on their laptop and have it synchronize with the main server whenever network connection is available. YES! I had not thought of that, but that would be killer.. although that would be multi-master which I think would be really difficult to implement.. :-( I was hoping to find an existing global lock manager. I think there exist some. If not, then I'll have to spend some more time thinking about it. Anyway everyone don't want to use AFS, so I can't rely on it :) It is not that people dont want.. it is that some times they can't. For example where I work we are keeping a close eye on Gluster, but it currently does not work in FreeBSD. Some of the other distrbibuted filesystems are either not as mature in FreeBSD or are non existent.
Re: [Dovecot] Getting rid of the common newbie problems
Timo Sirainen writes: actually giving useful error messages. Often the admin is only looking at the log file where info messages go (eg mail.log) because Dovecot logs its startup message and login messages there, but not where the errors go (eg mail.err). This has happened even with people who in general are experienced sysadmins. I had problems with Dovecot because of it's logs when I first started. think that syslog should be default and to point it to mail.info level. If the user tries to setup the log variables errors should be sent to syslog mail.crit. I don't recall exact details, but I recall that when I first tried to use the log files I made a mistake and dovecot did not help me find the error. Logging to eg. /var/log/dovecot.log by default would be helpful here, but it's probably better to log via syslog by default. I agree on syslog as default. Cyrus logs to local6 by default. I think mail.info may be a better choice, although this may be somewhat OS dependant. Many people may not even know where their syslog configuration file is or even how to configure it. Because of this whatever is the most commonly used syslog call may be the best choice. In FreeBSD there is a default mail.info. Anyone familiar with Linux Distros and/or other BSDs know how common is an entry for mail.info in syslog.conf.
Re: [Dovecot] Replication plans
Timo Sirainen writes: Master keeps all the changes in memory until slave has replied that it has committed the changes. If the memory buffer gets too large (1MB?) Does this mean that in case of a crash all that would be lost? I think the cache should be smaller. because the slave is handling the input too slowly or because it's completely dead, the master starts writing the buffer to a file. Once the slave is again responding the changes are read from the file and finally the file gets deleted. Good. If the file gets too large (10MB?) it's deleted and slave will require a resync. Don't agree. A large mailstore with Gigabytes worth of mail would benefit from having 10MB synced... instead of re-starting from scratch. Master always keeps track of user/mailbox - last transaction sequence in memory. When the slave comes back up and tells the master its last committed sequence, this allows the master to resync only those mailboxes that had changed. I think a user configurable option to decide how large the sync files can grow to would be most flexible. the whole slave. Another way would be to just mark that one user or mailbox as dirty and try to resync it once in a while. That sounds better. A full resync can be very time consuming with a large and busy mailstore. Not only the full amount of data needs to be synced, but new changes too. queues. The communication protocol would be binary Because? Performance? Wouldn't that make debugging more difficult? dovecot-replication process would need read/write access to all users' mailboxes. So either it would run as root or it would need to have at least group-permission rights to all mailboxes. A bit more complex solution would be to use multiple processes each running with their own UIDs, but I think I won't implement this yet. For now pick the easiest approach to get this first version out. This will allow testers to have something to stress test. Better to have some basics out.. get feedback.. than to try to go after a more complex approach; unless you believe the complex approach is the ultimate long term best method. But it should be possible to split users into multiple slaves (still one slave/user). The most configurable way to do this would be to have userdb return the slave host. Why not just have 1 slave process per slave machine? This is the most important thing to get right, and also the most complex one. Besides replicating mails that are being saved via Dovecot, I think also externally saved mails should be replicated when they're first seen. This is somewhat related to doing an initial sync to a slave. Why not go with a pure log replication scheme? this way you basically have 3 processes. 1- The normal, currently existing programs. Add logs to the process 2- A Master replication process which listens for clients requesting for info. 3- The slave processes that request infomation and write it to the slave machines. With this approach you can basically break it down into logical units of code which can be tested and debugged. Also helps when you need to worry about security and the level at which each component needs to work. The biggest problem with saving is how to robustly handle master crashes. If you're just pushing changes from master to slave and the master dies, it's entirely possible that some of the new messages that were already saved in master didn't get through to slave. With my suggested method that, in theory, never happen. A message doesn't get accepted unless the log gets written (if replication is on). If the master dies, when it gets restarted it should be able to continue. - If save/copy is aborted, tell the slave to decrease the UID counter by the number of aborted messages. Are you planning to have a single slave? Or did you plan to allow multiple slaves? If allowing multiple slaves you will need to keep track at which point in the log each slave is. An easier approach is to have a setting based on time for how long to allow the master to keep logs. Solution here would again be that before EXPUNGE notifications are sent to client we'll wait for reply from slave that it had also processed the expunge. From all your descriptions it sounds as if you are trying to do Synchronous replicat. What I suggested is basically to use Asynchronous replication. I think synchronous replication is not only much more difficult, but also much more difficult to debug and maintain in working order over changes. Master/multi-slave -- Once the master/slave is working, support for multiple slaves could be added. With the log shipping method I suggested multi-slave should not be much more coding to do. In theory you could put more of the burden on the slaves to ask for their last transaction ID.. that they got onward.. so the master will not need to know anything extra to handle multi-slaves. After master/multi-slave is working, we're
Re: [Dovecot] Getting rid of the common newbie problems
Joseba Torre writes: there's no easy way to get rid of newbie problems: right now dovecot is quite a complex software I tried Cyrus once, and have been working with Courier for nearly 2 years before I tried Dovecot. In my opinion Dovecot is much simpler than Cyrus, but perhaps more complex than Courier. However I found the dovecot documentation to be very helpfull. The problem is how to make the documentation friendlier to people with little or no exprience managing a pop/imap server. common configs: - system users (using pam/passwd) - ldap (with a common conf) - mysql - postgresql Agree. Having samples and sections for those different configurations will go a long way to help new users.
Re: [Dovecot] Getting rid of the common newbie problems
Timo Sirainen writes: Set pop3_uidl_format setting in config file pop3_uidl_format setting is missing from config file Set pop3_uidl_format in config file How about: You have choosen to run POP3. The setting pop3_uidl_format needs to be set in the dovecot.conf file for the POP3 server to work. See examples in configuration file. If that is too long.. then: You have choosen to run POP3. Setting pop3_uidl_format needed in dovecot.conf
Re: [Dovecot] Getting rid of the common newbie problems
Timo Sirainen writes: # dovecot Error: POP3 enabled but pop3_uidl_format not set And don't let Dovecot come up?
Re: [Dovecot] Replication plans
Timo Sirainen writes: Why not go with a pure log replication scheme? this way you basically have 3 processes. 1- The normal, currently existing programs. Add logs to the process 2- A Master replication process which listens for clients requesting for info. 3- The slave processes that request infomation and write it to the slave machines. With this approach you can basically break it down into logical units of code which can be tested and debugged. Also helps when you need to worry about security and the level at which each component needs to work. I'm not completely sure what you mean by these. Basically the same as what I said, except just have imap/deliver simply send the changes without any waiting? I am basically suggesting to log all the changes to a log(s) and have a separate program handle passing on the information to the slaves. But isn't the point of the master/slave that the slave would switch on if the master dies? Yes. If you switch slave to be the new master, it doesn't matter if the logs were written to master's disk. Sure the message could come back when the master is again brought back I was thinking that once a master dies, next it it comes back it would be a slave and no longer master. This would, unfortunately imply, that any transactions that were not copied over would be lost. I don't understand what you mean. Sure the logs could timeout at some point (or shouldn't there be some size limits anyway?), but you'd still need to keep track of what different slaves have seen. I was thinking that it would be the slaves job to ask for data. Example pseudo transactions. Master gets transactions 1 through 100 Slave(s) start from scratch and ask from transactions starting at 1. Say one slave, let's call it A, dies at transaction 50 and another slave, say B, continues and goes all the way to 100. More transactions come and now we are up to 150. Slave B will ask for anything after 100. When Slave A comes back it would ask for anything after 50. The master simply gets a request for transactions after a given number so it doesn't need to keep track the status of each slave. possible. It would be easier to implement much simpler master-slave replication, but in error conditions that would almost guarantee that some messages get lost. I want to avoid that. If you think Synchronous replication is doable.. go for it. :-) it is a tradeoff of reliability vs speed. Specially as the number of slaves grow the communication will grow. Sure. I wasn't planning on implementing multi-slave or multi-master before the master/slave was fully working and stress testing showing that no mails get lost even if master is killed every few seconds (and each crash causing master/slave to switch roles randomly). Great idea.
Re: [Dovecot] Getting rid of the common newbie problems
Timo Sirainen writes: Is there a need to have both? I was thinking about just splitting the current dovecot-example.conf to example/*.conf or something I think this may be somewhat a matter of preference, but I would find it easier to have a simple file.. and a complete file. I would find it more difficult to have to look at two files, to combine them.
Re: [Dovecot] Any plans for storing messages on a database?
Troy Benjegerdes writes: I think you should at least try Coda, but don't spend too much time on it. It is mostly a research project. I don't know of anyone really using it in production use. Hmmm. Didn't know that. I knew it was a research project, but did not know it was not much in production. AFS has been in production at universities and a few fortune 500 companies for a long time, and several installations have upwards of 50,000 users. Good to know. Thanks. Specs wise Coda did sound much better, but maturity is a crucial element.
Re: [Dovecot] 200 pop3-login processes
Zbigniew Szalbot writes: I am using dovecot 1.0.0 and have only 5 pop3 users. However, I have counted over 200 pop3-loging processes. I just wonder if it is normal for dovecot (has been running maybe for 2-3 weeks after installing the stable verion). What is your login_processes_count in dovecot.conf?
Re: [Dovecot] Any plans for storing messages on a database?
Scott Silva writes: If you want to experiment with a inexpensive NAS with replication, look at Freenas. It can do nfs sharing and automatic replication with rsync. And it is free and based on Freebsd. Still immature, but it has a lot of promise. Our experience with FreeBSD+NFS has been less than stellar. We had a lot of issues when we tried to use NFS as a mailstore repository in FreeBSD.
Re: [Dovecot] Any plans for storing messages on a database?
John Rowe writes: gluster is looking extremely interesting although it's rather new. Thanks. Saw it on a list of distributed FS but didn't click on it. I was planning to take a look at AFS and Coda to start. Will also take a look at gluster, although so far it seems a Linux only FS.
Re: [Dovecot] Any plans for storing messages on a database?
Troy Benjegerdes writes: http://www.openafs.org/pipermail/port-freebsd/2007-February/000199.html The freebsd port looks like it might be a bit hairy yet though. AFS and CODA are on my list to check. Another user in this list mentioned Gluster. I must say gluster looks very interesting.
[Dovecot] Any plans for storing messages on a database?
Redudancy and recovering from a mailstore failure is one of the concerns I am trying to address where I work. Any plans to have Dovecot store emails in a database? NAS/SAN devices which do automatic replication to a second device are extremely expensive. I also don't see any distributed filesystem which is mature and available for the OS we use (FreeBSD). I recall at one point, many months back, Timo mentioned that perhaps storing the messages in the database was a possibility for the future. Any additional thoughts on this?
Re: [Dovecot] Shared mailbox plans
Steffen Kaiser writes: My statement is simply my point of view, that the API should be independed of the backend. LDAP, Postgresql, Mysql.. I think any of them is fine. I think anything BUT the initial setup that Timo mentioned. Files in the mailstore I think is the least scalable option.
Re: [Dovecot] Shared mailbox plans
Steffen Kaiser writes: Having ACLs in SQL allows companies to have a centralized place for all ACLs. Well, this statement is true for any backend, incl. LDAP. Correct. But many companies do not have a LDAP infrastructure. It is much easier to setup a Mysql DB and put a table for ACL than it is to setup an LDAP infrastructure.
Re: [Dovecot] Shared mailbox plans
Timo Sirainen writes: Keeping ACLs in SQL is different from keeping the whole mailbox data in SQL. Currently the ACL plugin supports only vfile backend, but it wouldn't be too difficult to add support for SQL backend. Having ACLs in SQL allows companies to have a centralized place for all ACLs. For instance our mail tables are generated from other tables. Users update the primary tables in a management screen. A program takes data from these primary tables and populates the appropriate tables. All backend mailstore machines connect to the database to get their information. If ACLs were on files one would have to have a specialized program to grab data from a centralized database to create the local files. For one machine that is likely ok but for many machines it starts to get complex (ie you have to sync all the programs accross all the servers to be up to date).
Re: [Dovecot] The folder 'Inbox' cannot contain items. Namespace problems
Francisco Reyes writes:
I took off the Mac support and myself and two co-workers that were helping
me test were about to call it a day. The co-worker testing the Mac support
tried it.. and it worked.
Reporting back.
It has been two days since we upgraded to rc29
No reports of problems on Mac or PC clients.
Our namespace looks like:
#courier-imap compatibility/Thunderbird
namespace private {
separator = .
prefix = INBOX.
inbox = yes
}
First RC that we have been able to get both Mac and PC clients to co-exist
without problems.
Re: [Dovecot] The folder 'Inbox' cannot contain items. Namespace problems
Timo Sirainen writes: On Mon, 2007-04-02 at 22:31 -0400, Francisco Reyes wrote: Based on some TCP dumps we did we noticed that Outlook was doing LIST, but no select (except at account) creation. Could you show me the tcpdumps? Will report back today. After we upgraded to r29 and had both namespaces Outlook and thunderbird broke. I took off the Mac support and myself and two co-workers that were helping me test were about to call it a day. The co-worker testing the Mac support tried it.. and it worked. It seems that after taking the second namespace off now Mac mail was also working (with r29). This is the first time I have been able to get PC and Mac to work at the same time. Will wait a day or two before reporting back. To give it some time for customers to report back in case of problems. I can't think of why that would happen. The namespace is used only if the client is sending broken commands. I will install rc29 in a test machine and set both namespaces, then do tcpdumps.
