| Time |
Nick |
Message |
| 02:21 |
|
smayo joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 09:22 |
|
Dyrcona joined #evergreen |
| 10:11 |
* Dyrcona |
contemplates testing Evergreen with Ubuntu 26.04. |
| 10:13 |
|
Rogan joined #evergreen |
| 10:14 |
Dyrcona |
Looks like snapshot 4 is still the latest image. |
| 10:41 |
jeff |
speaking of testing and Ubuntu... |
| 10:42 |
jeff |
Dyrcona: have you ever made use of Ubuntu's cloud images with KVM/qemu/similar? I've used the Debian cloud images before with much success, but a quick attempt at using the Ubuntu images didn't work as expected. |
| 10:49 |
Dyrcona |
jeff: I've not used other's images. I have made my own and cloned them with great success in the past. |
| 10:50 |
Dyrcona |
I should probably do that again. |
| 10:51 |
Dyrcona |
And, I think I'm going to try this Debian 13 vm without a proxy for websockets. I think that means that I can't use the systemd service file as-is. I probably have to modify it. |
| 10:54 |
Dyrcona |
Yeahp. I need to modify ExecStart. Maybe I'll make a copy for ssl and add it to examples when I get it working... |
| 10:56 |
Dyrcona |
Grr.. Ubuntu-- |
| 10:57 |
Dyrcona |
They broke GNU Emacs again. It won't open links, says the file doesn't exist. Don't have that problem on Arch. Stupid distro patches.... |
| 10:58 |
Dyrcona |
Wonder if it is a snap and that's why? |
| 10:58 |
Dyrcona |
Nope. Doesn't look like a snap. |
| 11:01 |
Dyrcona |
Maybe I should just install Arch on the work laptop. They won't notice. |
| 11:06 |
|
smayo joined #evergreen |
| 11:10 |
Dyrcona |
Hey! that seems to work. |
| 11:29 |
csharp_ |
linux++ |
| 11:31 |
Dyrcona |
So, the OpenSRF check_transport_client test fails on Debian 13 with main but not on Ubuntu 24.04 and not with OpenSRF rel_3_3 on either. |
| 11:31 |
|
jihpringle joined #evergreen |
| 11:33 |
Dyrcona |
Same as reported in Lp 2143584. |
| 11:33 |
pinesol |
Launchpad bug 2143584 in OpenSRF "check_transport_client test failure on main" [Undecided,New] https://launchpad.net/bugs/2143584 - Assigned to Jason Stephenson (jstephenson) |
| 11:37 |
Dyrcona |
osrfConfigDefault is not getting set. |
| 11:48 |
Dyrcona |
These tests are weak. |
| 11:58 |
Dyrcona |
yeah. looks it blows trying to get /router from the default config. |
| 11:58 |
Dyrcona |
blows up while trying to get |
| 12:05 |
Dyrcona |
I wonder if this is a redis thing? |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:20 |
* Dyrcona |
stops scratching his head and decides to let someone else look into it if they want. |
| 13:07 |
Dyrcona |
hrm... Bet I can configure an openapi proxy for Apache2. |
| 13:07 |
Dyrcona |
Should be able to do the same for websocketd for that matter. |
| 13:12 |
|
Christineb joined #evergreen |
| 13:41 |
Dyrcona |
hrmm websocket connection failed.... |
| 13:41 |
Dyrcona |
Maybe I should just go back to using the proxy. |
| 13:54 |
Dyrcona |
Ah ha! Fixed it. [Note to self: Do not use --sameorigin without a proxy.] |
| 13:55 |
Dyrcona |
Awesome.... Cooking with Angular 21 and plenty of console errors to peruse. |
| 14:32 |
csharp_ |
Iron Chef: Angular 21 |
| 14:32 |
csharp_ |
@who left before I was able to make that joke? |
| 14:32 |
pinesol |
dmoo left before I was able to make that joke. |
| 14:32 |
pinesol_dev |
csharp_: No, you're a puzzleheaded kraken! |
| 14:33 |
jeff |
That's okay. I appreciated the reference. |
| 14:33 |
csharp_ |
jeff++ |
| 14:35 |
csharp_ |
eeevil: I'm looking at bug 2023192 and curious about your thoughts on PL/Perl vs PL/Perlu - non-superusers can't "use" modules under plperl unless you init them at DB startup - wondering if there's a hygenic or other reason to avoid plperlu for everything? |
| 14:35 |
pinesol |
Launchpad bug 2023192 in Evergreen "Make Evergreen services default to a non-Pg superuser " [Wishlist,Confirmed] https://launchpad.net/bugs/2023192 |
| 14:36 |
csharp_ |
(understanding that plperl is more secure, asking specifically about the way we're using it) |
| 14:37 |
csharp_ |
for those unaware PL/Perlu is the "unrestricted" version of PL/Perl for writing PG functions |
| 14:37 |
eeevil |
IMO, there's no reason not to use plperlu. we load modules all the time, so we need it. the few cases were we don't load modules, it's better to just use plperlu to have a unified %_SHARED hash |
| 14:38 |
csharp_ |
okay - I was leaning that way - maybe I'll comment in the bug about it |
| 14:38 |
eeevil |
otherwise someone's going to go "we don't need modules, just use plperl for safety" and want to use %_SHARED to communicate information to other functions, and it won't work in a confusing way |
| 14:38 |
eeevil |
+1 |
| 14:38 |
eeevil |
(+1 to commenting :) ) |
| 14:40 |
eeevil |
(the reason is there are 2 separate perl interpreter instances for U and non-U versions, explicitly avoid leaking between them, and therefore they don't share the %_SHARED hash) |
| 14:42 |
csharp_ |
ah - glad I asked |
| 14:42 |
csharp_ |
https://bugs.launchpad.net/evergreen/+bug/2023192/comments/2 |
| 14:42 |
pinesol |
Launchpad bug 2023192 in Evergreen "Make Evergreen services default to a non-Pg superuser " [Wishlist,Confirmed] |
| 14:44 |
|
Dyrcona joined #evergreen |
| 14:48 |
jeff |
csharp_: let me know if you want comments in the bug instead of here, but it sounds like you might have a typo/thinko in that comment. you say you're leaning towards moving to plperlu, but Evergreen already exclusively uses plperlu, and does not make use of plperl. |
| 14:50 |
jeff |
since we are using plperlu, PL code using plperlu is not subject to restrictions on what it can do, and therefore we need to be a database superuser to CREATE FUNCTION ... LANGUAGE 'plperlu' |
| 14:51 |
jeff |
it might be possible to run as a non-superuser database user after those functions have all been declared, which would be a worthwhile investigation, IMO |
| 14:53 |
csharp_ |
jeff: thanks - I honestly haven't dug in past hitting the error "psql:000.functions.general.sql:82: ERROR: Unable to load JSON/XS.pm into plperl at line 2." |
| 14:55 |
csharp_ |
I saw in a StackOverflow post that changing the lanpltrusted attribute of pg_language allows non-superusers to create plperlu functions https://stackoverflow.com/a/7014649 |
| 14:55 |
csharp_ |
so I've done that in my testing |
| 14:56 |
csharp_ |
we can point a bug comment to this discussion fwiw |
| 14:57 |
jeff |
so you were running as a db non-superuser, modifying the pg_language system tables to mark plperlu as trusted, then trying to use plperl and running into the issue where plperl is (intentionally) prevented from loading modules? |
| 14:57 |
csharp_ |
yes |
| 14:58 |
Dyrcona |
Don't do that. :) |
| 14:59 |
jeff |
You might want to start with trying to create an Evergreen db as a superuser, then use that db as an owner-not-superuser database user, leaving your pg_language tables alone and keeping with the current practice of using plperlu. |
| 14:59 |
csharp_ |
ok, so we need to be a superuser to create the functions then? |
| 14:59 |
* jeff |
nods |
| 14:59 |
csharp_ |
honestly, new to a lot of this since we've always been root-y |
| 14:59 |
csharp_ |
mkay - well that seems like a safer way to go then |
| 15:00 |
csharp_ |
obviously in the naively-trying-stuff stage :-) |
| 15:01 |
jeff |
a database owner can do most things in a database without explicit permissions being granted. it's "their" database. some things that they can't do are things that postgres limits, like "CREATE LANGUAGE" with an untrusted language, or "CREATE FUNCTION" using language 'plperlu'. |
| 15:03 |
csharp_ |
jeff++ Dyrcona++ eeevil++ # thanks |
| 15:03 |
jeff |
if you can execute commands as a database superuser, you generally have the ability to execute arbitrary code as the user that postgres is running as. |
| 15:03 |
Dyrcona |
The database should be able to be created by the postgres user, then ownership transferred to a non-superuser, evergreen in this case because PostgreSQL likes to associate users with databases like that. |
| 15:04 |
Dyrcona |
After that you should exercise various functions to see if anything breaks. |
| 15:04 |
csharp_ |
yeah - I'm starting by modifying create_database_extensions.sql and will work backwards to eg_db_config |
| 15:04 |
Dyrcona |
Upgrades will probably have to be done as the postgres user. |
| 15:04 |
jeff |
eliminating that risk / shrinking that blast radius is the primary benefit in moving to a non-superuser database user for general "database user that Evergreen services use". |
| 15:04 |
csharp_ |
yeah, definitely |
| 15:05 |
jeff |
you can of course take things further, but that IMO has the potential to be a solid first step. additional steps are then optional. |
| 15:05 |
csharp_ |
jeff: good plan |
| 15:06 |
Dyrcona |
csharp_++ for actually making time to look at this |
| 15:07 |
csharp_ |
next project: don't require opensrf to own Apache2 stuff :-D |
| 15:08 |
Dyrcona |
Heh. |
| 15:09 |
Dyrcona |
It's probably better to leave it owned by opensrf but not to run Apache as opensrf. |
| 15:09 |
csharp_ |
yeah, I was thinking of the runuser stuff |
| 15:15 |
Dyrcona |
Anyone remember off the top of their head how to enable the Angular circulation client? I can look it up but thought I'd ask before spending too much time on it. |
| 15:16 |
csharp_ |
I think it's a YAOUS? |
| 15:17 |
Dyrcona |
csharp_++ it is. 'ui.staff.angular_circ.enabled' |
| 15:17 |
csharp_ |
whoo! |
| 15:18 |
Dyrcona |
I looked it up in app/staff/nav.component.ts |
| 15:20 |
Dyrcona |
'Enable Angular Circulation Menu' in the LSE. |
| 15:20 |
csharp_ |
@who set their YAOUS in the LSE? |
| 15:20 |
pinesol |
eby set their YAOUS in the LSE. |
| 15:20 |
pinesol_dev |
csharp_: Have you confirmed your ISBN SPIDs with your service provider? |
| 15:21 |
Dyrcona |
ooh. LastPass is causing console errors. |
| 15:21 |
Dyrcona |
I usually set them in the database, but since I was already logged in to the client I figured I'd use LSE. |
| 15:21 |
csharp_ |
LastPass-- |
| 15:22 |
Dyrcona |
So, yeah, those errors I mentioned just before leaving briefly, they were the same I'm seeing now for LastPass. |
| 15:24 |
Dyrcona |
They also only happen when I first login. They go away if I reload or navigate to another page and come back. |
| 15:25 |
Dyrcona |
Interesting console warnings with Angular 21. |
| 15:32 |
jeff |
yeah, at this point it's almost a moral obligation to caution your users against using LastPass. I probably wouldn't go as far as to block them for showing signs of it, but... maybe? ;-) |
| 15:33 |
jeff |
(i kid, with that last bit... mostly.) |
| 15:55 |
Dyrcona |
Do the shortcut keys ever work? I find that they don't work on my test system with Angular 21 using Chrome. |
| 16:11 |
|
jihpringle joined #evergreen |
| 16:56 |
pinesol_dev |
News from commits: LP#2121686 Ensure stat cats can be cleared <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=97f158632df8656a65ebf4b3479c930afd589bdf> |
| 16:56 |
pinesol_dev |
News from commits: LP#2121686 Remove reset button pending further feedback <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d20c926c4a94b6f5a008c95e366f0b719fa43462> |
| 16:56 |
pinesol_dev |
News from commits: LP#2121686 Difficult to clear fields in the new holdings editor <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=69c3ce3e5dc7e181f452aaa74a3735902b8d2d6b> |
| 16:57 |
pinesol |
News from commits: LP#2121686 Ensure stat cats can be cleared <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=97f158632df8656a65ebf4b3479c930afd589bdf> |
| 16:57 |
pinesol |
News from commits: LP#2121686 Remove reset button pending further feedback <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d20c926c4a94b6f5a008c95e366f0b719fa43462> |
| 16:57 |
pinesol |
News from commits: LP#2121686 Difficult to clear fields in the new holdings editor <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=69c3ce3e5dc7e181f452aaa74a3735902b8d2d6b> |
| 17:26 |
|
jihpringle joined #evergreen |
| 22:25 |
|
mmorgan left #evergreen |
