DiscoFeed timeout · troubleshooting

It looks like that works! Still don't have federated on but based on what I'm getting with the test account I'm very certain that this setting is correct.
Which leads to Shibboleth Problem #2. No t sure why but suddely Shibboleth with the federeated login started to run so slow that the library systems group rolled back to the pre-federated settings. It basically ground to a hald. The time-out error was:
Failed to download metadata from /Shibboleth.sso/DiscoFeed.

According to Stephen Guernick (he's on slack), the hangup was loading in all the metadata for federated log-in. His guess wasthat the startup process was encountering a time-out-limit and that the start-up kept trying and failing. The new metatdata file was being downloaded on each restart.

So I went digging in the shibboleth settings. Could this be the problem?
<Sessions lifetime="7200" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="true"
idpHistory="false" idpHistoryDays="7" cookieProps="https">

Notification Bot (Sep 29 2023 at 16:44):

A message was moved here from #troubleshooting > federated login and shibboleth group by Philip Durbin.

Philip Durbin 🚀 (Sep 29 2023 at 16:45):

I'm really not sure. Did increasing the timeout help? Harvard and UNC both use the full feed and I don't remember hearing about any problems.

jamie jamison (Sep 29 2023 at 16:58):

I'll have to find out what the full feed is. And get back with what happens.

Philip Durbin 🚀 (Sep 29 2023 at 17:44):

Sorry, full feed is probably confusing. I mean that UNC and Harvard let anyone from the InCommon feed log in. Hundreds of schools and other orgs.

Philip Durbin 🚀 (Sep 29 2023 at 17:44):

Most Dataverse installations only let their institution log in via Shibboleth.

jamie jamison (Sep 29 2023 at 17:57):

No need to apologize. I'm still learning all this.

Philip Durbin 🚀 (Sep 29 2023 at 18:00):

Don is on vacation or I'd ping him to see if he's seen timeouts.

Don Sizemore (Oct 02 2023 at 19:26):

jamie jamison said:

It looks like that works! Still don't have federated on but based on what I'm getting with the test account I'm very certain that this setting is correct.
Which leads to Shibboleth Problem #2. No t sure why but suddely Shibboleth with the federeated login started to run so slow that the library systems group rolled back to the pre-federated settings. It basically ground to a hald. The time-out error was:
Failed to download metadata from /Shibboleth.sso/DiscoFeed.

According to Stephen Guernick (he's on slack), the hangup was loading in all the metadata for federated log-in. His guess wasthat the startup process was encountering a time-out-limit and that the start-up kept trying and failing. The new metatdata file was being downloaded on each restart.

So I went digging in the shibboleth settings. Could this be the problem?
<Sessions lifetime="7200" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="true"
idpHistory="false" idpHistoryDays="7" cookieProps="https">

I've had trouble with Shibboleth exceeding the systemd default timeout on launch (then systemd restarts it, then it takes too long, then systemd restarts it...). You can set the shibd.service file to use TimeoutStartSec=7m (or maybe longer) and Shibboleth launches for me. I hope this helps?

jamie jamison (Oct 09 2023 at 17:40):

From the UCLA systems person helping me (Stephen Guernick, not on zulip yet): he tried setting it to 10 minutes and shibboleth still timed-out. Not sure at this time why the problem started.