Директорії бінарних файлів Linux: Повний технічний довідник

Бінарні директорії Linux — це стандартизовані розташування у файловій системі, де зберігаються виконувані програми, інструменти системного адміністрування та спільні бібліотеки. Стандарт ієрархії файлової системи (FHS) визначає ці шляхи для забезпечення узгодженого розміщення програмного забезпечення в різних дистрибутивах, що дозволяє передбачувано вирішувати `PATH`, забезпечувати чисте керування пакетами та надійне відновлення системи — навіть коли несуттєві файлові системи недоступні.

Для будь-якого адміністратора, який керує середовищем VPS Хостингу або виділеним сервером, знання того, яке бінарне розташування де знаходиться — і чому — є обов’язковим. Це безпосередньо впливає на поведінку під час завантаження, розмежування привілеїв, стратегію розгортання програмного забезпечення та посилення безпеки.

Чому структура бінарних директорій має значення

Перш ніж заглиблюватися в окремі директорії, варто зрозуміти архітектурну логіку, що стоїть за їх розділенням. FHS ділить файлову систему на дві фундаментальні осі:

• Суттєві та несуттєві: Бінарні файли, необхідні для однокористувацького режиму та аварійного відновлення, повинні бути доступні до монтування `/usr`. Все інше може розміщуватися в `/usr`.
• Системний та користувацький рівень: Бінарні файли, призначені для адміністрування на рівні root, відокремлені від тих, що доступні непривілейованим користувачам, що дозволяє жорсткіше контролювати доступ через дозволи файлової системи.

Ця філософія проектування передує сучасним системам ініціалізації, але залишається вкрай актуальною. Неправильно налаштований `PATH`, бінарний файл, розміщений у неправильній директорії, або відсутнє символічне посилання на бібліотеку можуть непомітно порушити послідовності завантаження, завдання cron або сценарії запуску служб.

Основні бінарні директорії на перший погляд

/bin — Основні користувацькі бінарні файли

`/bin` містить мінімальний набір виконуваних файлів, необхідних для завантаження системи та виконання користувачем базових операцій в однокористувацькому або аварійному режимі. Ці бінарні файли повинні бути доступні навіть тоді, коли змонтована лише коренева файлова система.

Типові приклади: `ls`, `cp`, `mv`, `cat`, `bash`, `echo`, `grep`, `chmod`, `ln`, `mkdir`, `rm`, `ps`

Важлива технічна деталь: У дистрибутивах на основі systemd — включаючи Debian 10+, Ubuntu 20.04+, Fedora, Arch Linux та RHEL 8+ — `/bin` тепер є символічним посиланням, що вказує на `/usr/bin`. Це частина ініціативи UsrMerge, яка консолідує кореневі бінарні директорії в їхні аналоги `/usr` для спрощення проектування initramfs та забезпечення атомарних оновлень ОС. Ви можете перевірити це на будь-якій об’єднаній системі:

“`bash

ls -la /bin

lrwxrwxrwx 1 root root 7 /bin -> usr/bin

“`

Практичні наслідки: Якщо ви пишете сценарії оболонки, призначені для запуску в аварійних середовищах або хуках раннього завантаження (наприклад, сценарії initramfs), ніколи не припускайте, що `/usr/bin` доступний. Завжди використовуйте `/bin/sh` як shebang і посилайтеся лише на утиліти, визначені стандартом POSIX.

/sbin — Основні системні бінарні файли

`/sbin` містить бінарні файли, зарезервовані для завдань системного адміністрування, які повинні виконуватися під час завантаження та операцій відновлення файлової системи, до того як стане доступним повне дерево файлової системи.

Типові приклади: `fsck`, `ifconfig`, `ip`, `reboot`, `shutdown`, `mkfs`, `mount`, `umount`, `fdisk`, `modprobe`, `init`

