Live data from Hacker News

Advent of Sysadmin 2025

sadservers.com

71–80 of 140 posts

Re: Advent of Sysadmin 2025

#71

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…

None of them are technically hard. All of them are bureaucracy-hard.

If you just do any of this list without the proper migration plan/time, someone senior in the org will complain and you will lose.

Re: Advent of Sysadmin 2025

#72
post #67

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…

>> Sysadmin/DevOps (they're synonyms now!) Is this really like that? Isn't there any Unix/DBA anymore? I associate DevOps to what at my time we called "operations" and "development". We had 5 teams or so: 1) Developers, who would architect and write code, 2) Operations who would deploy, monitor and address customer complaints, 3) Unix (aka SYS) administrators, who would take care of housekeeping of well, the OS (and…

In full-cloud environments, in small/middle companies I've worked at:

Developers handle 1). Devops handle 2)/3)/5). Nobody does 4)

Re: Advent of Sysadmin 2025

#73
post #56

Earlier quoted context omitted.

Cons: - DSL is harder to get into. - Hard to reproduce a setup unless builds are in DSL and Jenkins itself is in a fixed version container with everything stored in easily transferable bind volumes; config export/import isn't straightforward. - Builds tend to break in a really weird way when something (even external things like Gitea) updates. - I've had my setup broken once after updating Jenkins and not being able…

I have a previous experience with it. I agree with most points. Jobs can be downloaded as xml config and thus kept/versioned. But the rest is valid. I just don't want to manage gitlab, we already have it at corp level, just can't use it right now in preprod/prod and I need something which will be either throwaway or kept just for very specific tasks that shouldn't move much in the long run.

For a throwaway, I don't think Jenkins will be much of a problem. Or any other tool for that matter. My only suggestion would be to still put some extra effort into building your own Jenkins container on top of the official one [0]. Add all the packages and plugins you might need to your image, so you can easily move and modify the installation, as well as simply see what all the dependencies are. Did a throwaway, non-containerized Jenkins installation once which ended up not being a throwaway. Couldn't move it into containers (or anywhere for that matter) without really digging in.

Haven't spent a lot of time with it myself, but if Jenkins isn't of much appeal, Drone [1] seems to be another popular (and lightweight) alternative.

[0] https://hub.docker.com/_/jenkins/

[1] https://www.drone.io

Re: Advent of Sysadmin 2025

#74
post #72
post #67

Earlier quoted context omitted.

>> Sysadmin/DevOps (they're synonyms now!) Is this really like that? Isn't there any Unix/DBA anymore? I associate DevOps to what at my time we called "operations" and "development". We had 5 teams or so: 1) Developers, who would architect and write code, 2) Operations who would deploy, monitor and address customer complaints, 3) Unix (aka SYS) administrators, who would take care of housekeeping of well, the OS (and…

In full-cloud environments, in small/middle companies I've worked at: Developers handle 1). Devops handle 2)/3)/5). Nobody does 4)

Can confirm: that's exactly what we do.

Re: Advent of Sysadmin 2025

#76
post #20

imagine typing in a terminal... you want to delete the previous word so press ctrl+w... actually you're in a browser; the window closes... :sadness:

Which is why macOS command key is such an undervalued nicety. One key for GUI stuff, one for command-line stuff.

Re: Advent of Sysadmin 2025

#77

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…

It’s not as easy as “I can technically change this”. If you think it is, you don’t understand the job of a sysadmin.

Re: Advent of Sysadmin 2025

#78
post #72
post #67

Earlier quoted context omitted.

>> Sysadmin/DevOps (they're synonyms now!) Is this really like that? Isn't there any Unix/DBA anymore? I associate DevOps to what at my time we called "operations" and "development". We had 5 teams or so: 1) Developers, who would architect and write code, 2) Operations who would deploy, monitor and address customer complaints, 3) Unix (aka SYS) administrators, who would take care of housekeeping of well, the OS (and…

In full-cloud environments, in small/middle companies I've worked at: Developers handle 1). Devops handle 2)/3)/5). Nobody does 4)

Nobody does 4 until they’ve had multiple large incidents involving DBs, or the spend gets hilariously out of control.

Then they hire DBREs because they think DBA sounds antiquated, who then enter a hellscape of knowing exactly what the root issues are (poorly-designed schemata, unperformant queries, and applications without proper backoff and graceful degradation), and being utterly unable to convince management of this (“what if we switched to $SOME_DBAAS? That would fix it, right?”).

Re: Advent of Sysadmin 2025

#79

Earlier quoted context omitted.

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…

None of them are technically hard. All of them are bureaucracy-hard. If you just do any of this list without the proper migration plan/time, someone senior in the org will complain and you will lose.

> If you just do any of this […], some senior in the org will complain and you will lose.

More accurate statement imo.

Re: Advent of Sysadmin 2025

#80

It seems it's called SRE nowadays right? I hate how things keep being renamed for no reason other than making more buzzwords for suits.

Nope, SREs keep applications running on a platform. Lots of metrics, tools to deploy apps in whatever rollout process the company has, etc.

In small companies, sysadmin might be a duty of the SRE team, but they definitely diverge if you have a large on-prem deployment or work with bespoke VMs in the cloud.

Post reply on HN