Cron Jobs on Linux with Cronie and Stratos Datacenter

One of the most powerful aspects of Linux is how efficiently it handles **search operations and file permissions**. In real-world DevOps and server administration, these two concepts are used almost every day. 🔍 **Search Commands in Linux** Finding files, logs, or configurations quickly is crucial while working on servers. Some of the most commonly used commands are: `find` → Used to search files and directories based on name, type, size, or modified time Example: `find /home -name "*.log"` `grep` → Used to search for a specific word, pattern, or text inside files Example: `grep "error" application.log` `locate` → Quickly finds file paths from the system database Example: `locate nginx.conf` These commands make troubleshooting and log analysis much faster in production environments. 🔐 **Permission Commands in Linux** Linux permissions decide **who can read, write, or execute a file**. Each permission has a numeric value: `r = 4` → Read permission `w = 2` → Write permission `x = 1` → Execute permission These values are added together to form permission codes. For example: `7 = 4 + 2 + 1` → `rwx` `6 = 4 + 2` → `rw-` `5 = 4 + 1` → `r-x` `4 = 4` → `r--` So when we use: `chmod 755 file.sh` It means: Owner → `7` = `rwx` Group → `5` = `r-x` Others → `5` = `r-x` Understanding permissions is essential for security, script execution, and access control in Linux-based environments. Linux is not just about commands — it’s about control, security, and efficiency. #Linux #DevOps #CloudComputing #AWS #SystemAdministration #ServerManagement #Automation #SoftwareEngineering #Infrastructure #LinuxCommands #CareerGrowth #Technology #DevopsWithMultiCloud #flm #frontlinesmedia

🚀 Built a Complete Monitoring Stack using Prometheus + Grafana (Hands-on Project) Recently, I set up a real-time monitoring system across multiple Linux servers — a practical deep dive into observability and troubleshooting. 💡 What I implemented: ✅ Connected to 5 remote servers via SSH (custom ports + troubleshooting) ✅ Installed and configured Prometheus (LTS version) ✅ Deployed Node Exporter to collect system metrics (CPU, Memory, Disk, Network) ✅ Configured Prometheus scrape targets ✅ Set up Grafana and integrated Prometheus as a data source ✅ Built clean, real-time dashboards 🔧 Challenges I faced & solved: • SSH timeout → Debugged using ping + port checks • Prometheus not accessible → Fixed firewall (port 9090) • Background service issue → Used nohup for persistence • YAML config errors → Fixed structure & indentation • Grafana not loading → Opened port 3000 + verified service • Wrong datasource → Corrected endpoint configuration 📊 Final Outcome: ✔ Real-time monitoring dashboards ✔ Centralized metrics across multiple nodes ✔ Strong hands-on experience in Linux + networking troubleshooting 📌 Tech Stack: Prometheus | Grafana | Node Exporter | Linux | SSH | Networking | Monitoring 💭 What I learned: 👉 Monitoring isn’t just dashboards — it’s about visibility + fast troubleshooting 👉 Small misconfigurations (ports, YAML, endpoints) can break entire systems 👉 Observability is critical for reliability in production environments 🔥 Next Steps: Alerting (Alertmanager) • Log aggregation • Kubernetes monitoring #DevOps #Prometheus #Grafana #Monitoring #Observability #SRE #Linux #CloudComputing #Infrastructure #Automation #Networking #OpenSource #TechProjects #LearningByDoing #BuildInPublic

🚀 Understanding Linux Directory Structure If you're starting your journey in DevOps or system administration, mastering the Linux file system is a must. Here's a quick breakdown of key directories every engineer should know: 📁 /bin – Essential system binaries 📁 /boot – Boot loader files 📁 /dev – Device files 📁 /etc – Configuration files 📁 /home – User directories 📁 /lib – Libraries & kernel modules 📁 /media – Removable media mount points 📁 /mnt – Temporary mounts 📁 /opt – Optional software 📁 /proc – Process & kernel info 📁 /root – Root user home 📁 /run – Runtime data 📁 /sbin – System binaries (admin) 📁 /srv – Service data 📁 /tmp – Temporary files 📁 /usr – User programs & data 📁 /var – Logs & variable data 💡 Knowing where things live in Linux makes troubleshooting, automation, and system management much easier. #Linux #DevOps #Cloud #SysAdmin #Learning #TechBasics #Infrastructure #SRE

