Rocky ও AlmaLinux-এ EPEL এবং CRB চালু করার নিয়ম

আপনার প্রয়োজনীয় package dnf খুঁজে না পাওয়ার কারণ

EPEL এবং CRB হলো সেই দুইটি repository, যা নতুন Rocky Linux বা AlmaLinux server-এ শুরু থেকেই দেওয়া থাকে না। তাই নতুন server-এ dnf install htop চালালে No match for argument: htop এবং পরে Error: Unable to find a match: htop দেখা যায়। কোনো কিছু নষ্ট হয়নি এবং কোনো mirror-ও বন্ধ নেই। Base distribution ইচ্ছাকৃতভাবে সীমিত সংখ্যক package সরবরাহ করে। CRB উপস্থিত থাকলেও এটি বন্ধ থাকে। আর EPEL হলো আলাদা একটি community repository, যা আপনাকে নিজে যোগ করতে হবে।

Ubuntu-তে একই package universe-এ থাকে এবং প্রায় সব cloud image-এ universe enabled থাকে। তাই সেখানে এই প্রশ্ন ওঠে না। Red Hat family তাদের package ভিন্নভাবে ভাগ করে এবং default হিসেবে কম package দেয়। সমাধান তিনটি command। এই guide-এর বাকি অংশে সেই বিষয়গুলো ব্যাখ্যা করা হবে, যা প্রথম সপ্তাহে সাধারণত কেউ বলে না: repository-গুলো কী সরবরাহের প্রতিশ্রুতি দেয়, কী দেয় না, এবং কীভাবে কোনো third-party repository-কে নীরবে আপনার base system নিয়ন্ত্রণ নেওয়া থেকে আটকাবেন।

এই command-গুলো কীভাবে পরীক্ষা করা হয়েছে। আমাদের command test container-গুলোতে শুধু Ubuntu চলে। তাই নিচের dnf command-গুলো আমাদের নিজস্ব test machine-এ চালানো হয়নি। এগুলো Rocky Linux এবং AlmaLinux-এর documentation অনুসরণ করে। প্রতিটি ধাপে প্রত্যাশিত output উল্লেখ করা হয়েছে। তাই পুরো block একবারে paste না করে নিজের server-এ প্রতিটি ধাপ আলাদাভাবে পরীক্ষা করুন।

BaseOS, AppStream এবং CRB কী?

BaseOS হলো অপারেটিং সিস্টেম নিজেই: kernel, glibc, systemd এবং মূল userland। প্রধান release-এর জীবনচক্রে এখানকার version খুব কমই পরিবর্তিত হয়। অধিকাংশ fix, security fix-সহ, আপনার ব্যবহৃত version-এই backport করা হয়। তবে কোনো minor release মাঝে মাঝে core component-কে আরও নতুন upstream version-এ rebase করে। যেমন, AlmaLinux 9.2 SELinux user-space package-গুলোকে version 3.5-এ update করেছিল। BaseOS-এ কোনো version number বহু বছরের পুরোনো দেখালেই package-টি unpatched নয়। সেটি patched পুরোনো version হতে পারে। Enterprise distribution-এর মূল উদ্দেশ্যই হলো এটি।

AppStream-এ থাকে যেসব জিনিস আপনি অপারেটিং সিস্টেমের ওপর চালান: web server, database, language runtime, editor এবং monitoring agent। version 8-এ AppStream-এর বড় অংশ alternate stream-সহ module হিসেবে সরবরাহ করা হতো। তাই dnf module list গুরুত্বপূর্ণ ছিল এবং, উদাহরণস্বরূপ, আপনাকে একটি PHP stream বেছে নিতে হতো। Version 9 প্রতিটি application-এর default version-কে সাধারণ package হিসেবে সরবরাহ করে। তাই Rocky 9 এবং Alma 9-এ সাধারণ dnf install ব্যবহার করলে আগে কোনো module enable না করেই সেই version পাওয়া যায়। Alternate version-গুলো এখনও module stream হিসেবে আসে। RHEL 9-এ PHP 8.0 সাধারণ php package হিসেবে এবং PHP 8.1 ও 8.2 যথাক্রমে php:8.1 ও php:8.2 stream হিসেবে নথিবদ্ধ আছে। AlmaLinux 9.8-এ MariaDB 11.8, PostgreSQL 18 এবং Ruby 4.0-এর মতো নতুন stream যোগ হয়েছে। Default version ছাড়া অন্য কিছু প্রয়োজন হলে 9-এও dnf module list গুরুত্বপূর্ণ।

