Versions Compared

Old Version 2

changes.mady.by.user Rod Widdowson

Saved on

compared with

New Version 3

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Installs an unpacked jetty-home alongside the idp.

  • Install & configures Procrun (an apache projects to allow you to run java programs as daemons).

    • They keep threatendng to end of life it and assure people that there are much nice solutions (my particular favorite recommendation is the one that allows you to inject arbitrary shell scrips to be run at system startup because that's really safe and secure). Frankly if it is ever end of lifed it would be quicker to write the 200 lines of C to do it ourselves.

    • The only interesting thing here is that it does require that jetty not fork.

  • Installs a jetty-base inside the idp (as a peer to conf &c)

The Jetty base that is used in the installer comes from the same repo is built from an entirely different branch (“10-windows”) from the “11” branch (noting that the windows branch and the substantive changes has been shown to work on jetty11 and jetty 10).

The substantive changes between the “11” branch and the “windows” branch are

  • idp-backchannel.xml: The default credentials location is different. I cannot remember why but there is reason

  • Some minor difference in idp.xml which I could collect

  • And 6 files

...

This is a changed version of the one distributed one with jetty and its maintenance represents the biggest ongoing cost.
https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/2937454597/JettyBase10ForWindows#etc/jetty-ssl-context.xml describes what needs to be done. As I recall it isall is all because at one stage (probably even now) Jetty got confused about

  • Absolute vs relative paths (which really matters on windows)

  • How to do defaulting of values. I think that there are 3 ways to do defaults now

idp.ini.windows

The installer turns this into idp.ini on a fresh install. It is modified to contain any collected passwords

...

Contains the “don't tinker with these) these” settings from the mainline idp.ini

idp.ini.rewrite.property.names

This deals with the issue when jetty rename properties (or indeed if one of our xml files changes a property name). The name changes this file it contains are made to an existing idp.ini

idp-backchannel.ini, idp.ini (not windows)

These are subsumed into idp.ini.windows and idp-system.ini

Installing Jetty base

Install the jetty base is made complicated since

  • The Jetty project change changes property names and we may need to rewrite the user’s idp.ini. This is historic

  • We need to merge in things like passwords

  • We create a keystore for the https port with a self signed cert in it.

  • Its all done with ant (which feels old)

  • But basically it works‘just works’ .

Other shit

I cannot remember why but for historic reasons we install into the 32 bit folder. Of course this is java so we are actually keyed into what JM is installed.

...

Cranking a windows release is pretty quick (Download the IdP, Jetty, Jetty base and procrun and run two bat files). I have a note that it might be nice to bundle that into a maven plugin so it can be done by anyone with a windows machine. And critically we can use our enforced Critically this would allow us to use the enforcer to do the signature checks on Jetty and procrun

The costs are the ancillary ones:

And we have this costs every time that the IdP ships and every time that jetty ships. Subjectively, it is the jetty changes that are the biggest pain because they are no made on our timeline.

So what are the options?

  • Walk away from shipping jetty on any platform

    • I am so bored with Jetty and this installer that this appeals to me. I’ll support the real installer for ever but….

  • Bludgeon what we have now into working with V5.

    • The path of least resistance but it does mean that we need to carry on shipping windows specific files (jettty-ant.xml) in the idp. I could even fix that at the same time.

  • Bludgeon what we have into two packages. One for the IdP and one for jetty

    • More work to get there, and we still have the same costs with every jetty release.

  • Try to bring the jetty bases base's together.

    • I have no idea what the problems would be and the wounds from last time still hurt, but I have a gut felling feeling that the real problem is that on Windows we cannot allow jetty to fork (I don’t even know whether that works in windows or if that is a procrun issueis because of Windows or because of procrun)

If we were starting with a clean slate

...

…. And we haven’t even talked about jetty12. If this really works it does change the game. Or at least the questions.