Here's 12 Sysadmin/DevOps (they're synonyms now!) challenges, straight from the day job:
After you complete each one, you get a glass of scotch. Happy Holidays!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 bake immutable images w/configuration rather than using configuration management. 6. Get a user to switch from Jenkins to GitHub Actions. 7. Get a user to stop keeping one file with all production secrets in S3, and use a secrets vault instead. 8. Convince a user (and management) you need to buy new servers, because although "we haven't had one go down in years", every one has faulty power supply, hard drive, network card, RAM, etc, and the hardware's so old you can't find spare parts. 9. Get management to give you the authority to force users to rotate their AWS access keys which are 8 years old. 10. Get a user to stop using the aws root account's access keys for their application. 11. Get a user to build their application in a container. 12. Get a user to deploy their application without you.> Get a user to stop logging in as root.
It really depends if the machine is hosting anything that you don't want some users to access. If the machine is single-purpose and any user is already able to access everything valuable from it (DB with customer data, etc) or trivially elevate to root (via sudo, docker access, etc) then it's just pointless extra typing and security theatre.
>> 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 web servers/middleware), 4) DBA who would be monitoring and optimizing Oracle/Postgres, and 5) Network admins, who would take care of Load Balancers, Routers, Switches, Firewalls (well, there were 2 security experts for that also)
So I think DevOps would be a mix of 1&2, to avoid the daily wars that would constantly happen "THEY did it wrong!"
Can somebody clear my mind, please!? It seems I was out of it for too long?!
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 happens, and no workaround from GitHub.
There are better solutions for CI, GitHub 's is half baked.
bugs happen to all of us. whats your better solution - gitlab?
Roll 2d6, sum result. Your CI migration target is:
2. migrate secret manager. Roll again 3. cloud build 4. gocd 5. jenkins 6. gitlab 7. github actions 8. bamboo 9. codepipeline 10. buildbot 11. team foundation server 12. migrate version control. Roll againsomehow i am really liking the kind of people that comment in the comment sections of sysadmin posts. i wonder what personality type this is
SysEng
Sysadmin.
GitLab pipelines are really good.
Not in love with its insistence on recreating the container from scratch every step of the pipeline, among a bundle of other irksome quirks. There are certainly worse choices, though.
honestly jenkins really isnt that bad
Yeah I was thinking of using it for us actually. Connects to everything, lots of plugins, etc. I wonder what the hate is from, they are all pretty bad aren't they ?
Will test forgejo's CI first as we'll use the repo anyway, but if it ain't for me, it's going to be jenkins I assume.
Cons:
Pros:- 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 to update the plugins to match the newer Jenkins version. - Reliance on system packages instead of containerized build environment out of the box. - Heavier on resources than some of the alternatives.
Wouldn't say there is a lot of hate, but there are some pain points compared to managed Gitlab. Using managed Gitlab/Github is simply the easiest option.- GUI is getting prettier lately for some reason. - Great extendability via plugins. - A known tool for many. - Can mostly be configured via GUI, including build jobs, which helps to get around things at first (but leads into the reproducibility trap later on).Setting up your own Gitlab instance + Runners with rootless containers is not without quirks, too.
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.
> Sysadmin/DevOps (they're synonyms now!)
I've notified the authorities and social services.
> … from Jenkins to GitHub Actions.
Oh, good lord why?
Because sysadmim wants to outsource their responsibilities (and job).
5. and 6. are a matter of taste (trade-offs), the rest is spot on!
You get me the permissions to do half of this stuff, and I'll do whatever you want.
I know its a common view that sysadmin/devops are the same these days, but witha current sysadmin role nothing youve mentioned sounds relevant. Let's give you my list:
1. Patch Microsoft exchange with only a three hour outage window 2. Train a user to use onedrive instead of emailing 50mb files and back and forth 3. Setup eight printers for six users. Deal with 9gb printer drivers. 4. Ask an exec if he would please let you add mfa to their mailbox. 5. Sit there calmly while that exec yells like a wwe wrestler about the ways he plans to ruin you in response 6. Debate the cost of a custom mouse pad for one person across three meetings 7. Deploy any standard windows app that expects everyone be an administrator without making everyone an administrator 8. Deploy an app that expects uac disabled without disabling uac 9. Debug some finance persons 9000 line excel function
That sounds more like Desktop Support than a SysAdmin role. My condolences if that's the job you landed when interviewing for a SysAdmin role
What you describe sounds more like a MS "Modern Workplace" / IT support in a corporate environment.
Are we arguing that corporate workers arent "real sysadmins"?
Pretty sure they mean “general IT support isn’t sysadmin work.”
i.e., Hell
Saying "keys which are 8 years old" implies you're worried about the keys themselves, which is just wrong. (Their security state depends on monitoring)9. Get management to give you the authority to force users to rotate their AWS access keys which are 8 years old.You can definitely make a strong argument that the organization needs practice rotating, so I would advise reframing it as an org-survivability-planning challenge and not a key-security issue.
I’d be super interested to see solutions to each, just to learn from.
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.
When I get sad and nothing to do in the world, may be hacking into a sad server's problem seems very interesting
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.
It doesn't seem to record my progress.
:sadness: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...We used to run terminal in browser using https://github.com/yudai/gotty and the entire dev team remapped their Ctrl+w to Ctrl+`. We did frontend and backend development with this setup almost for 1.5 years. Muscles memory and till this date, always have the fear if my actual terminal will get closed if I use Ctlr+w :P
You can use ctrl+shift+t to open the recently closed tab again.
hello, creator here, sorry about that. In this case you can click again on the "Open the Server Terminal in a New Window" button
It would be cool if we could SSH into the temporary host (I'm guessing these hosts currently aren't internet connected to avoid abuse so might not be possible or require some super careful firewalling)
I feel your pain - bites me from time to time, especially in KVM ;)
Without sharing too many spoilers... I solved the challenge but the check script was unhappy. The curl commands in the script worked fine, the earlier parts of the script failed, i.e. it didn't like how I'd decided to make that work.
This kind of thing annoys me. This is why CTFs are great, where the goal is to get the flag string. Obviously harder to do for sysadmin, but expecting a particular configuration when I managed to make it work without doing things exactly as they wanted is no better than a poorly written exam.
I wonder if we could get something like that for k8s, docker and other container ecosystem
[flagged]
well advent of code also needs an account
It’s not necessary to see the problems though
It's not clear that you will need an account to see the problems. Logged in with my account and it's exactly the same page. It's not Dec 1st everywhere yet, so they might open up for everyone when they do open them up.
This also has a paid account and a business account.
Checking out how the platform works was two clicks away: home -> give me a server.
I don't know of any other SaaS which gives you a VM with one click without any registration but we do it.
In any case thanks for the feedback, I've put a button on this /advent page for clarity, cheers
how do you want it to work? do you even sysadmin?
I see: a page offering something interesting but vague.
If you tell me more, I might sign up. If I have to create an account first, I'm walking away.
> how do you want it to work?
I would like to see and try to solve the scenarios for myself, not to get meaningless internet points. If you look at their front page, you can do that right now. So why do I have to create an account to even see these special advent scenarios?
> do you even sysadmin?
Yes.
I think the point is "ok, account is free, then what?"
At 5$/m I might give the paid subscription a try.
what's the deal with 12-days advent calendars lately?
Time pressures during christmas/holidays mean that the original calendars were becoming too stressful to handle. Seen several calendars switching to 12 consecutive days or 1 every 2 days challenges.
Advent of Code went from 25 days to 12 days starting this year, as it took too much time each year to come up with 25 unique challenges [1].
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.)
Don't the 12 Days of Christmas start on the 25th though?
Advent calendars track time until Christmas. “12 days of Christmas” are the twelve days after Christmas.
now we need advent of arts,math etc