Источник по сравнению с Диспетчерами пакетов на задании
Я раньше был администратором в моей Электротехнической компьютерной лаборатории, считая приблизительно 20 компьютеров, всю Ubuntu. Мне понравилось всегда использовать последний релиз Ubuntu, как только он был выпущен, таким образом, я обновил много.
Установка компьютерной лаборатории была такова, что у меня было одно основное поле Debian (редко обновлял/обновлял), который я использовал для хостинга веб-страницы студенческого ответвления, управления учетными записями пользователей (с LDAP, разрешение каждому пользователю находиться в любом компьютере и войти в систему с его домашней доступной папкой), запуская скрипты обслуживания, и т.д.
Метод, который я раньше обновлял (который несколько сыр, по-моему, tbh) включенная запись CD с последним выпуском при выпуске, и вручную размещение их в дисках, перезагрузке и прохождении через регулярного процесса установки. Когда установка была завершена, я скопировал общедоступный ключ RSA, который я генерировал (однажды) к хосту (в/root/.ssh/папку), и поэтому предоставление управления полем Debian полем хоста. Таким образом на основном поле у меня был сценарий Python (это может, конечно, быть любой язык сценариев), который принес главный компьютер до скорости с моей требуемой конфигурацией, копируя файлы конфигурации в поле хоста (такие как файлы конфигурации LDAP, предварительно созданные файлы конфигурации гнома, и т.д.), склонный - получают необходимые пакеты (долгий процесс), настраивая их (путем копирования их файлов конфигурации и файлов пункта меню к корректным местам) и иначе установки поля хоста.
Этот процесс, хотя сырой и бесхитростный, только потребовал моего присутствия для того, чтобы на самом деле загрузить "обновленное будущим образом" поле от человечности, устанавливает CD и пройти несколько экранов установки для человечности, настраивая/etc/network/interfaces файл для доступа к сети, и затем запуская скрипт на основном поле, затем я мог быть от выполнения чего-то еще.
Если Вы хотите больше информации, отправьте более конкретно, что Вы хотите автоматизировать, является ли это просто фактическим процессом установки новой версии выпуска в настоящее время рабочего дистрибутива Linux или программ установки, которые требуют исходных файлов здания или такого (потому что я раньше также создавал мои собственные пакеты для программ, таких как Eclipse (который не играет по правилам с Ubuntu прямо от диспетчера пакетов), XCircuit (который является "багги" в лучшем случае от пакета repo, Matlab (который требует перфорации в ключ CD и больше)...
Надежда, которая помогает!=)
Я всегда иду для диспетчера пакетов сначала. Однако экземпляры, где я компилирую из источника:
- Пакет горестно устарел. Это более распространено, чем это должно быть.
- Я хочу установить на другом местоположении, чем значения по умолчанию пакета. Я делаю это много на моих экземплярах Amazon EC2, таким образом, я могу установить на своем устройстве EBS, а не эфемерном, локальном устройстве хранения данных.
- Приложение должно быть скомпилировано с помощью различных вариантов или с исходным патчем. PHP является наиболее распространенным преступником здесь.
- Приложение является зависимостью чего-то еще, что Вы хотите установить, и Ваш диспетчер пакетов не имеет пакета заголовков/разработки соответствия. Не все, что распространенный, но это действительно происходит время от времени.
-
1Хороший список когда и почему использовать источник. – 3dinfluence 27 February 2010 в 07:51
-
2Я добавил бы, что, если Вы компилируете из источника, это - все еще хорошая идея создать пакет из него. Таким образом, можно установить и, что еще более важно, удалить или обновить программное обеспечение легко с помощью диспетчера пакетов. – Laurent Parenteau 27 February 2010 в 15:23
Поскольку системный администратор должен Вы знать, как иметь дело с источником... уверенным. В продуктивной среде это желательный для использования пакетов из источника. Я сказал бы только под определенными ситуациями, где версия дистрибутива не поддерживает Ваши требования.
Проблема с источником состоит в том, что Вы затем ответственны за проверку, что Вы применяете любые патчи безопасности к коду для приложения и любой библиотеки, на которую это полагается. Или необходимо постоянно присваивать версию удару для пребывания с последним безопасным кодом, который не является хорошим вариантом для рабочего сервера большую часть времени. В то время как дистрибутив поддержит патчи безопасности порта к версии, они много лет поддерживают. Так просто, говоря Вашему диспетчеру пакетов обновить систему усовершенствует его патчей безопасности. Это намного более управляемо в конечном счете.
Как системный администратор также необходимо думать о том, кто приезжает позади Вас. Наследование системы с путаницей исходных пакетов не является большой забавой и будет стоить компании большего количества денег в конечном счете.
Я столкнулся с несколькими местами, который, кажется, говорит, что сегодняшние администраторы действительно не знают то, что они делают, потому что они не делают вещей с нуля и вместо этого предпочитают управление пакетом.
Я полагаю, что этот оператор не точен. Конечно, системный администратор должен знать, как скомпилировать из источника, и очень редко, чтобы каждый не делал этого, по крайней мере, однажды.
Однако, поскольку все в жизни, решая, какой метод нужно использовать, основано на требованиях:
1) Если версии пакета официального распределения удовлетворяют Ваши потребности для функций, то ответ является четким: Используйте систему пакета. Нет никакого оправдания простоте, которую обеспечивает система пакета. Это устанавливает автоматически все зависимости, и Ваша работа ограничена в конфигурационных файлах. Большинство известных дистрибутивов (Redhat, Centos, debian) постоянно сохраняет официальные пакеты обновляемыми, так как они бэкпортируют все патчи безопасности, и Вы не должны волноваться об обновлениях системы защиты, так как они могут быть обновлены автоматически. Это очень полезно в рабочем сервере, так как Вы проводите свое время в системном администрировании, контролируя и т.д., вместо того, чтобы постоянно проверить, имеет ли пакет новое обновление.
2) Если для Вашего проекта нужны последние функции, которые только обеспечивают последние версии - приложений, в которых Вы нуждаетесь - то необходимо скомпилировать все из источника. Это является трудоемким, и необходимо постоянно контролировать, если новая версия выходит с ошибками безопасности. Затем необходимо перекомпилировать все. Недостаток ясен. Однако проблема больше, если необходимо администрировать больше чем 1 сервер. В этом случае самый легкий путь состоит в том, чтобы создать собственный репозиторий, создать Ваши собственные пакеты на основе исходного кода последней версии и затем использовать снова диспетчер пакетов на каждом сервере для обновления пакетов с помощью репозитория.
Если Вы собираетесь использовать какой-либо вид автоматизированного управления конфигурацией, как puppet, chef, cfadmin, и др. затем необходимо будет быть довольны тем, как Ваш *пакеты nix работают. Также знайте, где хорошие репозитории сторонних производителей - поскольку они обычно содержат обновленные пакеты при использовании Предприятия или распределения LTS.
Если необходимо скомпилировать что-то из источника затем, я рекомендую использовать последовательное расположение и схему именования. Читайте на как autoconf работы и используют --prefix директива.
Лично, мне нравится устанавливать мой пользовательский скомпилированный материал в /opt, например,
/opt/nginx/nginx-0.6.44
затем я создаю a 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 с Кв. - добираются, но я должен квалифицировать это с замечанием, что мы главным образом используем Linux для некритических функций.