Server-এর Linux — filesystem, user, permission আর package

১ · Server-এ কেন Linux, আর কোন Linux

আগের পর্ব DevOps আর SRE-তে দেখেছেন, যে দল software বানায়, চালানোর দায়ও তার। চালাতে হলে যন্ত্রটি চিনতে হবে। Cloud-এ যে virtual machine ভাড়া নেবেন, container চালাবেন, Kubernetes-এর যে node দেখবেন, তার বেশিরভাগের ভেতরে Linux. তাই মডিউল ২ শুরু হচ্ছে এখান থেকে।

Linux কেন? কারণগুলো ব্যবহারিক:

• প্রতি server-এ লাইসেন্স ফি নেই। একশো VM চালালেও OS-এর জন্য আলাদা ফি দিতে হয় না (RHEL-এর মতো সাবস্ক্রিপশন distribution বাদে)।
• সবকিছু লেখায়। Config সাধারণ text ফাইল, কাজ কমান্ডে। Text ফাইল git-এ রাখা যায়, কমান্ড script-এ বসানো যায়। Automation-এর জন্য এর চেয়ে ভালো ভিত্তি কমই আছে।
• স্ক্রিন লাগে না। দূর থেকে SSH দিয়ে চালানো হয়। Graphical desktop না থাকায় মেমরি আর CPU বাঁচে।
• Container-এর ভিত্তি। Container চলে Linux kernel-এর namespace আর cgroup সুবিধার ওপর। পর্ব ৩৬-এ এর ব্যবহার দেখবেন।

এর মানে এই নয় যে অন্য OS খারাপ। Windows Server সব বড় cloud-এ পাওয়া যায়, আর .NET Framework বা Active Directory-নির্ভর কাজে সেটিই ঠিক পছন্দ। তবে এই কোর্সের বেশিরভাগ tool Linux-কেন্দ্রিক।

Distribution — একই kernel, আলাদা সংসার

“Linux” শব্দটি কঠোর অর্থে শুধু kernel. আপনি যা install করেন, সেটি distribution বা distro: kernel, মৌলিক tool, package manager, আর একদল মানুষের নেওয়া সিদ্ধান্ত। অনেকটা একই চালের ভাত, কিন্তু আলাদা হোটেলের আলাদা রান্না আর আলাদা মেনু।

এখানকার প্রতিটি সময়সীমা বদলাতে পারে, তাই সিদ্ধান্তের আগে distribution-এর নিজের lifecycle পাতা দেখে নিন।

LTS — আসল পণ্য হলো সময়

LTS (Long Term Support) মানে নির্মাতা একটি নির্দিষ্ট release-এ বহু বছর নিরাপত্তা-সংশোধন দেওয়ার প্রতিশ্রুতি দেন। Ubuntu LTS-এ লেখার সময়ে সাধারণ support প্রায় পাঁচ বছর, আর RHEL পরিবারে প্রায় দশ বছর। এই সময়ে software-এর বড় version বদলায় না, কেবল ত্রুটি সংশোধন আসে। ফলে আপনার app হঠাৎ ভেঙে পড়ে না।

উল্টো পথটির নাম rolling release: সবসময় নতুন version, কিন্তু প্রায়ই বদল। Server-এ সাধারণত LTS-ই পছন্দ, কারণ এখানে নতুনত্বের চেয়ে পূর্বানুমেয়তা দামি।

২ · Filesystem-এর মানচিত্র — কোন জিনিস কোথায়

একটি বড় গুদামঘরের কথা ভাবুন। প্রতিটি মালের নির্দিষ্ট তাক আছে, তাই নতুন কর্মী এসেও জিনিস খুঁজে পান। Linux-এও একই ব্যবস্থা। Windows-এর মতো C: D: নেই। সবকিছু একটি গাছের ভেতরে, যার গোড়া /. কোন ধরনের ফাইল কোথায় থাকবে, তার মান হলো Filesystem Hierarchy Standard (FHS). Distribution-গুলো এটি মোটামুটি মেনে চলে, সামান্য পার্থক্যও আছে।

