| Time |
Nick |
Message |
| 01:33 |
|
StomproJ joined #evergreen |
| 03:04 |
|
Stompro joined #evergreen |
| 03:22 |
|
dcook__ joined #evergreen |
| 04:59 |
|
StomproJ joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:43 |
|
rhamby joined #evergreen |
| 05:43 |
|
gmcharlt joined #evergreen |
| 05:45 |
|
StomproJosh joined #evergreen |
| 06:01 |
|
Stompro joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
Dyrcona joined #evergreen |
| 09:20 |
|
maryj joined #evergreen |
| 09:25 |
|
jvwoolf joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:52 |
* Dyrcona |
should slow down and proof read his emails before hitting send this morning.... ;) |
| 09:59 |
|
mmorgan1 joined #evergreen |
| 10:14 |
|
Christineb joined #evergreen |
| 11:10 |
bshum |
@dessert add Mint Chocolate Chip Cookies |
| 11:10 |
pinesol_green |
bshum: The operation succeeded. Dessert #48 added. |
| 11:36 |
Dyrcona |
@weather |
| 11:36 |
pinesol_green |
Dyrcona: Methuen, MA :: Clear :: 52F/11C | Thursday: Sunny. High around 55F. Winds W at 10 to 15 mph. Thursday Night: Clear skies. Low near 35F. Winds WSW at 10 to 15 mph. |
| 11:37 |
Dyrcona |
Yeah, it's December 1, and I just went outside in a t-shirt and wearing flip flops and thought nothing of it. |
| 11:49 |
bshum |
I'm dreaming of a white Christmas |
| 11:49 |
bshum |
It's been awhile |
| 11:50 |
berick |
@weather 27712 |
| 11:50 |
pinesol_green |
berick: Durham, NC :: Clear :: 57F/14C | Thursday: Sunny. High 61F. Winds W at 5 to 10 mph. Thursday Night: Clear skies. Low around 35F. Winds light and variable. | Updated: 54m ago |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:06 |
|
mmorgan joined #evergreen |
| 12:07 |
|
bmills joined #evergreen |
| 12:27 |
tsbere |
@weather |
| 12:27 |
pinesol_green |
tsbere: North Andover, MA :: Mostly Cloudy :: 57F/14C | Thursday: Sunny. High 56F. Winds W at 10 to 15 mph. Thursday Night: A clear sky. Low 36F. Winds WSW at 10 to 15 mph. |
| 12:40 |
|
jvwoolf joined #evergreen |
| 13:05 |
|
sandbergja joined #evergreen |
| 13:20 |
|
rlefaive joined #evergreen |
| 13:21 |
|
rlefaive left #evergreen |
| 13:24 |
|
Dyrcona joined #evergreen |
| 13:24 |
|
kmlussier joined #evergreen |
| 13:36 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: fixing missing anchor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33956ec> |
| 14:13 |
Stompro |
Hmm, I wonder why it is taking 3+ hours for an email I sent to the general list to show up? |
| 14:15 |
|
TARA joined #evergreen |
| 14:15 |
tsbere |
Maybe your mail server is being stupid, or maybe it got stuck waiting for moderation |
| 14:16 |
kmlussier |
Stompro: It sometimes takes a while for my messages to show up. Not 3 hours, though. |
| 14:16 |
|
kmlussier joined #evergreen |
| 14:17 |
Stompro |
I checked the markmail archive to see if I just didn't receive a copy back, but it isn't there either. I wonder if I'm sending from the wrong address which is forcing moderation? We are using hosted exchange, and microsoft never messes up, so it cannot be that. |
| 14:18 |
miker |
Stompro++ |
| 14:18 |
* miker |
just snorted |
| 14:26 |
Dyrcona |
heh |
| 14:29 |
csharp |
Stompro: I'll look |
| 14:31 |
Stompro |
csharp, I'm checking exchange, looks like it is held up there, it is on my end. |
| 14:32 |
Stompro |
csharp, looks like it is just being held up by greylisting. |
| 14:33 |
csharp |
Stompro: yeah, I don't see your address in the mailman logs for anything today |
| 14:33 |
Dyrcona |
Stompro: Greylisting outgoing mail is unusual. |
| 14:35 |
Stompro |
Dyrcona, list.georgialibraries.org is doing the greylisting. |
| 14:35 |
Dyrcona |
Ah, OK, then. That makes more sense than what I was thinking. :) |
| 14:38 |
csharp |
outbound.protection.outlook.com is the issue |
| 14:39 |
jeff |
i was going to blame greylisting or DMARC. :-) |
| 14:39 |
csharp |
the sending hostname can change with every send |
| 14:39 |
csharp |
https://support.microsoft.com/en-us/kb/3019655 |
| 14:40 |
* tsbere |
hates that and should consider digging up what he did to bypass that for MVLC |
| 14:41 |
tsbere |
csharp: Is postfix being used by list.georgialibraries.org? |
| 14:41 |
csharp |
tsbere: yep |
| 14:42 |
tsbere |
csharp: I added this just before our greylisting entry in our main.cf to bypass that issue, maybe you should consider doing the same? permit_dnswl_client list.dnswl.org, |
| 14:42 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Making sure that image filenames don't include . character, as this can cause some versions of a2x to fail - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=80761d4> |
| 14:43 |
tsbere |
csharp: Note that our greylisting entry is literally the last one in the chain, if that isn't the case with list.georgialibraries.org then some adjustment may be needed |
| 14:51 |
csharp |
tsbere: I'll pass this on to our postfix guy ;-) Thanks! |
| 14:53 |
csharp |
in other news, 1) go to http://next.gapines.org 2) click on the language selector in the upper right, select "Spanish" and click "Change" |
| 14:53 |
csharp |
(we know there are some untranslated strings that are custom to us - we're working on it) |
| 14:57 |
bshum |
csharp: Pretty! |
| 14:58 |
bmills |
csharp: nice! we're doing the same thing pretty soon here |
| 14:58 |
bshum |
Doesn't seem to stick the language variable all the time, like after I switched it, I did a search and it came back as English :\ |
| 14:58 |
bshum |
Might just be a quirk with my browser. |
| 14:59 |
csharp |
bshum: I saw that too, but terran assures me it's a browser-side thing |
| 15:01 |
csharp |
yep, a fresh chrome browser "sticks" once I set it |
| 15:17 |
Bmagic |
I am troublshooting some SIP issues. It looks like we have come down to this: the server kills the connection at 10 minutes exactly. Does this sound familiar to anyone? |
| 15:18 |
tsbere |
Bmagic: Is the connection doing anything in those 10 minutes? |
| 15:18 |
tsbere |
(beyond sitting there) |
| 15:18 |
Bmagic |
yes, Bibliotheca said they tweaked their software to keepalive every 60 seconds |
| 15:18 |
tsbere |
Bmagic: To clarify: Are any *SIP* messages being sent in those 10 minutes? |
| 15:19 |
jeff |
what kind of keepalive? a tcp level keepalive, or an ACS Status message, or? |
| 15:19 |
jeff |
and yes, next question is are you seeing traffic in the logs during that otherwise-idle time. |
| 15:19 |
Bmagic |
tsbere: I don't have an answer for that right now. I will ask and track some logs |
| 15:19 |
Bmagic |
jeff: so in theory, if* they are sending those packets, it would keep it going? |
| 15:19 |
jeff |
it would be more likely to. |
| 15:20 |
tsbere |
Bmagic: If no SIP messages are being sent it is probably the timeout value, likely on the service entry. |
| 15:20 |
tsbere |
Though it may also be on the institution entry.....I would need to look it up. |
| 15:21 |
Dyrcona |
Bmagic: Install Socket::Linux....and set all timeouts to 0 in the oils_sip.xml. :) |
| 15:21 |
Bmagic |
hmmmm.... Dyrcona: I will try that |
| 15:21 |
Bmagic |
Dyrcona: will that eventually make the server crash? |
| 15:22 |
Dyrcona |
Bmagic: No, it actually improves things tremendously. |
| 15:22 |
Dyrcona |
Truly dead connections get cleaned up. |
| 15:22 |
Dyrcona |
We're running 50 fewer SIPServers at the end of the day, and no one complaining about losing the connection. |
| 15:23 |
Dyrcona |
Of course, Socket::Linux may not help if you're using the Multiplex variant. |
| 15:23 |
Bmagic |
using PreFork |
| 15:23 |
Dyrcona |
Yeah, PreFork here, too. |
| 15:23 |
Dyrcona |
So, it *should* help in theory. :) |
| 15:24 |
Dyrcona |
You might need to adjust the TCP keep alive timeout value in the SIPServer code. |
| 15:25 |
Dyrcona |
I had to lower it because some piece of equipment (probably the C/W MARS firewall) was killing idle connections sooner than the hard coded value in the SIPServer code. |
| 15:26 |
Dyrcona |
Could be the UMass routers... I never looked into what was doing it. |
| 15:26 |
Dyrcona |
Did I open a Lp bug to make those settings configurable? |
| 15:27 |
Bmagic |
"sending SC status without logging in first" |
| 15:27 |
Dyrcona |
Well, you can turn that on, too, but sounds like you're having idle tcp connections dropped somewhere along the line. |
| 15:28 |
Bmagic |
I set the config to 7200 seconds |
| 15:28 |
Bmagic |
handle_acs_status: timeout field wrong size: '7200' |
| 15:30 |
Dyrcona |
In the config, set all timeout="XXX" to timeout="0" |
| 15:30 |
Dyrcona |
That disables timeouts. |
| 15:30 |
Dyrcona |
Next, install Socket::Linux, that enables some code in SIPServer to do TCP keepalive with the client. |
| 15:31 |
Dyrcona |
It also cleans up dead connections much better than not having it installed. |
| 15:32 |
Dyrcona |
The "options" I'm talking about are related to Socket::Linux and have hard-coded values in SIPServer.pm starting about line 154. |
| 15:34 |
Bmagic |
I did that just now except for editing SIPServer.pm |
| 15:35 |
Bmagic |
setsockopt($self->{server}->{client}, SOL_SOCKET, SO_KEEPALIVE, 1) ??? |
| 15:35 |
Dyrcona |
Yeah, that's where it starts. |
| 15:35 |
Dyrcona |
I say leave it alone and see if the complaints stop. :) |
| 15:35 |
Dyrcona |
But the next line is the one that I had to change. |
| 15:36 |
Bmagic |
what should that be? that number 1 in that example should be 0? |
| 15:36 |
Dyrcona |
The setsockopt call to set TCP_KEEPIDLE. |
| 15:36 |
Dyrcona |
No, you want SO_KEEPALIVE 1, that turns on TCP keep alive packets. |
| 15:36 |
Bmagic |
that is hard coded to 120 right now |
| 15:36 |
Dyrcona |
Right. I'd leave at that for now. |
| 15:37 |
Bmagic |
no need to edit TCP_KEEPINTVL ? |
| 15:37 |
Dyrcona |
I changed ours to 30, because something was dropping connections at less than 2 minutes idle. |
| 15:37 |
Bmagic |
I messed with the kernel settings around this |
| 15:37 |
Dyrcona |
Ten seconds should be often enough to keep the connection open. :) |
| 15:38 |
Bmagic |
You changed your TCP_KEEPIDLE to 30 down from 120? |
| 15:38 |
Dyrcona |
Basically, the settings do this in the following order: |
| 15:38 |
Dyrcona |
SO_KEEPALIVE: 1 activates TCP keep alive packets |
| 15:39 |
Dyrcona |
TCP_KEEPIDLE : number of seconds to wait before sending keep alive packets on an idle connection |
| 15:39 |
Dyrcona |
TCP_KEEPINTVL: Number of seconds between keep alive packets on an idle connection. |
| 15:39 |
Dyrcona |
To answer your question: Yes. |
| 15:40 |
Dyrcona |
At 120 connections were still getting dropped. |
| 15:40 |
Dyrcona |
You might not have that issue. Depends on the networking at both ends and in between. :) |
| 15:43 |
Dyrcona |
It makes some sense for the last two to be the same, if they're both less than 60, but I left the TCP_KEEPINTVL at 10. |
| 15:46 |
Dyrcona |
Alles klar, Herr Kommissar? |
| 15:51 |
Bmagic |
I found some errors |
| 15:52 |
Bmagic |
open-ils.cstore: permacrud received a bad auth token |
| 15:53 |
Bmagic |
so, even with the keepalive, the authentication token is expiring? |
| 15:55 |
jeff |
are you still dealing with memcached evictions? |
| 15:55 |
jeff |
(or am i misremembering and you never were?) |
| 15:55 |
Bmagic |
no body has complained... but.... let me see what memcstat tells me |
| 15:55 |
Dyrcona |
Yes, it will expire unless they do something that renews it. |
| 15:55 |
Dyrcona |
And what jeff said. :) |
| 15:56 |
Bmagic |
evictions: 0 |
| 15:56 |
Bmagic |
so, it's subject to the library setting? |
| 15:56 |
jeff |
next question: are you using a distinct user per SIP client, or are some SIP clients using credentials that are in use by another SIP client? |
| 15:57 |
Dyrcona |
Yeah, that's controlled by Evergreen and doesn't change. |
| 15:57 |
jeff |
(this may not actually make a difference in your scenario, but i'm still asking :P) |
| 15:57 |
Bmagic |
one user per library, so, same user for every self check machine |
| 15:57 |
jeff |
okay. |
| 15:57 |
* jeff |
pulls at a probably-not-relevant thread |
| 15:57 |
Bmagic |
however, I am seeing odd things in the logs. I am seeing authentications from a totally different user that shouldn't* know about this server..... |
| 15:58 |
|
DPearl joined #evergreen |
| 16:00 |
Bmagic |
I get tons of authentication successes for a totally different user |
| 16:01 |
Bmagic |
I am going to try to remove that user from the config and see what I get |
| 16:04 |
Bmagic |
oh boy, this is weird. Now in leu of that user being in the config, it chose another one..... I am very sure now that this is not users that are really logging in from SIP |
| 16:06 |
Bmagic |
I wonder if this has something to do with the workstation not* being included in the auth |
| 16:06 |
Dyrcona |
I'm not sure that I understand the situation at this point. |
| 16:07 |
Bmagic |
I setup a server just to test this situation. I gave the IP address to this one library. This one library in theory is the only library that knows about this server |
| 16:08 |
Bmagic |
and I was seeing authentications for another user... Odd, but whatever.... now with these extra clues. I decided to remove the unexpected user from the oils_sip.xml, then I started seeing a totally different user in the logs |
| 16:09 |
|
jihpringle joined #evergreen |
| 16:11 |
Dyrcona |
Does the IP address have an associated hostname? Have you ever used the IP address for SIP before? |
| 16:12 |
Bmagic |
nope, no DNS, and never used before |
| 16:12 |
Bmagic |
"sending SC status without logging in first" - normal message? |
| 16:14 |
Bmagic |
it looks like when it gets a "99" message, it's not associated with a session, so it logs in again with a random user from oils_sip.xml |
| 16:14 |
Dyrcona |
Yeah, that means exactly what it says. The client sent a SC status message before logging in. |
| 16:15 |
Dyrcona |
What is "it?" |
| 16:15 |
Bmagic |
SIPServer software |
| 16:16 |
Dyrcona |
Is that what it does? |
| 16:16 |
Dyrcona |
I've never looked at the implementation of that "feature." |
| 16:17 |
Bmagic |
I haven't looked at the code, but that is the behavior that I am noticing |
| 16:19 |
|
hbrennan joined #evergreen |
| 16:21 |
Dyrcona |
I guess it does. It uses the first account sorted by login. |
| 16:22 |
jeff |
What clients do you have that send SC status without logging in first? |
| 16:22 |
Dyrcona |
Apparently, the one at this library. :) |
| 16:24 |
jeff |
so far Relais is the only vendor mentioned with such a client. |
| 16:27 |
phasefx |
that behavior sounds familiar.. wasn't there a security bug along those lines? messages going with the wrong session |
| 16:28 |
Bmagic |
So, should the "99" message include some identification? |
| 16:28 |
|
bmills joined #evergreen |
| 16:29 |
jeff |
SIPServer commit cd773c2 added support for the Relais behavior if you set allow_sc_status_then_login |
| 16:29 |
pinesol_green |
jeff: [sipserver|Galen Charlton] LP#1338731: support clients that send 99 then 93 when starting a raw connection - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=cd773c2> |
| 16:29 |
Dyrcona |
Bmagic: It should come after a client has logged in. |
| 16:29 |
phasefx |
that must be what I'm thinking of |
| 16:30 |
Dyrcona |
Couldn't we handle a 99 without logging in as the first account, though? |
| 16:30 |
jeff |
and commit 22b77ed fixed an issue where you could see the "use the first account, not the logged in account" behavior |
| 16:30 |
pinesol_green |
jeff: [sipserver|Thomas Berezansky] LP#1463459: make SC Status handler recognize logged-in SIP session - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=22b77ed> |
| 16:30 |
jeff |
and commit a0b23e9 is also related, somewhat |
| 16:30 |
pinesol_green |
jeff: [sipserver|Galen Charlton] LP#1464748: don't toss terminal account information prematurely - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=a0b23e9> |
| 16:31 |
Bmagic |
They are using the 99 message as the "keep alive" but if it's not associated with a session, then the auth token expires eventually |
| 16:36 |
Bmagic |
Any ideas on a different message to use to "restart the timer" on the auth token? |
| 16:37 |
jeff |
Why are your auth sessions so short? |
| 16:37 |
Bmagic |
10 minutes |
| 16:37 |
Bmagic |
is that short? It's a library setting |
| 16:37 |
Dyrcona |
MVLC uses 4 hours. |
| 16:38 |
Bmagic |
without some kind of interaction with OpenSRF, the auth token expires |
| 16:38 |
jeff |
I don't think you should use a different SIP message for keeping things alive. I'd first recommend using longer timeouts for SIP auth sessions, and second suggest adding code to SIPServer to optionally refresh the auth session when you're handling a 99 msg. |
| 16:39 |
Bmagic |
4 hours would still be unacceptable. Whatever number we put in the library setting, it will still expire at some point. And if we set it to 4 hours, then the staff clients wouldn't expire when they want them to.... |
| 16:39 |
jeff |
But it sounds like you have multiple issues here, and I'm not sure we have enough info to identify them all. |
| 16:39 |
Bmagic |
jeff: One issue with refreshing the auth session in response to the 99 is that we don't know which session it is, hence the login everytime |
| 16:40 |
Dyrcona |
I believe it uses the auth.staff_timeout if the self check "user" is a descendant of staff. |
| 16:40 |
Bmagic |
CALL: open-ils.actor open-ils.actor.ou_setting.ancestor_default 1, auth.opac_timeout |
| 16:40 |
Dyrcona |
Bmagic: If this status before login is a feature of the self check at this library, tell them to turn it off if they can. It is not helping. |
| 16:41 |
Bmagic |
the AC_STATUS ("99") is the method they are using to "keepalive" - which I believe is working for the network layer but not for the auth token |
| 16:42 |
jeff |
Bmagic: "we don't know which session it is" doesn't make sense once a SIP client has logged in. that only matters if you're supporting a 99-then-login client, which of course you'd need to support/handle if you added optional "refresh the login session when responding to a 99" support to SIPServer/Evergreen. |
| 16:42 |
Dyrcona |
Bmagic: When they login, it uses the value appropriate to the login type. |
| 16:43 |
Bmagic |
jeff: I assumed it didn't know because of logs like "sending SC status without logging in first" |
| 16:43 |
Dyrcona |
When handling a 99 without them being logged in, it has no idea what user is sending the message. |
| 16:44 |
Dyrcona |
Bmagic: Tell them to stop using 99 as a keep alive. Enable the tcp keep alive and up your auth timeout. |
| 16:45 |
Bmagic |
what does evergreen use as a default when the library setting auth.opac_timeout is null? |
| 16:45 |
jeff |
before telling them anything, you might want to confirm what they are actually doing. packet capture and client and server logs are your friend. :-) |
| 16:45 |
Dyrcona |
Oh, stupid SIP logs in as type opac.... |
| 16:46 |
Dyrcona |
See, this is what comes from people abusing TCP. |
| 16:46 |
Dyrcona |
They open 1 TCP connection and expect it to function all damned day long. It doesn't work that way in the field, but it works fine on the LAN at the vendor's lab. |
| 16:47 |
Dyrcona |
BTW, timing out OPAC logins after 10 minutes is way too short in my opinion. |
| 16:47 |
Bmagic |
Dyrcona: I agree, this should be handled silently on their software |
| 16:48 |
Bmagic |
"oops, I got an error, let me try to login to the SIP server again before I show the patron an error message" |
| 16:49 |
Dyrcona |
You could change opac to staff on line 254 in OpenILS/SIP.pm. |
| 16:49 |
Dyrcona |
You might need to add STAFF_LOGIN permission to your SIP accounts, too. |
| 16:49 |
Dyrcona |
That would get them the same timeout as staff logins at least. |
| 16:50 |
Dyrcona |
Note: I'm looking at rel_2_10 for that line number. |
| 16:50 |
* jeff |
makes note of some things to look at later |
| 16:52 |
Dyrcona |
Bmagic: On the "oops" thing. The SC should really connect, login, do its business, logout, and repeat for each user session. |
| 16:53 |
Bmagic |
I agree |
| 16:53 |
jeff |
I don't, but who cares. :-) |
| 16:53 |
Dyrcona |
heh. I was gonna say, it may not always know when a session begins and ends. :) |
| 16:55 |
tsbere |
I think the SC should logout/disconnect if it sits idle. Don't care if it stays connected as 5 different people come up right in a row, I do if it is still connected after sitting for 15 minutes with nada going on. ;) |
| 16:55 |
Bmagic |
jeff: the sip user needs STAFF_LOGIN permission in order for the auth.opac_timeout to be respected? |
| 16:55 |
jeff |
sounds like you're describing the way that Multiplex works! ;-) |
| 16:56 |
jeff |
Bmagic: no. |
| 16:56 |
jeff |
Bmagic: Dyrcona was suggesting that you change code so that SIP would request a login type of "staff" instead of "opac", and for that you may need to also grant the users used by SIP clients an additional STAFF_LOGIN permission. |
| 16:56 |
Dyrcona |
Bmagic: You would need STAFF_LOGIN to login as type staff. See what I mentioned about line 254 above. |
| 16:57 |
Dyrcona |
What jeff said. ;) |
| 16:57 |
Bmagic |
gotcha |
| 16:57 |
jeff |
Bmagic: the permission does not determine which auth timeout org unit setting (or default) is used for the session, but the login type (specified in the call to open-ils.auth) does. |
| 16:57 |
Dyrcona |
What jeff said. :) |
| 16:57 |
Bmagic |
I see, and right now the code takes sip logins as "opac" |
| 16:57 |
* Dyrcona |
sits back and let's jeff complete his thoughts before he can finish typing them. |
| 16:58 |
jeff |
yeah, which is weird. i'm trying to remember if i've looked at that before, and if it's always been that way. |
| 16:58 |
jeff |
git can help me with one of those questions. |
| 16:58 |
Bmagic |
there is a type "sip" that I see come through on actor.usr_activty |
| 16:58 |
jeff |
that is not an open-ils.auth login type. |
| 16:58 |
Bmagic |
ah |
| 16:59 |
Bmagic |
What keeps bothering me is, this was working without a problem before we upgraded to 2.11 |
| 17:00 |
jeff |
open-ils.auth login types are opac, staff, temp, or persist |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
jeff |
What were you on before? |
| 17:02 |
jeff |
And what version and flavor of SIPServer were you running? |
| 17:02 |
Dyrcona |
jeff: It has always been opac. |
| 17:02 |
jeff |
Lots of variables. |
| 17:02 |
Dyrcona |
Bmagic: Did this library change their opac timeout in the mean time? |
| 17:02 |
Bmagic |
no |
| 17:03 |
Bmagic |
2.9.1 before |
| 17:03 |
Dyrcona |
And, it may not be their auth session going, but the connection being dropped by network equipment, still. |
| 17:03 |
jeff |
OpenILS::SIP code has logic to log back in after auth token expiry. |
| 17:03 |
|
mmorgan left #evergreen |
| 17:03 |
jeff |
I don't think the auth token expiry is your issue. |
| 17:04 |
Bmagic |
hmmmm |
| 17:05 |
Bmagic |
I am about to find out if it's fixed or not. I increased the expire time to 20 hours. If it errors in the 10 minutes like it has been, we should know shortly |
| 17:10 |
Dyrcona |
Bmagic++ # For making me learn more about SIP and Evergreen. :) |
| 17:10 |
Bmagic |
ha! |
| 17:11 |
Dyrcona |
I had a couple of surprises. :) |
| 17:11 |
Bmagic |
Dyrcona++ # For learning more about SIP and Evergreen |
| 17:11 |
jeff |
pre-conference session: a bunch of evergreen admins in a room try to explain how they think things work, then take turns showing each other the way things actually work. |
| 17:11 |
Bmagic |
jeff++ |
| 17:11 |
Bmagic |
tsbere++ |
| 17:11 |
Dyrcona |
jeff++ |
| 17:11 |
Bmagic |
you all need lots of karma, I really appreciate your help and ideas! |
| 17:12 |
jeff |
later, they improve the way things work. |
| 17:12 |
hbrennan |
jeff: ha! |
| 17:12 |
Dyrcona |
jeff: Do you think the login type should be changed to staff? |
| 17:12 |
Bmagic |
the session expire is looking like it's fixing it so far...... |
| 17:13 |
jeff |
Dyrcona: that's one of the things i'm going to look at. probably. |
| 17:13 |
Dyrcona |
Bmagic: Did you make the other changes that I suggested to timeouts and installing Socket::Linux. |
| 17:13 |
Bmagic |
yep |
| 17:13 |
Bmagic |
I changed the timeout settings in oils_sip.xml to 0 in the three places I found it |
| 17:14 |
Bmagic |
I added Socket::Linux |
| 17:14 |
Bmagic |
and did NOT* change the hardcoded values in SIPServer.pm. |
| 17:14 |
Dyrcona |
So, how do you know the session expiration change fixed it? |
| 17:15 |
Dyrcona |
jeff: I'm inclined to agree that login type should be staff, but I can see a reason it would be opac. |
| 17:15 |
Bmagic |
I think we can rule out the TCP session / networking issues. This is the error that led me to the opac_timeout setting |
| 17:15 |
jeff |
Dyrcona: oh? what reason? |
| 17:15 |
Dyrcona |
jeff: The SC is being operated by a patron. |
| 17:16 |
jeff |
the sc is staff. |
| 17:16 |
Bmagic |
SIPServer.pm [ERR :21742:CStoreEditor.pm:139:] editor[0|0] request error open-ils.cstore.set_audit_info : ["tokenid",null,null] : Exception: OpenSRF::DomainObject::oilsMethodException OpenILS::Utils::CStoreEditor CStoreEditor.pm:465 <401> open-ils.cstore: permacrud received a bad auth token: tokenid |
| 17:16 |
dbs |
Bmagic: I'm really sorry, I ran into this exact problem about a month ago and solved it |
| 17:16 |
Bmagic |
dbs++ |
| 17:16 |
Dyrcona |
Yeah, I can agree to that. I just try to think of different angles. |
| 17:16 |
Bmagic |
dbs: what was your solution? |
| 17:17 |
dbs |
but I can't remember if I posted a bug with the solution, one second |
| 17:17 |
dbs |
(I was freaking out on IRC, which isn't unusual) |
| 17:17 |
Bmagic |
dbs: lol Bibliotheca? |
| 17:17 |
dbs |
Bmagic: yep, pirak |
| 17:18 |
Bmagic |
from the bibliotheca guy - "We had an issue after one of our Canadian libraries upgraded to 2.11....." |
| 17:18 |
Bmagic |
Pirak is who I am speaking with |
| 17:19 |
dbs |
ah yes, added some verify_session calls |
| 17:19 |
Bmagic |
dbs: this is starting to ring some bells. I think you chimed in last week when I was talking about SIP (at that point I hadn't had this much detail) |
| 17:20 |
dbs |
Ce dossier utilise LU Drive, et l'accès est limité a les comptes @laurentian.ca / @laurentienne.ca. Vous devez connecter avec votre compte Laurentienne et utiliser le bouton « Switching accounts » pour accéder le dossier. |
| 17:20 |
dbs |
Oh jesssssssuz |
| 17:20 |
dbs |
http://pastebin.ca/3743513 |
| 17:20 |
dbs |
that's the diff that made the diff (so to speak) |
| 17:21 |
dbs |
let me create a branch real quick |
| 17:22 |
Bmagic |
That pastebin isn't loading for me. How about for anyone else? |
| 17:23 |
Dyrcona |
I get 502 website is offline. |
| 17:25 |
dbs |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/fix_sip_timeout |
| 17:25 |
dbs |
perfect timing there, pastebin.ca |
| 17:25 |
|
StomproJ joined #evergreen |
| 17:25 |
Bmagic |
wow |
| 17:25 |
Bmagic |
dbs++ |
| 17:26 |
dbs |
gotta run, sorry my eyes weren't on IRC earlier |
| 17:26 |
Bmagic |
dbs: no problem at all! |
| 17:26 |
dbs |
(and we're only on 2.10 still, fwiw) |
| 17:28 |
Bmagic |
so.... how did this break between 2.9 and 2.11? |
| 17:36 |
Bmagic |
Dyrcona: We know that the session change fixed it because we tested the server through each of those changes and nothing fixed it until the session expire time was extended |
| 17:37 |
Dyrcona |
Bmagic: If the auth.opac_timeout for the library was 10 minutes, that's too low. |
| 17:37 |
Dyrcona |
It might be all right for people using the OPAC in the library, but for people signed in from home, it is way too short. |
| 17:38 |
Bmagic |
Dyrcona: it was set to 10 minutes when we were on 2.9.1, didnt have this SIP issue |
| 17:38 |
Dyrcona |
As for what changed, I'm looking but I suspect the change might be outside of the SIP code. |
| 17:38 |
Dyrcona |
Bmagic: Understood and a lot happened to the auth code from 2.9 to 2.10. |
| 17:41 |
Dyrcona |
Changes in SIP.pm from 2.9 to 2.11 were relatively minor. The workstation is added if the location is set in the config. |
| 17:43 |
Dyrcona |
And, the arguments to open-ils.auth.authenticate.complete are passed via a named hashref, $opts, instead of directly. |
| 17:43 |
Dyrcona |
The login type is still opac. |
| 17:44 |
Dyrcona |
My suspicion is that the changes for better password encryption had some unintended consequences. |
| 17:44 |
Dyrcona |
That said, C/W MARS is on 2.10 and we've not had an issue with SIP that I'm aware of that was not resolved with the timeout and Socket::Linux changes. |
| 17:45 |
Dyrcona |
BTW, no changes in SIP.pm from 2.9 to 2.10. |
| 17:47 |
Bmagic |
interesting |
| 17:47 |
Bmagic |
it probably stems from the auth_internal stuff |
| 17:48 |
Dyrcona |
Could be. |
| 17:48 |
Bmagic |
Is there a bug that we can post dbs's branch on? |
| 17:48 |
Dyrcona |
I don't recall any. |
| 17:49 |
Dyrcona |
You could see if he opened one. He said that he couldn't remember if he did or not. |
| 17:50 |
Dyrcona |
It could be that auth_internal fixed something that was broken and allowing accounts to stay logged in too long, too. |
| 17:50 |
Bmagic |
:) |
| 17:51 |
Bmagic |
Dyrcona: I was wondering if this issue is auxillary to an existing bug.... even if dbs didn't create one |
| 17:55 |
Dyrcona |
Ha! |
| 17:55 |
Bmagic |
I didn't find one, so I made a new one bug 1646638 |
| 17:55 |
pinesol_green |
Launchpad bug 1646638 in Evergreen "SIP authentication sessions timeout in 2.11" [Undecided,New] https://launchpad.net/bugs/1646638 |
| 17:55 |
Dyrcona |
I see that. :) |
| 18:03 |
Dyrcona |
I laughed 'cause when I found that bug in my search, I was going to share it here, but then I saw that you had just made it. |
| 18:08 |
* jeff |
looks |
| 18:10 |
Dyrcona |
There were changes to Open-ILS/src/perlmods/lib/OpenILS/SIP/Patron.pm that use the authtoken more between 2.9 and 2.10. |
| 18:13 |
Dyrcona |
However, part of those changes end up doing an auth.session.retrieve which should, IIRC, refresh the token. |
| 18:14 |
|
dcook__ left #evergreen |
| 18:15 |
Dyrcona |
Yep. It does, if the session is still valid. |
| 18:15 |
Dyrcona |
So, that can't be it. |
| 18:17 |
Dyrcona |
Well, that's enough of that... :) |
| 18:22 |
Dyrcona |
Bmagic: One suggestion, don't put version numbers in your bug titles. Instead include a block in the description with Evergreen version, OpenSRF Version, Pg Version, and Linux distro and version. |
| 18:23 |
Dyrcona |
Of course, I've broken that 'rule' myself. ;) |
| 18:27 |
* Dyrcona |
signs out. |
| 20:27 |
|
Stompro joined #evergreen |
| 21:20 |
|
StomproJ joined #evergreen |
