Rocky Linux ও AlmaLinux-এ dnf-automatic কনফিগারেশন

Rocky Linux এবং AlmaLinux-এ dnf-automatic যা করে

Rocky Linux এবং AlmaLinux-এ unattended security updates পাওয়ার উপায় হলো dnf-automatic। এটি একটি ছোট প্রোগ্রাম, যা systemd timer দ্বারা চালু হয়। এটি /etc/dnf/automatic.conf ফাইলটি পড়ে এবং সেই ফাইলে যা অনুমোদিত, তা প্রয়োগ করে। এটি ইনস্টল করতে একটি কমান্ডই যথেষ্ট। এই গাইডের বাকি অংশে সেই সেটিংসগুলো নিয়ে আলোচনা করা হয়েছে, যা নির্ধারণ করে যে এটি আপনার সার্ভারকে সুরক্ষিত রাখবে নাকি নীরবে কোনো কাজ না করেই বসে থাকবে।

আপনি যদি Debian বা Ubuntu থেকে এসে থাকেন, তবে এটি Ubuntu VPS-এ unattended-upgrades যে কাজ করে, ঠিক সেই একই কাজ করে। সব পার্থক্যের মধ্যে একটি বিষয় সবচেয়ে গুরুত্বপূর্ণ: প্যাকেজ ম্যানেজারের কাছে "security" শব্দটির অর্থ কী। Ubuntu-তে এটি একটি আলাদা archive pocket। RHEL ফ্যামিলিতে এটি প্রকাশিত advisories-এর সাথে যুক্ত মেটাডেটা, এবং এই মেটাডেটা অনেক সময় অনুপস্থিত বা পুরনো হতে পারে। যদি আপনি এমন কোনো repository-তে dnf-automatic নির্দেশ করেন যেখানে কোনো advisory ডেটা নেই, তবে এটি কোনো কিছু ইনস্টল না করেই সফলতার রিপোর্ট দেবে।

এই গাইডটি Rocky Linux 9 এবং AlmaLinux 9-এর জন্য লেখা হয়েছে, যা আগস্ট 2026 অনুযায়ী DNF 4 (RHEL ফ্যামিলির প্যাকেজ ম্যানেজার) ব্যবহার করে। 10 রিলিজগুলো DNF5-এ স্থানান্তরিত হয়েছে এবং সেখানে নামগুলো পরিবর্তিত হয়েছে, তাই সেগুলোর জন্য শেষের দিকে আলাদা একটি সেকশন রাখা হয়েছে। নিচে দেওয়া প্রতিটি কমান্ড আপনার নিজের সার্ভারে চালানোর জন্য, এবং এর পাশে প্রত্যাশিত আউটপুট দেওয়া হয়েছে।

dnf-automatic ইনস্টল করুন এবং এর কনফিগারেশন ফাইলটি পড়ুন

স্বয়ংক্রিয় আপডেট চালু করার বিষয়টি নতুন VPS সেটআপের প্রথম দশ মিনিটের কাজের অন্তর্ভুক্ত, যা একজন নন-রুট ইউজার এবং ফায়ারওয়াল সেটআপ করার পরপরই করা উচিত। যদি ফায়ারওয়াল সেটআপ বাকি থাকে, তবে জেনে রাখুন Rocky এবং AlmaLinux-এ ডিফল্ট হিসেবে firewalld থাকে। কয়েকটি কমান্ডের মাধ্যমেই SSH এবং আপনার সাইটের লিসেনিং পোর্ট ওপেন করা যায় এবং রিবুট পরবর্তী সময়ের জন্য তা স্থায়ী করা সম্ভব।

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

নতুন ইনস্টলেশনে systemctl is-enabled কমান্ডটি disabled আউটপুট দেয়, কারণ প্যাকেজটি ইনস্টল করলেই কোনো সার্ভিস নিজে থেকে চালু হয় না। এটিই সবচেয়ে সাধারণ কারণ যার ফলে একটি সার্ভারে "dnf-automatic" থাকা সত্ত্বেও কোনো আপডেট কার্যকর হয় না।

