Re: [squid-users] Compiling squid-3.3.5 with SSL on RedHat EL 6

Hey Peter,

Please take a look at the new 3.3.7 release which has couple bug and
security fixes which should solve the issues you are referring to.

I do hope to test it next week and distribute the new 3.3.7 RPM with
ssl-crtd support in it.
Since the RPM was created almost from scratch I am unsure about what are
all the dependencies like perl stuff are meant for, maybe helpers and
other stuff.
I have seen some dependency which was unclear to me in perl related to
OpenSSL libs and since I know what I compile I know I don't need it and
I am still waiting for someone else to answer what was the dependency
related to.

Best Regards,
Eliezer

On 07/11/2013 05:44 PM, Peter H. Lemieux wrote:
> I'm afraid that compiling OpenSSL then Squid 3.3.5 did not solve the
> problem either, Eliezer.
>
> I compiled openssl-1.0.1e and installed it to the default
> /usr/local/ssl. I then ran ./configure for squid-3.3.5 with
>
> ./configure --with-openssl=/usr/local/ssl --enable-ssl --enable-ssl-crtd
>
> Everything went swimmingly until libtool threw up this:
>
> Making all in ssl
> make[3]: Entering directory `/usr/local/src/squid-3.3.5/src/ssl'
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith
> -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -std=c++0x
> -g -o ssl_crtd ssl_crtd.o certificate_db.o libsslutil.la
> -L/usr/local/ssl/lib -lssl -lcrypto -L../../compat -lcompat-squid
>
> libtool: link: g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments
> -Werror -pipe -D_REENTRANT -g -O2 -std=c++0x -g -o ssl_crtd ssl_crtd.o
> certificate_db.o ./.libs/libsslutil.a -L/usr/local/ssl/lib -lssl -lc
> rypto -L/usr/local/src/squid-3.3.5/compat -lcompat-squid
>
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_globallookup':
> dso_dlfcn.c:(.text+0x31): undefined reference to `dlopen'
> dso_dlfcn.c:(.text+0x44): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x4f): undefined reference to `dlclose'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_pathbyaddr':
> dso_dlfcn.c:(.text+0x9e): undefined reference to `dladdr'
> dso_dlfcn.c:(.text+0x101): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
> dso_dlfcn.c:(.text+0x444): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x4eb): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
> dso_dlfcn.c:(.text+0x564): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x61e): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
> dso_dlfcn.c:(.text+0x67f): undefined reference to `dlclose'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
> dso_dlfcn.c:(.text+0x734): undefined reference to `dlopen'
> dso_dlfcn.c:(.text+0x7a0): undefined reference to `dlclose'
> dso_dlfcn.c:(.text+0x7d0): undefined reference to `dlerror'
> collect2: ld returned 1 exit status
> make[3]: *** [ssl_crtd] Error 1
> make[3]: Leaving directory `/usr/local/src/squid-3.3.5/src/ssl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/local/src/squid-3.3.5/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/squid-3.3.5/src'
> make: *** [all-recursive] Error 1
>
> It seems to be using /usr/local/ssl/lib/libcrypto.a for all of these, so
> I don't think it's a versioning problem. Is there some other
> configuration option I should use along with those I mentioned above?
>
> Peter
>
>
> On 06/29/2013 08:51 AM, Eliezer Croitoru wrote:
>> Hey Peter,
>>
>> At the time it was a thread which indicates that the problem is deep
>> inside the fact that CentOS didn't fixed the openssl issues.
>> I could have built squid in a portable format that will include Openssl
>> but it's much simpler to just compile from source since you already have
>> the Development Tools.
>> Just compile new version of OpenSSL in the basic /usr/local/... prefix
>> and then build squid based on it with the ssl option referring to this
>> specific location\libs.
>>
>> I now it's not like installing a RPM but it's far more reliable in your
>> case.
>>
>> I hope that you understand the main issues we are having to "force"
>> CentOS distro to update and upgrade their OpenSSL libs.
>>
>> Eliezer
>>
>> On 06/28/2013 07:03 PM, Peter H. Lemieux wrote:
>>> In May, Eliezer seemed to indicate that using CentOS 6.4 would be
>>> sufficient to build squid with the --enable-ssl-crtd extension without
>>> needing to patch the source code.
>>>
>>>> The above is known issue with RHEL 6.3 and CentOS 6.3. This issue
>>>> requires you to either install some custom openssl libs and headers
>>>> or upgrade to 6.4(which is much more reasonable to me) and use the
>>>> fixed openssl in 6.4.
>>>
>>> I installed a clean version of CentOS 6.4 in a VM, added the
>>> "Development Tools" packages and all the openssl packages including, of
>>> course, openssl-devel. I still get same errors Chris Ross reports below
>>> when trying to compile 3.3.5.
>>>
>>> Is it really still not possible to compile 3.3.5 with --enable-ssl-crtd
>>> on a RedHat or CentOS platform without having to patch the source code?
>>> I had hoped that upgrading to 6.4 would solve this problem, but that
>>> does not seem to be the case.
>>>
>>> This thread got rather lengthy and convoluted before which made it hard
>>> for me to see exactly what the solution might be. If there is a patch
>>> required to resolve this problem, could you please repost it again in
>>> response to this message?
>>>
>>> My openssl packages are both versioned 1.0.0-27.el6.4.2.x86_64, the same
>>> version Chris reported in another post in this thread.
>>>
>>> Thanks!
>>>
>>> Peter
>>>
>>>
>>> On 05/21/2013 10:28 AM, Eliezer Croitoru wrote:
>>>> On 5/21/2013 5:23 PM, Chris Ross wrote:
>>>>>
>>>>> I had gotten a patch for compiling with SSL on RHEL6 from the net,
>>>>> presumably by following something noted on this mailing list. When
>>>>> 3.3.5 came out yesterday, and the change log noted that this issue had
>>>>> been addressed, I was pleased to upgrade to 3.3.5.
>>>>>
>>>>> However, with an unmodified tree, I seem to still be unable to
>>>>> compile certificate_db.cc on my x86_64 RedHat EL 6.3 host. The
>>>>> following are the compilation errors:
>>>>>
>>>>> g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src
>>>>> -I../../include -I../../libltdl -Wall -Wpointer-arith
>>>>> -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2
>>>>> -std=c++0x -MT certificate_db.o -MD -MP -MF .deps/certificate_db.Tpo
>>>>> -c -o certificate_db.o certificate_db.cc
>>>>> certificate_db.cc: In static member function ‘static void
>>>>> Ssl::CertificateDb::sq_TXT_DB_delete(TXT_DB*, const char**)’:
>>>>> certificate_db.cc:170: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:170: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteInvalidCertificate()’:
>>>>> certificate_db.cc:520: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:520: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteOldestCertificate()’:
>>>>> certificate_db.cc:551: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:551: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteByHostname(const std::string&)’:
>>>>> certificate_db.cc:568: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:568: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> make[3]: *** [certificate_db.o] Error 1
>>>>>
>>>>>
>>>>> Is anyone either in the core squid team, or in the user community,
>>>>> aware both of the short-coming of the fix for bug 3759, and a way to
>>>>> address the issue myself in the short term?
>>>>>
>>>>> Thanks…
>>>>>
>>>>> - Chris
>>>>>
>>>> The above is known issue with RHEL 6.3 and CentOS 6.3.
>>>> This issue requires you to either install some custom openssl libs and
>>>> headers or upgrade to 6.4(which is much more reasonable to me) and use
>>>> the fixed openssl in 6.4.
>>>>
>>>> Eliezer
>>>
>
Received on Thu Jul 11 2013 - 15:02:00 MDT