Знакомство с Linux. Часть 22. Актуализация Fedora Core 1

Как уже отмечалось, Fedora Core 1 появилась на свет в довольно-таки сыром состоянии. Не в плане общей функциональности, а скорее в том, что касается проблем безопасности и устойчивости работы отдельных ее приложений.

Но ведь именно проблемы безопасности больше всего и занимают нынешнего завсегдатая Всемирной Паутины. Каналы связи становятся толще, сама связь - дешевле, ADSL и её аналоги распространяются на рынке с завидной скоростью... И значит, все больше времени пользователь ПК проводит в контакте с Интернетом. А иногда и оставляет компьютер подключенным к Сети для автономной работы под защитой надежного ИБП - чтобы, к примеру, скачать какой-нибудь фильм или крупный дистрибутив. Значит, каждому хочется иметь в своем распоряжении как можно более надежную, устойчивую к атакам и спонтанным сбоям систему, дабы уже не беспокоиться о ее автономной функциональности. И если мы собираемся построить такую систему на базе Fedora Core 1, исходный дистрибутив придется определенным образом подправить - избавив от некоторых присущих ему "с рождения" недостатков. Чем, собственно, прямо сейчас и займемся.

Одной из наиболее часто используемых в семействе ОС от Microsoft функций является Windows Update - если, конечно, владельцу вычислительной системы есть дело до сохранности его данных и собственного спокойствия. Аналогичная служба автоматизированного обновления устаревающих программных пакетов издавна присутствует и в дистрибутивах Linux от компании Red Hat Inc. Это утилита up2date - исполнив ее из командной строки от имени суперпользователя, можно установить соединение со служебным сервером компании, чтобы загрузить последние обновления системы. После загрузки производится процедура переустановки свежих версий пакетов. Поскольку при работе c Linux образы ядра и другого необходимого для функционирования системы ПО размещаются в оперативной памяти машины, непосредственно после инсталляции обновлений систему перезагружать не потребуется - но, разумеется, свежие версии программ запустятся на исполнение только после обращения к ним, так что если обновлению подверглось само ядро, для пользования его новой версией перезагрузка окажется необходимой.


Вплоть до версии 7.3 пользователи Red Hat Linux прибегали к услугам Red Hat Network, составной частью которой являлась служба up2date, совершенно свободно и без заметных проблем с трафиком. Однако ближе ко времени выхода девятой версии дистрибутива приоритеты уважаемой компании несколько изменились в сторону повышения внимания к нуждам платных пользователей ее продуктов - и трудно упрекнуть в этом право сотрудников Red Hat. Доступ к серверам с обновлениями системы "бесплатным" линуксоидам, конечно же, не перекрыли. Но зарегистрировавшиеся владельцы платных версий Red Hat Linux получали здесь преимущество - и поскольку данный дистрибутив является все-таки признанным мировым лидером, нагрузка на бесплатные сервера обновлений оказалась достаточно большой. А учитывая, что индивидуальные пользователи Linux на Западе - главным образом, люди не чуждые программирования и системного администрирования, и тем самым, уделяющие даже домашним своим каналам связи с Интернетом большое внимание, можно сделать неутешительный для нас с вами вывод: "толстые" каналы зарубежных линуксоидов, стремящихся выкачать с серверов Red Hat ободряющие своей частотой обновления, надежно перекрывают доступ к вожделенным ресурсам нам с вами - особенно тем, кто вынужден довольствоваться при выходе в Интернет с домашней Linux-машины модемным соединением. Если существенно необходимое обновление rpm-архива ядра системы "весит" около 12 Мбайт, то можете сами посчитать, сколько на уверенно обеспечиваемой вашим модемом скорости придется его оттуда выкачивать - и это в том случае, если соединение будет поддерживаться без сбоев и на максимально возможной скорости! А придется ведь обновлять и другие пакеты, с точки зрения безопасности (да и функциональности иногда) не менее нуждающиеся время от времени в модернизации, чем ядро...