এই মানচিত্র মুখস্থের বিষয় নয়, কাজের বিষয়। Server-এ সমস্যা হলে প্রশ্নগুলো এই ক্রমেই আসে:

• Config কোথায়? /etc/nginx/ বা /etc/ssh/. এখানকার ফাইল বদলালে আচরণ বদলায়, তাই এগুলো Git বা IaC-তে রাখা ভালো।
• Log কোথায়? /var/log/ আর systemd-এর journal. পর্ব ১১-তে journalctl দেখবেন।
• Disk কে ভরাল? প্রায়ই /var/log বা /var/lib, যেমন database বা Docker-এর ডেটা।
• এই প্রোগ্রাম কোথা থেকে এলো? Package manager যা বসায় তা /usr-এ যায়। নিজে হাতে বসানো থাকে /usr/local বা /opt-এ, যাতে package manager-এর হিসাবের সাথে না মেশে।

ফাইল, inode আর directory-র তত্ত্ব এখানে আবার গড়ছি না। Operating Systems কোর্সের File concept আর access method আর Directory আর link পর্বে সেগুলো আছে। Terminal একেবারে নতুন হলে Linux terminal পর্ব আগে দেখে নিন।

৩ · User, group, root আর sudo — ক্ষমতা ভাগ করা

একটি মেসের কথা ভাবুন। প্রত্যেক বোর্ডারের নিজের ঘরের চাবি আছে। রান্নাঘরের চাবি আছে বাজার কমিটির (group). আর বাড়িওয়ালার কাছে আছে মাস্টার চাবি, যেটি সব তালা খোলে। Linux-এ user মানে বোর্ডার, group মানে কমিটি, আর root মানে বাড়িওয়ালা।

Kernel নাম চেনে না, সংখ্যা চেনে। প্রতিটি user-এর একটি UID, প্রতিটি group-এর একটি GID. UID 0 হলো root. নিচের আউটপুট একটি নমুনা, আপনার server-এ সংখ্যা ও নাম আলাদা হবে।

# উদাহরণ: নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ id
uid=1001(rahim) gid=1001(rahim) groups=1001(rahim),27(sudo)

Root দিয়ে সরাসরি login কেন নয়

“আমি তো একাই, root দিয়ে ঢুকলে সমস্যা কী?” কারণ চারটি:

• ভুলের মাপ। Root-এর কোনো বাধা নেই। একটি ভুল rm পুরো server মুছতে পারে। সাধারণ user-এর ভুল সাধারণত নিজের ফাইলেই থামে, অর্থাৎ blast radius ছোট থাকে।
• জবাবদিহি। তিনজন একই root দিয়ে ঢুকলে log বলতে পারে না কে কী করেছে। নিজের নামে ঢুকলে audit log-এ নাম থাকে।
• জানা নাম। Internet-এর স্বয়ংক্রিয় scanner প্রায় সবসময় “root” নামে চেষ্টা করে। নামটি বন্ধ থাকলে এক ধাপ বাধা বাড়ে।
• চুরির ক্ষতি। আপনার প্রোগ্রাম root হিসেবে চললে সেটির একটি ত্রুটিই পুরো যন্ত্র খুলে দিতে পারে।

পর্ব ০৬-এ cloud account-এর root account নিয়ে একই কথা পড়েছেন। স্তর আলাদা, নীতি এক: least privilege. Cloud image-এ সাধারণত ubuntu বা ec2-user-এর মতো একটি শুরুর user থাকে, আর root login বন্ধ বা সীমিত থাকে। Image-ভেদে এটি আলাদা, তাই ধরে না নিয়ে যাচাই করুন।

sudo — খাতায় সই করে চাবি নেওয়া

