# authdaemond.mysql: exec: No such file or directory [solved]

## baak6

Hello friends.

I just upgraded courier-imap and postfix. I'm running the virtual mailhosting howto mailsystem. Now I get 'authdaemond.mysql: exec: No such file or directory' in /var/log/messages when starting authdaemond.mysql, so my mailsystem doesn't work anymore. I ran dispatch-conf and made sure no critical configs were overwritten, and then i browsed through everything in the howto and made sure things were like they are supposed to be. I have no idea what to do but I know for sure that log message would be a wee bit more helpful if it'd tell me WHAT directory doesn't exist....

Last summer I updated the same thing too and it stopped working aswell, I guess I won't upgrade this again :-/

Does anyone have any idea what gives? I'll post configs if needed.

Thanks.Last edited by baak6 on Sat Feb 05, 2005 4:54 am; edited 1 time in total

----------

## Kurse

I have exact same problem here, as well. I have been trying to figure out what is going on, but so far, I cant find anything misconfigured. Not sure what changed here.

----------

## turtlendog

Sorry all I can do at this point is comiserate with you...

----------

## mcbeth

Well, to get mine working again (just finished)

I had to go to

/etc/courier/authlib/authdaemonrc

This appears to be a new location for this file.

Once there, I reordered the module order back to what I had before the upgrade, and things started working again..

Hope this helps

----------

## turtlendog

Here's one clue:  The new initscript seems to be courier-authlib rather than authdaemond.

Also, it tries to execute /usr/lib/courier-authlib/authdaemond, but authdaemond is in /usr/sbin

I linked it to /usr/lib/courier-authlib/ with no luck.  I get an error of "Unknown option '-'"

Tried to run it with -h --help and man for clues about what it takes for arguments with no luck.

PS.  I'm using the virtual mail setup found at www.gentoo.org/doc/

----------

## j-m

You could avoid all the problems IF you bothered to read warning at the end of upgrade, visited http://www.courier-mta.org/imap/?INSTALL.html~upgrading and finally noticed that you should configure this in

```

/etc/courier/authlib

```

Finally, when done with all the configuration changes, run

```

/etc/init.d/authdaemond stop

/etc/init.d/courier-authlib start

rc-update del authdaemond default

rc-update add courier-authlib default

```

----------

## langthang

or read the ebuild ChangeLog  :Wink: 

 *Quote:*   

>   03 Feb 2005; Tuấn Văn <langthang@gentoo.org> courier-imap-4.0.1.ebuild:
> 
>   Stable on x86. This upgrade is non-trival. Please read:
> 
> http://www.courier-mta.org/imap/?INSTALL.html~upgrading
> ...

 

----------

## tinwood

I, for one, could've done without having to reconfigure it today.  I'd have hoped that by running stable wouldn't have peformed an upgrade to a version that has a completely different auth config.  Could it have been slotted or something?

----------

## Kurse

 *langthang wrote:*   

> or read the ebuild ChangeLog 
> 
>  *Quote:*     03 Feb 2005; Tuấn Văn <langthang@gentoo.org> courier-imap-4.0.1.ebuild:
> 
>   Stable on x86. This upgrade is non-trival. Please read:
> ...

 

Yep, This is what I did to find that some locations had been changed. Everything is working fine now.

----------

## j-m

 *tinwood wrote:*   

> I, for one, could've done without having to reconfigure it today.  I'd have hoped that by running stable wouldn't have peformed an upgrade to a version that has a completely different auth config.  Could it have been slotted or something?

 

I guess you should expect major changes when upgrading between major versions of the package  (like 3.0.x --> 4.0.x). I did carefully look at the changelog and at the link advertised in there when I noticed this major version change. The whole upgrade then took just 15 minutes. And I did NOT keep the previous config files in /etc/courier-imap as i decided that it will be safer and faster to tweak them manually from scratch. The upgrade does however do a fine job when transferring original authmysqlrc/authpgsqlrc settings to /etc/courier/authlib. 

And yes, there should be some instructions that /etc/init.d/authdaemond is no longer working and that you should use /etc/init.d/courier-authlib instead. Maybe you should file a bug for this.