Выход может заключаться в том, чтобы изыскивать альтернативные, заведомо "толстые" каналы для доступа к хранилищам обновленных программных пакетов, затем переносить эти пакеты на свой домашний компьютер (на дисках CD-RW, к примеру) и там уже заниматься непосредственно модернизацией. Собственно, работа любой утилиты "апдейта" разбивается на три этапа: определение, какие именно пакеты из установленных в данной системе требуют модернизации; загрузка новых версий этих пакетов во временный каталог; сама модернизация. В зависимости от того, какой именно утилитой пользоваться, необходимо разместить скачанные по "толстому" каналу пакеты в той или иной временной директории - и затем просто дать системе произвести модернизацию, в минимальной степени задействуя Интернет-соединение.

Откуда брать rpm-пакеты со свежими версиями программ? Пока речь шла о собственно Red Hat Linux, все было достаточно логично: отправившись по адресу ftp.redhat.com/pub/redhat/linux/updates/9/en/os/ (для 9-й версии системы), можно было заглянуть в каталог i386/, чтобы обнаружить там скомпилированные для установки на ПК Intel-архитектуры пакеты, не учитывающие особенностей процессоров старших поколений. Как правило, к таковым относятся все пакеты, за исключением самых базовых (системного ядра). Если же, допустим, на свет появлялась новая версия именно ядра системы, а компьютер в вашем распоряжени - не Intel-based, а выстроенный на AMD Athlon, то обновления файлов ядра для него следовало брать из каталога athlon/, а прочих программ - из все того же i386/. Затем выкачанные по хорошему каналу пакеты размещались в каталоге /var/spool/up2date/, после старта утилиты up2date она загружала с сервера заголовки этих пакетов (файлы .hdr), удостоверялась в целостности и правильности обновлений - и актуализировала систему. Всё очень просто.


