[JIRA] (IDP-2133) seckeygen.sh not updated on upgrade to v5
Rod Widdowson (Jira)
jira at shibboleth.atlassian.net
Thu Jun 22 16:36:41 UTC 2023
Rod Widdowson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=59fb32bbc24efb3c4ed3c977 ) *commented* on IDP-2133 ( https://shibboleth.atlassian.net/browse/IDP-2133?atlOrigin=eyJpIjoiMzQ2YTg5MjJlNWM5NDhhMmFhZTQ4ZGI2NzVjNTM1NDkiLCJwIjoiaiJ9 )
Re: seckeygen.sh not updated on upgrade to v5 ( https://shibboleth.atlassian.net/browse/IDP-2133?atlOrigin=eyJpIjoiMzQ2YTg5MjJlNWM5NDhhMmFhZTQ4ZGI2NzVjNTM1NDkiLCJwIjoiaiJ9 )
I think that the fundamental issue is that we don’t have a way to add files to a module when it gets changed and this is going to bite us forever. For modules which come with plugins it may be a bit less of an issue because we tend to rename the module (correct?).
Is it too much to have a module.required property which can be used for current state detection? Or is that just optional by another name
Anyway what happens in the installer right now is that
* If this is a new install then idp.core is enabled
* Stuff happens which need the core module - and specifically idp.properties
* If this is an existing install then only those modules detected as enabled when we started are re-enabled.
* If this is a new install then idp.EditWebApp, idp.CommandLine, idp.authn.Password, idp.admin.Hello are all enabled
* But notably there isn’t a “If this is an update then this module must be installed” list. This is Scotts suggestion.
It feels like the installer is the place to have the list of modules to force enable on update (i.e. stage 5), not the module itself. We could add this and populate it with idp.core, idp.EditWebApp, idp.CommandLine. But we are still going to die badly if another module (idp.authn.password, say) gets a new file, so maybe that's not such a good idea.
There is yet another idea (which scares me and I therefore detest, but we do this already for the plugins) is to get the *old* install to detect whether a module is enabled. We currently only run the installer with a classpath taken from the distro (so its the distro’s idea of what a module is that counts) but it would be possible to reach out into the existing install and map those jars into a separate ClasspathLoader and use that to ask about the modules, then we would use the old version to establish whether it was enabled. At that stage we have the “old enabled modules” and we can add the “new modules” if they are not in the module list (either disabled or enabled).
[I have no idea what this would mean for a module that changed when a plugin got updated (I have a feeling that the classpath there is also weird but I shudder at the idea of separating those ones out)]
Anyway that approach this would fix the V4->V5 issue (because IdP.CommandLine would not be found using the old classpath from the V4 install) but it would not fix the problem that Ian has (although his problem would also be fixable by hand enabling the IdP.CommandLine module.
Ian Young ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ae127cb03-43ed-473d-b6ba-592949cb4be8 ) I think that there are enough open questions here that it would be good if you can avoid doing another update until we know what we are going to do.
A final thought: we could help the diagnosis of this by changing the logging level in the module code so that if one file was found but another wasn’t this was a WARN and not a DEBUG.
Ugh! I’ll sleep on it and see what tomorrow brings. Right now I’m thinking that Scott’s “force it in the installer” combined with a change in logging is the way to go.
( https://shibboleth.atlassian.net/browse/IDP-2133#add-comment?atlOrigin=eyJpIjoiMzQ2YTg5MjJlNWM5NDhhMmFhZTQ4ZGI2NzVjNTM1NDkiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/IDP-2133#add-comment?atlOrigin=eyJpIjoiMzQ2YTg5MjJlNWM5NDhhMmFhZTQ4ZGI2NzVjNTM1NDkiLCJwIjoiaiJ9 )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100227- sha1:6a5b8c4 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20230622/417d0899/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-2834ba2f-93fd-409e-bf54-5878eb112828
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230622/417d0899/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-b3d73530-8bce-416f-b514-2012f6436f3f
Type: image/png
Size: 345 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230622/417d0899/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-6f6bdcc4-4d60-4ca0-b3eb-dc4872ea692c
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230622/417d0899/attachment-0005.png>
More information about the commits
mailing list