Как правильно обновлять Ubuntu Server 8.04?
У меня есть веб-сервер под управлением Ubuntu Server 8.04, и я хотел бы знать правильные команды для его обновления.
Я использую apt-get update и apt-get upgrade, но иногда он говорит мне, что есть задержанные пакеты. Я использую apt-get dist-upgrade, чтобы получить оставшиеся пакеты. Это лучший способ справиться с этим? Я не хочу обновляться до 8.10 или чего-то более позднего, пока не выйдет 10.04 LTS.
5 ответов
Обновление: за комментарий sparks, я должен отметить, что в моем ответе ниже вместо "apt-get" можно использовать "aptitude", с одним исключением: "apt-get upgrade" будет заменено на "aptitude safe-upgrade", Внешний интерфейс aptitude для APT имеет несколько приятных особенностей по сравнению с apt-get, как описано в этом сообщении в блоге. Однако, если у вас уже есть система, которой вы управляете с помощью apt-get, вы, безусловно, можете продолжить использовать apt-get, и, вероятно, должны. Мы не занимаемся большой установкой / удалением программного обеспечения на сервере, поэтому я не считаю, что использование aptitude имеет решающее значение, но если бы я сегодня запустил новый сервер, я бы, вероятно, использовал его.
Последняя документация по Ubuntu Server по- прежнему подробно описывает использование apt-get и обсуждает aptitude только как графический интерфейс для APT. Хотя это, конечно, недосмотр, это, безусловно, подразумевает, что в использовании apt-get нет ничего плохого.
Я использую пакет автоматических обновлений Ubuntu для автоматического применения обновлений безопасности. Вот мои замечания по настройке (на сервере Ubuntu 8.04 LTS):
$apt-get install unattended-upgrades update-notifier-common
Edit /etc/apt/apt.conf/50unattended-upgrades. Select only security upgrades, and set mail address
Unattended-Upgrade::Allowed-Origins {
"Ubuntu hardy-security";
// "Ubuntu hardy-updates";
};
Unattended-Upgrade::Mail "youremail@yourdomain.com";
Install mailx (required for unattended-upgrades mail to work)
$apt-get install mailx
Edit /etc/apt/apt.conf.d/10periodic :
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::Unattended-Upgrade "1";
Используя эту конфигурацию, обновления безопасности будут применяться автоматически, а список обновлений будет выслан вам по электронной почте. Хотя автоматическое применение любого обновления может показаться опасным, я считаю, что не отставать от обновлений безопасности - это задача, достойная риска… и, честно говоря, "поддержание" требует автоматизации.
Что касается обновления пакетов, я задал вопрос, чтобы уточнить значение dist-upgrade, которое может оказаться полезным. В основном, когда вы делаете обновление apt-get, установленные пакеты будут обновляться, только если обновление не требует новых пакетов или удаления пакета (например, зависимости не меняются). Если у обновленного пакета есть новые зависимости, вам нужно вместо этого использовать apt-get dist-upgrade. Поскольку apt-get dist-upgrade также делает все, что делает apt-get upgrade, я обычно использую его по умолчанию. Важно следить за тем, какие пакеты будут изменены, и принимать любые меры предосторожности, которые вы сочтете необходимыми.
Короче:
apt-get update
apt-get dist-upgrade
Если я нервничаю из-за того, что хочет сделать dist-upgrade, я сделаю:
apt-get update
apt-get upgrade
По крайней мере обновить пакеты, которые не имеют новых зависимостей, пока я не проведу небольшое исследование. Однако всегда есть вероятность, что что-то сломается, что бы вы ни делали, так что вам просто нужно верить:)
И последнее замечание: если вы применяете обновления для системы безопасности и уверены, что Canonical хорошо справляется с задачей, исправляя ошибки, вы можете обнаружить, что обновлять пакеты не так уж и нужно. Если сервер работает без ошибок, хорошо... он работает.
aptitude update
aptitude safe-upgrade
Команда Debian рекомендует использовать aptitude вместо apt-get в эти дни. Тем не менее, я также видел несколько мест, в которых говорилось, что если вы используете apt-get на конкретном сервере, вы должны продолжать делать это и просто использовать aptitude для будущего boxen.
Я использую гибридный подход. Я хочу, чтобы обновления были применены как можно скорее, но не "без присмотра", так как у меня были обновления, которые ломали вещи раньше.
Каждую ночь я запускаю задание cron с помощью следующей команды:
/usr/bin/apt-get update -qq;/usr/bin/apt-get dist-upgrade -duyq
Затем, если есть какие-либо доступные обновления, они загружаются и сидят там, ожидая меня, когда я читаю свою электронную почту утром. Тогда я просто бегаю
apt-get dist-upgrade
вручную и следите за проблемами. Often I will do a backup or snapshot of a server before performing the upgrade, if the packages appear critical to the functionality of that server.
This solves the problem for me by notifying me immediately (or whenever the cron job was run) of any available upgrades, but still allows me to be there when the actual upgrade takes place.
As for your second question about held-back packages. I don't often see them (perhaps because I use "dist-upgrade" instead of "upgrade"). But when I do, I have found that the problems can usually be resolved by removing and re-installing the package in question.
Я обычно использую aptitude для полного обновления, но он не содержится в man-странице. Странный...
Вы можете настроить Ubuntu для ограничения обновлений до версий LTS, чтобы вам не предлагали обновиться до текущей более новой версии, которая не является LTS. Однако в тот день, когда выйдет следующий LTS, он предложит обновить его. Вы можете или не хотите этого в первый день...
Поскольку я не нахожусь в версии LTS в настоящее время, я не могу искать настройку, поскольку она не предлагается. Я посмотрю в офисе и отредактирую эту запись завтра, если кто-то не укажет на соответствующие настройки, прежде чем я доберусь до нее.
Если вы просто заинтересованы в обеспечении его безопасности, вы можете использовать cron-apt для настройки автоматического обновления и закомментировать все, кроме репозиториев безопасности, в /etc/apt/sources.list.