🔐 Day 4 of #100DaysOfDevOps — Linux file permissions Today's task: a backup script existed on a production server but no one could run it. One missing permission bit was the culprit. Here's what I learned: Every Linux file has a 10-character permission string like -rw-r--r-- It's split into 3 groups: → Owner (the user who created it) → Group (a team sharing access) → Others (everyone else) Each group gets 3 bits: r (read=4), w (write=2), x (execute=1) The fix was one command: chmod a+x /tmp/xfusioncorp.sh or chmod 755 /tmp/xfusioncorp.sh a = all users | +x = add execute permission Before: -rw-r--r-- (no one can run it) After: -rwxr-xr-x (everyone can run it) Why does this matter in DevOps? → Automation scripts fail silently when permissions are wrong → CI/CD pipelines break if deploy scripts aren't executable → Every cloud server you ever manage will need this The numeric equivalent: chmod 755 Meaning: owner gets rwx (7), group gets r-x (5), others get r-x (5) "r = read, w = write, x = execute. Three bits. Three groups. That's all of Linux permissions." #DevOps #Linux #BashScripting #chmod #CloudEngineering KodeKloud

Pulling the plug on a running server is how you corrupt database writes, drop active users mid-session, and lose in-flight messages. The right way to shut down a server is to let it finish what it started. This is called a graceful shutdown. Let's have a detailed look at graceful shutdown. The three signals worth knowing: SIGTERM - sent by process managers and container runtimes; your application can catch it, finish work, and exit cleanly SIGINT - triggered by Ctrl+C in a terminal; behaviorally the same as SIGTERM for most applications SIGKILL - cannot be caught or ignored; the kernel terminates the process immediately with no cleanup window When a process receives a SIGTERM (the polite shutdown signal from orchestrators like Kubernetes or systemd), it should stop accepting new connections immediately and focus on finishing active requests. This transition is known as connection draining. The length of time you allow for this process is called the drain timeout, and you should set it based on your service's typical request duration and your specific performance goals. Once active requests are done, cleanup begins. The order here matters: tear down resources in reverse initialisation order. If your server opened a database connection pool and then a message queue consumer, shut down the consumer first, then drain and close the pool. Cleaning up in the wrong order means a component tries to use a dependency that no longer exists. SIGKILL is the last resort, equivalent to pulling the plug. If your service is still running 30 seconds after SIGTERM, the orchestrator sends SIGKILL. The best way to avoid that is to make your SIGTERM handler fast and correct. Graceful shutdown is one of those things that feels like an edge case until you're debugging a production incident at 2 a.m., wondering why half your users got a 500 during a routine deploy. #backend #systemdesign #linux #softwaredevelopment #devops

sos-vault 2.0.0 is now released. sos-vault is a platform for storing, exploring, and analyzing Linux sosreports — making it easier for support, SRE, and operations teams to troubleshoot systems, collaborate, and produce structured findings. This is not a minor update — the platform has been rebuilt and extended: • New UI (fully redesigned) • Compare tools (directory + file level) • Improved File Viewer (Table mode + Raw mode with annotations) • Expanded Summary dashboard (now includes TCP/IP statistics) • Issue reports now include team annotations and activity logs • File Lists to group and open bookmarks instantly New plans: • Teams (shared vault, up to 8 users) • Enterprise (up to 20 users, expandable) • Yearly subscriptions available Integrations: • Jira / JSM • CI/CD-friendly automatic upload and unpacking A self-hosted version is in progress, expected in the coming months. If you tried v1, this release significantly changes the experience. Feedback is welcome. #sos-vault #sosreport #linux #diagnostics #troubleshooting #devops #sre #sysadmin

