Automation Lessons from Manual Deployments to Linux Servers

Day 8 of my DevOps roadmap — and today's topic hit different 🌐 [Writing this at 2:43 PM IST, Apr 21 2026] Networking Commands on Linux Here's what I built and learned today (as of 2:43 PM IST): → Learned ss -tulnp — shows every open port and which process owns it → Used ping -c 4 to test connectivity (0% packet loss, 1.2ms latency ✓) → Curled my own site korelium.org and saw the raw HTML come back in terminal → Built a network_audit.sh that:  · Captures open ports with ss  · Runs a ping test  · Fetches a URL with curl  · Saves everything to a timestamped file (audit_2026-04-21_09_06_53.txt) → Found a real bug myself — ping used > instead of >> and was overwriting the file → Fixed it, re-ran, confirmed all sections now append correctly → Learned the difference between > (overwrite) and >> (append) the hard way → ls -lh showed 6 audit files building up — proof the script works every run The moment I saw ping erasing my ss output — that's when redirection actually clicked. Not just running commands. Understanding what they do to your files. #Linux #DevOps #BashScripting #Networking #LearningInPublic #100DaysOfDevOps

🚀 #100DaysOfDevOps by KodeKloud | Day 4 🔐 Day 4: Script Execution Permissions Today I worked on a simple yet important Linux concept — file permissions and how they impact script execution. 🧩 Task I had to grant executable permissions to a script: /tmp/xfusioncorp.sh on App Server 1, ensuring that all users can execute it. 🛠️ Steps I followed 1️⃣ Switched to root user from jump host: sudo -i 2️⃣ Connected to App Server 1: ssh stapp01 3️⃣ Checked existing permissions: ls -l /tmp/xfusioncorp.sh 4️⃣ Granted proper permissions: chmod 755 /tmp/xfusioncorp.sh 5️⃣ Verified the result: -rwxr-xr-x ⚠️ Issues I encountered ❌ Initially used: chmod a+x But it resulted in: r--r-x--x 👉 The owner didn’t have proper execute permission in expected format 👉 This caused the task validation to fail 💡 Learned that just adding execute (x) is not always enough — sometimes I need to explicitly set correct permission structure ✅ Key Learning ✔ File permissions matter more than they look ✔ Understanding rwx is crucial for Linux & DevOps ✔ Always verify using ls -l before submitting ✔ When in doubt, chmod 755 is a safe and common approach 🔥 Small task, big learning! If you're starting your DevOps journey, I highly recommend KodeKloud for hands-on labs 👇 https://lnkd.in/deg5ZDcV #DevOps #Linux #KodeKloud #LearningInPublic #CloudComputing #100DaysChallenge

We literally used sudo in the last lecture… And no one asked why. That’s the problem. Most people learning Linux for DevOps don’t actually learn things… They just follow along. Run this command. Copy that step. It works - so they move on. Until one day… Production says: Permission denied. And suddenly: – Commands stop working – Logs are inaccessible – Panic starts Because now it’s not about what to type It’s about who you are in the system User? sudo user? root? That difference decides everything. I’ve seen engineers who know Docker, Kubernetes, CI/CD… But still get stuck on something as basic as privileges. Not because it’s hard - But because no one explained it properly. So instead of just using sudo again… We stopped. And broke it down: – What actually happens when you run sudo – Why switching to root is risky – When to use su vs sudo in real systems Because DevOps is not about running commands. It’s about understanding control. And in Linux… control starts with privileges. If you’ve ever used sudo without thinking… You should probably watch this one. Link in comments 👇 #Linux #DevOps #CloudComputing #SystemDesign #AWS #DevOpsEngineer #LinuxCommands #TechCareers #Programming

