Кто стоит за хранилищем Webtatic и доверяете ли вы ему?

В Webtatic репозитории есть много полезных пакетов для CentOS и RedHat. Однако хранилище очень непрозрачно, и мне трудно найти информацию о том, кто за этим стоит, кроме «Эндрю Томпсона», известного как Энди.

Кажется, он отлично справляется со всеми этими полезными пакетами. Мне нужно использовать репозиторий на действующих серверах компании, а использование неофициальных репозиториев немедленно вызывает тревогу.

• Это хранилище для одного человека?
• Поддерживается ли это компанией?
• Кажется, он существует уже несколько лет, но как насчет завтра? (кроме гигантского астероида, который может стереть нас всех)
• Насколько это безопасно? Я не хочу, чтобы рядом yum updateскачать троян.
• Как быстро внедряются исправления безопасности из предоставленных пакетов? ....

Отзывы от реальных администраторов CentOS / RedHat будут высоко оценены.

заранее спасибо

Когда я впервые начал работать в качестве администратора Linux 8 лет назад, я использовал популярный сторонний репозиторий для обновления своего стека LAMP. Им управлял один человек. Одной из основных причин было то, что разработчики давили на меня за более новую версию PHP, чем та, которая шла с RHEL 5. В итоге она меня укусила.

Этот человек отказался от репозиториев, поэтому я больше не получал обновления безопасности, но я также не мог удалить все более новые пакеты и вернуться к пакетам RHEL из-за версии PHP RHEL из слишком старой ветки. Переход к стеку LAMP этого хранилища затронул как минимум полдюжины пакетов или более. Таким образом, поддержание этих пакетов и перекомпиляция их всех вручную время от времени будет важной PITA.

Вы также теряете возможность использовать рекомендации по безопасности поставщика ОС в отношении уязвимостей CVE, чтобы определить, является ли ваша система уязвимой для определенных эксплойтов для этих пакетов. Это оказалось для меня серьезной проблемой спустя годы, хотя я бы никогда не ожидал в то время.

Таким образом, помимо доверия к честности и техническим навыкам сопровождающих, вы должны спросить себя, доверяете ли вы им, чтобы они не переходили на новую работу, которая не позволит им сохранить хранилище, или они поженятся и будут иметь детей и больше не будут есть время и т.д ....

С тех пор я очень осторожен в использовании любых сторонних репозиториев, особенно тех, в которых работает только один человек.

Вопрос не в том, доверяем ли мы Энди, а в том, доверяете ли вы Энди.

Я не знаком с хранилищем, но кнопка пожертвования предполагает личные усилия. Не стесняйтесь вносить свой вклад, если это имеет значение для вас.

Пакеты выглядят как подписанные GnuPG, поэтому можно с уверенностью проверить, что пакеты являются подлинными. Вы также можете проверить, находится ли он в сети доверия.

Что касается качества или безопасности, лучше всего, если кто-то еще посмотрит, как работает репозиторий. Это может быть ты. Подпишитесь на последующие рекомендации по безопасности и проверьте, не затронуты ли они. Оцените пакеты как рецензент для Fedora.

Если для вас важна преемственность этих пакетов, приобретите аналогичные навыки. Изучите упаковку или наймите кого-нибудь, кто может.

Remi является стандартом для последних сборок PHP для RHEL. Он является давним и надежным источником пакетов RPM, который активно поддерживается и включает в себя как можно больше соответствующих пакетов.

Веб-источник неизвестен и не заслуживает доверия. Это не должно использоваться вообще.

Я обнаружил, что он работает на устаревшей системе. У него была серьезная утечка памяти. Я заменил его на Remi, точно такую ​​же версию PHP, и вдруг все работает гладко. Я не думаю, что это даже стабильная компиляция.

В общем, если вы не знаете, что есть функция, в которой вы действительно нуждаетесь и без которой не можете жить (многие люди будут верить, что они не смогут… пока не будет выбора между «старым» или ничем), тогда придерживайтесь пакетов поставщиков.

Научите своих веб-разработчиков, почему ветвь не является застойным снимком, и покажите им - PHP отлично подходит для этого - как перебазирование вверх по течению приносит гораздо больше ошибок; и как во многих случаях время отклика для бэкпорта вокруг проблемы безопасности на самом деле быстрее и надежнее доставляется дистрибутивом в поддерживаемой ветке (потому что это чей-то приоритет и работа), чем в вышестоящей OEM-версии.

Вы можете быть тем, кто действительно преуспевает, и вы обязаны сделать это для остальных из нас ;-)