Linux সার্ভার রক্ষণাবেক্ষণের পূর্ণাঙ্গ চেকলিস্ট

Linux সার্ভার রক্ষণাবেক্ষণ বলতে আসলে যা বোঝায়

Linux সার্ভার রক্ষণাবেক্ষণ হলো একটি নির্দিষ্ট সময়সূচী অনুযায়ী নিয়মিত কিছু চেক করার প্রক্রিয়া, এটি কোনো নির্দিষ্ট সময়ে শেষ হয়ে যাওয়া প্রকল্প নয়। সাপ্তাহিক ভিত্তিতে আপনি নিশ্চিত করবেন যে আপডেটগুলো ইনস্টল হয়েছে কি না, ডিস্কে পর্যাপ্ত জায়গা আছে কি না, কোনো সার্ভিস বন্ধ হয়ে গেছে কি না এবং ব্যাকআপ প্রক্রিয়া সফলভাবে সম্পন্ন হয়েছে কি না। মাসিক ভিত্তিতে আপনি একটি রিস্টোর পরীক্ষা করবেন, সার্টিফিকেটের মেয়াদ শেষ হওয়ার তারিখ যাচাই করবেন, অ্যাকাউন্ট ও কি (keys) অডিট করবেন এবং পুরনো কার্নেল ও লগ ফাইল মুছে ফেলবেন। প্রতিটি ডিস্ট্রিবিউশন রিলিজের সময় আপনি ভার্সন আপগ্রেডের পরিকল্পনা করবেন এবং যে রিবুটটি বারবার পিছিয়ে দিচ্ছেন তা সম্পন্ন করবেন।

সার্ভার তৈরি করা একটি ভিন্ন কাজ, এবং একটি নতুন VPS-এর প্রথম দশ মিনিট অংশে সেই বিষয়টি আলোচনা করা হয়েছে। এই পৃষ্ঠাটি তার পরবর্তী এক বছরের কাজের জন্য। নিচে প্রতিটি আইটেম এমন সব ব্যর্থতার কথা উল্লেখ করে যা এটি প্রতিরোধ করে, কারণ যে চেকলিস্টের কোনো সুনির্দিষ্ট ফলাফল নেই, মানুষ তা ধীরে ধীরে করা বন্ধ করে দেয়।

এখানে দেওয়া কমান্ডগুলো উদাহরণস্বরূপ এবং চালানোর আগে সেগুলো পড়ে নেওয়া উচিত। আপনার সার্ভারের আউটপুটের সাথে এগুলো তুলনা করুন, কারণ ফ্রি স্পেস বা প্রসেস কাউন্টের সঠিক মান নির্ভর করে আপনার সার্ভার কী কাজ করছে তার ওপর। ডিস্ট্রিবিউশনভেদে চেক করার পদ্ধতিতে পার্থক্য থাকলে তা টেক্সটে উল্লেখ করা হয়েছে। উদাহরণগুলোতে Debian এবং Ubuntu-এর সাথে apt ব্যবহার করা হয়েছে। RHEL ফ্যামিলিতে টুলিং হলো dnf এবং বেশ কিছু পাথ ভিন্ন হয়।

কিভাবে একটি Linux সার্ভার রক্ষণাবেক্ষণ রুটিন বেছে নেবেন যা আপনি মেনে চলতে পারবেন

সাপ্তাহিক চেকগুলো এমন বিষয়গুলো কভার করে যা আপনার হস্তক্ষেপ ছাড়াই পরিবর্তিত হয়: প্যাকেজ, ডিস্কের ব্যবহার, সার্ভিসের অবস্থা এবং নির্ধারিত কাজ (scheduled jobs)। এগুলো নিজে থেকেই পরিবর্তিত হয়, তাই এক সপ্তাহের বেশি সময় এগুলো না দেখে ফেলে রাখা উচিত নয়।

মাসিক চেকগুলো ধীরগতির ক্ষয় বা সমস্যাগুলো কভার করে: মেয়াদোত্তীর্ণ হতে চলা সার্টিফিকেট, অব্যবহৃত অ্যাকাউন্ট যা কেউ মুছে ফেলেনি, /boot-এ জমে থাকা কার্নেল এবং লগ ফাইল যা এমন একটি রোটেশন রুল অতিক্রম করেছে যা আর কাজ করছে না। এগুলোর কোনোটিই আগামীকালই ভেঙে পড়বে না। কিন্তু শেষ পর্যন্ত এগুলোর সবই সমস্যার কারণ হবে।