sudo একটি নির্দিষ্ট কমান্ড অন্য user হিসেবে, সাধারণত root হিসেবে, চালায়। কে কী চালাতে পারবে, তা লেখা থাকে /etc/sudoers আর /etc/sudoers.d/-তে। প্রতিটি ব্যবহার log-এ যায়। Debian পরিবারে admin group-এর নাম সাধারণত sudo, RHEL পরিবারে wheel. ঠিক যেন বাড়িওয়ালার ম্যানেজারের খাতায় সই করে এক কাজের জন্য চাবি নেওয়া।

# Edit only with: sudo visudo -f /etc/sudoers.d/deploy
# The deploy user may restart one service, and nothing else.
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart webapp

visudo ব্যবহার করুন, কারণ এটি সংরক্ষণের আগে syntax যাচাই করে। ভাঙা sudoers আপনাকে নিজের server থেকেই আটকে দিতে পারে। আর ALL=(ALL) NOPASSWD: ALL লিখলে কার্যত root-ই দিচ্ছেন। সাবধান থাকুন: vim বা tee-এর মতো প্রোগ্রামকে sudo দিলে সেটি দিয়ে যেকোনো ফাইল বদলানো যায়।

Service account — মানুষ নয়, app-এর পরিচয়

আপনার web app কার পরিচয়ে চলবে? আপনার নামে নয়, root-এ তো নয়ই। প্রতিটি app-এর জন্য আলাদা service account বানান, যার login নেই, home ফোল্ডার নেই, আর ক্ষমতা শুধু নিজের কাজটুকু। App-এ কোনো ত্রুটি থাকলেও ক্ষতি সেই account-এর সীমায় আটকে থাকে। nologin shell থাকায় এই account দিয়ে কেউ ঢুকতে পারে না।

# A system account with no login and no home directory
sudo useradd --system --no-create-home --shell /usr/sbin/nologin webapp

# A state folder only webapp can use
sudo install -d -o webapp -g webapp -m 750 /var/lib/webapp

# Config: root writes it, webapp may only read it
sudo install -d -o root -g webapp -m 750 /etc/webapp
sudo install -o root -g webapp -m 640 app.env /etc/webapp/app.env

এই পরিচয় দিয়ে service চালানো দেখবেন পর্ব ১১-তে। একই ভাবনা ফিরে আসবে পর্ব ৩১-এ cloud IAM-এর role হয়ে, আর পর্ব ৩৮-এ non-root container হয়ে।

৪ · rwx, octal, chmod, chown আর umask

পুরো তত্ত্ব আছে Operating Systems কোর্সের Linux permission পর্বে। এখানে শুধু server চালাতে যেটুকু হাতে লাগে।

প্রতিটি ফাইলের একটি owner, একটি group, আর একটি mode থাকে। Mode-এ তিন শ্রেণির (owner, group, other) জন্য তিনটি করে বিট: r = ৪, w = ২, x = ১. যোগ করলেই octal সংখ্যা। যেমন rw-r----- মানে owner ৪+২ = ৬, group ৪, other ০, অর্থাৎ 640.

chmod mode বদলায়, আর chown মালিক বদলায়। ফাইলের owner বা root mode বদলাতে পারেন, কিন্তু মালিকানা বদলাতে সাধারণত root লাগে। chown webapp:webapp data.db মানে owner আর group দুটোই webapp. -R দিলে পুরো গাছ বদলায়, তাই আগে দেখে নিন কোন path-এ চালাচ্ছেন।

নিচের converter-এ সংখ্যা বদলে নিজে পরীক্ষা করুন। শেষ অংশে আছে umask-এর হিসাব, যা একটু পরেই দেখবেন।