Нюанс щодо привілеїв: Хоча бінарні файли `/sbin` *призначені* для використання root, вони є виконуваними для всіх на більшості дистрибутивів. Обмеження забезпечується самими операціями — `fsck` потребує прямого доступу до пристрою, `mount` потребує `CAP_SYS_ADMIN` — а не бітом виконання бінарного файлу. Це є поширеним джерелом плутанини під час аудитів безпеки.

Сучасний стан: Як і `/bin`, `/sbin` є символічним посиланням на `/usr/sbin` на системах з об’єднаним usr. Відмінність між `/sbin` та `/bin` тепер є переважно семантичною та історичною, а не структурною.

/usr/bin — Основний репозиторій користувацьких бінарних файлів

`/usr/bin` є найбільшою та найчастіше використовуваною бінарною директорією у типовій інсталяції Linux. Вона містить усі стандартні утиліти командного рядка та програми, орієнтовані на користувача, встановлені через системний менеджер пакетів, які не потрібні для аварійних операцій.

Типові приклади: `vim`, `nano`, `git`, `python3`, `perl`, `gcc`, `curl`, `wget`, `ssh`, `tar`, `gzip`, `awk`, `sed`, `find`

Масштаб на практиці: На мінімальній серверній інсталяції Debian `/usr/bin` може містити 200–400 бінарних файлів. Повна інсталяція настільного середовища може збільшити цю кількість понад 2 000. Ця директорія завжди присутня в стандартному `PATH` для всіх користувачів.

Власність менеджера пакетів: Кожен файл тут відстежується `dpkg`, `rpm` або еквівалентом вашого дистрибутива. Розміщення файлів у `/usr/bin` вручну настійно не рекомендується — оновлення пакетів можуть непомітно перезаписати їх без попередження.

/usr/sbin — Несуттєві бінарні файли системного адміністрування

`/usr/sbin` містить інструменти системного адміністрування, які не потрібні під час процесу завантаження або відновлення в однокористувацькому режимі, але є необхідними для повсякденного керування сервером.

Типові приклади: `apache2`, `nginx`, `sshd`, `useradd`, `userdel`, `usermod`, `groupadd`, `iptables`, `nftables`, `cron`, `logrotate`, `tcpdump`

Архітектурне розуміння: Розділення `/sbin` та `/usr/sbin` спочатку було розроблено так, щоб системний адміністратор міг завантажитися в однокористувацький режим і виконати відновлення без необхідності монтування `/usr`. На практиці, на сучасних системах з initramfs та раннім простором користувача, це розмежування значною мірою зникло. Однак розуміння цього залишається важливим при роботі зі старішими системами RHEL 6/CentOS 6 або вбудованими середовищами Linux, де `/usr` може справді бути окремим розділом.

/usr/local/bin — Встановлені адміністратором користувацькі бінарні файли

`/usr/local/bin` є правильним розташуванням для бінарних файлів, встановлених вручну — поза системним менеджером пакетів — і які повинні бути доступні всім користувачам системи.

Типові випадки використання:

• Програмне забезпечення, скомпільоване з вихідного коду (наприклад, власна збірка `nginx` з нестандартними модулями)
• Python-сценарії, встановлені через `pip install –prefix=/usr/local`
• Сторонні CLI-інструменти, розповсюджувані як автономні бінарні файли (наприклад, `kubectl`, `helm`, `terraform`, `hugo`)
• Власні сценарії автоматизації, які повинні бути загальносистемними

Пріоритет PATH: На стандартній FHS-сумісній системі `/usr/local/bin` з’являється *перед* `/usr/bin` у стандартному `PATH`. Це означає, що бінарний файл, розміщений тут, затінить бінарний файл з тим самим ім’ям, керований менеджером пакетів. Це навмисно — це дозволяє локальним налаштуванням перевизначати стандартні значення дистрибутива — але це також є частою причиною непомітних помилок при розбіжності версій.

