Linux Complete Capstone: Production Server Build, Secure, Monitor आणि Fix करण्याचे Linux Admin Labs

By Ravindra Bagale, trainer · LinkedIn · Last updated: 26 October 2026

1. रोजचं उदाहरण: नवीन clinic उघडणे

हे का लागतं?

डॉ. कुलकर्णी कोथरूडमधे छोटं clinic उघडतात. आधी जागा तयार होते: rooms, वीज, furniture, reception computer. मग ती secure होते: कुलपं, CCTV camera, औषधांसाठी किल्लीचं कपाट. मग monitor होते: reception वर register, vaccines साठी fridge thermometer, रोजचा check. रुग्णांच्या files रोज संध्याकाळी photocopy करून घरी ठेवतात. आणि काही बिघडलं, fuse, गळणारा नळ, तर staff ला माहीत असतं कोणाला call करायचं आणि आधी काय तपासायचं.

हे काय आहे?

Clinic build = install, users, storage, packages आणि app. कुलपं आणि CCTV = SSH keys, firewall, SELinux आणि auditd. Register आणि thermometer = metrics, logs आणि alerts. संध्याकाळच्या photocopies = backups. कोणाला call करायचं हे माहीत असणे = runbooks आणि break-fix skills.

कसं करायचं (step by step)

2. Capstone brief आणि build plan

हे का लागतं?

खरे admins लगेच commands type करायला सुरुवात करत नाहीत. एका page चा plan rework टाळतो आणि server repeatable बनवतो.

हे काय आहे?

Brief: Shree Traders या पुण्याच्या distributor ला internal orders web app हवं आहे. Requirements: 2 vCPU, 4 GB RAM, 20 GB OS disk आणि 10 GB data disk असलेली Rocky Linux 9 VM; port 8000 वरच्या छोट्या Python app समोर nginx; data LVM वर /srv/app मधे; फक्त SSH key logins; firewall 22 (फक्त office subnet), 80 आणि 443 साठी open; 14 दिवस ठेवलेले daily backups; disk 80 टक्के पार गेला किंवा app health check fail झाला की alerts. हा plan आधी लिहा आणि /root/PLAN.md मधे ठेवा.

कसं करायचं (step by step)

1. सुरुवातीला server facts नोंदवा.

hostnamectl | egrep 'Static|Operating|Kernel'; nproc; free -h | awk '/Mem/{print $2}'; lsblk -dno NAME,SIZE

Output:

   Static hostname: localhost
  Operating System: Rocky Linux 9.4 (Blue Onyx)
            Kernel: Linux 5.14.0-427.el9.x86_64
2
3.6Gi
vda 20G
vdb 10G

याचा अर्थ: Plan शी जुळतं: 2 CPUs, सुमारे 4 GB, आणि extra 10 GB disk vdb.

2. Hostname, time zone आणि time sync set करा.

sudo hostnamectl set-hostname orders01.shree.local; sudo timedatectl set-timezone Asia/Kolkata; sudo systemctl enable --now chronyd; chronyc tracking | grep -E 'Reference|System time'

Output:

Reference ID    : A29FC801 (time.cloudflare.com)
System time     : 0.000012 seconds fast of NTP time

याचा अर्थ: Logs, TLS आणि backups साठी बरोबर वेळ महत्त्वाची.

3. इतर काहीही आधी पूर्ण patch करा आणि नव्या kernel मधे reboot करा.

sudo dnf -y upgrade >/dev/null; sudo needs-restarting -r; echo rc=$?

Output:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.
rc=1

याचा अर्थ: rc=1 म्हणजे reboot हवा; server अजून live नसताना आत्ताच reboot करा.

3. Build: users, sudo आणि storage

हे का लागतं?

Shared root logins आणि OS disk वरचा data ही messy, unsafe servers ची दोन सर्वात common कारणं.

हे काय आहे?

Sudo सह admins group मधे नाव असलेले admin accounts बनवा, application चा owner असणारा locked service account app बनवा, आणि application data स्वतःच्या LVM volume वर ठेवा म्हणजे तो वाढू शकेल आणि वेगळा backup होईल. XFS वापरा, UUID ने mount करा आणि reboot आधी mount -a ने verify करा.

