headers
David Jonas | 1 Aug 2006 01:17

Re: Quota with dict backend - sql does not get registered

On Mon, 2006-07-31 at 22:43 +0300, Timo Sirainen wrote:
> After I just yesterday added Berkeley DB support for lib-dict, I thought
> maybe everyone should just use dict via the proxy. The dict server is
> linked against all the necessary libraries, and it's probably faster to
> make it go through dict server anyway. Otherwise it gets a bit difficult
> to figure out how the linking should work..

Cool, thanks Tim. I tried the proxy before but was getting funny
results. So now I've focused my efforts on working those out. I've come
across some interesting stuff.

First, it appears that the order of fields/values in the SQL insert
queries in src/lib-dict/dict-sql.c are out of order. It seemed to me a
confirmed error upon evaluating the ON DUPLICATE KEY UPDATE portion of
the query, not just me messing up the config. Diff is at the bottom. I'd
make a formal patch for you, but there is some other hoky things going
on.

Here's my logs. I'm running down these bugs now:

Jul 31 15:56:06 uniroyal dovecot: dict: sql dict: commit failed: Not
connected to database
Jul 31 15:56:06 uniroyal dovecot: IMAP(djonas <at> ): dict_quota: Couldn't
update quota
Jul 31 15:56:06 uniroyal dovecot: dict: sql dict: commit failed: Not
connected to database
Jul 31 15:56:06 uniroyal dovecot: IMAP(djonas <at> ): dict_quota: Couldn't
update quota
Jul 31 15:56:06 uniroyal dovecot: IMAP(djonas <at> ): Sending log messages
too fast, throttling..
(Continue reading)

Permalink | Reply | 1 comment |
headers
J Moore | 1 Aug 2006 07:49

permissions warning on OpenBSD 3.9

At startup I get the following warning:
"Warning: Fixing permissions of /var/dovecot to be world-readable."

Q: Is this something that I can/should fix, or can it be safely ignored?

Thnx,
J
Permalink | Reply | 9 comments |
headers
Thomas Zajic | 1 Aug 2006 09:58

Re: permissions warning on OpenBSD 3.9

* J Moore, 2006-08-01 07:49

> At startup I get the following warning:
> "Warning: Fixing permissions of /var/dovecot to be world-readable."
> 
> Q: Is this something that I can/should fix, or can it be safely ignored?

You usually should only see this once, after that dovecot is supposed to
fix it by itself, provided that it has sufficient privileges to do so.
What user is dovecot running as, and what's the owner and permission
settings of /var/dovecot?

BTW, while we're at it (this one's for Timo, I guess ;-) - is there a
specific reason why this check is done via lstat() rather than via plain
ol' stat() (see src/master/master-settings.c, line# 784)?

I'm using GNU stow, so /usr/local/var/run/dovecot is actually a symlink
to /usr/local/stow/dovecot-data/var/run/dovecot - which, in fact, does
have the proper permissions (dovecot:dovecot, 0755) already. Yet I'm
still getting this warning everytime dovecot starts up, because lstat()
returns the permissions  of the symlink (0777) rather than those of the
target (0755). "Fixing" it with chmod() in line# 798 doesn't actually fix
it, of course, because chmod(), as opposed to lstat(), affects the link
target rather than the link itself.

Just curious ...

Thomas
--

-- 
=-------------------------------------------------------------------------=
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brad | 1 Aug 2006 10:04

Re: permissions warning on OpenBSD 3.9

On Tue, Aug 01, 2006 at 12:49:38AM -0500, J Moore wrote:
> At startup I get the following warning:
> "Warning: Fixing permissions of /var/dovecot to be world-readable."
> 
> Q: Is this something that I can/should fix, or can it be safely ignored?
> 
> Thnx,
> J

When Dovecot prints this message it has corrected the issue already.
The OpenBSD port was creating /var/doveocot with permissions of 0700
instead of 0755, as it should be. I fixed the port 3 days ago.
Permalink | Reply | 4 comments |
headers
Geert Hendrickx | 1 Aug 2006 10:10
Picon
Favicon

Re: permissions warning on OpenBSD 3.9

On Tue, Aug 01, 2006 at 09:58:33AM +0200, Thomas Zajic wrote:
> "Fixing" it with chmod() in line# 798 doesn't actually fix it, of course,
> because chmod(), as opposed to lstat(), affects the link target rather
> than the link itself.

Use chmod -h.  

	Geert
Permalink | Reply | 1 comment |
headers
Thomas Zajic | 1 Aug 2006 10:37

Re: permissions warning on OpenBSD 3.9

* Geert Hendrickx, 2006-08-01 10:10

