Shibboleth SP 2.5.1 and CentOS 5.8 x64

[Dan McLaughlin]

Never mind, I spoke too soon it actually did die…I was looking at a
cached page in the browser.

--

Thanks,

Dan

On Tue, Jan 8, 2013 at 8:04 PM, Dan McLaughlin
<dmclaughlin at tech-consortium.com> wrote:
> I figured it out.  If you have a system that had 2.4.3 on it and you
> don't update the init.d script after installing 2.5.1, then the shibd
> process will die with a Segmentation Fault.  Our wrapper build/install
> script normally updates the init.d script, but on CentOS when running
> as root, cp is aliased to "cp -i" which causes the init.d script not
> to get overwritten.  Changing my script to use \cp -f  causes the
> init.d script to get overwritten with the new init.d script and now
> things work.
>
> --
>
> Thanks,
>
> Dan
>
> On Tue, Jan 8, 2013 at 6:09 PM, Dan McLaughlin
> <dmclaughlin at tech-consortium.com> wrote:
>> As a test to see if it was anything odd about the CentOS install I
>> deleted the /opt/shibboleth-sp directory and rebuilt everything using
>> the following versions (build commands didn't change) and everything
>> works fine. Which would suggest to me that there isn't anything wrong
>> with the OS install/configuration.  I'm going to rebuild everything
>> with the debug symbols for SP 2.5.1 and see if I can get you a stack
>> trace using gdb.  It's been forever since I've used gdb, would you
>> mind sending me the steps to capture what you need?
>>
>> ZLIB_VERSION=1.2.3
>> OPENSSL_VERSION=0.9.8x
>> LOG4SHIB_VERSION=1.0.4
>> XERCES_C_VERSION=3.1.1
>> XML_SECURITY_C_VERSION=1.6.1
>> CURL_VERSION=7.28.1
>> OPENSAML_VERSION=2.4.3
>> XMLTOOLING_VERSION=1.4.2
>> SHIBBOLETH_SP_VERSION=2.4.3
>>
>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Dan
>>
>>
>> On Tue, Jan 8, 2013 at 11:51 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>> On 1/8/13 12:28 PM, "Dan McLaughlin" <dmclaughlin at tech-consortium.com>
>>> wrote:
>>>
>>>>Has anyone tried running SP 2.5.1 on CentOS 5.8 x64 yet?    The SP
>>>>accepts the SAML2 Post and then dies with a Segmentation Fault when it
>>>>tries to store the attributes for the new session.   See strace log
>>>>belowŠ
>>>
>>> A stack trace from a core dump or running shibd under gdb is probably more
>>> illuminating, but whatever it is is either something unique in your IdP's
>>> output that hit a bug, or your box, or your build.
>>>
>>> I find the stat of /etc/localtime curious, and don't really know what
>>> /etc/localtime is, actually. Seems to be a link to the local system's
>>> timezone info file? That would be used by some underlying system call,
>>> it's nothing I'm doing directly. Maybe there's something wacky about your
>>> system.
>>>
>>>
>>> -- Scott
>>>
>>>
>>> --
>>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net