Extras default হিসেবে enabled থাকে এবং এর আকার খুব ছোট। এতে মূলত অন্যান্য repository-এর release package থাকে। সেখান থেকেই epel-release নিজে আসে। এই কারণেই Rocky বা Alma-তে EPEL install করার জন্য random URL-এর ওপর নির্ভর করার প্রয়োজন হয় না।

CRB হলো CodeReady Builder repository। version 8-এ এর নাম ছিল PowerTools। এতে distribution-এর build-সংক্রান্ত উপাদান থাকে: development header, static library এবং package build করার সময় প্রয়োজনীয় test ও documentation tooling। এটি mirror-এ আগে থেকেই থাকে, তবে default হিসেবে disabled থাকে। Red Hat-এর নিজস্ব product-এ একই content-এর নাম CodeReady Linux Builder। এটি subscription-এর সঙ্গে আসে, এবং Red Hat জানায় যে এটি support-এর আওতাভুক্ত নয়। Rocky ও Alma উভয়ই একই content এবং disabled default উত্তরাধিকারসূত্রে পায়।

Debian বা Ubuntu থেকে আসা পাঠকদের জন্য: main একই archive-এ runtime package এবং -dev header একত্রে রাখে। তাই সেখানে enable করার জন্য CRB নেই। EPEL-এর সবচেয়ে কাছের সমতুল্য হলো universe। এটি community-maintained এবং vendor support-এর কোনো নিশ্চয়তা দেয় না।

EPEL কী এবং এর পেছনে কারা আছে

EPEL-এর পূর্ণরূপ Extra Packages for Enterprise Linux। এটি Fedora-এর একটি project: Fedora-তে থাকা package-গুলো বর্তমান enterprise release-এর জন্য পুনরায় build করা হয় এবং EPEL Special Interest Group সেগুলো maintain করে। এই group-এর সদস্যদের বেশিরভাগই Fedora community-এর volunteer। Red Hat build ও mirror infrastructure host করে, এবং কিছু Red Hat engineer এতে package maintain করেন। সম্পর্কটি এখানেই শেষ। EPEL কোনো Red Hat product নয়। EPEL package-এর জন্য RHEL বা কোনো rebuild-এ support contract বা SLA (service level agreement) নেই।

একটি policy EPEL enable করাকে নিরাপদ করে: EPEL package কখনো base distribution-এর কোনো package replace করতে পারবে না। AppStream যদি nginx ship করে, EPEL তা করবে না। EPEL package review করা ব্যক্তিরাই এই নিয়ম প্রয়োগ করেন, তাই এটি শুধু EPEL-এর জন্য প্রযোজ্য একটি প্রতিশ্রুতি। পরে আপনি যোগ করা অন্য কোনো জিনিস থেকে এটি আপনাকে সুরক্ষা দেয় না।

EPEL-এর lifetime promise-ও base distribution-এর মতো নয়, এবং তৃতীয় বছরে এটিই সমস্যার কারণ হয়। BaseOS package সাধারণত major release-এর পুরো দশ বছর একই version ধরে রাখে। এই সময়ে fix backport করা হয় এবং কেবল মাঝে মাঝে পরিকল্পিত rebase করা হয়। EPEL maintainer অনেক ছোট একটি সময়সীমার দায়িত্ব নেন: EPEL-এর release based package lifetimes proposal অনুযায়ী, এটি অন্তত একটি RHEL minor release অথবা 13 মাস, যেটি কম, ততদিন। বাস্তবে বেশিরভাগ package এর চেয়ে অনেক বেশি সময় maintain করা হয়। Maintainer অন্য কাজে চলে গেলে কিছু package retire করা হয়। আবার কিছু package আপনার distro-এর lifetime চলাকালীন নতুন major version-এ চলে যায়, কারণ EPEL Fedora অনুসরণ করে। তাই একটি নিয়মিত dnf upgrade এমন একটি machine-এ EPEL tool-এর নতুন major version এনে দিতে পারে, যেটিকে আপনি stable মনে করেছিলেন। আপনি যে package-এর ওপর নির্ভর করেন, সেটিও আপনার কাছে পৌঁছানো কোনো announcement ছাড়াই update পাওয়া বন্ধ করতে পারে। নতুন version ইতিমধ্যে চলমান service-এ কার্যকর হয় না। তাই transaction শেষ হওয়ার পরে কোন process এখনও পুরোনো binary ব্যবহার করছে তা জানাতে needs-restarting ব্যবহার করা হয়।

