- Arch-devops - lists.archlinux.org

Adding runner2.archlinux.org; decommissioning runner1.archlinux.org
by Sven-Hendrik Haase 23 Nov '25

23 Nov '25

Hey all, Due to runner1's recent reliability issues and general sketchiness given its nature of being a sponsored machine whose sponsor we can't get in touch with, we decided to order a new dedicated machine directly from Hetzner. This is a "public" runner, the "secure" runner is untouched by this. The new machine, runner2.archlinux.org, is much faster than the previous runner, in theory by a factor of almost 3! It's around €63/month and will be our sole GitLab Runner for the foreseeable future. It should be able to handle pretty much all the load we put on it, I think. In the same step, I'm also pausing runner1's GitLab Runner and I would also like to keep the machine out of our runner pool indefinitely. For our pipelines, we need a fast and reliable machine and runner1 has become frustrating to work with. Since the machine still works and it is already set up, we could add it to our geomirror pool. The reliability issues would be much less noticeable there and I think it should be "good enough" for a mirror. What do you guys think? Would anyone like to work on that? Cheers, Sven

2 1

Getting a small Hetzner dedicated server for buildbtw development and testing
by Sven-Hendrik Haase 22 Nov '25

22 Nov '25

Hey guys, I intend to get a small Hetzner box (most probably AX41-NVMe) for buildbtw development and testing, trying a bunch of things in the capacity of a proof-of-concept. We don't exactly know where we're going with this yet. We need a hardware machine as we need it to be able to do virtualization. Hetzner cloud VMs can't do virtualization. It will be a special gitlab-runner executor. The idea is to fork the libvirt runner and add a bunch of buildbtw-specific stuff to it. It will not be managed by devops. I will give root to people involved in the buildbtw project. Costs will be <€40/month. It will be decommissioned after development. Any thoughts or objections?

3 5

Junior DevOps application - Robin Candau (Antiz)
by Robin Candau 24 Aug '25

24 Aug '25

Hi everyone, I'm sending this mail to apply as a Junior DevOps. My application is sponsored by Christian Heusel (gromit) and Kristian Klausen (klausenbusk / wCPO). My name is Robin Candau, also known as "Antiz". I'm a 29-year-old French guy passionate about music, cycling and IT / nerdy stuff. I'm an open source enthusiast. I've been using Linux for over a decade, and Arch Linux specifically for the past 5 years. I joined the Arch Linux staff in early 2023 as a ~~Trusted User~~ Package Maintainer and I've been contributing to multiple other parts of the Arch project since then; including Reproducible Builds, the Arch Wiki, WSL image maintenance, Testing Team coordination, AUR moderation, various tools & projects (e.g. pacman-contrib, devtools / pkgctl, archlinux-contrib, ...), infrastructure, submitting RFCs, Mediator, event organization, and so on... Generally speaking, I'm always up to help wherever I can (and hopefully learn something in the process). Outside of Arch Linux, I work as a Linux System & DevOps Engineer as my day job. I'm therefore using some of the stack that the DevOps team relies on to maintain the Arch Linux infrastructure on a daily basis. For the rest, I've got a strong desire to learn and I consider myself a fast learner. My past and present contributions regarding the Arch Infrastructure include: - Setting up a mirror via Fastly's CDN service [1] - Working on bumpbuddy (a daemon watching for new upstream releases for our packages) [2] [3], including maintaining its dedicated server (back when it was still a PoC) and writing the Ansible role to deploy it on the Arch Linux infrastructure [4] - Various other occasional contributions [5] to fix or improve things here and there As a Junior DevOps, I'd be interested in: - Maintaining the bumpbuddy box & associated services - Continue working on the ongoing Fastly experiments - Helping with any common, frequent or redundant tasks that would benefit from getting an additional pair of hands to work on (creating gitlab accounts, updating servers, etc...) Of course, I’m happy to jump in and help wherever else I can though! :) Thanks for reading my application! [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/639 [2] https://gitlab.archlinux.org/archlinux/bumpbuddy [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [4] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/963 [5] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/?sor… -- Regards, Robin Candau / Antiz

6 8

Request For Insights On Kernel Security Hardening Practices In Arch Linux
by Yinhao Hu 18 Dec '24

18 Dec '24

Dear All, We are academic researchers from Huazhong University of Science and Technology, China. To foster a healthier Linux kernel community and enhance the overall security of Linux distributions, we are conducting a study on kernel security hardening deployments across various Linux distributions. In our research, we analyzed kernel config files and the /proc filesystem by installing and running multiple distribution ISO images. This allowed us to enumerate the default deployment of kernel defense mechanisms at runtime. So far, we have cataloged over 50 kernel security hardening features and documented inconsistencies in their deployment across different distributions. The results of our analysis are accessible via the following link: https://docs.google.com/spreadsheets/d/17QRr04pqK1K4-VoHXW2-9KgPd4uV8Q4I-NN…. Given Arch Linux’s reputation for exceptional performance and rich features, we conducted a detailed investigation into its kernel security hardening strategies. To further deepen our understanding, we would greatly appreciate your input on the following questions: 1. Effectiveness of Kernel Security Hardening 1.1 Do you consider deploying kernel security hardening features to be an effective strategy for ensuring operating system security? 2. Configuration Strategy for Default Kernel Security Hardening Options 2.1 What are the primary criteria for selecting kernel security hardening options in your distribution? 2.2 How are configurable security hardening features (e.g., unprivileged_bpf_disabled) typically set (e.g., 0, 1, or 2), and what are the main considerations involved? 2.3 How do you balance the trade-off between side-effects (e.g., performance overhead) and the enhanced security introduced by kernel security hardening? 2.4 Does the tolerance for performance overhead vary across different application scenarios? 2.5 Are there other negative factors, such as compatibility issues, that are considered when enabling security hardening features? 3. Customized Configurations 3.1 Do you provide different kernel security hardening configurations tailored to specific user groups? 4. Best Practices and Recommendations 4.1 Are there any best practices or recommendations you can share regarding kernel security hardening? 4.2 Are there relevant documents or materials available for reference? The purpose of these questions is to gain a deeper understanding of your security protection strategies. Your insights would be immensely valuable to our study. Thank you for taking the time to review our questions. We look forward to your response. Best regards, Yinhao Hu, PhD candidate huyinhaodd(a)gmail.com Huazhong University of Science and Technology

1 0

A Mumble server for Arch Linux
by Sven-Hendrik Haase 26 Nov '24

26 Nov '24

Hello everyone, I would like to suggest we set up a Mumble server for Arch Linux staff. Time and time again, it's been useful for Arch people to come together for a longer time to hack on various projects or to plan stuff like Arch Summit. Often times, people use Jitsi for such things. However, I think Mumble is a more suitable alternative for people hanging out for a longer time as it: - allows you to have multiple channels for dedicated topics and you can see who's currently meeting where - is more stable than Jitsi in my experience - has better desktop integration for muting - has better quality - can more easily be used over slow networks The idea is to use mumble-server, put it on the smallest Hetzner VPS and call it a day. I've been operating Mumble servers for years and it requires maintenance basically never. We cannot connect it to SSO so we'll run it like we run the IRC channels: have a password and ask people to not tell people outside of staff. We'll have a bunch of moderators (not necessarily devops, just whoever wants to do create some channels now and then) that can set up channels and such but apart from that I think we can just run it. Thoughts? Sven

7 9

Cannot register new security keys on accounts.archlinux.org
by Frederick Zhang 29 Sep '24

29 Sep '24

Hi all, I was trying to replace my security keys on accounts.archlinux.org however the page [1] seemed to be broken due to a missing base64url.js script [2]. Here's the Copy as cURL command I got from Firefox dev tools and its output: $ curl 'https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url…' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0' -H 'Accept: */*' -H 'Accept-Language: en-GB,en-US;q=0.8,en;q=0.5,ja;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: script' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Site: same-origin' -H 'TE: trailers' -D- HTTP/2 404 server: nginx date: Tue, 10 Sep 2024 11:47:04 GMT content-length: 0 referrer-policy: no-referrer strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff x-xss-protection: 1; mode=block strict-transport-security: max-age=31536000; includeSubdomains; preload Could someone who has access please look into this issue? And of course let me know if this is the wrong list. Thank you! [1] https://accounts.archlinux.org/realms/archlinux/login-actions/required-acti… [2] https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url… -- Frederick Zhang PGP: 8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D

2 2

becoming member of the infrastructure team
by khaliid caliy 18 Sep '24

18 Sep '24

I am a sysadmin and i would like to participate in Arch Linux infrastructure team with my skills and expertise and i willing and eager to learn more. Thanks all and apologies for inconvienance

3 4

Christian Heusel is now a full DevOps!
by Kristian Klausen 11 Feb '24

11 Feb '24

Hi all, Christian has been a Junior DevOps for nearly 4 months but has been consistently contributing for way longer than that. He has proven himself to be hard-working and reliable, the DevOps team has therefore decided to promote him to full DevOps with all responsibilities and privileges that come with that. Welcome aboard, Christian! Cheers, Kristian

1 0

Rebasing other users' MRs for packages
by Brett Cornwall 11 Jan '24

11 Jan '24

Not sure if this is intentional but trying to rebase the branch in this MR is giving me a "something went wrong": https://gitlab.archlinux.org/archlinux/packaging/packages/sway/-/merge_requ… I would guess that the person just didn't check the "let the maintainer edit the commits" or something but I'd expect a less generic error message. Is this intentional behavior or broken behavior?

3 2

Automatic mailman onboarding
by Jelle van der Waa 07 Jan '24

07 Jan '24

Hey all, We have been wanting to onboard folks automatically via Keycloak to all our services. Mailman being one of them: Gluebuddy seems to be the best fit for this, as it a) knows keycloak and b) can also talk to mailman eventually (as it's just a REST API). For this I made an issue in Gluebuddy and a WiP branch for Gluebuddy which can do onboarding. [1] There are however several issues left to solve as we have many different usages of our mailing list. I for example on Keycloak use jelle(a)vdwaa.nl for my account and my arch email is jelle(a)archlinux.org (same as keycloak username). However this is not always the case, we have folks who have: - Different Keycloak email from Arch - Different Arch mail address from login name ie. svenstaro => sven(a)archlinux.org - May not use Arch email for mailing lists but their own. So in Keycloak I've used the beta feature of profile attributes, to add arch_email. And I think we should set this for all staff to be their archlinux email address. Even if it's the same as their username. With that solved we can onboard all arch email addresses. Would this also help for onboarding users into mail.archlinux.org? At least we can maybe replace the hardcoded mailmap? Now I know a lot of us subscribe with their personal email, how do we want to handle that from gluebuddy? Just mass subscribe and allow users to unsubscribe? Or at least allow sending? I haven't implemented onboarding, that likely has to request all users from mailman and match them against known keycloak staff's email/arch_email attributes. [1] https://gitlab.archlinux.org/archlinux/gluebuddy/-/issues/4 [2] https://gitlab.archlinux.org/archlinux/gluebuddy/-/merge_requests/17 P.S. the irony, I am not subscribed with my @archlinux.org address to this list.

2 1