DevOps बूटकैंप · पाठ

न्यूनतम-अधिकार निष्पादन और sudo अनुशासन

अधिकार घटाएँ, sudo नियमों का दायरा कड़ा रखें और जोखिमपूर्ण ऑपरेशन से पहले प्रभावी UID की जाँच करें।

पाठ 3, कुल 4 में से13 चरण

न्यूनतम-अधिकार निष्पादन और sudo अनुशासन, CoddyKit पर DevOps बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह DevOps बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

शेल स्क्रिप्ट में न्यूनतम-अधिकार क्यों महत्वपूर्ण हैं

स्वचालन में अधिकांश सुरक्षा उल्लंघन किसी असाधारण शोषण के कारण नहीं, बल्कि इसलिए होते हैं कि स्क्रिप्ट आवश्यकता से अधिक अधिकारों के साथ चलती हैं। किसी लॉग फ़ाइल को केवल घुमाने वाली root के रूप में चल रही cron नौकरी किसी दुर्घटना को आमंत्रण देने जैसी है।

न्यूनतम अधिकार का सिद्धांत कहता है: प्रत्येक प्रक्रिया को अपना काम करने के लिए आवश्यक अनुमतियों का ही उपयोग करना चाहिए — उससे अधिक का नहीं। Bash स्क्रिप्टिंग में इसका अर्थ है:

जहाँ संभव हो, बिना विशेष अधिकार वाले उपयोगकर्ता के रूप में चलना
केवल उन विशिष्ट आदेशों के लिए root अधिकार लेना जिन्हें इसकी आवश्यकता हो
अधिकारयुक्त कार्य पूरा होते ही अधिकार छोड़ देना
अपने दायरे से बाहर प्रमाण-पत्रों को कभी संग्रहीत या विरासत में न लेना

इस पाठ में ठोस तकनीकों को समझाया गया है: sudo का दायरा सीमित करना, su से अधिकार छोड़ना, UID सत्यापन सुरक्षा-जाँच और sudoers को सुदृढ़ करना — ताकि उत्पादन स्क्रिप्ट के लिए अनुशासित अधिकार मॉडल बनाया जा सके।

जोखिमपूर्ण कार्यों से पहले प्रभावी UID जाँचना

रूट की वास्तविक आवश्यकता वाले किसी भी कोड-खंड से पहले आपकी स्क्रिप्ट को यह सत्यापित करना चाहिए कि वह अपेक्षित प्रभावी UID के साथ चल रही है। कभी अनुमान न लगाएँ; हमेशा पुष्टि करें।

$EUID एक Bash विशेष चर है, जिसमें वर्तमान प्रक्रिया की प्रभावी उपयोगकर्ता ID होती है। root का EUID हमेशा 0 होता है। स्क्रिप्ट की शुरुआत में — या किसी अधिकारयुक्त कोड-खंड के आसपास — इसकी जाँच करने से गलत पहचान के अंतर्गत आकस्मिक निष्पादन रुकता है।

यह सुरक्षा-जाँच प्रारूप अपनाएँ:

#!/usr/bin/env bash
set -euo pipefail

# Guard: this script must NOT run as root.
if [[ "$EUID" -eq 0 ]]; then
  echo "ERROR: Do not run this script as root. Use a normal user account." >&2
  exit 1
fi

echo "Running as UID $EUID — proceeding safely."

आवश्यकता होने पर ही root की पुष्टि करना

कुछ स्क्रिप्टों को वास्तव में root की आवश्यकता होती है। ऐसी स्थिति में सुरक्षा-जाँच उलट जाती है: root न होने पर तुरंत विफल हों, बजाय इसके कि स्क्रिप्ट किसी अधिकारयुक्त सिस्टम कॉल तक पहुँचे और बीच में अस्पष्ट अनुमति त्रुटि उत्पन्न करे।

तुरंत बाहर निकलने को उपयोग संबंधी सहायक संदेश के साथ मिलाने से स्क्रिप्ट अपने उपयोग का तरीका स्वयं स्पष्ट करती हैं:

#!/usr/bin/env bash
set -euo pipefail

require_root() {
  if [[ "$EUID" -ne 0 ]]; then
    echo "ERROR: $(basename "$0") must be run as root." >&2
    echo "  Try: sudo $(basename "$0") $*" >&2
    exit 1
  fi
}

require_root "$@"

echo "Root confirmed (EUID=0). Starting privileged work..."

sudo का दायरा एकल आदेशों तक सीमित करना

