...
doc\shibboleth:main.cssand the same license related files as the Shibboleth merge moduleetc\shibboleth:upgrade.xsl, example-metadata.xml, examples-shibboleth2.xml. These are uninstallable because that’s what the old one did. Also ,keygen.batandxsltproc.js(uninstallable. These are un-installable but will be updated (if the file versioning rules allow)etc\shibboleth\dist: A whole bunch of files (some uninstallable some not)files These are all un-installable and will be updated. See below for how these files are then handled.var\log,var\runare both created.
5. Installing and editing configuration
- Editing the config files.
- The same process as currently (note that some of the editing will be moved to the merge modules in order to get the catalogs located correctly)
- This work process will always be done (be run on installs and on upgrades, but the edit code is sensitive to not overwriting these files). Thus files can be via this mechanism on upgrades.
- The files create are never unstalled (should they be?)un-installed.
- Editing IIS. This will be roughly the same as currently but
- Architecture sensitibe DLLs for the x64 version
- The install will only be called if we know this is a from fresh install
- The uninstall will only be called if we know this is a not an upgrade
- Edit the Service (x64 only)
- The service is declared (because it has to be done there) with the 32 bit install of shibd.
- IFF we are doing the first install and the user has specified x64, then the path to shibd is changed to point at the x64 prior to the service being started.
- Environment Variables
- Add the lib direcrtory(s) that the merge modules installed into into the path
- Add (currently via javascript) SHIBSP_PREFIX to point to the shib install dir
...