| opendevreview | Merged opendev/system-config master: Mirror puppetlabs packages for Ubuntu Noble https://review.opendev.org/c/opendev/system-config/+/931670 | 00:10 |
|---|---|---|
| mnasiadka | clarkb: Found the Ansible locale problem - the centos 9 stream image comes without glibc-langpack installed (only with glibc-minimal-langpack that doesn't really deliver anything) so the only available locale is c.utf8 - but we have set LANG=en_US.UTF-8 | 08:39 |
| opendevreview | Martin Kopec proposed opendev/irc-meetings master: Update QA office hour https://review.opendev.org/c/opendev/irc-meetings/+/933076 | 08:45 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: Install glibc-langpack on alma/centos/rocky as well https://review.opendev.org/c/openstack/diskimage-builder/+/933080 | 09:22 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: Install glibc-langpack on centos as well https://review.opendev.org/c/openstack/diskimage-builder/+/933080 | 09:24 |
| mnasiadka | clarkb: ^^ this should fix this | 09:24 |
| opendevreview | Merged opendev/irc-meetings master: Update QA office hour https://review.opendev.org/c/opendev/irc-meetings/+/933076 | 12:15 |
| *** rlandy_ is now known as rlandy | 12:37 | |
| clarkb | mnasiadka: thanks +2 from me | 14:50 |
| clarkb | frickler: did you have time for https://review.opendev.org/c/openstack/project-config/+/931659 today? | 14:51 |
| clarkb | it has to do with which cirros images are cached in our test node image builds | 14:51 |
| *** gthiemon1e is now known as gthiemonge | 14:58 | |
| clarkb | JayF: you may know. How terrible of an idea is it to install obs studio from flathub as a flatpak? | 15:00 |
| frickler | clarkb: oh, I hadn't seen that one yet, checking now, thx for the pointer | 15:01 |
| JayF | clarkb: depends on how you feel about having a parallel stack of things | 15:01 |
| JayF | clarkb: flatpak has some big downsides in practice that mainly boil down to integration issues (most distros fix this transparently) and really, really, really slow launch times | 15:02 |
| clarkb | I don't mind so much having flatpaks alongside distro packages. More of a concern that it may just be a huge pain since I know snaps for example have all sorts of permissions issues with the sort of thing obs will do | 15:02 |
| clarkb | like usb access (for webcam) and so on | 15:03 |
| clarkb | there is also the issue of general trust too, but if you're installing obs you're trusting them regardless of where it comes from and they seem to be pushing the flatpak | 15:04 |
| fungi | i've struggled with flatpak a bit on my phone, since that's the "app" distribution solution pureos decided to go with (and debian for the base system) | 15:09 |
| fungi | unrelated, since today is the only day i don't have ptg sessions on top of lunch (and because i'm running a session in the middle of my evening), i'm going to take the opportunity to go out for a longer than usual lunch. leaving in a few minutes, probably back around 18:00-ish | 15:11 |
| clarkb | I guess an upside is that this in theory all runs as your user and without privilege? | 15:12 |
| clarkb | enjoy! | 15:12 |
| fungi | yeah, that's the main reason pureos used it for phone apps, isolation | 15:12 |
| fungi | but also things like video codecs can be much newer than what's packaged in debian | 15:12 |
| clarkb | I am installing flatpak now. At some point today I may have first hand knowledge on how well this works | 15:13 |
| fungi | the flatpaks supplied by the operating system maintainer are fairly well-integrated and transparent. where i've mainly struggled is adding third-party flatpaks | 15:14 |
| fungi | which is probably more akin to flatpak use in a more general purpose computing context | 15:15 |
| clarkb | I'm definitely not a fan of some of this ui... its very java needs fqdns for everything esque | 15:17 |
| clarkb | you want remote info? well you hvae to provide the remote name and remote ref nevermind there is already a remote configured with both pieces of info we could refer to | 15:18 |
| clarkb | this is interesting flathub shows you risks for each package "can access hardware devices" "can read and write to the fs" I like that but also "Legacy windowing system" is marked as an unsafe activity. How dare you support x11 | 15:29 |
| JayF | you /do/ understand that's really, really accurate, right? | 15:31 |
| JayF | x11 protocol lets any x app see the full screen at any point, so it's nearly impossible to trust any random X app | 15:31 |
| JayF | part of why the wayland migration has been a PITA has been all the authorization pieces | 15:31 |
| clarkb | JayF: yes I understand the shortcomings of x11 but installing a tool that supports x11 doesn't make x11 less secure. The way it is presented is the problem | 15:35 |
| clarkb | "uses a legacy windowing system" is vague but also is in addition to "screen content access" | 15:36 |
| JayF | I think a lot of that flatpak stuff is written for a level of non-technical user that barely exists in linux uses ime | 15:37 |
| JayF | so I can see why they're trying to gloss over stuff | 15:37 |
| JayF | I am the kinda guy who would probably use stronger language to change behavior too, so I have some empathy to that choice. | 15:38 |
| clarkb | the problem is that you aren't going to get someone to chagne to wayland for a random flatpak app. So flatpaks with x11 abilities should support that. Then you explain why that could be a risk. Not that its a problem software dare to support you | 15:39 |
| clarkb | which they have also done which is why I find it weird | 15:39 |
| clarkb | the install ui is really bad too. On tumbleweed flathub is preconfigured as a system level remote so installations from it are system wide. This requires prvileges to install. I didn't sudo the first time but it happily downloaded and failed to install every single one of 8 flatpaks. On rerunning it appears to have cached nothing and is redownloading everything (this is less bad | 15:42 |
| clarkb | because it may not have had perms to cache). Weird that it wouldn't fail fast and save the bw | 15:43 |
| JayF | To be clear: I kinda hate flatpak personally, not trying to defend it | 15:44 |
| JayF | just acknowledging that trying to boil down the security risk of running xwayland if you arne't already is very, very hard | 15:44 |
| clarkb | ya you mentioned the other problems I'm about to run into earlier :) | 15:44 |
| JayF | I have flatpak on my systems for exactly one reason: sometimes I wanna run an app real quick (often to see if it meets my needs) without compiling half the world (gentolol) :D | 15:45 |
| opendevreview | Merged openstack/project-config master: Stop caching CirrOS 0.5.2 and 0.6.1 images https://review.opendev.org/c/openstack/project-config/+/931659 | 16:05 |
| clarkb | I think this mostly works. From a recording perspective obs is a bit awkward with a single monitor | 16:16 |
| clarkb | but I can make that work | 16:16 |
| clarkb | now I just need to turn https://etherpad.opendev.org/p/advanced-opendev-brainstorm into something I can record | 16:18 |
| JayF | you want to make a video about that etherpad topic? | 16:23 |
| JayF | if you want it interview format style, I will volunteer to help. Probably could even exercise the GR-OSS streamyard subscription to record it | 16:23 |
| clarkb | I'm thinking it will be chunked up a bit more into separate videos | 16:24 |
| clarkb | one for zuul state managment, another for zuul multinode jobs, one for zuul secrets, and so on | 16:24 |
| clarkb | not sure about the format. This is all still early days of me trying to figure out how to put this together in a format that maybe people will consume :) | 16:24 |
| JayF | if you want a brainstorming partner, I'm still learning but have been doing a lot of content creation lately | 16:25 |
| JayF | (if you took me up on this I could try to talk them into paying the podcast producer to edit the video, too) | 16:26 |
| clarkb | cool I'll bring up qusetions/thoughts/ideas as I have them | 16:27 |
| clarkb | I am impressed that webcam, mic, and window capture all seem to have just worked. Looks like webcam capture is relatively new to linux obs. Also the auto detection of conversion settings seem to be overly conservative for a gaming setup I assume since it really didn't use all that much cpu. I can probably make the video look better by telling it to work harder | 16:33 |
| clarkb | JayF: re interview format I think that could work for some of the topics there. Particularly debugging maybe where one person has a problem to debug and the other coaches through it. For the other topics it may be best to just drive with examples? I'll think about it more | 16:38 |
| JayF | OBS is generally fine | 16:39 |
| frickler | clarkb: lots of good stuff in that etherpad, added just a couple of additional details that came to my mind while reading it. since I personally don't like watching videos, I think it would be great if also some kind of text document could come out of this | 16:41 |
| clarkb | oh wait no virtual camera support is what is new. Using webcam as an input source is not I don't think | 16:41 |
| JayF | I've had issues with it just randomly stopping audio mid-stream | 16:42 |
| JayF | which is why I no longer use OBS on linux for anything serious | 16:42 |
| JayF | (I switched most of my recording work to my personal windows machine) | 16:42 |
| clarkb | frickler: I saw your notes, thank you for the feedback. I too prefer text over video, but I'm told that everyone likes video now so I'm trying to meet the audience where they are at. I can probably convert a script for the videos into documentation though and cover both sets of preferences | 16:42 |
| clarkb | JayF: one protip I've gotten is to do a recording of the material talking through it as you go but without recording the audio. Then do another pass where you voice over using that video as the input | 16:43 |
| clarkb | might make problems with audio drops less bad. Not sure | 16:44 |
| frickler | clarkb: that'd be great, I'd also offer to help reviewing or editing that docs | 16:44 |
| opendevreview | Merged openstack/diskimage-builder master: Install glibc-langpack on centos as well https://review.opendev.org/c/openstack/diskimage-builder/+/933080 | 16:55 |
| clarkb | thinking about it more over breakfast I think the best appreaoch will be to pick one of the smaller subtopics and focus on doing that end to end to figure things out without all the other content getting in the way. Maybe zuul secrets since I think that is a self contained topic | 17:38 |
| clarkb | I don't expect to get to that this week due to the PTG but will dig in next week | 17:38 |
| clarkb | https://paste.opendev.org/show/bx5rwZyRrefaDi8au2Km/ here are the current disk consumptions for the nodes that I figure we can clear out of the backup server | 17:42 |
| clarkb | it won't have a huge impact but it should be measureable/noticeable in terms of time to reprune | 17:43 |
| clarkb | when fungi gets back from lunch I'd like to proceed with ethercalc02 and ask01 and then tomorrow if we don't notice complaints about those dirs missing and/or they don't come back we can proceed with theo thers? | 17:43 |
| clarkb | the plan would be to delete the dirs in /opt/backups and then remove the corresponding users and groups | 17:45 |
| clarkb | but now that I've said that I'm going to check ansible to make sure they won't come back automatically | 17:45 |
| clarkb | reading the borg-backup-server role I don't think they will come back. The borg-backup role creates a dataset that borg-backup-server takes as input and the dataset is based on the servers running that role. The servers don't exist anymore so can't run the role to update the dataset | 17:48 |
| clarkb | is there a better way to cleaing up the user/group than deleting the entries in /etc/passwd and /etc/group then deleting the homedir? | 17:50 |
| clarkb | userdel -r maybe? | 17:51 |
| clarkb | or maybe it is better to keep the user around and only delete the contents of hits homedir to prevent useradds in the future colliding with the same uid/gid? | 17:54 |
| clarkb | I'm beginning to think that may be the better options. Keep the user/group around but clear out the homedir which includes backup stuff | 17:54 |
| JayF | usually cleanup homedir + lock account is what I've done at other places | 17:55 |
| JayF | a note: if homedir does not exist, or is not a directory, `login` will use / as the homedir, so you may want to keep that in mind when deciding if you wanna delete or just empty the homedirs | 17:55 |
| clarkb | ya I think keep the homedir, delete the contents, then mark the account as not being able to login with whatever the special character is for that in /etc/password|shadow | 17:56 |
| clarkb | its a ! and is already set. Current plan: delete $user/backup and $user/.ssh. Set shell to /usr/sbin/nologin. Call that done | 18:04 |
| JayF | passwd -l user # this is from memory but I'm pretty sure this does the lock for you in passwd and shadow | 18:12 |
| JayF | I know it's not necessarily bad practice to edit the files directly, but I always prefer using the tools because that's less prone to mistakes | 18:12 |
| corvus | i restarted the zuul-launcher and then deleted the image records so it's now replacing the image build; that should fix the ssh key problem and we'll get timing information on the upload. | 18:19 |
| clarkb | corvus: ack thanks | 18:32 |
| clarkb | JayF: ya the accounts are already locked like that. I think we do that since we don't do local logins | 18:34 |
| clarkb | so its just a matter of further disabling login in and clearing some disk space | 18:34 |
| fungi | clarkb: let's proceed with ethercalc02 | 18:44 |
| clarkb | fungi: does the plan to keep the user in place but set the shell to no login then delete the backup dir for that user and clear out the .ssh dir make sense to you? | 18:44 |
| fungi | also the "everyone likes video" advice is apparently dated too, more recently i've heard that the younger crowd doesn't have the patience for sitting through long videos so if you can condense it into 30 seconds of content per idea that's more consumable for them | 18:49 |
| fungi | and yeah, don't delete users or groups since it could result in uidsgids getting recycled | 18:50 |
| clarkb | fungi: ya thats part of the reason for thinking multiple videos one per subtopic is a good idea | 18:50 |
| clarkb | ok I'm going to proceed with that plan against borg-ethercalc02 on the vexxhost backup server now | 18:50 |
| fungi | sounds good. we should do it on both backup servers for consistency too, right? | 18:51 |
| clarkb | I don't know that that is the case. Since the other server has larger disks having it store data longer is maybe a good thing? | 18:53 |
| clarkb | anyway this is done. The /opt/backups/borg-ethercalc02 dir is 7.2MB large now (mostly metadata about the old backup setup | 18:54 |
| clarkb | and if things don't complain over the next 24 hours or so we can proceed with the `usermod -s /usr/sbin/nologin borg-fooserverXY` then deletion of .ssh and backup within each homedir | 18:55 |
| clarkb | I'm going to grab lunch but if you get a moment maybe you can take a look and make sure that all looks good from your perspective | 18:55 |
| fungi | yeah, i suppose we could leave the old backups on the other server with more disk if we want the added safety | 19:01 |
| clarkb | https://cloud.google.com/blog/products/containers-kubernetes/how-class-e-addresses-solve-for-ip-address-exhaustion-in-gke/ hack of the day | 19:52 |
| fungi | not many people know about the class e space, though that does indeed seem like a hack | 19:59 |
| fungi | and feels like people might accidentally step on the multicast space if they're not careful | 20:00 |
| fungi | you'd think the real solution would be linklocal or netlocal v6 addresses | 20:01 |
| fungi | if only the container ecosystem would get with the 21st century | 20:01 |
| clarkb | I suspect the issue is their customers want/need/think they need ipv4? but ya if its all internal anyway and your cloud does ipv6 then you shouldn't need ipv4 addresses for that purpose | 20:01 |
| fungi | in their defense, the third and fourth sentences of the article are actually "IPv6 solves this exact address exhaustion issue by providing a lot more addresses. However not all enterprises or applications are ready for IPv6 yet." | 20:03 |
| fungi | so, really, get with the times people | 20:03 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update test arm64 mirror node https://review.opendev.org/c/opendev/system-config/+/933155 | 20:59 |
| clarkb | I have no idea if ^ will work but the quickest way to find out seemed to be this change. Basically I remembered that debian fixed that openafs dkms build problem and I'm hoping noble picked it up too | 20:59 |
| timburke | corvus, yeah, unfortunately the x-delete-at/after needs to be applied to all segments as well as the manifest | 21:23 |
| fungi | timburke: what's a good way to do that through the sdk? | 21:25 |
| corvus | timburke: okay, and swift cli doesn't do that i guess? | 21:26 |
| fungi | can it be done at creation (does it have to be done at creation), or as a separate call after upload? | 21:26 |
| corvus | fungi: well we switched to using the swift cli for now, but we can switch back to using the sdk if we resolve the issues we saw with that | 21:26 |
| fungi | oh, right, openstacksdk lacked some feature parity, i keep forgetting | 21:27 |
| corvus | yeah, and i already forgot what it was :) but it's all just software i'm sure we can fix it :) | 21:27 |
| corvus | for several values of "it" | 21:28 |
| fungi | might have also been multi-segment-related, i think image uploads were short/truncated? | 21:31 |
| corvus | 2024-10-23 19:44:09,155 INFO zuul.Launcher: Downloading artifact <ImageBuildArtifact 101caf00b7594a9e8cd72f401a066307 | 21:36 |
| corvus | 2024-10-23 20:29:34,232 DEBUG zuul.Launcher: Downloaded 8674676736 bytes to /tmp/101caf00b7594a9e8cd72f401a066307 | 21:37 |
| corvus | okay, i feel like we can probably do much better than 45 minutes downloading that. maybe we can do ranges or something. i'll put that on my list to look into. | 21:37 |
| corvus | 2024-10-23 20:29:34,234 INFO zuul.Launcher: Starting upload <ImageUpload 30a16e9515704f768077a9b3917ba8de | 21:38 |
| corvus | 2024-10-23 20:34:57,390 INFO zuul.Launcher: Finished upload <ImageUpload 30a16e9515704f768077a9b3917ba8de | 21:38 |
| corvus | 5 minutes to do the upload to create the image. | 21:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!