একটি নির্দিষ্ট অপশনের ক্ষেত্রে DNF-এর ভার্সন গুরুত্বপূর্ণ। reboot সেটিংটি DNF 4.15 ভার্সনে যুক্ত করা হয়েছিল এবং Red Hat এটিকে নভেম্বর 2023-এ RHBA-2023:6645 অ্যাডভাইজরির মাধ্যমে dnf-4.14.0-6.el9-এ ব্যাকপোর্ট করে। Rocky 9 এবং AlmaLinux 9 এই প্যাকেজটি রিবিল্ড করে, তাই বর্তমানের সার্ভারগুলোতে এটি থাকলেও 2023 সালের পর থেকে আপডেট না করা সার্ভারগুলোতে এটি নাও থাকতে পারে।

কনফিগারেশন ফাইলটি হলো /etc/dnf/automatic.conf। এর সাথে আসা কপিতে এই বিল্ডের প্রতিটি অপশন এবং সেগুলোর ডিফল্ট মান কমেন্ট আকারে দেওয়া থাকে। এডিট করার আগে ফাইলটি একবার পড়ে নিন, কারণ আপনার ভার্সনের জন্য এই ফাইলটিই হলো সঠিক তথ্যের উৎস।

যে দুটি সুইচ নির্ধারণ করে কী ঘটবে

download_updates এবং apply_updates, [commands] সেকশনে থাকা এই দুটি প্যারামিটার নির্ধারণ করে সিস্টেমটি কীভাবে কাজ করবে। EL9 (Enterprise Linux 9, যা Rocky 9 এবং AlmaLinux 9-এর ভিত্তি) এ ডিফল্টভাবে এই দুটিই no করা থাকে। তাই আপনি যদি কোনো পরিবর্তন না করে dnf-automatic চালু করেন, তবে এটি কেবল আপনাকে জানাবে যে কী কী আপডেট পাওয়া যাচ্ছে।

• উভয়ই no: dnf-automatic কেবল উপলব্ধ আপডেটগুলোর রিপোর্ট দেয় এবং সার্ভারে কোনো পরিবর্তন করে না।
• download_updates = yes এবং apply_updates = no: প্যাকেজগুলো DNF ক্যাশে ডাউনলোড করে রাখা হয়। এতে ইনস্টলেশন দ্রুত হয় এবং নেটওয়ার্কের প্রয়োজন পড়ে না, তবে তাৎক্ষণিকভাবে কোনো কিছু পরিবর্তন হয় না।
• উভয়ই yes এবং upgrade_type = default: নিরাপত্তা সংক্রান্ত হোক বা না হোক, সব ধরনের উপলব্ধ আপডেট ইনস্টল করা হয়।
• উভয়ই yes এবং upgrade_type = security: শুধুমাত্র নিরাপত্তা সংক্রান্ত অ্যাডভাইজরিতে উল্লেখ করা প্যাকেজগুলো ইনস্টল করা হয়।

পাবলিক-ফেসিং VPS-এর জন্য একটি যুক্তিসঙ্গত শুরুর কনফিগারেশন হলো:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout হলো কত সেকেন্ড সময় সিস্টেমটি নেটওয়ার্ক সংযোগের জন্য অপেক্ষা করবে, যা সদ্য রিবুট হওয়া সার্ভারের ক্ষেত্রে গুরুত্বপূর্ণ। random_sleep হলো লোড ডিস্ট্রিবিউশনের একটি পুরোনো পদ্ধতি, বর্তমানে টাইমার এই কাজটি করে। সার্ভিসটি ঠিক কী কী ফ্ল্যাগ ব্যবহার করে চলছে তা দেখতে systemctl cat dnf-automatic.service কমান্ডটি চালান।

সকাল 06:00 পর্যন্ত অপেক্ষা না করে ফাইলটি আপনার প্রত্যাশা অনুযায়ী কাজ করছে কি না তা পরীক্ষা করুন:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

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

sudo dnf-automatic --downloadupdates --no-installupdates

Rocky এবং Alma-তে upgrade_type = security বলতে আসলে কী বোঝায়

