# need desperate help with newest courier-imapd!

## Dragonlord

just did an emerge world to get the newest courier and now my entire mail-system has broken down... nothing works anymore (damn... a really bad timing for such a thing).

it all worked well with LDAP before and now things are hell, the logs show nothing even with debugging DEBUG=2... wtf is going on?!!

logs:

```
Feb  5 19:53:03 [authdaemond] modules="authldap", daemons=5

Feb  5 19:53:03 [authdaemond] Installing libauthldap

Feb  5 19:53:03 [authdaemond] Installation complete: authldap

Feb  5 19:53:13 [imapd] Connection, ip=[::ffff:192.168.1.20]

Feb  5 19:53:17 [imapd] LOGIN FAILED, user=roland, ip=[::ffff:192.168.1.20]

Feb  5 19:53:24 [imapd] Disconnected, ip=[::ffff:192.168.1.20], time=11
```

/etc/courier/authlib/authdaemonrc shortened:

```
authmodulelist="authldap"

authmodulelistorig="authuserdb authpam authshadow authpgsql authldap authcustom"

daemons=5

authdaemonvar=/var/lib/courier/authdaemon

DEBUG_LOGIN=2

DEFAULTOPTIONS=""
```

authldaprc stayed the same as before. i also removed the authdeamon* files from the old courier-imapd directory to no avail...

need help here...

----------

## nobspangle

I had a similar problem except I authenticate against pam.

Make sure you stop authdaemond then delete the init.d script for it and restart courier-imap it should start up with the new courier-authlib script.

----------

## Dragonlord

does not help... login still fails with the same non-telling log files.

----------

## nobspangle

if you 

```
ps aux
```

does it show authdaemond as being started the same time as the other courier processes?

