[Dovecot] 1.0.rc9 released
http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz.sig
Most importantly this should fix the login process problems that people have been reporting. There were also some bugs in the proxying feature.
Also note the 64bit change in dovecot.index.cache files. Unless you delete dovecot.index.cache files manually, you'll these kind of error messages into your logs:
Error: Corrupted index cache file ...dovecot.index.cache: registered field date.sent size changed
They'll get fixed automatically of course, but it might be a bit annoying to see them.
* 64bit systems: dovecot.index.cache file will be rebuilt because
some time fields have been changed from 64bit fields to 32bit
fields. Now the same cache file can be used in both 32bit and
64bit systems without it being rebuilt.
* Added libmysqlclient workaround to conflicting sha1_result symbol,
which caused Dovecot to fail logging into MySQL.
+ dovecot.index.cache file opening is delayed until it's actually
needed. This reduces disk accesses a bit with eg. STATUS commands.
+ auth_cache: Try to handle changing passwords automatically: If
password verification fails, but the last one had succeeded, don't
use the cache. This works only with plaintext auth.
- dovecot.index.cache: We didn't properly detect if some fields were
different length than we expected, which caused assert crashes
- Lots of fixes to login/master process handling
- mbox: Fixed a bug causing "X-IMAPbase uid-last unexpectedly lost
in mbox file" errors, and possibly others.On Oct 13, 2006, at 17:11, Timo Sirainen wrote:
- Added libmysqlclient workaround to conflicting sha1_result symbol, which caused Dovecot to fail logging into MySQL.
They fixed that in MySQL, too (4.1.18+ and 5.0.19+): http://bugs.mysql.com/13944
:-)
- ask
On Fri, 2006-10-13 at 17:13 -0700, Ask Bjørn Hansen wrote:
On Oct 13, 2006, at 17:11, Timo Sirainen wrote:
- Added libmysqlclient workaround to conflicting sha1_result symbol, which caused Dovecot to fail logging into MySQL.
They fixed that in MySQL, too (4.1.18+ and 5.0.19+): http://bugs.mysql.com/13944
I know, but since people keep complaining about this problem they clearly haven't all upgraded to new enough version..
Maybe I can remove the workaround in a year or so :)
On 2006-10-14 03:17:43 +0300, Timo Sirainen wrote:
On Fri, 2006-10-13 at 17:13 -0700, Ask Bjørn Hansen wrote:
On Oct 13, 2006, at 17:11, Timo Sirainen wrote:
- Added libmysqlclient workaround to conflicting sha1_result symbol, which caused Dovecot to fail logging into MySQL.
They fixed that in MySQL, too (4.1.18+ and 5.0.19+): http://bugs.mysql.com/13944
I know, but since people keep complaining about this problem they clearly haven't all upgraded to new enough version..
Maybe I can remove the workaround in a year or so :)
maybe in 3-4 ;)
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On 2006-10-14 03:11:05 +0300, Timo Sirainen wrote:
http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz.sig
http://software.opensuse.org/download/server:/mail/
has new rpms for various suse releases.
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marcus Rueckert schrieb:
On 2006-10-14 03:11:05 +0300, Timo Sirainen wrote:
http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz.sig
http://software.opensuse.org/download/server:/mail/
has new rpms for various suse releases.
darix
Wow, that was quick, thx
Mit freundlichen Gruessen Best Regards Robert Schetterer
robert_at_schetterer_dot_org Munich / Bavaria / Germany https://www.schetterer.org https://www.schetterer.com/public-gpg-robert-schetterer.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32)
iD8DBQFFMK3YNxddAhXBw7QRAtpdAJ4nGDiuxc9QY0z3r2XNa9vP4DOxngCeNBqS 79dKYEhJS8J8njFBL95N5jg= =Khkt -----END PGP SIGNATURE-----
-- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber.
Timo Sirainen пишет:
http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz http://dovecot.org/releases/dovecot-1.0.rc9.tar.gz.sig
Most importantly this should fix the login process problems that people have been reporting. There were also some bugs in the proxying feature.
Also note the 64bit change in dovecot.index.cache files. Unless you delete dovecot.index.cache files manually, you'll these kind of error messages into your logs:
Error: Corrupted index cache file ...dovecot.index.cache: registered field date.sent size changed
They'll get fixed automatically of course, but it might be a bit annoying to see them.
- 64bit systems: dovecot.index.cache file will be rebuilt because some time fields have been changed from 64bit fields to 32bit fields. Now the same cache file can be used in both 32bit and 64bit systems without it being rebuilt.
- Added libmysqlclient workaround to conflicting sha1_result symbol, which caused Dovecot to fail logging into MySQL.
- dovecot.index.cache file opening is delayed until it's actually needed. This reduces disk accesses a bit with eg. STATUS commands.
- auth_cache: Try to handle changing passwords automatically: If password verification fails, but the last one had succeeded, don't use the cache. This works only with plaintext auth.
- dovecot.index.cache: We didn't properly detect if some fields were different length than we expected, which caused assert crashes
- Lots of fixes to login/master process handling
- mbox: Fixed a bug causing "X-IMAPbase uid-last unexpectedly lost in mbox file" errors, and possibly others.
Sorry for importunity, but what about kqueue 100% cpu load fix? In rc8 notes it was marked with '-' sign, but in rc9 notes there is no status of kqueue problem at all ;-) I'm waiting for kqueue fix to start process of improving mail service by adding dspam and another things :)
-- С уважением, Савчук Тарас ООО "Элантек" : Аутсорсинг ИТ, WEB-разработка http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 575 22 11
On Sat, 2006-10-14 at 22:04 +0400, Taras Savchuk wrote:
Sorry for importunity, but what about kqueue 100% cpu load fix? In rc8 notes it was marked with '-' sign, but in rc9 notes there is no status of kqueue problem at all ;-)
I haven't heard any reports about it since rc8 release, but as far as I know it fixed it.
On Sat, 2006-10-14 at 03:11 +0300, Timo Sirainen wrote:
Most importantly this should fix the login process problems that people have been reporting.
Or not. I'm getting tired of that crap.
A bit over a year ago I rewrote the master process and its communication with login process. I also made config and log handling separate processes. I decided then not to use it since it was such a large change and v1.0 release was near (yea, right ;).
I spent today upgrading that code to contain the newest changes from CVS and fixing it in general. All of these login process problems seem to have gone away after using that code. Also it seems to be much faster than the old code.
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
One problem with the rewrite is that some settings in configuration file will change. Although I guess I could add backwards compatibility for most of them..
In case you're interested, this is how the native config looks like: http://dovecot.org/tmp/dovecot-1.conf
I was anyway going to separate all the service {} blocks to a separate dovecot-master.conf so that normally users would know not to edit it.
Also note that the service configuration makes it possible for services to have multiple listeners, ie. it's finally possible to make Dovecot listen in on multiple separate IP addresses. Or you could even create a UNIX socket where to listen for IMAP connections. :)
Timo Sirainen wrote:
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
I'd favour sticking with the existing processes until after 1.0 is released. A major change like that probably shouldn't happen at Release Candidate stage.
Having said that, I like the ideas suggested by the new config file. I've been very impressed with how flexible Dovecot already is, with multiple authentication databases, variable substitutions, namespaces etc. so this would be following in the grand tradition! The only downside is it makes it a little bit harder to follow the config file(s), but if it's commented as well as usual, it'll probably be fine.
As far as login process problems are concerned, I'm not terribly worried about the occasional failed login as long as Dovecot itself doesn't panic and stop accepting new connections. Perhaps Dovecot could try and keep going when the auth process dies (i.e fork a new one), though this may be slightly less secure and so should probably be an option. (Or I guess I could look at daemon-tools or other tricks to restart Dovecot if it dies.)
Best Wishes, Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Timo Sirainen wrote:
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
One problem with the rewrite is that some settings in configuration file will change. Although I guess I could add backwards compatibility for most of them..
Unfortunately at this stage, I don't think any major functionality changes are a good idea, however if we can get the final bugs cleaned up and get 1.0 out the door, I can see a very fruitful 1.1 release with this code ;)
Also note that the service configuration makes it possible for services to have multiple listeners, ie. it's finally possible to make Dovecot listen in on multiple separate IP addresses. Or you could even create a UNIX socket where to listen for IMAP connections. :)
I really like the new services concept, extremely flexible, well done as alway Timo, and I look forward to seeing it in 1.1 :P
Cheers, Pete
Peter Fern wrote:
Timo Sirainen wrote:
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
One problem with the rewrite is that some settings in configuration file will change. Although I guess I could add backwards compatibility for most of them..
Unfortunately at this stage, I don't think any major functionality changes are a good idea, however if we can get the final bugs cleaned up and get 1.0 out the door, I can see a very fruitful 1.1 release with this code ;)
I disagree...
Dovecot has been such a fast moving target anyway, I don't see any problem with making the change, as long as it is well documented, and well publicized.
That said, I don't guess its a big deal to just make the 1.0 release, then make this a 1.0.1 change...
:)
--
Best regards,
Charles
On Mon, 16 Oct 2006, Charles Marcus wrote:
Dovecot has been such a fast moving target anyway, I don't see any problem with making the change, as long as it is well documented, and well publicized.
That said, I don't guess its a big deal to just make the 1.0 release, then make this a 1.0.1 change...
I agree in principle with this last statement, except that to me it violates the principle of least astonishment to have a mandatory configuration file format change happen between 1.0 and 1.0.1. A change like should have a bigger change in version number in order to highlight it. When I see a change as small as 1.0 to 1.0.1, I tend to think only a few very minor changes have been made, or maybe only bug fixes.
- Logan
On Sat, Oct 14, 2006 at 11:13:52PM +0300, Timo Sirainen may have written:
On Sat, 2006-10-14 at 03:11 +0300, Timo Sirainen wrote:
Most importantly this should fix the login process problems that people have been reporting.
Or not. I'm getting tired of that crap.
I spent today upgrading that code to contain the newest changes from CVS and fixing it in general. All of these login process problems seem to have gone away after using that code. Also it seems to be much faster than the old code.
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
Personally, I would really like to be able to bind dovecot to a single IP address, so I would be in favor of the change. I understand many people really want 1.0 to come out, but it is just a number. There is no reason not to run beta or RC code when it is of the quality that dovecot has reached. 1.0 doesn't change the code.
That being said, would you (Timo) be willing to provide a patch/separate branch with this functionality in place?
Cheers,
On Sun, 2006-10-15 at 09:37 -0400, Brian T Glenn wrote:
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
Personally, I would really like to be able to bind dovecot to a single IP address, so I would be in favor of the change.
To just a single IP address? This is already possible:
listen = 1.2.3.4
That being said, would you (Timo) be willing to provide a patch/separate branch with this functionality in place?
I think I'll just put it to CVS HEAD once it's fully working. I could give a link to a tarball of it, but it's missing some features now (like I think only mbox code is working).
On Sun, Oct 15, 2006 at 04:49:31PM +0300, Timo Sirainen may have written:
On Sun, 2006-10-15 at 09:37 -0400, Brian T Glenn wrote:
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
Personally, I would really like to be able to bind dovecot to a single IP address, so I would be in favor of the change.
To just a single IP address? This is already possible:
listen = 1.2.3.4
I apologize. This should have been more specific. I would like to listen to a single public IP on the system as well as localhost.
That being said, would you (Timo) be willing to provide a patch/separate branch with this functionality in place?
I think I'll just put it to CVS HEAD once it's fully working. I could give a link to a tarball of it, but it's missing some features now (like I think only mbox code is working).
Well, without maildir, I wouldn't be able to use it. Once it is in CVS HEAD, I would be happy to test it.
Thanks!
http://www.delink.net/ If you want a language that doesn't believe in type checking at all, except when it does, try Python. Don't just toss it casually aside for the bizarre indentation-based syntax when there's so much else broken about it. - Peter Corlett in the monastery
Brian T Glenn wrote:
Personally, I would really like to be able to bind dovecot to a single IP address, so I would be in favor of the change. I understand many people really want 1.0 to come out, but it is just a number. There is no reason not to run beta or RC code when it is of the quality that dovecot has reached. 1.0 doesn't change the code.
There are plenty of reasons. However, the most important reason is that many people would like to have a stable branch and a development branch. That way the new wiz-bang feature can be in 1.1.1 and the bug fix which isn't likely to break anything can go into 1.0.1. If you don't do that, you'll never have stable bug free code, and people who need really stable bug free servers will be afraid to use dovecot.
The Linux kernel has similar issues. Linux used to have _3_ levels of code (the current dev tree, the current dev release, and the current stable release) and now only has 2. (there is no dev release) Again, I think that there are a lot of people who would prefer more of a separation between newly introduced code and their production servers.
That said, a lot of really smart people (Linus among them) have decided that for their project, the code would benefit more from more testers earlier in the process than it would from having that separation. So not having a development branch may not be a stupid idea.
But there clearly _is_ a reason to not run beta or rc code on production servers, and if dovecot doesn't have a stable branch (which is in many ways the case now, since pre rc code isn't supported anymore) then people who feel they need a stable branch which they can assume won't introduce new bugs can't use dovecot.
I personally fall somewhere in between those, I'll probably be willing to use dovecot to serve the mail for the college I work for even if there is no stable branch, but I'd feel much more comfortable if a stable branch existed. If bugs are introduced, I'll probably have to jump ship and use courier.
Ethan
--
Ethan Sommer Systems Administrator Gustavus Adolphus College 507-933-7042 sommere@gac.edu
On Sun, 15 Oct 2006, Brian T Glenn wrote:
Personally, I would really like to be able to bind dovecot to a single IP address, so I would be in favor of the change. I understand many people really want 1.0 to come out, but it is just a number.
It is just a number, but it should be a meaningful one. If a software package's version numbers are not going to be meaningful, it would be better to just use some number like a timestamp or serial number. If you use terms like "beta" and "release candidate" and version numbers like 1.0beta01 and 1.0, they should mean what people expect them to.
Just to throw my own opinion in here, if feature changes are being made, the clearest thing would be for the version numbers to go back to beta. That could mean going back to beta status on 1.0 (1.0beta20 or something), or it could mean going to beta status on 1.1 and just skipping the 1.0 release altogether. It wouldn't be a crime to go from 1.0rc10 to 1.1beta01 and for 1.0 to never exist. (It would delay the first release that is declared to be stable, though.)
- Logan
On Sat, 14 Oct 2006, Timo Sirainen wrote:
On Sat, 2006-10-14 at 03:11 +0300, Timo Sirainen wrote:
Most importantly this should fix the login process problems that people have been reporting.
Or not. I'm getting tired of that crap.
A bit over a year ago I rewrote the master process and its communication with login process. I also made config and log handling separate processes. I decided then not to use it since it was such a large change and v1.0 release was near (yea, right ;).
Does that mean it would (in theory, at least) fix the problem of logging from rsh/ssh connections (e.g. "ssh mailhost /etc/rimapd", where this invokes "/path/to/dovecot --exec-mail imap") going to a different place (stderr?) from normal IMAP connections?
Whilst I would appreciate seeing that resolved, nevertheless at this stage the important thing is probably to concentrate on getting 1.0 stabilised and fully released in the near future. So simply noting that this logging thing is a "known issue, believed to be minor, scheduled to be addressed later" would probably be sufficient.
I spent today upgrading that code to contain the newest changes from CVS and fixing it in general. All of these login process problems seem to have gone away after using that code. Also it seems to be much faster than the old code.
Now, I wonder if I still should try to get the login process bugs fixed from the old code tree, or just forget about that and use the rewrite..
My vote? I'm attempting to put dovecot into full user service. Having some sort of fix for the problem of the dying login process (discussed in the last week or so) is important. But important, too, is running a stable version (which "rc", by its very name, would not be).
Do both code trees somehow fix the "dying login process" problem?
If so, then perhaps keep 1.0 with the generally proven existing code and concentrate on releasing it soon, rather than inserting less-proven code, which would destabilise the stabilised "rc10" base and further delay official release.
One problem with the rewrite is that some settings in configuration file will change. Although I guess I could add backwards compatibility for most of them..
At an rc1 stage that would probably have been viable and good. But at this rc9/rc10 stage, so tantalisingly close to 1.0, I'd suggest against it. Ship 1.0 as soon as reasonably possible and add this later (1.1 or whatever).
Hope that helps. Best wishes.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
On Mon, 2006-10-16 at 11:17 +0100, David Lee wrote:
A bit over a year ago I rewrote the master process and its communication with login process. I also made config and log handling separate processes. I decided then not to use it since it was such a large change and v1.0 release was near (yea, right ;).
Does that mean it would (in theory, at least) fix the problem of logging from rsh/ssh connections (e.g. "ssh mailhost /etc/rimapd", where this invokes "/path/to/dovecot --exec-mail imap") going to a different place (stderr?) from normal IMAP connections?
Well, I'm not sure about that. :)
Do both code trees somehow fix the "dying login process" problem?
I think/hope it is now fixed in rc9 and rc10. But haven't heard any comments about that yet..
participants (12)
-
Ask Bjørn Hansen
-
Brian T Glenn
-
Charles Marcus
-
Chris Wakelin
-
David Lee
-
Ethan Sommer
-
Logan Shaw
-
Marcus Rueckert
-
Peter Fern
-
Robert Schetterer
-
Taras Savchuk
-
Timo Sirainen