| Time |
Nick |
Message |
| 00:15 |
|
dbwells joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:26 |
|
rjackson_isl_hom joined #evergreen |
| 07:43 |
|
rfrasur joined #evergreen |
| 08:11 |
|
mantis1 joined #evergreen |
| 08:17 |
|
alynn26 joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
dbwells joined #evergreen |
| 09:19 |
|
abneiman joined #evergreen |
| 09:25 |
|
jweston joined #evergreen |
| 09:25 |
jeff |
phasefx: regarding the k-line yesterday and quassel/identd, it does seem that oidentd can be configured to consult quassel, so that even while running under a single user each IRC client appears to an external identd query as their own user, not all as "quassel". |
| 09:27 |
jeff |
phasefx: see https://bugs.quassel-irc.org/projects/quassel-irc/wiki/Oident_spoofing and https://janikrabe.com/projects/oidentd/docs/guides/using-oidentd-with-quassel/ |
| 09:37 |
Dyrcona |
phasefx got k-lined? |
| 09:37 |
* Dyrcona |
checks the log instead of grousing about how long it takes ldirectord to realize that a brick is out of rotation. |
| 09:39 |
Dyrcona |
jeff: Did you get k-lined? |
| 09:39 |
jeff |
Dyrcona: all the quassel users on dc.esilibrary.com were k-lined yesterday. |
| 09:41 |
Dyrcona |
Ah. That makes a little more sense given the context of identd. |
| 09:41 |
jeff |
Dyrcona: In my interaction with Freenode staff to request removal of the k-line, they suggested running identd so that the nine-or-so users had distinct ident/user parts in their hostmask. |
| 09:41 |
Dyrcona |
Right. |
| 09:42 |
jeff |
As just a guess, it looked like all the clients with the same user/host (re)connecting at the same moment triggered an automatic response. |
| 09:43 |
Dyrcona |
Sounds about right as a defense/anti-spam mechanism. |
| 09:44 |
Dyrcona |
On my own topic: I imagine an Apache reload would help. It should finish up the current connections, then close them. That should send any current users the other bricks... |
| 09:47 |
Dyrcona |
I sure have a lot of "ESTABLISHED" http connections for a brick that is out of rotation. |
| 09:47 |
Dyrcona |
Also, ejabberd is using tcp6. |
| 09:55 |
Dyrcona |
I suspect that this method of taking a brick out of rotation doesn't actually work. Though I've noted it can take a long time in the past. |
| 10:00 |
Dyrcona |
I moved the file that ldirectord checks for almost 25 minutes ago. Nagios noticed 20 minutes ago, and the brick is still happily processing requests. |
| 10:05 |
Dyrcona |
ldirectord is broken. Based on the man page and our configuration, it should have considered the host down after 20 seconds. |
| 10:11 |
Dyrcona |
I'll bet it is the nginx or apache cache settings. |
| 10:11 |
Dyrcona |
We didn't used to have this problem before nginx. |
| 10:13 |
Dyrcona |
Neither a reload of apache nor a reload of nginx helped. |
| 10:21 |
Dyrcona |
Nothing but issues this morning.... |
| 10:47 |
Dyrcona |
That mass of overdues had consequences for other events that I hadn't noticed until this morning. |
| 10:48 |
|
alynn26_away joined #evergreen |
| 10:49 |
|
jihpringle joined #evergreen |
| 10:54 |
Dyrcona |
Fortunately, processing of pending events ignores the delay fields. |
| 10:54 |
Dyrcona |
@monlogue |
| 10:54 |
pinesol |
Dyrcona: Have you tried turning it off and back on again? |
| 10:54 |
Dyrcona |
ha! typos! |
| 10:54 |
csharp |
@blame [monologue] |
| 10:54 |
pinesol |
csharp: Your current monologue is at least 1 line long. stole bshum's tux doll! |
| 10:54 |
Dyrcona |
@monocle |
| 10:54 |
pinesol |
Dyrcona: uh huh.. please tell me more about that |
| 10:55 |
csharp |
pinesol: the tux doll is now in my office, which I haven't worked in since March |
| 10:55 |
pinesol |
csharp: http://xkcd.com/1739/ |
| 10:55 |
csharp |
also, the unicorn on a noose that used to hang on the pre-evergreen PINES server is there too |
| 10:59 |
Dyrcona |
@bad add Unicorn On a Noose |
| 10:59 |
pinesol |
Dyrcona: WORKSFORME WONTFIX |
| 10:59 |
Dyrcona |
bleh.... |
| 10:59 |
Dyrcona |
That xkcd hits a bit close to home this morning. :) |
| 11:01 |
Dyrcona |
The decorations from the closet in my office are apparently scattered all over my desk. They've removed the ceiling and demoed the back wall because of water damage from a leak on the 5th floor. (Our offices are on the 2nd floor.) I also haven't been in my office since March. |
| 11:02 |
Dyrcona |
2020: The year that keeps on "giving." |
| 11:06 |
|
jvwoolf joined #evergreen |
| 11:06 |
csharp |
2020 giveth, and 2020 taketh away |
| 11:07 |
* mmorgan |
has stopped by the office once or twice, to pick up a few things, and flip the wall calendar months at a time |
| 11:16 |
|
miker joined #evergreen |
| 11:25 |
jeff |
miker: welcome back from the land of the banned. |
| 11:35 |
|
jvwoolf1 joined #evergreen |
| 11:44 |
|
jihpringle joined #evergreen |
| 12:10 |
Dyrcona |
More "fun." When I upgraded training to Ubuntu 18.04, the upgrade disabled my swap partition in lvm and added a swapfile. I thought it would just keep the old partition.... |
| 12:10 |
Dyrcona |
That was Monday.... Feels like a long time ago, now. |
| 12:11 |
Dyrcona |
I also have fun with an encyrpted swapfile on my Ubuntu 20.04 laptop..... |
| 12:11 |
|
rjackson_isl_hom joined #evergreen |
| 12:11 |
Dyrcona |
I must be able to blame systemd for this, somehow..... ;) |
| 12:13 |
Dyrcona |
Um, what? My /etc/fstab was last modified in 2017.... |
| 12:16 |
Dyrcona |
So, maybe, I messed it up a couple of years ago. I'm seeing what looks like 1 TiB of unused disk space.... |
| 12:16 |
Dyrcona |
@blame me |
| 12:16 |
pinesol |
Dyrcona: I know it was you, Dyrcona. You broke Dyrcona's heart. You broke Dyrcona's heart. |
| 12:16 |
Dyrcona |
Ha! |
| 12:17 |
Dyrcona |
No, I am mistaken. That space is used. |
| 12:20 |
Dyrcona |
OK. All fixed! (I"m sure you're all glad to know that.) :) |
| 12:47 |
|
dbwells joined #evergreen |
| 12:54 |
csharp |
Dyrcona++ |
| 13:09 |
berick |
heh, chrome just alerted me my admin / demo123 passwords have been compromised |
| 13:37 |
|
jihpringle joined #evergreen |
| 14:50 |
Bmagic |
berick: lol |
| 14:52 |
Bmagic |
what's the solution for pg restore throwing an error with the "CREATE INDEX mrca_vlist_idx ON metabib.record_attr_vector_list USING gin ( vlist gin__int_ops );" command? |
| 14:53 |
csharp |
what's the full error? |
| 14:54 |
Bmagic |
pg_restore: [archiver (db)] could not execute query: ERROR: operator class “evergreen.gin__int_ops” does not exist for access method “gin” |
| 14:55 |
Bmagic |
search path? |
| 14:57 |
jeff |
search path won't help at pg_restore time. |
| 14:57 |
jeff |
as pg_restore explicitly sets search paths. |
| 14:58 |
jeff |
often you need to either change the source db to have an unambiguous reference to the cross-schema object, or edit the dump before restore if that's not possible/desirable. |
| 15:00 |
jeff |
looking at notes to see if I've had this specific issue. I remember digging into something similar a while back. |
| 15:00 |
Bmagic |
jeff: that error means the restore was a bust? I was thinking I just needed to make the INDEX after the restore was done |
| 15:00 |
jeff |
oh, you probably can. |
| 15:00 |
jeff |
i was solving for "make the pg_restore not throw the error" |
| 15:00 |
jeff |
sorry. :-) |
| 15:01 |
Bmagic |
I think it's a non-issue acctually |
| 15:01 |
Bmagic |
ERROR: relation "mrca_vlist_idx" already exists |
| 15:02 |
Bmagic |
ok, here we go: CREATE INDEX mrca_vlist_idx ON metabib.record_attr_vector_list USING gin (vlist evergreen.gin__int_ops); throws an error about "already exists" |
| 15:03 |
Bmagic |
but CREATE INDEX mrca_vlist_idx ON metabib.record_attr_vector_list USING gin (vlist evergreen.gin__int_ops); throws: ERROR: operator class "evergreen.gin__int_ops" does not exist for access method "gin" |
| 15:03 |
jeff |
you pasted the same command in both of those lines. |
| 15:04 |
Bmagic |
whoops |
| 15:04 |
Bmagic |
the first one (that works) does not have the "evergreen" qualifier for evergreen.gin__int_ops (AKA gin__int_ops) |
| 15:06 |
jeff |
does \x on the two databases show the intarray extension installed in different schemas? |
| 15:06 |
jeff |
er, not \x |
| 15:06 |
jeff |
\dx |
| 15:07 |
Bmagic |
intarray is only "on" for public |
| 15:08 |
|
dbwells joined #evergreen |
| 15:08 |
jeff |
On both the source database and the restored database, \dx shows that the intarray extension exists in the public schema? |
| 15:09 |
Bmagic |
well, no acctually |
| 15:09 |
Bmagic |
the source DB shows it for "evergreen" and not public |
| 15:10 |
jeff |
Okay, that would contribute to the error you experienced. |
| 15:11 |
Bmagic |
hmmm, alright. So the solution is to install that extension for the evergreen schema then? |
| 15:11 |
jeff |
There are (or were) some inconsistent ways in which we CREATE EXTENSION, leading to this. |
| 15:12 |
jeff |
I wouldn't recommend putting extensions in the evergreen schema, but it can happen by default if you CREATE EXTENSION with your search path set certain ways or with the default search path and running as a user named "evergreen". |
| 15:13 |
Bmagic |
alright, which way is the right way? |
| 15:13 |
jeff |
And I don't remember how tricky it is to move an extension that contains "in use" things in a db without a dump/reload. I've done it as part of looking into this in the past but can't find the notes in question (if I even made any). |
| 15:13 |
Bmagic |
I'm referring to create_database_extensions.sql right now. I suppose that's authoritative? |
| 15:20 |
Bmagic |
jeff: the search_path does need to be set to evergreen,public right? |
| 15:32 |
Dyrcona |
Bmagic: No, it should not be. Added public to the search path is unnecessary and the folks on in #postrgresql consider any apps that do so to be suspect. |
| 15:32 |
Bmagic |
should be simply "evergreen" then? |
| 15:32 |
Dyrcona |
If your user is named evergreen, then the evergreen schema is also automatically added to the path. |
| 15:32 |
Bmagic |
it's not, so I need to manually set the search path to "evergreen" |
| 15:33 |
Dyrcona |
Yes, you would in that case. |
| 15:33 |
Bmagic |
though, without public in the path - this gin index seems that it's broken |
| 15:33 |
Bmagic |
because the intarray extension is installed for public only |
| 15:33 |
Bmagic |
and not* evergreen schema |
| 15:34 |
Dyrcona |
Bmagic: I think we've been here before. :) |
| 15:34 |
jeff |
IMO the intarray being installed in the evergreen schema is not something I would recommend, though the Evergreen recommendation of search path and how we install some extensions is likely what led to it being in the evergreen schema to begin with. |
| 15:35 |
Bmagic |
yes, but not exactly this (I don't think) |
| 15:35 |
Dyrcona |
https://www.postgresql.org/docs/12/ddl-schemas.html#DDL-SCHEMAS-PATH |
| 15:36 |
Dyrcona |
In your case, with a differently named user, you probably do need to set the search_path. |
| 15:36 |
Dyrcona |
You're trying to do this with pg_restore? |
| 15:36 |
Bmagic |
I'm not hearing a direct "this is the way it should be" from anyone. |
| 15:36 |
Bmagic |
yes, when the user is not "evergreen" - then the search path needs to specify "evergreen" - no problem there. I'm clear on that |
| 15:37 |
Bmagic |
In the past, I've always included "public" after evergreen for "reasons from the great beyond" - and maybe that's not required with newer eg versions? |
| 15:37 |
Dyrcona |
Create an evergreen user and your problem is solved. |
| 15:38 |
Dyrcona |
Well, if you use that evergreen user, that is. |
| 15:38 |
Bmagic |
the default search_path is "$user",public - stock from PG repo |
| 15:39 |
Dyrcona |
Yeah, that's right, so if the user is named "evergreen" then the "evergreen" schema is in the search path along with public. |
| 15:39 |
Bmagic |
therefore, if I used a user "evergreen" - the search path would translate to: evergreen,public. Therefore, if I were manually setting the search path, it would be "evergreen,public" - and that's not correct (is what you are saying?) |
| 15:40 |
Dyrcona |
That's what I'm saying. public is supposed to be in the search path automatically. Adding it is considered an error. That's what they said in #postrgresql when you asked about something similar before. |
| 15:41 |
Dyrcona |
BUT! If you set the search with the SET command, you'll have to add public because if you don't, you'll lose it. |
| 15:44 |
Bmagic |
right - but you did say that " No, it should not be. Added public to the search path is unnecessary and the folks on in #postrgresql consider any apps that do so to be suspect." |
| 15:44 |
Dyrcona |
Right. It's confusing. |
| 15:45 |
Dyrcona |
If you do nothing at all, public should be in the search_path, so you shouldn't have to add it to access it. So gin_ops should be there. |
| 15:46 |
Dyrcona |
As I said before, it's easier for you if you a user named evergreen. :) |
| 15:46 |
Bmagic |
it sounds like the search path needs to include public. So.... I'm doing that.... and we are good, right? |
| 15:47 |
Dyrcona |
Maybe. :) But you said you were having a problem. |
| 15:48 |
Bmagic |
the CREATE INDEX command up there, where it includes "evergreen.gin__int_ops" - throws the error. Presumeably because "gin__int_ops" is no longer in the evergreen schema (now) - and dropping the schema qualifier allows PG to travel the search paths until it finds one (public) and that's working |
| 15:48 |
jeff |
returning from a quick trip to the archives to hopefully clear something up: |
| 15:48 |
jeff |
It's the inclusion of pg_catalog in the search_path that folk in #postgresql have identified as an issue when you two have had search_path related discussions there earlier last month. |
| 15:49 |
Bmagic |
jeff++ |
| 15:49 |
jeff |
1596642835 < depesz> Bmagic: setting search path to: evergreen, public; makes perfect sense, and is OK. |
| 15:49 |
jeff |
1596642844 < depesz> setting it to "evergreen, public, pg_catalog" is suspicious. |
| 15:49 |
Dyrcona |
Oh, right. :) |
| 15:49 |
Bmagic |
yep, there we go. I couldn't remember. Thank you! Now it's clear |
| 15:49 |
Dyrcona |
pg_catalog.... :) |
| 15:50 |
Dyrcona |
Information overload. |
| 15:51 |
Dyrcona |
@blame me |
| 15:51 |
pinesol |
Dyrcona: Dyrcona HAXORED Dyrcona's SERVERZ!!!! |
| 15:51 |
Dyrcona |
:) |
| 15:51 |
Dyrcona |
I always get one that doubles my name. |
| 15:52 |
Bmagic |
however, jeff did say that he doesn't recommend installing extensions on the evergreen schema (therefore, I can assume he is recommending that they all go to the "public" schema) - which if the search path were default and $user was "evergreen" - then the CREATE EXTENSION would land in the "evergreen" schema right? |
| 15:53 |
Dyrcona |
Bmagic: I don't think so, but let me check something. |
| 15:53 |
|
nfBurton joined #evergreen |
| 15:54 |
Bmagic |
I suppose the evergreen schema wouldn't have been created yet (as those commands are ran before the restore) |
| 15:55 |
Dyrcona |
Actually, it looks like that is correct. When I create the plprofiler extension in a test database it ends up in the evergreen schema. |
| 15:55 |
Bmagic |
and now it's becoming clear as to how I wasn't clear :) |
| 15:56 |
Dyrcona |
you can specify the schema when you create the extension: create extension [extension] with schema [schemaname] |
| 15:57 |
Dyrcona |
I have the intarray extension in the evergreen schema. |
| 15:57 |
Bmagic |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/create_database_extensions.sql;h=013032c78cfba427e5dce82aa2efe06584528963;hb=HEAD |
| 15:57 |
Dyrcona |
That's the one that's giving you problems isn't it? |
| 15:58 |
Bmagic |
yep, that's the one |
| 15:58 |
Bmagic |
if it's qualified with "evergreen" - it fails to create the index (because the intarray is on the public schema atm) |
| 15:58 |
Dyrcona |
Have you looked at the output of \dx |
| 15:58 |
Bmagic |
yep |
| 15:59 |
Bmagic |
\dx reveals that my restored db has intarray on "public" and the original db has it on "evergreen" |
| 15:59 |
Dyrcona |
I'm not sure how that happens. My restored database has it in evergreen. |
| 15:59 |
Bmagic |
not sure how big of a deal this is |
| 15:59 |
Bmagic |
jeff: where is your intarray installed? |
| 16:00 |
Dyrcona |
My production db and the restored copy look the same, except that I've added plprofiler to the copy. |
| 16:00 |
Dyrcona |
I think the intention is that it would be in public. |
| 16:01 |
Dyrcona |
"it" being the intarray and other extensions. |
| 16:01 |
Bmagic |
Do you think that the evergreen source code should be altered to handle the case when the database is setup with a user other than "evergreen" ? |
| 16:01 |
Dyrcona |
I'm not sure what happens if it moves, though. |
| 16:02 |
Dyrcona |
Well, it's actually potgres that assume username == dbname == main schema. |
| 16:02 |
Bmagic |
Dyrcona: pretty sure the reason that my restored db has it on public whereas the original is on "evergreen" is due to the search path not getting changed PRIOR to the restore |
| 16:03 |
Bmagic |
the db is also not named "evergreen" |
| 16:03 |
Dyrcona |
OK. I just pg_restore without issue, but I'm using an evergreen username. |
| 16:04 |
Dyrcona |
Right, I have multiple databases that are pg_restore'd and not named evergreen. The username == database name is more of a psql thing. |
| 16:04 |
Dyrcona |
If you don't specify the database on the command or environment variable, it assumes its the same as the username. |
| 16:05 |
Dyrcona |
But, my point was PostgreSQL is making these assumptions, not so much Evergreen. |
| 16:06 |
Bmagic |
yep, I feel better now. search path: evergreen,public (for sure) |
| 16:07 |
Dyrcona |
I'm sorry for being unreliable on that point earlier. It has been a bit nuts the last few days/weeks/months/years/lifetimes...... :) |
| 16:08 |
Bmagic |
lol, lifetimes. I feel the same way brother |
| 16:08 |
Bmagic |
Dyrcona++ |
| 16:08 |
Bmagic |
jeff++ |
| 16:08 |
Bmagic |
csharp++ # instigatore |
| 16:09 |
Dyrcona |
Bmagic++ # paralate Italiano! :) |
| 16:09 |
Bmagic |
lol |
| 16:09 |
gmcharlt |
Bmagic: is there any reason for me not to do a big ol squash of the Antora branch? |
| 16:09 |
Bmagic |
nope, go for it |
| 16:09 |
Bmagic |
it was preserved in steps for those who wanted to see them |
| 16:10 |
Bmagic |
(like myself :)) |
| 16:11 |
|
jihpringle joined #evergreen |
| 16:11 |
Bmagic |
I'll bet, when squashed, it will look like a pretty good sized commit. Especially if you include the rm -Rf docs && mv docs-antora docs |
| 16:12 |
gmcharlt |
yeah, I won't be squashing it into entirely one commit |
| 16:13 |
Bmagic |
easily the largest commit that I have ever added my name as author of :) |
| 16:13 |
Dyrcona |
Oftentimes, one big commit is harder to deal with than a few smaller commits. |
| 16:16 |
Dyrcona |
I think I need to turn the Led Zeppelin up. |
| 16:18 |
Dyrcona |
Ah, well, it's a long weekend. |
| 16:23 |
Dyrcona |
Guess, I'll sign out. Have a good weekend, everyone! |
| 16:28 |
Bmagic |
@later tell Dyrcona Have a good Labor Day weekend! |
| 16:28 |
pinesol |
Bmagic: The operation succeeded. |
| 16:35 |
|
dbwells joined #evergreen |
| 16:36 |
|
mantis1 left #evergreen |
| 17:00 |
|
rfrasur joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:24 |
|
jihpringle joined #evergreen |
| 17:33 |
|
rfrasur joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:05 |
|
jihpringle joined #evergreen |
| 20:36 |
pinesol |
Showing latest 5 of 44 commits to Evergreen... |
| 20:36 |
gmcharlt |
Antora stuff is now pushed |
| 20:36 |
pinesol |
[evergreen|Galen Charlton] LP#1848524: update the README symlink - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=78c3e4f> |
| 20:36 |
pinesol |
[evergreen|Galen Charlton] LP#1848524: tweaks to generate_docs.pl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b863683> |
| 20:36 |
pinesol |
[evergreen|Galen Charlton] LP#1848524: tweak the Antora site.yml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca31838> |
| 20:36 |
pinesol |
[evergreen|Galen Charlton] LP#1848524: update references to docs-antora - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5252928> |
| 20:36 |
pinesol |
[evergreen|Galen Charlton] LP#1848524: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=891f31c> |
| 20:39 |
gmcharlt |
Bmagic: I've also done the merge to update eg-antora |
| 22:36 |
|
sandbergja joined #evergreen |
| 22:41 |
csharp |
ITS is doing system work beginning at 11:00 p.m. tonight - window ends at 7:00 a.m., but it's supposed to be an hour or so - git/web/lists/etc. will be unavailable |
| 23:35 |
|
serflog joined #evergreen |
| 23:35 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 23:38 |
|
pastebot joined #evergreen |
