Upgrading to 3.4.8 -- Not Recognizing Earlier Version

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

Upgrading to 3.4.8 -- Not Recognizing Earlier Version

Cath Messner
I'm updating our IDP from a 3.4.6 version to 3.4.8. for the journey onto 4.0.1.

When './install.sh' on the 3.4.8 -- the following is triggered. If i remember correctly,  the installation validates from a file if a pre-existing version has been installed. We have shuffled some files around -- could anyone remind me which path/file it validates if a previous version is installed?


"[shib@idp bin]$ ./install.sh
Source (Distribution) Directory (press <enter> to accept default): [/home/shib/shibboleth-identity-provider-3.4.8]

Installation Directory: [/opt/shibboleth-idp]

Hostname: [server1.example.com]

Backchannel PKCS12 Password:
Password cannot be zero length"


The 'idp_ant.log' output:

target: init
target: getsource
target: target-properties
target: target-nosrc-default
target: prompttarget
target: v2detect
target: checkproperties
target: gethostname

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Upgrading to 3.4.8 -- Not Recognizing Earlier Version

Rod Widdowson
> -- could anyone remind me which path/file it validates if a previous version is installed?

In V3 this is sort of scrutable if you care to try and work out how ant works by reading bin/build.xml.  In V4 the rules are the same but you have to read the source code which isn't distributed.  

Anyway, certificate generation is (mostly) controlled by whether conf/relyingparty.xml is present.

Other files that are check for include (but are not limited to)

        metadata/idp-metadata.xml
        conf/idp.properties
        credentials/sealer.kver

and for automated installs and V2 updates
        conf/saml-nameid.properties
        conf/ldap.properties
        conf/services.properties
 

It would be useful if you would report back what exactly the issue was and also why you are doing it.  In general you are in for a world of pain if you break some of these assumptions and this is only going to get worse when 4.1 hits the streets when the configuration gets simpler, but managing the configuration tools becomes (for us, the developers)  an order of magnitude more complex.

Rod

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]