“`bash

echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

Міркування безпеки: Оскільки `/usr/local/bin` не перевіряється менеджером пакетів, бінарні файли, розміщені тут, не отримують автоматичних оновлень безпеки. На серверах, що виконують виробничі навантаження — включаючи ті, що розміщені на Виділених Серверах — встановіть ручний графік оновлень або використовуйте інструмент керування конфігурацією (Ansible, Puppet, Chef) для відстеження та оновлення цих бінарних файлів.

/usr/local/sbin — Встановлені адміністратором системні бінарні файли

`/usr/local/sbin` відображає відношення між `/sbin` та `/bin`, але на локальному рівні. Це правильне розташування для вручну встановлених інструментів системного адміністрування, які потребують підвищених привілеїв або призначені лише для root.

Типові випадки використання:

• Власні сценарії резервного копіювання, що запускаються від імені root через cron
• Вручну скомпільовані агенти моніторингу (наприклад, власна збірка `node_exporter`)
• Адміністративні сценарії-обгортки, що викликають привілейовані системні виклики
• Утиліти керування від постачальника, що постачаються у вигляді архівів tarball, а не пакетів

Операційна дисципліна: Ведіть `README` або файл інвентаризації в `/usr/local/sbin`, де документується походження, версія та процедура оновлення кожного бінарного файлу. На спільній інфраструктурі недокументовані бінарні файли в цій директорії є відповідальністю з точки зору безпеки та аудиту.

/opt — Автономні сторонні програми

`/opt` призначений для програмних пакетів, що не відповідають структурі директорій FHS — як правило, комерційних або пропрієтарних програм, великих програмних пакетів від постачальників та програм, що постачаються зі своїми власними бібліотеками для уникнення конфліктів залежностей.

Типові приклади:

• `/opt/google/chrome/` — браузер Google Chrome
• `/opt/lampp/` — стек XAMPP
• `/opt/pycharm/` — IDE JetBrains PyCharm
• `/opt/gitlab/` — Omnibus-інсталяція GitLab
• `/opt/aws/` — AWS CLI v2 та SSM Agent

Структурна угода: Кожна програма в `/opt` повинна займати власну піддиректорію за шаблоном `/opt/<provider>/` або `/opt/<package>/`. Бінарні файли програми зазвичай розміщуються в `/opt/<package>/bin/`, і від постачальника очікується встановлення символічного посилання в `/usr/local/bin` або зміна `/etc/profile.d/` для додавання шляху.

Коли використовувати `/opt` проти `/usr/local`: Використовуйте `/opt`, коли програмне забезпечення постачається як автономний пакет зі своїми власними бібліотеками, конфігурацією та директоріями даних. Використовуйте `/usr/local/bin` для однофайлових інструментів або сценаріїв, що чисто інтегруються з наявним стеком системних бібліотек.

Реальний граничний випадок: GitLab Omnibus встановлюється повністю в `/opt/gitlab/` та керує власними екземплярами PostgreSQL, Redis та Nginx. Ця ізоляція є навмисною — вона запобігає конфліктам версій із системними службами. Однак це також означає, що системні інструменти моніторингу не виявлятимуть ці процеси автоматично, якщо їх явно не налаштувати на пошук у `/opt`.

/lib, /usr/lib, /lib64 та /usr/lib64 — Спільні бібліотеки

Ці директорії містять файли спільних об’єктів (файли `.so`), від яких залежать бінарні файли у відповідних бінарних директоріях під час виконання. Вони не є виконуваними у традиційному розумінні, але завантажуються в пам’ять процесу динамічним компонувальником (`ld-linux.so`).

Ключові директорії та їх ролі:

• `/lib` — Спільні бібліотеки, необхідні для бінарних файлів у `/bin` та `/sbin`. На системах з об’єднаним usr — символічне посилання на `/usr/lib`.
• `/usr/lib` — Основний репозиторій усіх системних спільних бібліотек. Тут розміщуються бібліотеки, керовані менеджером пакетів.
• `/lib64` — 64-розрядний варіант `/lib` на системах multilib (поширено на x86_64 RHEL/CentOS). Часто є символічним посиланням на `/usr/lib64`.
• `/usr/lib64` — 64-розрядні спільні бібліотеки на дистрибутивах на основі RPM.
• `/usr/local/lib` — Бібліотеки, встановлені разом із вручну скомпільованим програмним забезпеченням.
• `/usr/lib/x86_64-linux-gnu/` — Шлях до бібліотек multiarch для Debian/Ubuntu, що дозволяє 32-розрядним та 64-розрядним бібліотекам співіснувати.

Механіка динамічного компонувальника: Коли виконується бінарний файл, ядро передає керування динамічному компонувальнику, вказаному в заголовку ELF (зазвичай `/lib64/ld-linux-x86-64.so.2`). Компонувальник вирішує залежності спільних бібліотек за допомогою кешу, побудованого `ldconfig`, який читає `/etc/ld.so.conf` та його директорію включень. Якщо бібліотека встановлена, але `ldconfig` не було запущено, бінарний файл завершиться з помилкою «shared library not found», навіть якщо файл існує.

“`bash

