| Time |
Nick |
Message |
| 00:00 |
|
nuentoter joined #evergreen |
| 00:20 |
|
nuentoter joined #evergreen |
| 07:24 |
|
jboyer-isl joined #evergreen |
| 07:33 |
|
ericar joined #evergreen |
| 07:52 |
|
rjackson_isl joined #evergreen |
| 08:02 |
|
collum joined #evergreen |
| 08:19 |
|
Newziky joined #evergreen |
| 08:35 |
|
mrpeters joined #evergreen |
| 08:41 |
|
montgoc1 joined #evergreen |
| 08:55 |
|
akilsdonk joined #evergreen |
| 08:56 |
|
maryj joined #evergreen |
| 08:56 |
|
Shae joined #evergreen |
| 09:06 |
|
RoganH joined #evergreen |
| 09:14 |
|
jwoodard joined #evergreen |
| 09:19 |
|
ericar joined #evergreen |
| 09:20 |
|
nuentoter joined #evergreen |
| 09:33 |
|
Stompro joined #evergreen |
| 09:33 |
dbwells |
gsams: it seems your config may no longer be allowing the 'texasgroup.worldcat.org' URL, but assuming you put that back, your SPU seems to be missing the middle pieces. Whatever is building that link is trying to tack the URL directly to the proxy server base, and that won't work. Rather, you want to end up with something like: https://catalog.northtexaslibraries.org:2443/login?url=http://texasgroup.worldcat.org/userObject?service=getToken&renew |
| 09:33 |
dbwells |
=true&groupNumber= |
| 09:35 |
Stompro |
Just got my first EG cluster running <virtual fist pump>. |
| 09:36 |
RoganH |
Stompro++ |
| 09:36 |
jeff |
Stompro++ |
| 09:40 |
Stompro |
Galen is going to go through it tomorrow and fix it all up, but I'm happy I got it as far as I did. gmcharlt++ esi++ |
| 09:45 |
|
dMiller_ joined #evergreen |
| 10:35 |
|
dMiller_ joined #evergreen |
| 10:36 |
|
bmills joined #evergreen |
| 10:40 |
|
wjr joined #evergreen |
| 10:43 |
|
drigeny joined #evergreen |
| 10:49 |
|
wjr joined #evergreen |
| 11:15 |
|
bmills joined #evergreen |
| 11:20 |
kmlussier |
Stompro++ |
| 11:33 |
tsbere |
Somewhat scary: One process's cpu/mem percents: 659.9 50.8 |
| 11:33 |
tsbere |
Made much less scary when I then realize it is a virtual machine with multiple cores allocated and a large amount of the system's memory allocated to it |
| 11:49 |
gsams |
dbwells: the texasgroup URL is actually supposed to be the entire last section of the config.txt file with all the find and replace bits. |
| 11:49 |
gsams |
at least, according to OCLC anyway. |
| 11:50 |
dbwells |
gsams: right, but something changed since I tried yesterday, and now I get "Bad URL" errors when using it in an SPU. Not sure what changed, though. |
| 11:50 |
dbwells |
I'm assuming you were trying things. |
| 11:51 |
gsams |
yeah I threw the sip info back into the user file, let me undo that again. |
| 11:54 |
pastebot |
"gsams" at 64.57.241.14 pasted "EZProxy attempt to request item from texasgroup results in a 404 after generating this web address." (1 line) at http://paste.evergreen-ils.org/62 |
| 11:55 |
gsams |
so I take the sip out and get this address, which I only pasted part of yesterday, after I try to order an item through texasgroup |
| 12:03 |
pastebot |
"dbwells" at 64.57.241.14 pasted "EZproxy URL with login portion added" (1 line) at http://paste.evergreen-ils.org/63 |
| 12:03 |
dbwells |
gsams:^^ I've not seen a typical use of EZProxy which doesn't start with a login, so maybe the above is what you want |
| 12:06 |
gsams |
dbwells: It appears that this ends up pointing to the same address, it just happened so fast originally that I didn't see it. |
| 12:06 |
gsams |
So it supposedly is taking me to that URL, then pointing me at the one that I pasted. |
| 12:06 |
gsams |
But I'm never given the option to log in at any point. |
| 12:08 |
gsams |
Well, I have another webex with them next week, maybe this will help us get this fixed... |
| 12:09 |
jwoodard |
gsams: I am not sure if anyone else is aware but I just let one of our libraries know that they can request items through NRE. This doesn't help patron-side but we are still able to request items for them. Might be worth mentioning in the general list. |
| 12:10 |
gsams |
jwoodard: That's would be an excellent idea, I'll do that now. Sometimes I forget what others may or may not be aware of. We fell back to our online/paper forms and have been notifying patrons of that. |
| 12:11 |
|
dMiller_ joined #evergreen |
| 12:11 |
dbwells |
gsams: ah, if you don't get a login, then you are probably getting bounced by EZProxy as a non-valid SPU. You need to add a RedirectSafe directive for catalog.northtexaslibraries.org |
| 12:12 |
dbwells |
i.e. RedirectSafe catalog.northtexaslibraries.org in your config.txt |
| 12:14 |
gsams |
dbwells: hrm. Same problem still occurs. |
| 12:14 |
dbwells |
no, you have to tell ezproxy to not bounce proxy requests to itself, but to allow a login->redirect |
| 12:14 |
dbwells |
sorry, ignore that |
| 12:15 |
dbwells |
When you say "same problem", you still get no login? Or you login and then get the 404? |
| 12:15 |
gsams |
I do not appear to be getting a login at all, it leads to the same address with a 404. |
| 12:15 |
gsams |
though I should probably reset or test at a different computer at this point |
| 12:16 |
gsams |
yeah, 404 no login option given |
| 12:17 |
hopkinsju |
jboyer-isl: Any update on those Ansible playbooks? I'm interested in working on that, but I'd like to have something to serve as a starting point. |
| 12:19 |
dbwells |
gsams: when I visit the URL I pasted above, I get the login prompt. It's possible you have cached redirect? |
| 12:21 |
gsams |
That is possible, I just attempted to request an item from a different computer instead to double check. I'm fixing that now on this computer with that link |
| 12:24 |
dbwells |
gsams: I'm heading out-of-office until later this afternoon. I know this issue isn't really EG releated, but feel free to ping me again later here or in a private channel if you want to keep troubleshooting. |
| 12:24 |
gsams |
dbwells: I appreciate the help so far, it's been a lot better than anything else I've received |
| 12:24 |
gsams |
I'll keep digging into it and see if I can figure it out |
| 12:24 |
gsams |
that did give me a login prompt though. |
| 12:25 |
dbwells |
gsams: and you got the 404 again after logging in? I think you may be missing some more configuration, as I am not seeing "Option UserObject" in anything you posted so far. |
| 12:26 |
gsams |
yeah, I get 404 after that |
| 12:26 |
|
jihpringle joined #evergreen |
| 12:27 |
gsams |
that'd probably be par for the course, the help I recieved early on has seemed only to have caused problems later on |
| 12:27 |
dbwells |
gsams: if you Google "Option UserObject" you can see some pages which show the config stuff needed for that to work. Good luck! |
| 12:27 |
gsams |
dbwells++ |
| 12:28 |
gsams |
thanks again for the help! |
| 12:28 |
|
collum joined #evergreen |
| 12:32 |
|
sandbergja joined #evergreen |
| 12:50 |
|
bmills joined #evergreen |
| 13:02 |
|
collum joined #evergreen |
| 13:07 |
mrpeters |
anyone handy at the moment (or here shortly) to put a key on file for me to push to working? new server... |
| 13:08 |
Bmagic |
Does anyone else have null columns for mmr.master_record? select * from metabib.metarecord where master_record is null |
| 13:21 |
Bmagic |
I might be wrong, but it looks like under some circumstances, rows are left in metabib.metarecord after a delete/merge of the underlying bibs. The master_record column ends up being null. |
| 13:23 |
Bmagic |
Which shows it's ugly face when browsing a patron's hold that happens to be on that metarecord |
| 13:24 |
tsbere |
mrpeters: Have you tried key forwarding from your workstation instead of putting keys on every new server? |
| 13:25 |
mrpeters |
no -- havent looked into that |
| 13:27 |
tsbere |
want some tips on getting that working? I have done so with windows and linux workstations before. |
| 13:27 |
mrpeters |
i can figure it out, i just want to push a patch real quick and need to move on to something else |
| 13:29 |
tsbere |
Bmagic: We have 140000 or so such rows, apparently |
| 13:36 |
rjackson_isl |
guess we have been bad here in Indiana - no exchange server for email this afternoon |
| 13:39 |
Bmagic |
tsbere: wow |
| 13:39 |
Bmagic |
tsbere: I guess your consortium doesn't use metarecord holds often? |
| 13:40 |
jeffdavis |
Bmagic: We have 1521 mmr records where master_record is null. |
| 13:41 |
tsbere |
Bmagic: Well, we also have 722000 without a null master_record column |
| 13:42 |
tsbere |
And yea, < 7000 total holds of type M out of around 4,000,000 total holds |
| 13:43 |
jeffdavis |
There's a function metabib.remap_metarecord_for_bib that I think is supposed to kick in when a bib record is deleted. It has a parameter retain_deleted which I think controls whether to purge now-useless mmr (and metarecord_source_map) entries |
| 13:44 |
Bmagic |
hmmm |
| 13:44 |
Bmagic |
it's a lib setting not set correctly? |
| 13:45 |
jeffdavis |
Ah, there it is. |
| 13:45 |
jeffdavis |
An internal flag, ingest.metarecord_mapping.preserve_on_delete. |
| 13:46 |
jeffdavis |
You want that flag to be enabled if you want to be able to search deleted bibs, I think. |
| 13:54 |
jboyer-isl |
hopkinsju: I have been working on that, stripping out a few hard-coded IPs and a few #WTF 's here and there. Nearly done! |
| 13:57 |
Bmagic |
jeffdavis: interesting |
| 13:58 |
Bmagic |
jeffdavis: that setting is false |
| 13:58 |
Bmagic |
so, with it false, it should remove those rows? |
| 14:04 |
jeffdavis |
Not exactly. |
| 14:20 |
|
buzzy joined #evergreen |
| 15:18 |
|
sarabee joined #evergreen |
| 15:51 |
|
wongon joined #evergreen |
| 15:54 |
Stompro |
@seen yboston |
| 15:54 |
pinesol_green |
Stompro: yboston was last seen in #evergreen 2 weeks, 0 days, 0 hours, 54 minutes, and 50 seconds ago: <yboston> OK folks time to wrap up. thank you for joing the practice time. I got two offers to have it June and I will follow through. Talk to you all later |
| 15:55 |
Stompro |
I haven't heard from Yamil for a while, Hopefully he is just on vacation. |
| 15:57 |
|
dMiller_ joined #evergreen |
| 16:54 |
Stompro |
Is there a guideline for when working git branches should be purged? I'm assuming that once something gets committed the working branch on git.evergreen-ils.org should be deleted? |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
dbs |
Stompro: that's a good assumption, but in practice very little ever gets purged |
| 17:12 |
Stompro |
dbs, I just thought of one reason not to purge, it would make it harder for someone that is looking at an old resolved bug, that wants to see details of a working branch. Rather than clicking on the link to the working branch they would have to track down the commit manually. |
| 17:18 |
|
bmills joined #evergreen |
| 17:19 |
kmlussier |
Stompro: Yes, he is on vacation. |
| 17:20 |
Stompro |
kmlussier, Good to hear, Was a dig meeting date ever scheduled? |
| 17:21 |
kmlussier |
I don't see a final decision on the date. |
| 17:23 |
|
Newziky left #evergreen |
| 17:23 |
kmlussier |
Stompro: I am one of those people who is always looking at old working branches after they have been committed. |
| 17:24 |
Stompro |
I shall never purge a working branch, thats resolved. |
| 17:24 |
Stompro |
:) |
| 17:48 |
kmlussier |
Stompro: About your request for a Sandbox for bug 1312699 |
| 17:48 |
pinesol_green |
Launchpad bug 1312699 in Evergreen "Editable Checkout History" (affected: 5, heat: 22) [Wishlist,Triaged] https://launchpad.net/bugs/1312699 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 17:49 |
kmlussier |
I could set one up for you, but my guess is that it would just result in the same internal error I got the last time I loaded it. |
| 17:49 |
* kmlussier |
should add a tag to that bug to rework the patch, but can't recall the name of the tag we decided to use. |
| 18:26 |
|
artunit joined #evergreen |
| 18:43 |
|
jonadab joined #evergreen |
| 19:35 |
|
wongon joined #evergreen |
| 20:06 |
|
nuentoter joined #evergreen |
| 20:06 |
nuentoter |
hello my friends |
| 20:33 |
|
opensrf joined #evergreen |
| 20:34 |
opensrf |
anyone live in here? |
| 20:35 |
|
opensrf left #evergreen |
| 20:47 |
|
woodswizard joined #evergreen |
| 20:47 |
woodswizard |
hello |
