Monday, 2022-08-29

opendevreviewTakashi Kajinami proposed opendev/system-config master: Update gpg key of puppetlabs repository
*** lbragstad2 is now known as lbragstad01:04
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ansible-lint: pin to < 6.5
opendevreviewIan Wienand proposed zuul/zuul-jobs master: linter: Use capitals for names
*** dasm is now known as Guest146601:41
*** jpena|off is now known as jpena07:38
*** akahat_ is now known as akahat07:48
*** ysandeep is now known as ysandeep|lunch08:53
*** elodilles is now known as elodilles_pto09:26
*** pojadhav is now known as pojadhav|ruck09:30
* pojadhav|ruck afk for half hr09:33
*** rlandy_ is now known as rlandy10:31
*** ysandeep|lunch is now known as ysandeep11:02
*** dviroel_ is now known as dviroel11:31
opendevreviewdaniel.pawlik proposed openstack/diskimage-builder master: Do not install python3-virtualenv in Centos 9 stream
*** rlandy__ is now known as rlandy11:36
opendevreviewMerged opendev/system-config master: Update gpg key of puppetlabs repository
*** dasm_ is now known as dasm14:03
opendevreviewMerged opendev/irc-meetings master: Restart of the Public Cloud SIG
clarkbdpawlik: please see comments on 85501414:40
*** ysandeep is now known as ysandeep|out14:52
clarkbfungi: I'm looking at to try and figure out when the updated glibc will end up in debian stable. Does that entire queue have to go green and then the entire set is updated in the debian repo together?14:58
clarkb(opendev will need to rebuild base python images when that lands so that zuul can drop its bookworm install of glibc)14:59
*** dviroel is now known as dviroel|lunch15:08
fungiclarkb: it's the "make grantpt usable after multi-threaded fork" part we're wanting, right?15:10
fungispu just gets periodically "released" (every two months i think?)15:11
clarkbfungi: yes that is the fix we want and it is included in the queued package15:11
fungi11.4 was releases on july 9, so i think we should expect 11.5 in a couple of weeks15:12
fungier, was released15:12
clarkbI see, less of a queue and more of a set then15:13
fungisince the glibc update there is accepted in spu, it should be included in the next stable point15:13
fungi says "about every two months"15:14
*** pojadhav|ruck is now known as pojadhav|out15:15
fungithat's part of why there's a separate security suite: it's an out of band way to provide critical fixes sooner than the spr cadence15:15
clarkbI'm half tempted to do a rebuild of our base python images anyway, but I think that can wait15:18
fungiit's also possible to add the spu suite in order to get packages from there in advance of the next spr15:19
clarkbConsidering that the bookworm glibc is functioning I don't think that is necessary15:21
fungiclarkb: what was the workaround for "open /dev/pts/0: operation not permitted" trying to use docker-compose exec in the mailman-{core,web} containers?16:05
*** dviroel|lunch is now known as dviroel16:07
frickleruse exec without "-t"?16:07
fricklerjust guessing from the issue I have in some other docker installations16:08
fricklerthat would be this one
Clark[m]Yes run individual commands without the -t so no interactive session.16:12
Clark[m]I'm going to get a bike ride in now while the air outside is cool.16:13
fungiinteresting. i'm not using -t but maybe there's something assuming -t16:15
fungiaha! "-T  Disable pseudo-tty allocation. By default `docker-compose exec` allocates a TTY."16:16
fungiyep, that works16:17
*** jpena is now known as jpena|off16:31
fricklerseems got release on Friday, which contains the fix afaict16:37
fricklerat least fixes it for my deployment16:38
fungioh cool, thanks for the details16:39
fungiclarkb: i've used the steps noted at to import all three of our service-* mailing lists on the held node and it seems to have worked, based on what browsing around i've done with my /etc/hosts overriding to that17:44
funginote the list which is supposed to be private does indeed not allow anonymous archive browsing17:44
fungi(i checked that first to make sure i hadn't leaked any sensitive data)17:45
fungiclarkb: i added some comments in 851248 about things i ended up needing to tweak on the server in order to get it to work, all fairly trivial17:51
fungifor the moment i'm punting on the vhost config for serving the old pipermail archives, since that path will need to differ by domain name17:52
fungii'm happy to push corresponding updates for that change if you agree with my comments17:53
clarkbfungi: repsonded. I think those edits are fine18:24
clarkbI left a suggestion for the file ownership stuff. I was really hoping upstraem would at least respond to my issue but we may need to decide if we are ok with things ebing weird with perms until they do or give up and build our own images based on theirs (that change /etc/passwd and chown things)18:25
fungiyeah, i'm good either way, i mainly just needed to do something so the process in the container could write to the index directory18:27
*** Guest1238 is now known as diablo_rojo18:28
clarkbya I think if we just stop overriding the perms on that dir with ansible then the container does chown things itself18:28
clarkbfungi: you can also add a testinfra test to check that after both ansible runs complete18:28
fungioh, good idea18:28
clarkblooks like the apt puppetlabs repo did end up getting synced after that change landed21:13
opendevreviewMerged zuul/zuul-jobs master: ansible-lint: pin to < 6.5
*** rlandy is now known as rlandy|bbl21:59
clarkbinfra-root getting the meeting agenda together for tomorrow. Anything important missing? Maybe fedora 36? I guess I can add a note about the apt puppetlabs repo too22:01
fungii didn't have anything in particular22:02
ianwme either, just things already in flight22:02
clarkbok I'll add a fedora 36 topic so that I can get up to speed :)22:02
clarkbfungi: unrelated to the meeting agenda one thing I was hoping we could do with mm3 testing is have list creation set settings for lists to mimic our public lists from mm222:03
clarkbfungi: do you think that make ssense? Idea is that new lists we create would need less hand editing by their owners22:04
clarkbfungi: also if you create yourself an account on the test mm3 node does it automatically associate you with ownership on the migrated lists?22:04
fungican you elaborate? i can't tell if you're asking for something which is already happening22:04
fungiand yes to the last one22:04
fungioh, i see, you're asking about altering the default new list settings22:05
funginot related to migration of existing lists (which does attempt to preserve them)22:05
clarkbfungi: when we create a list via ansible talking to the rest api we have the opportunity to set a bunch of list configuration settings. I think we should configure it so that new lists roughly match what we think a list should look like and we can use a migrated mm2 list as a short cut for that22:05
clarkbcorrect for new lists22:05
clarkbwe should be able to query the api for a new list config and a migrated list config then determine if we should change any of those settings for new lists by default 22:06
fungiyeah, i'll confess i don't know how different the mm3 defaults are from mm2's defaults, but we've in the past used the defaults when creating new lists and people rarely alter those22:06
clarkbthe main things are going to be dmarc handling I think22:06
fungiif we change our stance on dmarc handling, perhaps. we've only adjusted a few lists for that22:07
clarkbfungi: ya and we consistenyl have peopl ebeing confused about it. I think we should stonrgly consider "sane" defaults for dmarc on new lists22:07
fungiand i have a feeling mm3 is going to be worse in regards to preserving messages on forward so that existing signatures still match22:07
fungias in, i wouldn't be surprised if we just need to turn on the dmarc mitigation features, as well as look into adding signing infrastructure for outgoing messages22:08
clarkbanyway I think it would be a good thing to compare are bare newly created list config to a migrated list config as a sanity check to see if there are any settings we want to automatically apply at list creation22:08
clarkbI'll make a note about it on the etherpad22:09
fungibut yeah, before we decide what our precise dmarc position is for mm3, we'll need to do some testing to see if it's enough like mm2 that we don't need to change our approach22:10
clarkbI'll poke at config comparisons tomorrow morning. You were going to update the change too right? We should probably make a new hold when we've got updated changes. Also I left some comments on the etherpad22:14
fungiyep, thanks!22:15
fungiclarkb: on the "Ensure Mailman volume directories exist" task, is there any reason not to just set them all to be owned by 100:101 like the containers expect?22:17
clarkbfungi: 100:101 on the host are used by other unrelated things.22:17
fungiright, i get that, but the end result is going to be that they're owned by 100:101 until the containers are fixed to not need that, right?22:18
clarkbfungi: I think the vast majority of the content doesn't need to be writeable. Would just be the indexes, the emails themselves (this may be an outstanding bug?) and the databse22:18
clarkbfungi: I think the container only does the subdirs. Also one container is 100:101 the other is 100:65543 or something22:18
fungiwhen i look at the content in all of those, it's owned by 10022:18
clarkbthat mismatch is part of why I'm trying to find a middle ground22:19
fungiand yeah, they're all either group mailman or group nobody22:19
fungithe core container seems to prefer group nobody while the web container uses group mailman22:19
clarkbya its a bug (I filed it)22:19
clarkbat the very least they should be consistent imo22:19
clarkbfungi: I guess we can split that task up and make one half 100:101 and the other 100:nobody22:19
fungiright, what i guess i'm asking is, do we wait for the bug to be fixed, or do we set ansible to use the user:group mappings the containers expect for now with a big TODO comment?22:20
clarkbthat would address potential bugs iwth mail writing (though I think everything happens in subdirs so it may just work)22:20
clarkbfungi: there is a third option which is that we build our own images and fix this issue iwth the images. We would update /etc/passwd and /etc/group and chown everything (and I think maybe need to edit their startup scripts too)22:21
clarkbBut this is an open question to me right now. I'm not sure what the best thing to do is22:21
clarkbI think our options are: A) use 100:101/100:nobody in the appropriate dirs, B) inherit their images and modify them to match our host mailman user and group, C) build our own images from scratch (may be forks of their Dockerfiles though)22:22
clarkbfungi: maybe for continued testing work we can do A) with a TODO and we can dtermine later if we need to take the bigger step of making our own images22:23
clarkbthen before we go to production make sure we've understood the impact of chowning everything later if sticking with A)22:24
fungiseems like we could do a easily for now until either they fix the problem or we're closer to production, then decide on b vs c once we know we need to do that additional work22:28
clarkbyup exactly22:28
fungii'll add a todo in that part as well22:28
clarkbfungi: maybe add a link to the issue I filed in the TODO?22:34
fungioh, yes great idea22:34
*** dviroel is now known as dviroel|out22:42
opendevreviewJeremy Stanley proposed opendev/system-config master: WIP Add a mailman3 list server
fungiclarkb: ^ also i edited the pad to reflect your fqdn directory idea23:13
clarkbfungi: oh cool. Otherwise we'd need some sort of table lookup to keep the redirects all in one vhost23:18
fungiyes. since there's a known number of domains and migration is a one-time thing, i think we can just do the "mapping" manually when copying the data to the server so that the thing we're maintaining going forward is simpler23:18
opendevreviewJeremy Stanley proposed openstack/project-config master: Match the ansible-lint <6.5 pin from zuul-jobs

Generated by 2.17.3 by Marius Gedminas - find it at!