सबसे आम गलती स्क्रिप्ट की शुरुआत में sudo लगाकर सब कुछ root के रूप में चलाना है। इसके बजाय sudo केवल उस सटीक आदेश पर लगाएँ जिसे इसकी आवश्यकता है — बाकी सब आपके सामान्य उपयोगकर्ता के रूप में चलता है।

इससे नुकसान का दायरा सीमित रहता है: यदि कोई हमलावर आपकी स्क्रिप्ट में कोड डाल देता है, तो वह केवल उन्हीं हिस्सों को root अधिकारों के साथ चला सकता है जिनके आगे sudo नहीं लगा है।

नीचे दिए गए दोनों प्रारूपों की तुलना करें। दूसरा काफ़ी अधिक सुरक्षित है:

#!/usr/bin/env bash
set -euo pipefail

# BAD: escalate early, do everything as root (avoid this)
# sudo bash -c '
#   cp config.conf /etc/app/config.conf
#   chown app:app /etc/app/config.conf
#   systemctl restart app
# '

# GOOD: escalate only for the commands that require it
LOCAL_CONF="./config.conf"
DEST="/etc/app/config.conf"

# Unprivileged: validate the config before touching anything as root
if ! grep -q '^[[:space:]]*\[main\]' "$LOCAL_CONF"; then
  echo "ERROR: config.conf is missing [main] section" >&2
  exit 1
fi

# Privileged: only these three commands run under sudo
sudo cp "$LOCAL_CONF" "$DEST"
sudo chown app:app "$DEST"
sudo systemctl restart app

echo "Config deployed and service restarted."

कड़े sudoers नियम लिखना

किसी स्क्रिप्ट में sudo somecommand का उपयोग तभी सुरक्षित रूप से काम करता है जब sudoers फ़ाइल केवल उसी आदेश — और किसी अन्य को नहीं — चलाने की अनुमति देने के लिए कॉन्फ़िगर की गई हो। सेवा खातों के लिए ALL=(ALL) NOPASSWD: ALL जैसे नियमों से बचें।

इसके बजाय visudo-सुरक्षित सिंटैक्स का उपयोग करके नियमों को विशिष्ट तर्कों वाले विशिष्ट आदेशों तक सीमित करें। sudoers नियम के प्रमुख फ़ील्ड:

उपयोगकर्ता — कौन sudo चला सकता है
होस्ट — किस मशीन पर (पोर्टेबिलिटी के लिए ALL का उपयोग करें)
RunAs — किस पहचान को अपनाना है (लगभग हमेशा root)
आदेश — पूरा निरपेक्ष पथ, और आवश्यकता होने पर शाब्दिक तर्क

परिनियोजन सेवा खाते (deployer) के लिए कड़े नियमों का उदाहरण:

# /etc/sudoers.d/deployer  (edit with: sudo visudo -f /etc/sudoers.d/deployer)
#
# Allow 'deployer' to restart exactly one service — nothing else
deployer ALL=(root) NOPASSWD: /usr/bin/systemctl restart app

# Allow copying a config file to a fixed destination only
deployer ALL=(root) NOPASSWD: /usr/bin/cp /home/deployer/staging/config.conf /etc/app/config.conf

# Allow chown of that specific file only
deployer ALL=(root) NOPASSWD: /usr/bin/chown app\:app /etc/app/config.conf

# NEVER do this — gives full root shell:
# deployer ALL=(ALL) NOPASSWD: ALL

su और runuser से अधिकार छोड़ना

जब कोई स्क्रिप्ट root के रूप में शुरू होती है (जैसे root के रूप में चल रहे सिस्टम इनिट या cron द्वारा शुरू की गई हो), लेकिन अधिकांश काम बिना विशेष अधिकार वाले उपयोगकर्ता के रूप में होना चाहिए, तो पूरी स्क्रिप्ट को root के रूप में चलाने के बजाय अधिकार स्पष्ट रूप से छोड़ दें।

इसके लिए दो उपकरण हैं:

su -s /bin/bash -c 'command' username — username के रूप में शेल शुरू करता है और आदेश चलाता है
runuser -u username -- command args — root-स्वामित्व वाली स्क्रिप्ट के भीतर उपयोगकर्ता बदलने के लिए Linux पर पसंदीदा है; su से अधिक साफ़ तरीका

नीचे का प्रारूप root-स्वामित्व वाले परिनियोजन आवरण को वास्तविक अनुप्रयोग तर्क के लिए app उपयोगकर्ता के अधिकार में जाने का तरीका दिखाता है:

#!/usr/bin/env bash
# This script is called by systemd as root during pre-deployment
set -euo pipefail

APP_USER="app"
DEPLOY_DIR="/opt/myapp"

# Step 1: privileged — fix ownership of deploy directory
chown -R "${APP_USER}:${APP_USER}" "$DEPLOY_DIR"