EPEL enable করার আগে আরেকটি গুরুত্বপূর্ণ বিষয় জানা দরকার: আপনি যে পুরোনো minor release-এ server ধরে রেখেছেন, EPEL সেটির বিরুদ্ধে build করা হয় না। Fedora-এর EPEL policy অনুযায়ী, সর্বশেষ EPEL 10 minor version CentOS Stream 10-এর বিরুদ্ধে build করা হয়। আগের EPEL 10 minor version-গুলো নির্দিষ্ট RHEL 10 minor release-এর বিরুদ্ধে build করা হয়। EPEL 8 এবং 9-এর নিজস্ব target definition রয়েছে। আপনি যদি frozen mirror বা vendor point release repository ব্যবহার করে server-কে পুরোনো minor release-এ ধরে রাখেন, তাহলে কোনো EPEL package-এর এমন base library প্রয়োজন হতে পারে যা আপনার system-এ থাকা library-এর চেয়ে নতুন। dnf এটিকে missing dependency হিসেবে দেখায়। ফলে সমস্যাটি mirror-এর বলে মনে হয়, যদিও প্রকৃত কারণ version skew।

Rocky বা Alma-এ CRB সক্রিয় করে EPEL ইনস্টল করুন

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled-এ এখন baseos, appstream, extras, crb এবং epel তালিকাভুক্ত থাকার কথা। একটি ছোট epel-cisco-openh264 এন্ট্রিও দেখা যেতে পারে, যা epel-release যোগ করে। ওই তালিকায় crb না থাকলে সক্রিয় করার ধাপটি কার্যকর হয়নি। এর কারণ পরের section-এ ব্যাখ্যা করা হয়েছে।

Rocky 8 এবং Alma 8-এ repository-টির নাম এখনও PowerTools। তাই মাঝের command-টি হবে sudo dnf config-manager --set-enabled powertools। Repository id বড় হাতের ও ছোট হাতের অক্ষরনির্ভর। পুরোনো CentOS 8 documentation-এ এটি বড় হাতের অক্ষরে PowerTools লেখা হয়, যা মিলে না। AlmaLinux 10-এ 10.0 থেকে CRB repository ডিফল্টভাবে সক্রিয় থাকে (September 2025-এ পরিবর্তনটি করা হয়েছে)। তাই সেখানে শুধু epel-release ধাপটি প্রয়োজন।

epel-release আসে extras থেকে, যা আগে থেকেই সক্রিয়। তাই বিশ্বাস করার মতো কোনো URL নেই এবং হাতে কোনো key import করারও প্রয়োজন নেই। Package-টি /etc/yum.repos.d/epel.repo লেখে এবং /etc/pki/rpm-gpg/-এর অধীনে EPEL signing key ইনস্টল করে। ওই file-এ gpgcheck=1 নিশ্চিত করুন। Signature error এড়াতে --nogpgcheck ব্যবহার করতে বলে এমন যেকোনো guide উপেক্ষা করুন। Signature check ব্যর্থ হলে package-টি নিজের দাবিকৃত package নয়, অথবা আপনার clock ভুল।

Rocky-এ epel-release /usr/bin/crb-এ একটি ছোট helper-ও ইনস্টল করে। তাই plugin ছাড়াই sudo crb enable এবং crb status একই কাজ করে। নির্ভর করার আগে command -v crb দিয়ে এটি আছে কি না পরীক্ষা করুন। কারণ প্রতিটি rebuild-এর প্রতিটি branch-এ এটি থাকে না।

EPEL শুধু তালিকাভুক্ত নয়, reachable কি না নিশ্চিত করতে এমন একটি package-এর জন্য query করুন যা শুধু EPEL-এ পাওয়া যায়:

dnf repoquery --repo=epel htop

এতে package-এর নাম, version এবং architecture দেখা যাবে। কোনো output না থাকলে repository সক্রিয়, কিন্তু কোনো ফল দিচ্ছে না। সাধারণত এটি configuration সমস্যা নয়, mirror বা metadata-সংক্রান্ত সমস্যা। তাই এরপর sudo dnf clean all && sudo dnf makecache চেষ্টা করুন।

dnf কেন no such command: config-manager দেখায়

এটাই প্রথম সমস্যার কারণ। VPS provider-রা যে image দেয়, ঠিক সেগুলোতেই এটি বেশি ঘটে।

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager একটি plugin, dnf-এর built-in subcommand নয়। এটি dnf-plugins-core-এ অন্তর্ভুক্ত থাকে। Full server install-এ এটি সাধারণত ইনস্টল হয়। কিন্তু minimal image, cloud image এবং container image-এ এটি থাকে না। Package-টি এই virtual capability ঘোষণা করে বলে dnf-এর নিজস্ব পরামর্শটি কাজ করে:

sudo dnf install -y 'dnf-command(config-manager)'

এটি quote করে লিখুন। Parentheses হলো shell syntax। তাই quote ছাড়া version চালালে dnf error-এর বদলে syntax error দেখা যায়।

আপনার প্রয়োজনীয় repository-টি disabled থাকায় plugin ইনস্টল করতে না পারলে সরাসরি file সম্পাদনা করুন। কোন file-এ section-টি আছে তা খুঁজে বের করুন, file-টি খুলুন, এবং [crb]-এর অধীনে enabled=1 সেট করুন:

grep -rl crb /etc/yum.repos.d/

config-manager ঠিক এটিই লেখে। তাই হাতে করে করলে কোনো configuration হারায় না। dnf repolist --enabled ফলাফল নিশ্চিত করে।

কিছু EPEL package CRB সক্রিয় না করা পর্যন্ত install হবে না

দ্বিতীয় সাধারণ সমস্যাটিতে error message-এ CRB-এর কোনো উল্লেখ থাকে না। CRB-তে থাকা কোনো library-এর সঙ্গে link করা একটি EPEL package dependency resolution-এর সময় ব্যর্থ হয়। message-এ library এবং সেটি প্রয়োজন এমন package-এর নাম দেখা যায়:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

কারণ CRB disabled থাকায় dnf ওই library সরবরাহকারী একমাত্র repository দেখতে পায় না। ক্রমানুসারে এই দুটি বিষয় পরীক্ষা করুন:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

সাধারণ install এখনও ব্যর্থ হলেও দ্বিতীয় command যদি কোনো package-এর নাম দেখায়, তাহলে CRB বন্ধ আছে। এই ধরনের error এত সাধারণ যে এটি প্রতিরোধ করতে AlmaLinux version 10-এ CRB default হিসেবে সক্রিয় করেছে। --enablerepo=crb একটি single install-এর ক্ষেত্রে one-time flag হিসেবেও কাজ করে। তবে আপনি EPEL ব্যবহার করলে CRB স্থায়ীভাবে enabled রাখুন, কারণ পরবর্তী EPEL update আগে থেকে কোনো সতর্কতা না দিয়েই নতুন CRB dependency আনতে পারে।

এই প্যাকেজটি কোন repository থেকে এসেছে?

চারটি repository enable করে কয়েক সপ্তাহ কাজ করার পর, গুরুত্বপূর্ণ প্রশ্ন আর কী installed আছে তা থাকে না; বরং এটি কোথা থেকে এসেছে, সেটিই গুরুত্বপূর্ণ হয়ে ওঠে।

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

Installed package-এর ওপর dnf info চালালে একটি From repo line দেখায়। dnf list installed একই তথ্যের তৃতীয় column-এ সামনে একটি @ সহ দেখায়। তাই @epel অর্থ package-টি EPEL থেকে installed হয়েছে, আর @System অর্থ dnf জানে না এটি কোথা থেকে এসেছে। সাধারণত এর মানে, কেউ downloaded file-এর ওপর rpm -i চালিয়েছে। repoquery line প্রতিটি repository-এর package count দেখায়। উত্তরাধিকারসূত্রে পাওয়া কোনো server-এ এমন একটি repository থেকে চল্লিশটি package এসেছে, যার নাম আপনি কখনো শোনেননি—এটি দ্রুত শনাক্ত করার সবচেয়ে কার্যকর উপায়। শেষ command-টি একটি repository আপনাকে ঠিক কোন package দিয়েছে তা তালিকাভুক্ত করে। repository সরানোর সিদ্ধান্ত নেওয়ার আগে এই inventory প্রয়োজন।