DNF সংস্করণ নম্বর তুলনা করে কোনো আপডেট নিরাপত্তা আপডেট কি না তা নির্ধারণ করে না। এটি errata মেটাডেটা পড়ে: এটি updateinfo.xml নামে একটি ফাইল যা রিপোজিটরির ভেতরে প্রকাশিত হয়, যেখানে প্রতিটি অ্যাডভাইজরি সেই প্যাকেজগুলোর তালিকা দেয় যা ত্রুটি সংশোধন করে। AlmaLinux এগুলোকে ALSA অ্যাডভাইজরি হিসেবে প্রকাশ করে, Rocky এগুলোকে RLSA হিসেবে প্রকাশ করে। upgrade_type = security সেই মেটাডেটা থেকে একটি ফিল্টার তৈরি করে এবং শুধুমাত্র সেই প্যাকেজগুলো আপগ্রেড করে যা এর সাথে মিলে যায়।

এর দুটি ফলাফল পাওয়া যায়, এবং উভয়ই ব্যবহারকারীদের অবাক করে।

প্রথমত, মেটাডেটা না থাকলে কোনো আপডেট হয় না। যদি রিপোজিটরিতে কোনো updateinfo.xml না থাকে, তবে ফিল্টারটি কোনো কিছুর সাথেই মেলে না এবং রানটি জার্নালে এই লাইনটির মাধ্যমে শেষ হয়:

No security updates needed, but 3 updates available

সার্ভারটি প্যাচ করা হয়নি, এবং কোনো ব্যর্থতার রিপোর্টও পাওয়া যায়নি। নিজেই পরীক্ষা করে দেখুন:

dnf updateinfo list --security
dnf check-update

যদি dnf check-update প্যাকেজগুলোর তালিকা দেখায় কিন্তু dnf updateinfo list --security কিছুই প্রিন্ট না করে, তবে হয় পেন্ডিং কোনো আপডেটে অ্যাডভাইজরি নেই, অথবা রিপোজিটরিতে পড়ার মতো কোনো অ্যাডভাইজরি ডেটা নেই। Rocky এবং AlmaLinux উভয়ই এটি প্রকাশ করে, তাই এই দুটির ক্ষেত্রে খালি তালিকা সাধারণত সঠিক। CentOS Stream এটি মোটেও প্রকাশ করে না।

দ্বিতীয়ত, সিকিউরিটি মোড মানেই ন্যূনতম পরিবর্তন নয়। dnf-automatic সিকিউরিটি ফিল্টার যোগ করে এবং তারপর সাধারণ আপগ্রেড পাথ অনুসরণ করে, তাই অ্যাডভাইজরিতে নাম থাকা একটি প্যাকেজ রিপোজিটরির সর্বশেষ সংস্করণে চলে যায় এবং এর সাথে প্রয়োজনীয় ডিপেন্ডেন্সিগুলোও নিয়ে আসে। ছোট পদক্ষেপ, অর্থাৎ শুধুমাত্র সেই সংস্করণে যাওয়া যা অ্যাডভাইজরি সংশোধন করে, তা কেবল dnf upgrade-minimal --security ম্যানুয়ালি চালানোর মাধ্যমেই সম্ভব। dnf-automatic-এ এর জন্য কোনো সেটিং নেই।

Rocky-এর ক্ষেত্রে আরও একটি সতর্কতা প্রযোজ্য। Rocky তার নিজস্ব পাইপলাইনের মাধ্যমে Red Hat ডেটা থেকে errata তৈরি করে, এবং সেই পাইপলাইনটি পিছিয়ে পড়েছে। 2025 সালের সেপ্টেম্বর মাসে ব্যবহারকারীরা রিপোর্ট করেছিলেন যে Rocky 9 BaseOS updateinfo.xml 2024 সালের ডিসেম্বর থেকে আপডেট হয়নি, তাই --security সাম্প্রতিক অ্যাডভাইজরিগুলো থেকে বঞ্চিত ছিল এবং Rocky-এর কর্মীরা এটিকে একটি পরিচিত সমস্যা হিসেবে নিশ্চিত করেছেন। যদি আপনি upgrade_type = security-এর ওপর নির্ভর করেন, তবে মাঝে মাঝে সাম্প্রতিক RLSA ঘোষণার সাথে অ্যাডভাইজরি তালিকা মিলিয়ে দেখুন। এমন সার্ভারে যেখানে পরিবর্তন নিয়ন্ত্রণের চেয়ে নিরাপত্তা কভারেজ বেশি গুরুত্বপূর্ণ, সেখানে আপনার পছন্দমতো শিডিউলে upgrade_type = default চালানোই নিরাপদ সেটিং।

