Using SRPM method to install Shibboleth on Amazon EC2 ...

Michael A Grady mgrady at unicon.net
Fri Mar 13 13:52:02 EDT 2015


On Mar 13, 2015, at 8:43 AM, Peter Schober <peter.schober at univie.ac.at> wrote:

> * lhenry <larry.henry at ge.com> [2015-03-13 14:20]:
>> Hi Michael, Thanks for the reply. Actually I did follow those instructions
>> exactly as the OP did, and got the same result:
>> [root at ip-10-227-64-12 ~]# shibd -t
>> 2015-03-13 13:17:51 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific
>> options, this will greatly limit functionality
> 
> * Cantor, Scott <cantor.2 at osu.edu> [2015-03-13 14:22]:
>> Which means you didn't build the special libcurl package required to
>> fix what Red Hat broke, or didn't install it, or didn't use it at
>> runtime.
> 
> To elaborate slightly on the "didn't use at runtime" part: On a CentOS
> box I'd use a command like this to include the optional libcurl path
> in the `shibd -t` command:
> 
> $ LD_LIBRARY_PATH=/opt/shibboleth/lib64 shibd -t
> 
> Of course paths may different for you, and if you didn't build and
> install a copy of libcurl built against openssl that's also moot.
> 
> If you don't rely on SOAP requests (e.g. attrbute queries) that page
> sounds like you might get away with the OS suppplied version, though?
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRH6

My use was for internal testing, and I didn't need back channel support, so
I didn't worry about that libcurl error message. But given your note and this
discussion, I'd thought I'd see if I could get that message to "go away". So
I took a closer look.

Setting a LD_LIBRARY_PATH (at least on after building for Amazon AMI)
actually doesn't do any good. If one follows the SRPM instructions, the
/opt/shibboleth/lib64 version of libcurl gets built, but the only way to get it used
is to actually change the symlink for /usr/lib64/libcurl.so.4 to point to it (which,
of course, would impact anything on the system using that lib.) I'm assuming there
is something else embedded in what got built that is causing the /usr/lib64 version
to get used even though I've set LD_LIBRARY_PATH. (Both in init.d and in sysconfig,
and tested it was set by adding a "env" into the /etc/init.d/shibd script to see the
environment just before running "daemon ..".)

I'll note the "build from sprm" does not create the file /etc/sysconfig/shibd,
which /etc/init.d/shibd will use if it exists, and which is the RPM-build supplied
way to set the User to 'shibd' and the alternate LD_LIBRARY_PATH. But even if 
one creates that file with those settings, the User gets used, but the directory from
which libcurl gets loaded does not change -- it is still lib64.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.



More information about the users mailing list