// Octal <-> rwx, special bits and umask. Change the lists, press Run again.
const SPECIAL = [0o4000, 0o2000, 0o1000];     // setuid, setgid, sticky
function toRwx(mode) {
  let out = "";
  for (let i = 0; i < 3; i++) {
    const b = (mode >> (6 - 3 * i)) & 7;
    const on = mode & SPECIAL[i];
    const low = i === 2 ? "t" : "s";
    const x = on ? (b & 1 ? low : low.toUpperCase()) : (b & 1 ? "x" : "-");
    out += (b & 4 ? "r" : "-") + (b & 2 ? "w" : "-") + x;
  }
  return out;
}
function toOctal(text) {
  let mode = 0;
  for (let i = 0; i < 3; i++) {
    const [r, w, x] = text.slice(i * 3, i * 3 + 3);
    const b = (r === "r" ? 4 : 0) + (w === "w" ? 2 : 0) + ("xst".includes(x) ? 1 : 0);
    mode |= b << (6 - 3 * i);
    if ("sStT".includes(x)) mode |= SPECIAL[i];
  }
  return mode;
}
const oct = (m) => m.toString(8).padStart(4, "0");

console.log("octal -> rwx");
for (const m of [0o644, 0o640, 0o600, 0o750, 0o777, 0o2775, 0o1777, 0o4755, 0o4644])
  console.log(" ", oct(m), toRwx(m));
console.log("rwx -> octal");
for (const t of ["rw-r-----", "rwxr-x---", "rwsr-xr-x", "rwxrwxrwt"])
  console.log(" ", t, oct(toOctal(t)));
console.log("umask: real rule is AND NOT, not subtraction");
for (const u of [0o022, 0o002, 0o027, 0o077, 0o033])
  console.log(" ", oct(u), "file", oct(0o666 & ~u), "dir", oct(0o777 & ~u));

umask — নতুন তালার ডিফল্ট

নতুন ফাইল বানালে mode কে ঠিক করে? প্রোগ্রাম চায় সাধারণত 666 (ফাইল) বা 777 (directory), আর umask তা থেকে কিছু বিট বন্ধ করে। নিয়মটি হলো mode = চাওয়া & ~umask. অনেক server-এ ডিফল্ট 022, ফলে ফাইল 644, যা সবাই পড়তে পারে। গোপন ফাইল লেখে এমন app-এর জন্য 027 বা 077 ভালো।

set -euo pipefail
lab=$(mktemp -d)                 # a private folder, removed at the end
trap 'rm -rf "$lab"' EXIT
cd "$lab"

umask 022
echo "port=8080" > app.conf
echo "DB_PASS=example" > app.env
printf 'echo deployed\n' > deploy.sh
mkdir shared
echo "== 1. as created (umask 022) =="
stat -c '%a %A %n' app.conf app.env deploy.sh shared

chmod 640 app.conf               # owner rw, group r, other nothing
chmod 600 app.env                # a secret: owner only
chmod u+x,g+x deploy.sh          # symbolic: add x, keep the rest
chmod 2775 shared                # setgid on a folder
echo "== 2. after chmod =="
stat -c '%a %A %n' app.conf app.env deploy.sh shared

echo "== 3. umask sets the starting mode =="
for m in 022 027 077 033; do
  ( umask "$m"
    touch "file$m"; mkdir "dir$m"
    stat -c "umask $m: %a %A %n" "file$m" "dir$m" )
done

Setuid — ধার করা পরিচয়

Setuid বিট থাকা প্রোগ্রাম চলে ফাইলের মালিকের পরিচয়ে, যে চালাল তার পরিচয়ে নয়। passwd এর পরিচিত উদাহরণ: সাধারণ user নিজের password বদলায়, কিন্তু password-এর ফাইলে লেখার অধিকার তো শুধু root-এর। তাই passwd root-এর পরিচয় ধার করে চলে। ধারণাটি কাজের, কিন্তু এমন প্রোগ্রামে একটি ত্রুটি মানেই root-এর ঝুঁকি। Server-এ এদের তালিকা রাখুন, আর অচেনা কিছু দেখলে খোঁজ নিন। Linux kernel script-এর ওপর setuid মানে না; এটি শুধু compiled প্রোগ্রামে কাজ করে।

৫ · Kernel কীভাবে সিদ্ধান্ত নেয়