সিস্টেমটি যে systemd timer দিয়ে চলে

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers কমান্ডটি চালালে একটি সারি দেখাবে যেখানে NEXT সময়টি প্রায় একদিন পরের হবে। টেবিলটি খালি থাকলে বুঝতে হবে টাইমারটি চালু (enabled) করা নেই, তাই কোনো কাজই সম্পন্ন হবে না।

সফটওয়্যারের সাথে আসা টাইমারটি *-*-* 6:00 সময়ে চলে, যার সাথে RandomizedDelaySec=60m এবং Persistent=true যুক্ত থাকে। এই র‍্যান্ডম ডিলে বা বিলম্বের কারণে সার্ভারের বহরগুলো এক ঘণ্টার মধ্যে ছড়িয়ে পড়ে, ফলে সব সার্ভার একই সেকেন্ডে মিরর সার্ভারে চাপ সৃষ্টি করে না। Persistent=true এর অর্থ হলো, কোনো মেশিন যদি 06:00 টায় বন্ধ থাকে, তবে সেটি চালু হওয়ার পরপরই বাদ পড়া কাজটি সম্পন্ন করবে, দিনটি এড়িয়ে যাবে না।

শিডিউল পরিবর্তন করতে একটি ড্রপ-ইন (drop-in) ফাইল ব্যবহার করুন। মূল ইউনিট ফাইলটি এডিট করবেন না, কারণ প্যাকেজ আপগ্রেড হলে /usr/lib/systemd/system এর ভেতরের ফাইলগুলো মুছে নতুন ফাইল বসে যায়।

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

এখানে খালি OnCalendar= লাইনটি থাকা আবশ্যক। OnCalendar এর মানগুলো জমা হতে থাকে, তাই এই রিসেট না করলে আপনি 06:00 টার এন্ট্রির সাথে নতুন একটি এন্ট্রি যোগ করবেন এবং কাজটি দিনে দুইবার চলবে। systemctl list-timers dnf-automatic.timer চালিয়ে ফলাফল নিশ্চিত করুন এবং NEXT কলামটি দেখুন। একই ড্রপ-ইন নিয়ম অন্য যেকোনো শিডিউলের ক্ষেত্রেও প্রযোজ্য, যা systemd service এবং timer ইউনিট লেখা অংশে বিস্তারিত আলোচনা করা হয়েছে।

এবার সতর্ক হওয়ার পালা। প্যাকেজটিতে আরও তিনটি টাইমার থাকে: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer এবং dnf-automatic-install.timer। প্রতিটি টাইমার একই প্রোগ্রামকে ভিন্ন ভিন্ন কমান্ড-লাইন ফ্ল্যাগ দিয়ে চালায় এবং এই ফ্ল্যাগগুলো আপনার কনফিগারেশন ফাইলের download_updates ও apply_updates কে ওভাররাইড করে। dnf-automatic.timer এর পাশাপাশি এদের একটি চালু করলে কাজটি দুইবার দুই ধরনের আচরণ নিয়ে চলবে, যা দেখে মনে হতে পারে আপনার কনফিগারেশন ফাইলটি কাজ করছে না। একটি টাইমার চালু করে পরীক্ষা করুন:

systemctl list-unit-files 'dnf-automatic*'

কোনো কিছু কখন ইনস্টল করা হয়েছে তা কীভাবে জানব?

emit_via এর [emitters] সেকশন রিপোর্টিং নিয়ন্ত্রণ করে। systemd-এর অধীনে stdio ইমিটার জার্নালে লেখে, যা একটি নির্ভরযোগ্য বিকল্প কারণ এর জন্য অন্য কোনো কিছু ইনস্টল করার প্রয়োজন হয় না:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

