changes in login pages - kills IDP?

118 views
Skip to first unread message

Oleg Chaikovsky

unread,
Mar 18, 2012, 8:47:17 PM3/18/12
to us...@shibboleth.net
We had some of our folks change the login pages and related components
(added header, footer, etc) to meet the look and feel of the primary
user site. I re-ran the IdPs ./install.sh without making changes to the
configs (answered NO). when I restart tomcat there are NO entries in
the idp-process.log at all and when I try to garner a status, or test
the site, I go directly to the 404 error page the web admins created.

I have looked at the mods to each page and it appears all required
components are there. If I put back the default sample pages from the
dist the idp boots fine and I can test it with TestSP no problem. Since
there are no entries at all in the idp-process log there's something
else not even allowing the application to load through Tomcat and I
can't figure out where to look. Any help or pointers in the right
direction would be great. RHEL 6, using TOmcat 6. We have followed all
recommendations with the OS and JVM changes, and as I said it works
great with the default login pages...

--
Oleg Chaikovsky
AegisUSA - The Identity Company
303-222-1064
714-742-2823 mobile
http://www.aegisusa.com
twitter- @aegisidentity

--
To unsubscribe from this list send an email to users-un...@shibboleth.net

Paul Hethmon

unread,
Mar 18, 2012, 9:40:18 PM3/18/12
to Shib Users, us...@shibboleth.net
You've broken it at the container level somehow if there is nothing in the process log. Check the Tomcat logs.

Paul


