| Time |
Nick |
Message |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
JBoyer joined #evergreen |
| 07:25 |
|
agoben joined #evergreen |
| 08:03 |
|
Dyrcona joined #evergreen |
| 08:30 |
|
collum joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:49 |
Dyrcona |
Nice. Got a record that throws a 500 internal server error every time you load it, but I don't see anything obviously wrong with the MARC. |
| 09:02 |
JBoyer |
Dyrcona, sounds like a great record. Want to share? |
| 09:02 |
Dyrcona |
Maybe in a bit. I'm being bombarded with issues. |
| 09:03 |
mmorgan |
Dyrcona: Merry Christmas! |
| 09:03 |
Dyrcona |
I'm not so sure it's the record itself. Trouble is, I'm not finding any errors in the logs. |
| 09:12 |
|
jvwoolf joined #evergreen |
| 09:13 |
Dyrcona |
And I've got bigger problems..... |
| 09:15 |
Dyrcona |
At least the db is not in recovery mode.... ;) |
| 09:15 |
|
abneiman joined #evergreen |
| 09:22 |
Dyrcona |
24,000 pending a/t triggers.... :/ |
| 09:23 |
mmorgan |
:-( |
| 09:29 |
Dyrcona |
So, password reset has been running a long time. I killed it. It started right back up. |
| 09:30 |
Dyrcona |
Does that block the other action trigger runners? I haven't seen any others running since password reset started. |
| 09:33 |
* Dyrcona |
cranks up the "Bad Attraction" by Brad Sucks. |
| 09:34 |
* mmorgan |
does not think password reset should block other triggers. |
| 09:37 |
|
rhamby joined #evergreen |
| 09:38 |
* Dyrcona |
wonders why other a/ts are not running. They're configured in crontab. |
| 09:42 |
* rhamby |
wonders in a non-helpful suggestion if the server gremlins are objecting to not getting Holiday gingerbread and that's why a/ts aren't running. |
| 09:48 |
Dyrcona |
There were reports of a 15-minute outage on the 23rd (or so I hear), but everything looks "normal." |
| 09:48 |
* Dyrcona |
has asked for the exact time of this outage. |
| 09:49 |
* Dyrcona |
suspects something happened at the colo facility. |
| 09:50 |
Dyrcona |
Lots of cstore errors. |
| 09:51 |
Dyrcona |
Sweet! * open-ils.cstore [1950] uptime=54-21:30:45 cputime=13:58:27 #drones=60 |
| 09:51 |
Dyrcona |
The server that runs a/t has hit max cstore dronage. |
| 09:56 |
|
dteston joined #evergreen |
| 09:56 |
|
dteston joined #evergreen |
| 10:01 |
Dyrcona |
Maybe I just needed to restart services rather than change the configuration, but oh well.. |
| 10:04 |
Dyrcona |
Well, guess it'll take a while to catch up. |
| 10:06 |
dteston |
We are preparing to upgrade to 2.11 and I'm seeing something weird. When we update any password, the DB stores the same hash as any other password. For example, '1234' and '5678' yield the same hash. Does anyone know what might be happening? |
| 10:09 |
Dyrcona |
dteston: You're upgrading from what version? |
| 10:10 |
dteston |
Dyrcona: 2.9 |
| 10:10 |
Dyrcona |
There were lots of changes to auth in 2.10. I'm not sure if that is part of it, but berick would know the details. |
| 10:11 |
Dyrcona |
I'm not so sure the hashes are used any more, for instance. |
| 10:13 |
dteston |
Dyrcona: I vaguely remember berick saying it changed from MD5 to bcrypt. Users can still log in with the correct information, but I don't know how that's possible since the DB shows the same value. |
| 10:14 |
berick |
dteston: the password values have been moved to a new table. actor.passwd. the old hash values are unused |
| 10:14 |
berick |
and all set to "" |
| 10:14 |
berick |
well, md5("") |
| 10:14 |
Dyrcona |
berick++ |
| 10:15 |
berick |
dropping the actor.usr.passwd column is on my todo list in part to avoid this kind of confusion |
| 10:16 |
Dyrcona |
open-ils.cstore: Invalid predicate structure: null |
| 10:16 |
Dyrcona |
Just lovely, that. ;) |
| 10:16 |
dteston |
berick: That makes sense - thank you for the explanation. |
| 10:17 |
dteston |
berick: where is the code that updates the password when the user logs in for the first time? |
| 10:17 |
berick |
dteston: actor.migrate_passwd |
| 10:17 |
berick |
db function |
| 10:20 |
dteston |
berick: Thanks |
| 10:23 |
|
akilsdonk joined #evergreen |
| 10:25 |
|
krvmga joined #evergreen |
| 10:28 |
Dyrcona |
Hm... a/t runner seems to be doing something now.... |
| 10:28 |
Dyrcona |
I ran it manually. |
| 10:29 |
Dyrcona |
Or, maybe not.... :( |
| 10:31 |
mmorgan |
Dyrcona: a/t still not running after restarting services? |
| 10:31 |
Dyrcona |
Well, it "runs" but does nothing. I think the message is too big or times out, but logs haven't turned up much, yet. |
| 10:32 |
Dyrcona |
I'm going to check ejabberd logs. |
| 10:36 |
mmorgan |
Do you have granularity set for some triggers? |
| 10:36 |
Dyrcona |
Some, yes, and those trigger runners run. |
| 10:37 |
Dyrcona |
But still not sure if they do anything. |
| 10:37 |
Dyrcona |
And, so far nothing useful in the logs. It's like it looks up what to do and there's nothing to do, so it shuts down. |
| 10:38 |
Dyrcona |
Oh! Look at that. Not everything is being sent to syslog. There are some stderr logs in /openils/var/log. |
| 10:39 |
Dyrcona |
Of course, there's no indication of what application caused the errors. |
| 10:44 |
* mmorgan |
wonders if setting a granularity in the event defs without one and attemptging to run each individually would reaveal anything... |
| 10:46 |
Dyrcona |
I've tried running the daily granularity jobs and nothing happens. It starts and stops like there's nothing to do and there are thousands of pending events. |
| 10:47 |
berick |
Dyrcona: the pending events have a run_time < now() ? |
| 10:47 |
Dyrcona |
24,560 of them do. |
| 10:48 |
Dyrcona |
The other 1,000 or so, no. |
| 10:49 |
mmorgan |
Dyrcona: are there events where state != 'pending' and != 'complete'? |
| 10:50 |
Dyrcona |
mmorgan: I didn't look. I've looked at pending events. |
| 10:50 |
berick |
stranded A/T runner lock files? |
| 10:51 |
* mmorgan |
is grasping at straws wondering if there's an event stuck in some state that's derailing the process. |
| 10:52 |
Dyrcona |
berick: No. I've been checking that. It's like it runs and says "nothing to do." |
| 10:52 |
Dyrcona |
And, that query is taking a long time. must be a table scan. |
| 10:53 |
Dyrcona |
looking for state not pending and not complete, i mean. |
| 10:54 |
Dyrcona |
Apparently there are lots of them, but I didn't change my query enough to pull the state. |
| 10:55 |
mmorgan |
Dyrcona: Is the server time correct? |
| 10:56 |
Dyrcona |
mmorgan: Yes and yes. :) |
| 10:56 |
Dyrcona |
The util server and the db agree on the time. Both running ntp. |
| 10:57 |
Dyrcona |
I think maybe 25,000 events is just too much. |
| 10:59 |
Dyrcona |
mmorgan: 9829005 invalid events, all of them from last July. |
| 10:59 |
Dyrcona |
Don't think that's it. |
| 11:00 |
* mmorgan |
would agree ;-) |
| 11:01 |
Dyrcona |
Ok. It looks like the ones with no granularity are being handled OK. |
| 11:02 |
Dyrcona |
I just looked at those and based on add_time, run_time, and system clock and crontab schedule. They look OK. |
| 11:02 |
berick |
should be able to see in the logs if the cstore query to grab the events is timing out waiting.. would be ~60 second gap between the query and the "got 0 results" message |
| 11:03 |
Dyrcona |
berick: I tooked for timeout messages, but not got 0 results. I'll remember that one. |
| 11:03 |
Dyrcona |
Looks like it is working, I just have thousands of pending granularity events, that I think should have run last night. |
| 11:05 |
Dyrcona |
I have a bunch of pull list events from November. Should I do anything to mark them invalid or something? |
| 11:06 |
Dyrcona |
And May... Looks like times we had db trouble or something else was happening. |
| 11:07 |
Dyrcona |
Will the granularity events get picked up when that cron job runs tonight? Looks likes some from yesterday morning and this morning sitting there. |
| 11:08 |
* mmorgan |
thinks it depends on the max validity in the event def whether they will get picked up next time the job runs. |
| 11:08 |
|
sarabee joined #evergreen |
| 11:11 |
* Dyrcona |
checks that. |
| 11:13 |
Dyrcona |
You mean max_delay? |
| 11:14 |
Dyrcona |
Anyone know a trick to get the 2-day courtesy notices out? |
| 11:15 |
mmorgan |
Dyrcona: Yes, looks like the column name is max_delay |
| 11:16 |
Dyrcona |
yeah. So most of those look OK, except pre-overdue notices. |
| 11:16 |
berick |
max_delay would prevent the events from being created in the first place |
| 11:17 |
Dyrcona |
I'm running that granularity manually to see if it works. |
| 11:17 |
mmorgan |
Our 2 day courtesy notices have their own granularity, so we can run them with a granularity-only command |
| 11:19 |
mmorgan |
berick: so if an event is already pending, and is outside of max_delay, would it still process? |
| 11:23 |
berick |
mmorgan: yep, max_delay is only used for event creation |
| 11:24 |
Dyrcona |
Well, I did that, but I botched it. Guess folks will just have to deal with the complaints of patrons getting multiple notices. |
| 11:25 |
mmorgan |
So Dyrcona's pending events will process next time the job runs. |
| 11:28 |
mmorgan |
2 notices are better than no notices ;-) |
| 11:29 |
Dyrcona |
Well, yes. |
| 11:52 |
dteston |
berick: how does the DB know when it needs to call actor.migrate_passwd? |
| 11:54 |
dbs |
dteston: http://docs.evergreen-ils.org/2.10/_administration.html#_improved_password_management_and_authentication is a good starting point for the new auth info |
| 11:56 |
berick |
dteston: actor.verify_passwd() => actor.get_salt() will migrate old passwords as needed. |
| 11:56 |
dbs |
actor.get_salt() function in the DB notices when the password hasn't been migrated and does the migration |
| 11:56 |
berick |
jinx |
| 12:00 |
_bott_ |
The new authenticate.init doesn't seem to like a usrname that begins with a numeral |
| 12:02 |
dteston |
berick: dbs: thanks. |
| 12:03 |
berick |
_bott_: the barcode-vs-username check had to be moved into authenticate.init along with the rest of the password stuff. it still honors the opac.barcode_regex AOUS, though. |
| 12:04 |
berick |
_bott_: if no opac.barcode_regex setting is available (at the global level), then it falls back to the old opac-style "if it starts w/ a number it's a barcode" logic |
| 12:04 |
_bott_ |
wow, you guessed my next question! |
| 12:05 |
_bott_ |
berick:++ for mind reading |
| 12:15 |
|
bmills joined #evergreen |
| 13:25 |
|
bmills joined #evergreen |
| 13:51 |
Dyrcona |
So, the 500 error was a biblio.peer_bib_copy_map to a deleted/precat copy. |
| 13:51 |
Dyrcona |
Nothing in the logs could really help with that. |
| 13:51 |
Dyrcona |
I found the 500 in the access log, but the apache error log did not have the usual entry with the error message. |
| 13:52 |
Dyrcona |
Thanks to a suggestion from tsbere and a message in osrfsys.log about looking up the peer_bib_copy_map, I was able to sort it out. |
| 14:17 |
dteston |
Is there any part during the login process in 2.11 where the password is displayed in plain-text? |
| 14:18 |
Dyrcona |
dteston: You mean to the patron? |
| 14:18 |
dteston |
Dyrcona: no, on the server side |
| 14:19 |
Dyrcona |
dteston: What do you mean by "displayed?" It isn't logged or stored in the database in plain text. |
| 14:19 |
tsbere |
dteston: I think you really need to go a different route with your wifi access. :P |
| 14:19 |
Dyrcona |
heh |
| 14:20 |
Dyrcona |
dteston: I think the answer to your question is, "No." ;) |
| 14:20 |
dteston |
Dyrcona: exactly, and I don't want it to be stored - I just need access to it long enough to NTLM hash it and copy it to the wifi server. |
| 14:20 |
Dyrcona |
No. |
| 14:20 |
Dyrcona |
:) |
| 14:20 |
* Dyrcona |
agrees with tsbere. |
| 14:21 |
dteston |
Dyrcona: tsbere: there has to be a way to make this work properly - just a matter of how. |
| 14:22 |
tsbere |
dteston: To be honest, I think you should focus on getting the wifi system to talk to Evergreen, not the other way around. |
| 14:22 |
Dyrcona |
dteston: Yes, if you can add a module to your wifi access to authenticate against Evergreen. |
| 14:22 |
Dyrcona |
:) |
| 14:23 |
Dyrcona |
There's an auth_proxy module in Apache configs you might be able to use, or a SIP2 client.... |
| 14:23 |
berick |
also beware there's more than one way to log in to EG and in some of those ways (e.g. logging into staff client), the bare password never touches the server, because it goes through a preliminary hashing at the client. |
| 14:24 |
tsbere |
dteston: I was working on a perl module to log into Evergreen without needing Evergreen installed at a hackaway: http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/tsbere/remoteauth |
| 14:27 |
dteston |
Dyrcona: tsbere: I |
| 14:27 |
dteston |
would love to authenticate against EG |
| 14:27 |
dteston |
tsbere: thanks for the link |
| 14:28 |
|
mmorgan joined #evergreen |
| 14:29 |
dteston |
Dyrcona: tsbere: there are some protocol compatibility issues that prohibit using MD5 and salts, so it'll have to be a custom module |
| 14:30 |
tsbere |
dteston: Well, if you can use perl you have something that I just linked you to that can be used as a base. ;) |
| 14:32 |
dteston |
tsbere: browsing it now - thanks again |
| 14:33 |
Dyrcona |
If I forgot to do granularity only on an action trigger runner, though I did specify a granularity, is it going to just keep on running even though it looks like the events are all cleared in action_trigger.event? |
| 14:34 |
tsbere |
I think it may grab the non-granularity events in addition to the one you specified.....maybe? |
| 14:35 |
Dyrcona |
It doesnt' seem to be doing anything, just using up 1% of cpu. |
| 14:37 |
Dyrcona |
I'm wondering if I should just kill it or not. |
| 14:38 |
Dyrcona |
There are a bunch of events that are collected. |
| 14:38 |
Dyrcona |
I guess I should wait for those to complete. |
| 14:52 |
Dyrcona |
Looks like it is still doing its thing. |
| 15:55 |
|
bmills joined #evergreen |
| 16:00 |
|
jvwoolf left #evergreen |
| 16:42 |
|
bmills joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 19:12 |
|
miker joined #evergreen |
| 21:31 |
|
_bott_ joined #evergreen |