এখানে apt-এর প্রচলিত command হলো apt-cache policy <package>। প্রথম মাসে dnf ও apt command-এর সমতুল্য তালিকাটি দ্বিতীয় tab-এ খোলা রাখা উপযোগী। flag আলাদা হলেও ধারণাগুলো সহজে মিলিয়ে নেওয়া যায়।

তৃতীয় পক্ষের repo যাতে BaseOS-এর package প্রতিস্থাপন করতে না পারে, তা কীভাবে বন্ধ করব?

EPEL এটি না করার প্রতিশ্রুতি দেয়। অন্য কোনো repository তা দেয় না। Database, agent বা language runtime-এর vendor repository এমন কোনো library-এর নিজস্ব build সরবরাহ করতে পারে, যেটি BaseOS-ও সরবরাহ করে। dnf সেটি install করবে, কারণ dnf-এর default নিয়মটি সরল: যে উৎস থেকেই আসুক, সর্বোচ্চ version জয়ী হয়।

দুটি control-এর মাধ্যমে বেশিরভাগ কাজ করা যায়। দুটিই /etc/yum.repos.d/-এর অধীনে repository file-এ থাকে।

priority= নির্ধারণ করে, একই package name একাধিক repository-তে থাকলে কোন repository জয়ী হবে। কম সংখ্যার অগ্রাধিকার বেশি এবং default হলো 99। তাই base repository-গুলোকে কম number এবং তৃতীয় পক্ষের repository-গুলোকে বেশি number দিন। এরপর তৃতীয় পক্ষের version নতুন হলেও dnf base package নেবে। আধুনিক dnf নিজেই এটি পরিচালনা করে। তাই CentOS 7 যুগের আলাদা yum-plugin-priorities package এখন আর সমাধানের অংশ নয়।

includepkgs= filter option-গুলোর মধ্যে বেশি শক্তিশালী। excludepkgs= কোনো repository থেকে নির্দিষ্ট package block করে। এতে repository কী কী package সরবরাহ করতে পারে, তা আগে অনুমান করতে হয়। includepkgs= এর বিপরীত কাজ করে: এই repository কেবল নির্দিষ্ট name-গুলো সরবরাহ করতে পারবে, অন্য কিছু নয়। কোনো vendor repository যদি শুধু তার নিজস্ব agent সরবরাহ করার কথা হয়, তাহলে এক লাইনই যথেষ্ট।

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Version 8-এ আরও একটি setting জানা দরকার। কোনো তৃতীয় পক্ষের repository-এর package একই name-এর AppStream module-এ থাকলে সেটি hidden থাকতে পারে। সেই repository-এর section-এ module_hotfixes=1 থাকলে dnf সেটির filtering বন্ধ করে। কোনো package vendor-এর repository-তে নিশ্চিতভাবে থাকা সত্ত্বেও missing দেখালে বা install না হলে, 8-এর machine-এ সাধারণত এটাই কারণ। Modular filtering conflict দেখানোর বদলে বেশিরভাগ dnf command-এর কাছে package-টিকে invisible করে। Version 9-এ module কম থাকলেও module stream এখনও সরবরাহ করা হয়। তাই vendor package কোনো module-এর সঙ্গে একই name শেয়ার করলে সেখানেও একই filtering প্রযোজ্য হতে পারে।

একটি package-কে একটি নির্দিষ্ট version-এ স্থির করতে python3-dnf-plugin-versionlock install করুন এবং sudo dnf versionlock add <package> ব্যবহার করুন। এটি apt-mark hold-এর সমতুল্য। Debian থেকে আসা ব্যবহারকারীদের জন্য একটি গুরুত্বপূর্ণ পার্থক্য মনে রাখুন: apt-এ বেশি Pin-Priority জয়ী হয়, কিন্তু dnf-এ কম priority জয়ী হয়।

