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

Show HN: SadServers – Test your Linux troubleshooting skills

sadservers.com

Post reply on HN
Print view View original

31–40 of 133 posts

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#31

Post by temp0826 »

apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. 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 haven't fully grokked this yet, but one trick I've used in the past to get around limits is AWS Organizations, creating a sub-account per property. A bit more setup but can keep things cleaner administratively.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#32

Post by mathverse »

lbotos wrote: post #24
deeblering4 wrote: post #6

> It's also my not-so-secret hope that a sophisticated enough version of SadServers could be used by tech companies (or for companies that carry on job interviews on their behalf) to automate or facilitate the Linux troubleshooting interview section. Yup, that's what I was afraid of.

Why are you afraid of this? My org has run a hands-on technical exam with a stack of linux admin basics (I won't enumerate them here because people do their research) but 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." We ask the engineer who is proctoring the interview to think about the following question: Would you want to…

People in higher up positions like yourself will rarely be subjected to testing with tools like this. You are basically trying to remove the human from equation and industrialize the whole process.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#33

Post by sshd »

andrewmcwatters wrote: post #30

My only feedback is that this is unrealistic because today developers wouldn’t try to debug something, they’d just destroy the instance, push a commit and hope it fixed something infra related then recreate it. Why would you need to understand how something works? Just use containers. /s

This is so sad but so true!

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#35

Post by ilyt »

apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. 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.

That's kinda nice use case for the WASM machine/linux emulators, then you just need to provide image and user can run it in the browser

> 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.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#36

Post by Nextgrid »

fduran wrote: post #5
vermon wrote: post #3

Seems like it's out of capacity: An error occurred (VcpuLimitExceeded) when calling the RunInstances operation: You have requested more vCPU capacity than your current vCPU limit of 64 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. Maybe something like https://leaningtech.com/webvm-server-les…

Yes, HN effect lol-sob. Mitigation: reducing servers life time temporarily so more people can try.

Scaling this service without breaking the bank could become its own "sad server" scenario.

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).

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#37

Post by icedchai »

temp0826 wrote: post #31
apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. 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 haven't fully grokked this yet, but one trick I've used in the past to get around limits is AWS Organizations, creating a sub-account per property. A bit more setup but can keep things cleaner administratively.

AWS will raise limits if you ask. Increasing EC2 instance limits is usually a quick turn around.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#38

Post by splitstud »

mathverse wrote: post #32
lbotos wrote: post #24

Earlier quoted context omitted.

Why are you afraid of this? My org has run a hands-on technical exam with a stack of linux admin basics (I won't enumerate them here because people do their research) but 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." We ask the engineer who is proctoring the interview to think about the following question: Would you want to…

People in higher up positions like yourself will rarely be subjected to testing with tools like this. You are basically trying to remove the human from equation and industrialize the whole process.

No post body was provided.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#40

Post by ericbarrett »

icedchai wrote: post #37
temp0826 wrote: post #31

Earlier quoted context omitted.

I haven't fully grokked this yet, but one trick I've used in the past to get around limits is AWS Organizations, creating a sub-account per property. A bit more setup but can keep things cleaner administratively.

AWS will raise limits if you ask. Increasing EC2 instance limits is usually a quick turn around.

Yes, the default limits are there to prevent abuse and runaway misconfigurations. They won't turn down revenue if you confirm it's intentional.
Post reply on HN