রিলিজ চেকগুলো ক্যালেন্ডারের ওপর ভিত্তি করে হয়। একটি ডিস্ট্রিবিউশন রিলিজ হলো এমন একটি রক্ষণাবেক্ষণ কাজ যার একটি বাহ্যিক সময়সীমা থাকে, কারণ আপনার বর্তমান ভার্সনের সাপোর্ট শেষ হয়ে যাবে, আপনি প্রস্তুত থাকুন বা না থাকুন।

রক্ষণাবেক্ষণের কাজগুলো একটি নির্দিষ্ট সময়ে করুন, যেমন সাপ্তাহিক কাজের জন্য সোমবার সকাল এবং মাসিক কাজের জন্য মাসের প্রথম দিন। "যখন সময় পাব" এমন মানসিকতায় তৈরি চেকলিস্ট আসলে কোনো চেকলিস্ট নয়। কয়েকটি মেশিনের বেশি সার্ভার থাকলে, হাতে কাজ না করে একটি জায়গা থেকে সেগুলো পরিচালনা করুন, যা একটি জায়গা থেকে একাধিক Linux সার্ভার পরিচালনা করার বিষয়বস্তু।

সাপ্তাহিক যাচাই: আপডেটগুলো কি আসলেই ইনস্টল হয়েছে?

unattended-upgrades সক্রিয় করা মানেই এটি কার্যকর হয়েছে তা নিশ্চিত হওয়া নয়। সার্ভিসটি masked থাকতে পারে, কনফিগারেশন এমন কোনো অরিজিনের মধ্যে সীমাবদ্ধ থাকতে পারে যা আপনি ব্যবহার করেন না, অথবা একটি held প্যাকেজ পরবর্তী প্রতিটি রানকে বাধাগ্রস্ত করতে পারে। এটি ইনস্টল করার প্রক্রিয়া Ubuntu-তে স্বয়ংক্রিয় নিরাপত্তা আপডেট-এ আলোচনা করা হয়েছে। সাপ্তাহিক কাজের উদ্দেশ্য হলো আপনি যা ইনস্টল করেছেন তা সঠিকভাবে কাজ করছে কি না তা প্রমাণ করা।

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable হলো প্রকৃত পরিমাপক, কারণ এটি উদ্দেশ্যের পরিবর্তে বর্তমান অবস্থা রিপোর্ট করে। এই তালিকায় নিরাপত্তা আপডেটগুলো পড়ে থাকা মানে হলো অটোমেশন তার কাজ করছে না, তাই মেশিনটি প্যাচ করা হয়েছে ধরে নেওয়ার আগে লগটি পড়ুন। apt-mark hold দিয়ে পিন করা একটি প্যাকেজ চিরতরে এড়িয়ে যাওয়া হয় এবং এটি কোনো রিপোর্ট দেয় না, আর এই কারণেই একই ধাপে apt-mark showhold অন্তর্ভুক্ত করা প্রয়োজন।

এটি যে ব্যর্থতা প্রতিরোধ করে: আপডেটগুলো স্বয়ংক্রিয় হচ্ছে—এই বিশ্বাসে মাসের পর মাস একটি পরিচিত দুর্বলতাসম্পন্ন (vulnerable) প্যাকেজ চালিয়ে যাওয়া।

সাপ্তাহিক: ডিস্ক এবং ইনোড (inode) ধারণক্ষমতা

রুট ফাইলসিস্টেম পূর্ণ হয়ে গেলে এমন সব সমস্যা দেখা দেয় যা দেখে ডিস্কের সাথে সম্পর্কিত মনে হয় না। ডাটাবেস রাইট করতে অস্বীকার করে, লগিং বন্ধ হয়ে যায়, প্যাকেজ আপগ্রেড অসম্পূর্ণ থেকে যায় এবং কিছু সেটআপে নতুন সেশন খোলা যায় না কারণ সিস্টেম নিজের ফাইলগুলো লিখতে পারে না।

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i হলো সেই অর্ধেক অংশ যা বেশিরভাগ মানুষ এড়িয়ে যায়। ইনোড (inode) হলো নির্দিষ্ট সংখ্যক কাঠামো যা ফাইলের মেটাডেটা ধারণ করে। ফাইলসিস্টেমে ইনোড শেষ হয়ে যেতে পারে, যদিও df -h তখনও গিগাবাইট খালি থাকার রিপোর্ট দেয়। তখন রাইট অপারেশন ব্যর্থ হয় এবং আউটপুটে No space left on device দেখা যায়, অথচ ডিস্কে জায়গা খালি থাকে। প্রথমবার এমনটি ঘটলে এটি বুঝতে এক ঘণ্টা সময় নষ্ট হতে পারে। আটকে থাকা মেইল কিউ বা সেশন ডিরেক্টরি যা কেউ পরিষ্কার করে না—এমন লক্ষ লক্ষ ছোট ফাইল সাধারণত এর কারণ।