RHEL-সংলগ্ন রিপোজিটরি মেশালে কেন সার্ভার upgrade করা যায় না

Rocky, Alma, CentOS Stream, Oracle Linux এবং RHEL এতটাই কাছাকাছি যে একটির package অন্যটিতে install হয়। আবার এগুলো এতটাই আলাদা যে ফলাফল এমন একটি system-এ পরিণত হয়, যেটি কেউ support করতে পারে না। এগুলো কেন এত কাছাকাছি, এবং Stream কেন এখন RHEL-এর পাশে না থেকে তার আগে থাকে, তা Red Hat Linux কীভাবে Fedora ও RHEL-এ বিভক্ত হলো এবং CentOS-এর কী পরিণতি হলো-তে ব্যাখ্যা করা হয়েছে।

এর মূল কারণ version number। CentOS Stream 9, RHEL 9-এর আগে চলে। Red Hat-এর বর্ণনা অনুযায়ী, Stream-এর code-ই পরবর্তী RHEL minor release-এ পরিণত হয়। Rocky 9 server-কে Stream repository-তে একবারের জন্যও, এমনকি একটি package-এর জন্যও point করলে, এমন package install হয়ে যায় যার version Rocky বর্তমানে যে version release করে তার চেয়ে এগিয়ে। পরবর্তী Rocky minor release হয়তো সেটি পুষিয়ে নিতে পারে। কিন্তু সেই release-এ package-টির version আপনার install করা version-এর সমান বা তার চেয়ে নতুন হবেই, এমন নিশ্চয়তা নেই। তা না হওয়া পর্যন্ত dnf upgrade package-টি পরিবর্তন করবে না। ফলে machine-এ এমন একটি combination চলে, যা কেউ test করেনি। আপনি system patched আছে মনে করলেও সেটি বছরের পর বছর নীরবে এমন অবস্থায় থাকতে পারে।

এর লক্ষণ হলো dnf upgrade কোনো কাজ নেই বলে দেখায়, আর sudo dnf distro-sync দীর্ঘ তালিকার package downgrade করার প্রস্তাব দেয়। distro-sync হলো repair tool। এটি enabled repository-গুলোতে বাস্তবে যে package version দেওয়া আছে, তার সঙ্গে সব installed package মিলিয়ে দেয়। প্রয়োজনে downgrade-ও করে। প্রথমে foreign repository disable করুন। তারপর tool-টি চালান। গ্রহণ করার আগে প্রস্তাবিত package তালিকা পড়ুন। পুরোনো RPM mirror-এ আর না থাকলে repair ব্যর্থ হয়। তখন dependency solver নিয়ে লড়াই করার চেয়ে clean image থেকে server পুনর্নির্মাণ করা দ্রুত এবং নিরাপদ।

ELevate ব্যবহারের পরে থেকে যাওয়া file ও package এই সমস্যার আরেকটি সাধারণ রূপ। ELevate হলো Leapp-এর ওপর নির্মিত AlmaLinux migration tool। এটি CentOS 7 server upgrade করতে বা rebuild-এর মধ্যে conversion করতে ব্যবহৃত হয়। তাড়াহুড়ো করে migration করলে /etc/yum.repos.d/-এ EL7 repository file থেকে যায় এবং EL7 package-ও installed থাকে। rpm -qa | grep el7 দিয়ে সেগুলো খুঁজে বের করুন। প্রতিটি এমন package, যেটি কোনো enabled repository কখনো update করতে পারবে না। পরে Leapp চালালে এগুলো এমন package হিসেবে দেখায়, যেগুলোর mapping করা যায় না। এতে upgrade blocker তৈরি হয়, যা আপনাকে হাতে সরাতে হয়। পরবর্তী major upgrade-এর দিন পর্যন্ত অপেক্ষা না করে server স্বাভাবিক অবস্থায় থাকতেই এগুলো সরিয়ে ফেলুন।