সবচেয়ে বেশি ভুল বোঝা হয় এখানে। অনেকে ভাবেন, owner-এ না মিললে group, group-এ না মিললে other, এভাবে অনুমতি খোঁজা হয়। আসলে তা নয়। Kernel প্রথমে ঠিক করে আপনি কোন একটি শ্রেণিতে পড়েন, তারপর শুধু সেই শ্রেণির বিট দেখে। অন্য শ্রেণিতে অনুমতি থাকলেও লাভ নেই।

একটি বাস্তব অনুরোধ অনুসরণ করি। প্রসেসটি চলছে webapp user হিসেবে, যার group webapp আর appcfg. ফাইলটি হলো -rw-r----- root appcfg /etc/app.conf. দুটি directory-র mode 755, মালিক root. “পরে” চাপুন, ডান পাশের মান খেয়াল করুন।

1open("/etc/app.conf", read)2walk "/"    : x on dir?3walk "/etc" : x on dir?4uid == file owner?5file group in my groups?6class bits have r?7return fd or EACCES

এবার নিজে পরীক্ষা করুন। নিচের simulator একই নিয়মে চলে, আর root-এর বিশেষ নিয়মও আছে: read আর write-এ বিট লাগে না, কিন্তু চালানোর জন্য অন্তত একটি x বিট থাকতে হয়। শেষের তালিকায় নতুন অনুরোধ যোগ করে দেখুন।

// Unix permission check. Exactly ONE class applies: owner, else group, else other.
const users = { root: ["root"], webapp: ["webapp", "appcfg"],
                backup: ["backup"], rahim: ["rahim", "sudo"] };
const files = {
  "/":             { owner: "root",  group: "root",   mode: 0o755 },
  "/etc":          { owner: "root",  group: "root",   mode: 0o755 },
  "/etc/app.conf": { owner: "root",  group: "appcfg", mode: 0o640 },
  "/home":         { owner: "root",  group: "root",   mode: 0o755 },
  "/home/rahim":   { owner: "rahim", group: "rahim",  mode: 0o700 },
  "/home/rahim/a": { owner: "rahim", group: "rahim",  mode: 0o644 },
  "/home/rahim/b": { owner: "rahim", group: "rahim",  mode: 0o044 },
};
const WANT = { read: 4, write: 2, exec: 1 };
function classOf(user, node) {
  if (node.owner === user) return ["owner", 6];
  return users[user].includes(node.group) ? ["group", 3] : ["other", 0];
}
function allowed(user, node, bit) {
  if (user === "root") return bit !== 1 || (node.mode & 0o111) !== 0;
  return ((node.mode >> classOf(user, node)[1]) & bit) !== 0;
}
function check(user, want, path) {
  const parts = path.split("/").slice(1);
  for (let i = 0; i < parts.length; i++) {       // walk the parent folders first
    const dir = "/" + parts.slice(0, i).join("/");
    if (!allowed(user, files[dir], 1)) return `DENY  no x on ${dir}`;
  }
  const ok = allowed(user, files[path], WANT[want]) ? "ALLOW" : "DENY ";
  return `${ok} ${user === "root" ? "root rule" : classOf(user, files[path])[0]}`;
}
for (const [u, w, p] of [["webapp", "read", "/etc/app.conf"], ["webapp", "write", "/etc/app.conf"],
  ["backup", "read", "/etc/app.conf"], ["root", "write", "/etc/app.conf"],
  ["root", "exec", "/etc/app.conf"], ["rahim", "read", "/home/rahim/a"],
  ["webapp", "read", "/home/rahim/a"], ["rahim", "read", "/home/rahim/b"]])
  console.log(u.padEnd(7) + w.padEnd(6) + p.padEnd(15) + check(u, w, p));

৬ · Permission অডিট — ঝুঁকি খুঁজে বের করা

সিদ্ধান্ত বুঝলেন, এবার পুরো server-এ ভুল খোঁজার পালা। সবচেয়ে বিপজ্জনক ভুল হলো world-writable ফাইল, অর্থাৎ other-এর w বিট চালু। এমন script যে কেউ বদলে দিতে পারে, আর পরে root সেটি চালালে পুরো যন্ত্র ঝুঁকিতে পড়ে।