du -xh শুধুমাত্র একটি ফাইলসিস্টেমে কাজ করে, যা bind mount বা সংযুক্ত স্টোরেজ থাকা সার্ভারের জন্য প্রয়োজন। Docker হোস্টের ক্ষেত্রে এর সমাধান সাধারণত ইমেজ লেয়ার এবং অব্যবহৃত ভলিউমের মধ্যে থাকে, যা pruning Docker disk usage on a VPS-এ বর্ণিত পদ্ধতিতে পরিষ্কার করা যায়।

ফ্রি স্পেস আপনাকে ধারণক্ষমতা সম্পর্কে জানায়। এর নিচের স্টোরেজ তার নিজস্ব সময়সূচী অনুযায়ী ব্যর্থ হতে পারে, যা একটি আলাদা পরীক্ষা এবং এটি disk health monitoring on a VPS-এ কভার করা হয়েছে।

সাপ্তাহিক: কোন সার্ভিসগুলো আপনাকে না জানিয়েই বন্ধ হয়ে গেছে?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

একটি ইউনিট ক্র্যাশ করার পর যদি তার restart limit অতিক্রম করে, তবে সেটি failed অবস্থায় থেকে যায় এবং কোনো বার্তা দেয় না। এটি সম্পর্কে আপনাকে ইমেইল বা অন্য কোনো মাধ্যমে জানানো হয় না। list-timers হলো এই সমস্যার সমাধানের বেশি কার্যকর অংশ: এটি দেখায় প্রতিটি টাইমার শেষ কবে চলেছে এবং পরবর্তীবার কখন চলবে। যদি LAST-এর মান টাইমারের নিজস্ব বিরতির চেয়ে বেশি পুরনো হয়, তবে বুঝতে হবে সেই কাজটি আদৌ সম্পন্ন হয়নি।

সার্ভিসটি রিস্টার্ট করার আগে journalctl -u <unit> -n 100 --no-pager ব্যবহার করে সেই ইউনিটের জার্নাল পড়ুন। রিস্টার্ট করলে সমস্যার লক্ষণ মুছে যায়, ফলে পরবর্তীবার আরও খারাপ কোনো সময়ে একই সমস্যা না হওয়া পর্যন্ত আপনি আর এটি পরীক্ষা করার সুযোগ পাবেন না।

এটি যে ব্যর্থতা প্রতিরোধ করে: একটি মনিটরিং এজেন্ট, কিউ ওয়ার্কার বা ব্যাকআপ সার্ভিস, যা তিন সপ্তাহ আগে মেমোরি স্পাইকের কারণে বন্ধ হয়ে পড়ে আছে।

সাপ্তাহিক: ব্যাকআপ জব কি আসলেই সম্পন্ন হয়েছে?

একটি নির্ধারিত ব্যাকআপ এবং একটি সম্পন্ন ব্যাকআপ দুটি ভিন্ন বিষয়, এবং শুধুমাত্র সম্পন্ন ব্যাকআপই রিস্টোর করা সম্ভব। তাই ব্যাকআপ সম্পন্ন হয়েছে কি না তা নিশ্চিত করুন।

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

দুটি বিষয় নিশ্চিত করুন। সর্বশেষ রানটি শূন্য (zero) এক্সিট কোড দিয়েছে কি না এবং নতুন আর্কাইভটি সাম্প্রতিক কি না ও আপনার প্রত্যাশিত আকারের কাছাকাছি কি না। একটি ব্যাকআপ ফাইল যদি হঠাৎ তার স্বাভাবিক আকারের দশ ভাগের এক ভাগে নেমে আসে, তবে বুঝতে হবে এটি একটি ব্যর্থ ডাম্প যা একটি ফাইল তৈরি করেছে। এটি ব্যাকআপ ব্যর্থতার সবচেয়ে বিপজ্জনক রূপ, কারণ এর পরবর্তী সব প্রক্রিয়া স্বাভাবিক মনে হয়।

