У меня есть 2 побочных проекта, которые я хотел бы завершить на работе:
Вот в чем проблема. Сервер Linux, на котором будут размещаться инструменты, имеет версию PHP, в которой не скомпилирован LDAP, а на сервере Apache по какой-то причине отсутствует mod_proxy_html.
Если бы я работал в Windows, я бы загрузил соответствующие модули, поместил их в каталог ext или modules, отказал бы серверу и продолжил бы свои дела. Однако с Linux, похоже, мой единственный вариант - перекомпилировать PHP (для библиотек LDAP) или самостоятельно скомпилировать модуль mod_proxy_html и все его зависимости.
Теперь я знаю, о чем вы, вероятно, думаете: «Почему бы вам просто не использовать диспетчер пакетов для установки модулей?» Это справедливый вопрос.
Я смог скомпилировать PHP с нуля, но не без хорошей Бритье яка. Мне пришлось загрузить и скомпилировать 4 или 5 зависимостей, прежде чем я смог скомпилировать PHP с библиотеками LDAP, и даже тогда make test в основном сказал: «Привет, приятель. Я знаю, что у тебя было много проблем, чтобы скомпилировать это, но это выглядит некрасиво. Но удачи!»
Итак, мой вопрос: зачем это нужно? Почему я не могу просто загрузить предварительно скомпилированную (статически скомпилированную?) Версию нужных мне библиотек / модулей, поместить их в такое место, где Apache и PHP могут их видеть, перезапустить сервер Apache и продолжить свой веселый путь.
Какой бы дистрибутив Linux вы ни использовали, скорее всего, он предоставляет исходные коды для пакетов, которые он предлагает. Скорее всего, он также предоставляет готовые пакеты для стека LAMP.
Здесь можно получить исходный код пакета, изменить его в соответствии с вашими потребностями и перекомпилировать.
Вы должны сделать это на клиентском ПК и загрузить полученный пакет на сервер, тем самым избавившись от необходимости загружать на него что-то из Интернета.
Если вы решите установить двоичные файлы, предоставленные сторонними поставщиками, вам следует получить их исходные коды и изменить их.
Почему вы не можете найти предварительно скомпилированные библиотеки / модули для php в Интернете, потому что в этом нет необходимости. Обычно более удобно использовать (исходные) пакеты, созданные для вашего дистрибутива.
Причина, по которой вы не находите модель распространения программного обеспечения Windows почти столь же распространенной, заключается в совместимости двоичных файлов и управлении версиями библиотек. Вы можете спроектировать процесс сборки, который компилирует программное обеспечение на любом количестве платформ (путем автоматического определения необходимых инструментов сборки), гораздо проще, чем вы можете поддерживать X количество производных Unix и Y количество архитектур процессоров.
Что многие компании делают в этом сценарии, так это имеют сервер распространения пакетов в своей сети, к которому разрешен доступ серверам с ограниченным доступом. Этому серверу либо разрешено обновлять свой собственный репозиторий, либо он действует как прокси для запросов и обслуживает локальную версию пакета, если ему уже приходилось загружать его один раз. Это также становится центральной точкой распространения, если вы в конечном итоге создаете свои собственные пользовательские пакеты.
К сожалению, это будет не так полезно для вас, потому что вы загрузили сторонний «стек приложений» вместо того, чтобы использовать решение, поставляемое поставщиком. Обычно они предназначены для облегчения жизни энтузиастов программного обеспечения, которые просто хотят что-то запустить и запустить, не вкладывая столько усилий в то, чтобы компоненты хорошо взаимодействовали друг с другом, но на уровне предприятия вы должны тщательно продумать, как это происходит. впишется в жизненный цикл программного обеспечения вашей инфраструктуры.