IdP 3.4.3 for Windows - upgrade observations

[Doan, Tommy]

Thanks Rod. By the way, I should have mentioned for what it's worth that we had never edited the start.ini or backchannel.mod files.  

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Rod Widdowson
Sent: Thursday, February 14, 2019 4:12 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject: RE: IdP 3.4.3 for Windows - upgrade observations

Thanks for this. 

Some observations (which I'm sure you know, but I need to include for the mail-thread record).

Firstly, remember [1] that 

> The only configuration of Jetty which is available to you is in the file 
> %IDP_HOME%\jetty-base\start.d\idp.ini, and you should not edit any other file in the 
> jetty-base directory, let alone files in the Jetty installation directory, because you will 
> lose these changes when you perform upgrades.


One thing to not is that if you do edit anything in there then the windows installer will not remove or update it so:

> * JETTY_BASE\etc\jetty.xml was removed as part of the upgrade. Our only customization there is to add a ForwardedRequestCustomizer
> from our load balancer, so not a big deal to recreate.

Are explained.

> * JETTY_BASE\start.ini from IdP 3.3 includes module=logging, and attempting to load that module prevents startup of IdP 3.4.3
after an
> upgrade. We noticed that a default installation of 3.4.3 does not include start.ini, so we just removed it manually.> *
JETTY_BASE\modules\backchannel.mod was included in IdP 3.3 but not included in a default installation of 3.4.3, but the file is not
> removed when upgrading from 3.3 to 3.4.3. ProcRun logs an error about it, and since we don't even use a back channel we just
removed it
> manually.

If you edited these files at some stage, that would also be explained.

> * The dist version of conf\c14n\subject-c14n.xml does not comment out <ref bean="c14n/LegacyPrincipalConnector" /> even though
there
> is a deprecation warning about it in the IdP logs.

We cannot do that until V4 we still officially support V2 relying party configurations.  Believe it or not, people are still moving
from V2 to V3, which is a precursor to moving off legacy relying-party.xml.  You (of course) can and should remove it from your
configuration.  Once removed, it will stay removed..

> * Also, previously we didn't have to stop the IdP prior to rebuilding the WAR file - we would simply restart it after a rebuild.
However,
> stopping first appears to be a requirement now as the build fails because otherwise ANT cannot delete idp.war. We don't rebuild
our WAR
> file very often at all so this may not be new as of 3.4.3.

I'll leave it to others more versed in Containers to comment on this, but I have many (admittedly Tomcat-shaped) scars around that
so I would view that as a feature, not a bug.

To summarise what you are doing is not supported, I totally get why you are doing it, but my suggestion for you would be to take
complete ownership of the Jetty Install.  Feel free to make use of the installer hints and things you may observe in our jetty-base
repository [2], but if you own the jetty install then you'll never get hit by these items again...

One important thing I should share for when you take ownership is that it is essential that a Jetty started from Procmon not fork.
The world becomes very strange very quickly if it does that.  If pushed I could dig out a reference of exactly why.

[1] https://wiki.shibboleth.net/confluence/display/IDP30/WindowsInstallation#WindowsInstallation-JettyConfiguration
[2] http://git.shibboleth.net/view/?p=java-idp-jetty-base.git;a=summary

Rod

-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net