कसं करायचं (step by step)

1. Admins आणि service account बनवा.

sudo groupadd admins; sudo useradd -m -G admins ravi; sudo useradd -m -G admins asha; sudo useradd -r -m -d /srv/app -s /sbin/nologin app; echo '%admins ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/admins; sudo visudo -cf /etc/sudoers.d/admins

Output:

%admins ALL=(ALL) ALL
/etc/sudoers.d/admins: parsed OK

याचा अर्थ: नाव असलेली माणसं, group rule, आणि login न करू शकणारा service user.

2. Data disk वर LVM बनवा.

sudo pvcreate /dev/vdb; sudo vgcreate vg_data /dev/vdb; sudo lvcreate -n lv_app -L 6G vg_data; sudo mkfs.xfs -q /dev/vg_data/lv_app; sudo lvs vg_data

Output:

  Physical volume "/dev/vdb" successfully created.
  Volume group "vg_data" successfully created
  Logical volume "lv_app" created.
  LV     VG      Attr       LSize
  lv_app vg_data -wi-a----- 6.00g

याचा अर्थ: नंतर वाढवायला VG मधे 4 GB free ठेवले.

3. Persistently mount करा आणि ownership आणि SELinux label fix करा.

u=$(sudo blkid -s UUID -o value /dev/vg_data/lv_app); echo "UUID=$u /srv/app xfs defaults,nodev,nosuid 0 0" | sudo tee -a /etc/fstab; sudo mount -a; sudo chown app:app /srv/app; sudo restorecon -Rv /srv/app; findmnt /srv/app

Output:

UUID=8c2e... /srv/app xfs defaults,nodev,nosuid 0 0
TARGET   SOURCE                       FSTYPE OPTIONS
/srv/app /dev/mapper/vg_data-lv_app xfs    rw,nosuid,nodev,relatime

याचा अर्थ: nodev आणि nosuid data mount वर safety वाढवतात.

4. Build: systemd आणि nginx सह app deploy करा

हे का लागतं?

Terminal मधे हाताने चालवलेलं app logout केल्यावर मरतं आणि crash किंवा reboot नंतर restart होत नाही.

हे काय आहे?

Python आणि nginx install करा, app /srv/app मधे ठेवा, app user खाली 127.0.0.1:8000 वर Restart=on-failure आणि basic hardening सह systemd service म्हणून चालवा, आणि समोर port 80 वर nginx ठेवा. nginx proxy करू शकावा म्हणून SELinux ला httpd_can_network_connect boolean लागतो.

कसं करायचं (step by step)

1. Packages आणि छोटं app install करा.

sudo dnf -y install nginx python3 >/dev/null; sudo -u app tee /srv/app/app.py >/dev/null <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        body = b'ok' if self.path == '/health' else b'Shree Traders orders'
        self.send_response(200); self.end_headers(); self.wfile.write(body)
HTTPServer(('127.0.0.1', 8000), H).serve_forever()
PY
ls -l /srv/app/app.py

Output:

-rw-r--r--. 1 app app 297 Oct 26 11:20 /srv/app/app.py

याचा अर्थ: Monitoring साठी /health endpoint असलेलं stand-in app.

2. Hardening सह systemd unit बनवा.

sudo tee /etc/systemd/system/orders.service >/dev/null <<'U'
[Unit]
Description=Shree orders app
After=network-online.target
[Service]
User=app
WorkingDirectory=/srv/app
ExecStart=/usr/bin/python3 /srv/app/app.py
Restart=on-failure
RestartSec=3
NoNewPrivileges=yes
ProtectSystem=strict
ReadWritePaths=/srv/app
PrivateTmp=yes
[Install]
WantedBy=multi-user.target
U
sudo systemctl daemon-reload; sudo systemctl enable --now orders; curl -s 127.0.0.1:8000/health

Output:

ok

याचा अर्थ: App आता boot वर सुरू होतं, crash वर restart होतं आणि /srv/app बाहेर लिहू शकत नाही.

3. समोर nginx ठेवा.

sudo tee /etc/nginx/conf.d/orders.conf >/dev/null <<'N'
server { listen 80; server_name orders01.shree.local;
  location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; } }
