DEV Community

Cover image for Week 1 of KodeKloud’s 100 Days Challenge: Days 1-4 (Or: How I Learned to Stop Worrying and Love the Slow Labs
Elijah
Elijah

Posted on • Originally published at elijahu.me

Week 1 of KodeKloud’s 100 Days Challenge: Days 1-4 (Or: How I Learned to Stop Worrying and Love the Slow Labs

#devops #linux #kodekloud #100daysofcode 
I decided to torture myself with KodeKloud's 100 Days of DevOps challenge. The VMs load slower than continental drift, but the hands-on Linux practice is actually solid.

Here's what I learned (and broke) in my first four days.

**Day 1: Non-Interactive Users**

The challenge was to create a user with a non-interactive shell.

```

bash
sudo useradd -s /usr/sbin/nologin username
getent passwd username
Enter fullscreen mode Exit fullscreen mode

The mistake? I ran all these commands on the wrong host. Spent 10 minutes wondering why validation wasn't working before realizing I was on my local terminal instead of SSH'd into the lab.

Lesson learned: Always double-check which host you're on. Run hostname first.

Day 2: Temporary Users

The challenge was to create a user account with an expiration date.


bash
sudo useradd anita -e 2023-06-05
chage -l anita
Enter fullscreen mode Exit fullscreen mode

This creates a ticking time bomb account—perfect for temporary contractors or intern access.

Bonus trick: Auto-lock account after 20 minutes:


bash
echo "usermod --lock username" | at now + 20 minutes
Enter fullscreen mode Exit fullscreen mode

The mistake? Did it on the wrong host. Again. 🤦

Day 3: Disabling Root SSH

The challenge was to disable root login across multiple servers.

Manual approach:


bash
sudo vi /etc/ssh/sshd_config
# Change: #PermitRootLogin no → PermitRootLogin no
sudo systemctl restart sshd
Enter fullscreen mode Exit fullscreen mode

Problem: I had to do this on three servers manually. Each SSH connection took 30 seconds—enough time to make coffee, question my life choices, and consider farming.

Automation solution:


bash
for server in app1 app2 app3; do
    ssh $server "sudo sed -i 's/#PermitRootLogin no/PermitRootLogin no/' /etc/ssh/sshd_config && sudo systemctl restart sshd"
done
Enter fullscreen mode Exit fullscreen mode

My 30-minute nightmare became a 2-minute coffee break.

Lesson learned: If you're doing something more than twice and it's boring, automate it.

Day 4: File Permissions

The challenge was to make a script executable for all users.


bash
chmod 755 /tmp/xfusioncorp.sh
ls -l /tmp/xfusioncorp.sh
Enter fullscreen mode Exit fullscreen mode

Output: -rwxr-xr-x

Permission breakdown:

  • 7 (rwx) = full access for owner
  • 5 (r-x) = read and execute for group
  • 5 (r-x) = read and execute for others

Common patterns worth memorizing:


bash
chmod 644 file.txt    # Owner: rw, Others: r
chmod 755 script.sh   # Owner: rwx, Others: rx
chmod 600 secret.txt  # Owner: rw, Others: nothing
Enter fullscreen mode Exit fullscreen mode

Week 1 Stats

  • Commands run: ~50
  • Wrong host mistakes: 2
  • Lab loading time: ~5 min/lab
  • "Why isn't this working?" moments: 7
  • Times I questioned my career: 3

Key Takeaways

Commands I now know by heart:


bash
useradd -s /usr/sbin/nologin username
chage -l username
chmod 755 script.sh
Enter fullscreen mode Exit fullscreen mode

Mistakes that taught me:

  1. Always check hostname before running commands
  2. Automate anything you do more than twice
  3. Lab speed ≠ learning speed

What's Next

Days 5-8 are coming up:

  • Package management (yum, apt, dnf)
  • Service management (systemctl deep dive)
  • Cron jobs and scheduling
  • More automation

Full Article

This is a condensed version. For the complete writeup with more details, code examples, and commentary:

👉 Read the full article on my blog

Following this challenge? Drop your biggest "wrong host" moment in the comments. I can't be the only one. 😅

Top comments (0)