changes to apply after upgrade (include system dir?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

changes to apply after upgrade (include system dir?)

Peter Schober
I thought files in /opt/shibboleth-idp/system/ are supposed to get
overwritten with newer versions when installing a new IDP version over
an older one?

I just noticed that 3.3.3 has this in ${idp.home}/system/conf/mvc-beans.xml:
  <import resource="conditional:${idp.home}/conf/mvc-beans.xml" />
but after upgrading my 3.3.2 to 3.3.3 my copy of that file still reads:
  <import resource="../../conf/mvc-beans.xml" />

Why does this matter: When one applies the changes to the config
directory from 3.3.2 to 3.3.3 the file ${idp.home}/conf/mvc-beans.xml
would get removed, but unless ${idp.home}/system/conf/mvc-beans.xml
would get changed accordingly this breaks the update.

What's the suggested process here? Not applying any updates to the
config directory at all? How would I know in advance that a change to
a file in config/ breaks the IDP unless another change to
system/config is also being made?

Apply changes to the system directory, too, on each upgrade (y'know,
the one with the file DONOTTOUCH in it)?

-peter
--
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: changes to apply after upgrade (include system dir?)

Rod Widdowson
Notwithstanding your question:

> Why does this matter: When one applies the changes to the config
> directory from 3.3.2 to 3.3.3 the file ${idp.home}/conf/mvc-beans.xml
> would get removed,

Unless I'm mis-remembering, we *shouldn't* be removing or changing any files in conf.  That’s part of the contract.  We add files,
but never remove them.  IIRC the install consists of copying file to dist and then copying into conf any file not already present.

/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]
Reply | Threaded
Open this post in threaded view
|

Re: changes to apply after upgrade (include system dir?)

Peter Schober
* Rod Widdowson <[hidden email]> [2018-05-18 15:27]:

> Notwithstanding your question:
>
> > Why does this matter: When one applies the changes to the config
> > directory from 3.3.2 to 3.3.3 the file ${idp.home}/conf/mvc-beans.xml
> > would get removed,
>
> Unless I'm mis-remembering, we *shouldn't* be removing or changing
> any files in conf.  That’s part of the contract.  We add files, but
> never remove them.  IIRC the install consists of copying file to
> dist and then copying into conf any file not already present.

I've probably not expressed that properly: What I did was applying the
diff in git between 3.3.2 to 3.3.3 to my config directory, so to speak
(not autoamtically, but manually).  conf/mvc-beans.xml is no longer
there in 3.3.3 so I removed it from the upgraded machine, too.
Doing that breaks the IDP unless a corresponding change to
system/conf/mvc-beans.xml is being made.

So it's not the upgrade process that breaks anything, it's me trying
to keep the diff to current IDP release as small as possible.

In this case the error was both expected (a comment in mvc-beans.xml
even mentioned it being included from system) and immediately obvious
since the IDP failed to restart with a clear message (that the
included file wasn't found).

So I'm fully prepared for "You can't do that!" as a reply.

Just trying to tease out what changes to config/ between releases I
can apply, and whether I'd have to apply changes to system/config/
too, then, if I do that.

-peter
--
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: changes to apply after upgrade (include system dir?)

Cantor, Scott E.
In reply to this post by Peter Schober
> I thought files in /opt/shibboleth-idp/system/ are supposed to get overwritten
> with newer versions when installing a new IDP version over an older one?

Yes.

> I just noticed that 3.3.3 has this in ${idp.home}/system/conf/mvc-beans.xml:
>   <import resource="conditional:${idp.home}/conf/mvc-beans.xml" /> but after
> upgrading my 3.3.2 to 3.3.3 my copy of that file still reads:
>   <import resource="../../conf/mvc-beans.xml" />

The conditional: change should not, AFAIK, be in 3.3.3, that wouldn't work. It is not in the branch in git. If it's in the package, that would be a corruption of the release (and yes, it should have copied that file over top, and would have broken it).

> Why does this matter: When one applies the changes to the config directory
> from 3.3.2 to 3.3.3 the file ${idp.home}/conf/mvc-beans.xml would get
> removed, but unless ${idp.home}/system/conf/mvc-beans.xml
> would get changed accordingly this breaks the update.

No, the update process would not remove the one in conf. It doesn't have the ability or intelligence to remove files like that, it's not RPM.

Something is seriously off. But nobody else has reported a problem, and if that file got changed in the branch it would break.

-- Scott

--
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: changes to apply after upgrade (include system dir?)

Cantor, Scott E.
In reply to this post by Peter Schober
> I've probably not expressed that properly: What I did was applying the diff in
> git between 3.3.2 to 3.3.3 to my config directory, so to speak (not
> autoamtically, but manually).  conf/mvc-beans.xml is no longer there in 3.3.3
> so I removed it from the upgraded machine, too.

It *is* in the branch in 3.3, so again, that would be a corrupt package. We need to see what's actually been released and do a 3.3.4 if needed.

> So I'm fully prepared for "You can't do that!" as a reply.

That is in fact true, the update process is only safe if it runs as it is, and any other diffs are going to be situational as to how safe they are because it would depend on local changes and what else has been done. But there's still something off if anything like this got into the branch.

-- Scott

--
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: changes to apply after upgrade (include system dir?)

Tom Zeller-3
In reply to this post by Cantor, Scott E.
> Something is seriously off. But nobody else has reported a problem, and if that file got changed in the branch it would break.

FWIW The only changes between IdP 3.3.3 and 3.3.2 were JARs in webapp/WEB-INF/lib.

Tom
--
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: changes to apply after upgrade (include system dir?)

Cantor, Scott E.
> FWIW The only changes between IdP 3.3.3 and 3.3.2 were JARs in
> webapp/WEB-INF/lib.

Yes, I don't see any sign that what's in the zip or tarball have the change being discussed. Peter, I think your tree was mixed up with other content from the master branch somehow.

-- Scott

--
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: changes to apply after upgrade (include system dir?)

Peter Schober
* Cantor, Scott <[hidden email]> [2018-05-18 15:52]:
> Yes, I don't see any sign that what's in the zip or tarball have the
> change being discussed. Peter, I think your tree was mixed up with
> other content from the master branch somehow.

Yes, it was me being sloppy (the diff was to master).
Sorry for causing a wild goose chase.

But the larger question still stands, even if there's no simple answer
and certainly none that involves automatisms:

What's the process by which deployers can stay up-to-date not only
with the software but also wrt new features, changed default
behaviour, etc.?
Would the outlied process (diffing REL-1 with REL) generally work had
I being in the righ branch for that?

-peter
--
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: changes to apply after upgrade (include system dir?)

Cantor, Scott E.
> What's the process by which deployers can stay up-to-date not only with the
> software but also wrt new features, changed default behaviour, etc.?
> Would the outlied process (diffing REL-1 with REL) generally work had I being in
> the righ branch for that?

Generally, but what we're doing with Spring is, simply put, not something anybody else in the world is even attempting and I don't think that I could say with total confidence that you could always safely apply every diff to conf/ mechanically. Removing files that have disappeared probably isn't going to hurt if they haven't been modified.

But the user modifiable files are only under so much control so I don't think we could be sure that any given change wouldn't conflict with a local change somebody made. I'm sure I could come up with an example if I tried.

-- Scott

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