Also make sure your famd is running (if you compiled courier-imapd with USE=fam

----------

## servermonk

Are you actually using ldap for auth? my "authmodulelist" reads:

```
authmodulelist="authvchkpw authpam authcustom"

authmodulelistorig="authvchkpw authpam authcustom"
```

----------

## Dragonlord

i am using LDAP and authd is started together with courier-authlib (as stated in the init.d out message)

----------

## servermonk

I don't know if this would help but I have 

/etc/courier-imap/authdaemonrc symlinked to /etc/courier/authlib/authdaemonrc

What's your DEBUG_LOGIN value set to? Seems like you should be able to get more info in the logs as to why they're failing...

----------

## Dragonlord

it's DEBUG=1... and it's strange as there is nothing written in the logs... i suspect the LDAP beeing broken in this version. otherwise i see no reason why it fails. when i login on the mail-server it takes 2-3 secs before it fails. looks like the authmodule can't speak with the ldap but it's running.

----------

## Dragonlord

F***!!! F***!! F***!!!!

i can't even roll back anymore to the previous packages... the entire mail system is broken... nothing works anymore... ****!!!

----------

## Dragonlord

more tries... it is definitly not the LDAP server playing bad, i can ldapsearch with the same parameters that are in the config files... still i get no usable output in the logs using DEBUG=1 at any config file i can find in /etc/courier/authlib and /etc/courier-imap . what the heck is going on?

----------

## servermonk

The new ebuild states:

 *Quote:*   

>         einfo "Authdaemond is no longer provided this package."
> 
>         einfo "athentication libraries are from courier-authlib"
> 
>         einfo "for a quick start please refer to"
> ...

 

Though unfortunately nothing in /usr/share/doc/courier-imap-4.0.1/courier-imap-gentoo.readme.gz about ldap  :Sad: 

----------

## Dragonlord

the old package had no ldap notes too. got it working from howtos on the web. but here something must have been broken with the new authlib... i could cheat around it but that's not the point if i have all my stuff in my LDAP.

----------

## Dragonlord

ok... i have no idea what i have done... but it works... imap over LDAP works again.

* is completly clueless what he has done *

----------

## j-m

 *Dragonlord wrote:*   

> * is completly clueless what he has done *

 

Lesson learned: Don´t panic, don´t panic, don´t panic.   :Rolling Eyes: 

----------

## Dragonlord

 :Laughing:  ... i usually don panic but if my mail server is down a lot of 'special' log reports i use for debugging are... erm... not accessible   :Wink: 

----------

## Sandro

I also updated courier-imapd today and I think I'm having exactly the same problem.  :Shocked:  Can you remember what you did before it worked again?

I get the same log entries.

authdaemond simply refuses to start, I can't even start it directly...

 *Quote:*   

> cerberus root # /etc/init.d/courier-authlib restart
> 
>  * Stopping courier-imapd...                                                                                           [ ok ]
> 
>  * Stopping courier-imapd over SSL...                                                                                  [ ok ]
> ...

 

I'm not using LDAP.

Any help is very appreciated.  :Confused: 

----------

## j-m

 *Sandro wrote:*   

> 
> 
> cerberus root # /usr/sbin/authdaemond
> 
> Unknown option '-'
> ...

 

OMG.  :Rolling Eyes: 

```

/etc/init.d/courier-authlib start

```

----------

## Sandro

Yay! It's working again.  :Smile: 

In case anyone runs into the same problem (which even seems to be likely, considering Dragonlord probably had the same problem), here is what I did:

Somehow /etc/init.d/courier-authlib lost track of authdaemond. I "zapped" it, and was able to restart it again.

 *Quote:*   

> cerberus root # /etc/init.d/courier-authlib zap
> 
>  * Manually resetting courier-authlib to stopped state.
> 
> cerberus root # /etc/init.d/courier-authlib start
> ...

 

----------

## Sandro

 *j-m wrote:*   

>  *Sandro wrote:*   
> 
> cerberus root # /usr/sbin/authdaemond
> 
> Unknown option '-'
> ...

 Ok, the direct call was stupid. But don't worry.  :Smile:  I tried the init script before, but it didn't do anything because it thought authdaemond was already running.

----------

## Dragonlord

in my case i did just this:

first stop all:

/etc/init.d/courier-authlib stop

=> this will stop all, if something fails stop by hand and 'zap' it

then just start it up like this:

/etc/init.d/courier-authlib start

/etc/init.d/courier-imap start

/etc/init.d/courier-imap-ssl start

=> ssl only if you have ssl in

this should do it. so far for my problem i guess the updating of the config fails messed it up. i think the option to specify what key in the ldap refers to the mail directory as deleted by the merge. otherwise after a clean setup i noticed this:

- /etc/init.d/authdeamond does not exist. delete if existing.

- /etc/init.d/courier-* => add them to default run-level.

- /etc/courier/authlib/* => place there your settings ALSO in the *.dist files. no idea what they are for but it seems to be necessary to write the same crap also into them. i'm not sure if they are copies as with me the file sizes have been different.

- delete /etc/courier-imap/auth* as those files are now in authlib.

that's what i did in the last attempt and i think it does not hurt to do it so.

----------

## j-m

 *Dragonlord wrote:*   

> 
> 
> - /etc/courier/authlib/* => place there your settings ALSO in the *.dist files. no idea what they are for but it seems to be necessary to write the same crap also into them. i'm not sure if they are copies as with me the file sizes have been different.
> 
> - delete /etc/courier-imap/auth* as those files are now in authlib.
> ...

 

Enough of this mess!  :Rolling Eyes: 

- *.dist files are samples of configuration

- *rc files have settings transferred from previous location (/etc/courier-imap)

- courier-authlib does not read anything from *.dist files at all.

----------

## Dragonlord

 *j-m wrote:*   

>  *Dragonlord wrote:*   
> 
> - /etc/courier/authlib/* => place there your settings ALSO in the *.dist files. no idea what they are for but it seems to be necessary to write the same crap also into them. i'm not sure if they are copies as with me the file sizes have been different.
> 
> - delete /etc/courier-imap/auth* as those files are now in authlib.
> ...

 

for some reason though the settings of the *rc files have NOT been transfered... otherwise i would not have gotten into this mess  :Wink: 

----------