#Day3 Essential Linux Commands Every DevOps Engineer Must Know 🚀 The command line is the backbone of every DevOps workflow. Today I covered 15 must-know Linux commands — grouped by category for clarity! 📁 Navigation 🔹 pwd — Print current working directory 🔹 ls — List files in current directory 🔹 ls -l — Detailed list with permissions & size 🔹 ls -la — Show hidden files with full details 🔹 uname — Display system & kernel information 🗂️ File Operations 🔹 touch — Create a new empty file 🔹 mkdir — Create a new directory 🔹 rmdir — Remove an empty directory 🔹 rm -r — Recursively delete files & directories 🔹 --help — Deep dive into any command's usage 👁️ View & Move 🔹 cat — Display file contents in terminal 🔹 mv — Move or rename files & directories 🔹 cp — Copy files or directories 🌐 Search & Network 🔹 grep — Search patterns inside files 🔹 curl — Transfer data from URLs / APIs 🔹 wget — Download files from the internet 💡 Pro Tip: Combine grep with pipes — cat file.log | grep "error" — to instantly filter large files like a pro! 💡 Key Takeaway: These 15 commands are the foundation of every DevOps workflow. Master them and you'll navigate, manage, and automate any Linux server with speed and confidence. #DevOps #Linux #LinuxCommands #Bash #SysAdmin #CloudEngineering #LearningInPublic #CareerGrowth

Bash Scripting for DevOps — Part 11/? Till now, I was passing values using environment variables. That worked. But I realized something. Sometimes, I don’t want to set variables separately.I just want to pass values directly when running the script. That’s where arguments come in. In Bash, we can pass values like this: ./deploy.sh staging Inside the script, we can access it using: echo "Deploying to $1 environment" Here, $1 means the first argument. So if I run: ./deploy.sh prod It becomes: Deploying to prod environment This makes scripts much more flexible. Instead of editing the script or setting variables, I can just pass what I need at runtime. This is used a lot in real DevOps workflows: • passing environment names • passing versions or tags • controlling script behavior dynamically Small change. But now the script feels more like a real tool, not just a fixed set of commands. #DevOps #BashScripting #Linux #Automation #DevOpsJourney #LearningInPublic

Ever typed the same Linux commands again and again and thought, “There has to be a better way”? That is exactly where shell scripting starts to make sense. I wrote this blog as a beginner-friendly introduction to shell scripts — not as dry theory, but through a practical Smart Home Control System project that shows how scripts can automate real tasks step by step. In this blog, you’ll learn: 1) What a shell script actually is 2) Why #!/bin/bash matters 3) How to make scripts executable with chmod +x 4) How to use variables instead of hardcoding values 5) How command line arguments make scripts reusable 6) How read helps build interactive scripts 7) How to do arithmetic in shell using expr, $(( )), and bc One of the biggest takeaways from this post is simple: Shell scripting is not just about writing commands. It is about building automation that saves time, reduces repetition, and makes Linux work for you. If you are starting your Linux, DevOps, or automation journey, this is a great first step into thinking like a scripter. Read the full blog here: https://lnkd.in/grgWN5vB What should I write about next? Feel free to comment below & I’ll try to create a post on your suggestion within a day. I can cover topics like: Git, Ansible, Jenkins, Groovy, Terraform, AWS, Networking, Linux, DevOps practices, Cloud architecture, CI/CD pipelines, Infrastructure as Code, or anything related. If you find the content useful, please share it with your network and drop a like 👍 it really helps these posts reach more Linux, DevOps, and Cloud folks. Your likes and shares are what keep me motivated to keep writing consistently. Thanks in advance for your ideas and support! #Linux #ShellScripting #Bash #DevOps #Automation #LinuxBasics #LearningLinuxBasics #Scripting #SystemAdministration

