Pages from Dashboard Timing Out

Update I checked our dnf history and it doesn’t look like anything really installed. I would welcome further suggestions. Thanks again!

To further clarify it seem like any of the edit functions times out in the same way.

I attempted to do an upgrade install but the same thing is happening.

Specifically I can not navigate to

https://ojsserv1.towson.edu/index.php/tapestry/management/settings/context

or

https://journals.towson.edu/index.php/index/admin/index

Hi @egadsby,

Is your server behind a proxy that prevents OJS from reaching out to the outside world? If so, make sure the proxy is configured in the [proxy] section of config.inc.php.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher Thank you I will try that. Our OJS sits behind a F5 device. I will need to figure out what values to configure. Follow up, we have made no changes to software why would it get picky about the proxy now? Thanks for all your kind help!

Hi @egadsby,

I don’t think OJS’s requirements have changed recently in that regard; the administration area needs to check in with the PKP webserver in order to see if there’s a new version of OJS available, and to fetch the list of plugins for presentation in the Plugin Gallery. I think those requests are currently failing for lack of a workable proxy configuration.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

@asmecher Thanks for your help so far. We are working with our firewall team and they have asked me to provide the domains/URL OJS is trying to contact. What might they be? Thanks!

Hi @egadsby,

OJS fetches the contents of the plugin gallery from http://pkp.sfu.ca/ojs/xml/plugins.xml; it gets the most recent available version of OJS from https://pkp.sfu.ca/ojs/xml/ojs-version.xml.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher thanks for that!

To clarify defining the proxy and permitting these URL will clear up the time outs we are seeing on both:
-“Journal” (for any journal)
-“Administration”

Thanks again!!!

Hi @egadsby,

I’m diagnosing the problem remotely, so no guarantees, but I think it’s very likely.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher thanks for your continued help.

Somebody from our firewall team asked me to put this into the config file:

http_proxy=http://serverproxy.towson.edu

They said no user name or password was required.

I placed this into the config file and restarted Apache:

http_proxy = “http://serverproxy.towson.edu:80

This did not work, is my syntax wrong here? Thanks!

Hi @egadsby,

You will need to configure both a http_proxy and an https_proxy in your configuration file.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher that is very helpful, thanks!

Our firewall teams says we need no username or password will OJS just passover this and use the URL only?

Ok I got it further but now we have a new error. It now goes to a while screen (behind the firewall) and a firewall error (outside the firewall) almost instantly. Now we get this on the log:

"[12-Jan-2023 17:15:17 UTC] PHP Fatal error: Uncaught GuzzleHttp\Exception\ConnectException: cURL error 35: error:1408F10B:SSL routines:ssl3_get_record:wrong version number (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:200

Stack trace:

#0 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(155): GuzzleHttp\Handler\CurlFactory::createRejection()

#1 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(105): GuzzleHttp\Handler\CurlFactory::finishError()

#2 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish()

#3 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(28): GuzzleHttp\Handler\CurlHandler->__invoke()

#4 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(51): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler{closure}()

#5 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddlewar in /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 200"

Thanks!

Hi @egadsby,

I think this is a configuration error; see e.g.:

https://stackoverflow.com/questions/50840101/curl-35-error1408f10bssl-routinesssl3-get-recordwrong-version-number

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher

Hi. I am trying to parse this article. Does the mean we need to change something on the server or on the firewall? In the past we have problems with the F5’s implementation of HTTPS… See OJS stylesheets and scripts not loading… OJS seems to be looking for HTTP instead of HTTPS

Hi @egadsby,

OJS passes the http_proxy and https_proxy configuration options into the Guzzle client’s constructor and Guzzle deals with the details from there. (Guzzle is the 3rd party library that we use for making HTTP/HTTPS requests from within OJS/OMP/OPS; it relies on curl when available, as in your case, but has other options when it isn’t.)

The message you’re getting is from curl, indicating that something went wrong during the protocol handshake when it tried to contact the proxy server. From the thread, you might try using a http URL (rather than https) in the https_proxy option, but the details will depend on your proxy server, and I’m just guessing.

If you can’t get this going and want to test your proxy configuration with Guzzle outside of the OJS environment, you could start working with a basic Guzzle example script.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

@asmecher I got it working! Your guess was correct. This is how our config file reads now:

http_proxy = “http://serverproxy.towson.edu:80
https_proxy = “http://serverproxy.towson.edu:80

Here is what I think is happening; Our F5 device takes HTTP sites hosted in our data center and automagically converts them to to HTTPS. This is meant to make hosting sites and applying SSL certs easier and more centralized.

In our case our proxy is looking for HTTP over HTTPS and thus we need to configure the OJS proxy in a somewhat backward way. Counter intuitive but it seems to work. I will poke it a little more before informing end uses but it seems to work!

@asmecher thank you for your kind help! I will gladly finance a beverage of your choice at any time. I appreciate your knowledge and diligent assistance!

Hi @egadsby,

Glad it’s fixed! My beer fridge is healthy at the moment (thanks for the offer) – but a kind word with your institution in support of the work we do would be wonderful.

Thanks,
Alec Smecher
Public Knowledge Project Team

This topic was automatically closed after 6 days. New replies are no longer allowed.