যদি আপনার স্ক্রিপ্ট কোনো ডাম্পকে পাইপলাইনের মাধ্যমে কম্প্রেসারের কাছে পাঠায়, তবে স্ক্রিপ্টের শুরুতে set -o pipefail যোগ করুন। এটি ছাড়া পাইপলাইনের এক্সিট স্ট্যাটাস শুধুমাত্র কম্প্রেসারের স্ট্যাটাস দেখাবে, আর কম্প্রেসার সফল হয়েছে কারণ সে এরর মেসেজটিই কম্প্রেস করেছে। ফলে জবটি প্রতি রাতে সফল হিসেবে রিপোর্ট করবে, অথচ বাস্তবে কোনো কার্যকর ডেটা ছাড়াই ছোট একটি আর্কাইভ তৈরি করবে।

মাসিক: অন্য কোথাও ব্যাকআপ রিস্টোর করুন

অধিকাংশ মানুষ এই ধাপটি এড়িয়ে যান, অথচ এই একটি ধাপই নির্ধারণ করে যে তালিকার বাকি কাজগুলোর কোনো গুরুত্ব ছিল কি না।

লাইভ ডেটার ওপর রিস্টোর না করে অন্য কোনো মেশিন বা নতুন কন্টেইনারে রিস্টোর করুন। এরপর রিস্টোর করা ফাইলগুলো খুলে নিশ্চিত হোন যে সেগুলো সঠিক আছে। টেবিলের সারি গণনা করুন। কোনো ডকুমেন্ট খুলে দেখুন। রিস্টোর করা অ্যাপ্লিকেশনে লগ-ইন করুন। ব্যাকআপ প্রক্রিয়া সম্পন্ন হওয়া মানে কেবল এটিই যে আর্কাইভটি পড়া সম্ভব, এর চেয়ে বেশি কিছু নয়।

রিপোজিটরি টুলগুলোর নিজস্ব যাচাইকরণ ব্যবস্থা থাকে: restic check --read-data-subset=5% এবং borg check --verify-data ইনডেক্সের পরিবর্তে সংরক্ষিত ডেটা সরাসরি পড়ে। এগুলো চালান, তবে এগুলোকে মূল পরীক্ষার বিকল্প হিসেবে নয়, বরং প্রাথমিক পরীক্ষা (smoke test) হিসেবে গণ্য করুন। যাচাইকরণ নিশ্চিত করে যে বাইটগুলো টিকে আছে কি না। আর রিস্টোর নিশ্চিত করে যে বাইটগুলো আপনার অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় কি না।

দুটি বিষয় মানুষ তিক্ত অভিজ্ঞতার মাধ্যমে শেখে। এমন একটি মেশিনে ডিক্রিপশন পাসফ্রেজ পরীক্ষা করুন যেখানে আগে থেকে কোনো এজেন্ট-এ কি (key) সংরক্ষিত নেই, কারণ যে ব্যাকআপ আপনি ডিক্রিপ্ট করতে পারেন না, তা কোনো ব্যাকআপই নয়। এছাড়া রিস্টোর করতে কত সময় লাগে তা মেপে দেখুন, কারণ এই সময়টুকুই আপনার প্রকৃত রিকভারি টাইম। সাধারণত কোনো বিপর্যয় ঘটার পরেই মানুষ এই সময় সম্পর্কে জানতে পারে।

মাসিক: কোন সার্টিফিকেটগুলোর মেয়াদ শীঘ্রই শেষ হবে?

রিনিউয়াল অটোমেশন অনেক সময় নীরবে ব্যর্থ হয়। certbot টাইমার ডিস্কে ফাইলটি রিনিউ করতে পারে, কিন্তু ওয়েব সার্ভার মেমোরি থেকে পুরনো সার্টিফিকেটটিই সার্ভ করতে থাকে, কারণ যে deploy hook সার্ভিসটি রিলোড করার কথা ছিল তা চলেনি। তাই সার্ভারের বাইরে থেকে জিজ্ঞাসা করুন যে এটি বর্তমানে কোন সার্টিফিকেট সার্ভ করছে।

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

-servername ফ্ল্যাগটি SNI (server name indication) সেট করে, যা একাধিক সাইট হোস্ট করা যেকোনো ঠিকানায় প্রয়োজন। এটি ছাড়া আপনি আপনারটির পরিবর্তে ডিফল্ট সার্টিফিকেট পাবেন। যদি certbot স্ন্যাপ (snap) থেকে ইনস্টল করা হয়ে থাকে, তবে টাইমারের নাম ভিন্ন হবে, তাই আপনার অনুমান করা ইউনিটের পরিবর্তে নামের সাথে মিল আছে কি না তা যাচাই করুন।

