Paketlarni boshqarish asoslari: dastur tizimga qanday o'rnatiladi

nginx ni bitta buyruq bilan o'rnatish juda oddiydek tuyuladi, lekin bu soddalik ortida haqiqatan ishonchli mexanizm ishlaydi: bog'liqliklarni hal qilish, kriptografik tekshiruv va dastur diskka joylashtirgan har bir fayl haqidagi to'liq qayd. Oldingi modul /proc fayl tizimi maqolasi bilan yakunlangan edi: unda ishlab turgan jarayon o'z holatini ochiq, tekshirish mumkin bo'lgan interfeys orqali ko'rsatishi ko'rildi. Bu modul undan pastroqdagi qatlamga o'tadi: dastur tizimga birinchi navbatda qanday tushadi, o'rnatilgan paytda qanday hisobga olinadi va keraksiz bo'lganda qanday toza olib tashlanadi. Bu mexanizm paketlarni boshqarish (package management) deb ataladi.

Bu maqola modulning qolgan qismi tayanadigan atamalar va tushunchalarni belgilaydi: paket aslida nima, nega deyarli barcha production ishlarida u manba koddan kompilyatsiya qilishdan ustun turadi, bog'liqlik nima va u nega mavjud, repozitoriy bu tizimda qayerda turadi va nega deyarli har bir distributiv bu ishni ikki alohida vositalar qatlamiga ajratadi.

Paket aslida nima

Paket — dasturni o'rnatish, ishga tushirish va keyinchalik olib tashlash uchun kerak bo'lgan hamma narsani o'z ichiga olgan bitta fayl: kompilyatsiya qilingan binary fayllar, namunaviy konfiguratsiya fayllari, shu dasturga xos ichki kutubxonalar, hujjatlar va eng muhimi — metama’lumotlar (metadata): paket nomi, versiyasi, maintainer’i, tavsifi va aynan qaysi boshqa paketlarga bog'liqligi haqidagi tuzilgan qayd. Debian oilasi .deb fayllaridan, RHEL oilasi esa .rpm dan foydalanadi.

Paketni .tar.gz kabi oddiy arxivdan aynan shu metama’lumotlar va ularni tushunadigan vosita ajratib turadi. Oddiy arxivni ochsangiz, tizim nima bo'lganidan bexabar qoladi: qaysi fayl qayerga tushgani, ular qaysi paketga tegishliligi va keyinroq ularni qanday xavfsiz olib tashlash haqida hech qanday qayd yo'q. Paket menejeri esa aksincha, qaysi o'rnatilgan fayl qaysi paketga tegishli ekanini doim aniq biladi. Shu sababli keyinchalik "bu faylni diskka qaysi paket joylashtirgan" degan savolga aniq va darhol javob bor:

dpkg -S /usr/sbin/nginx

nginx-core: /usr/sbin/nginx

dpkg -L <package> (RHEL oilasida rpm -ql <package>) teskari savolga javob beradi — muayyan paket o'rnatgan har bir fayl. Ikkala buyruq ham dpkg va bog'liqliklar maqolasida batafsil ko'rib chiqiladi.

Manba koddan yig'ish va paket o'rnatish

Har qanday open-source dasturni nazariy jihatdan o'z manba kodidan kompilyatsiya qilish mumkin: kodni yuklab olasiz, kerakli kompilyator va kutubxonalarni o'zingiz topib o'rnatasiz, configure va make ni ishga tushirasiz va natijani tizimga qo'lda joylashtirasiz. Bu yondashuvning hali ham o'z o'rni bor: distributiv repozitoriysida sizga aynan kerak bo'lgan juda yangi versiya bo'lmasligi yoki dasturni nostandart build flag'lari bilan kompilyatsiya qilish kerak bo'lishi mumkin.

Lekin production serverda manba koddan yig'ishning uchta haqiqiy narxi bor:

• bog'liqliklarni qo'lda kuzatish — dastur o'nlab kutubxonalarga bog'liq bo'lishi mumkin va ularning har birining to'g'ri versiyasini topib o'rnatish tizimning emas, sizning zimmangizga tushadi;
• yangilanish yoki xavfsizlik haqida xabar yo'q — distributiv shu yo'l bilan o'rnatilgan dasturni ko'rmaydi, shuning uchun uning uchun xavfsizlik tuzatishi chiqqanda sizni ogohlantira olmaydi;
• toza olib tashlash deyarli imkonsiz — qaysi fayl qayerga tushgani haqida qayd bo'lmagani uchun manba koddan yig'ilgan dasturni ortida ortiqcha fayl qoldirmasdan to'liq o'chirish amalda qiyin.

