[Shib-Users] request for simple sample shibboleth2.xml
Philip Brown
I'm trying to do a very basic from-scratch shibboleth sp install.
It's not working :-/
I dont "sprechen sie XML" very well. More than a tty page, tends to give me
a headache :-) and shibd is not helping me figure out the mess; point of
fact, it is CORE DUMPING, rather than giving me a useful error message.
So, i was wondering if someone could point me to an example of a minimalist
sample shibboleth2.xml file please?
No fancy stuff.. no extras. no backward compatibility .I just need something
that will request a single attribute (email addr), and pass it on to apache.
For a single application on the host.
SP 2.1, with IDP version 2 also.
Scott Cantor
> I dont "sprechen sie XML" very well. More than a tty page, tends to give
me
> a headache :-) and shibd is not helping me figure out the mess; point of
> fact, it is CORE DUMPING, rather than giving me a useful error message.
If you can, send me the file so I can plug the bug that's causing the core
dump (or actually please just file that as a bug and attach it).
> So, i was wondering if someone could point me to an example of a
minimalist
> sample shibboleth2.xml file please?
The default pretty much already is. Nothing that isn't a standard feature is
uncommented with the exception of some of the handlers inside <Sessions>. If
the comments are causing you trouble, you can delete anything inside <!--
--> to get more clarity. That would be the "sample" you're looking for.
Eventually there will be a different approach that defaults all of the
settings that aren't always touched, but as with most software, that isn't
where it started.
> No fancy stuff.. no extras. no backward compatibility .I just need
something
> that will request a single attribute (email addr), and pass it on to
apache.
> For a single application on the host.
The directions in the abstract for it are here:
https://spaces.internet2.edu/display/SHIB2/NativeSPApplication
Under Basic Configuration is a fairly good list of "what gets changed". If
you don't understand what the things being changed *are* or "mean", look
them up and/or ask. The worst thing you can do is randomly change things.
That leads to most of the weirder questions on this list.
-- Scott
Paul Hethmon
> So, i was wondering if someone could point me to an example of a minimalist
> sample shibboleth2.xml file please?
It will let you talk to it and will generate that xml for you.
Paul
-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----
God does not play dice with the universe; He plays an ineffable game of his
own devising, which might be compared, from the perspective of any of the
other players, to being involved in an obscure and complex version of poker
in a pitch dark room, with blank cards, for infinite stakes, with a dealer
who won't tell you the rules, and who smiles all the time.
-- Terry Pratchett, Good Omens
Philip Brown
> Philip Brown wrote on 2009-04-30:
> me
>> a headache :-) and shibd is not helping me figure out the mess; point of
>> fact, it is CORE DUMPING, rather than giving me a useful error message.
>
> dump (or actually please just file that as a bug and attach it).
>
ok.
Scott Cantor
the defaults we use more generally. It's a point of debate (I wouldn't say a
resolved one).
Anyway, the default files in the SP assume that your "single" application is
handled with the default settings found in the outer ApplicationDefaults
element and content, and doesn't rely on an ApplicationOverride. I point
this out because if somebody handed you a stripped down version, or you
started from the default file as I suggested, it wouldn't look like the one
you attached.
-- Scott
Philip Brown
> On 4/30/09 3:57 PM, "Philip Brown" <p...@usc.edu> wrote:
>
>> So, i was wondering if someone could point me to an example of a minimalist
>> sample shibboleth2.xml file please?
>
> www.testshib.org
>
> It will let you talk to it and will generate that xml for you.
>
> Paul
Thanks for the pointer.
The directions on that site, are a little lacking in some areas, though.
For example,
https://www.testshib.org/testshib-two/newSPEntry.do
> "Your SP generated a certificate for itself during installation.".
well, mine didnt.
it would be nice to have more explicit directions on what to do, on how to
generate the appropriate needful, if it wasnt automatically generated for you.
Philip Brown
> I would note that the example from USC uses an approach that is at odds with
> the defaults we use more generally. It's a point of debate (I wouldn't say a
> resolved one).
I'm trying to put together, a "kinder, gentler" set of config files.
even the "defaults" provided, arent particularly readable by mere mortals.
I'm trying to come up with a really-really-reduced sized set of config
files, that are going to be more comprehensible by a wide set of our
potential SP-desiring customers (not to mention, myself! :-)
The USC one is 298 lines.
the shibboleth2.xml.dist is still 258 lines!
Something tells me it should be possible to come up with a working version
of that, that is much, much smaller (eg: 100 lines or less, while still
being reasonable formatted) for simple installs.
Scott Cantor
>
> well, mine didnt.
If you "make install", it does this by running etc/shibboleth/keygen.sh,
which you can do yourself or use openssl directly.
Testshib just assumes the installation works, but if there's some evidence
it doesn't more than "rarely", I'm sure Nate can add a note.
-- Scott
Philip Brown
> Philip Brown wrote on 2009-04-30:
>> well, mine didnt.
>
> which you can do yourself or use openssl directly.
>
> Testshib just assumes the installation works, but if there's some evidence
> it doesn't more than "rarely", I'm sure Nate can add a note.
>
That works great if you are installing directly from source.
Trouble is, i'm trying to deal with an install from a binary package
(which i'm making myself:)
So some kind of more standalone "generate-shib-keys" utility script that
gets installed somewhere itself, could be useful.
Nate Klingenstein
else reporting failure to generate keys in the past. If I do hear it
more times, I'll be glad to add a note.
Scott Cantor
> files, that are going to be more comprehensible by a wide set of our
> potential SP-desiring customers (not to mention, myself! :-)
My best guess, you won't succeed without altering the code (i.e. supplying a
plugin designed to support a reduced configuration). That is not a planned
deliverable until after 2.2 is done.
> the shibboleth2.xml.dist is still 258 lines!
> Something tells me it should be possible to come up with a working version
> of that, that is much, much smaller (eg: 100 lines or less, while still
> being reasonable formatted) for simple installs.
You'll chop some number of lines by deleting the SingleLogout and NameIDMgmt
handlers and not affect most sites unless you're planning on logout. The
only other non-commented content would probably be the alternate
SessionInitiators, though I suppose some of the SSO bindings could also be
chopped.
-- Scott
Scott Cantor
There is, keygen.sh. Any package with the SP in it has that script or its
omitting files. There's nothing the Makefile does but run a script that's
included in the software.
-- Scott
Nate Klingenstein
with significant comments. It won't work in every scenario, but it
could probably be compressed further, as well. It strikes me as a
reasonable intermediate point.
https://www.testshib.org/cgi-bin/sp2config.cgi?dist=Others&hostname=myhost.intestshib.org
Philip Brown
> On 4/30/09 3:57 PM, "Philip Brown" <p...@usc.edu> wrote:
>
>> So, i was wondering if someone could point me to an example of a minimalist
>> sample shibboleth2.xml file please?
>
> www.testshib.org
>
> It will let you talk to it and will generate that xml for you.
>
Ooo!
I'm happily surprised to see, that the "shibboleth.xml" generated by that
set of scripts, is much, much smaller, than the sample one I was dealing
with internally.
it's almost readable as-is :-)
and shibd starts up now.
So I'm tossing out a buncha stuff, going to full .dist defaults, and seeing
where things lead from there.
hmm... not so good.
apache works, but anything under the "secure" dir, just goes off into limbo.
plain empty page.
aaand... there are whines in the apache err log about
[Thu Apr 30 15:19:12 2009] [notice] child pid 20327 exit signal Segmentation
fault (11)
Apparently, the apache2 httpd servicing the request, is crashing with
segfault for some reason, when it gets the shib request.
arg.
I'm just Includeing the apache22.config file straight as it comes from the
SP-2.1 tree.
no fancy stuff here.
Philip Brown
oh, excellent! and its already in our package :) i'll add it to the package
docs.
Might be nice to reference that in the testshib.org stuffs, then.
eg:
"if you dont have the file sp-cert.pem in your etc/shibboleth directory
already, you can run the keygen.sh script to generate one for yourself", and
plug it into this form.
Scott Cantor
As Nate said, there's no evidence this happened to anybody until you
mentioned it, so my assumption is your package installer simply didn't run
it, and it probably should do so.
But nothing you're creating should involve testshib, since combining that
with anything custom is just a disaster waiting to happen. (Not to say you
can't borrow the concepts or use it to identify simplifcations, I meant
combining them explicitly).
-- Scott
Philip Brown
>
> As Nate said, there's no evidence this happened to anybody until you
> mentioned it, so my assumption is your package installer simply didn't run
> it, and it probably should do so.
>
> But nothing you're creating should involve testshib, since combining that
> with anything custom is just a disaster waiting to happen. (Not to say you
> can't borrow the concepts or use it to identify simplifcations, I meant
> combining them explicitly).
>
I'm trying to design a package to promote more shibboleth use on campus.
Thus, the target audience for the package, is a generic case shib-clueless
(and somewhat tech-clueless) customer,that will result in the least amount
of calls to us, (and you :) both at initial install time, and for long-term
support purposes.
So I'm trying to document as part of the post-deployment verification phase,
"here, try this with the simplified configs, against this outside
testshib.org, which is known to work. If it doesnt work with THEM, then our
IDP isnt broken either. Fix the install on YOUR machine"
:-)
only trouble is, as mentioned a few mins ago, the simple case is not working
for me either - apache2 is crashing, when anything under /secure is
requested. Something's up with apache+mod_shib22, I guess...
Ugh.
just crashing, is very ugly behaviour, though.
Scott Cantor
> Thus, the target audience for the package, is a generic case shib-clueless
> (and somewhat tech-clueless) customer,that will result in the least amount
> of calls to us, (and you :) both at initial install time, and for
long-term
> support purposes.
I understand, but I think custom packages ultimately are counter-productive
and instead I provide files for my customers to use when they install,
rather than a separate installer.
> So I'm trying to document as part of the post-deployment verification
phase,
> "here, try this with the simplified configs, against this outside
> testshib.org, which is known to work. If it doesnt work with THEM, then
our
> IDP isnt broken either. Fix the install on YOUR machine"
I would tend to think that's pretty dangerous, but to each his own. Last I
knew we posted the testshib IdP's private key to hammer home this point.
> only trouble is, as mentioned a few mins ago, the simple case is not
> working for me either - apache2 is crashing, when anything under /secure
> is requested. Something's up with apache+mod_shib22, I guess... Ugh.
>
> just crashing, is very ugly behaviour, though.
If you can show it's my code crashing, I'll fix it, but a conflict is a lot
more likely, and on Solaris it's practically a certainty.
Unfortunately, the code is so far beyond 2.1 at this point that it's
difficult to address low level issues. Depending on your timeline, you may
be better off working with newer code, one reason being some config changes
have been made. There is no breaking change (nor will there be, ever), but
there are some deprecated structures and the defaults are adjusted as a
result.
For planning purposes, 2.2 is out no later than end of June. Ironclad
promise.
-- Scott
Philip Brown
> Philip Brown wrote on 2009-04-30:
>>
>> working for me either - apache2 is crashing, when anything under /secure
>> is requested. Something's up with apache+mod_shib22, I guess... Ugh.
>>
>> just crashing, is very ugly behaviour, though.
>
> more likely, and on Solaris it's practically a certainty.
>
not sure why you think "conflicts" are more likely on solaris. apache is
apache, isnt it?
But just in case I somehow goofed doing a compile of my own apache, I did a
fresh compile of shibboleth, against **sun apache2**, to get a new mod_shib.
So this would be using mod_shib_20.
still same invisible problem.
[Thu Apr 30 17:05:55 2009] [notice] child pid 17679 exit signal Segmentation
fault (11)
Maybe somethin wrong with my other dependancy libs, lib xercesc, and so on?
So i added the
CoreDumpDirectory
directive to my sun apache configs.
then RE-recompiled mod_shib, with -g
also ran httpd under dbx, with -X.
Got the following blow-up:
t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0x2fc083
0x002fc083: <bad address 0x2fc083>
Current function is shibsp::SSCache::active
112 return (session_id ? session_id : "");
(dbx) where
current thread: t@1
[1] 0x2fc083(0x80473c7, 0x0), at 0x2fc083
=>[2] shibsp::SSCache::active(this = 0x81f8978, application = CLASS, request
= CLASS), line 112 in "StorageServiceSessionCache.cpp"
[3] shibsp::SSCache::find(this = 0x81f8978, application = CLASS, request
= CLASS, client_addr = 0x830818c "68.181.191.168", timeout = 0x8047514),
line 123 in "StorageServiceSessionCache.cpp"
[4] shibsp::AbstractSPRequest::getSession(this = 0x8047840, checkTimeout
= true, ignoreAddress = false, cache = true), line 101 in
"AbstractSPRequest.cpp"
[5] shibsp::ServiceProvider::doAuthentication(this = 0x81dfe90, request =
CLASS, handler = true), line 210 in "ServiceProvider.cpp"
[6] shib_check_user(r = ???) (optimized), at 0xfe2f5731 (line ~560) in
"mod_apache.cpp"
[7] ap_run_check_user_id(0x82f6208), at 0x80817ed
[8] ap_process_request_internal(0x82f6208), at 0x8082003
[9] ap_process_request(0x82f6208), at 0x806c52b
[10] 0x8067f70(0x81d0078), at 0x8067f70
[11] ap_run_process_connection(0x81d0078), at 0x8077601
[12] ap_process_connection(0x81d0078, 0x81cffa0), at 0x807788a
[13] 0x806d915(0x0), at 0x806d915
[14] 0x806da41(0x80b6bd0, 0x0), at 0x806da41
[15] 0x806db28(0x5), at 0x806db28
[16] ap_mpm_run(0x80b4df0, 0x80e0ea0, 0x80b6bd0), at 0x806de53
[17] main(0x4, 0x8047b5c, 0x8047b70), at 0x8073585
Scott Cantor
> not sure why you think "conflicts" are more likely on solaris. apache is
> apache, isnt it?
Of the errors that occur that never show up on any other system, probably
80% or more of them are on Solaris. Different compiler, different runtime,
various reasons. Common sense dictates that a working configuration doesn't
just crash instantly when you use it, or the software wouldn't work for
anybody, which isn't the case.
I see a lot of reports of seg faults on Solaris, except for my builds at
least, which tells me I'm doing something others aren't doing. Then again, I
have no Sparc instance except for 2.8 either, and I suspect that's part of
the problem. If people stopped requiring 2.8 support, I'd move up.
> Maybe somethin wrong with my other dependancy libs, lib xercesc, and so
on?
More likely a runtime library issue, reinforced by the stack trace.
> t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at
> 0x2fc083 0x002fc083: <bad address 0x2fc083> Current function is
> shibsp::SSCache::active
> 112 return (session_id ? session_id : "");
Which is absurd, so something's up. The pointer it's trying to dereference
is the result of parsing the cookie header returned from Apache, routine
code that gets run all over the place. Something's just not right and there
are no config changes that are going to matter.
The simple thing I would do is a routine scan with ldd and make sure there
aren't any obvious issues with the version of libCrun it's loading or
anything else that just looks off.
Best I could suggest is adjusting the flags. I use particular optimize
levels that have worked for me, but I don't pretend to have exhaustive
knowledge of them. If you did a debug build, make sure it's turning all
those off, perhaps and start from there?
This is a total side track essentially, a corrupt build somewhere. That's
the thing I don't see anywhere else much.
-- Scott
Philip Brown
> ....
> More likely a runtime library issue, reinforced by the stack trace.
>
>> 0x2fc083 0x002fc083: <bad address 0x2fc083> Current function is
>> shibsp::SSCache::active
>> 112 return (session_id ? session_id : "");
>
Well, Scott's instincts were correct.
I did a FUUULLL rebuild of #$@$ everything in the shibd chain.
Which in our case, meant i had to repackage:
USCdb4
USCxercesc2
USClog4shib
USCxmlsecurityc
USCsasl
USCopenldap
USCcurl
USCxmltooling
USCopensaml
USCshibsp2
What I did this time, was ensure that everything was built with -mt.
Specifically, I used
CC=cc CXX=CC
CFLAGS="-O -mt -xnorunpath"
CXXFLAGS="-O -mt -norunpath" (yes that is one letter different on purpose)
aaand.. it worked. I now have a happy test page from
https://idp.testshib.org/idp/Authn/UserPassword
Thank you Scott!
BTW: this was on solaris 10 x86.
Our solaris 8 sparc builds were for some reason, happier. But now I feel
like i should rebuild them anyway "Just to make sure". ugh...
Scott Cantor
> What I did this time, was ensure that everything was built with -mt.
The packages I'm maintaining, at least, are supposed to use that option
automatically, so if something wasn't doing that I need to fix the autoconf
tests. The ones that probably need manual intervention are probably openssl,
curl, and xerces. The others in the SP build set are mine or maintained by me.
> BTW: this was on solaris 10 x86.
> Our solaris 8 sparc builds were for some reason, happier. But now I feel
> like i should rebuild them anyway "Just to make sure". ugh...
Using -mt is definitely not optional, whatever the superficial test results.
Glad it worked, and I'll continue to reinforce the -mt mantra, I guess.
-- Scott