Чи варто використовувати версію пакету CentOS у (офіційних) сховищах чи останніх стабільних версіях пакетів?

Це відкрите запитання, але я хочу бачити конструктивну та корисну дискусію в цій темі.

Отже, щоб уточнити питання: На сервері, на якому працює CentOS 7 (або будь-який інший дистрибутив / версія Linux для цього питання), найкраще дотримуватися версії пакета в репортажі Base / EPEL або добре, щоб отримати останню стабільну версію формувати сайт пакету? У цьому випадку я конкретніше маю на увазі такі пакети, як nginx, MariaDB та PHP 7. Наприклад, які б були плюси та мінуси встановлення nginx 1.8.0 над версією EPEL 1.6.3? Чи існують якісь різниці в ефективності чи ризики для безпеки?

Вся дискусія та досвід вітаються, будь ласка, спробуйте навести ресурси та факти.

Взагалі, я дуже намагаюся використовувати системні пакети за замовчуванням.

Однак це колись неможливо. Щоб зробити освічений вибір, вам довелося відповісти на ці запитання:

1. чи надають пакунки дистрибутива потрібні функції? Якщо це так, вам навіть не потрібно шукати інші пакети; просто використовуйте пакети, надані системними сховищами.
2. чи потрібна вам офіційна підтримка та / або чи дотримувалися ви конкретної політики? Якщо так, ви не можете використовувати неофіційне сховище . У цьому випадку ви, ймовірно, використовуєте неправильний дистрибутив для свого програмного проекту.
3. якщо відповідь на попередні запитання була "ні", вам довелося шукати більш нову версію програмного забезпечення. Чи існує добре розпізнане сховище з необхідним пакетом? Якщо так, то використовуйте його.
4. якщо немає конкретних, надійних сховищ, вам довелося використовувати програмне забезпечення вище. У цьому випадку намагайтеся використовувати пакетне програмне забезпечення (наприклад: RPM, DEB, ecc), а не звичайний tar.gz (або подібне).

Відповіді Метью Іфе та Шоданшока висвітлюють проблеми в цілому, але я хочу вирішити вашу конкретну проблему, поставивши питання в контекст, оскільки саме цими системами я керую.

Моя поточна версія для розгортання веб-додатків PHP / MySQL:

• CentOS 7.x
• nginx 1.8.x, наданий nginx
• PHP 7 або PHP 5.6 (залежно від програми), надані ремі
• MariaDB 10.0.x надається MariaDB

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

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

Однак я зіткнувся з тим, що версія nginx, що входить до CentOS, була занадто старою і не мала деяких необхідних функцій та виправлень помилок. Тому я пішов шукати альтернативні пакети і виявив, що nginx.org поширює свої власні. Я перейшов до них майже одразу і виявив їх ідеально стійкими протягом тривалого перевезення.

Потім є PHP. Я знаю з історії, що версія PHP, що постачається разом з CentOS, буде єдиною версією, яку вона коли-небудь отримує, і отримає лише оновлення безпеки; немає нових функцій або виправлень помилок. Таким чином, як тільки вона не буде підтримуватись вгору, я з часом не зможу запускати сучасні веб-програми PHP, якщо я буду використовувати ці пакети. Таким чином, необхідно також замінити їх.

З багаторічного досвіду я дізнався, що найкраще відслідковувати виправлення помилок за допомогою PHP, а не просто заморожувати в один момент випуску та приймати лише виправлення безпеки, оскільки запущені веб-додатки також будуть оновлені та потребуватимуть цих виправлень. Отже, оцінивши безліч різних наборів пакетів PHP, я зупинився на пакунках remi. Ремі є співробітником Red Hat і також відповідає за пакети PHP в RHEL / CentOS. Тож я знаю, що його пакети будуть якісними, і вони були. Вони є замінниками, що випадають для системних пакетів, і працюють ідеально.

Нарешті ми дістаємось до MariaDB. Ви можете зберігати системні пакети тут і не зазнавати негативних наслідків. Я вирішив перейти на пакети 10.0 MariaDB (і незабаром піде на 10.1), щоб скористатися TokuDB та деякими іншими поліпшеннями продуктивності, які не доступні у версії 5.5, що постачається разом з CentOS, і що він ніколи не отримає великих оновлень для.

В цілому вам потрібна стабільність у вашій базовій системі, але веб-додатки змінюються набагато швидше, ніж, скажімо, програмне забезпечення для бізнесу, і ваш сервер повинен буде йти в ногу. Таким чином, я вибрав цільові моменти, де оновлення пакетів отримає явні переваги з невеликими додатковими адміністративними витратами (він же працює).

Коротка відповідь - завжди використовуйте те, що надається в системних сховищах. Будьте дуже обережні, які сховища ви також встановлюєте. Деякі з них просто погані.

Не слід перезаписувати системні пакети з новішими версіями, Redhat розроблений і оркестрований дуже ретельно, і у вас можуть виникнути дивні помилки або проблеми.

Серед деяких речей, які слід врахувати та розглянути, які можуть спричинити проблеми.

1. Деякі сховища просто погано підтримуються. Вони не оновлюються виправленнями безпеки для пакетів.
2. Люди схильні писати погані RPM, вони не позначають конфігураційні файли як конфігураційні файли, що перезаписує вашу конфігурацію щоразу, коли ви оновлюєтесь, що може спричинити проблеми. Я бачив цю проблему раніше.
3. Вони недостатньо декларують свої залежності належним чином. Я також бачив це і раніше, коли phpпакет був розміщений у системі, але не оновив pearпакет, який ввів проблеми.
4. Встановлення декількох сховищ, які пропонують однакові назви пакетів, може призвести до непередбачених проблем залежності у вашій системі.
5. Деякі пакети перезаписують або переписують файли системної конфігурації, від яких залежать або очікують існування інших пакетів. Це призводить до проблем з іншими пакетами, яких ви можете не очікувати.

Ніколи не створюйте пакунки з джерела та не встановлюйте їх у верхній частині пакетів, які там є. Це порушує цілісність системного пакету, що може призвести до дивних проблем ABI, таких як отримання unresolved symbolабо undefined referenceповідомлення. Це досить важливо, що система підтримує надійний та точний показник того, яке програмне забезпечення було розгорнуто в даній системі, щоб забезпечити, що воно все працює один з одним належним чином, саме тому ми використовуємо RPM в першу чергу.

Життєздатним (і Redhat блаженним) способом вирішити це є використання колекцій програмного забезпечення.

www.softwarecollections.org

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

Веб-сайт дає вказівки, як встановити та активувати ці пакунки, він містить більшість того, що люди пропускають у старих версіях CentOS та Redhat (зокрема, EL6). Деякі речі, які я успішно використовував на цьому веб-сайті.

• MySQL 5.6 та MySQL 5.7, MariaDB.
• PHP 5,5 і PHP 5,6
• Apache 2.4

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

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