| Time |
Nick |
Message |
| 05:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T04:52:32,076196669-0500 -0> |
| 07:05 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 07:31 |
|
jeffdavis joined #evergreen |
| 08:23 |
|
tlittle joined #evergreen |
| 08:24 |
|
bos20k joined #evergreen |
| 08:35 |
|
Dyrcona joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:19 |
|
stephengwills joined #evergreen |
| 09:43 |
|
sandbergja joined #evergreen |
| 09:50 |
|
RMiller joined #evergreen |
| 09:51 |
|
yboston joined #evergreen |
| 09:54 |
RMiller |
Hi, quick Evergreen install question. In step 11 of the Evergreen install, it tells me to copy the opensrf_core.xml file again, then modify it the same way I did in OpenSRF setup |
| 09:55 |
RMiller |
Since I only installed OpenSRF for the purposes of using Evergreen, do I need to do this step? |
| 09:56 |
JBoyer |
RMiller, yeah, the one included in OpenSRF only has a couple testing services defined, the example included with Evergreen defines the other services required by Evergreen and a couple testing services. |
| 09:56 |
RMiller |
So the Evergreen setup replaced that example file with something more thorough? |
| 09:57 |
RMiller |
It's the same location and filename, so that just seemed weird |
| 09:58 |
|
bwicksall joined #evergreen |
| 10:00 |
JBoyer |
yeah, that can be a little confusing. Changing one of their names slightly might make those steps a little easier to follow. |
| 10:00 |
RMiller |
Thanks for the clarification :) |
| 10:12 |
Dyrcona |
Seems to me that the redundant stuff could be moved from opensrf_core.xml to opensrf.xml, but no tuits. |
| 11:05 |
|
sandbergja joined #evergreen |
| 11:11 |
|
khuckins joined #evergreen |
| 11:48 |
|
RMiller joined #evergreen |
| 11:50 |
RMiller |
In Evergreen installation, step 13.2, where I'm configuring the database, what are "appropriate values" for <hostname>, <port>, and <dbname>? |
| 11:53 |
csharp |
RMiller: if you're on a single server (which your question implies, I think), you would probably use "localhost", "5432" (default PG port), and "evergreen" (suggested DB name from the install docs) |
| 11:55 |
RMiller |
Thank you! I don't know if my eyes just skipped over it, or if it's just assumed background knowledge I was missing, but I couldn't find it in the documentation |
| 11:58 |
csharp |
probably in the "assumed background knowledge" category - we've always struggled with where to draw the line between "what you should already know" and "what we should spell out explicitly" in our docs |
| 12:00 |
|
nfBurton joined #evergreen |
| 12:02 |
|
yboston joined #evergreen |
| 12:03 |
|
khuckins_ joined #evergreen |
| 12:25 |
stephengwills |
has anyone run into 3.1 opac login crashing with too many redirects? |
| 12:35 |
JBoyer |
stephengwills, sounds familiar but I don't recall what was going on. Are you using one of the proxy methods or connecting straight to apache? |
| 12:36 |
stephengwills |
i’m thinking this is my load balancer not playing well with the redirect |
| 12:37 |
stephengwills |
I have a round robin between two web servers. if I use the direct URL to web1, for instance, it appears to be working. |
| 12:37 |
JBoyer |
That's a good sign at least. |
| 12:38 |
JBoyer |
Which load balancer are you using? |
| 12:42 |
stephengwills |
looks like haproxy |
| 12:57 |
stephengwills |
yeah it’s bouncing between 1 and 2 trying to load /eg/opac/myopac/main which, of course redirects to /login |
| 12:57 |
|
khuckins joined #evergreen |
| 13:13 |
JBoyer |
Ouch. I don't have any experience with haproxy myself, but it sounds like there must be a config issue somewhere in there. |
| 13:25 |
JBoyer |
If it's safe to throw in a paste I'm sure someone could find time to take a look |
| 14:12 |
jeff |
stephengwills: a few possible issues... one, are all of the backend systems using the same memcached instance? |
| 14:13 |
jeff |
stephengwills: and is haproxy connecting to the backend systems over https? |
| 14:14 |
stephengwills |
backends would each have their own memcached system. I believe haproxy is connecting over 443 |
| 14:15 |
jeff |
if your backend systems are not sharing a memcached instance, then the session token from one would not be considered valid on another. |
| 14:16 |
jeff |
so unless you have taken some extraordinary steps to ensure that requests by a given client are only ever serviced by a specific backend host, you're going to run into issues where it appears that you are not logged in. you may never be able to successfully log in and could loop, like you're seeing. |
| 14:16 |
stephengwills |
ok. makes sense. |
| 14:17 |
jeff |
if haproxy was connecting over http and you weren't taking other steps to inform the backend systems of the client <-> haproxy protocol being https, then you'd run into similar redirect issues because the backend systems would think the client connection was over http and try to redirect to https, looping. |
| 14:19 |
jeff |
if you rule out those two issues and are still having problems with a "fresh" client, you might consider configuring haproxy to only use a single backend system as a next troubleshooting step. |
| 14:20 |
jeff |
and by a "fresh" client, I mean you might want to clear cache and restart the web browser, or try a new incognito/private browing session to test, to rule out the possibility that the client had cached a problematic redirect, etc. often not necessary, but good to rule out... |
| 14:21 |
stephengwills |
fair. thanks will do |
| 14:21 |
jeff |
good luck! |
| 14:26 |
jeff |
another issue that we might still be susceptible to is if you've created a directory in your DocumentRoot titled "eg", or if your hostname contains (or perhaps just starts with) "staff". I should find or create bugs for those two. They're less common, but if either rings a bell for you, could be that. :-) |
| 15:06 |
|
mmorgan1 joined #evergreen |
| 15:29 |
|
bdljohn1 joined #evergreen |
| 16:51 |
stephengwills |
one of the hosts I am retiring was named staff but that is no longer an issue. I fixed the eg_vhost to rewrite all traffic to https and now haproxy delivers a user to one of the hosts and that user should stay put for the druation of thier session, anyway. not fool proof but it got me past that issue. I’ll look into shared memcache after dinner. thanks for the suggestions. |
| 16:57 |
|
stephengwills left #evergreen |
| 17:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live/test.24.html#2018-12-19T16:53:56,389847953-0500 -0> |
| 17:33 |
|
stephengwills joined #evergreen |
| 18:17 |
|
nfBurton joined #evergreen |
| 20:27 |
|
sandbergja joined #evergreen |
| 20:36 |
* csharp |
looks forward to PG 10: https://wiki.postgresql.org/wiki/FAQ#How_does_PostgreSQL_use_CPU_resources.3F |
| 21:46 |
|
sandbergja joined #evergreen |
