upgrade from 2.4.3 to 2.5.1

[Russell Beall]

Thanks Scott,

This makes it very clear where the issues are -- all because of assumptions in our config generator.

Regards,
Russ.

On Mar 29, 2013, at 11:02 AM, "Cantor, Scott" <cantor.2 at osu.edu>
 wrote:

> On 3/29/13 1:50 PM, "Russell Beall" <beall at usc.edu> wrote:
> 
>> The downloaded metadata file remained owned by root.
>> The /etc/shibboleth directory remained owned by root also, (and that is
>> where the metadata files are configured to be written).
> 
> If you mean the backup files are written there, that's absolutely
> inappropriate for the usual reasons. That's meant to be a read only file
> system for the software, and it is meant to be owned by root.
> 
>> I believe this is partly (or fully) answered by the release notes for
>> 2.5.0.  Looks like the metadata should be downloaded to
>> /var/cache/shibboleth?
> 
> It used to be written to /var/run/shibboleth and now it's /var/cache, but
> neither should be mentioned anywhere or even noticed.
> 
>> The socket listener file was set to /var/run/shibd.sock, but looks like
>> it should have been set to /var/run/shibboleth/shibd.sock (or omitted and
>> allowed to use the default).  This was just the convention used by
>> longstanding use in our configuration generator.  This should probably
>> just be left to the default, right?
> 
> You should have no absolute paths anywhere. If you do, I cannot do
> anything about upgrades breaking, and they will break in the future. Using
> absolutes basically means "I'm owning this and will ensure that things
> keep working across upgrades". You should probably turn off automated
> package management for the packages in such a case.
> 
>> I also saw a note that made it seem like the use of the shibboleth logo
>> was not appropriate.  I always assumed that this would be fine to show on
>> the info pages displayed by shib, and many of our sites will display that
>> when there is an error or access issue.  Is this considered a copyright
>> problem?
> 
> Not in our case, but it is a project problem. The logo only appears
> because something went wrong, 99% of the time because something unrelated
> to Shibboleth went wrong. It leads users to go searching us out to
> complain or expect us to fix their access problems.
> 
> The logo is no longer in the SP software and won't be in the IdP shortly.
> That is, BTW, another point about upgrades. Pointing pages to content
> sitting in /usr/share is not guaranteed to work across upgrades either,
> and any cases of that are samples.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>