motd ইমিটার রিপোর্টটিকে /etc/motd ফাইলে লেখে এবং সেই ফাইলের পূর্বের বিষয়বস্তু প্রতিস্থাপন করে। আপনি যদি সেখানে কোনো লগইন ব্যানার রাখেন, তবে এই ইমিটারটি ব্যবহার করবেন না।

email ইমিটারটি email_host এর email_port পোর্টে একটি SMTP (simple mail transfer protocol) সংযোগ খোলে, যার ডিফল্ট মান হলো localhost এবং 25। একটি নতুন VPS-এ সেখানে কোনো কিছু লিসেনিং অবস্থায় থাকে না, তাই সংযোগটি প্রত্যাখ্যাত হয় এবং কোনো মেইল পাঠানো হয় না। এর ওপর নির্ভর করার আগে ss -lnt | grep ':25' চালান এবং যদি আউটপুট খালি থাকে তবে একটি relay-only Postfix সেট আপ করুন। যখন মেইল কাজ করা শুরু করবে, তখন সাবজেক্টে Updates applied on 'web01'. লেখা থাকবে, যা system_name থেকে নাম গ্রহণ করবে।

অন্য যেকোনো কিছুর জন্য, command ইমিটার রিপোর্টটিকে আপনার কোনো প্রোগ্রামের স্ট্যান্ডার্ড ইনপুটে পাঠিয়ে দেয়:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages এর ডিফল্ট মান হলো no, যার অর্থ হলো কোনো রান ব্যর্থ হলে তা কিছুই রিপোর্ট করে না। এটি চালু করুন। এমন একটি প্যাচিং সিস্টেম যা কেবল সফলতার খবর দেয়, তা কোনো সিস্টেম না থাকার চেয়েও খারাপ, কারণ এই নীরবতাকে সুস্থতা হিসেবে ভুল করা হতে পারে।

dnf-automatic আপনার সার্ভিসগুলো রিস্টার্ট করে না

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

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s সেইসব systemd সার্ভিসগুলোর তালিকা দেখায় যেগুলোর ফাইল চালু হওয়ার পর পরিবর্তিত হয়েছে। -r একটি প্রশ্নের উত্তর দেয় এবং দুটি ব্লকের যেকোনো একটি প্রিন্ট করে:

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

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r কোনো গভীর বিশ্লেষণ নয়। এটি প্যাকেজের একটি নির্দিষ্ট তালিকা পরীক্ষা করে: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon এবং microcode_ctl। যদি এর মধ্যে কোনোটি শেষ রিবুটের পরে ইনস্টল করা হয়ে থাকে, তবে আপনি প্রথম উত্তরটি পাবেন। যখন সার্ভারের অন্য কোনো কিছুর জন্য রিবুট প্রয়োজন হয়, তখন /etc/dnf/plugins/needs-restarting.d/-এর অধীনে .conf দিয়ে শেষ হয় এমন একটি ফাইলে আপনার নিজস্ব প্যাকেজের নাম যোগ করুন।

স্ক্রিপ্টের জন্য একটি সতর্কতা: dnf needs-restarting -r রিবুট প্রয়োজন হলে এবং কমান্ডটি ব্যর্থ হলেও নন-জিরো (non-zero) এক্সিট কোড প্রদান করে, তাই শুধুমাত্র এক্সিট স্ট্যাটাস দেখে পার্থক্য করা সম্ভব নয়। আউটপুট টেক্সটটি পড়ুন।

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

কন্টেইনারের বিষয়টি আলাদা, কারণ dnf-automatic শুধুমাত্র হোস্টের প্যাকেজগুলো প্যাচ করে এবং ইমেজের ভেতরে থাকা ইউজারল্যান্ডকে স্পর্শ করে না। তাই Rocky Linux বা AlmaLinux-এ Docker Engine চালানো সার্ভারের ক্ষেত্রেও ইমেজগুলো পুনরায় পুল করতে হবে এবং কন্টেইনারগুলো নতুন করে তৈরি করতে হবে, যাতে প্যাচটি সেই কোডে পৌঁছায় যা প্রকৃতপক্ষে ট্রাফিক সার্ভ করছে।

