Рейтинг@Mail.ru

Наши партнеры

UnixForum


Библиотека сайта rus-linux.net

Обзор дистрибутива CentOS 8.0-1905

Оригинал: Review: CentOS 8.0-1905
Автор: Jesse Smith
Дата публикации: 21 октября 2019 года
Перевод: А. Кривошей
Дата перевода: 07 ноября 2019 г.

CentOS - это управляемый сообществом проект, который строит свой дистрибутив из исходного кода Red Hat Enterprise Linux. Целью проекта является предоставление бинарно-совместимого, практически идентичного с Enterprise Linux дистрибутива, но без коммерческой поддержки, предоставляемой Red Hat. Это делает CentOS привлекательным вариантом для людей, которые хотят иметь дистрибутив с долгосрочной поддержкой и той же технологией, которую предоставляет Red Hat, но считают, что им не нужна поддержка поставщика. Я рассматривал Red Hat Enterprise Linux 8 (RHEL 8), кратко рассказав об установщике дистрибутива, управлении программным обеспечением и настройками, некоторых его функциях на рабочих станциях и некоторых серверных технологиях, таких как Cockpit. В ходе этого опыта я столкнулся с несколькими проблемами - некоторые из них касались документации, некоторые были проблемами с разрешениями, некоторые из-за отсутствия приложений в официальных репозиториях, и мне было любопытно посмотреть, будет ли CentOS обеспечивать такой же опыт, такие же проблемы и все такое. Можно предположить, что будет, учитывая, что CentOS использует тот же исходный код, но CentOS имеет свой собственный веб-сайт и репозитории, поэтому я подумал, что стоило бы провести тестовый прогон и посмотреть, какие различия, если таковые имеются, я мог бы заметить. В частности, я планировал сосредоточиться на сильных и слабых сторонах, которые я заметил в моем обзоре RHEL 8.

Прежде чем приступить к описанию работы с CentOS 8.0.1905, я хочу упомянуть, что CentOS теперь доступен в двух ветвях: CentOS Linux, традиционная операционная система с фиксированными релизами, основанная на RHEL; и CentOS Stream. Новая ветвь Stream описана как платформа с непрерывным выпуском обновлений, которая будет располагаться где-то между Fedora и RHEL. Идея заключается в том, что программное обеспечение и концепции пройдут первоначальное тестирование в Fedora. Затем Red Hat создаст версию Fedora, которая станет основой будущего выпуска RHEL. Изменения и улучшения, которые обычно вносятся внутри Red Hat до следующего релиза RHEL, станут доступны общественности для тестирования и комментариев в CentOS Stream. В идеале, план, по-видимому, заключается в том, что это даст большей части сообщества возможность опробовать новые идеи и сообщить о проблемах, предоставив Red Hat больше отзывов и возможность отполировать свой коммерческий дистрибутив.

И CentOS Linux, и CentOS Stream доступны в двух редакциях: для DVD и для сетевой установки под названием Boot. DVD-образ CentOS Linux занимает 6,7 ГБ (примерно того же размера, что и RHEL 8), а выпуск Boot - 534 МБ. DVD-образ CentOS Stream еще больше, около 8 ГБ, но диск для сетевой установки занимает 533 МБ.

В примечаниях к релизу CentOS есть раздел, посвященный известным проблемам. Одно из этих предупреждений касается установки пакета «Server with GUI» в VirtualBox: «Если вы планируете установить CentOS-8 в гостевой VirtualBox, не следует выбирать «Server with GUI» (по умолчанию) во время установки». В примечаниях к релизу содержится ссылка на статью Red Hat, в которой подтверждается это предупреждение, но без объяснения причин возникновения такой проблемы. Так как «Server with GUI» является выбором по умолчанию в установщике, мы должны помнить об изменении выбора, если мы используем VirtualBox.

Установка