# Step 2: drop to app user for the actual migration/startup logic
# runuser is available on most modern Linux systems
runuser -u "$APP_USER" -- bash -c "
  cd $DEPLOY_DIR
  ./bin/migrate.sh
  ./bin/start.sh
"

echo "Deploy complete. Privileged wrapper exiting."

किसी अन्य उपयोगकर्ता के रूप में एकल आदेश चलाने के लिए sudo -u का उपयोग करना

आपको हमेशा पूर्ण शेल सत्र में जाने की आवश्यकता नहीं होती। sudo -u username command निर्दिष्ट उपयोगकर्ता के रूप में एकल आदेश चलाता है और फिर बुलाने वाली पहचान पर लौट आता है। यह किसी सेवा खाते के स्वामित्व वाली फ़ाइलों पर काम करने के लिए उपयोगी है, बिना उस खाते को इंटरैक्टिव पहुँच दिए।

इसे ऐसे sudoers नियम के साथ जोड़ें जो ठीक उसी उपयोगकर्ता/आदेश संयोजन की अनुमति देता हो:

#!/usr/bin/env bash
set -euo pipefail

# Scenario: deploy script runs as 'deployer'; DB migrations must run as 'postgres'
# sudoers entry needed:
#   deployer ALL=(postgres) NOPASSWD: /opt/app/bin/run_migrations.sh

DB_MIGRATION_SCRIPT="/opt/app/bin/run_migrations.sh"

if [[ ! -x "$DB_MIGRATION_SCRIPT" ]]; then
  echo "ERROR: migration script not found or not executable: $DB_MIGRATION_SCRIPT" >&2
  exit 1
fi

echo "Running DB migrations as postgres user..."
sudo -u postgres "$DB_MIGRATION_SCRIPT"

echo "Migrations done. Returning to deployer context (EUID=$EUID)."

पर्यावरण चरों के माध्यम से अधिकार बढ़ने से रोकना

हमले का एक सूक्ष्म क्षेत्र है: sudo सत्र द्वारा विरासत में मिले पर्यावरण चर। डिफ़ॉल्ट रूप से sudo पर्यावरण को रीसेट करता है, लेकिन गलत तरीके से कॉन्फ़िगर किए गए env_keep या env_reset ओवरराइड हमलावर-नियंत्रित चरों, जैसे LD_PRELOAD, PATH या PYTHONPATH, को अधिकारयुक्त आदेशों तक पहुँचा सकते हैं।

सर्वोत्तम अभ्यास:

sudo के अंतर्गत चलने वाली स्क्रिप्ट में हमेशा निरपेक्ष पथ इस्तेमाल करें — $PATH पर कभी निर्भर न रहें
केवल आवश्यक चर दें: sudo env VAR=value /path/to/cmd
sudoers में env_keep += PATH या env_keep += LD_* से बचें
sudo -E का उपयोग तभी करें जब बुलाने वाले पर्यावरण पर आपका पूरा नियंत्रण और विश्वास हो

#!/usr/bin/env bash
set -euo pipefail

# BAD: relies on $PATH — attacker who controls PATH can hijack 'cp'
# sudo cp config.conf /etc/app/

# GOOD: absolute paths for every command called under elevated context
SUDO_BIN="/usr/bin/sudo"
CP_BIN="/usr/bin/cp"
CHOWN_BIN="/usr/bin/chown"
SYSTEMCTL_BIN="/usr/bin/systemctl"

"$SUDO_BIN" "$CP_BIN" ./config.conf /etc/app/config.conf
"$SUDO_BIN" "$CHOWN_BIN" app:app /etc/app/config.conf
"$SUDO_BIN" "$SYSTEMCTL_BIN" restart app

echo "Deployed with hardened absolute-path invocations."

आदेश तर्क सत्यापन से sudo को सुरक्षित करना

जब sudoers नियम किसी विशिष्ट स्क्रिप्ट को चलाने की अनुमति देता है, तब भी उस स्क्रिप्ट को मनमाने तर्क दिए जा सकते हैं, जब तक नियम उन तर्कों को भी सीमित न करे। एक आम गलती:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

इससे sudo /opt/scripts/manage.sh restart की अनुमति मिलती है — लेकिन sudo /opt/scripts/manage.sh --arbitrary-flag की भी। यदि manage.sh तर्कों को बिना जाँच के अधिकारयुक्त उप-आदेशों को भेजती है, तो यह समस्या है।

गहराई में सुरक्षा अपनाएँ: sudoers के साथ-साथ अधिकारयुक्त स्क्रिप्ट के भीतर तर्कों की जाँच करें:

