Evergreen ILS Website

IRC log for #evergreen, 2015-06-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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:2​443/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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat