| Time |
Nick |
Message |
| 05:13 |
|
stephengwills joined #evergreen |
| 05:14 |
|
stephengwills left #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:37 |
|
agoben_ joined #evergreen |
| 07:20 |
|
rjackson_isl_hom joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:51 |
|
Dyrcona joined #evergreen |
| 09:01 |
|
rfrasur joined #evergreen |
| 09:16 |
Dyrcona |
NULL can be a problem in the database. |
| 09:16 |
Dyrcona |
Well, it complicates queries for sure. |
| 09:17 |
|
stephengwills joined #evergreen |
| 10:20 |
|
terranm joined #evergreen |
| 10:21 |
terranm |
Is anybody here using a product called Open+ with Evergreen? |
| 10:31 |
jeff |
Not here. All of our libraries are staffed when they are open. |
| 10:35 |
terranm |
One of our libraries bought it without checking with us first, and of course the vendor claimed that other Evergreen libraries are using it. |
| 10:35 |
jeff |
An article about the Ventura County library that implemented it in 2018 stated that there were only two other libraries in the US offering similar service (though not explicit that they were using the same product): "one in Georgia and the other in the Minneapolis area" |
| 10:35 |
jeff |
Hah! |
| 10:36 |
jeff |
Well then they should check with the vendor to see which libraries are using it with Evergreen. |
| 10:38 |
terranm |
Yeah :/ She is checking with the vendor but hasn't heard back. There is a county in Georgia that is using it, but they are one of the only counties that isn't with PINES. |
| 10:38 |
jeff |
Since that vendor has a lot of SIP-based products, I'd imagine that much of the integration is SIP, but I'd want to see docs and get hands-on. |
| 10:38 |
terranm |
Yep |
| 10:39 |
terranm |
They told her it uses SIP2 and bases access on the permission group, so hopefully it will be that simple. |
| 10:39 |
* jeff |
nods |
| 10:40 |
jeff |
...as long as the permission group structure/conventions in the larger consortium supports what they want to do, which is probably to move people into a "special" group that are permitted access. |
| 10:42 |
jeff |
It could be something where you could create a sub-group, but if you don't want other libraries using that group but still need them to be able to edit patrons that the library has placed into that group, or if this library granting access should not mean that the next library to implement this wants that patron to have access... it quickly gets complex. |
| 10:43 |
terranm |
Yeah :/ |
| 10:43 |
jeff |
There are a few ways of implementing the more complex approaches, but they 1) may not be necessary and 2) would require some work that they may not have anticipated or planned for. |
| 10:44 |
jeff |
Hopefully it's 1. :-) |
| 10:56 |
terranm |
I will lobby hard against any more complex approaches. |
| 11:07 |
jeff |
Oh? |
| 11:07 |
jeff |
I mean, they're probably going to want to use the product that they're purchasing. :-) |
| 11:09 |
terranm |
By that I mean, if we can fix it by creating a new permission group, that's what we'll do rather than trying to do something more complex. |
| 11:12 |
jeff |
Ah! Yes, here's hoping it's that easy. |
| 11:14 |
jeff |
I don't know enough about PINES policy to comment on the probability of that. :-) |
| 11:19 |
terranm |
Heh. Yeah, it will have to go through review by the Subcommittees and then get approved by the Executive Committee before we can do anything. If we created a permission group for every one of the side cases that gets requested, there'd be hundreds. |
| 11:23 |
rhamby |
terranm only hundreds? |
| 11:23 |
terranm |
Well, just since I've been here :) |
| 11:27 |
csharp |
ok, so if there's a blocked SIP2 user (oilsAuth found too many recent failures for 'rbdigital' : 1129, forcing failure state.) what's the memcached key that stores that |
| 11:27 |
csharp |
memcdump | grep count shows no keys with that suffix |
| 11:42 |
csharp |
I don't want to have to go nuclear and kill everyone's sessions - I don't see how oils-auth is keeping count if there are no memcached keys |
| 11:43 |
berick |
csharp: you sure that memcdump is returning stuff? i think it needs --servers |
| 11:44 |
csharp |
yeah - it's returning other keys, just none with _count appended |
| 11:45 |
csharp |
memcdump --servers localhost | grep oils_auth (on each server in multiplexing terminal) |
| 11:46 |
csharp |
I've confirmed that OpenSRF and SIPServer are using those memcache servers |
| 11:47 |
berick |
hm, yeah, i'm getting the key here when I use the wrong password. e.g. oils_auth_br1mclark_count |
| 11:49 |
csharp |
hmm - not here |
| 11:50 |
berick |
csharp: would 'localhost' be right for a memcache instance that's accessed by other servers? |
| 11:50 |
csharp |
wtf? |
| 11:50 |
csharp |
oh - hmm |
| 11:50 |
csharp |
no, using the actual hostname didn't make a difference |
| 11:51 |
csharp |
(doing memcdump from the actual memcache servers) |
| 11:52 |
csharp |
I'm pulling my hair out here - it makes no sense |
| 11:57 |
csharp |
not seeing anything with my authtoken in memcache after a successful login either |
| 11:59 |
jeff |
if this doesn't return a session object, then you're most likely hitting the wrong memcached instance: |
| 11:59 |
jeff |
MEMCACHED_SERVERS=127.0.0.1 memccat oils_auth_TOKEN |
| 11:59 |
jeff |
replace IP and TOKEN with your values |
| 12:00 |
jeff |
memcdump is not guaranteed to return all keys. |
| 12:00 |
jeff |
rather, memcached does not guarantee that it will return all keys, making it impossible for memcdump to make that guarantee. |
| 12:01 |
csharp |
jeff: yes - I see that key with memccat! |
| 12:01 |
csharp |
hmm |
| 12:01 |
csharp |
found it! |
| 12:01 |
csharp |
jeff++ |
| 12:02 |
berick |
jeff++ |
| 12:02 |
* berick |
makes mental note re: memcdump |
| 12:02 |
csharp |
jeff: God bless you! |
| 12:02 |
jeff |
maybe postgres for session/auth in 3.next :-) |
| 12:03 |
berick |
+1 |
| 12:03 |
jeff |
csharp: I hope your hair feels better now. :-) |
| 12:03 |
* csharp |
glues hair back on |
| 12:03 |
jeff |
How many other areas are there where we're not using memcached as a cache? |
| 12:04 |
terranm |
jeff++ |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:24 |
rfrasur |
Ya know. Someone could theoretically use the booking module to replicate some of the aspects of open+ |
| 12:35 |
|
Dyrcona joined #evergreen |
| 12:35 |
jeff |
rfrasur: the building access, security system integration/replacement, and remote video monitoring are features that are touted which I don't think exist in the booking module at present. :-) |
| 12:37 |
rfrasur |
lol, no. Those things don't. But the reservation stuff does. Add proximity card access to a library card's functionality and a decent security monitoring service, it could work. Of course, no matter what, it's expensive. |
| 12:40 |
terranm |
Yeah, they want it only for a limited number of users who they want to give access to during off hours - people who have sensory issues and difficulty around lots of people, and people who are in high risk COVID populations. |
| 12:41 |
terranm |
And they're only doing it at one branch |
| 12:52 |
rfrasur |
Hmm, it's a laudable intention. |
| 12:55 |
terranm |
Yes, it's experimental for sure, but I'm interested in seeing how it goes. |
| 12:56 |
JBoyer |
I suppose if DEMCO still sells those self-service selfcheck book robots that would be an option. Wildly expensive but they do work with Evergreen and can be indoor/outdoor/both. |
| 12:56 |
JBoyer |
Doesn |
| 12:56 |
JBoyer |
t help folks who just buy some service and then ask you to make it work though. :) |
| 12:57 |
rfrasur |
lol, no. But there might be an alternate universe where all those intentions equate to outcomes that don't also include a million unintended (and less desirable) outcomes. |
| 12:58 |
rfrasur |
It COULD happen. In another universe. |
| 13:05 |
* mmorgan |
wonders what would be involved in booking a trip to another universe :-/ |
| 13:18 |
rfrasur |
Many have tried. We have no idea if they succeeded or not. |
| 13:18 |
* rfrasur |
sighs. |
| 14:13 |
|
jihpringle30 joined #evergreen |
| 14:37 |
mmorgan |
comcast-- |
| 14:39 |
pinesol |
[evergreen|Galen Charlton] LP#1896070: ensure that deatching course material doesn't delete non-temporary bibs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3347e86> |
| 14:48 |
gmcharlt |
noting that as of now, I've branched off rel_3_6 |
| 15:04 |
rfrasur |
gmcharlt++ |
| 15:09 |
pinesol |
[evergreen|Galen Charlton] clean up RELEASE_NOTES_NEXT upon branching of rel_3_6 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=acc168f> |
| 15:15 |
pinesol |
[evergreen|Galen Charlton] stamp 3.6-beta2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7521908> |
| 15:15 |
pinesol |
[evergreen|Galen Charlton] move 3.6-beta1 schema update to 3.6-beta2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f70e84f> |
| 15:15 |
pinesol |
[evergreen|Galen Charlton] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5244fbd> |
| 15:17 |
terranm |
gmcharlt++ |
| 15:25 |
pinesol |
[evergreen|Bill Erickson] LP1774008 Remove Hatch storage options - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=219ad43> |
| 15:52 |
Dyrcona |
gmcharlt++ |
| 16:03 |
terranm |
mmorgan: I'm refreshing my server and going to reinstall the holds fix again, so it'll be down for a little while |
| 16:04 |
mmorgan |
terranm++ Thanks! |
| 16:35 |
jeffdavis |
gmcharlt: bug 1843818 is ready with some fixes you previously suggested for remote auth APIs, would be good to get into the RC |
| 16:35 |
pinesol |
Launchpad bug 1843818 in Evergreen 3.5 "Configurable patron auth improvements" [Undecided,New] https://launchpad.net/bugs/1843818 |
| 16:35 |
jeffdavis |
not that your todo list needs lengthening... |
| 16:48 |
|
terranm joined #evergreen |
| 17:09 |
|
rjackson_isl_hom joined #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:24 |
|
jihpringle joined #evergreen |
| 18:37 |
gmcharlt |
jeffdavis: thanks! |
| 19:45 |
|
dickreckard_ joined #evergreen |
| 21:58 |
|
sandbergja joined #evergreen |
