Since we're all doing the top-posting thang..
Bernd - thanks for the advice. Without it, I would sure have done
exactly the opposite (as it is, my "introduction to the world of linux
impressed upon me the need to compile always from source - so this is
what I've made a habit of doing).
Leigh - your disclaimer was quite unwarranted - I appreciated the
back-ground and the advice (I only wish I'd had it sooner since I am
currently struggling with an orphan saslauthd implementation which is
really getting me down. I wasn't stung by Sam's brevity (having twice
before been on this list, I'm aquainted with Sam's style and I
appreciate the time he takes in answering idiotic queries - because
unless someone has started paying him to write the courier-suite, I
believe he still has a full time job).
Finally, Sam - thanks. I stripped out the tarballs and installed
everything from apt-get and after some issues because I was following
a howto and trying to make it fit to my old set-up, it's all working
like a peach.
Lydiard
----- Message from [EMAIL PROTECTED] ---------
Date: Sat, 1 Dec 2007 00:12:15 +0900
From: Bernd Plagge <[EMAIL PROTECTED]>
Reply-To: Bernd Plagge <[EMAIL PROTECTED]>
Subject: [courier-users] Error compiling Courier with TLS
To: [email protected]
> Leigh,
>
> you' did a pretty good job in explaining it.
> For about 2 years or so Debian was only offering outdated packages and
> even I started to compile packages.
> While I greatly appreciate the 'standard file locations' and
> dependencies Debian enforces there may be good reasons to recompile a
> Debian package e.g. if command line values need to be changed.
> In such case I download the Debian source files (original source plus
> Debian diff), change the compile parameters in debian/rules and build
> the packges.
> This normally works UNLESS there are major program changes.
>
> Therefor, in conclusion and for the benefit of any other reader, if you
> need to change some compile parameters you should NOT download the
> tarball and compile it but the original source together with the Debian
> diff file and then recompile it.
>
> Just my 2 yen.
>
> Thanks,
> Bernd
>
>
>
> ---
> 差出人: "Leigh S. Jones, KR6X" <[EMAIL PROTECTED]>
> 宛先:: [email protected]
> 件名: Re: [courier-users] Error compiling Courier with TLS
> 日付: Thu, 29 Nov 2007 18:06:17 -0800
>
> Leigh Jones writes:
>
> I don't want to tread on toes too very hard here.
>
> It seems to me that Sam Varshavchik has been clear here, but the
> brevity with which he has spoken belies the depth of meaning.
>
> So let me attempt to expound.
>
> If you come from the background of running a very "tiny" linux
> implementation, as in not particularly well supported, you may miss
> entirely the strength o
>
> --
> プラゲ ベェアント - Bernd Plagge
> ファースト・チョイス・インターネット(有)
> First Choice Internet Ltd., Tokyo
> Tel. 03-4500-7799
> Fax. 03-4400-3723
> mail: [EMAIL PROTECTED]
> url: http://www.choicenet.ne.jp
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>
----- End message from [EMAIL PROTECTED] -----
----- Message from [EMAIL PROTECTED] ---------
Date: Thu, 29 Nov 2007 18:06:17 -0800
From: "Leigh S. Jones, KR6X" <[EMAIL PROTECTED]>
Reply-To: "Leigh S. Jones, KR6X" <[EMAIL PROTECTED]>
Subject: Re: [courier-users] Error compiling Courier with TLS
To: [email protected]
> Leigh Jones writes:
>
> I don't want to tread on toes too very hard here.
>
> It seems to me that Sam Varshavchik has been clear here, but the brevity
> with which he has spoken belies the depth of meaning.
>
> So let me attempt to expound.
>
> If you come from the background of running a very "tiny" linux
> implementation, as in not particularly well supported, you may miss entirely
> the strength of a very "large" linux implementation.
>
> FSF software can be compiled and run with some degree of success on a Debian
> system. But to make full use of the Debian linux implementation you need to
> "hook in" to the full strength of the Debian organization.
>
> Debian has locations for system files that it considers to be "just so". As
> soon as you start compiling FSF programs over the top of Debian linux you
> will start to misplace files. For instance, openssl wants all of the
> certificate files that it uses to be located in a particular place, and the
> default location for these certificate files is decided at compile time.
> Type "openssl version -d". If you compile the openssl program yourself, you
> can manage that location with command line options, and put it where you
> want it. But if you haven't carefully studied the Debian party line you
> probably won't know where that is. So if you use apt-get to grab openssl
> from the Debian servers you will get back "/usr/lib/ssl" in response to
> "openssl version -d", but if you try the same thing with an RPM package for
> Red Hat on a Red Hat system you'll get a different directory.
>
> Now, Sam Varshavchik could probably quote you verse and line on where Debian
> puts all the files in a Courier e-mail server and would probably tell you
> why he wishes they would accept the default locations. But Debian puts
> Courier here and Apache there and Apache-SSL somewhere else, and all the
> files would probably be found in a different location on Red Hat. Then
> Debian builds packages for apt so that they locate everything just so. So
> if you keep on installing the required software using apt-get or Synaptic
> Package Manager or Debian's Update Manager, then you will keep getting
> software packages that don't have any conflicts on installation, and you
> will have fewer copies of libraries all over everywhere. That gets to be
> important, because the library updates need to be managed to prevent that
> updating one software package doesn't break another.
>
> Debian does this extremely well, and has more FSF software available on
> their servers than any other linux implementation. And a number of popular
> linux implementations such as Ubuntu are essentially Debian at heart, so
> packages from the Debian servers may work pretty well on Ubuntu.
>
> Red Hat, and of the "nearly Red Hat" implementations such as Centos also do
> it very well, but the choice of RPM packages that are ready to go might not
> allow you to run Courier. Well, frankly, Debian doesn't really allow you to
> run the most current version of Courier using apt-get, etc. They won't
> update my Debian Etch Courier 0.53.3 right now, anyway, and I sure would
> like the Courier 0.57 stuff instead. Oh well. Nothing's perfect, but
> frankly working within the system seems pretty smart with Debian.
>
> I can tell you that Apache with Openssl and Courier with Openssl work
> straight out of the box without doing any compiling using Debian and
> apt-get. And before too long Debian will get around to providing more
> current versions of Courier.
>
> Lydiard writes:
>
>> ----- Message from [EMAIL PROTECTED] --------
>>> Lydiard writes:
>>>
>>>> I am running debian
>>>> I downloaded the source of courier-imap-4.2.1
>>>> I unpacked it as a user
>>>> All commands that I've run to date have been as non-root
>>>>
>>>> I am using these flags
>>>> CPPFLAGS="-I/usr/include/openssl -I/usr/local/include/openssl"
>>>
>>> Why?
>>
>> God, I've missed you :)
>>
>>> Why are you not using Debian's OpenSSL package?
>>
>> Cos Apache wouldn't compile with it
>
> And why do you want to compile Apache? Debian also has a perfectly fine
> Apache package.
>
>>> The standard OpenSSL library does not get installed in /usr/local. This
>>> must be some custom version of OpenSSL that you installed, and it's not
>>> built correctly. OpenSSL must be built as a shared library, not as a
>>> static library.
>>
>> I'm starting to think it may be the version/installation of make
>
> No, it's not.
>
>> that's the issue - postfix is choking as well (but not on the TLS).
>
> Maybe, but if the compile gets to the linking stage, it'll choke on it in
> exactly the same way.
>
>>> You need to clean up your system and remove all duplicate libraries and
>>> binaries that you installed yourself, that conflict with existing
>>> Debian packages, and are giving you these problems for no good reason.
>>> Debian has perfectly working OpenSSL runtime and development libraries,
>>> and there is no good reason to waste your time installing some mutated
>>> version of OpenSSL into /usr/local.
>>>
>>> Just use the standard Debian software libraries to build your code.
>>
>> Sam - tbh, if that's your opinion, I'm inclined to go with it. And
>> whilst it's not your problem, what will happen to Apache if I rip out
>> the OpenSSL?
>
> Debian should not let you rip out openssl if you have Apache installed,
> because Apache requires OpenSSL.
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>
----- End message from [EMAIL PROTECTED] -----
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