find-এর -perm তিন রকম: -perm 644 মানে হুবহু 644; -perm -o+w মানে বলা বিটগুলোর সবই আছে; -perm /022 মানে বলা বিটগুলোর অন্তত একটি আছে। নিচের script নিজের বানানো একটি ছোট ফোল্ডারে কাজ করে, আর সেখানে ইচ্ছা করে কিছু ভুল রাখা হয়েছে।

set -euo pipefail
lab=$(mktemp -d); trap 'rm -rf "$lab"' EXIT; cd "$lab"

# A tiny fictional app tree, with some mistakes on purpose
mkdir -p srv/app srv/uploads srv/spool etc
touch srv/app/main.py srv/app/notes.txt srv/app/.env srv/app/run.sh etc/tool
chmod 644 srv/app/main.py
chmod 664 srv/app/notes.txt      # the group may edit it, others may not
chmod 666 srv/app/.env           # mistake: anyone can edit a secret
chmod 777 srv/app/run.sh         # mistake: anyone can edit a script
chmod 777 srv/uploads            # mistake: no sticky bit
chmod 1777 srv/spool             # shared folder, sticky bit is set
chmod 4755 etc/tool              # setuid: must be on an approved list

echo "== exact mode 644 =="
find . -type f -perm 644 | sort
echo "== all of these bits: o+w =="
find . -type f -perm -o+w | sort
echo "== any of these bits: g+w, o+w =="
find . -type f -perm /022 | sort

n=0
flag() {                         # level, message, then find tests
  local level=$1 msg=$2 p; shift 2
  while IFS= read -r p; do
    printf '%s %s %s %s\n' "$level" "$(stat -c %a "$p")" "$p" "$msg"
    n=$((n + 1))
  done < <(find . "$@" | sort)
}
echo "== audit =="
flag HIGH "world-writable file" -type f -perm -o+w
flag HIGH "world-writable dir, no sticky" -type d -perm -o+w ! -perm -1000
flag WARN "setuid, check the allow-list" -type f -perm -4000
echo "findings: $n"

আসল server-এ এই খোঁজ একটু সাবধানে চালাতে হয়: -xdev দিয়ে একটি filesystem-এ থাকুন, যাতে /proc আর network disk-এ না ঢোকে। ফলাফল ঠিক করার আগে পড়ুন; অনেক package-এর setuid বিট ইচ্ছাকৃত। এটি শুধু খোঁজে, কিছু বদলায় না।

# Read-only checks. They list files and change nothing.
sudo find / -xdev -type f -perm -o+w
sudo find / -xdev -type d -perm -o+w ! -perm -1000
sudo find / -xdev -type f -perm -4000

৭ · Package manager — apt, dnf আর স্বাক্ষর করা package

আগের দিনে software বসাতে হলে source code নামিয়ে compile করতে হতো, আর প্রতিটি নির্ভরতা নিজে খুঁজতে হতো। Package manager এই কাজ করে দেয়। ধরুন ওষুধ কিনছেন: রাস্তার ফেরিওয়ালার বদলে অনুমোদিত দোকান, সিল করা প্যাকেট, আর গায়ে মেয়াদ লেখা। Repository সেই দোকান, signature সেই সিল।

Script-এ apt-এর বদলে apt-get লিখুন, কারণ apt-এর আউটপুট মানুষের জন্য, আর সেটি স্থির থাকার নিশ্চয়তা নেই। এবার দেখি apt install-এর ভেতরে কী হয়।

Types: deb
URIs: https://deb.example.org/debian
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/example-archive-keyring.gpg

Get:1 https://deb.example.org/debian stable InRelease
Get:2 https://deb.example.org/debian stable/main amd64 Packages
Reading package lists... Done
# saved in /var/lib/apt/lists/