Paket menejeri uchalasini ham hal qiladi: u bog'liqliklarni avtomatik hal qiladi, o'rnatilgan versiyalarni qayd qilib boradi va qaysi fayl qaysi paketga tegishli ekanini aniq biladi, shuning uchun olib tashlash to'liq va oldindan aytib bo'ladigan bo'ladi. Shu sababli production serverda paket menejeri orqali o'rnatish deyarli har doim sukut bo'yicha tanlov, manba koddan yig'ish esa muayyan, asosli ehtiyoj uchun qoldirilgan istisno.

Bog'liqliklar: nega paket kamdan-kam yolg'iz turadi

Dasturlar kamdan-kam hollarda to'liq mustaqil bo'ladi. Masalan, nginx umuman ishlashi uchun tizimda libssl va libpcre kabi kutubxonalar oldindan mavjud bo'lishi kerak. Boshqa paket ishlashi uchun zarur bo'lgan paket bog'liqlik (dependency) deb ataladi.

Bog'liqliklarni qo'lda hal qilish — kerakli kutubxonani topish, uni o'rnatish, keyin uning o'z bog'liqliklarini aniqlash va jarayonni takrorlash — tezda boshqarib bo'lmaydigan, ba’zan o'nlab darajali zanjirga aylanadi. Bu holatning norasmiy, keng tanilgan nomi bor: dependency hell.

Yuqori darajali paket menejerining (apt, dnf) asosiy vazifasi aynan shu: siz bitta paketni nomlaysiz, u esa repozitoriydan bog'liqliklarning butun zanjirini avtomatik topib, ularni mos versiyalarda birga o'rnatadi. Bu mexanizm amalda apt va repozitoriylar maqolasida ko'rsatiladi.

Paket qayerdan keladi: repozitoriylar va metama’lumotlar

Repozitoriy — paketlar va ularning metama’lumotlaridan iborat katta to'plam saqlanadigan markaziy joy, odatda internetdagi server. Tizimingiz repozitoriy manzilini biladi va undan ikki xil narsani so'raydi:

1. metama’lumotlar indeksi — qaysi paketlar mavjud, qaysi versiyalar bor va ularning har biri nimaga bog'liq;
2. paket faylining o'zi — faqat aynan shu paketni o'rnatishga qaror qilganingizda yuklab olinadi.

Aynan shu ikki bosqichli model tufayli apt search nginx kabi buyruq o'sha paytda internetdan hech narsa yuklamasdan, butunlay lokal keshlangan metama’lumotlar indeksi ustida ishlaydi. Indeksning o'zi vaqti-vaqti bilan yangilanadi — bu qadam, shuningdek repozitoriy qo'shish va bir nechta manbani boshqarish keyingi maqolada ko'rib chiqiladi.

Ikki qatlamli model: past darajali va yuqori darajali vositalar

Deyarli har bir zamonaviy Linux distributivi paketlarni boshqarishni ikki qatlamga ajratadi:

Past darajali vosita ishonchli, lekin ataylab "ko'r": unga bitta muayyan paket faylini bersangiz, u shu faylni o'rnatadi; agar tizimda kerakli bog'liqlik yetishmasa, u shunchaki xato haqida xabar beradi va to'xtaydi — uni topish uchun hech qachon o'zi repozitoriyga murojaat qilmaydi. Yuqori darajali vosita esa to'g'ridan-to'g'ri past darajali vosita ustiga qurilgan qatlam: u repozitoriylar bilan ishlaydi, bog'liqliklarning to'liq zanjirini hal qiladi va oxirida haqiqiy o'rnatishni bajarish uchun baribir past darajali vositani chaqiradi.

flowchart LR
    R[Repository] --> H["High-level: apt / dnf\n(search, resolve dependencies)"]
    H --> L["Low-level: dpkg / rpm\n(install/remove the file)"]
    L --> S["System: files, services"]