#!/usr/bin/env bash
# /opt/scripts/manage.sh — called via sudo; must validate its own args
set -euo pipefail

# Allowlist of valid actions
declare -A ALLOWED_ACTIONS=(
  [restart]=1
  [status]=1
  [reload]=1
)

ACTION="${1:-}"

if [[ -z "$ACTION" ]]; then
  echo "Usage: $(basename "$0") <restart|status|reload>" >&2
  exit 1
fi

if [[ -z "${ALLOWED_ACTIONS[$ACTION]:-}" ]]; then
  echo "ERROR: Unknown action '${ACTION}'. Allowed: ${!ALLOWED_ACTIONS[*]}" >&2
  exit 2
fi

/usr/bin/systemctl "$ACTION" app
echo "Action '$ACTION' executed successfully."

ट्रैप से अस्थायी विशेषाधिकार बढ़ाना और सफ़ाई करना

जब किसी स्क्रिप्ट को थोड़े समय के लिए विशेषाधिकार वाली फ़ाइल, क्रेडेंशियल या संसाधन अपने पास रखना हो, तो Bash के trap का उपयोग करें, ताकि त्रुटि या सिग्नल आने पर भी सफ़ाई सुनिश्चित हो सके। इससे विशेषाधिकार लीक होने से बचते हैं — उदाहरण के लिए, यदि स्क्रिप्ट क्रैश हो जाए तो कोई अस्थायी setuid बाइनरी या रूट-स्वामित्व वाला सॉकेट पीछे छूटने से रोका जा सकता है।

नीचे दिया गया पैटर्न रूट के रूप में एक अस्थायी फ़ाइल बनाता है, उसका उपयोग करता है और फिर उसे हटा देता है — इसकी गारंटी EXIT पर लगाए गए ट्रैप से मिलती है:

#!/usr/bin/env bash
set -euo pipefail

# Must run as root for this demo
if [[ "$EUID" -ne 0 ]]; then
  echo "Run as root" >&2; exit 1
fi

TMP_SECRET=""

cleanup() {
  local exit_code=$?
  if [[ -n "$TMP_SECRET" && -f "$TMP_SECRET" ]]; then
    # Overwrite before deletion to reduce forensic recovery risk
    shred -u "$TMP_SECRET" 2>/dev/null || rm -f "$TMP_SECRET"
    echo "[cleanup] Removed privileged temp file." >&2
  fi
  exit "$exit_code"
}

trap cleanup EXIT INT TERM

# Create a root-owned temp file for a short-lived secret
TMP_SECRET="$(mktemp /tmp/deploy_secret.XXXXXXXX)"
chmod 600 "$TMP_SECRET"

# Simulate fetching a secret into the temp file
echo "super-secret-token" > "$TMP_SECRET"

# Use the secret (e.g., pass to a sub-command via file descriptor)
/usr/bin/some-privileged-tool --key-file "$TMP_SECRET"

echo "Privileged operation complete."

विशेषाधिकार वाली कार्रवाइयों का ऑडिट और अभिलेखन

न्यूनतम विशेषाधिकार लागू करना तब आसान होता है, जब हर विशेषाधिकार-वृद्धि घटना को संदर्भ सहित दर्ज किया जाए: किसने क्या चलाया, कब चलाया और क्यों चलाया। इसके लिए दो स्तरों को मिलाएँ:

sudo स्वयं — /var/log/auth.log (Debian/Ubuntu) या /var/log/secure (RHEL) हर sudo आह्वान को अपने-आप दर्ज करता है
स्क्रिप्ट-स्तरीय ऑडिट लॉग — हर विशेषाधिकार वाले फ़ंक्शन की शुरुआत में एक संरचित प्रविष्टि लिखें, ताकि उद्देश्य सिस्टम लॉग के साथ दर्ज हो

एक सरल संरचित लॉग फ़ंक्शन का उपयोग करने से ऑडिट रिकॉर्ड एकसमान और grep के अनुकूल रहते हैं:

#!/usr/bin/env bash
set -euo pipefail

AUDIT_LOG="/var/log/app_deploy_audit.log"

log_privileged_action() {
  local action="$1"
  local reason="${2:-unspecified}"
  local ts
  ts="$(date -u '+%Y-%m-%dT%H:%M:%SZ')"
  printf '{"ts":"%s","user":"%s","euid":%d,"action":"%s","reason":"%s"}\n' \
    "$ts" "${SUDO_USER:-$USER}" "$EUID" "$action" "$reason" \
    | sudo tee -a "$AUDIT_LOG" > /dev/null
}