N
sudo setsebool -P httpd_can_network_connect on; sudo nginx -t && sudo systemctl enable --now nginx; curl -s localhost/

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Shree Traders orders

याचा अर्थ: Reload आधी nginx -t, आणि -P मुळे boolean persistent.

5. Secure: SSH, firewall आणि SELinux

हे का लागतं?

Public server online आल्यावर काही minutes मधे SSH password-guessing attempts येतात.

हे काय आहे?

फक्त SSH keys वापरा, root login आणि passwords बंद करा, फक्त admins group allow करा, आणि पहिलं session बंद करण्याआधी दुसऱ्या session मधून test करा. firewalld rich rules ने फक्त office subnet साठी 22 आणि सगळ्यांसाठी 80/443 उघडा. SELinux enforcing ठेवा आणि denials तपासा.

कसं करायचं (step by step)

1. Drop-in file ने sshd harden करा.

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null <<'S'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups admins
MaxAuthTries 3
S
sudo sshd -t && sudo systemctl reload sshd; sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|allowgroups'

Output:

permitrootlogin no
passwordauthentication no
allowgroups admins

याचा अर्थ: आधी sshd -t; नवं session test करताना सध्याचं session उघडं ठेवा.

2. SSH office subnet पुरतं मर्यादित करा आणि web ports उघडा.

sudo firewall-cmd --permanent --remove-service=ssh; sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.20.0.0/24 service name=ssh accept'; sudo firewall-cmd --permanent --add-service={http,https}; sudo firewall-cmd --reload; sudo firewall-cmd --list-all | egrep 'services|rule'

Output:

  services: cockpit dhcpv6-client http https
	rule family="ipv4" source address="10.20.0.0/24" service name="ssh" accept

याचा अर्थ: खऱ्या आयुष्यात ssh काढण्याआधी rich rule जोडा म्हणजे स्वतःला lock out करणार नाही.

3. SELinux confirm करा आणि denials शोधा.

getenforce; sudo ausearch -m AVC -ts today 2>&1 | tail -1; sudo dnf -y remove cockpit-ws >/dev/null; sudo firewall-cmd --permanent --remove-service=cockpit; sudo firewall-cmd --reload

Output:

Enforcing
<no matches>
success
success

याचा अर्थ: Denials नाहीत, आणि attack surface कमी करायला न वापरलेली cockpit service काढली.

6. Secure: updates, fail2ban, auditing आणि TLS

हे का लागतं?

बहुतेक खरे breaches माहीत असलेले, आधीच patch झालेले bugs वापरतात, आणि audit trail शिवाय काय झालं ते सांगताही येत नाही.

हे काय आहे?

dnf-automatic ने automatic security updates चालू करा, SSH साठी fail2ban जोडा, sudoers आणि SSH config बदलांसाठी auditd rules जोडा, आणि HTTPS enable करा. Internal name साठी company CA किंवा lab साठी self-signed certificate वापरा; public name साठी certbot सह Let's Encrypt वापरा.

कसं करायचं (step by step)

1. Automatic security updates.

sudo dnf -y install dnf-automatic >/dev/null; sudo sed -i 's/^upgrade_type.*/upgrade_type = security/; s/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf; sudo systemctl enable --now dnf-automatic.timer; systemctl list-timers dnf-automatic.timer --no-pager | sed -n 2p

Output:

Tue 2026-10-27 06:12:41 IST 18h left - - dnf-automatic.timer dnf-automatic.service

याचा अर्थ: Security patches रोज लागतात; kernels ला अजूनही planned reboot लागतो.

2. fail2ban आणि audit rules.

sudo dnf -y install epel-release >/dev/null && sudo dnf -y install fail2ban >/dev/null; printf '[sshd]\nenabled = true\nmaxretry = 4\nbantime = 1h\n' | sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null; sudo systemctl enable --now fail2ban; printf -- '-w /etc/sudoers -p wa -k priv\n-w /etc/sudoers.d/ -p wa -k priv\n-w /etc/ssh/sshd_config.d/ -p wa -k sshcfg\n' | sudo tee /etc/audit/rules.d/50-admin.rules >/dev/null; sudo augenrules --load >/dev/null; sudo auditctl -l | wc -l

Output:

3