After installing a library to /usr/local/lib, always run:

ldconfig

Verify library resolution for a specific binary:

ldd /usr/bin/curl

“`

Поширена помилка: Встановлення власноруч скомпільованої бібліотеки в `/usr/local/lib` без подальшого запуску `ldconfig` є однією з найпоширеніших причин помилок «cannot open shared object file» на серверах Linux. Це особливо поширено при збірці програмного забезпечення з вихідного коду на VPS з cPanel або подібних керованих середовищах, де процес збірки може не мати доступу root для запуску `ldconfig`.

UsrMerge: Сучасна консолідація файлової системи

Ініціатива UsrMerge (або `usr-merge`) заслуговує на окрему увагу, оскільки вона фундаментально змінює ментальну модель, яку багато адміністраторів несуть зі старіших систем.

Проблема, яку вона вирішує: Історично `/bin`, `/sbin`, `/lib` та `/lib64` існували як незалежні директорії в кореневій файловій системі, окремо від `/usr`. Це вимагало від initramfs містити мінімальний набір інструментів для монтування `/usr` перед повною ініціалізацією системи. Коли initramfs став універсальним, а `/usr` почав розглядатися як том лише для читання, потенційно змонтований по мережі або керований знімками, розділення стало перешкодою для атомарних оновлень та розгортань на основі образів.

Що змінилося: На об’єднаних системах кореневі директорії стають символічними посиланнями:

“`

/bin -> usr/bin

/sbin -> usr/sbin

/lib -> usr/lib

/lib64 -> usr/lib64

“`

Дистрибутиви, що завершили UsrMerge:

• Fedora (починаючи з Fedora 17, 2012)
• Arch Linux (починаючи з 2013)
• Debian (починаючи з Debian 12 Bookworm, 2023)
• Ubuntu (починаючи з Ubuntu 21.10)
• RHEL/CentOS (починаючи з RHEL 7)

Практичний вплив: Сценарії, що жорстко кодують `/bin/bash`, продовжують працювати, оскільки `/bin` є символічним посиланням на `/usr/bin`. Однак сценарії, що намагаються визначити, чи є шлях «суттєвим», перевіряючи, чи починається він з `/bin`, а не з `/usr/bin`, даватимуть неправильні результати. Оновіть будь-яку таку логіку у своїх інструментах автоматизації.

Дозволи бінарних директорій та посилення безпеки

Розуміння бінарних директорій невіддільне від розуміння їх наслідків для безпеки. Кілька заходів посилення безпеки безпосередньо стосуються цих шляхів.

Рекомендовані базові значення дозволів:

Бінарні файли SUID/SGID: Деякі бінарні файли в `/usr/bin` та `/usr/sbin` мають біт SUID, що дозволяє їм виконуватися з підвищеними привілеями незалежно від того, хто їх викликає. Приклади включають `passwd`, `sudo`, `su` та `ping`. Регулярно перевіряйте їх:

“`bash

find /usr/bin /usr/sbin /bin /sbin -perm /4000 -o -perm /2000 2>/dev/null

