SadServers Linux & DevOps Troubleshooting Scenarios

Linux & Bash

- Linux commands, Bash scripting
- Systemd
- Networking, DNS
- Storage
- SSH, Firewall
- Libraries
- Cron and more...

Web Servers

- Nginx
- Apache
- HAProxy
- Caddy
- Gunicorn
- uWSGI
- HTTPS/TLS

Databases

- PostgreSQL
- MySQL
- SQLite
- Redis
- ClickHouse
- MongoDB
- etcd

Data Processing

- CSV
- JSON
- SQL queries

Docker

- Building images
- Multi-stage builds
- Volumes
- Networks
- Docker Compose
- Podman

Kubernetes

- kubectl
- Helm
- K8S Roles & Permissions
- Services
- Namespaces
- Deployments, StatefulSets
- ConfigMaps, Secrets

Tooling / Applications

- Git
- Rabbitmq
- Envoy
- Vault
- Harbor
- Prometheus
- Jenkins

Hacking

- Capture the Flag (CTF) Challenges
- Code Vulnerabilities
- Privilege Escalation

Languages

- Python
- Golang
- PHP
- Java
- Node.js
- C

advent2025 apache bash c caddy clickhouse csv data processing disk volumes dns docker envoy etcd git golang gunicorn hack haproxy harbor hashicorp vault helm java jenkins json kubernetes linux-other mongodb mysql nginx node.js php podman postgres prometheus python rabbitmq redis sql sqlite ssh ssl supervisord systemd traefik

realistic / interviews new pro business

Medium

#	Name	Time	Type
1	"San Juan": mucho Traefik	20 m	Fix New	"San Juan": mucho Traefik Scenario: "San Juan": mucho Traefik Level: Medium Type: Fix Access: Email Description: There is a Traefik load balancer that must be up and running. The server and the backend services are managed by Docker Compose. Running `curl -s app.sadserver \| head -n1` must return the host ID of one of the backend servers, running the command again must return a new host ID. The server seems to be working some times, some others fails or just times out. The round-robin configuration should make the webserver iterate through the back-end servers. Test: `curl -s app.sadserver \| head -n1` returns something like `Hostname:` The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute. Time to Solve: 20 minutes.
2	"Suzhou": MongoDB replicas!	20 m	Fix New	"Suzhou": MongoDB replicas! Scenario: "Suzhou": MongoDB replicas! Level: Medium Type: Fix Access: Email Description: A new MongoDB replica set has been setup in the development environment trough `/home/admin/app/rs0.js`, however, a variety or errors are showing up when trying to bring it up. You should bring up all the replica servers, get them communicating to each other and make sure the replica set is working as it should. The status of the first replica can be checked via `systemctl status mongo1` same for the replicas `mongo2` and `mongo3`. The logs are also in a separate file for each replica under the directory `/var/log/mongodb`. To initilize the replica set again: `mongosh --file app/rs0.js` Note: The default configuration file `/etc/mongo.conf` is not the problem. Test: `mongosh --eval "rs.status()" \| grep health` returns the status of all the replicas health: 1, health: 1, health: 1, The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute. Time to Solve: 20 minutes.