AppStream-এর package-কে shadow করা vendor repository একই সমস্যার হালকা রূপ। উপরের includepkgs line-ই এর সমাধান। Container tooling-এ এটি বেশি দেখা যায়। কারণ Docker-এর নিজস্ব repository-এর containerd.io, AppStream-এর runc-এর সঙ্গে conflict করে। তাই দুটির একটিকে সরাতে হবে। একবার সিদ্ধান্ত নিন, exclusion লিখে রাখুন, এবং পরীক্ষিত ক্রম অনুসরণ করুন: Rocky Linux-এ Docker install walkthrough-তে প্রথমে কোন distribution package সরাতে হবে তা দেওয়া আছে।

রিপোজিটরির ক্ষেত্রে apt থেকে dnf-এ অনুবাদ

• /etc/apt/sources.list.d/*.sources হয় /etc/yum.repos.d/*.repo, যেখানে একটি ফাইলে একাধিক [sections] থাকতে পারে এবং প্রতিটির নিজস্ব id থাকে।
• add-apt-repository universe হয় dnf install epel-release, তবে পার্থক্য হলো universe এখনও Ubuntu-এর নিজস্ব archive-এর অংশ, আর EPEL একটি আলাদা project।
• apt update-এর কোনো সমতুল্য নেই যা আপনাকে মনে রাখতে হবে। dnf নিজের নির্ধারিত সময়সূচি অনুযায়ী metadata refresh করে, আর dnf makecache সেটি এখনই করায়।
• apt-cache policy <pkg> হয় dnf info <pkg>, এবং সব প্রস্তাবিত version দেখতে dnf list --showduplicates <pkg> ব্যবহার করুন।
• apt-mark hold হয় dnf versionlock add, যা python3-dnf-plugin-versionlock থেকে আসে।
• /etc/apt/preferences.d/-এ pinning repository section-এ priority= হয়, তবে সংখ্যাগুলো বিপরীত ক্রমে চলে।
• dpkg -S /path/to/file হয় rpm -qf /path/to/file।

Automatic update syntax হিসেবে নয়, একটি ধারণা হিসেবে স্থানান্তরিত হয়, কারণ এখানে কোনো unattended-upgrades নেই। timer, config file এবং reboot করা হবে কি না—এই বিষয়গুলো Rocky এবং Alma-তে dnf-automatic-এ ব্যাখ্যা করা হয়েছে।

রিপোজিটরির তালিকা সংক্ষিপ্ত রাখুন

CRB সক্রিয় করুন, epel-release ইনস্টল করুন, তারপর আপনি কী করেছেন এবং কেন করেছেন তা configuration management-এ অথবা সার্ভারের একটি সাধারণ ফাইলে লিখে রাখুন। সার্ভারটি যখন তিন বছর পুরোনো হবে এবং অন্য কেউ এটি পরিচালনা করবে, তখন এই নোটের মূল্য ধারণার চেয়ে বেশি হবে।

যোগ করার আগে অনুসন্ধান করুন। dnf search চালান, তারপর dnf info চালান, এবং কেবল এরপর নতুন কোনো repository বিবেচনা করুন। মানুষ EPEL সক্রিয় করার যে কারণগুলোর কথা বলে, তার উল্লেখযোগ্য অংশ ইতিমধ্যে AppStream-এ আছে। System monitoring এর সবচেয়ে স্পষ্ট উদাহরণ, কারণ Performance Co-Pilot base repositories-এ প্রকাশিত হয় এবং কোনো third-party repository প্রয়োজন হয় না। প্রতিটি অতিরিক্ত repository এমন আরেকটি পক্ষ, যারা মঙ্গলবার আপনাকে একটি package সরবরাহ করতে পারে। প্রতিটি অতিরিক্ত repository পরবর্তী major upgrade আরও কঠিন করে তোলে।

আপনি যদি এখনও দুটি distribution-এর মধ্যে বেছে নিচ্ছেন, এই সম্পূর্ণ বিন্যাস উভয় ক্ষেত্রেই একই এবং epel-release একইভাবে কাজ করে। প্রকৃত পার্থক্য অন্যত্র: Rocky Linux ও AlmaLinux-এর তুলনা rebuild philosophy ব্যাখ্যা করে, কারণ AlmaLinux এখন line-for-line rebuild-এর পরিবর্তে ABI (application binary interface) compatibility লক্ষ্য করে।

FAQ

Rocky Linux 9 বা AlmaLinux 9-এ EPEL কীভাবে সক্রিয় করব?

প্রথমে sudo dnf install -y dnf-plugins-core, তারপর sudo dnf config-manager --set-enabled crb, এবং এরপর sudo dnf install -y epel-release চালান। dnf repolist --enabled দিয়ে যাচাই করুন। এতে baseos, appstream, extras, crb এবং epel তালিকাভুক্ত হওয়ার কথা। EPEL package ইনস্টল করার আগে CRB সক্রিয় করুন, কারণ অনেক package এমন library-এর ওপর নির্ভর করে যা শুধু CRB-তে পাওয়া যায়। version 8-এ repository id হিসেবে powertools ব্যবহৃত হয়, crb নয়।

Production server-এ EPEL সক্রিয় করা কি নিরাপদ?

EPEL ব্যাপকভাবে ব্যবহৃত হয়। এর নীতিমালা অনুযায়ী EPEL package কখনও base distribution-এর কোনো package প্রতিস্থাপন করে না। তাই এটি সক্রিয় করলে BaseOS বা AppStream থেকে পাওয়া package পরিবর্তিত হয় না। তবে support-এর সীমাবদ্ধতা আছে। EPEL একটি স্বেচ্ছাসেবী Fedora project; এর কোনো service level agreement নেই। EPEL-এর package lifetime proposal অনুযায়ী একজন maintainer-কে কোনো package-এর জন্য মাত্র একটি RHEL minor release অথবা 13 মাস পর্যন্ত দায়বদ্ধ থাকতে হতে পারে। dnf repository-packages epel list installed দিয়ে package-এর inventory রাখুন। Customer-facing service যে কোনো EPEL package-এর ওপর নির্ভর করলে সেখানে dnf versionlock ব্যবহার করুন।

dnf কেন no such command: config-manager দেখায়?

কারণ config-manager একটি dnf plugin, built-in command নয়। Minimal বা container image-এ dnf-plugins-core সাধারণত থাকে না। Message-টিই সমাধান নির্দেশ করে: sudo dnf install -y 'dnf-command(config-manager)'। Parentheses-গুলো উদ্ধৃতির মধ্যে রাখুন, যাতে shell সেগুলোকে নিজের syntax হিসেবে না পড়ে। এখনও কিছু install করতে না পারলে grep -rl crb /etc/yum.repos.d/ চালান। এটি যে file-এর নাম দেখাবে, সেটি খুলে [crb] section-এ হাতে করে enabled=1 সেট করুন।

CRB এবং PowerTools-এর মধ্যে পার্থক্য কী?

দুটি একই repository-এর দুটি নাম। Version 8-এ এর নাম PowerTools এবং id powertools। Version 9 ও পরবর্তী version-এ এর নাম CRB এবং id crb। Red Hat-এর নিজস্ব product-এ এই content-এর নাম CodeReady Linux Builder। এখানে development header, static library এবং build-time tooling থাকে। Rocky এবং AlmaLinux 9-এ এটি default হিসেবে নিষ্ক্রিয় থাকে। AlmaLinux 10-এ 10.0 থেকে এটি default হিসেবে সক্রিয় থাকে। তাই সেখানে enable command চালানোর আগে dnf repolist --enabled পরীক্ষা করুন।

কোনো সমস্যা না করে EPEL কীভাবে আবার সরাব?

প্রথমে dnf repository-packages epel list installed দিয়ে inventory নিন। শুধু epel-release package সরালে EPEL থেকে install করা package সরবে না। ওই package-গুলো disk-এ থেকে যাবে, update পাওয়ার উৎস হারাবে এবং কোনো error না দেখিয়েই security fix পাওয়া বন্ধ করবে। প্রতিটি package আলাদাভাবে পর্যালোচনা করুন। যেগুলোর আর প্রয়োজন নেই, সেগুলো সরান বা বিকল্প package দিয়ে প্রতিস্থাপন করুন। এরপর sudo dnf remove epel-release চালান। EPEL-এর কোনো package যদি অন্য কোনো package প্রতিস্থাপন না করে থাকে এবং সেটি সরাতেই হয়, তাহলে sudo dnf repository-packages epel remove এক transaction-এ পুরো set সরিয়ে দেবে। Confirm করার আগে প্রস্তাবিত তালিকাটি সতর্কভাবে পড়ুন।