বক্সটি কি নিজে থেকে রিবুট হওয়া উচিত?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never হলো ডিফল্ট সেটিং। when-changed কোনো আপডেট প্রয়োগ করার পরেই রিবুট করে। when-needed শুধুমাত্র তখনই রিবুট করে যখন needs-restarting -r-এর পেছনের চেকটি নিশ্চিত করে যে কোনো কোর প্যাকেজ প্রতিস্থাপিত হয়েছে; বেশিরভাগ সিঙ্গেল-সার্ভার ব্যবহারকারী এটিই চান এবং তারা নিজেরা একটি টাইমার উইন্ডো বেছে নেন। ডিফল্ট reboot_command সেটিংটি লগ-ইন করা ব্যবহারকারীদের shutdown-এর মাধ্যমে পাঁচ মিনিটের সতর্কতা দেয়, আপনি চাইলে এই সময়সীমা বাড়াতে পারেন।

এটি চালু করার আগে দুটি বিষয় নিশ্চিত করুন। আপনার প্রতিটি প্রয়োজনীয় সার্ভিসকে বুট হওয়ার সময় নিজে থেকেই চালু হতে হবে, যা সাধারণত হাতে চালু করা Docker Compose stack-এর ক্ষেত্রে অনুপস্থিত থাকে। এছাড়া আপনার প্রোভাইডারের কাছ থেকে কনসোল বা রেসকিউ অ্যাক্সেস থাকা প্রয়োজন, কারণ যে কার্নেল বুট হয় না তা SSH-এর মাধ্যমে ঠিক করা সম্ভব নয়। যদি এই দুটির কোনো একটিও না থাকে, তবে reboot = never সেটিংটি বজায় রাখুন এবং জার্নাল পড়ার পর নিজে রিবুট করুন।

Rocky, AlmaLinux এবং CentOS Stream: এদের পার্থক্য

Rocky 9 এবং AlmaLinux 9-এ উপরের সবকিছুই হুবহু এক, এমনকি কনফিগারেশন পাথ এবং ইউনিটের নামও। উভয়ই errata প্রকাশ করে, তাই upgrade_type = security-এ ফিল্টার করার মতো ডেটা থাকে। আগে বর্ণিত Rocky-এর পুরনো errata-এর বিষয়টি তাদের দৈনন্দিন কার্যপদ্ধতির অন্যতম একটি পার্থক্য, তাই যদি সার্ভারটি এখনো তৈরি না হয়ে থাকে, তবে compatibility promise এবং পুরনো CPU-এর জন্য সমর্থন, যা এই দুটিকে আলাদা করে তা বিবেচনা করুন।

CentOS Stream একটি ব্যতিক্রম এবং এটি বেশ গুরুত্বপূর্ণ। Stream রিপোজিটরিতে কোনো updateinfo.xml থাকে না, তাই সিকিউরিটি ফিল্টার কখনোই কোনো ফলাফল পায় না এবং প্রতিবার রান করলে No security updates needed রিপোর্ট করে। Stream-এর ক্ষেত্রে upgrade_type = default ব্যবহার করুন এবং মেনে নিন যে আপনি প্রতিটি আপডেট গ্রহণ করছেন। Stream, RHEL-এর চেয়ে এগিয়ে থাকে, তাই Rocky বা AlmaLinux-এর তুলনায় Stream বক্সে সেটিংস বেশি পরিবর্তিত হয়। এই পার্থক্যটি প্যাকেজিংয়ের কোনো ভুল নয়, বরং 2020 সালে Red Hat-এর নেওয়া সিদ্ধান্তের ফল, যার মাধ্যমে CentOS-কে RHEL-এর একটি রোলিং প্রিভিউতে পরিণত করা হয়, যা Rocky Linux এবং AlmaLinux তৈরির মূল কারণ।