> On Tue, Aug 01, 2006 at 09:58:33AM +0200, Thomas Zajic wrote:
>> "Fixing" it with chmod() in line# 798 doesn't actually fix it, of course,
>> because chmod(), as opposed to lstat(), affects the link target rather
>> than the link itself.
> 
> Use chmod -h.  

I'm not talking about fixing it from the command line (no need to, as the
permissions are in fact correct), I'm talking about the chmod() call in
the dovecot source (src/master/master-settings.c, line# 798). ;-)

BTW my (command line) chmod doesn't know a "-h" option, what's it supposed
to do? Something with (not) following symlinks, I guess?

| [zlatko <at> disclosure]:~$ chmod -h
| chmod: invalid option -- h
| Try `chmod --help' for more information.
| [zlatko <at> disclosure]:~$ chmod --version | head -1
| chmod (coreutils) 5.2.1

Thomas
--

-- 
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic  <zlatko <at> gmx.at>   Linux-2.6.17 & Thunderbird-1.5 -
-  "It is not easy to cut through a human head with a hacksaw."  (M. C.)  -
=-------------------------------------------------------------------------=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geert Hendrickx | 1 Aug 2006 10:57
Picon
Favicon

Re: permissions warning on OpenBSD 3.9

On Tue, Aug 01, 2006 at 10:36:01AM +0200, Thomas Zajic wrote:
> BTW my (command line) chmod doesn't know a "-h" option, what's it supposed
> to do? Something with (not) following symlinks, I guess?

from NetBSD's chmod(1) manpage: 

     -h      If file is symbolic link, the mode of the link is changed.

But apparantly only NetBSD and FreeBSD have this flag, sorry.  

	Geert
Permalink | Reply | 1 comment |
headers
Thomas Zajic | 1 Aug 2006 11:05

Re: permissions warning on OpenBSD 3.9

* Geert Hendrickx, 2006-08-01 10:57

> On Tue, Aug 01, 2006 at 10:36:01AM +0200, Thomas Zajic wrote:
>> BTW my (command line) chmod doesn't know a "-h" option, what's it supposed
>> to do? Something with (not) following symlinks, I guess?
> 
> from NetBSD's chmod(1) manpage: 
> 
>      -h      If file is symbolic link, the mode of the link is changed.
> 
> But apparantly only NetBSD and FreeBSD have this flag, sorry.  

No problem - Linux here, BTW, not one of the *BSDs. ;-) I was answering
to the OP because I also saw that lstat() warning thing on my own system
again yesterday.

Thomas
--

-- 
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic  <zlatko <at> gmx.at>   Linux-2.6.17 & Thunderbird-1.5 -
-  "It is not easy to cut through a human head with a hacksaw."  (M. C.)  -
=-------------------------------------------------------------------------=
Permalink | Reply | 0 comments |
headers
Richard Birkett | 1 Aug 2006 16:15

Inconsistent handling of CRLF in APPEND

One of the recent 1.0 commits relating to CRLF handling (maybe 2006-06-24) 
has changed the behaviour of APPEND when using mbox files with ordinary 
plain text emails.

When a client stores a new message using an APPEND command (eg. saving a 
draft or copy of a sent message), it uses CRLF consistently as a 
line-ending throughout the literal data block over the wire - both for the 
header and the body.  At least, this is what both Pine and Thunderbird do, 
so I suspect it's correct according to the IMAP specs, though perhaps 
there are grey areas around 8bit messages with no transfer-encoding.  When 
Dovecot stores the message in the mbox file, it *used* to convert all the 
CRLFs to LF.  Since the change, it is still converting the CRLFs in the 
header, but is leaving them intact in the body.  The result is a weird 
hybrid format within the file.

FETCH seems to undo the damage - at least, it sends back data with CRLF in 
both the header and the body - so provided the only access to the 
mail-store is through Dovecot, the clients are none the wiser.  Dovecot 
also seems to handle existing messages (stored with LF only) OK too, and 
doesn't seem to be re-encoding them on update (eg. status changes). 
However, direct local access to the hybrid new messages will only work if 
the client is lenient about line endings: Pine seems OK, but others might 
not be, expecting an mbox file to be consistently "Unix" format.

Is this a regression introduced while trying to fix the attachment 
corruption problem, or just a brand new bug?!  Hopefully there is a way of 
reverting this change without reintroducing the attachment problem.

Richard
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steve Roemen | 1 Aug 2006 16:20

server provisioning

All,
    I was curious as to what size of systems (cpu, memory) that you are 
using.  I'm going to build a new server for imap, imap-ssl, pop3, 
pop3-ssl, maildir storage (NOT smtp or spam --that's on another server)  
for ~500 users.  What do you believe is the minimum for this?

Thanks,
Steve
Permalink | Reply | 0 comments |

Gmane