[Dovecot] v1.0 plans, rc11 tomorrow
As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :)
I've now read all the mails from this list again, and it looks like pretty much the only problems with rc10 was the mbox assert crash, which is now fixed.
My TODO contains:
v1.0 blocker:
- inetd logins are broken? I should look more into this.. I only remembered this just now while writing this mail.
New non-v1.0 blockers:
- trash plugin is apparently broken?
- mbox_min_index_size != 0 causes Invalid new transaction log sequence (4 >= 4)
The old preferrably-fixed-for-v1.0 items are:
- ldap auth is leaking memory? maybe not, maybe it's something else.
- master leaks log fds with kqueue. I don't have a machine to test this on. Could someone give me an account in some BSD system for a while to test this?
Anyway, I'll most likely release rc11 tomorrow, but it would be nice if you tested today's CVS snapshot already to see if I accidentally broke something. :) http://dovecot.org/nightly/dovecot-latest.tar.gz
Oh and one thing that I wanted for Dovecot v1.0 was nice documentation. I think the current wiki is a bit chaotic. I started http://wiki.dovecot.org/NewIndex a long time ago. Maybe I should finish it finally and put it as the new main index..
On Thu, November 2, 2006 23:29, Timo Sirainen wrote:
Anyway, I'll most likely release rc11 tomorrow, but it would be nice if you tested today's CVS snapshot already to see if I accidentally broke something. :) http://dovecot.org/nightly/dovecot-latest.tar.gz
Nov 3 09:23:43 palantir dovecot: imap-login: Login: user=ts@dreamcoder.dk, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Nov 3 09:23:43 palantir dovecot: IMAP(ts@dreamcoder.dk): mail_never_cache_fields: Invalid cache field name 'imap.envelope', ignoring Nov 3 09:23:44 palantir dovecot: IMAP(ts@dreamcoder.dk): file mail-cache-transaction.c: line 713 (mail_cache_add): assertion failed: (fixed_size == (unsigned int)-1 || fixed_size == data_size) Nov 3 09:23:44 palantir dovecot: child 14738 (imap) killed with signal 6
// Tom
On 3.11.2006, at 10.25, Tom Sommer wrote:
On Thu, November 2, 2006 23:29, Timo Sirainen wrote:
Anyway, I'll most likely release rc11 tomorrow, but it would be
nice if you tested today's CVS snapshot already to see if I accidentally
broke something. :) http://dovecot.org/nightly/dovecot-latest.tar.gzNov 3 09:23:43 palantir dovecot: imap-login: Login: user=ts@dreamcoder.dk, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Nov 3 09:23:43 palantir dovecot: IMAP(ts@dreamcoder.dk): mail_never_cache_fields: Invalid cache field name 'imap.envelope', ignoring Nov 3 09:23:44 palantir dovecot: IMAP(ts@dreamcoder.dk): file mail-cache-transaction.c: line 713 (mail_cache_add): assertion failed: (fixed_size == (unsigned int)-1 || fixed_size == data_size) Nov 3 09:23:44 palantir dovecot: child 14738 (imap) killed with
signal 6
Thanks, I noticed this myself also but then thought it had something
to do with switching between CVS HEAD and 1.0. Updated CVS, and the
snapshot is being rebuilt now also.
-- Start of PGP signed section.
As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :)
I wonder if I might add a request please. Would it be possible to offer an option which limits the per-user number of imap processes? We have users who gaily open 30 mail folders simultaneously. OK, 1 or 2 such users dont matter, but the number creeps up.
Also, would a PDF version of the wiki docs be possible? It is very handy to take something to read in bed...
And a big thank you for dovecot. We are migrating right now.
Cheers, Terry.
I've now read all the mails from this list again, and it looks like pretty much the only problems with rc10 was the mbox assert crash, which is now fixed.
My TODO contains:
v1.0 blocker:
- inetd logins are broken? I should look more into this.. I only remembered this just now while writing this mail.
New non-v1.0 blockers:
- trash plugin is apparently broken?
- mbox_min_index_size != 0 causes Invalid new transaction log sequence (4 >= 4)
The old preferrably-fixed-for-v1.0 items are:
- ldap auth is leaking memory? maybe not, maybe it's something else.
- master leaks log fds with kqueue. I don't have a machine to test this on. Could someone give me an account in some BSD system for a while to test this?
Anyway, I'll most likely release rc11 tomorrow, but it would be nice if you tested today's CVS snapshot already to see if I accidentally broke something. :) http://dovecot.org/nightly/dovecot-latest.tar.gz
Oh and one thing that I wanted for Dovecot v1.0 was nice documentation. I think the current wiki is a bit chaotic. I started http://wiki.dovecot.org/NewIndex a long time ago. Maybe I should finish it finally and put it as the new main index..
-- End of PGP section, PGP failed!
On Fri, 2006-11-03 at 10:11 +0000, T. Horsnell wrote:
Also, would a PDF version of the wiki docs be possible? It is very handy to take something to read in bed...
May I suggest http://moinmoin.wikiwikiweb.de/FormatterMarket/#head-a1aba44104a18e48f3187e9...
for that? :) The formatters should work with most MoinMoin versions, and if the text_latex.py (and multipart_latex.py if there are embedded images) formatters are installed it becomes possible to pull a latex file that can be run through pdflatex.
I don't recommend to install the application_pdf formatter directly because it may be possible to write exploits in latex, though if the latex parser isn't installed this shouldn't be possible since the latex formatter will quote everything and the application_pdf formatter will get sanitised input.
johannes
On Fri, 2006-11-03 at 10:11 +0000, T. Horsnell wrote:
-- Start of PGP signed section.
As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :)
I wonder if I might add a request please. Would it be possible to offer an option which limits the per-user number of imap processes?
Too large change, I'll do it after v1.0.
We have users who gaily open 30 mail folders simultaneously. OK, 1 or 2 such users dont matter, but the number creeps up.
Luckily Dovecot shouldn't take much memory normally :)
Also, would a PDF version of the wiki docs be possible? It is very handy to take something to read in bed...
I'll see about the link that Johannes gave.
On Fri, 2006-11-03 at 14:40 +0200, Timo Sirainen wrote:
I'll see about the link that Johannes gave.
Oh, I have a very tiny action installed on one wiki that makes a 'get this page as latex' item in the actions menu.
Here you go: --snip-- # -*- coding: utf-8 -*- """Add from MoinMoin.Page import Page
def execute(pagename, request): url = Page(request, pagename).url(request, {'action': 'format', 'mimetype': 'text_latex'}, relative=False) request.http_redirect(url) --snip--
maybe that relative=False won't work and you need to put False instead. I'm working against so many different Moin versions that I'm losing track.
johannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
T. Horsnell wrote:
-- Start of PGP signed section.
As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :)
I wonder if I might add a request please. Would it be possible to offer an option which limits the per-user number of imap processes? We have users who gaily open 30 mail folders simultaneously. OK, 1 or 2 such users dont matter, but the number creeps up.
I'd like to request a *complete* freeze on any kind of features (i.e. just bugfixes) until 1.0 is out the door, and probably for a while after.
All this talk of new features whilst 1.0 is trying to get out makes me extremely uneasy... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFFS20jhk3bo0lNTrURAqAqAJ94rDiNPrBsqd6eRkoawlWI9fuYJACVED3t 0uvda1AOnhmlVwaTDPxaJA== =2I2i -----END PGP SIGNATURE-----
Timo, I dont know about any ldap-auth memory leak, but I still havent seen any responses about the issue myself and Matheus Antonio Oliveira have reported about ldap authentications against Active Directory using auth_bind. Any chance this could be looked at before the v1.0 release is finalised ?
This is causing us ever growing pain as all it takes is a single user to type their password wrongly and it locks out dovecot preventing anyone else from logging in until the service is restarted. I currently have a cron job checking dovecot every minute and restarting when necessary.
Last post on the issue: http://www.dovecot.org/list/dovecot/2006-October/017073.html
Many thanks, Rob Coward
On Fri, 2006-11-03 at 00:29 +0200, Timo Sirainen wrote:
As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :)
I've now read all the mails from this list again, and it looks like pretty much the only problems with rc10 was the mbox assert crash, which is now fixed.
My TODO contains:
v1.0 blocker:
- inetd logins are broken? I should look more into this.. I only remembered this just now while writing this mail.
New non-v1.0 blockers:
- trash plugin is apparently broken?
- mbox_min_index_size != 0 causes Invalid new transaction log sequence (4 >= 4)
The old preferrably-fixed-for-v1.0 items are:
- ldap auth is leaking memory? maybe not, maybe it's something else.
- master leaks log fds with kqueue. I don't have a machine to test this on. Could someone give me an account in some BSD system for a while to test this?
Anyway, I'll most likely release rc11 tomorrow, but it would be nice if you tested today's CVS snapshot already to see if I accidentally broke something. :) http://dovecot.org/nightly/dovecot-latest.tar.gz
Oh and one thing that I wanted for Dovecot v1.0 was nice documentation. I think the current wiki is a bit chaotic. I started http://wiki.dovecot.org/NewIndex a long time ago. Maybe I should finish it finally and put it as the new main index..
This e-mail and any files transmitted with it are confidential and intended solely
for the use of the individual or entity to whom they are addressed. If you have
received this e-mail in error please notify the system manager at:
mailto:postmaster@game.netThe recipient acknowledges that the transmissions made via the Internet
can be corrupted and therefore THE GAME GROUP PLC and any of its subsidiaries
do not give any warranty as to the quality or accuracy of any information
contained in the message or assume any liability for it or for its transmission,
reception or storage.
This footnote also confirms that this e-mail message has been swept by
anti-virus software for the presence of computer viruses.
On Fri, 2006-11-03 at 10:47 +0000, Rob Coward wrote:
Timo, I dont know about any ldap-auth memory leak, but I still havent seen any responses about the issue myself and Matheus Antonio Oliveira have reported about ldap authentications against Active Directory using auth_bind. Any chance this could be looked at before the v1.0 release is finalised ?
I did quite large changes related to this and other auth_bind related things. All of it is untested unfortunately, because I haven't bothered to figure out why my OpenLDAP server installation is broken (and I really don't want to spend time figuring it out either).
Anyway, if you (or someone else) could test that these changes work before I release rc11 that'd be great.
The changes are in CVS and in the latest nightly snapshot: http://dovecot.org/nightly/dovecot-latest.tar.gz
The changes are also in these patches:
http://dovecot.org/list/dovecot-cvs/2006-November/006683.html http://dovecot.org/list/dovecot-cvs/2006-November/006687.html
Timo Sirainen wrote:
I did quite large changes related to this and other auth_bind related things. All of it is untested unfortunately, because I haven't bothered to figure out why my OpenLDAP server installation is broken (and I really don't want to spend time figuring it out either).
Surely the code-base should be pretty much frozen except for bug-fixes, since we're already *way* into an extremely protracted RC series.
I understand this change was to fix an existing bug, but it sounds like the change was far more than a simple bug fix. Major code rewrites, especially without any testing, don't seem right at this stage in the game.
On Sat, 2006-11-04 at 10:07 -0700, Stephen Warren wrote:
Timo Sirainen wrote:
I did quite large changes related to this and other auth_bind related things. All of it is untested unfortunately, because I haven't bothered to figure out why my OpenLDAP server installation is broken (and I really don't want to spend time figuring it out either).
Surely the code-base should be pretty much frozen except for bug-fixes, since we're already *way* into an extremely protracted RC series.
I understand this change was to fix an existing bug, but it sounds like the change was far more than a simple bug fix. Major code rewrites, especially without any testing, don't seem right at this stage in the game.
In general I agree, but there wasn't any simple fix for this bug, except to just tell people that auth_bind sort of works but not really. And since so many people have wanted auth binds for a long time, I think it's better to fix it now than to hear complains about it for a long time.
On Saturday 04 November 2006 12:20, Timo Sirainen wrote:
On Sat, 2006-11-04 at 10:07 -0700, Stephen Warren wrote:
Timo Sirainen wrote:
I did quite large changes related to this and other auth_bind related things. All of it is untested unfortunately, because I haven't bothered to figure out why my OpenLDAP server installation is broken (and I really don't want to spend time figuring it out either).
Surely the code-base should be pretty much frozen except for bug-fixes, since we're already *way* into an extremely protracted RC series.
I understand this change was to fix an existing bug, but it sounds like the change was far more than a simple bug fix. Major code rewrites, especially without any testing, don't seem right at this stage in the game.
In general I agree, but there wasn't any simple fix for this bug, except to just tell people that auth_bind sort of works but not really. And since so many people have wanted auth binds for a long time, I think it's better to fix it now than to hear complains about it for a long time.
I'll drink to that! Seriously though, if you know the problem exists, then there is really no good reason to procrastinate. Fix it and get it over with.
-- Gerard
I'd give my right arm to be ambidextrous.
I understand this change was to fix an existing bug, but it sounds like the change was far more than a simple bug fix. Major code rewrites, especially without any testing, don't seem right at this stage in the game.
In general I agree, but there wasn't any simple fix for this bug, except to just tell people that auth_bind sort of works but not really. And since so many people have wanted auth binds for a long time, I think it's better to fix it now than to hear complains about it for a long time.
Did I miss something here? I did read some "maybe-there-is-a-memleak-issue" reports, but other than that, I saw no auth_bind related issues. We ourselves use it quite heavily in production environments with no problems whatsoever.
Regards, Marc
On 5.11.2006, at 23.50, J.M. Maurer wrote:
I understand this change was to fix an existing bug, but it
sounds like the change was far more than a simple bug fix. Major code rewrites, especially without any testing, don't seem right at this stage in
the game.In general I agree, but there wasn't any simple fix for this bug,
except to just tell people that auth_bind sort of works but not really. And since so many people have wanted auth binds for a long time, I think it's better to fix it now than to hear complains about it for a long time.Did I miss something here? I did read some "maybe-there-is-a-memleak-issue" reports, but other than that, I
saw no auth_bind related issues. We ourselves use it quite heavily in production environments with no problems whatsoever.
The problem was the after a user gave an invalid password, no-one was
then logged into the LDAP server so all the queries afterwards
failed. Now I'm not sure if it's possible to configure the LDAP
server to allow the queries even if no-one is logged in, I'd guess it
is and maybe that's why it worked with you? Or if you were using
auth_bind_userdn that also worked because no queries were done until
a valid binding was done.
On Sat, 2006-11-04 at 17:11 +0200, Timo Sirainen wrote:
I did quite large changes related to this and other auth_bind related things. All of it is untested unfortunately, because I haven't bothered to figure out why my OpenLDAP server installation is broken (and I really don't want to spend time figuring it out either).
I ended up reinstalling my OpenLDAP server and testing myself. There were several bugs, so I guess I would have had to do that anyway :)
participants (9)
-
Gerard Seibert
-
J.M. Maurer
-
Jakob Curdes
-
Johannes Berg
-
Rob Coward
-
Stephen Warren
-
T. Horsnell
-
Timo Sirainen
-
Tom Sommer