Насколько я могу судить, установка CentOS была идентична установке RHEL, по крайней мере, во время начальной настройки. Когда завершилось копирование пакетов на жесткий диск и мы перезагрузились, мастер первого запуска попросит нас принять лицензию. В CentOS это лицензионное соглашение является всего лишь отказом от ответственности и уведомлением о том, что CentOS использует Стандартную публичную лицензию GNU. Этап активации лицензии, используемый RHEL, отсутствует в CentOS, мы не обязаны регистрировать нашу установку у кого-либо.

Первые впечатления

CentOS предлагает те же параметры рабочего стола: GNOME Shell и GNOME Classic, которые доступны через сеансы X.Org и Wayland. Использование памяти и производительность, по-видимому, практически идентичны во всех параметрах сеанса по сравнению с их аналогами RHEL. Меню и выбор программного обеспечения также выглядят одинаково, наряду с настройками по умолчанию.

Панель настроек GNOME

Поддержка железа

CentOS без проблем работал на моей рабочей станции и обнаружил все мое оборудование. Настольный компьютер, аудио и беспроводные сети работали правильно. Как и RHEL, CentOS хорошо работал на моем физическом оборудовании. Попытка запустить CentOS в экземпляре VirtualBox - это другое дело. Как и RHEL, CentOS не предоставляет гостевые модули VirtualBox и не может интегрироваться с VirtualBox или использовать разрешение экрана хост-компьютера. Чтобы еще больше усложнить ситуацию, ни один из дистрибутивов не предоставляет модуль VirtualBox в своих репозиториях.

Когда я тестировал RHEL 8, я пытался собрать универсальный модуль VirtualBox, и сначала потерпел неудачу из-за отсутствующего пакета: elfutils-libelf-devel. После установки этого пакета я смог собрать дополнительный модуль и установить его без дальнейших проблем. Я попробовал это на CentOS, установив elfutils-libelf-devel и затем собрав гостевой модуль VirtualBox. Похоже, что это работает, и процесс сообщил, что модуль был успешно установлен. Но вскоре стало ясно, что модуль не работает.

Я проверил и обнаружил, что, несмотря на успешное создание отчетов о процессе сборки, модуль в моей системе нигде не был установлен. Затем я просмотрел список зависимостей, которые есть у VirtualBox, и обнаружил, что, хотя компилятор, инструменты сборки и файлы заголовков были доступны, Perl отсутствовал. По какой-то причине процесс сборки сообщает об успехе (и молча терпит неудачу), если не установлен Perl. Я установил Perl и больше у меня не было проблем. Я не уверен, почему это произошло в CentOS, а не в RHEL (возможно, в установке присутствуют разные пакеты по умолчанию), но в итоге я разобрался с этим, и в виртуальной среде дистрибутив заработал.

Управление пакетами

Работа с программными пакетами была той областью, где я увидел самые большие различия между RHEL и CentOS. Было некоторое сходство, так как оба используют диспетчер пакетов командной строки DNF (большая часть документации относится к диспетчеру пакетов YUM, но YUM - просто символическая ссылка на DNF). Оба дистрибутива используют GNOME в качестве графического интерфейса для установки новых пакетов и загрузки обновлений. Различия в основном касаются проблем с разрешениями и конфигурацией.

Например, когда я работал с RHEL, в GNOME Software не было доступных приложений. CentOS может отображать установленное программное обеспечение в GNOME Software и некоторые рекомендуемые элементы. Тем не менее, помимо этих нескольких пунктов в списке практически нет приложений. Поиск практически любого приложения не дает результатов, даже когда я искал пакеты, которые, как я знал, имелись в репозиториях. Например, поиск «thunderbird» в командной строке работает, но такой же поиск не работает в GNOME Software. Поиск слова «gimp» в любой из этих утилит предоставляет нам графический редактор GIMP.

Сравнение поиска в GNOME Software и DNF

Другое отличие заключалось в том, что в CentOS я мог выполнять поиск пакетов в командной строке, не используя sudo. Когда я запускал RHEL, любой поиск менеджера пакетов, выполняемый без разрешений sudo (или root), завершался ошибкой.

CentOS, как и RHEL, имеет небольшое подмножество программного обеспечения по сравнению с репозиториями Fedora. В то время как доступно множество пакетов программного обеспечения для ядра и сервера, большинства программ для рабочих станций, которые я пытался найти, там не было. Я смог найти GIMP и Thunderbird, но мало что кроме них. Не было VLC, MPlayer, Clementine, AbiWord, K3b, Audacity, веб-браузера Chromium или медиакодеков. Я надеялся исправить это, включив сторонние репозитории, такие как RPMFusion, ELrepo и EPEL-репозиторий Fedora. Исследуя эти репозитории, я смог найти медиаплеер VLC и некоторые кодеки, но другие пакеты остались недоступны.

Некоторое программное обеспечение, которое я нашел, я не смог установить. CentOS, как и его родитель, делает доступными кодеки MP3, но для большинства популярных форматов отсутствуют видеокодеки. При попытке воспроизвести видеофайл GNOME Software предложит найти отсутствующие кодеки. Менеджер программного обеспечения успешно нашел несколько пакетов кодеков, которые я мог загрузить, и большинство из них работало. Однако не все пакеты кодеков будут успешно установлены, и сообщения об ошибке не объясняют, почему это происходит. Я подозреваю, что существует конфликт между доступными репозиториями/пакетами, но GNOME Software не объясняет, почему оно отказалось установить пакет.

Когда я работал в RHEL, каждый раз, когда я делал опечатку в командной строке, например, набирал «sl» вместо «ls», оболочка зависала на несколько секунд и затем отображала сообщение об ошибке, относящееся к неудачному поиску пакета. Этого не происходит на CentOS. Набор опечатки, такой как «sl», сразу вызывает предложение, спрашивающее, хотел ли я напечатать «ls». Аналогично, ввод «ttop» предлагает использовать «top». В CentOS нет задержки или ошибки, только полезный совет.

Я считаю, что Flatpak, который установлен по умолчанию, заслуживает отдельного упоминания. Многие пользователи, обнаружив, что в CentOS и сторонних репозиториях отсутствуют многие популярные приложения, вероятно, решат обратиться к Flatpak, чтобы заполнить пробелы. На практике это может оказаться сложным. Начнем с того, что в CentOS нет репозиториев, включенных по умолчанию. Я пошел на Flathub и в инструкциях по включению репозитория в RHEL/CentOS сказано просто загрузить файл и установить его. Это звучит просто, но CentOS не распознает тип файла, что означает, что мы не можем установить или запустить его автоматически - нам нужно работать с ним из командной строки вручную. Затем я попытался вручную включить хранилище, используя файл, но, как сообщается, его цифровая подпись не была доверенной. В конце концов я включил репозиторий Flatpak вручную с помощью командной строки.

Прослушивание музыки в Rhythmbox

Другие наблюдения

Когда я работал с RHEL, я не смог установить какие-либо расширения Firefox. Я попробовал несколько, после обновления моей копии Firefox, но ни одно не работало. Каждое из расширений Firefox, которое я скачал в CentOS, работало безупречно.

CentOS, как и RHEL, разрешает удаленный вход в систему по умолчанию даже в роли рабочей станции. Это удобно для людей, выполняющих удаленные настройки, но также и дыра в безопасности, которую закрыло большинство других дистрибутивов. С другой стороны, CentOS обеспечивает соблюдение правил сложных паролей RHEL, требующих, чтобы учетные записи при создании имели либо длинные, сложные пароли, либо их вообще не было.

CentOS поставляется с установленным программным обеспечением для удаленного администрирования Cockpit, хотя оно и не активировано. Это отражает мой опыт с RHEL. Мне очень нравится Cockpit и как он дает легкий доступ к нескольким административным функциям. Используя Cockpit, я смог управлять службами, проверять использование ресурсов и просматривать журналы.

Управление службами в Cockpit

