| Time |
Nick |
Message |
| 04:28 |
|
beardicus7 joined #evergreen |
| 04:49 |
|
beardicus5 joined #evergreen |
| 05:13 |
|
beardicus9 joined #evergreen |
| 06:39 |
|
beardicus joined #evergreen |
| 07:39 |
|
beardicus5 joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
mmorgan joined #evergreen |
| 11:01 |
|
Christineb joined #evergreen |
| 11:15 |
goood |
Dyrcona: fwiw, test-json-query.c isn't going to help you. I suspect you might want to take a look at Open-ILS/examples/reporter-sql-builder-test.pl ... but, really, if you can't see the output, the output is gone and you'd have to run it again anyway? the debug output is generated with every report run. just get the blah.html.debug.html from the output dir (but, as you see now, the output has been removed...) |
| 11:17 |
Dyrcona |
goood: There was no output because the queries timed out. I'm not looking into it right, but I will take a look at reporter-sql-builder-test.pl. I did come to the conclusion on Friday, that I probably could not recreate the queries entirely on my own. |
| 11:18 |
Dyrcona |
^right^right now^ |
| 11:20 |
goood |
I see. luckily, the code to do that is simple, see the bottom of Open-ILS/examples/reporter-sql-builder-test.pl. the $report in there is the data column from reporter.template, and $params is the data from reporter.report. you'll want to look at how clark injects the relative run time and runner variable and stuff, but it's pretty simple. that script shows how to parse the data and dump the top-level sql |
| 11:23 |
goood |
perhaps a good wishlist LP would be to generate the debug output regardless of whether the report completes. that's probably just an oversight from 20 years ago. should be a bitesize bug, really. |
| 11:39 |
Dyrcona |
Today, I am dealing with EDI fetcher issues. |
| 11:39 |
jeff |
goood++ I think I was thinking of that and said the other. Oops! Thanks! |
| 11:40 |
Dyrcona |
jeff: I was looking at test-json-query, too. |
| 11:41 |
jeff |
good deal. sorry if my mis-recommendation wasted any of your time! :-) |
| 11:41 |
Dyrcona |
I'm getting the impression that Ingram just doesn't like us. |
| 11:41 |
goood |
jeff: there are, like, 17 different "this turns data into SQL" things floating around inside EG, some superseding others, so def no worries. ;) |
| 11:42 |
Dyrcona |
Yeah. I at least learned what wouldn't work. My next plan was to see what the reporter does, but other things have come up. |
| 11:44 |
jeff |
good outlook. very thomas edison "I've just found 10,000 ways that won't work." |
| 11:45 |
goood |
Dyrcona: oooohhhhh... we've had to reset passwords (or, more likely, have the libraries call and reset them) what seems like randomly, recently. fetcher just locks up when sftp fails due to a PW mishap. if a manual test of sftp with the in-db creds fails, you might need to call ingram for a pw reset |
| 11:46 |
Dyrcona |
goood: I have accounts from two different libraries not working. There's a Lp bug about the fetcher locking up. I filed it but haven't gotten around to trying to fix it: https://bugs.launchpad.net/evergreen/+bug/2060702 |
| 11:48 |
Dyrcona |
Guess I could work on some fetcher bugs this week. |
| 11:48 |
goood |
that's a good bug to fix ... but why are the passwords changing? (I'm pretty sure they are, in fact, changing. presumbably-old accounts are seeing this happen) |
| 11:48 |
goood |
IOW, I think there's an ingram issue there, too |
| 11:49 |
Dyrcona |
One of the staff reported that they had trouble logging into their account (I assume it was on the Ingram site) when this started happening last week. I'm getting that second hand or third if you count it was a ticket update. |
| 12:39 |
jeff |
from a message to the evergreen-acq list just now, it sounds like Ingram is experiencing an "out of an abundance of caution" event: "As part of our ongoing commitment to security, our security team is requiring an immediate update to your sFTP password used to transmit your EDI orders." |
| 12:47 |
Dyrcona |
Well, that explains it. Bet they had some kind of intrusion event or a disgruntled former employee. |
| 12:47 |
jeff |
or they just accidentally the whole EDI user db. we'll see! |
| 12:48 |
jeff |
schrodinger's blast radius. |
| 12:48 |
jeff |
anyone know offhand what sftp implementation they were using? |
| 12:50 |
Dyrcona |
it does not announce itself when you login manually. I just get "Welcome! Please login." |
| 13:05 |
Dyrcona |
Reading through the acq emails, and someone said their credentials worked on Friday. We started having issues Thursday afternoon. When I checked the fetcher on Friday morning, it had been hung up for 22 hours. |
| 13:12 |
Dyrcona |
Huh. It looks like all we have to do fix bug 2060702 is add a timeout parameter to the Net::SFTP::Foreign->new(); |
| 13:12 |
* Dyrcona |
tries it. |
| 13:16 |
* Dyrcona |
hot patches edi_fetcher.pl in produciton. |
| 13:17 |
Dyrcona |
Wrong file. It's RemoteAccount.pm... |
| 13:22 |
Dyrcona |
rsync |
| 13:23 |
Dyrcona |
oops wrong windo. |
| 13:25 |
Dyrcona |
Ok. We'll see if that works. |
| 13:26 |
Dyrcona |
That patch is probably too simple. |
| 13:31 |
Dyrcona |
RemoteAccount.pm doesn't really seem to have a way to return failure from new/init. |
| 13:31 |
Dyrcona |
Oh, wait. It does. |
| 13:33 |
Dyrcona |
Except that it looks like the connection occurs after that. Why do we overcomplicate things? |
| 13:35 |
* Dyrcona |
rethinks live patching production. |
| 13:39 |
Dyrcona |
I guess if it was simple, I would have fixed it when I filed the bug. |
| 13:41 |
jeff |
in hindsight, live-patching was probablConnection closed by foreign host. |
| 13:54 |
Dyrcona |
heh |
| 14:08 |
csharp_ |
Dyrcona: coincidentally, I'm troubleshooting a possible Net::SFTP::Foreign issue but with the pusher |
| 14:09 |
csharp_ |
in my case pushing fails with OpenILS::Utils::RemoteAccount : SFTP put to edi.follettcontent.com failed with error: Couldn't setstat remote file: Cannot find message [/DropOff/7T_BaCodyr] |
| 14:09 |
csharp_ |
I'm thinking there's probably a param missing from our invocation of Net::SFTP::Foreign |
| 14:10 |
csharp_ |
however, the "Cannot find message [/path/to/file]" thing appears to be a Java-related error |
| 14:10 |
csharp_ |
vendor is Follett, who is apparently new to EDI ordering, so I'm not sure |
| 14:14 |
csharp_ |
hmm |
| 14:14 |
csharp_ |
https://www.ibm.com/support/pages/apar/PH70402 |
| 14:15 |
jeff |
csharp_: sorry, forgot I asked that question in here and found the answer and didn't report back. They're currently using (and have been since at least mid-May) a product called GoAnywhere MFT. |
| 14:15 |
csharp_ |
jeff: follett? |
| 14:16 |
csharp_ |
fwiw, when we connect via FileZilla, it works fine |
| 14:19 |
Dyrcona |
csharp_: Ingram, not Follet. |
| 14:20 |
Dyrcona |
I don't like the pusher. "Goddam, the pusher man!" |
| 14:20 |
Dyrcona |
I see, you're also hunting down Follett issues.... |
| 14:20 |
csharp_ |
no prob |
| 14:21 |
Dyrcona |
For anyone not getting the quote, look up Hoyt Axton, "The Pusher." |
| 14:22 |
csharp_ |
(reminds me of Tom Lehrer's The Old Dope Peddler) |
| 14:24 |
Dyrcona |
Tom Lehrer is funny.... |
| 14:24 |
Dyrcona |
Too bad kids today won't get the majority of the jokes. |
| 14:25 |
Dyrcona |
I guess I'm struggling with the fetcher right now, not the pusher. :) |
| 14:25 |
Dyrcona |
Maybe I should just hit the reset button on the day and work on something else for a while? |
| 14:25 |
* Dyrcona |
listens to Little Feat, Waiting for Columbus... |
| 14:30 |
jeff |
(and yes, my statement above about SFTP implementation was for Ingram Content, not Follett) |
| 14:30 |
csharp_ |
jeff: thanks for clarifying |
| 14:31 |
Dyrcona |
"Oh! Atlanta! Oh! Atlanta! .... I've got to get back to you." |
| 14:31 |
Dyrcona |
csharp_ ^^ |
| 14:32 |
csharp_ |
aww yeah |
| 14:33 |
csharp_ |
we're targeting Athens as a possible hack-a-way destination for this year so you might get your wish! |
| 14:35 |
Dyrcona |
:) |
| 14:35 |
Dyrcona |
I know. We offered to host this year, but there was a preference for Georgia again. |
| 14:37 |
Dyrcona |
Huh. Looks like the 3.14 final release never made it to the Community Calendar. |
| 14:38 |
Dyrcona |
I guess it was about October 22-24, 2024. |
| 14:39 |
Dyrcona |
I think I was in, or soon to be in, North Carolina at the time. |
| 14:40 |
jeff |
following "if you don't write it down, it never happened", does that mean that 3.14 is supported forever, or that everyone running 3.14.12 needs to uninstall it? |
| 14:40 |
jeff |
oh, you mean the one before that. never mind! |
| 14:42 |
Dyrcona |
Well, we usually do a beta, then a RC, then a "final" release. |
| 14:42 |
Dyrcona |
3.14.0 |
| 14:42 |
Dyrcona |
But, yeah, anyone running 3.14 should upgrade. :) |
| 14:43 |
Dyrcona |
I'm just trying to figure out when to say 3.18.0 will be released. |
| 14:43 |
jeff |
that makes more sense, especially with regard to the time range you mentioned. |
| 14:59 |
csharp_ |
sad that Evergreen π never caught on |
| 14:59 |
Dyrcona |
Heh. Like the version numbers of TeX. |
| 15:00 |
Dyrcona |
Guess we're not as cool as Donald Knuth. |
| 15:10 |
|
beardicus joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