অটোমেশন নেই এমন সার্টিফিকেটগুলোর কথা মনে রাখুন: যেমন মেইল সার্ভার, VPN, বা অভ্যন্তরীণ সার্টিফিকেট অথরিটি (internal certificate authority)। এগুলোই সাধারণত ছুটির দিনে মেয়াদোত্তীর্ণ হয়, এবং ব্রাউজার বা ক্লায়েন্টরা তখন সতর্কবার্তা না দিয়ে সরাসরি সংযোগ প্রত্যাখ্যান করে।

মাসিক পর্যালোচনা: ব্যবহারকারী, sudo অ্যাক্সেস এবং SSH কী

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T কমান্ডটি প্রতিটি Include মার্জ হওয়ার পর কার্যকর কনফিগারেশন প্রদর্শন করে, যা মূলত ডেমোন (daemon) ব্যবহার করে। সাম্প্রতিক Ubuntu ইমেজগুলোতে /etc/ssh/sshd_config.d/ ডিরেক্টরিতে ড্রপ-ইন ফাইল থাকে, যা মূল ফাইলকে ওভাররাইড করতে পারে। তাই শুধুমাত্র sshd_config ফাইলটি পড়লে আপনি ভুল তথ্য পেতে পারেন। RHEL ফ্যামিলিতে অ্যাডমিনিস্ট্রেটিভ গ্রুপ wheel, sudo নয়, তাই সেই অনুযায়ী getent লাইনটি পরিবর্তন করুন।

এরপর সরাসরি authorized_keys ফাইলগুলো দেখুন। অ্যাক্সেস অ্যাকাউন্টের পরিবর্তে কী (key)-এর ভিত্তিতে দেওয়া হয়। তাই ছয় মাস আগে কাজ শেষ করা কোনো কন্ট্রাক্টরের ফেলে যাওয়া কী একটি সক্রিয় লগইন হিসেবে কাজ করবে, যা কোনো ইউজার লিস্টে ধরা পড়বে না। প্রতিটি কী-তে একটি কমেন্ট ফিল্ড থাকে। এটি ব্যবহার করুন এবং এমন যেকোনো কী মুছে ফেলুন যা আপনি কোনো নির্দিষ্ট ব্যক্তির সাথে মেলাতে পারছেন না।

লগইন ইতিহাসের জন্য, journalctl -t sshd --since "30 days ago" | grep -i accepted কমান্ডটি ইউনিট নামের পরিবর্তে syslog আইডেন্টিফায়ারের সাথে ম্যাচ করে। এটি গুরুত্বপূর্ণ কারণ Ubuntu 24.04 সকেটের মাধ্যমে SSH সক্রিয় করে। ফলে প্রতিটি সংযোগ একটি জেনারেটেড পার-কানেকশন ইউনিটের অধীনে লগ হয় এবং সাধারণ journalctl -u ssh কমান্ড ব্যবহার করলে সেগুলো বাদ পড়ে যেতে পারে।

মাসিক রক্ষণাবেক্ষণ: পুরনো কার্নেল এবং পূর্ণ হয়ে যাওয়া /boot

/boot সাধারণত একটি VPS ইমেজে কয়েকশ মেগাবাইটের একটি আলাদা পার্টিশন হিসেবে থাকে। প্রতিটি কার্নেল আপডেটের সাথে এতে একটি নতুন ইমেজ এবং initramfs যুক্ত হয়। এটি পূর্ণ হয়ে গেলে পরবর্তী আপগ্রেড মাঝপথে ব্যর্থ হয় এবং প্যাকেজগুলো অসংরক্ষিত (unconfigured) অবস্থায় থেকে যায়, যা শুক্রবারের মতো সময়ে অপ্রত্যাশিতভাবে পাওয়া একটি বাজে পরিস্থিতি।

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r সবার আগে চালান: এটি আপনার বর্তমানে চলমান কার্নেলের নাম দেখাবে, এবং আপনি যা-ই মুছে ফেলুন না কেন, এই কার্নেলটি অবশ্যই অক্ষত রাখতে হবে। apt autoremove সাধারণত Debian এবং Ubuntu-তে স্বাভাবিক পরিস্থিতি সামাল দেয়, কারণ কার্নেলগুলো স্বয়ংক্রিয়ভাবে ইনস্টল করা হিসেবে চিহ্নিত থাকে এবং বর্তমান কার্নেলটি সুরক্ষিত থাকে। বিশেষ ক্ষেত্রগুলো, যেমন ম্যানুয়ালি ইনস্টল করা কার্নেল বা এমন একটি /boot যা এতটাই পূর্ণ যে apt নিজেই কাজ করতে পারছে না, সেগুলো Ubuntu-তে পুরনো কার্নেল মুছে ফেলা নির্দেশিকায় আলোচনা করা হয়েছে।