“`

Незмінні прапорці: На системах з підвищеними вимогами до безпеки розгляньте можливість застосування `chattr +i` до критичних бінарних файлів або монтування `/usr` лише для читання. Це запобігає модифікації під час виконання шкідливим програмним забезпеченням або скомпрометованим процесом, хоча для законних оновлень пакетів потрібне повторне монтування з правами запису.

Параметр монтування `noexec`: Монтування `/tmp` та `/var/tmp` з `noexec` запобігає прямому виконанню бінарних файлів, розміщених там — це поширена техніка в атаках з веб-оболонками. Це не впливає на самі бінарні директорії, але є додатковим заходом посилення безпеки, актуальним для будь-якого сервера, що запускає веб-програми, включаючи ті, що використовують середовища Спільного Веб-Хостингу.

Змінна середовища PATH та порядок вирішення бінарних файлів

Змінна `PATH` визначає порядок, у якому оболонка шукає виконувані файли в директоріях. Розуміння цього порядку є важливим для налагодження помилок «command not found» та для навмисного затінення бінарних файлів.

Типовий PATH для root у системі Debian/Ubuntu:

“`

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

Типовий PATH для непривілейованого користувача:

“`

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

“`

Ключові спостереження:

• `/usr/local/bin` передує `/usr/bin`, тому локально встановлені бінарні файли затінюють ті, що керуються менеджером пакетів.
• `/sbin` та `/usr/sbin` відсутні в стандартному PATH непривілейованого користувача на деяких дистрибутивах, тому запуск `ifconfig` від імені не-root користувача може завершитися помилкою «command not found», навіть якщо бінарний файл існує.
• Коли служба запускається під обліковим записом не-root користувача (наприклад, користувач веб-програми), її PATH може бути ще більш обмеженим. Завжди використовуйте абсолютні шляхи у файлах службових модулів та завданнях cron.

Налагодження проблем PATH:

“`bash

Find all instances of a binary across PATH directories:

which -a python3

Show full PATH resolution including aliases and functions:

type -a python3

Check the effective PATH for a specific service:

systemctl show myservice | grep -i environment

“`

Практична матриця рішень: куди встановити бінарний файл

При розгортанні програмного забезпечення на сервері Linux — будь то скомпільований інструмент, завантажений бінарний файл або власний сценарій — використовуйте цю систему прийняття рішень:

Чи керується воно системним менеджером пакетів?

• Так: Менеджер пакетів автоматично розміщує його в `/usr/bin` або `/usr/sbin`. Не переміщуйте його.

Чи є це одним бінарним файлом або сценарієм, встановленим вручну, призначеним для всіх користувачів?

• Інструмент для користувача: `/usr/local/bin`
• Інструмент для root/адміністратора: `/usr/local/sbin`

Чи є це автономним пакетом програми з власними залежностями?

• Використовуйте `/opt/<vendor>/<package>/` та створіть символічне посилання на основний бінарний файл у `/usr/local/bin`

Чи є це тимчасовим або специфічним для користувача інструментом?

• Розмістіть його в `~/bin` (створіть, якщо відсутній) та додайте `~/bin` до вашого особистого `PATH` в `~/.bashrc` або `~/.profile`

Чи є це спільною бібліотекою для вручну скомпільованої програми?

• Встановіть у `/usr/local/lib`, потім запустіть `ldconfig`

Ця система запобігає найпоширенішій формі ентропії файлової системи на серверах, що тривалий час працюють: бінарні файли, розкидані по довільних місцях, невидимі для менеджера пакетів та забуті адміністратором, який їх встановив.

Контрольний список ключових технічних висновків