# Each privileged step is logged before execution
log_privileged_action "cp_config" "deploy release v2.4.1"
sudo /usr/bin/cp ./config.conf /etc/app/config.conf

log_privileged_action "chown_config" "ensure app user owns config"
sudo /usr/bin/chown app:app /etc/app/config.conf

log_privileged_action "restart_service" "activate new config"
sudo /usr/bin/systemctl restart app

echo "Deployment complete. Audit entries written to $AUDIT_LOG"

ज्ञान जाँच: sudo का दायरा

Bash स्क्रिप्ट में न्यूनतम-विशेषाधिकार वाले निष्पादन की अपनी समझ का परीक्षण करें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: न्यूनतम-विशेषाधिकार वाला निष्पादन और sudo अनुशासन

इस पाठ में आपने हर चरण पर आवश्यक न्यूनतम विशेषाधिकार के साथ Bash स्क्रिप्ट चलाने की तकनीकें सीखीं। मुख्य सिद्धांतों का संक्षिप्त सारांश यहाँ दिया गया है:

$EUID से सुरक्षा-जाँच करें — यदि स्क्रिप्ट गलत पहचान के रूप में चल रही हो, तो तुरंत विफल हो जाएँ; चाहे आपको रूट को अस्वीकार करना हो या रूट की आवश्यकता हो
sudo का दायरा अलग-अलग कमांड तक रखें — पूरी स्क्रिप्ट के विशेषाधिकार कभी न बढ़ाएँ; sudo केवल उन्हीं पंक्तियों पर लगाएँ जिन्हें वास्तव में इसकी आवश्यकता है
कड़े sudoers नियम लिखें — पूर्ण निरपेक्ष पथ और शाब्दिक तर्क निर्दिष्ट करें; वाइल्डकार्ड और ALL से बचें
runuser या sudo -u से विशेषाधिकार घटाएँ — जब रूट के रूप में शुरू हुई स्क्रिप्ट को किसी अप्रivileged उपयोगकर्ता को काम सौंपना हो, तो सब कुछ रूट के रूप में चलाने के बजाय सही उपकरण का उपयोग करें
निरपेक्ष पथों का उपयोग करें — विशेषाधिकार वाले कोड में $PATH पर कभी निर्भर न रहें; नियंत्रण हथियाने से बचने के लिए बाइनरी पथ स्पष्ट रूप से लिखें
विशेषाधिकार वाली स्क्रिप्ट के भीतर तर्कों की जाँच करें — sudoers नियम सुरक्षा की पहली पंक्ति हैं, एकमात्र पंक्ति नहीं; अनुमत-सूचियों का उपयोग करें
ट्रैप लगाकर सफ़ाई करें — त्रुटि होने पर भी अस्थायी विशेषाधिकार वाले संसाधनों को नष्ट करने की गारंटी के लिए trap cleanup EXIT का उपयोग करें
हर विशेषाधिकार-वृद्धि को दर्ज करें — संरचित ऑडिट प्रविष्टियाँ और अंतर्निहित sudo syslog मिलकर हर विशेषाधिकार वाली कार्रवाई का पता लगाने की सुविधा देते हैं

इन तरीकों को लगातार लागू करने पर आपके स्वचालन का आक्रमण-क्षेत्र हर समय रूट से घटकर केवल सिद्ध रूप से आवश्यक स्थानों पर रूट रह जाता है — यही सुदृढ़, उत्पादन-स्तर के Bash की पहचान है।

शुरुआत निःशुल्क

एआई शिक्षक के साथ DevOps बूटकैंप सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 142
पाठ: 568

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “न्यूनतम-अधिकार निष्पादन और sudo अनुशासन” पाठ निःशुल्क है?

हाँ — DevOps बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “न्यूनतम-अधिकार निष्पादन और sudo अनुशासन” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“न्यूनतम-अधिकार निष्पादन और sudo अनुशासन” में मैं क्या सीखूँगा?

अधिकार घटाएँ, sudo नियमों का दायरा कड़ा रखें और जोखिमपूर्ण ऑपरेशन से पहले प्रभावी UID की जाँच करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ DevOps बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या DevOps बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर DevOps बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।

“न्यूनतम-अधिकार निष्पादन और sudo अनुशासन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस DevOps बूटकैंप पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर DevOps बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

कमांड और तर्क इंजेक्शन रोकना
गोपनीय जानकारी का सुरक्षित प्रबंधन और परिवेश की स्वच्छता
न्यूनतम-अधिकार निष्पादन और sudo अनुशासन
ShellCheck से स्थैतिक विश्लेषण और ऑडिट

← DevOps बूटकैंप पर वापस जाएँ