| Time |
Nick |
Message |
| 01:05 |
|
Keith__isl joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
brettgilio joined #evergreen |
| 07:23 |
|
mantis joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:43 |
|
rfrasur joined #evergreen |
| 08:49 |
|
dguarrac joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
jvwoolf joined #evergreen |
| 09:27 |
Dyrcona |
So, for those following along (or not), I have run my db upgrade script on Pg 9.6, Pg 10, and Pg 11 so far. This includes a partial ingest of record attributes for MARC item type g. |
| 09:31 |
Dyrcona |
It took 28 hours 48 minutes on Pg 9.6. On Pg 10, it ran for 25 hours 3minutes. Pg 11 finished after 12 hours 7 minutes. This is with the db being "optimized" and the server rebooted in between each configuration change. |
| 09:31 |
berick |
pg11 FTW |
| 09:32 |
Dyrcona |
I probably won't get around to "testing" Pg 12 and Pg 13 until next week. I want to restore the configuration for Pg 10 for an automated production restore over the weekend. |
| 09:32 |
Dyrcona |
Yeah, my experience is newer Pg releases are faster over all, but some specific things have degraded performance. |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:35 |
Dyrcona |
I'm doing the full did you mean setup at the moment. I have a script that I run with time to get the timing of it. I thought about just using the files generated from the first process since they should be all the same, but that wouldn't quite be fair. |
| 09:37 |
Dyrcona |
That process took just about 4 hours (minus 2 or 3 minutes) on both Pg 9.6 and Pg 10, so it will be interesting to see the time for Pg 11. |
| 09:38 |
Dyrcona |
I may do all of this again if we get the bad drive replaced. |
| 09:43 |
Dyrcona |
Hmm. I may get to testing Pg 12 today after all. Pg 11 seems to be ripping right through the DYM stuff. |
| 09:45 |
Dyrcona |
66GB in cache.... |
| 09:45 |
|
mantis joined #evergreen |
| 09:49 |
berick |
too bad you can't do them all at once, we could take bets. |
| 09:49 |
berick |
my kind of olympics |
| 09:50 |
Dyrcona |
ha! |
| 09:51 |
* alynn26 |
laughs |
| 09:52 |
mantis |
We have some libraries reporting that sometimes when printing receipts in the self check, it gets hung up on loading and doesn't print. |
| 09:52 |
mantis |
Is that a problem more so with the connection than evergreen? |
| 09:56 |
mmorgan |
mantis: The self check receipts are action triggers, have you checked that the events completed? |
| 10:01 |
Dyrcona |
I was thinking, again, this morning that we do some things via action trigger that should probably not be. I'm not so sure about receipt printing, but basically anything that the user expects to be done immediately should probably just be done in the code and not handed off to a/t. |
| 10:02 |
Dyrcona |
Not helpful to the immediate question, I know, but I was mucking about with a/t in two ways yesterday. |
| 10:04 |
Dyrcona |
berick: I'm just going to delete the line that creates the events for the au.create.ecard hook in the Quipu branch. I know you use it, but I don't see how we can add something universal for that when it seems that every site does printing in a different way. |
| 10:04 |
mmorgan |
Interestingly, I had a report yesterday of a hold slip that would not print in the client. |
| 10:05 |
berick |
Dyrcona: well, don't worry about me. however, the line's not hurting anything and could be useful for those that want it down the road |
| 10:06 |
Dyrcona |
berick: Yeah, I thought of just leaving it because nothing happens. I could just add a comment saying it does nothing but could be used to set up some local verification or other notifications. |
| 10:06 |
berick |
comment++ |
| 10:06 |
Dyrcona |
berick++ |
| 10:06 |
Dyrcona |
I'll add the comment. |
| 10:09 |
eby |
Dyrcona: If there was a setting so you could set any A/T to complete immediately vs wait for the runner script it would probably solve most of the use cases we have |
| 10:10 |
berick |
printing receipts typically happens in real time and doesn't wait for the runner |
| 10:10 |
berick |
but also note we have server print templates now, which will replace A/T print templates over time |
| 10:13 |
Dyrcona |
Speaking of A/T, nagios just sent me this: CRITICAL: 2144 AT events pending |
| 10:13 |
Dyrcona |
I'll check but it's pretty much always hold notifications at this time of day. |
| 10:13 |
mantis |
mmorgan: I'll look into that thanks! |
| 10:14 |
Dyrcona |
I will say, A/T is pretty cool. |
| 10:16 |
Dyrcona |
Yeah, hold ready for pickup and curbside events that haven't reached their delay time. |
| 10:17 |
mantis |
mmorgan: what's your processing delay for your self check receipts? |
| 10:20 |
mmorgan |
mantis: I'ts 00:05:00, but as others have mentioned, the print-on-demand triggers don't use the delay. |
| 10:21 |
mmorgan |
I was thinking maybe there could be an error when processing the template. |
| 10:22 |
mantis |
I'll run it with the console up and see what comes up |
| 10:24 |
Dyrcona |
mantis: I'd suggest checking action_trigger.event for whatever the event_def id is to see if the event was even created and what state it is in. |
| 10:25 |
Dyrcona |
That reminds me that I should check the logs again related to my import items ramblings from yesterday. |
| 10:25 |
mantis |
Dyrcona: the issue with us is this is a CONS level AT so tracking down the specific org unit/action I think will be tricky |
| 10:25 |
mantis |
Drycona: do you have yours set up by individual libraries? |
| 10:26 |
Dyrcona |
mantis: If you know the rough time that helps. We don't have many sites using the Evergreen self check. Most of our self-checks use SIP2. |
| 10:28 |
Dyrcona |
I'll see if we have any self-check receipt events while I'm poking around at action_trigger.event. (I suspect we might have had a failure to create a CSV download event on Tuesday and/or yesterday.) |
| 10:33 |
Dyrcona |
We have more self check receipt events than I expected. |
| 10:33 |
mantis |
Dyrcona: Yeah for us we have a lot of people using the Evergreen self check |
| 10:33 |
mantis |
Hopefully when I do a remote call live with the library, I can narrow it down |
| 10:35 |
|
Keith-isl joined #evergreen |
| 10:35 |
mantis |
Er well I did just limit to != 'complete' and I only have a few that are in 'validating' status |
| 10:35 |
mantis |
These are from 2016 |
| 10:36 |
Dyrcona |
mantis: If your template includes some information about the library, you could possibly find them. Or template doesn't. I'm not sure if we modified the stock template, but I don't think so. |
| 10:36 |
Dyrcona |
We started clearing old events last year. We only keep 6 months of events in the table. |
| 10:37 |
Dyrcona |
"Or template" should have been "Our template," just in case anyone was confused. |
| 10:37 |
mmorgan |
mantis: We have some customized self check triggers for libraries, others use the default one. |
| 10:37 |
Dyrcona |
Hmm... Maybe it was 2019....That's still "last year," right? :) |
| 10:38 |
mmorgan |
:) |
| 10:38 |
Dyrcona |
We try to avoid customized triggers because we fear constantly making changes, but it makes sense for receipts and some other things. |
| 10:39 |
Dyrcona |
Also, 150 event definitions for the same thing isn't much fun to manage. |
| 10:41 |
mmorgan |
mantis: Do you know patron or item for a receipt that didn't print? The target of the action_trigger event would be the circ id. |
| 10:41 |
Dyrcona |
I kind of wish we'd added the library name to the self-check receipt template. Then, I could get a feel for how many libraries are using it. |
| 10:42 |
Dyrcona |
Our receipt has the patron name in it. |
| 10:43 |
mmorgan |
Dyrcona: We require workstations for selfcheck, and ws names include "selfcheck" so we have a couple of ways to count. |
| 10:43 |
Dyrcona |
Oh, I suspect we have something like that. I've not really thought about it before today. |
| 10:44 |
Dyrcona |
I'm sure that our members want that for statistics/reports. |
| 10:45 |
Dyrcona |
Well, it looks like I was wrong about events not being created. I have the CSV events that I thought might be missing, and they're all "complete." |
| 10:45 |
Dyrcona |
a/t++ |
| 11:12 |
|
mmorgan joined #evergreen |
| 11:16 |
mantis |
mmorgan: I'm asking them for a more detailed log this time. I was only given a log of times when it doesn't work. |
| 11:17 |
mantis |
Another thing is that particular library has a Star printer which I know has issues corresponding to Windows 10 so I sent them the updated driver for install |
| 11:17 |
mantis |
The other library that's also having this problem however uses an EPSON |
| 11:17 |
mantis |
I'll be in touch when I find out more info |
| 12:08 |
|
jihpringle joined #evergreen |
| 13:49 |
Dyrcona |
Well, Pg 11 didn't make much difference for the did you mean setup. It finished only about 2 minutes faster than Pg 9.6. I think that's because the process spends most of its time reading and writing data files with Perl. |
| 14:33 |
|
stephengwills joined #evergreen |
| 15:24 |
Dyrcona |
berick: Do I have to md5 hash the password before using AppUtils::verify_user_password? I'm getting 0 when I try to verify either of the passwords on my test account. |
| 15:29 |
Dyrcona |
Apparently, I have to do more than that because the database function fails with the correct information. |
| 15:30 |
* Dyrcona |
looks at how open-ils.auth does it, again. |
| 15:33 |
berick |
Dyrcona: verify_user_password assumes non-md5'ed passwords. verify_migrated_user_password assumes md5-hashed passwords. |
| 15:33 |
Dyrcona |
berick: It aint' workin' with known good passwords. |
| 15:36 |
Dyrcona |
I'm trying it with this: https://pastebin.com/HQMCJPVg |
| 15:41 |
berick |
Dyrcona: my instinct would be to see what sql that is producing |
| 15:42 |
berick |
specifically the call to actor.verify_passwd(...) |
| 15:42 |
Dyrcona |
I have run the sql, and it doesn't verify. |
| 15:42 |
berick |
ok so it's not the perl |
| 15:43 |
Dyrcona |
I just tried verify_migrated_user_password with my main password and as_md5 set to 0, so it should have done the "magic" for me, but it didn't work, either. |
| 15:43 |
Dyrcona |
When I added an ecard_vendor password to my account, should I not have salted it? |
| 15:44 |
|
jvwoolf left #evergreen |
| 15:46 |
berick |
the salting happens automatically w/ actor.set_passwd |
| 15:46 |
Dyrcona |
Yeah, I see that, but how am I supposed to verify a raw password? It seems I have to look up the salt, first. |
| 15:47 |
stephengwills |
does someone have a link to a sample bash startup script for evergreen or is that too custom a thing? |
| 15:49 |
Dyrcona |
stephengwills: I've heard of such things. JBoyer may have had some at one point. If you're using bricks with multiple servers for drones, it can get tricky to start things up in the proper order. |
| 15:51 |
Dyrcona |
berick: FWIW, I'm trying to figure out how to set up the Quipu ecard_vendor account and passwd. |
| 15:52 |
berick |
Dyrcona: $U->verify_user_password($e, $user->id(), $pass, $type); -- put $type in front of $pass |
| 15:52 |
berick |
well, wait on that |
| 15:52 |
berick |
i was looking at the raw sql |
| 15:52 |
berick |
so this works for me on my SIP2 mediator branch: |
| 15:52 |
berick |
select actor.verify_passwd(1, 'sip2', 'demo123'); |
| 15:54 |
berick |
Dyrcona: what does your ecard_vendor actor.passwd_type look like? |
| 15:55 |
berick |
https://gist.github.com/berick/052b82b0563f16fd6218c300bb43188c |
| 15:55 |
berick |
mine |
| 15:55 |
Dyrcona |
berick: switching password and type looks wrong given the actor.verify_passwd signature and the code in AppUtils.pm. |
| 15:56 |
berick |
Dyrcona: right, your code is fine, it's just the sql that's different -- but the apputils code accounts for that |
| 15:56 |
Dyrcona |
berick: I accounted for that with my tests. |
| 15:57 |
Dyrcona |
Hey! patebot! You here? |
| 15:57 |
Dyrcona |
pastebot, even... |
| 15:58 |
Dyrcona |
http://paste.evergreen-ils.org/14413 |
| 15:58 |
Dyrcona |
It looks just like main, and to be honest, I don't know where it came from. I'll have to check. |
| 15:58 |
Dyrcona |
But, I can't my main password to verify, either, so I'm doing something wrong.... |
| 16:01 |
Dyrcona |
OK. It's coming from the upgrade script in the branch. |
| 16:05 |
berick |
not a big deal yet since it's not fully supported, but 'login' should be set to false on that |
| 16:06 |
berick |
to indicate it cannot be used to create a real authtoken |
| 16:06 |
berick |
Dyrcona: also, how did you set the password for your ecard account? |
| 16:07 |
berick |
it has to be done in the database directly |
| 16:09 |
Dyrcona |
berick: Yes. I got it to work. By just doing actor.set_passwd() and not using my custom function. I still don't get why verify migrated password fails for my main password. I'm gonna play with that a little more. |
| 16:09 |
Dyrcona |
I was setting the password in the database, just incorrectly, for the record. |
| 16:09 |
Dyrcona |
I also changed the ecard_vendor entry to match berick's. I'll modify the upgrade script. |
| 16:10 |
berick |
cool |
| 16:10 |
Dyrcona |
I think I'll fix my custom function and try again. |
| 16:14 |
Dyrcona |
berick++ |
| 16:15 |
Dyrcona |
All right, my custom function appears to be fixed. |
| 16:27 |
Dyrcona |
typos-- :) |
| 16:28 |
Dyrcona |
Too many os, 0s, and uppercase vs. lowercase typos. :) |
| 16:28 |
Dyrcona |
IOW, it helps to use the correct password when trying to verify it. :) |
| 16:31 |
mmorgan |
Never hurts to test the wrong password, too, to make sure it's not verifying inapproriately :) |
| 16:32 |
Dyrcona |
Well, that's true. |
| 16:32 |
jeff |
yes. |
| 16:33 |
jeff |
Dropbox learned that lesson in a very public fashion in 2011. :-) |
| 16:35 |
Dyrcona |
Grr... Git problems.... |
| 16:36 |
Dyrcona |
Well, simple git problems.... Just had to reset. |
| 16:37 |
Dyrcona |
I often think that I have too many branches.... |
| 16:37 |
Dyrcona |
I should do something about that, but IDK what's worse, lots of small branches or 1 giant branch. |
| 16:48 |
JBoyer |
stephengwills, Sorry I missed this earlier, but I do have systemd service units for most bits of Evergreen: https://github.com/HitScan/systemd-evergreen |
| 16:49 |
JBoyer |
Note that they work fine on a single server installation but like Dyrcona mentioned, if you have things spread out (more likely on production) they would require some tweaking. |
| 16:50 |
JBoyer |
And they require enough tweaking that I haven't tried getting them into Evergreen proper yet. |
| 16:50 |
stephengwills |
cool, thanks. I assumed I would have to customize. maybe get some messaging happening or something? |
| 16:50 |
JBoyer |
(Also, Evergreen could stand to learn some things about re-trying network connections when dropped or not yet ready...) |
| 16:52 |
JBoyer |
They're largely good to go as-is, but things like Requires and BindsTo are too strict if you have things spread out. No point running Nginx on your bricks, for instance. |
| 16:53 |
Dyrcona |
Well, systemd can also replace inetd, so if we want to go that far..... |
| 16:54 |
JBoyer |
We do not. ;p |
| 16:54 |
JBoyer |
My comment re: networks was about things that are outgoing, not incoming |
| 16:54 |
Dyrcona |
:) |
| 16:55 |
Dyrcona |
Yeah, I've been poking at our not connected to the network and most of 'em look like clients, i.e. someone closed the browser tab or navigated away. |
| 16:55 |
Dyrcona |
Very few say "drone." |
| 16:58 |
* Dyrcona |
calls it a day. Thanks, everyone! |
| 17:22 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:59 |
|
stephengwills left #evergreen |