The following NEW packages will be installed:
  nginx nginx-common
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Do you want to continue? [Y/n]

nginx_1.24.0-2_amd64.deb
nginx-common_1.24.0-2_all.deb
# SHA256 of the file == SHA256 in the signed list
a1b2c3... == a1b2c3...  OK

/usr/sbin/nginx
/etc/nginx/nginx.conf
/usr/lib/systemd/system/nginx.service
/var/log/nginx
# the record: /var/lib/dpkg/status

active
# RHEL family: installed but not started.
# There you run: systemctl enable --now nginx

স্বয়ংক্রিয় নিরাপত্তা update

নিরাপত্তা-ত্রুটি (CVE) প্রকাশের পর হাতে update-এর অপেক্ষা করা মানে ঝুঁকি খোলা রাখা। তাই unattended security update চালু রাখা হয়: শুধু নিরাপত্তা-সংশোধন নিজে থেকে বসে।

# Debian, Ubuntu
sudo apt-get install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

# RHEL family: in /etc/dnf/automatic.conf set
#   upgrade_type = security
#   apply_updates = yes
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

একটি বিষয় মনে রাখুন: live patch ব্যবস্থা না থাকলে kernel-এর update চালু হয় কেবল reboot-এর পর, আর চলমান service-কে নতুন library পেতে restart করতে হয়। Unattended tool ডিফল্টভাবে সাধারণত reboot করে না। Ubuntu-তে /var/run/reboot-required ফাইল থাকলে বুঝবেন reboot বাকি।

৮ · Disk — df, du, mount আর fstab

Production-এর একটি খুব পরিচিত ঘটনা: রাত তিনটায় app থেমে গেল, log-এ No space left on device. Disk-এর কাজ বুঝতে তিনটি প্রশ্ন যথেষ্ট: কতটুকু ভরেছে, কে ভরেছে, আর কোন disk কোথায় বসেছে। নিচের সব আউটপুট নমুনা, version-ভেদে আলাদা হতে পারে।

# উদাহরণ: কতটুকু ভরেছে (নমুনা আউটপুট)
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   30G   27G  1.4G  96% /
/dev/nvme1n1    100G   61G   34G  65% /data
tmpfs           1.9G     0  1.9G   0% /run

# উদাহরণ: কে ভরেছে (নমুনা আউটপুট)
$ sudo du -xh --max-depth=1 /var | sort -h | tail -4
120M    /var/cache
1.8G    /var/lib
19G     /var/log
21G     /var

হিসাব পড়ুন: / ৯৬% ভরা, আর তার ২১ GB যাচ্ছে /var-এ, যার ১৯ GB log. কারণটি প্রায়ই এমনই। সমাধান হলো log-এর ঘূর্ণন (logrotate) আর log-কে বাইরে পাঠানো (পর্ব ৬৪). হাতে মুছলে দুটি জিনিস মাথায় রাখুন। Size থেকে Used বাদ দিলে Avail মেলে না, কারণ ext4 সাধারণত root-এর জন্য কিছু জায়গা সংরক্ষিত রাখে। আর কোনো প্রসেস ফাইল খোলা রেখে থাকলে সেটি মোছার পরও জায়গা ফেরে না, যতক্ষণ না প্রসেস ফাইলটি বন্ধ করে।

আরেকটি ফাঁদ: df -h-এ জায়গা খালি, তবু একই error. তখন df -i দেখুন। প্রতিটি ফাইলের জন্য একটি inode লাগে, আর লাখ লাখ ছোট ফাইল inode শেষ করে দিতে পারে।

mount আর fstab

নতুন disk নিজে থেকে দেখা যায় না। তাকে গাছের কোনো একটি ফোল্ডারে বসাতে হয়; একে বলে mount. গুদামের একটি নির্দিষ্ট দরজা দিয়ে পাশের গুদামে যাওয়ার মতো: /data-এ ঢুকলেই আপনি আসলে অন্য disk-এ। Reboot-এর পরও বসে থাকতে হলে লিখতে হয় /etc/fstab-এ।

