Блог:Точка Росы
Блог с постами технической направленности — чтобы похвалиться сделанной работой и поделиться результатами исследований, выполненных в текущей рутине.
Если вы умеете пользоваться агрегаторами RSS/Atom, подписывайтесь!. По любым вопросам можно писать сюда.
Весь контент данного блога распространяется на условиях Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA)
Открытый тест надежности жестких дисков и SSD
Создан открытый проект по оценке надежности жестких дисков (HDD и SSD) на основе собранных SMART данных в базе оборудования https://linux-hardware.org. Исходные данные в обезличенном виде, методы анализа и результаты выложены в новый репозиторий на github: https://github.com/linuxhw/SMART. Это наш ответ Google и Backblaze по анализу надежности дисков, но только участвовать в исследовании может каждый Linux-пользователь из сообщества путем обычного создания проб с помощью hw-probe!
Целью проекта является выявление дисков с максимальным временем работы без ошибок. В качестве меры надежности выбрано время работы диска в годах деленое на количество ошибок плюс один: Power_On_Hours/(1 + Number_Of_Errors), т.е. среднее количество лет работы до возникновения первой ошибки (или время между ошибками).
Таблицей с результатами надо пользоваться аккуратно. Надо обращать внимание не только на рейтинг, но и на число проверенных экземпляров модели диска. Если рейтинг низкий, то смотрите на число дней работы этого диска и количество накопленных ошибок. Если диск новой модели, то он будет постепенно подниматься к вершине рейтинга, если отработает достаточное время без ошибок.
В этом проекте есть целое поле задач для исследований. Наиболее актуальными являются улучшение формулы для меры надежности, формулы для усреднения результатов для нескольких дисков одной модели и выявление типов ошибок, указывающих на реальные неисправности или их скорое возникновение.
Пробу компьютера можно, как и раньше, сделать из приложения в SimpleWelcome или из консоли одной простой командой:
hw-probe -all -upload
Мобильная база оборудования
Встречайте мобильный интерфейс к базе оборудования ОС РОСА. Просто зайдите на сайт https://linux-hardware.org со смартфона или планшета и откроется компактная версия сайта. Теперь пользоваться базой значительно удобнее вне дома или офиса.
Пополняйте базу, ищите Linux-совместимые модели компьютеров и устройств, изучайте внутреннее строение своего компьютера — все это легче вместе с базой https://linux-hardware.org!
Docker-образ для ROSA Desktop Fresh R9
Нас часто спрашивают, где взять образ Docker для Росы. Такой образ полезен в ситуации, когда хочется быстро отладить сборку какого-то пакета, а установленной ОС ROSA под рукой нет. Разворачивать ради такой такой задачи виртуальную машину — излишество, а вот создать за пару секунд контейнер — самое то.
Для rosa2016.1 образы можно найти здесь:
Для платформы 2014.1 — здесь:
Образы rootfs, которые можно использовать для chroot или systemd-nspawn, с предустановленным ПО для сборки пакетов:
Запуск контейнера осуществляется стандартным образом:
# docker run -it --rm dsilakov/rosa
Файлы и скрипты, которые можно использовать для сборки образов: https://abf.io/soft/docker-brew-rosa.
Желающие делать производные образы либо дорабатывать текущие — welcome.
Установка свежих версий приложений в виде контейнеров
Несмотря на слово Fresh в названии нашего открытого дистрибутива, мы вовсе не стремимся всеми силами поместить в него самые свежие версии всех приложений. Все основные программы (входящие в репозиторий main) проходят тщательную проверку нашего QA, и в случае обнаружения проблем (особенно регрессий) мы либо чиним их сами, либо ждем исправлений от апстрима.
Однако время от времени все-таки хочется попробовать новую версию какого-нибудь приложения, несмотря на ее ошибки не дожидаясь ее появления в официальных репозиториях. Нередко для этого можно использовать неофициальные сборки от разработчиков и членов сообщества (например, немало интересного можно найти в репозиториях https://rosa.pkgs.org/2016.1/stan8-x86_64/ от наших пользователей из Польши.
Но есть и альтернатива — приносить пакеты не в виде RPM, а в виде самодостаточных контейнеров. Подробнее о данных технологиях можно узнать, например, из этой статьи, а применительно к РОСЕ и десктопным приложениям можно сразу воспользоваться инструментарием flatpak, доступным в репозиториях ROSA Desktop Fresh начиная с релиза R9.
Для начала поставим сам flatpak:
$ urpmi flatpak
А теперь перейдем в каталог приложений, скачаем файл flatpakref для нужного приложения и передадим его инструменту:
$ flatpak install --from https://flathub.org/repo/appstream/com.skype.Client.flatpakref $ flatpak run com.skype.Client
И вуаля — в два клика мы запустили новый Skype.
На данный момент приложений в каталоге не очень много. Но, с другой стороны, есть очень интересные и востребованные программы, свежие версии которых интересны многим пользователям — тот же Skype, LibreOffice, Spotify, Pitivi, Linphone и ряд других.
2017-06-20 Настройка двухфакторной аутентификации в ОС ROSA Desktop Fresh R9
Те, для кого информационная безопасность — не пустой звук, знают, что глупо просто увеличивать длину пароля в надежде повысить защищённость. Здесь целесообразно использовать многофакторную аутентификацию.
Тем более что почти все уже привыкли к так называемой 2FA, ибо даже покупки по карточке в интернете теперь требуют не только CVV2-код, но и одноразовый пароль из SMS от банка или другой дополнительный фактор аутентификации (привет отпечатку пальца).
Конечно, если у вас ноутбук, двухфакторная аутентификация не спасет вас от его кражи вместе с данными — тут нужно шифрование. Но от тех, кто подглядывает пароль через плечо, а потом втихую использует ваш компьютер, вполне поможет.
Да и выглядит это круто и профессионально, если вдруг нужно произвести впечатление на кого-нибудь.
Как же настроить двухфакторную аутентификацию в ОС ROSA?
Под катом — длинная инструкция для тех, кого не пугают трудности.
Настройка двухфакторной аутентификации в ОС ROSA Desktop Fresh R9
ABF: разблокируем Pull Request
За годы разработки РОСЫ мы получили тысячи Pull Request’ов от добровольных помощников из сообщества (в частности, запросы на обновление тех или иных программ). Жизненный путь большинства запросов очень прост — разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку Смерджить, после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого — если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.
Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) — Git-сервер ABF должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто — если сразу после создания запроса он находится в состоянии Готов к мерджу, то все хорошо. Если же он сразу оказался в состоянии Заблокирован, то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.
Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы — rosa2014.1, rosa2016.1 и так далее).
Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:
- пользователь создает «форк» проекта, который хочет изменить, в свой репозиторий;
- пользователь вносит необходимые изменения в свою копию проекта;
- пользователь создает запрос на изменение (Pull Request) в исходный проект.
Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял Pull Request от другого пользователя), то с большой вероятностью ABF не сможет автоматически влить изменения. Именно в такой ситуации и получится заблокированный Pull Request. Строго говоря, если вы изменяли одни файлы, а разработчик — другие, то блокировки не будет. Однако специфика сборки rpm-пакетов такова, что при внесении любых изменений вам надо как минимум пересобрать пакет с поднятием версии или релиза, а для этого надо изменить spec-файл. Поэтому 99 % изменений в проекте изменяют и spec-файл, как следствие — почти всегда параллельные изменения приводят к невозможности автоматически их объединить.
Итак, что же делать в такой ситуации?
Объединяем несколько коммитов Git в один
Нередко нам поступают Pull Request'ы типа такого: https://abf.io/import/flacon/pull_requests/3
Для разработчика здесь все хорошо, кроме истории Git-изменений:
- комментарии типа "Updated flacon.spec" не очень информативны - по ним невозможно понять, что именно изменилось. Конечно, об этом написано в заголовке и описании Pull Request'а, однако это описание в Git никак не попадает
- коммитов много, а хотелось бы объединить их все в один - который бы просто обновлял версию пакета.
Ниже мы покажем, как это можно сделать - объединить несколько коммитов в один и дать ему разумное имя. Делать это надо на локальной машине в клонированном репозитории; объединять коммиты рекомендуется до того, как делать "git push", но можно и после:)
Итак, склонируем проект drxank/flacon, ветку rosa2014.1:
$ abf get drxank/flacon -b rosa2014
Посмотрим на коммиты:
$ git log --pretty="%H - %s"
0daafc634cc589d1c873f6edae0fe21502d75594 - Updated flacon.spec 9e47bed614eacf1a1861936d7c18ab8e7f65bab4 - Updated flacon.spec b1083c0c6f5c5e80260c5f1dfc3aea15fbb69ef6 - Updated flacon.spec a800744f44b7cb10b3a03a2c97d0fe67c71a2992 - Updated flacon.spec 8d76a8f9322445f8a85b19d24ae6930bd14150c9 - Updated flacon.spec 7ace05fd871b5bde3aeefeac5bc4407ddfb9f04a - Updated flacon.spec f4814908d3d8fb0e17cea6cce44c82d90d1d3124 - Updated flacon.spec 81e7d1c97ca58747e24855f5a41285a93699842b - Updated .abf.yml e6f6db1e4eea0bd152a13845fb10afa75606a6d5 - Updated to 2.0.1 558e40eb6f548b63b8b4f029b5682a3aae67da02 - Updated to release 1.2.0 and added means to optionally build against QT5 c418829888ab1aa563a5453281147939451693ad - Updated to 1.0.1 6573986febf60d4cf5ff041bf83038178556c974 - MassBuild#464: Increase release tag 0de5f6058e14f49a971223401ddb0a59033609a8 - Log: Update to 0.9.4 4be631b55b44b1fa889e6fa41e1a9a8122f2b30c - Merge pull request #1 from symbianflo/flacon:rosa2012.1 Symbianflo da1fa9f156b85a070d8597c2ad8fcf59c164474b - Log update to 0.9.2, spec clean, fix buildreq, suggested restricted stuff, instead of required e7a176408a6f240549179d7f34dd193ffa6bed70 - Log update to 0.9.2, spec clean, fix buildreq 14cdfb66e339b5d07fc125ad008646881f44624c - Log update to 0.9.2, spec clean 3f703af118b51ae39e18b8a0c47bd1a3b0303905 - Updated to version 0.8.0 1d86128c11c086784734bcb2f04fa63e616bcef6 - Drop debug package bd4679a420d825cbf1e14d3793ddddfb1ef683d2 - Fix wavpack req to work on 64bit system dc8ccf7bf1ecaf5a0af076c4d86b46babe070a79 - Automatic import for version 0.6.1 79a243063006274f258c0e78932e9e0ca912c921 - Automatic import for version 0.6.0
Из это истории мы хотим объединить все коммиты вплоть до 81e7d1c97ca58747e24855f5a41285a93699842b - Updated .abf.yml.
Для этого делаем rebase на коммит перед "Updated .abf.yml" (это коммит e6f6db1e4eea0bd152a13845fb10afa75606a6d5 - Updated to 2.0.1)
$ git rebase -i e6f6db1e4eea0bd152a13845fb10afa75606a6d5
-i включает интерактивный режим - перед вами откроется редактор, где вы увидите следующую информацию:
pick 81e7d1c Updated .abf.yml pick f481490 Updated flacon.spec pick 7ace05f Updated flacon.spec pick 8d76a8f Updated flacon.spec pick a800744 Updated flacon.spec pick b1083c0 Updated flacon.spec pick 9e47bed Updated flacon.spec pick 0daafc6 Updated flacon.spec
Мы хотим слить все эти коммиты в один - в терминах Git это означает, что мы берем первый из них (хронологически) и "затаскиваем" ("squash") в него остальные. Для этого необходимо слово "pick" перед каждым "затаскиваемым" коммитом поменять на "s" (или на "squash", если не лень писать): Так что отредактируйте текст, чтобы он выглядел следующим образом:
pick 81e7d1c Updated .abf.yml s f481490 Updated flacon.spec s 7ace05f Updated flacon.spec s 8d76a8f Updated flacon.spec s a800744 Updated flacon.spec s b1083c0 Updated flacon.spec s 9e47bed Updated flacon.spec s 0daafc6 Updated flacon.spec
После чего можно сохраняться и выходить.
Далее вам предложат отредактировать описание коммита - по умолчанию это будет объединение описаний всех коммитов:
# This is a combination of 9 commits. # The first commit's message is: Updated to 2.0.1
# This is the 2nd commit message:
Updated .abf.yml # This is the 3rd commit message:
Updated flacon.spec # This is the 4th commit message:
Updated flacon.spec # This is the 5th commit message:
Updated flacon.spec # This is the 6th commit message:
Updated flacon.spec # This is the 7th commit message:
Updated flacon.spec # This is the 8th commit message:
Updated flacon.spec # This is the 9th commit message:
Updated flacon.spec
Все это смело удаляем и заменяем на одну фразу, отражающую суть:
Updated to 2.1.0
Сохраняемся и выходим.
Если вы уже сделали "git push" и изменения находятся на сервере, но необходимо проделать следующую операцию, чтобы закинуть на сервер объединенные коммиты:
$ git push origin +rosa2014.1
Сборка RPM — исправляем ошибки
После публикации заметки про обновление пакетов с помощью ABF к нам присоединилось немало добровольных помощников, регулярно присылающих pull request'ы на новые версии пакетов. Большинство pull request'ов очень просты и сводятся к обновлению версии приложения в spec-файле и заливке архива с новым исходным кодом на File Store. Однако часто сборка новой версии пакета завершается с ошибкой, которая не связана напрямую с кодом программы и может быть относительно легко исправлена без изучения ее кода.
Для тех, кто не желает ограничиваться обновлением версий программ и не хочет сдаваться при возникновении первой же ошибки, мы подготовили перечень часто встречающихся при сборке пакетов RPM ошибок, которые можно относительно быстро исправить. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.
Добавления и исправления в этот перечень всегда приветствуются!
Рулим Росой по сети
Содержание
- 1 Задача - рулить!
- 2 Доступ по SSH - используем консоль и mc
- 3 Защищаем SSH-сессии от прекращения при разрыве соединения
- 4 Запуск графических приложений через SSH (X11Forwarding)
- 5 Доступ к GUI, или помогаем пользователю
- 6 Простая программа для подключения к удаленной системе по VNC
- 7 То же самое, но красиво
- 8 Рулим зоопарком систем... или наоборот
- 9 Подключение по VNC с планшетов и смартфонов с Android
Большое обновление базы оборудования
Вот уже два года прошло с момента создания первой версии базы оборудования. За это время база активно использовалась сообществом, опередила Ubuntu по количеству компьютеров и получила простое и удобное приложение для KDE4 и Plasma5 для создания проб. При этом было выявлено много существенных недостатков. Все их удалось устранить в новой версии базы, которая доступна по адресу: https://linux-hardware.org
Из самых интересных доработок стоит отметить оптимизированный и переработанный web-интерфейс, передачу проб по шифрованному соединению HTTPS и получение пользователем дополнительной приватной ссылки для доступа ко всем данным пробы. Эта приватная ссылка в будущем будет использоваться для редактирования и комментирования статусов устройств в пробе.
Совместимость со старой базой полностью сохранена. Все пробы компьютеров из старой базы были перенесены в новую базу. Все будущие пробы в старой базе также будут раз в неделю копироваться в новую, так как остается ещё много установок РОСЫ со старым hw-probe.
С новой базой работают пакеты hw-probe и hw-probe-gui версии 1.1, которые должны уже скоро прийти в обновлениях на компьютеры пользователей после расширенного тестирования.
Приложение для KDE4 SimpleWelcome и для Plasma5.
Новый интерфейс: https://linux-hardware.org
Помимо приложения, пробу можно создать, как и раньше, одной простой командой из консоли:
hw-probe -all -upload
Теперь подробнее о наиболее интересных улучшениях:
- Из-за большого количества проб и устройств в старом интерфейсе большинство страниц тормозило, а некоторые и вовсе перестали работать. В новом web-интерфейсе существенно переработаны SQL-запросы и все страницы открываются быстро.
- Пробы теперь передаются по шифрованному соединению HTTPS.
- Помимо обычного URL для просмотра пробы, пользователю возвращается еще один приватный URL для доступа ко всем данным пробы. В скором времени по этому URL можно будет изменять статусы работающих и неработающих устройств и писать комментарии к ним. Таким образом база будет коллективно редактируемой.
- Используется XZ-компрессия проб, чтобы уменьшить трафик и увеличить емкость базы.
- Емкость базы увеличена до 110.000 проб.
- Упрощена система статусов устройств. Теперь статус (работает, не работает, и т.д.) закрепляется за системой, а не за драйвером. Если на каком-то драйвере не работает, то это описывается в комментариях.
- Определяется версия дистрибутива (R1-R8), а не только платформа.
- Если Mac-адрес был изменен, то будет определен настоящий.
- Все созданные пробы сохраняются в каталоге /root/HW_PROBE/ на компьютере пользователя.
- Оптимизированы алгоритмы хранения и доступа к пробам, что увеличило скорость открытия страницы самой пробы и ее логов.
Исследуйте различные конфигурации железа, обменивайтесь пробами, устраняйте проблемы и оптимизируйте работу Linux на компьютере. Все это теперь проще с новой базой оборудования!
«Сделай сам» — howto для желающих обновлять программы в Росе
Запросов от пользователей на обновление тех или иных программ в дистрибутивах ROSA Desktop Fresh мы получаем не много, а очень много. Приходится закрывать слишком разросшиеся темы на форуме, разбивая их на более мелкие.
К сожалению, выполнить абсолютно все пожелания разработчики РОСЫ не в состоянии. Однако помочь нам может каждый — вопреки распространенному мнению, для обновления какой-либо программы вовсе не обязательно быть программистом, разбираться в сборке пакетов и прочих премудростях. Во многих случаях вам хватит веб-браузера и желания сделать нечто полезное.
Итак, вы узнали о выходе новой версии вашей любимой программы и хотите обновить соответствующий пакет в РОСЕ. Для примера, возьмем набирающий популярность редактор Atom — у него недавно вышла версия 1.3.2, а в репозиториях РОСЫ на момент написания этой статьи — все еще версия 1.2.0. Давайте исправим это досадное недоразумение.
Первым делом идем и регистрируемся в нашей среде сборки ABF, если вы этого до сих пор не сделали — на http://abf.io кликаем в правом верхнем углу на «Регистрацию», вводим логин/пароль и успешно заходим в систему (регистрация абсолютно свободна, происходит мгновенно и не требует никаких подтверждений).
Теперь находим с помощью поиска интересующий нас пакет atom, находящийся в группе import (обязательно используйте эту группу, именно из нее собираются пакеты в официальные репозитории!).
Переходите в этот проект и жмите кнопку «Клонировать» («Fork»).
В появившемся окне выберите опцию «Клонировать в <ваш_логин>/atom» («Fork to <your_login>/atom»). Этим действием вы склонируете проект в ваш персональный репозиторий, где вы сможете с ним играться в свое удовольствие. Клонирование происходит достаточно быстро, и вы сразу будете перенаправлены на страницу склонированного проекта. Если вы видите сообщение о том, что репозиторий пуст — просто обновите страницу.
Следующим пунктом необходимо изменить используемую ветку Git-репозитория на rosa2014.1. Если эта фраза вам ни о чем не говорит, не пугайтесь — достаточно в выпадающем списке в правом верхнем углу выбрать значение «rosa2014.1» (мы используем эту ветку, начиная с релиза ROSA Desktop Fresh R4 и точно продолжим использовать в R7).
Теперь вам необходимо в списке файлов проекта найти файл с расширением «spec» («atom.spec» в нашем случае) и кликнуть на него и затем кликнуть на «Edit» для его редактирования.
Все, что вам надо изменить в этом файле — это значение тэга Version, который обычно находится где-то вверху файла. Как мы видим, сейчас здесь указана версия 1.2.0, и мы ее заменим на 1.3.2. После этого в окне «Commit message» оставьте некоторое разумное описание произведенных изменений — например, «Updated to version 1.3.2». На этом все — теперь файл можно сохранить соответствующей кнопкой внизу экрана.
Далее, необходимо скачать архив с новым исходным кодом (указанный в теге Source) и загрузить его на http://file-store.rosalinux.ru/. Для аутентификации необходимо использовать те же логин и пароль, что и на ABF. Для каждого файла File Store сгенерирует хэш, который необходимо прописать в гите в файле .abf.yml, например как в https://abf.io/import/texlive-accents/blob/rosa2019.1/.abf.yml
Если кто-то подумал, что этим мы и обновили программу в дистибутиве — спешим огорчить, мы всего лишь подготовились к попытке собрать новую версию, и теперь пора эту попытку произвести. Для этого кликаем на кнопку «New Build», и в появившемся окне выполняем два действия:
- на всякий случай, отключите ваш персональный репозиторий — вдруг там уже есть что-то, что помешает чистоте сборки
- если вы собираете пакет для репозитория Contrib (или просто не уверены, в какой репозиторий вы его собираете), то обязательно отметьте в левой колонке позицию «contrib» в секции «rosa2014.1»
После этого можно нажать на кнопку «Start Build» и ждать результата. Если сборка завершится с ошибкой — что ж, «нахаляву» обновить пакет не получилось, надо либо разбираться с ошибками либо бежать за помощью к более осведомленным людям. Если же сборка завершилась успешно, то на страничке сборки вы сможет получить rpm-пакеты с новой версией программы, которые вы можете скачать, установить и попробовать в деле.
Если новая программ работает как положено, то надо поделиться своими достижениями с остальными членами сообщества (ведь вы помните, что до сих пор мы все действия производили в вашем персональном репозитории?), послав запрос на обновление в основной проект, находящийся в группе import. Делается это посредством нажатием на кнопку «Pull Request» на страничке вашего проекта.
В появившемся окне убедитесь, что для исходного и целевого проектов выбрана ветка rosa2014.1, при необходимости нажмите кнопку «Update commits», оставьте некоторое вразумительное сообщение в поле Description и отправьте запрос, нажав на кнопку «Send Pull Request».
Разработчики получат уведомление о предлагаемых вами изменениях, рассмотрят их, внесут в основной проект в группе import и соберут новую версию пакета в официальные репозитории.
ROSA Desktop Fresh R6 LXQt
Спустя несколько месяцев после выхода ROSA Desktop Fresh R6 KDE, мы рады представить редакцию Desktop Fresh R6 с легковесным рабочим окружением, в роли которого на сей раз выступает LXQt.
Вплоть до версии Fresh R5 в качестве рабочего стола мы использовали LXDE, основанного на использовании библиотек GTK+2. Однако последний крупный релиз серии 2.x стека GTK+ состоялся четыре года назад; в настоящее время ветка 2.x еще поддерживается в плане исправления ошибок, но основная разработка ведется в ветке 3.x. Однако переход с GTK+2 на GTK+3 — занятие не очень прямолинейное, а результат перехода нравится не всем. Среди недовольных оказались и разработчики LXDE, поэкспериментировавшие с новым GTK и решившие посмотреть в сторону альтернативы в лице Qt. В 2013 году большинство разработчиков LXDE объединились с коллегами из проекта Razor-qt для работы над совместным проектом, получившим имя LXQt.
Основанный на GTK+2 «старый» LXDE при этом вовсе не умер и продолжает поддерживаться группой энтузиастов, но по темпам развития сильно отстает от своей новой альтернативы — например, между LXDE-редакциями ROSA Desktop Fresh R4 и Fresh R5 практически не было различий непосредственно в компонентах LXDE. А поскольку дистрибутив у нас все-таки называется «Fresh», то мы решили попробовать новое рабочее окружение. И вот, после нескольких месяцев полировки и обкатки нескольких версий LXQt, мы готовы предложить вам редакцию нашего дистрибутива на основе этого перспективного окружения.
Релиз основан на LXQt 0.10.0 — последней на данный момент версии окружения рабочего стола, собранной с использованием библиотек Qt5. По возможности, мы отбирали для включения в образ приложения, также использующие Qt5. Набор таких приложений включает в себя:
- менеджер файлов PCManFM-Qt
- эмулятор терминала qterminal
- просмотрщик изображений lximage-qt
- почтовый клиент Trojita
- просмотрщик PDF qpdfview
- аудиопроигрыватель qmmp
- текстовый редактор juffed
- менеджер буфера обмена qlipper
Впрочем, Qt5-программ на все случаи жизни пока что не хватает, поэтому в Desktop Fresh R6 LXQt входят и несколько Gtk-приложений. В первую очередь это офисный пакет LibreOffice и веб-браузер Firefox — мы решили не заменять их полуфункциональными альтернативами исходя только из используемых библиотек, хотя энтузиасты могут попробовать и otter-browser — браузер на основе Qt5, имеющий целью воспроизвести внешний вид Opera 12.x.
Отметим, что у LXQt есть собственная панель управления (аналог KDE System Settings, также известного как «Параметры системы»), в который органично вписались специфичные инструменты РОСЫ — в частности, программа установки и удаления программ.
В Desktop Fresh R6 LXQt используется дисплейный менеджер SDDM, являющийся также рекомендуемым менеджером для Plasma 5 — так что с большой вероятностью в будущем вы увидите его и в релизах РОСЫ на основе KDE. Также это первый релиз РОСЫ с новым ядром по умолчанию — мы переехали на использование LTS-ветки 4.1 в качестве основной для наших настольных систем.
Скачать дистрибутив можно здесь
Минимальные системные требования
- 256 Мб ОЗУ (рекомендуемый объем — 512 Мб, для режима Live рекомендуется 384 Мб).
- Место на жёстком диске: 6 Гб HDD
- Процессор: Pentium4/Celeron
Описание системы управления виртуализацией
В последние месяцы мы отмечаем рост интереса пользователей к теме виртуализации. В этой статье речь пойдет о системе управления виртуализацией «ROSA Virtualization», базирующейся на продукте с открытым исходным кодом «oVirt» (www.ovirt.org).
Сейчас мы осуществляем его перевод на русский язык, занимаемся написанием документации и модифицируем его с учетом требований нормативной базы по ИБ (согл. Приказам ФСТЭК №№ 17 и 21).
Настройка VNC-сервера в ОС РОСА «КОБАЛЬТ» 1.0 и RELS 6.x
В этой статье мы настроим простой сервер VNC в ОС "РОСА SX COBALT 1.0".
Эта же настройка справедлива и может применяться для ОС ROSA Enterprise Linux Server 6.x.
Для сервера применялась ОС "РОСА SX COBALT 1.0", установленная по-умолчанию (в конфигурации "Стандартный сервер РОСА").
FQDN сервера - cobaltsx.rels.dom, IP - 192.168.231.118.
Для клиента применялась ОС "РОСА DX64 COBALT 1.0", установленная по-умолчанию.
FQDN клиента - cobaltdx.rels.dom, IP - 192.168.231.120.
- 1. Сперва настроим сервер. Для настройки VNC сервера требуются полномочия суперпользователя (root).
- 2. Для начала на сервере заведите пользователя (в примере мы с помощью командного интерфейса добавляем пользователя с именем user2):
adduser user2
Установите пароль для пользователя:
passwd user2
Переключитесь в контекст пользователя user2:
su - user2
Теперь нужно установить пользователю отдельный пароль на доступ к VNC соединению. Для этого выполните команду:
vncpasswd
Выйдите из контекста пользователя, нажав Ctrl+d
- 3. Любым удобным для Вас текстовым редактором отредактируете файл /etc/sysconfig/vncservers и внесите в него следующее, см. Рисунок 1:
VNCSERVERS="1:user2"
VNCSERVERARGS[1]="-geometry 1024x768"
Где, user2 имя пользователя, который может соединяться по VNC.
А цифра обозначает порт подключения сервера, который исчисляется после порта 5900, на котором по-умолчанию функционирует сервер VNC.
Допускается указывать несколько пользователей, например:
VNCSERVERS="1:user2 2:user3 3:user4]"
и т.д.
И где
VNCSERVERARGS[1]="-geometry 1024x768"
Это желаемое разрешение экрана для каждого пользователя.
Допускается использовать разное разрешение для каждого пользователя, например:
VNCSERVERARGS[1]="-geometry 1024x768"
VNCSERVERARGS[2]="-geometry 800x600"
VNCSERVERARGS[3]="-geometry 1280x1024"
- 4. После этого установите службу VNC сервера в качестве запускаемой по-умолчанию и запустите сервер:
chkconfig vncserver on
/etc/init.d/vncserver start
/etc/init.d/vncserver status Xvnc (pid 3130 выполняется...)
- 5. Теперь можно подключаться клиентом.
Нажмите на кнопку Rocket Bar (Пуск) и выбирайте Приложения, а затем запустите программу KRDC (Клиент удаленного рабочего стола для KDE). Смотрите конфигурацию клиента на Рисунке 2 и Рисунке 3:
Затем укажите в программе адрес и порт сервера, как на Рисунке 4.
В примере на Рисунке 4 указывается адрес 192.168.231.118:5901, содержащий сетевой порт 5901.
Соответственно для первого клиента на сервере по-умолчанию используется порт 5901, для второго 5902, и т.д.
Пример запущенного клиента смотрите на Рисунке 5.
Проброс USB устройства из материнской хост-системы внутрь виртуальной машины под управлением Rosa Virtualization (oVirt 3.5)
В данной статье мы рассмотрим типовую ситуацию, когда требуется обеспечить доступность USB устройства для виртуальной машины, работающей под управлением Rosa Virtualization (oVirt 3.5).
- Эта задача может возникнуть если требуется развернуть в виртуальной машине, скажем, сервер «1С Бухгалтерия», и обеспечить доступность для клиентов HASP ключа.
- Может потребоваться подключить USB Flash накопитель для ВМ, или подключить к ней USB диск.
- Может потребоваться подключить к ВМ принтер или USB модем.
Или мало ли что еще.
Прежде чем я начну описывать процесс, требуется сперва помнить о ряде важных ограничений:
- Виртуальная машина, которая будет обслуживать USB устройство должна будет жестко закреплена к хост-системе, на которой вставлено USB устройство.
- USB устройство должно быть установлено в порт хост-системы ДО того, как будет запущена соответствующая виртуальная машина.
- В случае, если это USB флэш-накопитель, и он уже смонтирован в хост-системе, то при «пробросе» устройства в ВМ и монтировании внутри ВМ, содержимое диска будет недоступно в хост-системе.
- В свойствах ВМ в разделе Консоль ("Console") необходимо использовать подключение по протоколу SPICE, с VNC протоколом это не поддерживается. Кроме того, поддержка USB не должна быть отключена (Disable). Мы рекомендуем поддержку USB устанавливать в штатный режим "Native".
- Функциональность USB устройств с интерфейсом USB 3.0 нами не проверялась, ввиду отсутствия на наши серверах аппаратной поддержки USB 3.0.
В моем примере я использую обычную USB флешку, размером 8 GB, отформатированную в FAT32, установленную в хост-систему и смонтированную там в каталог /mnt
Хост-система носит название hammer2 (см. Снимок 2).
Виртуальная машина, на которую я делаю проброс флешки называется rels67_min (ip — 192.168.231.108, FQDN — rels76minimal).
Собственно настройка (потребуются полномочия суперпользователя root либо sudo):
1. Подключите USB устройство в желаемую хост-систему (в мооем случае узел hammer2)
2. Установите на нужную ноду (в моем случае — это хост-система hammer2), и на управляющую систему oVirt (в моем случае это система с названием head) пакет vdsm-hook-hostusb:
yum install vdsm-hook-hostusb
3. На управляющей системе oVirt выполните команду:
engine-config -s UserDefinedVMProperties='hostusb=[\w:&]+'
После этого, система предложит выбор соответствующей версии oVirt.
В моем случае, я выбрал версию 3.5, нажав на клавиатуре цифру шесть.
4. Перестартуйте систему управления oVirt командой на управляющей системе:
/etc/init.d/ovirt-engine restart
5. Перестартуйте интерфейс управления oVirt на управляемой хост-системе (в моем случае на узле hammer2, куда подключен накопитель):
/etc/init.d/vdsmd restart
6. На хост-системе с USB устройством проверьте, что устройство подключено и опозналось верно:
lsusb
(если команда lsusb не доступна установите пакет usbutils: yum install usbutils)
В моем случае, устройство опозналось как:
Bus 001 Device 004: ID 8564:1000 Transcend Information, Inc. JetFlash
См. Снимок 1.
7. Зайдите в свойства желаемой ВМ, нажав ПКМ и выбрав Edit в меню. ВМ при этом должна быть выключена.
Закрепите ВМ за нужным узлом (как на Снимке 3, выбран узел hammer2)
8. В меню Custom Properties у вас появится новый пункт в разделе Please select a key Выбирайте там hostusb и прописывайте там ID USB устройства, указав перед идентификатором 0x. То есть в моем случае я прописываю 0x8564:0x1000
См. Снимок 4
9. Запустите ВМ штатным способом, подключитесь либо к ней в консоль, либо по SSH и проверьте доступность USB устройства:
lsusb
Смотрите Снимок 1.
Теперь устройство USB можно смонтировать внутри ВМ.
Проверка контрольных сумм образов ROSA Desktop с помощью Checkisomd5
Большинство пользователей для установки РОСЫ скачивает ISO-образ с наших сайтов и дальше либо производит установку непосредственно с этого образа, либо записывает его на флешку (или на DVD-диск — этот способ особенно актуален для сертифицированных версий). К сожалению, несмотря на всяческий рост распространения Интернета, его скорости и качества, иногда при закачке образов случаются-таки ошибки, скачанный файл оказывается «битым» и установка с него невозможна.
Для проверки целостности скачанных файлов традиционно применяется вычисление их контрольной суммы и сравнение её с заданным результатом. Обычно это отдельный файл с расширением .md5, .sha1 и так далее — смотря какой алгоритм используется. Для проверки целостности требуется скачать этот файл, запустить программу подсчета контрольной суммы, например md5sum ROSA.iso и сравнить результаты. Некоторые программы могут делать это автоматически и даже сравнить контрольную сумму с эталоном, если обнаружат рядом с образом md5-файл.
Как показывает практика, далеко не все пользователи знают, что помимо традиционного пути, контрольная сумма ISO-образа может быть встроена непосредственно в ISO-файл. Дело в том, что файлы формата ISO9660 содержат неиспользуемую секцию, размера которой вполне достаточно для помещения туда MD5-суммы. Осуществить такое встраивание MD5 в файл может утилита implantisomd5, входящая в набор программ isomd5sum, а проверить соответствие содержимого образа встроенной в него контрольной сумме поможет утилита checkisomd5 из того же пакета.
Делается это так, сначала утилита вычисляет MD5-сумму, затем внедряет её в образ-диска ROSA.iso + MD5. Далее на зеркало выкладываются файлы md5sum = ROSA.iso + MD5 и sha1sum = ROSA.iso + MD5 . У пользователя есть выбор, проверять контрольную сумму командой checkisomd5 или md5sum, sha1sum. Но имейте ввиду, checkisomd5 проверяет внедрённую MD5-сумму и она не равна md5sum, sha1sum, ибо они проверяют уже общую сумму ROSA.iso + MD5.
Уже довольно долгое время встраивание контрольной суммы с помощью implantisomd5 осуществляется во все образы ROSA Desktop Fresh, поэтому проверить их целостность вы можете одной простой командой:
[имя_юзера@rosa2021 ~/Загрузки]$ checkisomd5 ROSA.iso Нажмите [Esc], чтобы прервать проверку. Проверка носителя завершена, результат: PASS (ПРОЙДЕН). Использовать этот носитель можно.
У команды есть опции: « --verbose », которая выводит полную информацию о ходе проверки на целостность образа, в том числе и его MD5-сумму, внедрённую в него, « --gauge », с индикацией процесса в виде цифр от 1 до 100, а также « --md5sumonly », покажет только MD5-сумму данного образа, не делая проверку на целостность.
Утилита checkisomd5 работает не только с ISO-образами, но и с блочными устройствами — например, если в ваш DVD-привод вставлен диск с РОСОЙ, то запустите команду checkisomd5 на /dev/dvdrw.
Для проверки с помощью md5sum, sha1sum потребуется скачать не только образ.iso, но и файл .md5sum, или .sha1sum в один каталог, например "Загрузки", команда запускается именно оттуда, для перехода в него cd ~/Загрузки, далее:
[имя_юзера@rosa2021 ~/Загрузки]$ md5sum -c ROSA.md5sum ROSA.iso: ЦЕЛ
Из сравнения видно, что проверка образа командой checkisomd5 ROSA.iso проще и быстрее.
Настоятельно рекомендуем производить проверку скачанных образов перед их использованием. Процесс этот недолгий, cэкономит вам много времени, предотвращая неудачную попытку установки с испорченного образа и длительное выяснение причин.
Подобная, но краткая статья: Проверка целостности ISO образа.
Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе RELS 6.6
Большая часть наших статей в «Точке Росы» была посвящена нашим десктопным системам. Однако в последнее время мы более активно стараемся развивать и серверное направление. В связи с чем в августе нами была обучена группа специалистов одного очень известного и уважаемого системного интегратора.
Народ в группу подобрался крайне квалифицированный, и мы с удовольствием подтвердили классификацию проходивших обучение специалистов нашим сертификатом.
И мы были рады, когда один из наших слушателей, Черятников Виталий, написал цикл статей «Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6» ([1], [2], [3], [4]).
C некоторыми правками, перепубликуем их и тут, одной статьей.
Материал в изложении Виталия преподнесен крайне интересно и правильно. Нам практически нечего к этому материалу добавить, настолько все толково изложено. Спасибо Виталию большое, за то, что он нашел время, написал и опубликовал данный цикл статей.
Об использовании URL в метаданных RPM-пакетов
Как вы наверняка знаете, все программы в ROSA Linux распространяются в виде RPM-пакетов, включающих в себя архив с собственно файлами программы (скомпилированными исполнимыми файлами и библиотеками, данными и прочим добром), а также некоторые метаданные — имя пакета, его опиcание, зависимости и многое другое. В этой заметке мы остановимся на полях метаданных, содержащих ссылки на внешние ресурсы в сети Интернет.
В первую очередь это поле URL — ссылка на домашнюю страницу приложения, которую вы можете видеть при просмотре информации в менеджере пакетов. Кроме того, в spec-файлах (инструкциях для программы rpmbuild по сборке пакетов из исходного кода) большинства пакетов часто указывается ссылка на исходный код в апстриме, например:
Source0: http://my-app.org/downloads/my-app-1.0.tar.gz
Чем полезны ссылки в таких полях и почему бы просто не указать имя архива с исходным кодом? Исконная причина заключается скорее всего в том, чтобы предоставить разработчику удобный способ скачать архив с той или иной версией программы — ведь знать домашнюю страничку — это хорошо, но нередко на этой страничке надо покопаться, чтобы добраться до архивов с исходным кодом. Если же ссылка уже указана в spec-файле, то для скачивания новой версии программы достаточно поменять my-app-1.0.tar.gz на my-app-2.0.tar.gz и скормить ссылку менеджеру закачек. Когда-то давно это надо было делать вручную, сейчас же наш rpmbuild способен сам скачивать файлы из интернета — так что для сборки новой версии программы вам достаточно поменять значение версии в spec-файле и запустить rpmbuild, все остальное будет сделано для вас автоматически.
Еще один используемый в РОСЕ инструмент, использующий данные о ссылках на исходный код — это Updates Tracker. Именно на основе анализа ссылок в spec-файлах этот инструмент определяет, где надо искать новые версии тех или иных программ.
Таким образом, ссылки на внешние источники в spec-файлах полезны и активно используются. Однако как и любые интернет-ресурсы, эти источники иногда меняют свое местоположение, а то и вовсе исчезают. Мэйнтейнерам пакетов необходимо отлавливать такие метаморфозы и соответсвующим образом обновлять метаданные, иначе пользователи будут отсылаться на несуществующие домашние страницы приложений, а Updates Tracker искать новые версии там, где их ожидать уже не стоит.
Для популярных пакетов, находящихся под пристальным вниманием мэйнтейнеров и регулярно обновляющихся, такой мониторинг происходит фактически в ручном режиме. Но в наших репозиториях немало пакетов, обновления которых выходят редко, либо которые нужны очень небольшому количеству пользователей и по этой причине не удостаиваются частого взгляда мэйнтейнера. К тому же ручное обновление метаданных имеет все недостатки, связанные с выполнением рутинных задач человеком — можно опечататься, что-то перепутать, забыть что-то обновить либо просто оставить старую информацию по причине лени или нехватки времени.
Способ борьбы с этими проблемами известен и заключается в автоматизации того, что ей хорошо поддается. А мониторинг актуальности ссылок и их обновление в эту категорию, безусловно, попадает. Впрочем, для работы с пакетами нам не нужны сложные веб-краулеры или трекеры сайтов — вместо этого, нам хотелось бы иметь специализированный инструментарий, способный находить мертвые ссылки в наших spec-файлах и по возможности заменять их на актуальные.
Способ написания подобных инструментов нам тоже хорошо известен — в этом году мы вновь воспользовались возможностью привлечь студентов НИУ ВШЭ к выполнению полезных задач в рамках прохождения практики, в результате чего получили две утилиты — первая проверяет актуальность ссылок в заданном наборе spec-файлов, а вторая пробует угадать новую ссылку, если старая потеряла актуальность.
Первая утилита — find_dead_links — действует прямолинейно, извлекая из spec-файлов все ссылки на внешние источники и проверяя их доступность (просто пытаясь к ним достучаться). На выходе получается список нерабочих ссылок для каждого пакета.
Вторая программа — URLFixer — принимает на вход вывод find_dead_links и проводит его анализ, пытаясь определить — куда мог переехать тот или иной ресурс. Переезд домашних страниц на другие дислокации эта программа пока отловить неспособна (хотя с развитием поисковых систем эта задача не кажется такой уж нерешаемой), а вот с переездом архивов с исходным кодом вполне может справиться. Как показала практика, поломка ссылок на такие архивы часто вызвана довольно прозаическими причинами — например, разработчики могли удалить конкретную версию программы (заменив ее на более новую — в этом случае имеем явный сигнал мэйнтейнерам к обновлению пакета) или перепаковать архив в другой формат (в последнее время стало популярным переходить на использование xz). check_url проверяет, не произошел ли со сломавшейся ссылкой один из этих сценариев и пытается определить, на что следует заменить битую ссылку.
Казалось бы, в этих программах нет ничего сверхестественного (и их сложность вполне соответсвует двухнедельным усилиям пары студентов, практически не имевших опыта работы с Linux), но опыт их применения к репозиториям ROSA Desktop Fresh оказался впечатляющим — выяснилось, что некорректные ссылки содержались примерно в 500 пакетах (подавляющая часть которых находится в репозитори Contrib), а с помощью URLFixer удалось исправить около 80 % из них.
Наша база оборудования — самая большая в мире
У Росы меньше разработчиков, чем у международных конкурентов, поэтому нам приходится проявлять особую сообразительность и смекалку. Помимо роботов, которые автоматически производят тестирование пакетов и обновление пакетов прямо из апстрима, а также осуществляют установку, загрузку и тестирование новых образов, у нас еще есть и автоматически наполняемая сообществом база поддерживаемого оборудования. Конечно, на создание роботов, базы и других инструментов потребовалось немало времени и кропотливой работы, а их поддержка сейчас требует ежедневного внимания, но в целом разработка дистрибутива заметно ускорилась.
Месяц назад мы попросили сообщество активнее пополнять базу, чтобы обогнать лидеров рынка, таких как Ubuntu и openSUSE. Откликнулось огромное число наших пользователей и теперь у нас самая большая база поддерживаемого оборудования в мире! Можно сказать, что она и самая технологичная, так как содержит гораздо больше информации об устройствах и компьютерах, чем базы других дистрибутивов и пополняется автоматически при помощи инструмента для снятия проб оборудования.
На 25 августа 2015 размер баз оборудования такой:
| База | Размер |
|---|---|
| РОСА | 1515 |
| Ubuntu | 1105 |
| openSUSE | 946 |
| h-node | 533 |
| Debian | 226 |
Базу Росы составляют теперь 1515 компьютеров и она почти в полтора раза больше, чем у ближайшего конкурента — Ubuntu. Из них 768 — это мобильные компьютеры (ноутбуки и планшеты), 728 — настольные компьютеры и 18 — серверы. Самый старый протестированный компьютер с Росой на борту — Acer TravelMate 420 2002 года выпуска с процессором Pentium 4 (a8af42d6e7). Самый "большой" компьютер с Росой — HP Superdome2 с 15-ядерным процессором Xeon E7-2890 и 2ТБ оперативной памяти (9036136416). Протестировано в целом 1372 видеокарты, 332 WiFi карты и тысячи других устройств.
Наличие такой большой базы устройств позволяет быстрее и системнее исправлять проблемы с отдельными устройствами на компьютерах пользователей, а также выбирать для покупки проверенные на совместимость с Росой модели компьютеров и устройств.
База компьютеров: ноутбуки, десктопы и серверы.
Список протестированных видеокарт.