----------

## langthang

 *tinwood wrote:*   

> I, for one, could've done without having to reconfigure it today.  I'd have hoped that by running stable wouldn't have peformed an upgrade to a version that has a completely different auth config.  Could it have been slotted or something?

 

how's about not upgrade it if you are not ready.

```
# echo ">=coruier-imap-4* /etc/portage/package.mask"
```

Very simple.

----------

## langthang

> And yes, there should be some instructions that /etc/init.d/authdaemond is no longer working and that you should use /etc/init.d/courier-authlib instead.

not perfect but I got it cover, you missed it.

```
$ less /usr/share/doc/courier-imap-4.0.1/courier-imap-gentoo.readme.gz

...

// Start authdaemond

localhost ~ # etc/init.d/courier-authlib start

* Starting courier-authlib: authdaemond ... [ ok ]

...
```

----------

## j-m

 *langthang wrote:*   

> > And yes, there should be some instructions that /etc/init.d/authdaemond is no longer working and that you should use /etc/init.d/courier-authlib instead.
> 
> not perfect but I got it cover, you missed it.
> 
> 

 

OK, I would suggest adding the rc-update part I mentioned above (otherwise people will get errors on reboot), maybe deleting /etc/init.d/authdaemond entirely. Personally I would prefer putting at least part of these instructions into ewarn where it might get better attention from people who are upgrading. 

OK, and as it seems that I have a dev on the phone  :Very Happy:  - there is a problem with FEATURES="collision-protect" concerning courier-authlib but I am not sure that this can be solved (the files naturally belong to previous courier-imap version).

----------

## tinwood

 *Quote:*   

> 
> 
> how's about not upgrade it if you are not ready. 
> 
> Code:
> ...

 

Yes, and I would've done if I had know BEFORE I upgraded that it would break the config.  I'm seriously considering masking it and going back - but now it has become a challenge to sort it out.  

My point was that I was just raising the idea that it would be nice if upgrading packages in stable didn't just break existing configurations.  I guess this is part of the pain of having such a bleeding edge distro.

In an ideal world it would have either:

Upgraded the packagte and automatically taken the config from the existing system and moved it to the new one OR

NOT upgraded as part of a 'emerge -u' and been blocked

Maybe I'm just moaning because I have to sort out the config ...

----------

## j-m

 *tinwood wrote:*   

> 
> 
> Maybe I'm just moaning because I have to sort out the config ...

 

OK, once again - I´d suggest you backup your current config files, emerge again, let etc-update or dispatch-conf update your configuration and reconfigure from scratch - it is very easy and fast if you have your previous config files ready. And prevents you from overlooking some minor changes and having problems after.

----------

## tinwood

Yep, I'd just reached the same conclusion.  Thanks for the nudge in the right direction. 

Cheers

Alex.

PS I missed your earlier post which, as you rightly said, does map it out.

----------

## sigmalll

I got it working by nuking courier-imap, all the configs and binning the init scripts (etc) just for luck.

Re emerge & configure courier-imap and the new moved authfiles, then...

```
# /usr/lib/courier/courier-authlib/authdaemond

INFO: modules="authvchkpw", daemons=5

INFO: Installing libauthvchkpw

INFO: Installation complete: authvchkpw

Now press CTRL+C

# /etc/init.d/authdaemond stop 

# /etc/init.d/courier-authlib start 

# rc-update del authdaemond default 

# rc-update add courier-authlib default 

(or something like that)

```

----------

## baak6

sigmalll: You rock my world!  :Smile: 

----------

## KpR2000

 *sigmalll wrote:*   

