- Arch-devops - lists.archlinux.org

Junior DevOps application - Christian Heusel (gromit)
by Christian Heusel 19 Oct '23

19 Oct '23

Hello everyone, tl;dr: I would like to hereby apply as junior devops with jelle and klausenbusk sponsoring my application. I am using linux systems since around 2012, arch-based systems since 2016 and Arch Linux itself since 2018. Since a few years I am also an active contributor to open source software either by publishing own projects or modifying existing ones to fit my liking[0]. In Arch Linux I am currently mainly contributing as Package Maintainer[1], Tester, via contributions to various projects (devtools, AUR, archwiki etc)[2] and anywhere where I find contributing fun or figure someone needs to step up. I like things moving fast and improving over their status quo and feel like Arch Linux is a great fit to actually do that. Outside of Arch Linux I have so far already worked a few years as a part time linux systems administrator (2018-2021) and also still do on a volunteer basis for my student council (since 2018). I am therefore quite used to ansible, the mediawiki stack, hedgedoc, monitoring with the prometheus stack, backups via borg(matic) and in general just quickly getting any unknown systems to run when they are needed for the project or putting in the maintenance work to keep existing systems happily running. Past and current contributions to infrastructure projects in Arch Linux include helping a bit during the git packaging migration and when the gitlab was hit by spam and recently more meaningful contributions to the wiki setup[3][4] and in the light of the upcoming bugtracker migration[5][6]. To be able to further help out in the devops team I would like to become part of it as junior devops. I would initially be interested in the following areas, but will pick up whatever looks doable and progress from there: - Bugtracker, Gitlab and Bugbuddy (for the bugtracker migration) - Mediawiki (SSO, updates and fixes) - Hedgedoc Thanks for reading until here, I am excited to see your reactions/feedback! Cheers, gromit [0] https://github.com/christian-heusel [1] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [2] https://gitlab.archlinux.org/gromit [3] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/747 [4] https://github.com/archlinux/archwiki/pull/67 [5] https://gitlab.archlinux.org/gromit/flyspray2gitlab/ [6] https://gitlab.archlinux.org/flyspray-migration/

3 3

CSS for the archlinux website could be more readable
by Jean Luc Picard 05 Sep '23

05 Sep '23

I've never noticed this until just right now, but I just viewed arclinux dot org slash news on a fairly competent laptop LCD (poor coverage, decent angles, good contrast) & was damn nearly blinded, even well after adjusting the relative font size w/ ctrl - +/-. I get that someone took the care to make the link colors to the official colorscheme, but I shouldn't feel like I should need an extension or toggle a browser flag as to not feel like I'm about to have a wall of text seizure. It's not the cyan link colorscheme so much as the combination with the table bg colorscheme complementing it, destroying whatever contrast was left. Something like 30% of the human population has some level of color-blindness & you might not want the overhead of whatever population might have photosensitive epilepsy. I know of good frens in the community who have been triggered by stupider problems. Some of which aren't around anymore for stupider problems. This is coming from someone that runs cdm in matrix mode & turns motd into an animation of ansi code. My recommendation: Find a color picker applet, reduce brightness a few notches (manual: keep subtracting from the subpixel values), & enable bold. Perhaps clicked on links go to arch cyan regular & unclicked go for a more Web 1.0 deepish blue bold. Change the table colorscheme to greyscale, or find an appropriate one that would complement in contrast rather than sameness. Something Something ADA Reasonable Accomodation Request Posting to devops cause I figure this is where the webmaster would be.

1 0

Self-managed Arch repo & build-server
by Pascal Bryner 28 Aug '23

28 Aug '23

Hello Arch-DevOps Community We'd like to ask you, if there's a possibilty to clone all core & extra packages from the ArchLinux GitLab Packages Group to one of our build-servers and build them for our self. I've found the pkgctl utility, but when trying to execute 'pkgctl repo clone --protocol https --universe', it creates the respective directories but is then stuck at the cloning-process. The reason for this request is: We're running 60+ Arch clients for our employees (tendency increasing), which all are managed through a central application, where we can execute OS-updates, software-installs, firmware-updates, etc. The main problem is, that if we execute a company-wide update, some people directly install them and some postpone them as far as possible, sometimes taking vacation without installing the updates first. This leads us to the problem that the clients don't have the same state, sometimes with a 2 week or more gap, which makes it difficult for us to troubleshoot any problems. We had in mind, cloning all package-sources and then making snapshots of the build-directory, for a "stable" release. When using the gitlab-api to get all the urls of the repos, after some time the request times out, because we made to many requests. We do understand, that it's not the idea of Arch Linux to be a "part-stable" distribution, since of it's rolling-release model, but for maintenance-reasons it's the best option, having a rolling-release distro with up-to-date software and the ability to control, which packages are getting installed and which not. I hope you understand our proposal. -- Best regards Pascal Bryner Junior System Administrator