মাসিক: লগ বৃদ্ধি এবং systemd journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug একটি ড্রাই রান এবং এটি কোনো কিছু লেখে না, তাই একটি লাইভ সার্ভারে এটি চালানো নিরাপদ। এটি চালানো গুরুত্বপূর্ণ কারণ রোটেশন রুলগুলো পাথ অনুযায়ী কাজ করে: কোনো আপগ্রেডের সময় যদি কোনো অ্যাপ্লিকেশনের লগ লোকেশন পরিবর্তিত হয়, তবে সেটি আর তার নিজস্ব রুলের আওতায় থাকে না এবং সেই ফাইলটি ডিস্ক পূর্ণ না হওয়া পর্যন্ত সীমাহীনভাবে বাড়তে থাকে।

journal-এর আকার systemd দ্বারা সীমাবদ্ধ করা থাকে, তবে এটি আপনার বেছে নেওয়া কোনো সংখ্যার পরিবর্তে ফাইলসিস্টেমের একটি ভগ্নাংশ অনুযায়ী হয়। আপনি যদি একটি নির্দিষ্ট সীমা নির্ধারণ করতে চান, তবে /etc/systemd/journald.conf-এ SystemMaxUse= সেট করুন এবং systemd-journald রিস্টার্ট করুন। sudo journalctl --vacuum-time=14d তাৎক্ষণিকভাবে জায়গা খালি করে দেয় এবং এটি একটি পলিসির পরিবর্তে একবারের কাজ, তাই কনফিগারেশন পরিবর্তনের সাথে এটি ব্যবহার করুন।

রিলিজ অনুযায়ী: যে রিবুট আপনি বারবার পিছিয়ে দিচ্ছেন

ডিস্কে থাকা একটি আপডেট করা kernel package মানেই চলমান kernel নয়। রিবুট না করা পর্যন্ত মেশিনটি পুরনো kernel-ই চালায়, এবং live patching যেখানে উপলব্ধ, তা কেবল কিছু নির্দিষ্ট ত্রুটি সংশোধন করে।

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

এই flag ফাইলটি Debian এবং Ubuntu-এর একটি রীতি, যা package script-এর মাধ্যমে তৈরি হয়। RHEL ফ্যামিলির সিস্টেমে এটি তৈরি হয় না, এবং সেখানে সমতুল্য প্রশ্নের উত্তর পাওয়া যায় needs-restarting -r-এর মাধ্যমে, যা dnf-utils থেকে আসে। সাম্প্রতিক Ubuntu server ইমেজগুলোতে ডিফল্টভাবে ইনস্টল থাকা needrestart kernel-এর নিচের স্তরের বিষয়গুলো সমাধান করে: এটি এমন সব process-এর তালিকা দেয় যা এখনো এমন একটি library ব্যবহার করছে যা ডিস্কে প্রতিস্থাপন করা হয়েছে। এই কারণেই একটি patched OpenSSL ব্যবহারকারী service-গুলো রিস্টার্ট না করা পর্যন্ত কার্যকর হয় না।

রিবুট এড়িয়ে না গিয়ে বরং তা শিডিউল করুন। /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; এবং Unattended-Upgrade::Automatic-Reboot-Time "03:00";-এ আপনার পছন্দমতো সময়ে রিবুট করার সিদ্ধান্ত নিন। একটি পরিকল্পিত রিবুটই একমাত্র পরীক্ষা যার মাধ্যমে বোঝা যায় সার্ভারটি পুনরায় সচল হবে কি না, কারণ একটি ত্রুটিপূর্ণ fstab এন্ট্রি বা এমন কোনো service যা আপনি enable করেননি, তা কেবল রিবুটের সময়ই ধরা পড়ে।

রিলিজ অনুযায়ী পরিকল্পনা: ডিস্ট্রিবিউশন আপগ্রেড