Когда я работал с RHEL, я не мог устанавливать обновления или новые приложения через Cockpit. Во время работы CentOS я мог проверять (и устанавливать) обновления пакетов. Однако Cockpit под CentOS не смог найти никаких приложений для установки.

Заключение

Опыт работы с CentOS очень похож на мой опыт работы с RHEL, чего и следовало ожидать. Оба дистрибутива используют один и тот же исходный код и одни и те же версии утилит. Хотя имеются небольшие различия, большинство из них относится к области управления программным обеспечением и начальной настройке.

Хотя процесс установки CentOS практически такой же, как в Red Hat, процесс получения установочного носителя совершенно другой. Для CentOS можно просто зайти на сайт проекта и нажать на соответствующую ссылку для скачивания. Red Hat требует регистрации (даже для бесплатной версии для разработчиков), просмотра версий продукта и выбора нужной версии. Затем мы должны сделать онлайновую регистрацию при первом запуске дистрибутива.

Управление пакетами в обоих дистрибутивах использует одни и те же утилиты, но опыт отличался как день и ночь. В RHEL GNOME Software вообще не работал для поиска и установки программного обеспечения. В CentOS он немного работал, хотя и с ограниченным выбором и с некоторыми пакетами, тихо отказывающимися от установки. DNF работал лучше на CentOS и не требовал административного доступа для выполнения простых поисков. Я не знаю, заключается ли разница в изменении конфигурации или исправлениях ошибок, которые были сделаны в CentOS за последние несколько месяцев.

Одно из самых больших отличий - это только вопрос времени. Когда я попробовал RHEL 8, сторонние репозитории еще не успели заполниться. К тому времени, когда появился CentOS 8, сторонние источники пакетов были запущены и работали, предоставляя некоторые (хотя, на мой взгляд, еще недостаточные) пакеты для заполнения пробелов.

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

* * * * *

CentOS/RHEL на десктопе

Я хотел бы добавить несколько комментариев об использовании Red Hat Enterprise Linux и CentOS на настольном компьютере. После того, как вышел мой обзор RHEL 8 , несколько человек подняли вопрос о ценности тестирования RHEL на рабочей станции или ноутбуке. Основной аргумент, что Red Hat в основном используется на серверах, так зачем обсуждать, как RHEL работает в среде рабочего стола? Зачем говорить о GNOME Software, GNOME и Wayland в операционной системе, которая часто работает без графического сервера?

Это справедливо, продукты Red Hat (и CentOS) обычно встречаются на серверах. Вот почему я говорил об управлении пакетами в командной строке и серверных утилитах, таких как Cockpit, больше, чем обычно. Тем не менее, я думаю, что есть как минимум три причины, почему важно также говорить об этих дистрибутивах, работающих на десктопах:

Установщик CentOS по умолчанию выбирает роль «Сервер с графическим интерфейсом». CentOS и RHEL могут использоваться в основном на серверах, но по умолчанию они устанавливают графические инструменты. Я думаю, что имеет смысл тестировать программное обеспечение, которое может быть установлено по умолчанию. Некоторые из альтернативных ролей также устанавливают десктопное программное обеспечение.

В примечаниях к релизу Red Hat говорится о таких функциях рабочего стола, как Wayland. Я подозреваю, что они не будут советовать пользователям этих функций, если они не ожидают, что люди будут их использовать. Аналогичным образом, хотя RHEL известен тем, что работает на серверах, многие профессионалы запускают эти дистрибутивы на своих рабочих станциях, особенно на работе.

Ранее в этом году Red Hat опубликовала статью «Why You Should Be Developing On Red Hat Enterprise Linux». В статье изложены предложения относительно того, почему разработчики должны использовать RHEL на своих рабочих станциях. Профессиональный пользователь настольного компьютера - рынок, на который Red Hat активно ориентируется. Если Red Hat хочет, чтобы разработчики, такие как я, запускали RHEL на наших рабочих станциях и ноутбуках, я думаю, что разумно принять их предложение.

Если вам понравилась статья, поделитесь ею с друзьями: