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

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

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

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

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

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

স্বয়ংক্রিয় আপডেট চালু করার বিষয়টি নতুন VPS-এ প্রথম দশ মিনিট-এর অন্যান্য কাজের সাথে সম্পন্ন করা উচিত, বিশেষ করে যখন আপনার কাছে একটি non-root user এবং firewall তৈরি থাকে।

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। এই ফাইলে আপনার বিল্ডে সমর্থিত প্রতিটি অপশন এবং সেগুলোর ডিফল্ট মান মন্তব্য (comment) আকারে দেওয়া আছে। সম্পাদনা করার আগে ফাইলটি একবার পড়ে নিন, কারণ আপনার ভার্সনের জন্য এই ফাইলটিই সঠিক তথ্যের উৎস।

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

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 শুধুমাত্র ভার্সন নম্বর তুলনা করে কোনো আপডেট নিরাপত্তা আপডেট কি না তা নির্ধারণ করে না। এটি 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 চালানোই বেশি নিরাপদ।

সিস্টেমটি টাইমার যা প্রকৃতপক্ষে এটি চালায়

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

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

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

একটি ড্রপ-ইন ফাইল ব্যবহার করে সময়সূচী পরিবর্তন করুন। মূল ইউনিট ফাইলটি এডিট করবেন না, কারণ প্যাকেজ আপগ্রেডের সময় /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 সার্ভিস এবং টাইমার ইউনিট লেখা অংশে বিস্তারিত আলোচনা করা হয়েছে।

এখন একটি সতর্কবার্তা। প্যাকেজটিতে আরও তিনটি টাইমার থাকে: 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_port-এর মাধ্যমে email_host-এ একটি 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 সেশন থেকে রিস্টার্ট করুন, যাতে ভুল কনফিগারেশনের কারণে আপনি লকড আউট না হয়ে যান। নতুন কার্নেলের ক্ষেত্রে শুধুমাত্র রিবুটই কার্যকর, কারণ চলমান কার্নেলকে সরাসরি প্রতিস্থাপন করা সম্ভব নয়।

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

[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-এ ফিল্টার করার মতো ডেটা থাকে।

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

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-তে সংশ্লিষ্ট প্যাকেজের তালিকা থাকে। যখন এই মেটাডেটা অনুপস্থিত বা পুরনো থাকে, তখন security ফিল্টার কোনো কিছু খুঁজে পায় না কিন্তু সাধারণ আপডেটগুলো পেন্ডিং থাকে, যা ঠিক এই লাইনটি তৈরি করে। 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-এ এমন কোনো emitter সেট না করেন যা আপনি নিয়মিত দেখেন, তবে এটি কোনো রিপোর্টও দেবে না। অন্তত emit_via-কে stdio-এ সেট করুন, ব্যর্থতার রিপোর্ট পাওয়ার জন্য send_error_messages চালু করুন এবং প্যাচ উইন্ডোর পর dnf needs-restarting -s চালিয়ে দেখুন কোন সার্ভিসগুলো এখনো পুরনো কোড চালাচ্ছে।