Ubuntu LTS রিলিজগুলোতে পাঁচ বছরের স্ট্যান্ডার্ড সাপোর্ট থাকে এবং অন্তর্বর্তীকালীন (interim) রিলিজগুলোতে নয় মাসের সাপোর্ট থাকে, তাই আপনার পছন্দের ওপর নির্ভর করবে আগামী কয়েক বছরের আপগ্রেড কাজের চাপ। এই বিষয়টি সার্ভারে LTS বনাম অন্তর্বর্তীকালীন রিলিজ-এ বিস্তারিত আলোচনা করা হয়েছে।

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade ফাইলটি পড়ে এবং Prompt=lts এটিকে শুধুমাত্র LTS থেকে LTS-এ স্থানান্তরের জন্য সীমাবদ্ধ করে। নতুন ভার্সনের রিলিজের দিনেই সাধারণত LTS থেকে LTS-এ যাওয়ার পথ উন্মুক্ত হয় না, বরং প্রথম পয়েন্ট রিলিজের সময় এটি কার্যকর হয়। তাই কোনো নির্দিষ্ট তারিখের ওপর ভিত্তি করে পরিকল্পনা না করে আপনার মেশিনে কী অফার করা হচ্ছে তা যাচাই করুন। আপগ্রেড প্রক্রিয়ার কৌশলগুলো Ubuntu 24.04 থেকে 26.04 আপগ্রেড-এ দেওয়া আছে।

পরিকল্পনায় তিন মাসের বাড়তি সময় হাতে রাখুন। একটি স্ন্যাপশট নিন এবং সেটি পুনরুদ্ধার করা যায় কি না তা পরীক্ষা করুন। আপনার থার্ড-পার্টি apt রিপোজিটরিগুলোর তালিকা তৈরি করুন (আপগ্রেড করার সময় এগুলো নিষ্ক্রিয় হয়ে যায় এবং নতুন রিলিজের জন্য প্রতিটির নতুন টার্গেট প্রয়োজন হয়)। কাজ শুরু করার আগেই রোলব্যাক পরিকল্পনা ঠিক করে নিন। আগস্ট 2026 অনুযায়ী, Ubuntu 24.04 LTS-এর স্ট্যান্ডার্ড সাপোর্ট এপ্রিল 2029 পর্যন্ত রয়েছে, তাই এটি একটি রুটিন শিডিউলিংয়ের বিষয়, জরুরি কোনো পরিস্থিতি নয়।

কী কী অটোমেট করবেন এবং কী কী ম্যানুয়াল রাখবেন

যেসব সিদ্ধান্ত আপনি ইতিমধ্যে নিয়ে ফেলেছেন সেগুলো অটোমেট করুন: সিকিউরিটি আপডেট, লগ রোটেশন, সার্টিফিকেট রিনিউয়াল এবং ব্যাকআপ জব। অ্যালার্টিং বা সতর্কীকরণ ব্যবস্থাও অটোমেট করুন, কারণ যে চেকটি আপনার মনে রাখার ওপর নির্ভর করে, সেটি রাত 2টার সময় আর করা হবে না। একটি এক্সটার্নাল মনিটর, যেমন Uptime Kuma দিয়ে সেলফ-হোস্টেড স্ট্যাটাস মনিটরিং, এমন একটি বিষয় ধরতে পারে যা কোনো অন-বক্স স্ক্রিপ্ট পারে না, আর তা হলো সার্ভারটি রিচেবল না থাকা।

দুটি বিষয় ম্যানুয়াল রাখুন: রিস্টোর টেস্ট এবং অ্যাকাউন্ট অডিট। দুটির ক্ষেত্রেই ফলাফল সঠিক কি না তা নির্ধারণ করার জন্য একজন মানুষের প্রয়োজন। আপনি যদি টার্মিনালের পরিবর্তে ব্রাউজারে মেশিনের অবস্থা দেখতে পছন্দ করেন, তবে সার্ভার ম্যানেজমেন্টের জন্য Cockpit বনাম Webmin নিবন্ধটি দুটি প্রচলিত ওয়েব কনসোলের তুলনা করে।

অটোমেশনের জন্য আবার নিজস্ব চেকিং প্রয়োজন, আর তাই এই তালিকার প্রথম সাপ্তাহিক কাজটি হলো আপডেটার যাচাই করা। যে অটোমেশন নীরবে ব্যর্থ হয় তা কোনো অটোমেশন না থাকার চেয়েও খারাপ, কারণ এটি একই সাথে ব্যর্থতাকে আড়াল করে এবং নিয়মিত চেক করার অভ্যাসটিও নষ্ট করে দেয়।

এক নজরে সম্পূর্ণ চেকলিস্ট

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

লিনাক্স সার্ভার রক্ষণাবেক্ষণ কত ঘন ঘন করা উচিত?

