Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advent of Sysadmin 2025

sadservers.com

Post reply on HN
Print view View original

31–40 of 140 posts

Re: Advent of Sysadmin 2025

#31

Post by swyx »

cobertos wrote: post #28
0xbadcafebee wrote: post #14

Here's 12 Sysadmin/DevOps (they're synonyms now!) challenges, straight from the day job: 1. Get a user to stop logging in as root. 2. Get all users to stop sharing the same login and password for all servers. 3. Get a user to upgrade their app's dependencies to versions newer than 2010. 4. Get a user to use configuration management rather than scp'ing config files from their laptop to the server. 5. Get a user to bak…

Re: 6. ... Github Actions Github Actions left a bad taste in my mouth after having it randomly removed authenticated workers from the pool, after their offline for ~5 days. This was after setting up a relatively complex PR workflow (always on cheap server starts up very expensive build server with specific hardware) only to have it break randomly after a PR didn't come in for a few days. And no indication that this h…

bugs happen to all of us. whats your better solution - gitlab?

Re: Advent of Sysadmin 2025

#34

Post by dragonwriter »

swyx wrote: post #32
NooneAtAll3 wrote: post #29

what's the deal with 12-days advent calendars lately?

aren't they canonically 12? 12 days of christmas etc

No, Advent is the liturgical season preceding Christmas, beginning the fourth Sunday before Christmas (which is also the Sunday nearest November 30), it is a period of at least three weeks and one day (the shortest period that can start on a Sunday and include four Sundays.)

The 12 days of Christmas start on Christmas and end on January 5, the eve of the Feast of Epiphany.

12-day advent calendars are a fairly recent invention that mirrors the 12-days of Christmas, but has no direct correspondence to anything in any traditional Christian religious calendar (the more common 24-day format is also a modern, but less recent, invention detached from the religious calendar, that simplifies by ignoring the floating start date of advent and always starting on Dec. 1.)

Re: Advent of Sysadmin 2025

#35

Post by sharts »

swyx wrote: post #31
cobertos wrote: post #28

Earlier quoted context omitted.

Re: 6. ... Github Actions Github Actions left a bad taste in my mouth after having it randomly removed authenticated workers from the pool, after their offline for ~5 days. This was after setting up a relatively complex PR workflow (always on cheap server starts up very expensive build server with specific hardware) only to have it break randomly after a PR didn't come in for a few days. And no indication that this h…

bugs happen to all of us. whats your better solution - gitlab?

honestly jenkins really isnt that bad

Re: Advent of Sysadmin 2025

#40

Post by JuniperMesos »

0xbadcafebee wrote: post #14

Here's 12 Sysadmin/DevOps (they're synonyms now!) challenges, straight from the day job: 1. Get a user to stop logging in as root. 2. Get all users to stop sharing the same login and password for all servers. 3. Get a user to upgrade their app's dependencies to versions newer than 2010. 4. Get a user to use configuration management rather than scp'ing config files from their laptop to the server. 5. Get a user to bak…

A lot of these problems seem pretty solveable, if you're the admin of the machine (or cloud system) and the user isn't.

If you don't want a user to log in as root, disable the root password (or change it to something only you know) and disable root ssh. If you want people to stop sharing the same login and password across all servers, there's several ways to do it but the most straightforward one seems like it would be to enforce the use of a hardware key (yubikey or similar) for login. If people aren't using configuration management software and are leaving machines in an inconsistent state, again there are several options but I'd look into this NixOS project: https://github.com/nix-community/impermanence + some policy of rebooting the machines regularly.

If you don't like how users are making use of AWS resources and secrets, then set up AWS permissions to force them to do so the correct way. In general if someone is using a system in a bad or insecure way, then after alerting them with some lead time, deliberately break their workflow and force them to come to you in order to make progress. If the thing you suggest is actually the correct course of action for your organization, then it will be worthwhile.

Post reply on HN