याचा अर्थ: तीन watches loaded; sudo किंवा SSH config मधला प्रत्येक बदल आता user च्या login id सह record होतो.

3. Lab certificate सह HTTPS enable करा.

sudo openssl req -x509 -newkey rsa:2048 -nodes -days 365 -subj '/CN=orders01.shree.local' -keyout /etc/pki/tls/private/orders.key -out /etc/pki/tls/certs/orders.crt 2>/dev/null; sudo tee -a /etc/nginx/conf.d/orders.conf >/dev/null <<'N'
server { listen 443 ssl; server_name orders01.shree.local;
  ssl_certificate /etc/pki/tls/certs/orders.crt; ssl_certificate_key /etc/pki/tls/private/orders.key;
  location / { proxy_pass http://127.0.0.1:8000; } }
N
sudo nginx -t 2>&1 | tail -1; sudo systemctl reload nginx; curl -sk https://localhost/health

Output:

nginx: configuration file /etc/nginx/nginx.conf test is successful
ok

याचा अर्थ: Production साठी खरा CA वापरा; nginx मधल्या steps त्याच राहतात.

7. Monitor: metrics, logs, health checks आणि alerts

हे का लागतं?

Site down आहे किंवा disk full आहे हे तुम्हाला सांगणारे users पहिले कधीच नसावेत.

हे काय आहे?

Prometheus साठी node_exporter ने metrics expose करा, journal persistent आणि size-limited ठेवा, app logs rotate करा, आणि दर minute ला health URL आणि disk usage तपासणारा आणि threshold पार झाला की alert (इथे webhook ला) पाठवणारा छोटा systemd timer जोडा. खरंच काहीतरी बिघडवून alert test करा.

कसं करायचं (step by step)

1. Persistent, size-limited journal.

sudo mkdir -p /etc/systemd/journald.conf.d; printf '[Journal]\nStorage=persistent\nSystemMaxUse=500M\n' | sudo tee /etc/systemd/journald.conf.d/size.conf >/dev/null; sudo systemctl restart systemd-journald; journalctl --disk-usage

Output:

Archived and active journals take up 24.0M in the file system.

याचा अर्थ: Logs reboot नंतर टिकतात आणि disk भरू शकत नाहीत.

2. Health check script आणि timer.

sudo tee /usr/local/bin/healthcheck >/dev/null <<'H'
#!/usr/bin/env bash
set -uo pipefail
msg=''
curl -fsS -m 5 http://127.0.0.1/health >/dev/null || msg+='app health failed; '
use=$(df --output=pcent /srv/app | tail -1 | tr -dc 0-9)
(( use >= 80 )) && msg+="disk /srv/app ${use}%; "
if [[ -n $msg ]]; then logger -t healthcheck "ALERT $msg"; curl -fsS -m 5 -d "text=orders01: $msg" "${ALERT_URL:-http://10.20.0.5/hook}" >/dev/null || true; fi
H
sudo chmod 755 /usr/local/bin/healthcheck
printf '[Unit]\nDescription=health\n[Service]\nType=oneshot\nExecStart=/usr/local/bin/healthcheck\n' | sudo tee /etc/systemd/system/healthcheck.service >/dev/null
printf '[Unit]\nDescription=health every minute\n[Timer]\nOnCalendar=minutely\n[Install]\nWantedBy=timers.target\n' | sudo tee /etc/systemd/system/healthcheck.timer >/dev/null
sudo systemctl daemon-reload; sudo systemctl enable --now healthcheck.timer; systemctl is-active healthcheck.timer

Output:

active

याचा अर्थ: दर minute ला app आणि disk तपासतो आणि फक्त problems वर alert करतो.

3. App बंद करून alert test करा.

sudo systemctl stop orders; sleep 65; journalctl -t healthcheck -n 1 --no-pager -o cat; sudo systemctl start orders

Output:

ALERT app health failed;

याचा अर्थ: Alert fire झाला. कधीच fire होताना न पाहिलेल्या alert वर विश्वास ठेवता येत नाही.

8. Backup आणि restore

हे का लागतं?

कधीच restore न केलेला backup ही फक्त आशा. Disks fail होतात, लोक गोष्टी delete करतात, आणि ransomware data encrypt करतो.

हे काय आहे?

/srv/app, /etc आणि installed packages ची list restic ने वेगळ्या backup host वर SFTP ने, encrypted, backup करा. Systemd timer ने रोज रात्री चालवा, 14 daily आणि 4 weekly snapshots ठेवा, आणि ते चालतं हे सिद्ध करायला दर महिन्याला temporary folder मधे restore करा. 3-2-1 follow करा: तीन copies, दोन प्रकारचे media, एक off site.

कसं करायचं (step by step)

1. Repository initialise करा.

sudo dnf -y install restic >/dev/null; export RESTIC_REPOSITORY=sftp:backup@10.20.0.9:/backups/orders01 RESTIC_PASSWORD_FILE=/root/.restic-pass; sudo -E restic init | tail -1

Output:

created restic repository 3f9a1c22be at sftp:backup@10.20.0.9:/backups/orders01

याचा अर्थ: Password file सुरक्षित ठेवा आणि एक copy offline; त्याशिवाय backup निरुपयोगी.

2. Backup चालवा आणि retention लावा.

rpm -qa | sort | sudo tee /root/pkglist.txt >/dev/null; sudo -E restic backup /srv/app /etc /root/pkglist.txt --tag nightly -q; sudo -E restic forget --keep-daily 14 --keep-weekly 4 --prune -q; sudo -E restic snapshots --compact | tail -2

Output:

3c1d7e2a  2026-10-26 11:48:03  orders01  nightly  /etc, /root/pkglist.txt, /srv/app
1 snapshots

याचा अर्थ: मग या lines nightly systemd timer सह script मधे गुंडाळा.

3. Restore सिद्ध करा.

sudo -E restic restore latest --target /tmp/restore --include /srv/app/app.py -q; diff /srv/app/app.py /tmp/restore/srv/app/app.py && echo restore-ok

Output:

restore-ok

याचा अर्थ: सारखीच file restore झाली. प्रत्येक test ची तारीख runbook मधे लिहा.

9. Fix: सहा production break-and-fix scenarios

हे का लागतं?

Interviewers आणि on-call shifts दोन्ही तुम्ही cause लवकर आणि safely शोधू शकता का ते तपासतात, प्रत्येक flag आठवतो का ते नाही.

हे काय आहे?

तुम्ही दुसरीकडे बघत असताना partner ला खालच्या commands ने तुमचा server बिघडवायला सांगा, मग method वापरून fix करा: symptom, scope, recent changes, logs, resources, fix, verify, लिहून ठेवा. प्रत्येक scenario break, clue आणि fix दाखवतो.

कसं करायचं (step by step)

1. Scenario 1 आणि 2: 502 Bad Gateway.

curl -sI localhost | head -1; systemctl is-active orders; getsebool httpd_can_network_connect; sudo tail -1 /var/log/nginx/error.log

Output:

HTTP/1.1 502 Bad Gateway
active
httpd_can_network_connect --> off
... connect() to 127.0.0.1:8000 failed (13: Permission denied) while connecting to upstream

याचा अर्थ: App चालू आहे, पण permission denied आणि boolean off SELinux कडे बोट दाखवतात. Fix: setsebool -P httpd_can_network_connect on. App inactive असतं तर journalctl -u orders तपासा आणि start करा.

2. Scenario 3: disk full.

df -h /srv/app | tail -1; sudo du -xah /srv/app | sort -h | tail -2; sudo lsof +L1 | tail -1

Output:

/dev/mapper/vg_data-lv_app  6.0G  6.0G   20K 100% /srv/app
5.7G	/srv/app/debug.log
6.0G	/srv/app

याचा अर्थ: Process धरून असेल तर delete करण्याऐवजी truncate करा: sudo truncate -s 0 /srv/app/debug.log. मग logrotate जोडा, किंवा वाढवा: lvextend -r -L +2G /dev/vg_data/lv_app.

3. Scenarios 4, 5 आणि 6: SSH, emergency mode आणि high load.

sudo firewall-cmd --list-rich-rules | wc -l; findmnt --verify 2>&1 | tail -1; ps -eo pid,user,%cpu,cmd --sort=-%cpu | head -2

Output:

0
   1 parse errors, 0 errors, 0 warnings
    PID USER  %CPU CMD
   4121 app   99.3 python3 -c while True: pass

याचा अर्थ: Rich rule नाही: console मधून परत जोडा. fstab parse error: mount -o remount,rw / नंतर emergency shell मधून line fix करा. Runaway process: owner शी confirm करा, मग kill 4121 आणि तो का सुरू झाला ते शोधा.

10. Runbook, handover आणि final checklist

हे का लागतं?

फक्त एकाच माणसाला समजणारा server हा risk आहे. Runbook मुळे team मधला कोणीही रात्री 2 वाजता तो handle करू शकतो.

हे काय आहे?

/root/RUNBOOK.md लिहा: server काय करतो, तिथे कसं पोहोचायचं, services आणि ports, data आणि logs कुठे आहेत, deploy कसं करायचं, restore कसं करायचं, सहा scenarios आणि त्यांचे fixes, आणि कोणाला call करायचं. मग plan मधली प्रत्येक requirement तपासणारी आणि PASS किंवा FAIL print करणारी final checklist script चालवा.

कसं करायचं (step by step)

1. Final checklist script.

cat > check.sh <<'C'
#!/usr/bin/env bash
ok(){ printf '%-28s %s\n' "$1" "$( eval "$2" >/dev/null 2>&1 && echo PASS || echo FAIL)"; }
ok 'SELinux enforcing' '[[ $(getenforce) == Enforcing ]]'
ok 'root ssh disabled' 'sshd -T | grep -q "permitrootlogin no"'
ok 'password ssh disabled' 'sshd -T | grep -q "passwordauthentication no"'
ok 'app healthy' 'curl -fs localhost/health'
ok 'https healthy' 'curl -fsk https://localhost/health'
ok 'data mounted' 'findmnt /srv/app'
ok 'backup timer' 'systemctl is-active restic-backup.timer'
ok 'health timer' 'systemctl is-active healthcheck.timer'
ok 'auto updates' 'systemctl is-active dnf-automatic.timer'
ok 'no failed units' '[[ -z $(systemctl --failed --no-legend) ]]'
C
sudo bash check.sh

Output:

SELinux enforcing            PASS
root ssh disabled            PASS
password ssh disabled        PASS
app healthy                  PASS
https healthy                PASS
data mounted                 PASS
backup timer                 PASS
health timer                 PASS
auto updates                 PASS
no failed units              PASS

याचा अर्थ: प्रत्येक line PLAN.md मधल्या requirement शी जुळते.

2. Reboot करा आणि परत चालवा.

sudo systemctl reboot
# after login
sudo bash check.sh | grep -c PASS

Output:

10

याचा अर्थ: खरा पुरावा: reboot नंतर सगळं आपोआप परत येतं.

3. Handover note लिहा.

cat /root/HANDOVER.txt

Output:

orders01.shree.local (10.20.0.21), Rocky 9.4. nginx :80/:443 -> orders.service :8000 (user app). Data /srv/app on vg_data/lv_app (6G, 4G free). SSH keys only, admins group, office subnet. Backups restic nightly 01:30 to 10.20.0.9, last restore test 2026-10-26 OK. Alerts via healthcheck.timer. Runbook /root/RUNBOOK.md.

याचा अर्थ: नव्या teammate ला लगेच वापरता येतील अशा पाच lines.

11. अनेक industries मधली खरी उदाहरणं

हे का लागतं?

तेच Linux skill प्रत्येक प्रकारच्या company मध्ये लागतं. वेगवेगळ्या ठिकाणी पाहिलं की लक्षात राहतं.

हे काय आहे?

प्रत्येक row म्हणजे एक काल्पनिक team. कोण हे वापरतं आणि कसं ते दाखवते.

कसं करायचं (step by step)

12. नेहमीच्या errors आणि त्यांचे fixes

हे का लागतं?

हे errors सगळ्यांना येतात. कारण माहीत असलं की तास वाचतात.

हे काय आहे?

आधी नेमका message वाचा. मग खालच्या row शी जुळवा.

कसं करायचं (step by step)

13. Troubleshooting step by step

हे का लागतं?

Production server बिघडला की प्रत्येक वेळी तोच क्रम follow करा आणि जे सापडेल ते लिहून ठेवा.

हे काय आहे?

वरून खाली जा. ज्या step ला problem दिसतो तिथे थांबा.

कसं करायचं (step by step)

1. Up आणि reachable आहे का?

curl -sI https://orders01.shree.local -k | head -1

2. कोणती service नाराज आहे?

systemctl --failed; systemctl status orders nginx --no-pager | grep Active

3. Logs काय म्हणतात?

journalctl -p err -b --no-pager | tail -20

4. Resources: CPU, memory, disk.

uptime; free -h; df -h

5. Security layers: SELinux आणि firewall.

ausearch -m AVC -ts recent; firewall-cmd --list-all

6. अलीकडे काय बदललं?

dnf history | head -5; ausearch -k priv -ts today | tail -3

14. Lab 1: orders01 end to end build आणि secure करा

हे का लागतं?

Fresh Rocky 9 VM वर sections 1 ते 5 follow करा आणि सगळे security checks pass होऊन संपवा.

हे काय आहे?

पूर्ण hands-on lab. प्रत्येक step test Linux machine वर करा (EC2 instance, VM किंवा WSL).

कसं करायचं (step by step)

1. PLAN.md लिहा आणि facts नोंदवा.

wc -l /root/PLAN.md; hostname

Output:

24 /root/PLAN.md
orders01.shree.local

2. Users, sudo आणि LVM.

getent group admins; findmnt -no SOURCE /srv/app

Output:

admins:x:1001:ravi,asha
/dev/mapper/vg_data-lv_app

3. App आणि nginx.

curl -s localhost/; systemctl is-enabled orders nginx

Output:

Shree Traders orders
enabled
enabled

4. SSH आणि firewall hardening.

sshd -T | grep -c -E 'permitrootlogin no|passwordauthentication no'; firewall-cmd --list-services

Output:

2
dhcpv6-client http https

5. Updates, fail2ban, audit, TLS.

systemctl is-active dnf-automatic.timer fail2ban auditd; curl -sk https://localhost/health

Output:

active
active
active
ok

15. Lab 2: Monitor, backup, break आणि fix

हे का लागतं?

Monitoring आणि backups जोडा, मग partner ला सगळे सहा break scenarios चालवायला सांगा; प्रत्येक 10 minutes मधे fix करा आणि log करा.

हे काय आहे?

पूर्ण hands-on lab. प्रत्येक step test Linux machine वर करा (EC2 instance, VM किंवा WSL).

कसं करायचं (step by step)

1. Health timer आणि alert test.

systemctl stop orders; sleep 65; journalctl -t healthcheck -n1 -o cat; systemctl start orders

Output:

ALERT app health failed;

2. Backup आणि restore test.

restic snapshots --compact | tail -1; restic restore latest --target /tmp/r -q && ls /tmp/r/srv/app

Output:

1 snapshots
app.py

3. Partner बिघडवतो: SELinux boolean off.

curl -sI localhost | head -1; getsebool httpd_can_network_connect

Output:

HTTP/1.1 502 Bad Gateway
httpd_can_network_connect --> off

4. Fix करा आणि verify करा.

setsebool -P httpd_can_network_connect on; curl -sI localhost | head -1

Output:

HTTP/1.1 200 OK

5. Partner बिघडवतो: disk भरतो. Fix करा आणि log करा.

truncate -s 0 /srv/app/debug.log; df --output=pcent /srv/app | tail -1; echo '2026-10-26 12:30 disk full, truncated debug.log, added logrotate' >> /root/INCIDENTS.log

Output:

  2%

6. Reboot नंतर final checklist.

bash check.sh | grep -c PASS

Output:

10

16. नेहमी विचारले जाणारे प्रश्न

17. मुलाखत प्रश्न आणि उत्तरं

Beginner level

Mid level level

Senior level

18. संबंधित chapters

• DevOps साठी Linux Ops Refresh
• Automation साठी Bash Scripting
• Linux grep आणि find Commands Examples सह
• Linux Servers मध्ये Passwordless SSH

उजळणी, तुलना आणि मुलाखत cards

हा lesson काही मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR हा lesson उघडतो.

अजून cards: Ravi Sir's Cards.