Bu qatlamlanishning to'g'ridan-to'g'ri amaliy oqibati bor: apt install <package> ishlaganda u ostida dpkg ni chaqiradi, shuning uchun biror narsa buzilganda ba’zan faqat apt darajasida emas, to'g'ridan-to'g'ri dpkg darajasida tekshirish kerak bo'ladi. Qachon qaysi vositadan foydalanish keyingi ikki maqolada — apt va repozitoriylar va dpkg va bog'liqliklar da ko'rib chiqiladi.

Bu modul qaysi muhitni nazarda tutadi

Paketlarni boshqarish tabiatan distributivga bog'liq — hamma joyda bir xil ishlaydigan yagona buyruq yo'q. Bu modulning asosiy amaliy misollari Ubuntu Server LTS va uning apt/dpkg juftligidan foydalanadi, chunki bu birikma production’dagi eng keng tarqalgan muhitlardan biri. Agar RHEL, Rocky Linux, AlmaLinux yoki Fedora kabi RPM asosidagi distributiv bilan ishlasangiz, asosiy tushunchalar o'zgarmaydi — faqat buyruq nomlari va ayrim fayllar joylashuvi farq qiladi; bular RPM, YUM va DNF maqolasida to'liq ko'rib chiqiladi. Agar sizni distributivdan mustaqil, konteynerlangan paket formati bo'lgan Snap qiziqtirsa, u alohida Snap paketlari maqolasida ko'rib chiqiladi.

Amaliy vaziyat: yangi serverda nima allaqachon borligini tekshirish

Muammo. Siz hozirgina yangi Ubuntu Server LTS mashinasiga ulandingiz va hali hech narsani o'rnatmasdan, o'chirmasdan yoki o'zgartirmasdan nginx allaqachon o'rnatilganmi-yo'qmi, shuni aniqlashingiz kerak.

1-qadam. Distributiv va versiyani aniqlang.

cat /etc/os-release

PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
ID=ubuntu
ID_LIKE=debian

ID_LIKE=debian bu tizim Debian oilasiga tegishli ekanini, ya’ni to'g'ri vositalar apt/dpkg ekanini tasdiqlaydi. RHEL oilasidagi tizimda bu qator o'rniga ID_LIKE="rhel fedora" ga o'xshash bo'ladi.

2-qadam. nginx allaqachon o'rnatilganmi-yo'qmi, tekshiring.

dpkg -l nginx

Agar o'rnatilgan bo'lsa, chiqish shunday ko'rinadi:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version              Architecture Description
+++-==============-====================-============-===============
ii  nginx          1.24.0-2ubuntu7      amd64        small, powerful, scalable web/proxy server

Eng chap ustundagi ii "o'rnatilgan" degani (birinchi i — istalgan holat, ikkinchisi paket to'liq o'rnatilganini tasdiqlaydi). Agar paket umuman o'rnatilmagan bo'lsa, dpkg -l buning o'rniga "no packages found matching nginx" deb xabar beradi.

3-qadam. Agar o'rnatilmagan bo'lsa, u hech bo'lmaganda repozitoriyda mavjudligini tasdiqlang (hali o'rnatmasdan).

apt list nginx 2>/dev/null

nginx/noble 1.24.0-2ubuntu7 amd64

Bu buyruq faqat lokal metama’lumotlar indeksini o'qiydi — hech narsa yuklamaydi va tizimga hech qanday o'zgarish kiritmaydi.

Xulosa. Faqat o'qiydigan uchta buyruq — /etc/os-release, dpkg -l, apt list — tizimga tegmasdan uchta alohida savolga javob beradi: qaysi distributivdasiz, dastur allaqachon o'rnatilganmi va agar o'rnatilmagan bo'lsa, u mavjudmi. Har qanday o'rnatish yoki yangilashdan oldin aynan shu ketma-ketlikni bajarish notanish serverda ishlash uchun oqilona minimal odat.

Keng tarqalgan xatolar

Paketni oddiy arxiv bilan adashtirish

.deb yoki .rpm faylni oddiy .tar.gz kabi qo'lda ochib, uning ichidagilarni qo'lda nusxalash paket menejerining bog'liqliklar va fayllar qaydini butunlay chetlab o'tadi. Shundan keyin tizim bu dastur haqida hech narsa bilmaydi va kelajakda uni toza olib tashlash yoki yangilash imkonsiz bo'ladi.

