| Time |
Nick |
Message |
| 01:31 |
|
JBoyer_alt joined #evergreen |
| 01:31 |
|
dcook joined #evergreen |
| 01:35 |
|
gsams joined #evergreen |
| 04:00 |
|
wsmoak_ joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:24 |
|
JBoyer joined #evergreen |
| 07:41 |
|
rlefaive joined #evergreen |
| 07:52 |
|
ericar joined #evergreen |
| 07:54 |
|
rlefaive left #evergreen |
| 07:55 |
|
rlefaive joined #evergreen |
| 08:21 |
|
Dyrcona joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:47 |
|
mrpeters joined #evergreen |
| 08:53 |
|
kmlussier joined #evergreen |
| 08:54 |
kmlussier |
Happy Friday! |
| 08:56 |
mmorgan |
kmlussier: Happy Friday to you, also! It finally came! |
| 08:56 |
|
ericar_ joined #evergreen |
| 09:02 |
* Dyrcona |
sings "It's Friday, Friday..." ;) |
| 09:02 |
Dyrcona |
So, having the database(s) stored on a single hard drive is a bad idea. |
| 09:03 |
* jeff |
raises an eyebrow |
| 09:03 |
Dyrcona |
A pingest that I started on Wednesday is still running. |
| 09:03 |
jeff |
Ah. |
| 09:04 |
jeff |
I'm safe. My database is on flash storage. Got one of those cool new "scandisk cruisers". |
| 09:04 |
Dyrcona |
Heh... |
| 09:04 |
Dyrcona |
Yeah, I should put it on my Cruzer or my Slide.... ;) |
| 09:04 |
Dyrcona |
Oh, wait, it won't fit..... Bummer. |
| 09:05 |
Dyrcona |
It's just a server that I use for development, so... |
| 09:06 |
Dyrcona |
At least I set noatime. :) |
| 09:08 |
Dyrcona |
On a marginally related note, looks like I'm going to write a script to turn our Apache entries from syslog into a common log format file so that I can run webalizer on it. |
| 09:09 |
Dyrcona |
Anyone else think that they'd be interested in that? |
| 09:11 |
jeff |
I'm surprised there isn't something like that already. |
| 09:12 |
JBoyer |
Why not just have apache log it as expected up front? (i.e. mess with or don't mess with the rsyslog config?) |
| 09:12 |
kmlussier |
Dyrcona: Yes, I think others would be interested. I would be interested. |
| 09:12 |
JBoyer |
Or am I missing something? (quite possible) |
| 09:16 |
Dyrcona |
JBoyer: I prefer just using Apache logs, but the recommendation in the README (now) is to run everything through syslog, and the sample configs do that. |
| 09:17 |
Dyrcona |
Everything gets logs to a central logging server in our present environment. |
| 09:17 |
Dyrcona |
s/logs/logged/ |
| 09:17 |
|
bos20k joined #evergreen |
| 09:17 |
JBoyer |
Sure, I just mean as far as format; can it not go through syslog and end up in the format that webalizer needs? |
| 09:18 |
JBoyer |
If so, that part of the sample configs could be improved. |
| 09:23 |
Dyrcona |
Not when combined with other log entries, it can't. |
| 09:24 |
Dyrcona |
That's twice already today where I've either shared or offered to share something, and I've had to defend the practices behind what I'm talking about sharing. |
| 09:24 |
Dyrcona |
The Internet suck. |
| 09:24 |
Dyrcona |
s/suck/sucks/ |
| 09:28 |
Dyrcona |
Webalizer is a bit picky and I don't think it can parse the syslog entries with the extra junk that syslog adds. |
| 09:29 |
Dyrcona |
JBoyer: Sorry for the little remarks about sharing. It wasn't meant to be personal or anything. |
| 09:31 |
|
yboston joined #evergreen |
| 09:31 |
Dyrcona |
It's just tiring when you share something (with the git community on G+ in this case), and within 5 minutes you face comments like, "Why don't you do X?" or "Why don't you do Y?" |
| 09:32 |
Dyrcona |
As if you're expected to defend every little decision you make. |
| 09:32 |
Dyrcona |
Even when those decisions are made for you by the community you work in. |
| 09:33 |
Dyrcona |
As for demangling the Apache logs, I think putting them into a separate file in CLF is a bit better than what I'm presently doing. |
| 09:33 |
Dyrcona |
Right now I have a Perl program that parses the log entries and then inserts them into a Pg database. |
| 09:34 |
Dyrcona |
That Pg database also runs on that server where the databases are stored on a single hard drive. |
| 09:34 |
Dyrcona |
ok.... </rant> |
| 09:36 |
Dyrcona |
Putting the logs into a database made sense when I wanted to use SQL queries to figure out why we were slow at certain times, etc. |
| 09:36 |
JBoyer |
I can see that being annoying. I meant it more as "help me understand" than "why are you so wrong," but you know, internet. |
| 09:36 |
JBoyer |
(The sharing thing, that is.) |
| 09:36 |
Dyrcona |
JBoyer: Yeah, I know. I think I just had a bad taste from G+ still in my mouth. |
| 09:37 |
Dyrcona |
I also think our log format may be a little customized beyond normal.... I'll double check. |
| 09:38 |
Dyrcona |
By default, you should be getting CLF into syslog, but what comes out is CLF plus syslog stuff in front. |
| 09:38 |
Dyrcona |
Webalizer might be able to parse that with some options, it has been a while since I last actually used webalizer. |
| 09:39 |
Dyrcona |
My plan is to just pull the apache entries from our various syslog files and dump them into a single, CLF-formatted, gzipped file to be parsed by webalizer. |
| 09:40 |
Dyrcona |
Oh, look at that! |
| 09:40 |
Dyrcona |
The inserts of a year's worth of log entries finished while I was ranting. :) |
| 09:40 |
Dyrcona |
My parallel ingest is still going though. :) |
| 09:41 |
JBoyer |
Not having timed it I sometimes wonder if I didn't make everyone's reingest times go through the roof by adding all of those ff entries. D: |
| 09:43 |
Dyrcona |
JBoyer: I don't really have any metrics to compare on this server. |
| 09:43 |
Dyrcona |
We also haven't applied that upgrade to production, yet. |
| 09:43 |
Dyrcona |
Production is a lot faster: more RAM plus SSDs with software RAID. |
| 09:44 |
Dyrcona |
I suppose that I could do an ingest before applying that upgrade and then after. |
| 09:44 |
JBoyer |
Well I don't feel so bad now, heh. |
| 09:45 |
Dyrcona |
No, don't feel bad. More field entries is a good thing. |
| 09:45 |
jeff |
JBoyer: when you were auditing those fixed fields, did you also correct the errors in the marc editor and such? |
| 09:45 |
JBoyer |
If they're not too intrusive on your environment I'd be curious. I mean, I don't really plan to pull it out, but curiosity, you know. |
| 09:45 |
jeff |
JBoyer: or were you focused exclusively on the in-db defs? |
| 09:45 |
JBoyer |
jeff, I did not. I believe that patch is all in-db. |
| 09:46 |
jeff |
Got it. Thanks. |
| 09:47 |
JBoyer |
My hope is that the web client will be correct so it won't matter for long, but what errors are you referring to? |
| 09:47 |
jeff |
In some of my notes (which I think I shared) I had found some fields were the marc editor was off. |
| 09:47 |
jeff |
They may have since been fixed. |
| 09:48 |
jeff |
I'll try to go back and look. |
| 09:49 |
JBoyer |
I'm not sure the editor "knows" anything on it's own, and there were a couple of db defs that I corrected in that same patch, so maybe it worked out. Have to see when you find your notes. |
| 09:49 |
JBoyer |
Hello, william, shatner here to, upgrade your, data, bases. |
| 09:50 |
jeff |
JBoyer: to be clear, i was referring to the XUL client marc editor. :-) |
| 09:51 |
JBoyer |
I know, that's also what I meant about it not mattering for much longer. :) |
| 09:51 |
* jeff |
nods |
| 09:52 |
Dyrcona |
:) |
| 09:52 |
jeff |
The comment about the editor "knowing" anything on its own made me think you were speaking of the web staff client marc editor. :-) |
| 09:52 |
* Dyrcona |
imagines a lolcat meme: "I'm in your bases, upgradin' your data." |
| 09:53 |
JBoyer |
Ah, no. That was why I'm hoping that the very few changes I made to exiting defs helped. |
| 09:53 |
JBoyer |
Dyrcona++ |
| 09:57 |
* Dyrcona |
need some vacation... Oh look! I'm off next week! |
| 09:57 |
* Dyrcona |
needs to learn to spell in his native language. |
| 09:57 |
Dyrcona |
Well, PgAdmin took a dirt nap. |
| 09:58 |
Dyrcona |
My day if off to a ripping start.... |
| 09:58 |
Dyrcona |
@roulette |
| 09:58 |
pinesol_green |
Dyrcona: *click* |
| 09:58 |
|
bos20k joined #evergreen |
| 09:58 |
|
ericar_ joined #evergreen |
| 09:58 |
|
mdriscoll joined #evergreen |
| 10:00 |
kmlussier |
vacations++ |
| 10:18 |
* Dyrcona |
would not be surprised if just doing the ingest without parallelization is faster on this particular hardware. |
| 10:21 |
|
bos20k joined #evergreen |
| 10:30 |
JBoyer |
Ooh, just saw my first SIP transaction with a workstation id. Fly, fly my patches! |
| 10:32 |
jeff |
heh |
| 10:34 |
JBoyer |
It honestly took longer to figure out how the connection between SIPServer and the ILS driver worked that it did to get this whole feature finished. |
| 10:34 |
JBoyer |
(If you separate the two, that is. Otherwise talk about literally being more then the sum of its parts...) |
| 10:35 |
Dyrcona |
JBoyer++ |
| 10:35 |
Dyrcona |
Yep. It often takes longer to figure out where to make the changes than it does to make the actual changes. |
| 10:35 |
|
Christineb joined #evergreen |
| 10:47 |
JBoyer |
I'll spare everyone the complaining that all know lies deep in my heart. |
| 10:49 |
Dyrcona |
Heh. That's just software. Complex systems are complex. |
| 10:50 |
* Dyrcona |
is trying to have a better rest of his day... |
| 10:50 |
|
brahmina joined #evergreen |
| 10:51 |
mmorgan |
@tea Dyrcona |
| 10:51 |
* pinesol_green |
brews and pours a pot of Masala Chai, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/rishi/masala-chai/4495/) |
| 10:51 |
Dyrcona |
mmorgan: Thanks! |
| 10:56 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Sample Syslog" (3 lines) at http://paste.evergreen-ils.org/24 |
| 10:57 |
Dyrcona |
JBoyer ^ above is why I can't just run webalizer on our syslogs. |
| 10:58 |
Dyrcona |
It's a mix of Apache logs and other things. |
| 10:59 |
Dyrcona |
And some of the Apache lines include a "message repeated X times" bit. |
| 11:03 |
Dyrcona |
On the plus side, the actual Apache bit is already in common log format. |
| 11:21 |
JBoyer |
I was thinking about using a different LOCALx options to pull them out into their own file, but then you've still got to fix the format I suppose, so not much of a win there |
| 11:28 |
|
bmills joined #evergreen |
| 11:34 |
Bmagic |
grep filter first? |
| 12:01 |
|
sandbergja joined #evergreen |
| 12:07 |
Bmagic |
I am writing some code to generate fines on specific transactions. I used some examples from fine_generator.pl which has "parallel" turned on. I don't want my code to continue executing until the fines have finished generating |
| 12:08 |
Bmagic |
so, I need to simply turn that off? |
| 12:08 |
tsbere |
Bmagic: Parallel is actually more of a "generate fines for more than one circ at a time" |
| 12:08 |
Bmagic |
$multi_generator->request( 'open-ils.storage.action.circulation.overdue.generate_fines', $circID ); |
| 12:09 |
tsbere |
Yes, that is basically intended as something like "queue them all up and run X at the same time" |
| 12:10 |
Bmagic |
I see, so, I need to code it to not use OpenSRF::MultiSession |
| 12:10 |
tsbere |
Only if you want to. You can also have it run one at a time. |
| 12:10 |
Bmagic |
perhaps I just need to sleep (that would suck) ? |
| 12:11 |
tsbere |
Bmagic: Are you collecting the response when you make your calls? |
| 12:11 |
Bmagic |
no, if I add ->gather(1); that will work? |
| 12:13 |
Dyrcona |
Bmagic: It should. |
| 12:13 |
Bmagic |
groovy, I'll try that |
| 12:14 |
Dyrcona |
I sometimes skip that and do ->recv() in a loop, then ->finsh() after the loop. |
| 12:14 |
Dyrcona |
gather gets all the results in one shot and the 1 indicates you want to finish. |
| 12:15 |
tsbere |
Bmagic: I think you could also call wait_complete? I am not positive. |
| 12:18 |
Dyrcona |
yeah, probably. |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:19 |
Dyrcona |
The code's in src/perl/lib/OpenSRF/AppSession.pm in OpenSRF if you want to look. |
| 12:19 |
Bmagic |
thanks! |
| 12:20 |
Dyrcona |
wait_complete doesn't return the data. |
| 12:21 |
Bmagic |
I don't really need the data, just want it to finish before I move on |
| 12:21 |
Bmagic |
so $multi_generator->request( 'open-ils.storage.action.circulation.overdue.generate_fines', $circID )->wait_complete(1); |
| 12:25 |
Dyrcona |
I don't usually use MultiSession. |
| 12:26 |
Bmagic |
yeah, I am thinking I want to abandon that too |
| 12:28 |
Dyrcona |
You probably want to fire them all off and do session_wait from OpenSRF::MultiSession |
| 12:28 |
tsbere |
Or just fire each one off and wait_complete it before firing the next one. Either way. |
| 12:31 |
Dyrcona |
The fine generator does each request in a loop and does session_wait after the loop. That's what I'd do if you've already started with MultiSession. |
| 12:35 |
|
bos20k_ joined #evergreen |
| 12:36 |
|
jvwoolf joined #evergreen |
| 12:39 |
rlefaive |
Does anyone know how to change the stemming configuration for search? The closest I can find is this message, but I can’t find the file referred to. http://markmail.org/message/qygwuvpmzqbwgipp |
| 12:40 |
kmlussier |
rlefaive: Are you looking to disable stemming altogether or are you making another adjustment to it? |
| 12:40 |
rlefaive |
kmlussier: ideally I want to disable it for title search while leaving it on for keyword, but realize that might not be an option. |
| 12:41 |
rlefaive |
kmlussier: I wish i hadn’t missed your discussions of search from earlier! |
| 12:41 |
kmlussier |
rlefaive: I have good news. It is an option! |
| 12:41 |
kmlussier |
And I'm pretty sure things have changed since that email thread, but give me a minute, I want to take a look at NOBLE's configuration to make sure I get it right. |
| 12:42 |
rlefaive |
kmlussier: that is awesome, thanks!! |
| 12:43 |
kmlussier |
OK, I'm not sure where this is in the database, but, in the staff client, go to Server Admin -> MARCH Search/Facet Class FTS Maps |
| 12:44 |
kmlussier |
You'll see that each search class has an entry with the non-stemmed simple config and the english stemmed config. |
| 12:45 |
mmorgan |
kmlussier: rlefaive: in the db it's config.metabib_class_ts_map |
| 12:45 |
kmlussier |
You want to set active to false for the english stemmed config for the classes where you want to disable stemming. |
| 12:45 |
rlefaive |
Ah!! wonderful! thanks! |
| 12:45 |
rlefaive |
@beer kmlussier mmorgan |
| 12:45 |
pinesol_green |
rlefaive: The horror... The horror... |
| 12:45 |
kmlussier |
I also always thought you needed to do a reingest after making that change, but miker once told me that you don't, so I'm not sure. |
| 12:46 |
rlefaive |
haha, thanks kmlussier! it sounds like the kind of thing that would need re-index. |
| 12:46 |
kmlussier |
I know NOBLE performed a reingest. |
| 12:46 |
rlefaive |
though it might disable the stemming of the query without a reingest |
| 12:46 |
kmlussier |
rlefaive: Yes, that's exactly it. |
| 12:47 |
miker |
kmlussier: there are situations where you don't need to reingest. fo rinstance, if you had it on and then turned it off, no reingest required because the exact string is already indexed |
| 12:47 |
miker |
however, if you had it off an turned it on, you would def need to reingest |
| 12:48 |
kmlussier |
miker: I see. That makes sense. Sort of |
| 12:48 |
rlefaive |
so queries like “chromaticism” will stop returning “chromatic” but i’ll still have “the assist” returning things with “assistance” |
| 12:49 |
rlefaive |
though if users could be trained to put quotes around words that they meant exactly, then we wouldn’t be in this dilemma… ;) |
| 12:50 |
kmlussier |
rlefaive: Yeah, well, if it only involved training staff, maybe. But training end users is an entirely different thing. :) |
| 12:51 |
kmlussier |
tsbere++ #Surfacing those settings in the client. |
| 12:51 |
mmorgan |
So, the ts_config always applies to the search query as well as creating the indexes? |
| 12:52 |
* mmorgan |
once thought that was true, but then wasn't sure. |
| 12:54 |
kmlussier |
mmorgan: That's my understanding. |
| 12:59 |
mmorgan |
Ok, thanks. I knew the normalizers were applied on the query side, but wasn't sure about this. |
| 13:10 |
Dyrcona |
And, PgAdmin takes another dirt nap.... |
| 13:28 |
|
geoffsams joined #evergreen |
| 13:38 |
sandbergja |
Is there a way to figure out what workstation applied a grocery bill to a patron's account? |
| 13:38 |
sandbergja |
I couldn't find anything likely in the auditor schema, but I also just don't know much about bills/money in evergreen. :-( |
| 13:41 |
jeff |
sandbergja: I don't think that there's anything that tracks that, no. You could go digging in logs if you were very motivated... |
| 13:41 |
sandbergja |
Good to know, jeff. Thanks! |
| 13:46 |
JBoyer |
Ugh. So, SIP stuff: does anyone know of a SIP selfcheck that forces you to supply a Location field that you can't change? I don't want to add YAOUS for this, but if you supply an invalid workstation name your connection dies. (the same thing happens now if you login with an inactive account.) |
| 13:47 |
JBoyer |
I am leaning hard on "turn it off if you aren't supplying a workstation name" but I could be persuaded if need be. |
| 13:52 |
jeff |
being able to ignore and/or force the location field on a per-listener and/or per-sip-user basis might cover you there. |
| 13:52 |
jeff |
i think we may have talked about that last month. |
| 13:53 |
jeff |
also, a soft failure with warning in logs on unfound workstation might be useful. |
| 13:53 |
jeff |
i think that would have to be implemented as "try to log in with username+password+workstation and if it fails try username+password" |
| 13:53 |
jeff |
(in the ILS driver) |
| 13:54 |
Dyrcona |
What prevents you from registering the workstation in Evergreen? |
| 13:56 |
JBoyer |
Dyrcona, nothing, I'm thinking about how much noise there will be if you currently have a random string in the CP field since it's currently unused and once SIPServer + Evergreen both have my patches you can't login until you edit the selfcheck config. |
| 13:57 |
JBoyer |
Although I didn't understand what you meant until now. |
| 13:57 |
JBoyer |
I suppose nothing. |
| 13:58 |
Dyrcona |
I haven't looked at your patches, yet, so maybe I don't have enough context. |
| 13:58 |
JBoyer |
I was asking in case I had to change them. I'll throw up what I have now and let people poke. |
| 13:59 |
JBoyer |
jeff, that would work, but I'm not aiming to go to that amount of effort unless required. |
| 14:00 |
Dyrcona |
If I have to change configs as a result of your patches, I don't mind. Just make sure there are release notes to that effect. :) |
| 14:00 |
jeff |
And ideally don't require touching every SIP2 client config. |
| 14:01 |
JBoyer |
configs only need to be changed on selfcheks if they currently supply the CP field. (I suspect that's very unlikely since it's currently unused.) Release notes are coming in case it's ready to go as-is. |
| 14:01 |
JBoyer |
Blank CPs are fine, they're ignored. |
| 14:01 |
JBoyer |
Also testing notes will go in LP. |
| 14:08 |
jeff |
Yeah, most of our SIP2 clients set CP. I don't want to speak for anyone else's clients, though. |
| 14:11 |
|
bmills joined #evergreen |
| 14:15 |
jeff |
Oh... lovely. |
| 14:21 |
Dyrcona |
So, poor webalizer got a little confused when processing our 137.6 million log lines. |
| 14:21 |
Dyrcona |
The summary page only included this month, followed by last month repeated for other month of statistics. |
| 14:22 |
Dyrcona |
However, the individual month files look all right. |
| 14:26 |
JBoyer |
lp1579144 |
| 14:26 |
JBoyer |
Oh, come now. |
| 14:26 |
jeff |
bug 1579144 |
| 14:26 |
pinesol_green |
Launchpad bug 1579144 in SIPServer "Send Location field to ILS driver at Login" [Undecided,New] https://launchpad.net/bugs/1579144 |
| 14:26 |
JBoyer |
bug 1259196 |
| 14:26 |
pinesol_green |
Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" [Wishlist,Confirmed] https://launchpad.net/bugs/1259196 |
| 14:27 |
JBoyer |
I assume the SIPServer patch is effectively harmless, it just sets one more value that can be ignored if it's not expected. |
| 14:38 |
|
bmills joined #evergreen |
| 14:41 |
Dyrcona |
We average just a touch over half a million hits/day on our OPAC. |
| 14:45 |
jeff |
including or excluding internal hits for AC pre-fetching? |
| 14:46 |
jeff |
because that's a significant multiplier, but should be included depending on what you're trying to measure and why. |
| 14:47 |
Dyrcona |
jeff: including. |
| 14:47 |
Dyrcona |
I didn't exclude any hosts. |
| 14:48 |
Dyrcona |
S'pose I could run it again, takes less than 1 hour. |
| 15:05 |
Dyrcona |
jeff: It isn't finished, yet, but a rough guess based on total hits/month for 1 month, indicates excluding the added content hits will knock off about 70,000/day on average. |
| 15:05 |
Dyrcona |
That puts us a hair under half a million/day. |
| 15:07 |
Dyrcona |
Not sure what effect it will have on sessions. |
| 15:07 |
Dyrcona |
However, I'm not gonna revise the visits/sessions numbers because they varied a lot from lows around 10,200 to high of almost 30,000. |
| 15:10 |
|
jlitrell joined #evergreen |
| 15:10 |
Dyrcona |
And, hey! My parallel ingest is almost done. It's working on the last two groups. |
| 15:10 |
Dyrcona |
;) |
| 15:12 |
Dyrcona |
I'm also using a bad method to count the average per day by averaging the average per day for each month, rather than adding up the total and averaging over the total number of days. |
| 15:12 |
Dyrcona |
The average of the average has a tendency to produce lower valued. |
| 15:12 |
Dyrcona |
s/valued/values/ |
| 15:16 |
|
bmills joined #evergreen |
| 15:17 |
Dyrcona |
Hmm... Might be nice to plug webalizer data into a database, then you can run queries on it..... |
| 15:18 |
Dyrcona |
That's my solution to everyhing isn't it? "Stick it in a database, then you can run queries on it." |
| 15:20 |
Dyrcona |
Hmm... index.html from this run is just as messed up as the previous one. |
| 15:20 |
Dyrcona |
And, it did not appear to change the output, so the hits for added content from the local IP were not ignored. |
| 15:26 |
|
jvwoolf joined #evergreen |
| 15:28 |
|
jvwoolf1 joined #evergreen |
| 15:28 |
tsbere |
Dyrcona: Did it re-use the various files and thus assume it was to skip processing anything it had already looked at? |
| 15:29 |
Dyrcona |
tsbere: Nope. I ran it with a different output directory and different options and there was no history file. |
| 15:30 |
Dyrcona |
I may have misunderstood the options.... |
| 15:33 |
Dyrcona |
Maybe the HideSite (-s) option only works if DNS lookups are used? |
| 15:35 |
Dyrcona |
Ah, I probably want IgnoreSite that can only be set in the config file. |
| 15:37 |
Dyrcona |
Third time's the charm, right? |
| 15:50 |
kmlussier |
tsbere++ #Fixing up VM build scripts. |
| 15:55 |
Dyrcona |
jeff: Looks like ignoring the local host's address makes about .1% difference in overall results. |
| 15:59 |
jeff |
Dyrcona: and of course they were probably already excluded by your reporting tool because they're HEAD requests... :-) |
| 15:59 |
jeff |
sorry if my curiosity drove you to do extra work for little gain! |
| 15:59 |
Dyrcona |
jeff: I think webalizer includes all requests unless otherwise told. |
| 16:00 |
Dyrcona |
Well, I might get a real average of the numbers this time, instead of an average of an average. |
| 16:00 |
|
ericar_ joined #evergreen |
| 16:03 |
Dyrcona |
Never mind, that's too much work for 4:00 pm on a Friday. :) |
| 16:05 |
csharp |
@quote add < Dyrcona> Never mind, that's too much work for 4:00 pm on a Friday. :) |
| 16:05 |
pinesol_green |
csharp: The operation succeeded. Quote #152 added. |
| 16:05 |
gmcharlt |
Dyrcona: bshum: er, am I wrong to think that turning on mod_perl2 for Xenail belongs in Evergreen, not OpenSRF? |
| 16:06 |
Dyrcona |
gmcharlt: OpenSRF installs it as a prerequisite, not Evergreen. |
| 16:06 |
* jeff |
nods |
| 16:06 |
jeff |
traditionally OpenSRF pre-req makefile installs and enables apache and modperl |
| 16:07 |
Dyrcona |
And enabling modperl was the issue on the VMs that kmlussier alluded to earlier. |
| 16:07 |
gmcharlt |
there are no mod_perl handlers in OpenSRF proper |
| 16:08 |
gmcharlt |
but yeah, given the tradition, 032a9647 now makes more sense to me |
| 16:08 |
pinesol_green |
gmcharlt: [opensrf|Jason Stephenson] LP#1551090: Enable mod_perl2 on Ubuntu 16.04 (Xenial Xerus). - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=032a964> |
| 16:09 |
|
bos20k joined #evergreen |
| 16:10 |
Dyrcona |
gmcharlt: Well, it could always be moved to Evergreen where it is actually required. |
| 16:10 |
* csharp |
has always wondered about the necessity of apache deps for opensrf |
| 16:10 |
gmcharlt |
Dyrcona: yeah; topic of a separate bug I'll open (though low priority for me) |
| 16:10 |
csharp |
(excluding websockets, of course) |
| 16:12 |
gmcharlt |
csharp: well, APR at least would be a mandatory build dep for opensrf, at least for building the translator and gateway |
| 16:12 |
Dyrcona |
So, on the webalizer thing: excluding the localhost IP drops average "sessions" by about 230 or .14%. |
| 16:14 |
jeff |
historical note: the Evergreen Makefile.install did install mod_perl, the OpenSRF Makefile.install was originally based off of Evergreen's, and later duplicates were removed from Evergreen... and mod_perl fell on the OpenSRF side of things. |
| 16:14 |
Dyrcona |
It has a more profound effect on "hits," dropping the average by almost 20%. |
| 16:15 |
jeff |
Also, fun fact: If you go back far enough in time, you run into the point where Evergreen and OpenSRF were in the same repo, and thus you get commit messages that reference things that aren't actually included in the commit content. :-) |
| 16:15 |
Dyrcona |
:) |
| 16:15 |
jeff |
commit 619e645 |
| 16:15 |
pinesol_green |
jeff: [evergreen|erickson] moved redirect to latest mod_perl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=619e645> |
| 16:16 |
Dyrcona |
Well, if modperl moves to Evergreen for 2.11 and OSRF 2.5, that might be a good thing. |
| 16:16 |
jeff |
commit 619e645 |
| 16:16 |
pinesol_green |
jeff: [evergreen|erickson] moved redirect to latest mod_perl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=619e645> |
| 16:16 |
jeff |
wait... hrm. |
| 16:16 |
jeff |
oh, right. |
| 16:17 |
jeff |
commit 23cc80e |
| 16:17 |
pinesol_green |
jeff: [opensrf|erickson] moved redirect to latest mod_perl - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=23cc80e> |
| 16:17 |
jeff |
there we go. confused myself. :-) |
| 16:18 |
jeff |
anyway, those two commits (one in evergreen, one in opensrf) are an example from when the repos were one. |
| 16:19 |
jeff |
also, early early pre-JSPAC template toolkit days :-) |
| 16:20 |
gmcharlt |
bug 1579219 |
| 16:20 |
pinesol_green |
Launchpad bug 1579219 in OpenSRF "don't require mod_perl as an OpenSRF dependency" [Wishlist,New] https://launchpad.net/bugs/1579219 |
| 16:26 |
|
kmlussier joined #evergreen |
| 16:30 |
Dyrcona |
Oof.. Factor of ten error at 04:12:32... That should be 1.4% |
| 16:30 |
Dyrcona |
It has been a long couple of weeks.... |
| 16:43 |
Dyrcona |
Hey! My parallel ingest finished after 55 hours and 9 minutes! |
| 16:44 |
bshum |
Huzzah! |
| 16:44 |
Dyrcona |
It's really not a good idea to have the database all on one hard drive. |
| 16:44 |
Dyrcona |
Use a RAID setup. |
| 16:44 |
jeff |
one point twenty-one gigaWALs! |
| 16:45 |
Dyrcona |
heh |
| 16:45 |
jihpringle |
kmlussier: if you're around and have time could you check your 2.9 community test server? it's giving me "There was an error testing this hostname" |
| 16:46 |
kmlussier |
jihpringle: You made need to add an SSL exception. |
| 16:48 |
|
jihpringle_ joined #evergreen |
| 16:48 |
* jeff |
cringes |
| 16:49 |
kmlussier |
jihpringle: Hmm, actually, it looks like something else is going wrong with it. I'll fix it up. |
| 16:54 |
jihpringle |
kmlussier: thanks :) |
| 17:01 |
jeffdavis |
Anyone else seeing an issue in 2.10 where any password entered during new patron registration in the XUL client does not work on OPAC login? (Changing the password of an existing patron seems to work fine.) |
| 17:06 |
jeffdavis |
ah, I see we've already reported it: bug 1579225 |
| 17:06 |
pinesol_green |
Launchpad bug 1579225 in Evergreen "Patron registration- unable to log in with password entered during registration" [Undecided,New] https://launchpad.net/bugs/1579225 |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
kmlussier |
jihpringle: Give it a try now. |
| 17:13 |
kmlussier |
jihpringle: With a new client. |
| 17:16 |
jihpringle |
kmlussier: when I follow the link to clients tow download a new client and chose the Windows option it's telling me Not Found "The requested URL /updates/clients/2016.03mlnc4.14.104301_setup.exe was not found on this server." |
| 17:17 |
kmlussier |
jihpringle: You need to refresh the page with the clients. It's still bringing you to the old client. Happens to me all the time. :) |
| 17:19 |
jihpringle |
I'm in |
| 17:19 |
jihpringle |
Thanks kmlussier++ |
| 17:19 |
kmlussier |
Huzzah! |
| 17:19 |
kmlussier |
jihpringle++ |
| 17:20 |
kmlussier |
Looks like the server had that problem since the last time I updated it. I appreciate you telling me about it. :) |
| 17:23 |
jihpringle |
you're welcome and thanks for fixing. I've now been able to confirm a bug is definitely new in 2.10 |
| 17:33 |
kmlussier |
I wonder if work on the Angular patron editor may have leaked into the xul client and caused the issue with bug 1579225 |
| 17:33 |
pinesol_green |
Launchpad bug 1579225 in Evergreen "Patron registration- unable to log in with password entered during registration" [Undecided,New] https://launchpad.net/bugs/1579225 |
| 17:34 |
gmcharlt |
jihpringle: roughly when did you test it on the ESI community demo? (I want to check logs) |
| 17:35 |
jihpringle |
gmcharlt: around 1:37pm PDT |
| 17:36 |
gmcharlt |
thanks |
| 17:36 |
dbwells |
Being related to the new password hashing infrastructure would also be a good bet. |
| 17:36 |
jihpringle |
and around 1:51pm PDT for the web client |
| 17:36 |
kmlussier |
dbwells: Yes, I was just remembering that's new too. |
| 17:41 |
* gmcharlt |
takes a look |
| 17:42 |
gmcharlt |
test record: a cat with poor password hygiene |
| 17:58 |
|
jihpringle joined #evergreen |
| 18:18 |
|
jlitrell joined #evergreen |
| 18:26 |
gmcharlt |
yep, it's the password hashing |
| 18:26 |
gmcharlt |
during registration, the hashed password is getting set to CRYPT( MD5( pw_salt || MD5(MD5(real_password)) ), pw_salt ) |
| 18:26 |
gmcharlt |
when comparisons are expecting CRYPT( MD5( pw_salt || MD5(real_password) ), pw_salt ) |
| 18:27 |
gmcharlt |
I'll poke more after dinner |
| 18:30 |
gmcharlt |
ok, seeing more: during the open-ils.actor.patron.update dance, a new actor.usr is created |
| 18:30 |
gmcharlt |
the password trigger on actor.usr sets au.passwd to md5(real_password) |
| 18:31 |
gmcharlt |
*then*, the new row gets retrieved and passed on to the rest of the process, including a call to actor.set_passwd |
| 18:31 |
gmcharlt |
and that's where the extraneous md5 is coming from |
| 18:31 |
gmcharlt |
more anon |
| 18:43 |
Christineb |
gmcharlt++ thank you for investigating |
| 19:41 |
|
brahmina joined #evergreen |
| 20:58 |
|
sandbergja joined #evergreen |
| 21:48 |
gmcharlt |
@later tell berick I'd appreciate your eyes on 1579225 |
| 21:48 |
pinesol_green |
gmcharlt: The operation succeeded. |
| 21:48 |
gmcharlt |
dbwells: ^^ |
