Я немного запутался, так как есть два способа установки приложений. Один из них - настраивать и создавать из исходников, а другой - из диспетчера пакетов. Если бы кто-то был администратором UNIX / Linux, справедливо ли использовать менеджеры пакетов и заслуживает ли это доверия? Я наткнулся на несколько мест, в которых, кажется, говорится, что сегодняшние администраторы действительно не знают, что они делают, потому что они не делают ничего с нуля и вместо этого предпочитают управление пакетами.
Итак, как начинающий администратор UNIX, я знаю, что должен знать оба метода, и я знаю, но какой из них следует выбрать в первую очередь. Например, на собеседовании, когда вас просят настроить Apache, нужно ли обращаться к источнику или к менеджеру пакетов?
Я всегда в первую очередь обращаюсь к менеджеру пакетов. Однако случаи, когда я компилирую из исходного кода:
Как системный администратор вы должны знать, как работать с исходным кодом ... конечно. В производственной среде рекомендуется использовать пакеты из исходного кода. Я бы сказал, только в определенных ситуациях, когда версия дистрибутива не поддерживает ваши требования.
Проблема с исходным кодом заключается в том, что вы несете ответственность за применение любых исправлений безопасности к коду приложения и любой библиотеке, на которую оно опирается. Или вам нужно постоянно обновлять версию, чтобы оставаться с последним защищенным кодом, что в большинстве случаев не является хорошим вариантом для производственного сервера. В то время как дистрибутив поддерживает исправления безопасности портов до версии, которую они поддерживают в течение многих лет. Таким образом, просто указав диспетчеру пакетов обновить систему, вы сможете поддерживать ее в актуальном состоянии с помощью исправлений безопасности. В долгосрочной перспективе это гораздо более управляемо.
Как системный администратор, вы также должны думать о том, кто стоит за вами. Наследование системы с мешаниной исходных пакетов не так уж и весело и в конечном итоге будет стоить компании больше денег.
Я наткнулся на несколько мест, в которых, кажется, говорится, что сегодняшние администраторы действительно не знают, что они делают, потому что они не делают ничего с нуля и вместо этого предпочитают управление пакетами.
Я считаю, что это утверждение неточно. Конечно, системный администратор должен знать, как компилировать из исходников, и очень редко кто не делал этого хотя бы раз.
Однако, как и все в жизни, решение о том, какой метод использовать, основано на ваших требованиях:
1) Если версии пакета официального дистрибутива покрывают ваши потребности в функциях, то ответ очевиден: используйте систему пакетов. Нет оправдания легкости, которую предоставляет система пакетов. Он автоматически устанавливает все зависимости, и ваша работа ограничена файлами конфигурации. В большинстве известных дистрибутивов (Redhat, Centos, debian) официальные пакеты постоянно обновляются, поскольку они поддерживают все исправления безопасности, и вам не нужно беспокоиться об обновлениях безопасности, поскольку они могут обновляться автоматически. Это очень полезно на производственном сервере, поскольку вы тратите свое время на системное администрирование, аудит и т. Д., Вместо того, чтобы постоянно проверять, есть ли в пакете новое обновление.
2) Если вашему проекту нужны новейшие функции, которые предоставляют только последние версии приложений, которые вам нужны, то вам нужно скомпилировать все из исходников. Это отнимает много времени, и вам нужно постоянно отслеживать, выходит ли новая версия с ошибками безопасности. Затем вам нужно все перекомпилировать. Недостаток очевиден. Однако проблема больше, если вам нужно администрировать более 1 сервера. В этом случае самый простой способ - создать собственный репозиторий, построить свои собственные пакеты на основе исходного кода последней версии, а затем снова использовать диспетчер пакетов на каждом сервере для обновления пакетов с помощью вашего репозитория.
Если вы собираетесь использовать какое-либо автоматическое управление конфигурацией, например puppet, chef, cfadmin, и др., тогда вам нужно будет хорошо разбираться в том, как работают ваши пакеты * nix. Также знайте, где находятся хорошие сторонние репозитории, поскольку они обычно содержат обновленные пакеты, если вы используете дистрибутив Enterprise или LTS.
Если вам нужно что-то скомпилировать из исходного кода, я рекомендую использовать согласованный макет и схему именования. Прочтите, как autoconf работает и использовать --prefix директива.
Лично мне нравится устанавливать свои собственные скомпилированные файлы в /opt, например
/opt/nginx/nginx-0.6.44
затем я создаю current символическая ссылка
/opt/nginx/current
затем создайте символическую ссылку на все двоичные файлы из пакета в известном месте, например
/opt/bin
например
cd /opt/bin && find /opt/nginx/current/bin -type f -exec ln {} \;
Позвольте мне добавить /opt/bin к моему $PATH а переключаться между версиями nginx так же просто, как установить новую версию в /opt/nginx/nginx-$VERSION и обновление символической ссылки
сегодняшние администраторы действительно не знают, что делают, потому что они не делают ничего с нуля и вместо этого предпочитают управление пакетами.
Я не думаю админ не знает, что они делают потому что они не хотят использовать управление пакетами. Есть много веских причин использовать менеджер пакетов. я думаю они не знаю, что они делают когда они не хотят понимать; как работает их система управления пакетами, как создавать собственные пакеты или когда им следует создавать свои собственные пакеты.
Обычно вы можете получить коммерческую поддержку от таких дистрибутивов, как Redhat и Ubuntu. Вы обнаружите, что получить поддержку намного проще, если вы используете официально поддерживаемые пакеты, а не то, что вы создали сами.
Есть также несколько коммерческих приложений, которые требуют использования официальных поддерживаемых пакетов, чтобы продукт действительно функционировал.
Если бы кто-то был администратором UNIX / Linux, справедливо ли использовать менеджеры пакетов и заслуживает ли это доверия
Преимущества пакетов из основных официальных дистрибутивов, таких как Redhat, Ubuntu, Debian и других, заключаются в том, что их использует множество людей, сила в цифрах. Все основные дистрибьюторы предлагают исходный код, необходимый для самостоятельной сборки пакета. Но если вы не доверяете распространителям создавать пакет, как вы можете даже верить, что в загруженном вами исходном коде нет ничего плохого? Есть ли у вас навыки для проведения аудита исходного кода? Сможете ли вы обнаружить лазейку в источнике или уязвимую ошибку? В какой-то момент вам придется кому-то доверять, потому что у вас, вероятно, не будет времени просматривать каждую строку кода, входящего в операционную систему.
На собеседовании, если вас просят настроить Apache, нужно ли обращаться к источнику или диспетчеру пакетов?
Чтобы ответить на вопрос, вам нужно время, чтобы изучить требования. Часто задаваемые вопросы правильного типа на собеседовании будут более впечатляющими, чем простой ответ. Вы также можете просто выбрать один метод и рассказать им несколько причин, почему этот метод хорош, и несколько причин, почему этот метод плох.
Я немного запутался, так как есть два способа установки приложений. Один из них - настраивать и создавать из исходников, а другой - из диспетчера пакетов.
Вы пропустили третий вариант. Создавайте свои собственные пакеты и поддерживайте локальный репозиторий, на который ссылается менеджер пакетов. Создание собственных пакетов предпочтительнее, потому что то, что вы создали, будет частью стандартной системы. Кто-нибудь, знакомый с менеджером пакетов, знает, как его удалить. Они смогут получить об этом информацию.
Если вы получаете свои посылки из надежного места, вы, вероятно, в порядке. У меня не было бы особых проблем с установкой Apache с помощью apt-get, но я должен уточнить это, отметив, что мы в основном используем Linux для некритических функций.