# device                                  mount  type  options                 dump pass
UUID=11111111-2222-3333-4444-555555555555 /data  ext4  defaults,noatime,nofail 0    2

• UUID: disk-এর নাম (/dev/nvme1n1) reboot-এ বদলে যেতে পারে, UUID বদলায় না।
• nofail: disk না পেলেও boot চলতে থাকে। Cloud-এ এটি জরুরি, কারণ volume খুলে নেওয়া (detach) থাকলে এই option ছাড়া server boot-এ আটকে যেতে পারে, আর তখন SSH দিয়েও ঢোকা যায় না।
• noatime: প্রতিবার পড়ার সময় “শেষ পড়ার সময়” লেখা বন্ধ করে, ফলে বাড়তি লেখা কমে।
• যাচাই: reboot-এর আগে sudo findmnt --verify চালান। ভুল fstab পরের boot ভাঙতে পারে।

Cloud-এর disk কেমন, আর কোনটি VM বন্ধ করলে মুছে যায়, তা দেখবেন পর্ব ২০-এ।

৯ · নতুন server শক্ত করা — প্রথম ঘণ্টার চেকলিস্ট

Public IP পাওয়া একটি server-এ কয়েক মিনিটের মধ্যেই অচেনা login চেষ্টা আসতে শুরু করে, কারণ scanner সারাক্ষণ internet ঘুরে বেড়ায়। Hardening মানে অপ্রয়োজনীয় দরজা বন্ধ করে আক্রমণের সুযোগ কমানো। নতুন দোকান খোলার আগে যেমন তালা বদলান, হিসাবের খাতা গুছিয়ে রাখেন, তেমন।

নিচের stepper-এ একটি কাল্পনিক Ubuntu VM ধাপে ধাপে শক্ত হচ্ছে। ঠিকানাটি উদাহরণের জন্য সংরক্ষিত 203.0.113.10. প্রতিটি ধাপে ডান পাশের অবস্থা কীভাবে বদলায়, খেয়াল করুন। RHEL পরিবারে কমান্ড একটু আলাদা, কিন্তু ক্রম একই।

# /etc/ssh/sshd_config.d/10-hardening.conf
# Keep your current session open while you test a new login.
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

এখানে ফাইলের নাম 10- দিয়ে শুরু, কারণ sshd একটি সেটিংয়ের প্রথম পাওয়া মানটি রাখে, আর ফাইলগুলো নামের ক্রমে পড়া হয়। Cloud image নিজস্ব ফাইল রাখতে পারে। তাই sudo sshd -T | grep -i passwordauth দিয়ে শেষ পর্যন্ত কী কার্যকর হলো, তা দেখে নিন।

১০ · AI-এর যুগে server চালানো

AI “Permission denied” দেখলে প্রায়ই সবচেয়ে ছোট সমাধানটি দেয়, আর সেটিই সবচেয়ে বিপজ্জনক। কাজ চলে যায়, ঝুঁকি থেকে যায়, আর আপনি টেরও পান না।

AI-এর কমান্ড চালানোর আগে যাচাইয়ের চেকলিস্ট

• প্রতিটি কমান্ড আর flag-এর অর্থ man পাতায় মিলিয়েছি; অচেনা flag অন্ধভাবে চালাইনি
• শুধু-দেখার রূপ আগে চালিয়েছি: apt-get -s, rm-এর আগে ls, chmod -R-এর আগে find
• 777, * অনুমতি, 0.0.0.0/0, যাচাই বন্ধের flag বা হাতে লেখা secret আছে কি না খুঁজেছি
• Production-এর আগে একটি throwaway VM বা container-এ চালিয়েছি (cloud VM-এ খরচ হতে পারে, তাই কাজ শেষে মুছে ফেলেছি, আর budget alert চালু রেখেছি)
• SSH বা firewall বদলানোর সময় পুরোনো session খোলা রেখেছি, আর ফিরে যাওয়ার পথ জানি