[gentoo-amd64] Re: Courier won't start... And Courier tls doesn't work

[Duncan]

Hamish Marson posted <434ED1A4.3060006@××××××××××××××.com>, excerpted
below,  on Thu, 13 Oct 2005 22:29:08 +0100:

> tarting with '/etc/init.d/courier-imap-ssl start' the script runs but
> exits with
>
>  * Starting courier-imapd over SSL...                         [ !! ]
>
>
> Inserting a few set -x's in scripts I find that the script runs to
> completion OK, and even looks like it's trying to start courier, but
> there's nothing started & no error.
>
> Now I could live with that, because starting it by hand it will run. But
> when anything connects (e.g. openssl s_client -connect <host>:993) gives
> me
>
> hamish@ballbreaker:~$ openssl s_client -connect damned:993
> CONNECTED(00000003)
> write:errno=104
>
> on the client and in the mail log I get
>
> Oct 13 21:28:44 [imapd-ssl] couriertls: connect: error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number
>
> Anyone know what's gone wrong? I've removed courier-imap, re-installed
> openssl, reinstalled courier-imap, (tried it with & without pam), but
> nothing.

I'm /not/ an authority on SSL and am only repeating here a couple things
that seem to "click" with your problem descripion, but...

1)  You don't mention versions of the various packages, but I happened to
note entries for openssl-0.9.8 in the changelog, and was only getting
0.9.7g-r1 to install, even tho I'm on ~amd64, so happened to investigate. 
Trying an emerge -p =openssl-0.9.8 results in:

Calculating dependencies
!!! All ebuilds that could satisfy "=openssl-0.9.8a" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/openssl-0.9.8a (masked by: package.mask, -* keyword)
# Martin Schlemmer <azarah@g.o> (05 Jul 2005)
# Masked for testing, as it breaks api

So 0.9.8* is masked, due to API breakage.  Even if you have 
0.9.7something merged, it's possible you somehow have a new courier-imap
that would (haven't checked, just speculating, here) possibly also be
masked, or maybe /should/ be masked, if it now works with the new SSL API
that matches the masked openssl.

2)  There's a recent GLSA (Gentoo Linux Security Advisory) on OpenSSL,
dated October 12.  In brief, it was possible under certain circumstances
to force it to fallback to SSL 2.0 instead of using the more secure SSL
3.0.  The workaround was to ensure SSL 2.0 was disabled, if possible, to
prevent fallback to it.  Here's the vunerability table:

    -------------------------------------------------------------------
     Package           /  Vulnerable  /                     Unaffected
    -------------------------------------------------------------------
  1  dev-libs/openssl     < 0.9.8-r1                       >= 0.9.8-r1
                                                            *>= 0.9.7h
                                                         *>= 0.9.7g-r1
                                                         *>= 0.9.7e-r2

So... it's possible that either you have the new openssl but that your
older version of courier-imap only does ssl v2, or that you have a new
courier-imap that refuses to fall back to v2, and an older ssl that's
somehow doing v2 only, no v3.

Besides checking your versions against the above, try running
revdep-rebuild (don't forget to put the -p in it the first time to see how
many packages it wants to rebuild, there could be quite a few...) to see
if you've anything that doesn't match up properly.  You may also want to
run emerge -pN (N being the short form of --newuse), to see if all your
merges are upto date with your latest USE flags settings (again, don't
forget that -p the first time...).  Finally, run emerge depclean -p, and
see what it might want to remove.  Note that in some cases this last one
makes mistakes, particularly if you have something compiled with USE flags
that included something you now have turned off in your USE flags. 
However, as the warning states, as long as you use common sense and add
the stuff you /know/ you want to keep to your world file, anything else
removed that's needed, should be fixable by simply remerging the package
that broke after the depclean.  (Also, there's significantly /less/
potential for broken packages, if you've already updated your merged
packages to match your current USE flags, using the --newuse step above,
thus the reason I listed it first.)

If after the above steps it's still giving problems, there's a chance you
have old libraries left on the system, that emerge /should/ have cleaned
up but didn't for some reason.  Run ldd on the involved executables, and
see what libraries they are loading, first making sure they can find all
needed libraries, then, starting with the ssl and crypto libs, ensure that
the libs it is finding aren't orphan, by running equery belongs
<path/library> on them and verifying that portage links them to a package
(again, paying special attention to any it says belong to the openssl
package, ensuring the version agrees with what you believe you have
merged.  If there are any libraries ldd said it would load, that don't
belong to a package, move/rename them temporarily, with a view to
removing them entirely if nothing breaks. (Likewise, any that belong to an
obsolete package, emerge -C the old package, keeping in mind multi-slots
such as gtk and gtk2, where two versions of the package are /supposed/ to
be merged, but this shouldn't occur if you've done the depclean step above.)

If after all that, you /still/ have problems, then it's time for some
SERIOUS troubleshooting, and possibly bug filing.  However, I expect the
problem should be solved by this point, likely well before it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list