Shibboleth Developers

["Scott Cantor" <>]

> You lost me...what "root" are you referring to?

The root of the result of the installation process, by default
/usr/local/shibboleth-idp

Everything that's not "in the war" is potentially relative to that. At a
minimum, that's how you find the jars so stuff in bin/ will run. That's
where logs are kept, and where the production copies of metadata, idp.xml,
etc. will generally be maintained. Not that you have to, that's just what we
do by default now.

> - The install script includes the GridShib plugin, the metadata file,
> and the gridmap files into the build, which is deployed to tomcat. 
> Some (unspecified) manual setup to the IdP config may be required.

Right.

> - Simultaneously, as part of the install, the metadata file and the
> gridmap files are copied into $IDP_HOME$ (which we assume is suitably
> protected).  Any needed tools are copied into $IDP_HOME$ as well.

Ok, so IDP_HOME is what I meant by SHIB_HOME and "the root".

> - Later, as part of an ongoing maintenance process, the metadata file
> and/or the gridmap files in $IDP_HOME$ are modified.

Sure.

> This is where I'm stuck.  How do the modified files in $IDP_HOME$ get
> into the tomcat webapp directory?  I was thinking there would be a
> tool that copied the files from $IDP_HOME$ to the webapp directory,
> but from your comments, it sounds like you have a different idea.

No, nothing ever gets copied *from* IDP_HOME. Those are the authority
copies. Referencing things inside the war is the old way of doing things
that nobody would use in production, it's too confusing. That's why we
created this new IDP_HOME tree.

You can certainly have staging copies if your tools want to do checking of
changes before deploying into production, but generally that's what dev/QA
servers are for. Once I move something to prod, I've already checked it.

-- Scott