Har bir muammoga internetdan topilgan qo'lda tuzatishni qo'llash

Faylni /usr/lib ga qo'lda nusxalash yoki forumdagi postda topilgan --force turidagi flag bilan o'rnatishni majburlash odatda paket menejerining ichki holatini buzadi. Agar asl muammo bog'liqlik bilan bog'liq bo'lsa, avval haqiqiy sababni aniqlang — aniqlash usuli dpkg va bog'liqliklar maqolasida ko'rib chiqiladi.

RHEL tizimida Debian buyrug'ini ishlatish (yoki aksincha)

RHEL asosidagi tizimda apt install mavjud emas, Ubuntu’da esa dnf install mavjud emas — bular butunlay alohida ekotizimlarning vositalari. Qaysi buyruqlar oilasi mos kelishini taxmin qilishdan oldin cat /etc/os-release ni tekshirish odatga aylanishi kerak.

Imzosini tekshirmasdan repozitoriy qo'shish

Uchinchi tomon repozitoriysini GPG tekshiruvisiz (gpgcheck/ishonchli kalit) qo'shish tizimni supply-chain hujumiga ochiq qoldiradi. Bu xavf va undan qanday saqlanish apt va repozitoriylar maqolasida chuqur ko'rib chiqiladi.

Mashqlar

1. O'z tizimingizda cat /etc/os-release ni ishga tushiring va ID hamda ID_LIKE maydonlari yordamida u qaysi paket ekotizimiga (Debian yoki RHEL oilasi) tegishli ekanini aniqlang.
2. Tizimingizda hozir nechta paket o'rnatilganini dpkg -l | wc -l (RHEL oilasida rpm -qa | wc -l) bilan sanang. Nega bu son yuzlab yoki minglab bo'lishi ehtimolini tushuntiring, garchi o'zingiz ataylab buncha dastur o'rnatmagan bo'lsangiz ham.
3. dpkg -l | grep ^ii | head -20 (yoki rpm -qa | head -20) dan ikkita paketni tanlang va apt show <package> yoki paket tavsifi yordamida ularning har biri aslida nima uchun kerakligini aniqlang.

Mashqni bajardim deyish uchun: har bir mashq uchun hech narsa o'rnatmasdan yoki o'chirmasdan tizimingiz qaysi paket ekotizimidan foydalanishini, taxminan nechta paket o'rnatilganini va kamida ikkitasi nima uchun kerakligini o'z so'zlaringiz bilan ayta olishingiz kerak.

Xulosa

Paket — dasturni, uning metama’lumotlarini va bog'liqliklar ro'yxatini birlashtirgan boshqariladigan birlik; paket menejeri uni o'rnatishni manba koddan qo'lda yig'ishga qaraganda ancha ishonchli, kuzatiladigan va toza olib tashlanadigan qiladi. Deyarli har bir distributiv buni ikki qatlamda quradi: past darajali vosita (dpkg, rpm) bitta faylni o'rnatadi, yuqori darajali vosita (apt, dnf) esa repozitoriylar bilan ishlaydi va bog'liqliklarni avtomatik hal qiladi.

Bu modulning qolgan qismi uchun poydevor. Keyingi maqola — apt va repozitoriylar yuqori darajali qatlamni amalda ko'rsatadi: apt buyruqlari, repozitoriy konfiguratsiyasi va metama’lumotlarni yangilash. Undan keyin dpkg va bog'liqliklar past darajali qatlamga tushadi va bog'liqlik muammolarini to'g'ridan-to'g'ri aniqlashni ko'rib chiqadi.

Manbalar

• Debian Wiki: Package Management: https://wiki.debian.org/PackageManagement
• Debian Policy Manual: https://www.debian.org/doc/debian-policy/
• Linux man-pages: dpkg(1): https://man7.org/linux/man-pages/man1/dpkg.1.html
• Ubuntu Server hujjatlari: paketlarni boshqarish: https://ubuntu.com/server/docs/package-management
• Linux man-pages: os-release(5): https://man7.org/linux/man-pages/man5/os-release.5.html
• Fedora Docs: DNF hujjatlari: https://dnf.readthedocs.io/en/latest/