Show HN: SadServers – Test your Linux troubleshooting skills (sadservers.com)
Hello, I'm building SadServers.com, a SaaS where users can test their Linux troubleshooting skills on real Linux servers in a "Capture the Flag" fashion.
I hope this is useful, to learn more about the project please see https://github.com/fduran/sadservers
132 comments
[ 3.2 ms ] story [ 210 ms ] threadMitigation: reducing servers life time temporarily so more people can try.
I'd start by moving the test VMs to bare-metal servers running libvirt. You can get a 128GB RAM server for ~110 EUR and that should be able to run around 120 concurrent VMs assuming 1GB of RAM to each (CPU isn't a major issue in this case).
I've long wanted for some sort of mock, "things are broken - I want to see how you think" approach for sysad
As I tend to favorite less often than I comment, it makes it easier to find those things I want to find again.
The HN interface too tends to just have my eyes filter out those links... but that's no defense.
Especially good to know that it's publicly viewable!
Not that I'm particularly worried of being outed by anything I favorite here, it's just good to be mindful of the data we make and where it goes.
Yup, that's what I was afraid of.
Heck, I'm not even asking for an email (and I had to do extra session management coding for that).
We ask the engineer who is proctoring the interview to think about the following question: Would you want to pair with that engineer again?
If that answer is no, then we probably won't go further because pairing with engineers to troubleshoot is what we do every day.
Some great resumes have died with not knowing how to see what's running on port 80.
I wouldn't feel the need to do this if so many candidates didn't fail rudimentary tests. A SWE candidate MUST be able to write the function min(), in the language and tooling of their choice. But in an interview, a sizable fraction cannot. (The actual bar is far higher than min(), ofc., but min() ought to be trivial.)
If the interview was along the lines of upgrading the packages on the system, debugging why nginx was crashing, figuring out the specs of the system, etc. that is totally fine with me and I believe respectful of a candidates time. Unfortunately it always turns into something else when people need to come up with new "challenges" for canidates.
Rejecting someone because they can't recall the correct netstat syntax doesn't seem like good hiring practice, but I assume in good faith that's not what you meant :)
I'm quite happy to try to demonstrate how I think, but I hate hate hate leet code because A) it's not relevant to showing how one thinks and B) I've read so much dunking on it on HN that I'm now stopping interviews when they pull out the hackerrank or live code to say 'without using the library, reverse this linked list'.
And usually you only use a fairly small set of tools that often, in any job, and which set will depend on the employer, how things are set up, and what exactly you're doing.
Oh and somehow I get "-r" versus "-R" for "recursive" wrong almost every time, even for commands I type almost daily, unless I check first. It's weird. If tools could get on the same damn page about which means "recursive", that'd be great.
TL;DR I do have a pretty good idea what I'm doing, but look like an absolute idiot if anyone watches me do it. Much worse, even, if I know they're watching and we're not in some kind of relatively high-trust relationship (so, definitely not in an interview setting).
> My org has run a hands-on technical exam with a stack of linux admin basics ... they are based on real problems we've had and the feedback is overwhelmingly "this was one of the best technical interviews I've ever had."
You essentially answered your own question.
Putting thought into the interview process and working with candidates through real problems is valuable. I cannot say the same for outsourcing or "automating" this portion of an interview using 3rd party SaaS.
One example, is we had them ssh, download & extract a tarball (the Linux source, but the content doesn't matter). Sometimes, they'd gunzip to stdout. The reaction tells you a lot "lol whoopsie" followed by a quick fix: person knows what they're doing. "uh… what is going on? did I break it?" followed with general cluelessness… maybe not.
That did occasionally break tmux, though.
Part of it was "what are the specs of this thing you're SSH'd into?" and we had one candidate who was adamant the numbers must be wrong: 2 GiB is too little RAM, no machine is that small! Yeah we didn't spin up 128 GiB VM for your interview…
Supporting your point: Hardware is awesome if you use it wisely.
It's amazing how bloated today's software is...
Even so, test taking can be stressful but it's arguably less stressful than actual production support with people waiting on the result. Whether people really want to put candidates in a stressful situation is up to them. Sadserver seems like it's somewhere in the middle vs some of the things I've seen. One job interview put me in a room with a boot cd, and an ancient computer with a cdrom so slow you got exactly one chance to boot the media and recover the system in the time limit. But the job was for a trading company, so if you couldn't handle that they didn't want you. It was a fun exercise but would I do that to someone else? Probably not.
[...] Please don't pick the most provocative thing in an article or post to complain about in the thread.
https://news.ycombinator.com/newsguidelines.html
its certainly better than some crappy whiteboarding session, or worse a take home test.
You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/. That will avoid account limits and also keep your AWS costs more predictable.
> You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/. That will avoid account limits and also keep your AWS costs more predictable.
I'd imagine (still waiting for it to load lmao) most of it could be containers too.
I like making jokes with coworkers about implementing this or that bit of infra with WASM-based tools mostly to get a rise out of them but each time I make the joke I look into some of the tools or projects and the balance of joke to "I'm actually serious" shifts a little bit to the right.
trollface.jpg
VMs are designed from the ground up to isolate guests, rather than focusing on application deployment.
Firecracker is the modern container alternative in untrusted compute scenarios, with Fly.io even converting container images into Firecracker VMs.
Generally agreed, but for this use-case do we care?
Also, all container runtimes automatically block unshare(CLONE_NEWUSER) with seccomp already (unless they've disabled seccomp, which I'm not sure if Kubernetes still does).
* Boot problems, such as: GRUB config/install errors, kernel parameters, init startup errors, blocking processes
* Many network scenarios, such as: PXE issues, multipath, load-balacing, anything requiring configuring network interface settings, firewall configuration.
* Resetting an unknown root password
* Booting directly to bash
* Filesystem mounts through fstab or systemd mounts
There's probably more I could think of, but I think that's a good list.
(FWIW I think this is a very cool and fun educational project regardless of what usefulness it might or might not have in IT hiring decisions, and I'm looking forward to playing with it)
If it does
Then renaming bad.log will not solve the challenge.(Yes, these are bad solutions, since the instructions explicitly said to stop the process which is writing.)
https://github.com/copy/v86
Why would you need to understand how something works? Just use containers. /s
[Edited my compensation numbers to avoid down votes - yikes]
My guess is trying to sell high end services as a "principal software engineer" isn't going to be enough to justify that cash comp to a lot of people hiring.
I'd make a list of the companies where hiring/scaling the ops team will make or break the business's value delivery, and filter by companies aware of this.
You can knock this out at the recruiting step, just by asking about open developer headcount vs. open SRE ops headcount. Ask which direction that ratio seems to be going, and if there's anyone you can talk to whose job it is to change that ratio (director or VP mandate).
The referral network from working at a hyperscaler co in ops is a great way to break into the space.
I've been waiting a while for the "sad server" to come up for me and read the scenario (saint john) whilst waiting.
lsof was the first thing that came to mind after reading the scenario.
I guess that once I actually get a "sad server" I'll make it "happy" quickly :)
It seems like this is a similar SaaS.
Are SREs and DevOps tasked with administration of operating systems?
yes, eventually.
you can dress it up in all the fancy terms that you like. but devops and SREs are sysadmins with better PR.
its critical that SREs understand _how_ to debug a system, so that they can work out how to put in fixes, and or design better systems.
You'd get SSH access to the VM, then submit a diagnostic report of what was broken (and how you fixed it).
Reminded me of how Red Hat used to run their certification test (RHCE). I probably still have the live CDs for my RHCE laying around somewhere.
Usually a simple combination of immutable files, SELinux policies, and types in configuration files were enough for most of the challenges. Though now and again you'd find they'd given you a server with packages removed, or not yet installed.
After choosing a problem, the endpoint you poll at https://sadservers.com/celery-progress/xxxx repeatedly returns {pending: true, current: 0, total: 100, percent: 0} for me.