Rocky 10 এবং AlmaLinux 10-এ DNF5 ব্যবহার করা হয়েছে, যা অনেক কিছুর নাম পরিবর্তন করেছে। আপস্ট্রিম DNF5 ডকুমেন্টেশন অনুযায়ী টাইমারটি হলো dnf5-automatic.timer, ডিফল্ট সেটিংস থাকে /usr/share/dnf5/dnf5-plugins/automatic.conf-এ এবং আপনার ওভাররাইডগুলো থাকে /etc/dnf/automatic.conf-এ। এটি download_updates-কে 'no'-এর পরিবর্তে 'yes' হিসেবে ডিফল্ট করে এবং upgrade_type হিসেবে distro-sync যোগ করে। অ্যাডভাইজরি কুয়েরি হলো dnf advisory list, যেখানে updateinfo-কে একটি অ্যালিয়াস হিসেবে রাখা হয়েছে। ভার্সন 9-এর জন্য লেখা কোনো গাইড থেকে প্যাকেজ বা ইউনিটের নাম কপি করার আগে আপনার সিস্টেমে আসলে কী ইনস্টল করা আছে তা নিশ্চিত করুন:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

এই বিষয়ের ওপর প্রকাশিত অনেক গাইড এখনো শুধুমাত্র Rocky 8 কভার করে। সেই গাইডগুলো লেখার পর থেকে অপশন সেট অনেক বেড়েছে, তাই পুরনো কোনো আর্টিকেলের ওপর নির্ভর না করে আপনার নিজের বক্সে থাকা কমেন্ট করা ফাইলটি যাচাই করুন।

ব্যর্থতার ধরন এবং যে বার্তাগুলো আপনি দেখবেন

কোনো কিছুই চলছে না। systemctl list-timers dnf-automatic.timer একটি খালি টেবিল প্রদর্শন করে এবং systemctl is-enabled dnf-automatic.timer-এ disabled প্রিন্ট হয়। প্যাকেজটি ইনস্টল করা হয়েছে, কিন্তু টাইমারটি কখনোই কার্যকর হয়নি।

জবটি চলে কিন্তু কিছুই ইনস্টল করে না। জার্নালে No security updates needed, but 3 updates available বার্তাটি থাকে। সিকিউরিটি ফিল্টার কোনো কিছুর সাথে মেলেনি, কারণ হয় পেন্ডিং কোনো অ্যাডভাইজরি নেই অথবা রিপোজিটরি কোনো অ্যাডভাইজরি ডেটা প্রকাশ করছে না।

একটি সেটিং উপেক্ষা করা হয়েছে বলে মনে হয়। DNF ডিবাগ লেভেলে automatic.conf-এ একটি অজানা অপশন লগ করে এবং তারপর ডিফল্ট মান ব্যবহার করে, তাই ভুল বানানের কোনো কি (key) কোনো পরিবর্তন ঘটায় না এবং কাউকে সতর্কও করে না। apply_update = yes লিখুন এবং apply_updates যদি no-এ থেকে যায়, তবে সার্ভারটি চিরকাল ডাউনলোড করবে কিন্তু কিছুই ইনস্টল করবে না। যেকোনো পরিবর্তনের পর sudo systemctl start dnf-automatic.service চালান এবং ফাইলের ওপর ভরসা না করে জার্নালটি পড়ুন।

জবটি দিনে দুবার চলে। দুটি টাইমার এনাবল করা আছে। systemctl list-unit-files 'dnf-automatic*' দেখাবে কোনটি চলছে, এবং অতিরিক্ত টাইমারগুলো এমন ফ্ল্যাগ পাস করে যা আপনার কনফিগারেশন ফাইলকে ছাপিয়ে যায়।

কোনো মেইল আসে না। হয় email ইমিটারের জন্য পোর্ট 25-এ কেউ লিসেন করছে না, অথবা send_error_messages এখনো no অবস্থায় আছে এবং রিপোর্ট করার মতো একমাত্র বিষয়টি ছিল একটি এরর।

প্যাচ করা সার্ভিসটি এখনো পুরোনো ভার্সন দেখাচ্ছে। ডিস্কের ফাইলটি নতুন কিন্তু মেমরিতে থাকা প্রসেসটি পুরোনো। dnf needs-restarting -s সেই সার্ভিসগুলোর নাম বলে দেয় যেগুলোকে রিস্টার্ট করতে হবে।

FAQ

Rocky Linux-এ dnf-automatic কি শুধুমাত্র security update ইনস্টল করে?