সাপ্তাহিক ভিত্তিতে এমন সব বিষয় দেখুন যা নিজে থেকেই পরিবর্তিত হয়: আপডেটের অবস্থা, ডিস্ক ও ইনোড (inode) ধারণক্ষমতা, ব্যর্থ ইউনিট এবং ব্যাকআপ জব সম্পন্ন হয়েছে কি না। মাসিক ভিত্তিতে ধীরগতির ক্ষয় বা সমস্যাগুলো পরীক্ষা করুন: রিস্টোর টেস্ট, সার্টিফিকেটের মেয়াদ, অ্যাকাউন্ট ও SSH কি (key) অডিট, পুরনো কার্নেল এবং লগের আকার। প্রতিটি ডিস্ট্রিবিউশন রিলিজের সময় ভার্সন আপগ্রেড করুন এবং বর্তমান কার্নেলে রিবুট করুন। একটি সুস্থ সার্ভারে সাপ্তাহিক এই কাজগুলো করতে মাত্র কয়েক মিনিট সময় লাগে; আর এই কারণেই কোনো সমস্যা হওয়ার অপেক্ষায় না থেকে নিয়মিত পরীক্ষা করা জরুরি।

ব্যাকআপ জব সফল হওয়ার রিপোর্ট দিলেও কেন রিস্টোর টেস্ট করতে হবে?

কারণ জবটি কেবল তার নিজস্ব এক্সিট স্ট্যাটাস রিপোর্ট করে, আর সেই স্ট্যাটাস 'সফল' দেখালেও আর্কাইভটি অকেজো হতে পারে। set -o pipefail ছাড়া কোনো ডাম্প যদি কমপ্রেশারে পাইপ করা হয়, তবে সেটি কমপ্রেশারের স্ট্যাটাস রিটার্ন করে। ফলে ডাম্প ব্যর্থ হলেও যদি কেবল একটি এরর মেসেজ তৈরি হয়, তবুও সেটি জিরো এক্সিট কোড দেয় এবং একটি ছোট ফাইল তৈরি করে। অন্য একটি মেশিনে রিস্টোর করুন, ডেটা ওপেন করুন এবং কিছু ফাইল বা এন্ট্রি গুনে দেখুন। রিস্টোর করার সময়টি পরিমাপ করুন, কারণ এই সময়টুকুই আপনার প্রকৃত রিকভারি টাইম।

প্রতিটি কার্নেল আপডেটের পর কি রিবুট করা বাধ্যতামূলক?

নতুন কার্নেল কার্যকর করতে রিবুট করা প্রয়োজন। Debian এবং Ubuntu-তে /var/run/reboot-required ফাইলের উপস্থিতি নির্দেশ করে যে কোনো প্যাকেজ রিবুট চেয়েছে, এবং /var/run/reboot-required.pkgs কমান্ডটি জানায় কোনটি। RHEL ফ্যামিলিতে এই ফাইলটি থাকে না, সেখানে dnf-utils প্যাকেজের needs-restarting -r কমান্ডটি একই প্রশ্নের উত্তর দেয়। অনির্দিষ্টকালের জন্য রিবুট এড়িয়ে না গিয়ে /etc/apt/apt.conf.d/50unattended-upgrades-এ একটি স্বয়ংক্রিয় রিবুট উইন্ডো সেট করুন। কারণ যে মেশিন এক বছর ধরে রিবুট করা হয়নি, তার বুট পাথ যেমন পরীক্ষিত নয়, তেমনি কার্নেলটিও পুরনো।

এই চেকগুলোর মধ্যে কোনগুলো নিরাপদে অটোমেট করা যায়?

যেসব কাজের সিদ্ধান্ত আগে থেকেই নেওয়া আছে, সেগুলো অটোমেট করুন: সিকিউরিটি আপডেট, লগ রোটেশন, সার্টিফিকেট রিনিউয়াল এবং শিডিউলড ব্যাকআপ। নোটিফিকেশনও অটোমেট করুন, যাতে কোনো ইউনিট ব্যর্থ হলে বা ডিস্ক পূর্ণ হয়ে গেলে তা কমান্ড না চালিয়েই আপনার কাছে পৌঁছে যায়। রিস্টোর টেস্ট এবং কি (key) অডিট ম্যানুয়ালি করুন, কারণ প্রতিটি ক্ষেত্রে ফলাফল সঠিক কি না তা যাচাই করার জন্য একজন মানুষের বিচারবুদ্ধি প্রয়োজন। এরপর অটোমেশনের ওপর একটি চেক রাখুন, কারণ অটোমেটেড আপডেটার ব্যর্থ হলে তা দেখে মনে হতে পারে সবকিছু ঠিকঠাক কাজ করছে।