Вопрос: Источник против менеджеров пакетов на работе


Я немного смущен, так как есть два способа установки приложений. Один из них - настроить и сделать из источника, а другой - менеджером пакетов. Если кто-то был администратором UNIX / Linux, справедливо ли использовать менеджеров пакетов и заслуживает ли доверия? Я столкнулся с несколькими местами, которые, по-видимому, говорят, что сегодняшние админы действительно не знают, что они делают, потому что они не делают ничего с нуля и вместо этого предпочитают управление пакетами.

Так что, как начинающий администратор UNIX, я знаю, что должен знать оба метода, но я должен это сделать, но в первую очередь выбирать. Например, на собеседовании, если его попросили настроить Apache, можно ли обратиться к источнику или менеджеру пакетов?


6
2018-02-27 05:03


Источник


Только 2? Это было бы блаженством. - William Pursell


Ответы:


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

  • Пакет устарел. Это чаще, чем должно быть.
  • Я хочу установить в другое место, чем по умолчанию.  Я делаю это много на экземплярах Amazon EC2, поэтому я могу установить на свое устройство EBS, а не на эфемерное локальное хранилище.
  • Приложение необходимо скомпилировать с использованием различных опций или с исходным патчем.  PHP является самым распространенным преступником здесь.
  • Приложение - это зависимость от того, что вы хотите установить, и у вашего менеджера пакетов нет соответствующих заголовков / пакетов разработки. Не все так распространено, но это происходит время от времени.

11
2018-02-27 05:46



Хороший список того, когда и зачем использовать источник. - 3dinfluence
Я бы добавил, что если вы скомпилируете исходный код, по-прежнему неплохо создать пакет из него. Таким образом, вы можете установить и, что более важно, удалить или обновить программное обеспечение с помощью диспетчера пакетов. - Laurent Parenteau


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

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

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


4
2018-02-27 05:50





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

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

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

1) Если версии пакета официального дистрибутива покрывают ваши потребности в функциях, тогда ответ ясен: используйте систему пакетов. Нет никакого оправдания легкости, предоставляемой системой пакетов. Он автоматически устанавливает все зависимости, и ваша работа ограничена в файлах конфигурации. Самые известные дистрибутивы (Redhat, Centos, debian) постоянно обновляют официальные пакеты, поскольку они поддерживают все патчи безопасности, и вам не нужно беспокоиться о обновлениях безопасности, так как они могут обновляться автоматически. Это очень полезно на производственном сервере, поскольку вы тратите свое время на системное администрирование, аудит и т. Д., А не на постоянную проверку наличия нового обновления пакета.

2) Если вашему проекту нужны новейшие функции, которые предоставляют только самые последние версии приложений, которые вам нужны, тогда вам нужно скомпилировать все из источника. Это требует много времени, и вы должны постоянно следить за тем, не выходит ли новая версия с ошибками безопасности. Тогда вам придется перекомпилировать все. Недостаток ясен. Однако проблема больше, если вам необходимо администрировать более одного сервера. В этом случае самый простой способ - создать собственный репозиторий, создать свои собственные пакеты на основе исходного кода последней версии, а затем снова использовать диспетчер пакетов на каждом сервере для обновления пакетов с помощью вашего репозитория.


3
2018-02-27 09:35





Если вы собираетесь использовать любое автоматическое управление конфигурацией, например 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 и обновление символической ссылки


2
2018-02-27 08:00





сегодняшние админы действительно не знают, что они делают, потому что они   не делайте ничего с нуля и вместо этого предпочитаете управление пакетами.

Я не думаю, что admin не знает, что они делают потому что они не хотят использовать управление пакетами. Существует много веских причин для использования диспетчера пакетов. Я думаю, что они не знаю, что они делают когда они не понимают; как работает их система управления пакетами, как создавать собственные пакеты или когда они должны создавать свои собственные пакеты.

Обычно вы можете получать коммерческую поддержку от дистрибутивов Redhat и Ubuntu. Вы найдете поддержку намного легче, если вы используете официально поддерживаемые пакеты, а не то, что вы сами создали.

Есть также несколько коммерческих приложений, которые требуют, чтобы вы использовали официальные поддерживаемые пакеты, чтобы фактически создать функцию продукта.

Если бы вы были UNIX / Linux   администратора, справедливо ли использовать   менеджеров пакетов и заслуживает доверия

Преимущества пакетов от официальных крупных дистрибутивов, таких как Redhat, Ubuntu, Debian и других, это то, что многие люди используют их, есть численность. Все основные дистрибьюторы предлагают источник, который вам нужно, чтобы перестроить пакет самостоятельно. Но если вы не доверяете дистрибьюторам создавать пакет, как вы можете даже верить, что нет ничего плохого в загруженном вами источнике? У вас есть навыки для выполнения проверки кода исходного кода? Сможете ли вы обнаружить заднюю дверь в источнике или уязвимость? В определенный момент вам придется доверять кому-то, потому что у вас, вероятно, не будет времени, чтобы просмотреть каждую строку кода, которая входит в операционную систему.

на собеседовании, если его попросят создать   Apache, доступен ли для источника   или менеджер пакетов?

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

  • Нужна ли им стабильная коммерческая поддержка?
  • Нужна ли им какая-то необычная функция, которая не включена
  • Ожидайте поддержку нескольких серверов в будущем
  • У вас достаточно хостов, работающих под управлением apache в вашей сети, которые вы можете себе позволить, самостоятельно контролируя восходящие каналы безопасности и списки безопасности.

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

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


2
2018-02-27 08:39





Если вы получаете свои пакеты из уважаемого места, вы, вероятно, в порядке. У меня не было бы особых проблем с установкой Apache с apt-get, но я должен квалифицировать это, отмечая, что мы в основном используем Linux для некритических функций.


0
2018-02-27 05:21