4 4

DevOps Meeting Thursday 27 July
by Jelle van der Waa 24 Jul '23

24 Jul '23

Hi, Agenda: https://md.archlinux.org/devops-agenda-27-july Time: 20:00 CEST Greetings, Jelle van der Waa

1 0

DevOps Meeting 13-07-2023
by Jelle van der Waa 09 Jul '23

09 Jul '23

Hi all, This Thursday there should be another DevOps meeting, I can't attend as I'll be on vacation. Previous meeting: https://md.archlinux.org/obH9H0v1TYSsxiN0UTY1Kg Greetings, Jelle van der Waa

1 0

Biweekly DevOps meeting
by Jelle van der Waa 03 Jul '23

03 Jul '23

Hey, This Thursday should be another bi-weekly DevOps meeting on 20:00 CEST. I won't be able to attend due to a work trip. Topics I can think of worth discussing are: - Uptimerobot - Flyspray migration - migration script status Greetings, Jelle

4 3

DevOps meeting Thursday
by Jelle van der Waa 30 May '23

30 May '23

Hey all, Let's re-start the bi-weekly meetings to sync up on the state of things, on Thursday 20:00 CEST. # Topics - Leftover migration ToDo's - Closing Flyspray - Gitlab package related topics Detailed agenda: https://md.archlinux.org/kF4a9cx2Sqe5ESusZw85zg?both Greetings,

1 0

GitLab's SSH moved to port 22 and sshd to port 2222
by Evangelos Foutras 19 May '23

19 May '23

GitLab's SSH clone URLs no longer require port 222. This matches the structure used by most GitLab instances. Previous clone URLs (which include port 222) will continue to work for the foreseeable future. The host's SSH port has been changed to 2222 and Ansible will use it automatically. Arch DevOps will also need to: ssh-keygen -R gitlab.archlinux.org Credits go to Kristian for suggesting and implementing this quality-of-life improvement: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/716

1 0

New host keys for gitlab.archlinux.org
by Evangelos Foutras 08 May '23

08 May '23

Dear Arch DevOps Team, Following the migration of our GitLab instance from a cloud server to a new dedicated box, you will need to remove the old host keys from your $HOME/.ssh/known_hosts file. For this please do: ssh-keygen -R gitlab.archlinux.org After the above, when you attempt to connect to gitlab.archlinux.org, you will be prompted to accept a new host key. Please find below the new host key fingerprints: SHA256:ZHy7zbNNwKHukTEyFcAT2Ns+mT/wlc2vAjJULnlOroE (ECDSA) SHA256:KD3Og7bPg9glmODrqUKN0r3Jl18pQ0OVp2MT7xv/bm8 (ED25519) SHA256:2R7QoVWeZ2DpKEsZBgVKUieM+9TQu6g9N62CIJCyVtc (RSA) Please note that this change only affects the host machine and not GitLab itself. Git clones from the latter will work without change. Stay safe and frosty!

1 0

Upgrading GitLab hardware specs
by Levente Polyak 03 May '23

03 May '23

Hi all, we already seem to have a quite high base load on our current VPS instance for our GitLab. We see some periodic soft lockups for git and UI operations when resource hungry tasks are performed, like Linux kernel mirror operations or GitLab housekeeping. Soon we will have Git packaging sources on our GitLab as well, which will increase the baseline usage against our GitLab quite noticeably. We really want to avoid to cheap out on this crucial and central part of our infra. As we already sort of maxed out on the VPS capabilities, we'd proceed and move the GitLab box to a bare metal system. The best bang for the bucks seems to be the AX52 [0], which will give us a spicy and more responsive GitLab instance. Cheers, Levente [0] https://www.hetzner.com/de/dedicated-rootserver/ax52

1 0