Якщо я хочу запустити додаток в Linux без використання менеджера пакунків, чи є єдиним моїм варіантом компіляція з джерела?

У мене є два побічні проекти, які я хотів би виконати на роботі:

1. Увімкніть користувачів wiki для автентифікації на корпоративному сервері Active Directory (LDAP).
2. Налаштуйте інструмент перегляду коду для моєї команди розробників.

Ось проблема. Сервер Linux, на якому знаходяться інструменти, має версію PHP, у якій немає компільованого LDAP, а сервер Apache чомусь відсутній mod_proxy_html.

Якби я працював у Windows, я завантажував би відповідні модулі, кидав їх у каталог ext або module, відбивав сервер, а потім продовжував займатися своїм бізнесом. Однак у Linux, здається, єдиний мій варіант - перекомпілювати PHP (для бібліотек LDAP) або самостійно скласти модуль mod_proxy_html та всі його залежності.

Тепер я знаю, про що ви, мабуть, думаєте: "Чому ви просто не використовуєте менеджер пакунків для встановлення модулів?" Це справедливе питання.

1. Сервер може отримати доступ до загальнодоступного Інтернету лише через проксі-сервер зі списком білих списків
   . (Адже це інтранет-сервер.)
2. Apache та PHP, що працюють на сервері, є з пакету LAMP. Вони не контролюються YUM, RPM або будь-яким іншим 3-літерним абревіатурою.

Мені вдалося скласти PHP з нуля, але не обійшлося без гарного шматка як-гоління . Мені довелося завантажувати і компілювати 4 або 5 залежностей, перш ніж я зміг скласти PHP з бібліотеками LDAP, і навіть тоді, в make testосновному, сказав: "Ей, приятелю. Я знаю, що ти пережив чимало клопотів, щоб скласти це, але це виглядає як-небудь привабливо Удачі, хоча! "

Отже, моє запитання: чому це потрібно? Чому я не можу просто завантажити попередньо складену (статично скомпільовану?) Версію потрібних мені бібліотек / модулів, поставити їх на місце, Apache і PHP можуть побачити їх, перезапустити сервер Apache і продовжувати свій веселий шлях.

Причина, по якій ви не вважаєте, що модель Windows для розповсюдження програмного забезпечення майже не є такою поширеною, - це бінарна сумісність та версія бібліотеки. Ви можете спроектувати процес збирання, який збирає програмне забезпечення на будь-якій кількості платформ (шляхом автоматичного виявлення необхідних інструментів збирання) набагато простіше, ніж ви можете підтримувати X кількість похідних Unix та Y кількість процесорних архітектур.

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

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

Який би дистрибутив Linux ви не використовували, найімовірніше, надає джерела пакетів, які він пропонує. Швидше за все, він також забезпечує попередньо вбудовані пакети для стека LAMP.

Шлях до цього - отримати джерело пакету, змінити його під свої потреби та перекомпілювати.

Ви повинні зробити це на клієнтському ПК і завантажити отриманий пакет на сервер, тим самим знявши необхідність завантажувати щось з Інтернету на нього

Якщо ви вирішите встановити бінарні файли, надані стороннім постачальником, вам слід отримати їх джерела та змінити їх.

Чому ви не знайдете в Інтернеті попередньо складені файли / модулі для php, тому що в цьому немає необхідності. Використання (джерело) пакетів, зроблених для вашого розповсюдження, як правило, зручніше.