IdP V4 Installer

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

IdP V4 Installer

Rod Widdowson
This mail is targeted at those of you who have embedded or otherwise extended the V3 installer.  

For V4 we are in the process of rewriting the installer with three aims:

   - To maintain backwards compatibility at both the "programmatic" and the "user experience" levels.
   - To make your injection of user input (installation directories passwords and so forth) easier.
   - To make it significantly easier for us to introduce new customizations to the installation in patch releases.

As far as you are concerned the key point is the formalization of the APIs used to interact with the installation and the fact that
these are set in Java, not (necessarily) as properties set in a JVM.

I have tried to capture this here [1].    You input would be appreciated and you might want to start making plans on how to best
leverage these new capabilities.

As always there is an element of time pressure.  I hope to be code frozen by the end of this month, but I'm expecting to be able to
accept suggestions for extensions up to the start of December...

Thanks

        Rod

[1] https://wiki.shibboleth.net/confluence/display/DEV/V4+Windows+Installer+-+Developer+Notes

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP V4 Installer

Etienne Dysli Metref
On 17/10/2019 14.46, Rod Widdowson wrote:
> As always there is an element of time pressure.  I hope to be code
> frozen by the end of this month, but I'm expecting to be able to
> accept suggestions for extensions up to the start of December...
A bit late, but I took the v4 installer for a ride. I don't plan on
programmatically embedding it, but only providing properties as input to
skip all prompts.

With a simple run (`./bin/install.sh`), here's what I can say.

# Positive things #

- All familiar directories are there so I assume an IdP has been
completely installed. Job's done! :)


# Confusing things #

- Prompts don't look like prompts.
  There is (still) no question mark in prompts where human input is
expected. This was already confusing in the v3 installer. Please add a
question mark to prompts.

- Passwords end up in idp.properties (and in the output).
  > Creating /home/user/Downloads/test_idp4/conf/idp.properties from
/home/user/Downloads/test_idp4/dist/conf/idp.properties and
{idp.entityID=https://mymachine.switch.ch/idp/shibboleth,
idp.sealer.keyPassword=mypassword, idp.sealer.storePassword=mypassword,
idp.scope=switch.ch}
  This one is more dangerous than confusing. Can we avoid mixing secret
bits and configuration by putting all passwords in a separate properties
file?

- "Version null"??
  > Rebuilding /home/user/Downloads/test_idp4/war/idp.war, Version null
  Probably harmless, but still raises an eyebrow.


# Unnecessary things #

- Backup directories created on fresh install.
  The installer noticed it's a clean install, but still went ahead and
created a backup (of nothing):
  > No relying-party.xml file detetected. Inferring a clean install
  > Created directory /home/user/Downloads/test_idp4/old-2019-12-19-11-23-15
  This is a fresh install so I don't need any backups. Having it lying
around uselessly pollutes the IdP's "space" and with such a name
"old-<date>" it is unlikely to be deleted by a human ("oh that must be
important"), so please skip backups on clean installs.

- Windows batch files installed even on Linux.
  I don't need `bin/*.bat`, they shouldn't be installed on non-Windows
systems. The same goes in the other direction, Windows users probably
don't need `bin/*.sh`.

The installer's output (redacted) is also attached.

  Etienne

--
To unsubscribe from this list send an email to [hidden email]

installer_log.txt (15K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IdP V4 Installer

Rod Widdowson
Thanks a lot.  That is *really* appreciated.

I've appended the comments to the relevant case (IDP-1499) and I'll get onto the low hanging fruit.

I should also add that I intend turning the logging down to WARN (from DEBUG) in the first non beta release.

(I may also write up how to adjust that)

Thanks again
        Rod



--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP V4 Installer

Cantor, Scott E.
In reply to this post by Etienne Dysli Metref
On 12/19/19, 6:22 AM, "dev on behalf of Etienne Dysli Metref" <[hidden email] on behalf of [hidden email]> wrote:

> Passwords end up in idp.properties (and in the output).

Which output?

>  This one is more dangerous than confusing. Can we avoid mixing secret
> bits and configuration by putting all passwords in a separate properties
> file?

Not for upgrades obviously, but I think we should fix the defaults. I'm not sure how that impacts the installer though.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IdP V4 Installer

Etienne Dysli Metref
On 19/12/2019 14.06, Cantor, Scott wrote:
>> Passwords end up in idp.properties (and in the output).
>
> Which output?

In the installer's log which ends up in the console. More precisely this
line:

> DEBUG [net.shibboleth.idp.installer.V4Install:234] - Creating /home/user/Downloads/test_idp4/conf/idp.properties from /home/user/Downloads/test_idp4/dist/conf/idp.properties and {idp.entityID=https://mymachine.switch.ch/idp/shibboleth, idp.sealer.keyPassword=mypassword, idp.sealer.storePassword=mypassword, idp.scope=switch.ch}


>> This one is more dangerous than confusing. Can we avoid mixing secret
>> bits and configuration by putting all passwords in a separate properties
>> file?
>
> Not for upgrades obviously, but I think we should fix the defaults.
> I'm not sure how that impacts the installer though.
We currently separate secrets for v3 by storing them into
`conf/credentials.properties` which is included from
`conf/idp.properties`. We have a wrapper script for the installer [1]
that generates this file and executes the installer with
`-Didp.sealer.password=$(cut -d " " -f3 <credentials.properties)` among
other flags.

[1] https://www.switch.ch/aai/guides/idp/installation/idp-install.sh


--
To unsubscribe from this list send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IdP V4 Installer

Rod Widdowson
> In the installer's log which ends up in the console. More precisely this
> line:
>
> > DEBUG [net.shibboleth.idp.installer.V4Install:234] - Creating /home/user/Downloads/test_idp4/conf/idp.properties from
> /home/user/Downloads/test_idp4/dist/conf/idp.properties and {idp.entityID=https://mymachine.switch.ch/idp/shibboleth,
> idp.sealer.keyPassword=mypassword, idp.sealer.storePassword=mypassword, idp.scope=switch.ch}

The canonical solution is that we only emit passwords at TRACE and hide them at DEBUG.  I'll make a note in the relevant case.

Thanks

        Rod

--
To unsubscribe from this list send an email to [hidden email]