(Sent from a phone that doesn't have a keyboard)

Stephen Chan

unread,
Mar 19, 2012, 1:11:40 AM3/19/12
to Shib Users

   Check the contents of /var/log/tomcat6/catalina.out
   No doubt tomcat6 has left some complaints about the contents of the warfile.

   Steve

Oleg Chaikovsky

unread,
Mar 19, 2012, 5:35:17 PM3/19/12
to us...@shibboleth.net

Yeah - I pretty much felt this was the issue but the catalina.out log
file did not offer succinct clues to me (well, at least that pointed me
in the right direction). the threads errors were well known in this list
that its something that can be ignored. it also showed the deployment
descriptor for idp.xml which made me wonder why that showed up.

I realize this is the shib list, and not the tomcat list. If you can
point me to a possible avenue
of solution I will go there otherwise I will check Tomcat lists


see my catalina.out below
------------------------------------------------------------------------------------

Mar 18, 2012 5:36:27 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Mar 18, 2012 5:36:27 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/idp] appears to have started a thread
named [MultiThreadedHttpConnectionManager cleanup] but has failed to
stop it. This is very likely to create a memory leak.
Mar 18, 2012 5:36:27 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/idp] appears to have started a thread
named [Timer-1] but has failed to stop it. This is very likely to create
a memory leak.
Mar 18, 2012 5:36:27 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory.ThreadLocalSslConfig]
(value
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory$ThreadLocalSslConfig@291fc2])
and a value of type
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer] (value
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer@1e41869]) but
failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
Mar 18, 2012 5:36:33 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/java/jdk1.6.0_30/jre/lib/i386/client:/usr/java/jdk1.6.0_30/jre/lib/i386:/usr/java/jdk1.6.0_30/jre/../lib/i386::/apps/dev/apr/lib:/apps/dev/tomcat/lib:/usr/java/packages/lib/i386:/lib:/usr/lib
Mar 18, 2012 5:36:33 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 597 ms
Mar 18, 2012 5:36:33 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Mar 18, 2012 5:36:33 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
Mar 18, 2012 5:36:33 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
Mar 18, 2012 5:36:33 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor idp.xml
Mar 18, 2012 5:36:52 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor manager.xml
Mar 18, 2012 5:36:52 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory docs
Mar 18, 2012 5:36:52 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
Mar 18, 2012 5:36:53 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory examples
Mar 18, 2012 5:36:54 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Mar 18, 2012 5:36:55 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/60 config=null
Mar 18, 2012 5:36:55 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 21699 ms
Mar 18, 2012 5:46:25 PM org.apache.catalina.startup.HostConfig
checkResources
INFO: Undeploying context [/idp]
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/idp] appears to have started a thread
named [MultiThreadedHttpConnectionManager cleanup] but has failed to
stop it. This is very likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/idp] appears to have started a thread
named [Timer-1] but has failed to stop it. This is very likely to create
a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory.ThreadLocalSslConfig]
(value
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory$ThreadLocalSslConfig@cdf872])
and a value of type
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer] (value
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer@7227a8]) but
failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory.ThreadLocalSslConfig]
(value
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory$ThreadLocalSslConfig@cdf872])
and a value of type
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer] (value
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer@899e6a]) but
failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type [org.apache.xml.security.algorithms.SignatureAlgorithm$3] (value
[org.apache.xml.security.algorithms.SignatureAlgorithm$3@ff665a]) and a
value of type [java.util.HashMap] (value
[{http://www.w3.org/2000/09/xmldsig#rsa-sha1=Sun RSA private CRT key,
2048 bits
modulus:
16774957166316599701928033554832039253852485214770847429037183550999407472154794428769314084553458618569368767425416970579927865437828569120168332236862572662033263830313265537940850585822713106202152712009235707865758613702994228646253876828004006839007305935142908128131478186830370045981046976949454722964517527335038776909287550692984808147324305248088824786976504147128089738525226782666052930298171765039807991275657908965711845707961568133778568910629331386418410838591150196363755405576614710192484295660534236440468050413549702471741429071674427433678471535233230183062931587244881548865468725312445147223121
public exponent: 65537
private exponent:
6866682574740610955698664207630485329861004026071646916684934054391581919457660102546567419111580242616544179985682302664872130950465035381338112042331999279862770172205227193590478640552144963914813781605379653248008092067232649829761093026303668026764255250043163348236616954057987659238804755338557179195906501884901059725482315193407349121815334406532744666376572609379454077469409301704644624475188898761418618692041321814188258518440585140728701971527987339555009143657245726077817681756258715361365577681356928363148633175287055810401716758709192865387439353439940336358153271997865798266395773756098481730573
prime p:
143814101092153293258653559324891430200646806311937230263759738799195985390788589712423429222316968975445241393263260731613730257927831783963222448972237521305943640085521173257681255232586423802433777239165106154225369819035143866704082310864771217180414162905820539456957929677874813208982086883501527207311
prime q:
116643340527279252927003860825181584741671227368400316234068481057813055512166697601286907635274229540819602559909386828184077409140582871307241153272641400341280176182413115626224095948832124738064986513101749880842450512552811982369985102199883494281759877028145103258402517039771829741372021637896309575711
prime exponent p:
47161949138235784041304641607192374046299054904193889754317779365432047820602535515806404639303542994343182141752201041302505313080930782625655383574337073834739776198453103676611464324866066807481372971361772151099556710723763858327420190504686863903466151779481743656391653945662533919578909795996381017433
prime exponent q:
64338314489839597693795299830164473607682274106845034584209553714068146904943985101376633414827168220563770281492354310573053607321405163722560697768477562002181013607855893873268151493878762792869847528298749659620881999149665080041695400452013190026875471789835014384057747356008237687426296751275061337143
crt coefficient:
3555895788419534998235027295222359422458148621564387069997560520011089745481148283945291803213824850260701527791265770546745093988617962592904126073364820669584705919412947506657750858820550558495769326736869051967100418333431091312255283907006079895219015994819081402355445126906484868074631133512799897258}])
but failed to remove it when the web application was stopped. This is
very likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type [org.apache.xml.security.algorithms.MessageDigestAlgorithm$1]
(value
[org.apache.xml.security.algorithms.MessageDigestAlgorithm$1@198c113])
and a value of type [java.util.HashMap] (value
[{http://www.w3.org/2000/09/xmldsig#sha1=SHA-1 Message Digest from SUN,
<initialized>
}]) but failed to remove it when the web application was stopped. This
is very likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type [org.apache.xml.security.utils.UnsyncBufferedOutputStream$1] (value
[org.apache.xml.security.utils.UnsyncBufferedOutputStream$1@37eaab]) and
a value of type [byte[]] (value [[B@10f80a9]) but failed to remove it
when the web application was stopped. This is very likely to create a
memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type [org.apache.xml.security.utils.UnsyncByteArrayOutputStream$1]
(value
[org.apache.xml.security.utils.UnsyncByteArrayOutputStream$1@1780f30])
and a value of type [byte[]] (value [[B@12d297a]) but failed to remove
it when the web application was stopped. This is very likely to create a
memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory.ThreadLocalSslConfig]
(value
[edu.vt.middleware.ldap.ssl.ThreadLocalTLSSocketFactory$ThreadLocalSslConfig@cdf872])
and a value of type
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer] (value
[edu.vt.middleware.ldap.ssl.DefaultSSLContextInitializer@1fe3238]) but
failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [/idp] created a ThreadLocal with key of
type [org.apache.xml.security.algorithms.SignatureAlgorithm$1] (value
[org.apache.xml.security.algorithms.SignatureAlgorithm$1@19331eb]) and a
value of type [java.util.HashMap] (value
[{http://www.w3.org/2000/09/xmldsig#rsa-sha1=org.apache.xml.security.algorithms.implementations.SignatureBaseRSA$SignatureRSASHA1@b27bb5}])
but failed to remove it when the web application was stopped. This is
very likely to create a memory leak.
Mar 18, 2012 5:46:25 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor idp.xml
Mar 18, 2012 5:46:36 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Mar 18, 2012 5:46:40 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/java/jdk1.6.0_30/jre/lib/i386/client:/usr/java/jdk1.6.0_30/jre/lib/i386:/usr/java/jdk1.6.0_30/jre/../lib/i386::/apps/dev/apr/lib:/apps/dev/tomcat/lib:/usr/java/packages/lib/i386:/lib:/usr/lib
Mar 18, 2012 5:46:40 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 535 ms
Mar 18, 2012 5:46:40 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Mar 18, 2012 5:46:40 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
Mar 18, 2012 5:46:40 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
Mar 18, 2012 5:46:40 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor idp.xml
Mar 18, 2012 5:46:41 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor manager.xml
Mar 18, 2012 5:46:41 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory docs
Mar 18, 2012 5:46:41 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
Mar 18, 2012 5:46:41 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory examples
Mar 18, 2012 5:46:41 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Mar 18, 2012 5:46:41 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/27 config=null
Mar 18, 2012 5:46:41 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1034 ms
---------------------------------------------------------------------

------------------------------

Message: 4
Date: Sun, 18 Mar 2012 22:11:40 -0700
From: Stephen Chan<syc...@lbl.gov>
Subject: Re: changes in login pages - kills IDP?
To: Shib Users<us...@shibboleth.net>
Message-ID:
<CA+n9YfpNOGtJ6Ogd5nNRu9EHtgmaQq=XmFVBdKQUXXBu=vA...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Check the contents of /var/log/tomcat6/catalina.out
No doubt tomcat6 has left some complaints about the contents of the
warfile.

Steve
----------------

On Sun, Mar 18, 2012 at 5:47 PM, Oleg Chaikovsky<
oleg.ch...@aegisusa.net> wrote:

can't figure out where to look. Any help or pointers in the right
direction would be great. RHEL 6, using TOmcat 6. We have followed all
recommendations with the OS and JVM changes, and as I said it works
great with the default login pages...

------------------------------------------------

Paul Hethmon

unread,
Mar 19, 2012, 5:52:57 PM3/19/12
to Shibboleth Users
Kill Tomcat completely, clear all of your Tomcat and Shib logs. Then start
it up.

Do not load or reload the IdP code using Tomcat's reload feature (bug).

I don't see an error beyond that.

Paul

Chad La Joie

unread,
Mar 19, 2012, 5:57:34 PM3/19/12
to Shib Users
The behavior your describing is uncommon for JSP changes. Those are
compiled at runtime when a request comes in and if the compilation
fails Tomcat spits out some gross stacktrace.

So I'd do what Paul just suggested and then log in to the Tomcat
manager and see what it says the status of the IdP app and what
context path it claims to be mounted under. I'm wondering if the
web.xml file is corrupted in some way. Did you add anything to it
(e.g., servlet filters or taglibs) when doing the JSP updates? If
taglibs, perhaps a TLDs is corrupted to. Whatever it is, it's
something Tomcat is checking *before* it starts up anything to do with
the IdP itself.

On Mon, Mar 19, 2012 at 17:35, Oleg Chaikovsky
<oleg.ch...@aegisusa.net> wrote:
>
>
> Yeah - I pretty much felt this was the issue but the catalina.out log
> file did not offer succinct clues to me (well, at least that pointed me
> in the right direction). the threads errors were well known in this list
> that its something that can be ignored. it also showed the deployment
> descriptor for idp.xml which made me wonder why that showed up.
>
> I realize this is the shib list, and not the tomcat list. If you can
> point me to a possible avenue
> of solution I will go there otherwise I will check Tomcat lists

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

Sharma, Dattathreya

unread,
Mar 20, 2012, 12:06:28 AM3/20/12
to Shib Users
Anything in tomcat localhost log?

I think this could happen if container cannot not start IdP due to
incorrect file paths in web.xml.
<context-param>
<param-name>contextConfigLocation</param-name>

<param-value>file:///opt/tomcat/webapps/idp/WEB-INF/classes/conf/internal.x
ml;
file:///opt/tomcat/webapps/idp/WEB-INF/classes/conf/service.xml;</param-val
ue>
</context-param>

Whether you are using relative or absolute path, make sure container can
load this.

Datta

Oleg Chaikovsky

unread,
Mar 20, 2012, 7:45:54 PM3/20/12
to us...@shibboleth.net
I went back and took the original login page, added the graphics from our web team and made the changes to referencing the campus resource; what I also changed was to reference the login.css prior to the campus style sheet (they created their own for headers and footers), and removed reference in the css and in the login.jsp to their unique table structure. Lo and behold the install script compiled and the IDP is now operational. So - I can't tell you exactly if it was the style sheet order or if it was an issue with overtly custom table references for the login fields. (while still using required elements).  Either way it as Chad stated below I believe; tomcat did not like what was loading into memory prior to completion and seemed to reject the entire element.

Thanks to all those who responded.

--------------------------------------------------------
Date: Mon, 19 Mar 2012 17:57:34 -0400
Chad La Joie <laj...@itumi.biz>
Subject: Re: changes in login pages - kills IDP?
To: Shib Users <us...@shibboleth.net>
Message-ID:
	<CACTY7uBFUtDGS1ikYZ_==XXPWALxfB6_L5yPjxJP=FfeQ...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

The behavior your describing is uncommon for JSP changes.  Those are
compiled at runtime when a request comes in and if the compilation
fails Tomcat spits out some gross stacktrace.

So I'd do what Paul just suggested and then log in to the Tomcat
manager and see what it says the status of the IdP app and what
context path it claims to be mounted under.  I'm wondering if the
web.xml file is corrupted in some way.  Did you add anything to it
(e.g., servlet filters or taglibs) when doing the JSP updates?  If
taglibs, perhaps a TLDs is corrupted to.  Whatever it is, it's
something Tomcat is checking *before* it starts up anything to do with
the IdP itself.

On Mon, Mar 19, 2012 at 17:35, Oleg Chaikovsky
<oleg.ch...@aegisusa.net> wrote:

Yeah - I pretty much felt this was the issue but the catalina.out log
file did not offer succinct clues to me (well, at least that pointed me
in the right direction). the threads errors were well known in this list
that its something that can be ignored. it also showed the deployment
descriptor for idp.xml which made me wonder why that showed up.

I realize this is the shib list, and not the tomcat list. If you can
point me to a possible avenue
of solution I will go there otherwise I will check Tomcat lists


-- 
Oleg Chaikovsky
AegisUSA - The Identity Company
Reply all
Reply to author
Forward
0 new messages