> I got it working by nuking courier-imap, all the configs and binning the init scripts (etc) just for luck.
> 
> Re emerge & configure courier-imap and the new moved authfiles, then...
> 
> ```
> ...

 

 /usr/lib/courier/courier-authlib/authdaemond      

INFO: modules="authcustom authcram authuserdb authmysql authpam", daemons=5

INFO: Installing libauthcustom

INFO: Installation complete: authcustom

INFO: Installing libauthcram

INFO: libauthcram.so: cannot open shared object file: No such file or directory

INFO: Installing libauthuserdb

INFO: Installation complete: authuserdb

INFO: Installing libauthmysql

INFO: Installation complete: authmysql

INFO: Installing libauthpam

INFO: Installation complete: authpam

What should I do, because of libauthcram.so: cannot open shared object file: No such file or directory?

----------

## j-m

 *KpR2000 wrote:*   

> 
> 
>  /usr/lib/courier/courier-authlib/authdaemond      
> 
> INFO: modules="authcustom authcram authuserdb authmysql authpam", daemons=5
> ...

 

Do you need CRAM-MD5 or CRAM-SHA1 authentication? If not, you should remove it from you config files. Otherwise, you should probably emerge courier-authlib again with USE="crypt" flag.

----------

## KpR2000

I got it working with:

.

modules="authpam"

.

.

Though I had emerge net-libs/courier-authlib-0.53 with crypt.

----------

## swtaylor

On needing to start the "courier-authlib" module vs. "authdaemond": the updated script for courier-imap (and friends) have the dependancy changed from "need authdaemond" to "need courier-authlib". If you let etc-update replace these scripts like its supposed to, it will automatically start the proper authentication daemon. You should make sure that the old authdaemond won't get started with a "rc-update del authdaemond". It is okay to, but is not necessary to "rc-update add courier-authlib" as the other init scripts define it as a "need" which means they will start it if it wasn't already running. Files in /etc/init.d do NOT usually get deleted during an emerge even if they become obsolete, as the user would not be able to gracefully "/etc/init.d/blah stop" a currently running daemon if "blah" was deleted during an upgrade. So, its not exactly something that can get wiped out automatically. We should hold a contest for the best way to get people to actually read warnings instead of letting them scroll by. 

authdaemond location: not in /usr/sbin. not in /usr/lib/courier-authlib/ either. it is in /usr/lib/courier/courier-authlib/authdaemond which is exactly where /etc/init.d/courier-authlib looks for it.

on being a "completely different auth config": The config files are in a slightly different location. Its not a vastly different authdaemon. Its just not duplicated among multiple packages anymore. It should have migrated all of the old configurations (authmysqlrc, authldaprc, etc) to the new location. If it missed those, that should be reported and looked into.

on collision-protect, thats a new feature of portage, and by using it, you are slightly in uncharted waters. Since you see that its a legitimate package you're migrating versions of  instead of some random package trying to wreck data, you can safely turn it off for this merge. Perhaps there should be a way to tell that feature what can be ignored or know to print a warning about that at the beginning... thats its own topic though.

on libauthcram: was that inherited from an old config? 

on authpam: if courier-authlib was built with USE="pam" which it should've been if your system is using pam, it should've already been added to the modules list.  And along those lines, if you have use flags like mysql and ldap and whatever else but aren't and won't be using them for courier, it would be wise to drop those flags at least for these builds with a setting in /etc/portage/package.use. Methods like authmysql, if there is no match for the username, it will move on and try the next authentication module. Courier can tell the difference between a bad password and a nonexistant user there and will try other modules. Authpam though just returns a pass/fail response and a fail at that point is the end of the road. Its suggested to only build modules you actually plan to use.

----------

## tinwood

To swtaylor and the other devs:

My apologies - I had blown things out of proportion.   :Embarassed:    In the end I had to make only one change which was to disable the auth modules I didn't need and then everything worked.  However, finding that out took much longer than the 30 seconds it took to make the change.

 *Quote:*   

> We should hold a contest for the best way to get people to actually read warnings instead of letting them scroll by. 

 

Agreed!  Pity they can't be collected and then be available for viewing at the end of the emerge process?  Sort of like 'unread' messages.  Maybe provide an option to email these notices (via a configurable make.conf parameter) so that the admin has a permanent record of what the notice was?

 *Quote:*   

> on being a "completely different auth config": The config files are in a slightly different location. 

 

Sorry.  I over-reacted and was flippant - a very small amount was moved but I assumed it was wildly different before actually confirming the whether it was.

Once I was clear what was going on it was very easy to sort it out - my thanks to the devs and packagers - courier-imap still works very well indeed.

Cheers

Alex.

----------