শুধুমাত্র যদি আপনি upgrade_type = security-কে /etc/dnf/automatic.conf ফাইলে সেট করেন এবং যদি আপনার রিপোজিটরিগুলো errata মেটাডেটা প্রকাশ করে। Rocky Linux এবং AlmaLinux উভয়ই এটি প্রকাশ করে, তাই ফিল্টারটি মেলানোর জন্য advisories খুঁজে পায়। ডিফল্ট হিসেবে upgrade_type = default সেট করা থাকে, যা apply_updates = yes হওয়ার সাথে সাথে সমস্ত উপলব্ধ আপডেট ইনস্টল করে ফেলে।

dnf-automatic কেন "No security updates needed, but 3 updates available" রিপোর্ট করে?

DNF রিপোজিটরি থেকে updateinfo.xml পড়ে সিদ্ধান্ত নেয় কোনটি security update, যেখানে প্রতিটি advisory-তে সেই আপডেটটি যে প্যাকেজগুলো ঠিক করে তার তালিকা থাকে। যখন এই মেটাডেটা অনুপস্থিত বা পুরনো থাকে, তখন সিকিউরিটি ফিল্টার কোনো কিছু খুঁজে পায় না, কিন্তু সাধারণ আপডেটগুলো পেন্ডিং থাকে, যা ঠিক এই লাইনটি তৈরি করে। CentOS Stream-এর ক্ষেত্রে এটি প্রত্যাশিত, কারণ তারা কোনো errata প্রকাশ করে না। Rocky বা AlmaLinux-এর ক্ষেত্রে, dnf updateinfo list --security-এর সাথে dnf check-update তুলনা করুন এবং আপনার মেটাডেটা আপ-টু-ডেট কি না তা যাচাই করুন।

kernel আপডেট হওয়ার পর dnf-automatic কি আমার সার্ভার রিবুট করবে?

আপনি না বললে এটি করবে না। reboot অপশনটি ডিফল্টভাবে never থাকে। reboot = when-needed সেট করলে, শুধুমাত্র তখনই রিবুট হবে যখন dnf needs-restarting -r-এর পেছনের চেকটি খুঁজে পাবে যে kernel বা glibc-এর মতো কোনো কোর প্যাকেজ বুট হওয়ার পর প্রতিস্থাপিত হয়েছে। reboot = when-changed যেকোনো আপডেট প্রয়োগের পরেই রিবুট করে। উভয়ই reboot_command ব্যবহার করে, যা ডিফল্টভাবে shutdown -r +5 থাকে এবং লগ-ইন থাকা ব্যবহারকারীদের একটি সতর্কবার্তা দেখায়।

dnf-automatic চলার সময় কীভাবে পরিবর্তন করব?

sudo systemctl edit dnf-automatic.timer চালান এবং একটি [Timer] সেকশন যোগ করুন, যেখানে একটি খালি OnCalendar= লাইন থাকবে এবং তার নিচে আপনার সময়সূচী থাকবে, যেমন OnCalendar=*-*-* 03:30। খালি লাইনটি প্রয়োজনীয় কারণ OnCalendar জমা হতে থাকে, তাই এটি বাদ দিলে ডিফল্ট 06:00-এর রানটি থেকে যাবে এবং তার সাথে নতুন একটি সময় যোগ হবে। systemctl list-timers dnf-automatic.timer দিয়ে যাচাই করুন এবং NEXT কলামটি পড়ুন।

নিজে নিজে প্যাচ হওয়া সার্ভার কি আমার চেক করা প্রয়োজন?

হ্যাঁ। dnf-automatic শুধুমাত্র প্যাকেজ ইনস্টল করে এবং সেখানেই থেমে যায়। এটি daemon রিস্টার্ট করে না এবং আপনি যদি এমন কোনো emit_via সেট না করেন যা আপনি নিয়মিত দেখেন, তবে এটি কোনো রিপোর্টও দেবে না। অন্তত emit_via-কে stdio-তে সেট করুন, send_error_messages চালু করুন যাতে ব্যর্থতার রিপোর্ট পাওয়া যায় এবং প্যাচ উইন্ডোর পরে dnf needs-restarting -s চালান যাতে পুরনো কোড চালানো সার্ভিসগুলো খুঁজে পাওয়া যায়।