Stop wasting 3 hours every week on repetitive server tasks. When I first started managing Linux servers, I used to manually run backups every night until I discovered the hidden superpower of automation. If you aren't using cron jobs, you are essentially choosing to work harder than you need to. 🐧 * Set it once: You define the exact minute, hour, and day for your script to trigger automatically. * Zero mistakes: Unlike humans, a cron job never forgets to run a security patch at 3:00 AM. * Total control: You can schedule everything from simple disk cleanups to complex database syncs. Mastering this syntax is the fastest way to reclaim your time and start operating like a senior engineer. 🚀 Which manual task would you automate first if you had an extra hour today? _________ Follow for more and let's grow together Muhammad Hashim #Linux #DevOps #Automation #Coding #Engineering

DevOps often looks impressive from the outside. • Cloud dashboards • Automation scripts • Modern web interfaces • CI/CD pipelines Everything appears fast, advanced, and seamless 🚀 But when something breaks in production… We go back to the basics: • Connecting to servers via SSH • Analyzing logs in /var/log • Running Linux commands to debug issues • Writing quick Bash scripts to resolve problems And that’s when an important realization hits — Behind every sophisticated cloud platform and automation tool, there are still core fundamentals: • Linux • Bash • CLI tools Quietly powering the entire system. No fancy UI. No colorful dashboards. Just a terminal… and the knowledge to use it effectively. Lesson learned: You might overlook Linux and Bash at the beginning, but sooner or later — the terminal becomes unavoidable. #DevOps #Linux #Bash #CloudComputing #AWS #Automation #CloudEngineer #TechJourney

🖥️ Day 10 of #100DaysOfDevOps — Writing my first website backup automation script Today's task: write a bash script that automatically zips a website's media directory and copies it to a remote storage server — with zero password prompts and zero manual steps. The complete script: #!/bin/bash # Zip the media directory zip -r /backup/xfusioncorp_media.zip /var/www/html/media # Copy to storage server (passwordless SSH) scp /backup/xfusioncorp_media.zip natasha@ststor01:/backup/ Two lines. But here's everything that had to be in place for those two lines to work: → #!/bin/bash (shebang) Tells the OS which interpreter to run this file with. Without it, nothing works. → zip -r The -r flag means recursive — it includes every file and subfolder inside the media directory. Without -r your backup would be empty. → scp over passwordless SSH SCP copies files between servers over SSH. No password prompt because banner's SSH keys are already in natasha's authorized_keys — set up on Day 7. → No sudo inside the script Automation scripts must never use sudo — they break in cron jobs and CI/CD pipelines. Instead I fixed directory ownership before running the script: sudo chown banner:banner /backup sudo chown banner:banner /scripts → chmod +x to make it executable Remember Day 4? A script without execute permission is just a text file. Everything from the past 10 days came together in this one task: Day 4 → chmod to make the script executable Day 7 → SSH keys so scp works silently Day 6 → cron will schedule this script #DevOps #BashScripting #Linux #Automation #Backup #CloudEngineering KodeKloud

Building a High Availability cluster on Linux? Then you’ve likely run into the ARP Problem—where multiple servers try to claim the same Virtual IP (VIP), causing traffic chaos. 😵💫 This technical breakdown for DevOps and Network Engineer pros explains how to automate the fix using Ansible. 🛠️ 1️⃣ The ARP race is real 🏁 In a Layer 4 Direct Server Return (DSR) setup, the VIP sits on the loopback interface of every real server. Without the right configuration, these servers will fight to answer ARP requests meant for the load balancer, leading to intermittent connection drops and flapping. 2️⃣ Don't just patch—automate with Ansible 🤖 Manually editing sysctl.conf across a 20-node cluster is a recipe for human error. By using the ansible.posix.sysctl module, you can ensure arp_ignore and arp_announce settings are applied consistently and persist across reboots. 3️⃣ The winning config ✅ To silence the loopback and let the load balancer do its job, you need two specific settings on your backend servers: • net.ipv4.conf.all.arp_ignore = 1 (Only reply if the target IP is on the incoming interface) • net.ipv4.conf.all.arp_announce = 2 (Use the best local address for the target) If you're tired of manual network troubleshooting, this Ansible approach is a game changer for cluster stability. Check out the full guide and the playbook code here: https://bit.ly/4cPyZtI #Linux #Ansible #SysAdmin #LoadBalancing #DevOps #Networking #Automation #HighAvailability