On Mon, Aug 28, 2006 at 05:04:40PM +0200, Damien Wyart wrote:
> After seeing that 2.0.2 was in experimental --- had not followed it
> closely (my tests & bug were from 1.8), I retried installing it again
> today, and first got messages like this :
> 
>   Command died with status 127: "/usr/bin/maildrop -d ${USER}". Command
>   output: /usr/bin/maildrop: error while loading shared libraries:
>   libcourierauth.so.0: cannot open shared object file: No such file or
>   directory
> 
> So the problem of dependency on courier-authlib is still the same.
> Installing maildrop should have it work by default, not complain on
> a missing lib !

It shouldn't actually fail without it - this is supposed to be a dlopen
warning message.

I've tried to reproduce it now, and it seems that it's a full-blown link
instead of a dynamic open. Please install courier-authlib in the meantime.
I'll investigate if it should become more optional.

> temporary failure. Command output: ERR: authdaemon: s_connect() failed:
> Permission denied /usr/bin/maildrop: Temporary authentication failure.

What user are you running maildrop with? That's what I meant by
"even then you need a privileged user to run it, I think."

> So I guess I would again need to configure something else to make it
> work, which is inacceptable.

No, actually, it should have continued to work *without* the authlib.

But more to the point, what user are you trying to run maildrop -d with, and
what is your expected behaviour? What do you expect from the -d option?

Since the initial bug report says you run it from a .forward file, can you
instead try simply omitting the -d option altogether?

The manual page maildrop(1), in 1.5.x, too, states clearly:

       -d user
              Run maildrop in delivery mode for this user ID.

              The system administrator may optionally restrict the  -d  option
              to be available to the mail system only, so it may not be avail-
              able to you.  In all cases, the -d option is allowed if user  is
              the  same user who is running maildrop.  Also, for the -d option
              to work at all, maildrop must be executed by root,  or  maildrop
              must  be  a root-owned program with the setuid bit set.  Absence
              of a filename on maildrop's command line implies the  -d  option
              for the user running maildrop.

The behaviour of new maildrop changed in a way that -d is no longer idly
ignored for normal users. This will need to be dealt with. However, this
should not be a grave issue.

-- 
     2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to