Listener won't start after modifying config for Shib IdP delegation plugin configuration

[Karla Borecky]

Yes, it seemed clear that things were failing at an early stage, and in a
very broad way. Not having those jar files in the idp.war would pretty much
make everything come to a screeching halt, would it??

I just recently had a Tomcat update that didn't work, and in the process
found out that my tomcat setup wasn't standard: /etc/tomcat6/Catalina was
supposed to be a symlink, but it was a real directory - and it was where I
was successfully putting my idp.war (under localhost). Why or how is lost
in the mists of time, frankly. But bringing my tomcat setup back to
standard of course made my branded login page go away, and I had to find
where the generic idp.war was getting loaded from. Well, try to find is
probably more accurate, in hindsight.

I did see the /idp directory tomcat created in webapps, and was suspicious
about what was in there. Maybe the reason I got it to recognize my
customized idp.war again last week was because the /idp directory hadn't
been created on the snapshot I reverted to, so Tomcat re-unpacked it, using
the correct one? Well, either way, I really like the deployment fragment
idea. It certainly saves some steps, and it seems a lot clearer than
humoring Tomcat!

Thank you for you help. I hope I haven't exhausted everyone's patience!

Karla

On Wed, Apr 18, 2012 at 9:57 PM, Brent Putman <putmanb at georgetown.edu>wrote:

>
>
> On 4/18/12 4:23 PM, Karla Borecky wrote:
>
> The only step I didn't do yet was to modify the idp metadata file to add
> an SSO endpoint. I don't know if that's a deal-breaker? Perhaps so.
> Goodness knows the error could be in any one of those files! I just started
> with the first one it complained about.
>
>
>
> If you are still dealing with the "Classpath resource does not exist"
> error: no, that wouldn't have anything to do with, nor would any of the
> other config files.  That cause of that error is unambiguously that you
> aren't running the idp.war that you think you are.
>
>
>
>
> I sort of figure the internal.xml file must be loaded early on in the
> process, though.
>
>
>
> It is.  It is in fact the first one loaded.  See the idp.war's
> /WEB-INF/web.xml.  None of this is relevant to your problem though.
>
>
>
>
>  I'm attaching the whole shebang. I feel confident the idp.war that shows
> the correct contents is in the right place (/srv/tomcat6/webapps -
> running SLES 11 SP1, FYI.)
>
>
> Well, that is a hint as to the idp.war problem.  We usually don't
> recommend that you copy or put the war in the webapps directory because,
> amongst other reasons, Tomcat does seemingly unpredictable things with what
> it actually deploys, especially if you have it set to unpack the war.  We
> recommend that you use a context deployment fragment, as documented here:
>
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
>
> That section in the wiki even highlights the exact issue you are probably
> experiencing.
>
> --Brent
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120419/90de886f/attachment.html