Для того, чтобы сориентироваться, откуда именно закачивать программные пакеты, логично использовать браузер; затем для собственно скачивания - "рабочие лошадки" вроде ReGet под Windows или wget под Linux/*NIX-системами. Если же доступа к "толстому" каналу не было - ничего не попишешь; базовые пакеты приходилось скачивать пусть даже через модем, по нескольку часов не прекращая работы компьютера. А что делать: безопасность превыше всего!

Однако с выходом Fedora Core 1 положение несколько изменилось. Во-первых, хотя уилита up2date никуда не делась из набора системных, обращаться за обновлениями она стала к серверу fedora.redhat.com - к серверу, специально выделенному для поддержки изначально бесплатного дистрибутива. Так что с одной стороны, делить канал с привелигированными пользователями уже не придется, а с другой - он все равно будет достаточно сильно загружен, причем постоянно - если американские и австралийские линуксоиды активны тогда, когда у нас наступает ночь, то из Европы и Африки обращаться к серверам Red Hat пользователи Fedora Core будут в одно время с нами.

Во-вторых, выход нового дистрибутива из-под единоличного надзора Red Hat Inc. означает, что теперь можно надеяться и обновления системы получать из альтернативных источников - причем с тем большей эффективностью, чем больше этих источников будет на свете появляться. И действительно: в качестве таких альтернатив можно уже сейчас указать как минимум два официальных репозитория модернизации пакетов Fedora Core - это сервера mirrors.kernel.org, главного портала, посвященного ядру Linux, и ftp.fedora.us - "материнский" сайт дистрибутива Fedora, продолжающий оставаться источником важнейшей информации, связанной с этим проектом.

В качестве примера того, как можно задействовать дополнительные серверы для закачки обновлений Fedora Core 1, рассмотрим настройку утилиты yum - "текстовой" альтернативы полностью графическому в настоящее время по умолчанию up2date. Yum - проект, предназначавшийся его разработчиками для автоматизации системных обновлений другого дистрибутива Linux, Yellow Dog, построенного на базе Red Hat. Утилита оказалась настолько простой и удобной, что трудившиеся над созданием Fedora программисты решили включить ее в комплект поставки наряду с up2date - и, на мой вкус, поступили очень удачно. Прежде всего потому, что настраивать yum и контролировать ее работу очень просто.

Для начала имеет смысл просмотреть страницы руководства по данной утилите - как обычно, при помощи команды man yum. Нас в основном будет интересовать применние yum с одним-единственным аргументом, а именно:

yum update

Эта команда заставит утилиту обратиться к ее конфигурационному файлу, считать оттуда имя сервера, где размещаются обновления системы, закачать их, а затем установить - с соблюдением всех взаимозаисимостей, что особенно важно при модернизации, скажем, библиотек KDE. Вообще, автоматическое отслеживание зависимостей - это главная причина, по которой имеет смысл применять утилиты, подобные yum и up2date. Разбираться вручную, какой пакет потребует, чтобы перед ним были непремено установлены другие, и какие из этих других откажутся устанавливаться без предварительно проинсталлированных третьих - задача частенько невероятно утомительная. Пусть уж в последовательности установки разбирается компьютер. Кстати, если к утилите обратиться следующим образом:

yum update наименование_пакета

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

Конфигурационный файл утилиты yum - /etc/yum.conf. Главные строки, которые он содержит, - это указания на сервера, откуда пойдёт закачка обновлений системы. Рекомендуемый сайтом Fedora.us (http://www.fedora.us/wiki/FedoraSources) внешний вид "серверной" секции /etc/yum.conf таков:

[fedora-us-1]
name=Fedora Core 1 -- Fedora US mirror
baseurl=http://SERVERNAME/fedora/fedora/1/i386/yum/os
[fedora-us-1-updates]
name=Fedora Core 1 updates -- Fedora US mirror
baseurl=http://SERVERNAME/fedora/fedora/1/i386/yum/updates
[fedora-us-1-stable]
name=Fedora Linux (stable) for Fedora Core 1 -- Fedora US mirror
baseurl=http://SERVERNAME/fedora/fedora/1/i386/yum/stable

Здесь заключенные в квадратные скобки обозначения - наименования отдельных подсекций, соответствующих, собственно, исходному коду дистрибутива, его обновлениям и стабильной ветке релиза. Именно в ней, кстати, можно ожидать в апреле появления следующей его версии, Fedora Core 2 - и те, кто будет к тому времени уверенно пользоваться yum, своевременно получат сообщение о доступности нового релиза. Другое дело, что новая версия дистрибутива опять-таки будет занимать не менее трех CD - так что с нашими скоростями выкачивать ее с сервера вряд ли окажется разумным шагом.

Строка "name=" содержит ту информацию, которая будет выведена в терминальное окно для удобства пользователя при старте утилиты. А строка "baseurl=" - самая главная. Здесь для каждой из подсекций указывается путь по дереву каталогов на данном сервере к собственно хранилищу инсталляционных пакетов, откуда они будут закачиваться на ваш компьютер. На каком именно сервере? Вместо http://SERVERNAME/ следует подставить действительное наименование одного из зеркальных серверов-репозиториев обновлений Fedora Core. Откуда их брать? Со странички http://www.fedora.us/wiki/FedoraMirrorList - здесь постоянно поддерживается в актуальном состоянии список действующих и готовых к услугам серверов. Просто добавьте нужный.

Дополнительное удобство работы с yum (и отличие от up2date) заключается в том, что в качестве базового сервера можно указывать не один - а столько, сколько понадобится. О деталях этой процедуры можно справиться на страницах руководства по самому файлу /etc/yum.conf, доступных по команде:

man 5 yum.conf

Так, например, указывать три сервера вместо одного в подсекции fedora-us-1-updates следует таким образом:

[fedora-us-1-updates]
name=Fedora Core 1 updates -- Fedora US mirror
baseurl=ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/fedora/fedora/1/i386/yum/updates
ftp://mirrors.usc.edu/pub/linux/fedora/fedora/1/i386/yum/updates
http://fedora.multikabel.nl/fedora/fedora/1/i386/yum/updates

Выбор текущего сервера загрузки производится по умолчанию в очередности записи - сперва проверяется на доступность первый, затем второй и т. д. Можно установить другой приоритет, - выбирать сервер из списка доступных случайным образом. Вообще, настроек у yum немало - можно, скажем, заставить утилиту оставлять без внимания выход обновлений для отдельных пакетов. Такое поведение очень удобно, скажем, в условиях модемного соединения, если вам не требуется при обновлении ядра системы (около 12 Мбайт) скачивать еще и файлы его исходных текстов (более 30 Мбайт). Как именно этого добиться - читайте на страницах руководства для самой утилиты и ее конфигурационного файла.

Сразу после установки Fedora Core 1 - и даже после обновления до самых распоследних версий пакетов - вы заметите, что в системе многого не хватает. Точно так же, как и в Red Hat Linux 9, по умолчанию отсутствует всяческая поддержка mp3, - соответствующие программы придется устанавливать самостоятельно. Надеюсь, по предыдущим статьям нашей серии вы с легкостью припомните, как это делается. Нет в Fedora Core 1 и средств для просмотра видео в Windows- и Mac-форматах - что же, мы не так давно научились справляться и с этим. А вот такой важный компонент мультимедийной среды современного компьютера, как флэш-плеер, не рассматривали. А ведь и он в комплект поставки по умолчанию Fedora Core 1 не входит. Займемся!


Простейший путь заставить систему саму помочь вам установить то или иное ПО - поставить ее в ситуацию, когда какой-то программы или драйвера будет явно недоставать. Так например, если мы решим заглянуть на возрожденный сайт Олега Куваева для повторного знакомства с вернувшейся из-за Можая Масяней (и не только), предупредительный браузер, будь то Mozilla или Konqueror, любезно поставит нас в известность о том, что воспроизведение флэш-роликов в настоящий момент невозможно. Загрузить ли соответствующее дополнение, будет нам задан вопрос? О, да!

В ответ на наше решительное "да" в новом окне откроется страница www.macromedia.com, и оттуда, проследовав по соответствующим ссылкам секции Download, можно будет скачать необходимый плеер. А можно сделать и по-другому - отправиться на страничку http://sluglug.ucsc.edu/macromedia/site_ucsc.html и взять уже скомпилированный для Fedora Core 1 плеер оттуда.

Если просто щелкнуть по выделенной подчеркиванием и цветом ссылке в окне браузера, то в действие придет встроенный в данный браузер внутренний загрузчик - мне лично очень нравится тот, что поставляется с Konqueror. Linux-пуристы вправе использовать более традиционные средства командной строки, такие как wget, задавая в качестве аргумента скопированный с текущей страницы адрес ссылки.


Следующий шаг - переход в терминальный режим и инсталляция закачанного пакета от имени суперпользователя:

su
rpm -Uvh flash-plugin-6.0.79-2.i386.rpm

(в том случае, если в терминале вы уже находитесь в том каталоге, куда скачали плагин-обновление). Macromedia Flash Player распространяется по собственной лицензии, хоть и бесплатно, и явное согласие с этой лицензией вы обязаны выразить в точности перед инсталляцией. Поэтому после того, как rpm-пакет будет распакован, на экране перед вами возникнет окошко с текстом лицензии и двумя кнопочками - Accept и Decline. Какую из них выбрать, пусть подскажет само сердце :).

Для тех, кто выбрал Accept, мир флэш-приложений оказывается отныне доступным и под Linux. Достаточно теперь закрыть все активные браузерные окна, запустить Mozilla - да, флэш-плеер, который мы только что установили, не работает с Konqueror, только с Mozilla, - перейти на намеченную станичку с вожделенным роликом - и насладиться им в полной мере.

Можно, конечно, при каждом входе в Сеть запускать yum с параметром update - на всякий случай, просто чтобы быть в курсе последних обновлений ПО, если они вдруг появятся. Можно даже встроить запуск yum в перечень программ, стартующих после установки ррр-соединения автоматически, - kppp такой возможностью обладает. Но мы не будем умножать сущностей: достаточно подписаться на почтовую рассылку Fedora, которая будет сообщать время от времени о выходе новых версий программ. Кроме того, через рассылку можно поучаствовать в обсуждении неясных для вас моментов, связанных с работой Fedora Core 1 - и для того, и для другого пригодится знание английского, конечно. Но как уже не раз подчеркивалось, в мире свободного ПО без этого языка деваться некуда.

Итак, почта. Воспользуемся для ее получения, хранения и отправки почтовым клиентом Evolution, рекомендуемым в Fedora для работы по умолчанию - это достойный и уверенно развивающийся проект, прекрасно подходящий для начинающих пользователей (особенно знакомых с Outlook) и богатый возможностями для пользователей "продвинутых".

Запуск клиента электронной почты и календаря Evolution осуществляется из главного меню KDE или Gnome, из раздела "Интернет". Это и в самом деле мощное средство организации времени - в нем реализованы ежедневник и система напоминаний о событиях, так что если вы собираетесь проводить за компьютером с Fedora Core 1 много времени, тем больше будет поводов ориентироваться именно на Evolution в повседневной работе. Собственно, почтовый клиент настраивается безо всякого труда: достаточно нажать на кнопку меню "Сервис", выбрать пункт "Изменить настройки" и в первом же разделе открывшегося менеджера настроек добавить при помощи соответствующей кнопки новую учетную запись.

Любопытной и в мире конечных Windows-пользователей пока что диковинной возможностью Evolution является не требующая особых мыслительных затрат настройка повышенной безопасности почтового соединения. Устанавливается она следующим образом. В том окне, где вы только что вводили имя новой учетной записи и свой почтовый адрес, перейдите к закладке "Получение почты" и пропишите в соответствующем окошке наименование почтового сервера. А затем обратите внимание на подвальчик "Проверка подлинности". Заставив появиться выпадающее меню "Тип проверки подлинности", вы увидите, сколько таких типов существует, - и какая, следовательно, по крайней мере теоретически у вас имеется возможность защитить свой канал почтовой связи. Теоретически - потому, что обмен почтой в кодированном режиме будет возможен, конечно же, только тогда, когда такой режим поддерживает почтовый сервер. Бесплатные сервера, как правило, этого делать не умеют. А вот многие сервера уважающих себя организаций, сотрудники которых имеют возможность проверять свою почту "снаружи", только защищенные соединения и настроены поддерживать - иначе трудно гарантировать, что передаваемый по открытому каналу пароль клиента или содержание его письма останутся скрытыми от чужих любопытных глаз. Так вот, нажав на кнопку "Проверка поддерживаемых типов", вы через некоторое время сможете посмотреть, насколько интеллектуален ваш почтовый сервер: сразу после этой проверки в уже знакомом нам выпадающем меню доступные опции соединения будут подсвечены, а недоступные - затенены.


Аналогичный сервис доступен и для соединений с целью отправки почты через внешний сервер; просто обратитесь к закладке "Отправка почты".

Настроив почтовый клиент для приема и передачи, переходите к тому, чего ради мы вообще за него взялись, - к подписке на сообщения команды разработчиков Fedora о выпускаемых ими обновлениях. Войдя на домашнюю страницу проекта www.fedora.us, обратите внимание на перечень Mailing Lists слева - как минимум, вас должны заинтересовать Fedora Package Announcements, объявления об обновлениях пакетов проекта. После того, как вы перейдете на нужную страницу и внесете свой почтовый адрес и выбранный для управления данной подпиской пароль в соответствующие поля, нажмите на кнопку "Subscribe" и ждите появления в своем ящике подтверждающего письма. Когда оно придет, ответьте на него, просто отправив обратно целиком, и дело будет сделано.


Вот теперь можно перестать беспокоиться относительно безопасности системы - и заняться другими её особенностями...