-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Duncan wrote:
> Hamish Marson posted <[EMAIL PROTECTED]>,
> 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
>>
>> [EMAIL PROTECTED]:~$ 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:
>
I have
damned ~ # emerge -pv openssl
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] dev-libs/openssl-0.9.7g-r1 -bindist -emacs -test -zlib
So 0.9.7g installed. It seems to work. e.g. I can use the openssl
client to connect to ssl sites and it all goes hunky dory.
> 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 <[EMAIL PROTECTED]> (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.
>
My courier is
damned ~ # emerge -pv courier-authlib courier-imap
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] net-libs/courier-authlib-0.57-r1 +berkdb +crypt
- -debug -gdbm -ldap +mysql -pam* -postgres 0 kB
[ebuild R ] net-mail/courier-imap-4.0.4 +berkdb -debug -fam -gdbm
- -ipv6 -nls (-selinux) 0 kB
Total size of downloads: 0 kB
> 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
No packages listed... It found lots of old stuff in /usr/local/src
that I hadn't cleaned up in a while. Some more in various filesystems
I copied across from older installations. But nothig in the actual OS
itself. Nothing in the path or libpath. (And it was only XOrg & Scotty
anyway).
> 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
Now here's where it starts to get interesting... CounterContinent
interesting at that.
damned ~ # emerge -pN world
>>> --newuse implies --update... adding --update to options.
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[blocks B ] dev-php/mod_php (is blocking dev-lang/php-5.0.5-r1)
[blocks B ] dev-php/php (is blocking dev-lang/php-5.0.5-r1)
[blocks B ] dev-php/mod_php (is blocking dev-php/PEAR-PEAR-1.3.6-r1)
[blocks B ] dev-php/php (is blocking dev-php/PEAR-PEAR-1.3.6-r1)
[blocks B ] <=dev-php/PEAR-PEAR-1.3.5-r1 (is blocking
dev-php/PEAR-PEAR-1.3.6-r1)
[blocks B ] =kde-base/kdebase-kioslaves-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/khotkeys-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/konqueror-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kdesu-3.4* (is blocking kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kdialog-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kcminit-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/khelpcenter-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kdebase-data-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kdm-3.4* (is blocking kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/kcontrol-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] =kde-base/libkonq-3.4* (is blocking
kde-base/kdebase-3.4.3)
[blocks B ] media-libs/libungif (is blocking
media-libs/giflib-4.1.3-r2)
[blocks B ] app-cdr/dvdrtools (is blocking
app-cdr/cdrtools-2.01.01_alpha01-r2)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/konqueror-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/libkonq-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/kdebase-kioslaves-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/kdebase-data-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/khotkeys-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/khelpcenter-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking
kde-base/kcontrol-3.4.3)
[blocks B ] =kde-base/kdebase-3.4* (is blocking kde-base/kdm-3.4.3)
[ebuild U ] sys-apps/coreutils-5.3.0-r2 [5.3.0-r1]
[ebuild U ] dev-lang/perl-5.8.7-r1 [5.8.7]
[ebuild U ] dev-lang/python-2.4.2 [2.4.1-r1]
A few blockers... Well I've seen that before. Except that it's
claiming kdebase is a blocker. And I don't have kdebase installed.
damned ~ # emerge -pv --unmerge kdebase
>>> These are the packages that I would unmerge:
- --- Couldn't find kdebase to unmerge.
>>> unmerge: No packages selected for removal.
damned ~ # grep kdebase /var/lib/portage/world
damned ~ #
> 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
Well. ldd says it's using my new versions of libssl and libcrypto
(Among other things). e.g.
damned ~ # ldd /usr/sbin/couriertls
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x00002aaaaabc1000)
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7
(0x00002aaaaacf8000)
libc.so.6 => /lib/libc.so.6 (0x00002aaaaaf3b000)
libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab160000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
damned ~ # ls -l /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 11 Oct 14 23:37 /lib64/ld-linux-x86-64.so.2 ->
ld-2.3.5.so
damned ~ # ls -l /lib/libdl.so.2
lrwxrwxrwx 1 root root 14 Oct 14 23:37 /lib/libdl.so.2 -> libdl-2.3.5.so
damned ~ # ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 13 Oct 14 23:37 /lib/libc.so.6 -> libc-2.3.5.so
damned ~ # ls -l /usr/lib/libcrypto.so.0.9.7
- -r-xr-xr-x 1 root root 1328968 Oct 15 00:52 /usr/lib/libcrypto.so.0.9.7
damned ~ # ls -l /usr/lib/libssl.so.0.9.7
- -r-xr-xr-x 1 root root 223920 Oct 15 00:52 /usr/lib/libssl.so.0.9.7
damned ~ #
> 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.
>
I downgraded courier-imap to 4.0.1 (Stable version according to the
package database). Same thing. Urg!
Is it possible to get courier to log a bit more detail? I can fix
things IF the damn thing logs why it's doing stuff. Not getting logs &
flying blind just frustrates me.
H
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDUMoH/3QXwQQkZYwRAgkRAKDTD69xzx+KIxlM52NM0PKkPSF1SwCeMvx6
wXqxv7fxRAHtNbSZPvWxErE=
=FgQ8
-----END PGP SIGNATURE-----
--
[email protected] mailing list