🐳 Docker Compose Essential Training — Engine v29 | Compose v5 Hands-on Lab I just published Guide #2 of the Essential Training Series — a practical, hands-on Docker Compose lab that I personally tested command by command before sharing. 📋 What's inside: • 8 exercises covering the core Docker Compose fundamentals • Services, networks, volumes and environment management • Build workflows with Dockerfile and live reload • Health checks and correct startup ordering • Profiles for optional services • Scaling services and resource limits • Debugging with logs, exec and compose config 🔧 Tested on: • Docker Engine v29.4 — Compose v5.1.2 (latest) • WSL2 on Windows — HP i3, 20GB RAM • Real commands, real errors, real fixes This is not a copy-paste from the docs. Every exercise was validated hands-on before being shared. 📎 PDF attached — free to download and use. 📁 Exercise files on GitHub: https://lnkd.in/dhVQ5BVN 🚀 More coming soon: ✅ Docker ✅ Docker Compose (this one) ✅ K3s ⏳ Helm ⏳ GitHub Actions CI/CD ⏳ ArgoCD (GitOps) ⏳ Prometheus & Grafana ⏳ Loki + OpenTelemetry If this is useful — share it with someone learning DevOps 🙌 If it is not — drop a comment or send me your feedback. I am still improving it. #DockerCompose #Docker #DevOps #Kubernetes #CloudNative #Linux #LearningInPublic #OpenSource

#Day_9 – Mastering Shell Scripting Basics (Linux & DevOps) Today, I went deeper into Shell Scripting, and now I can build more practical and useful scripts. 💡 What I learned today (in very simple terms): 🔹 Conditional Logic (Advanced) if-elif-else – handle multiple conditions case – cleaner way to handle options Makes scripts more dynamic 🔹 Arguments in Scripts $1, $2 – take input from command line $# – number of arguments $@ – all arguments Helps create flexible scripts 🔹 Scheduling with Cron Jobs crontab -e – schedule tasks Run scripts automatically at fixed time Very useful in automation 🔹 Logging & Debugging Store output in log files Use set -x for debugging Track errors easily 🔥 What I realized today: Shell scripting is a powerful automation tool Scheduling tasks saves a lot of manual effort Real DevOps work depends on automation + monitoring Excited to move towards advanced DevOps tools next 🚀 Let’s keep learning and growing 💪 #Linux #DevOps #ShellScripting #Day9 #LearningInPublic #ITSkills #CareerGrowth

Bash Scripting for DevOps — Part 10/? Till now, my scripts worked. But everything inside them was hardcoded. So every time I wanted to run it for a different environment, I had to go and change the script. That didn’t feel right. In real DevOps workflows, we don’t change the script. We change the environment. For example: ENV=staging ./deploy.sh Inside the script: echo "Deploying to $ENV environment" Now the same script works for dev, staging, and prod without changing the code. Just by changing the input. Small change in approach, but this is what makes scripts flexible and reusable. And this is used everywhere — CI/CD, Docker, Kubernetes. #DevOps #BashScripting #Linux #Automation #DevOpsJourney #LearningInPublic

Managing logs on Linux sounds simple… until it isn’t. While working on systems, I noticed how quickly things can go wrong: * Disk fills up without warning * Thousands of small files eat space silently * Manual cleanup feels risky * And there’s no clear visibility into what actually changed So I built something to solve this properly. I created a **production-style Linux log cleanup tool in Bash** — not just to delete logs, but to make the process safe, visible, and automated. Here’s what it does: 🔹 Runs in **dry-run mode by default** (no accidental deletions) 🔹 Cleans logs using **time + size based strategies** 🔹 Handles both **journalctl logs and custom directories** 🔹 Uses a **lock mechanism** to prevent concurrent runs 🔹 Sends **Slack & Email notifications** after execution 🔹 Supports **cron automation** for scheduled cleanup 🔹 Provides a clear summary of what changed But the real learning came from the challenges: * Handling permissions for `/var/log` * Dealing with limitations of `journalctl` * Debugging email setup with `msmtp` * Designing everything around **safety first** This project helped me understand something important: 👉 Writing scripts is easy. 👉 Building something that behaves safely in production is not. If you’re into DevOps or system engineering, I’d love your feedback. Link in comment #DevOps #Linux #Bash #Automation #SRE #CloudEngineering #OpenSource #SystemDesign #LearningInPublic #Engineering