Earlier quoted context omitted.
Why not spin up containers instead of VMs? Seems to me containers would fit much better than VMs.
If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?
Show HN: SadServers – Test your Linux troubleshooting skills
121–130 of 133 posts
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#122Earlier quoted context omitted.
> Containers have a history of escape vulnerabilities Generally agreed, but for this use-case do we care?
I haven’t gotten any of the challenges to load, but if you’re going to simulate a sysadmin it would make sense to give you high privileges (or even root) on the box. The more privileged you are inside a container, the more attack surface you expose.
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#123Earlier quoted context omitted.
Replace it with a symlink to /dev/null! Or /dev/full if we feel like it. (Yes, these are bad solutions, since the instructions explicitly said to stop the process which is writing.)
It will still keep writing to an open inode
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#124New challenge: Fix SadServers’ sad servers
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#125Earlier quoted context omitted.
If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?
Can you give me an example of some of the severe limitations you're mentioning?
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#126Earlier quoted context omitted.
Can you give me an example of some of the severe limitations you're mentioning?
I don't think the DNS exercise would behave the same although that probably depends on how the container was setup. Docker usually controls /etc/resolv.conf. Another exercise is "try to figure out if you're in a container or VM so that'd definitely be different"
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#127Earlier quoted context omitted.
If you give the person you're interviewing access to the same tools they'd have in a regular day on the job (Google, manpages, etc.), I'd say that's a fair and probably relatively enjoyable interview. 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 :)
Exactly, all man pages and google is fair. We want to see how they think not rote memorization .
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#128Earlier quoted context omitted.
Cloudflare exists
I thought Cloudflare only ensures high usage of the free tier for "web"-ish responses, which doesn't even include .txt files. But I suppose this use case is several orders of magnitude away from that of EasyList, at least in request rate.
Re: Show HN: SadServers – Test your Linux troubleshooting skills
#129Earlier quoted context omitted.
If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?
Can you give me an example of some of the severe limitations you're mentioning?
* 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.