• Перевірте статус UsrMerge у вашій системі за допомогою `ls -la /bin /sbin /lib`. Якщо вони є символічними посиланнями, `/bin` та `/usr/bin` є ідентичними просторами імен.
• Ніколи не розміщуйте файли безпосередньо в `/usr/bin` або `/usr/sbin` — оновлення пакетів перезапишуть їх непомітно.
• Завжди запускайте `ldconfig` після встановлення спільних бібліотек у `/usr/local/lib` або будь-який нестандартний шлях.
• Використовуйте абсолютні шляхи в завданнях cron, файлах модулів systemd та сценаріях ініціалізації — ніколи не покладайтеся на правильне встановлення `PATH` у неінтерактивних контекстах.
• Щоквартально перевіряйте бінарні файли SUID/SGID на виробничих серверах: `find /usr /bin /sbin -perm /6000 -type f`
• Документуйте кожен бінарний файл, встановлений у `/usr/local/` та `/opt/`, із зазначенням версії, URL-адреси джерела та дати встановлення в системі керування конфігурацією або принаймні в локальному журналі змін.
• На системах з об’єднаним usr оновіть будь-яку автоматизацію, що розрізняє «суттєві» бінарні файли за префіксом шляху — це розмежування тепер є суто семантичним.
• При розгортанні програм на Панелях керування VPS або керованих хостинг-середовищах переконайтеся, чи панель керування змінює `PATH` або встановлює власні версії бінарних файлів у `/opt` або `/usr/local`, оскільки це може спричинити конфлікти версій із системними інструментами.
• Для інструментів, пов’язаних з SSL (`openssl`, `certbot`), переконайтеся, яка версія бінарного файлу викликається — застаріла вручну встановлена версія в `/usr/local/bin` затінить версію, керовану менеджером пакетів, і може містити невиправлені вразливості. Поєднайте це з належним керуванням SSL-сертифікатами, щоб забезпечити актуальність вашого криптографічного ланцюжка інструментів від початку до кінця.

Часті запитання

У чому різниця між `/bin` та `/usr/bin` у сучасному Linux?

У сучасних дистрибутивах, що завершили UsrMerge, функціональної різниці немає — `/bin` є символічним посиланням на `/usr/bin`. Історично `/bin` містив лише бінарні файли, необхідні до монтування `/usr`, тоді як `/usr/bin` містив усе інше. Це розмежування тепер є семантичним на об’єднаних системах, але залишається архітектурно значущим на старіших або вбудованих інсталяціях Linux.

Чому розміщення бінарного файлу в `/usr/local/bin` перевизначає той самий бінарний файл у `/usr/bin`?

Тому що `/usr/local/bin` з’являється раніше в стандартному `PATH`, ніж `/usr/bin`. Оболонка вирішує команди, шукаючи директорії `PATH` зліва направо та виконуючи перший знайдений збіг. Цей порядок є навмисним — він дозволяє адміністраторам розгортати локальні перевизначення без зміни файлів, керованих менеджером пакетів.

Що станеться, якщо я забуду запустити `ldconfig` після встановлення спільної бібліотеки?

Кеш динамічного компонувальника (`/etc/ld.so.cache`) не міститиме нову бібліотеку, і будь-який бінарний файл, що залежить від неї, завершиться під час виконання з помилкою на кшталт `error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory`. Запуск `sudo ldconfig` відновлює кеш і негайно вирішує проблему.

Чи безпечно встановлювати програмне забезпечення безпосередньо в `/usr/bin` замість `/usr/local/bin`?

Ні. Файли в `/usr/bin` належать менеджеру пакетів та відстежуються ним. Майбутнє оновлення пакету або системне оновлення може перезаписати, перемістити або видалити будь-який файл у цій директорії без попередження. Завжди використовуйте `/usr/local/bin` для вручну встановлених бінарних файлів, щоб підтримувати чітке розмежування між програмним забезпеченням, керованим менеджером пакетів, та програмним забезпеченням, керованим адміністратором.

Як знайти, з якої директорії виконується команда?

Використовуйте `which <command>` для швидкого пошуку першого збігу в `PATH`, або `type -a <command>` для виведення всіх збігів, включаючи вбудовані команди оболонки, псевдоніми та кожен екземпляр у всіх директоріях `PATH`. Для остаточної відповіді, включаючи вирішення символічних посилань, використовуйте `readlink -f $(which <command>)`.