Викилоги

Запросов от пользователей на обновление тех или иных программ в дистрибутивах 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 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 в качестве основной для наших настольных систем.

Скачать дистрибутив можно здесь

• 32bit ISO
• 64bit ISO

Минимальные системные требования

• 256 Мб ОЗУ (рекомендуемый объем — 512 Мб, для режима Live рекомендуется 384 Мб).
• Место на жёстком диске: 6 Гб HDD
• Процессор: Pentium4/Celeron

В последние месяцы мы отмечаем рост интереса пользователей к теме виртуализации. В этой статье речь пойдет о системе управления виртуализацией «ROSA Virtualization», базирующейся на продукте с открытым исходным кодом «oVirt» (www.ovirt.org).

Сейчас мы осуществляем его перевод на русский язык, занимаемся написанием документации и модифицируем его с учетом требований нормативной базы по ИБ (согл. Приказам ФСТЭК №№ 17 и 21).

→ продолжить чтение…

В этой статье мы настроим простой сервер 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"

Рисунок 1

Где, 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:

Рисунок 2

Рисунок 3

Затем укажите в программе адрес и порт сервера, как на Рисунке 4.
В примере на Рисунке 4 указывается адрес 192.168.231.118:5901, содержащий сетевой порт 5901.
Соответственно для первого клиента на сервере по-умолчанию используется порт 5901, для второго 5902, и т.д.

Рисунок 4

Пример запущенного клиента смотрите на Рисунке 5.

Рисунок 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).

Снимок-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)

Снимок-3

8. В меню Custom Properties у вас появится новый пункт в разделе Please select a key Выбирайте там hostusb и прописывайте там ID USB устройства, указав перед идентификатором 0x. То есть в моем случае я прописываю 0x8564:0x1000

См. Снимок 4

Снимок-4

9. Запустите ВМ штатным способом, подключитесь либо к ней в консоль, либо по SSH и проверьте доступность USB устройства:

lsusb

Смотрите Снимок 1.

Снимок-1

Теперь устройство USB можно смонтировать внутри ВМ.

Большинство пользователей для установки РОСЫ скачивает 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 на базе ROSA Enterprise Server 6.6» ([1], [2], [3], [4]).

C некоторыми правками, перепубликуем их и тут, одной статьей.

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

→ продолжить чтение…

Как вы наверняка знаете, все программы в 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. Из них 768 — это мобильные компьютеры (ноутбуки и планшеты), 728 — настольные компьютеры и 18 — серверы. Самый старый протестированный компьютер с Росой на борту — Acer TravelMate 420 2002 года выпуска с процессором Pentium 4 (a8af42d6e7). Самый "большой" компьютер с Росой — HP Superdome2 с 15-ядерным процессором Xeon E7-2890 и 2ТБ оперативной памяти (9036136416). Протестировано в целом 1372 видеокарты, 332 WiFi карты и тысячи других устройств.

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

• 

  База компьютеров: ноутбуки, десктопы и серверы.

• 

  Список протестированных видеокарт.

• 

  База многофункциональных устройств.

Поздравляем всех с Днем Сисадмина!

Опустим пафосную часть про важность и нужность этой профессии, ведь, думаю, не ошибёмся, что все, кто нас читает — причастны к хардкорному IT, это наш общий праздник, посторонних тут нет.

По всей стране сейчас идут разные слеты сисадминов на природе, в прошлом году мы даже ездили под Калугу развлекать сисадминов своими выступлениями, а в этом году мы ездили в глухие белорусские леса, чтобы порадовать всех хардкорных линуксоидов записями докладов с Linux Vacation Eastern Europe-2015.

О самом мероприятии можно почитать на хабре, ну, а три десятка докладов уже ждут зрителей!

Своя база поддерживаемого оборудования есть у многих дистрибутивов Linux. Наличие такой базы помогает пользователям настраивать систему на своих компьютерах, а разработчикам позволяет быстрее исправлять ошибки связанные с оборудованием. Самые большие базы у Debian, Ubuntu, openSUSE и РОСА. Также представляет интерес и проект h-node — база оборудования, совместимого с полностью свободными ОС.

Подход к реализации базы у всех разный. У Debian и openSUSE — это наполняемый сообществом и разработчиками Wiki-портал. У Ubuntu и РОСА — это автоматически наполняемый сайт собственной разработки. При этом база данных РОСЫ — это полностью независимая разработка с уникальной архитектурой, основанной на понятии пробы оборудования. Проба оборудования — это снимок состояния оборудования компьютера, включающий помимо списка устройств и их статусов еще и набор системных журналов и результаты тестов работоспособности. Это позволяет зафиксировать состояние компьютера в момент возникновения проблемы и проанализировать причину ее возникновения по системным журналам. Также это позволяет проанализировать правильность работы найденных на компьютере устройств.

На 25 июля 2015 года размер этих баз оборудования следующий (по количеству компьютеров):

Как можно заметить, у Ubuntu на сегодняшний день самая большая база — 1087 компьютеров. Это не удивительно, так как пока это самая популярная международная система. У РОСЫ же — 789 компьютеров. Отрыв от лидера не такой уж и большой. Поэтому мы призываем всех пользователей РОСЫ сделать пробы своих компьютеров. Если каждый пользователь РОСЫ сделает пробу собственного компьютера, то база РОСЫ будет не только самой технологичной, но и самой большой базой в мире. В РОСА R6 пробу теперь можно сделать легко с помощью встроенного приложения "Проба оборудования".

Давайте общими усилиями станем лучшими в мире Linux!

• 

  Приложение для создания пробы компьютера включено в РОСА R6.

• 

  База компьютеров: ноутбуки, десктопы и серверы.

• 

  База периферийного оборудования.

Недавно мы протестировали огромное количество различных МФУ, принтеров и сканеров в офисах HP и Xerox, которые любезно предоставили нам свое оборудование. Каждое устройство тщательно тестировалось под управлением нескольких версий операционной системы РОСА (DX32 Nickel 1.0, DX32 Nickel 2.0, DX64 Nickel 2.0, RED X2 и Desktop Fresh R5). Главным образом тестировалось качество печати на драйвере по умолчанию. Если на драйвере по умолчанию устройство не функционировало, то подбирался подходящий драйвер. Для некоторых устройств требовался проприетарный драйвер с сайта производителя.

Для записи результатов тестирования мы создали специальный подраздел нашей базы оборудования для периферийных устройств: hw.rosalinux.ru/mfp/. В записи для каждого устройства вы можете найти информацию о протестированном драйвере, версии системы, качестве печати и другие комментарии по настройке устройства. Теперь при покупке МФУ, принтера или сканера для использования под управлением ОС РОСА вы можете смело руководствоваться этой базой данных.

В будущем планируется также посещение офисов Epson, Brother, Samsung и Canon.

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• ...

Мы выпустили новую версию 0.9.2 нашего инструмента HW Probe для сбора информации об оборудовании и системных журналов.

→ продолжить чтение…

Недавно вышла версия 1.0 системы RaceHound для поиска «состояний гонки» при обращениях к данным в ядре Linux.

Если говорить простым языком, такие «состояния гонки» — это когда к данной области памяти разные потоки выполнения в программе (или, скажем, в ядре) могут обращаться одновременно, причём хотя бы один из потоков выполнения меняет содержимое этой области памяти. Такие ситуации могут приводить к очень неприятным последствиям, но выявить их бывает очень непросто.

В этом, например, может помочь инструмент KernelStrider. Он находит много потенциальных «гонок», но у него могут быть и ложные срабатывания, то есть бывает, что он сообщает о «гонке», которой нет.

RaceHound же, наоборот, может многое «не заметить», но если он выявил «гонку» — та, действительно, происходит. Кстати, эти инструменты хорошо работают в паре: KernelStrider выявляет потенциальные «гонки», а RaceHound проверяет, действительно ли эти «гонки» происходят.

В частности, таким образом удалось недавно выявить интересную «гонку» в драйвере «uvcvideo» (работа с web-камерой) из ядра 4.1-rc5. Правда, разработчики этого драйвера уверяют, что ничего страшного из-за этой гонки произойти не может, но всё же.

Принцип работы RaceHound очень прост.

• Ставим программную точку прерывания, ПТП, (наподобие того, как это делают отладчики) на те инструкции в коде, которые могут участвовать в «гонке».
• Когда какая-то из ПТП срабатывает, выясняем, к каким данным в памяти соотв. инструкция собирается обратиться, то есть находим их адрес и размер.
• Ставим аппаратные точки прерывания на эту область памяти.
• Делаем небольшую задержку. Если в это время кто-то обратится к этой области памяти, аппаратные точки прерывания сработают — «гонка» выявлена.
• Убираем аппаратные точки прерывания, затем даём возможность той инструкции, для которой выше сработала ПТП, выполняться дальше.

Разумеется, «дьявол — в деталях» и реализовать такой алгоритм на практике оказалось очень и очень непросто. Не зря работа над RaceHound ведётся с лета 2012 года.

По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания.

Кстати, при подготовке этой версии была найдена и исправлена ошибка в механизме работы с точками прерывания (точнее, с т. н. Kprobes) в самом ядре. Исправление должно войти в версию ядра 4.1.

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

Теперь при создании пробы компьютера вы можете дополнительно передать его фотографию или фотографии отдельных устройств (видеокарты, материнские платы, принтеры и т.д.) и мы непременно добавим их в базу. Сделать это можно в специальной теме на нашем форуме или в социальной сети ВКонтакте. Загружайте только сделанные вами лично фотографии.

Фотография устройства будет отображаться только на странице этого устройства (пример: диск SanDisk SSD U110 16GB). Фотография же компьютера будет отображаться не только на странице этого компьютера, но и во всех его пробах (пример: ноутбук ASUS A3L).

Помимо множества ноутбуков и десктопов с разнообразными конфигурациями в нашей тестовой лаборатории есть еще и склад отдельных компонентов (видеокарты, мониторы, сетевые карты и т.д.), которые мы тестируем отдельно на тестовых стендах. Некоторое время назад склад пополнился пакетом из нескольких сот разнообразных WiFi карт. И, наконец, мы закончили тестирование этих карт.

Изначально тестирование было начато еще на старой платформе R3 и затем продолжено на R5. Большую часть карт составляли карты формфактора Mini PCI-E и Mini PCI-E Half-Size, но был и десяток старых Mini PCI. После классификации и выявления дубликатов был составлен каталог из 69 различных моделей карт. Производителями карт были: Atheros (30), Broadcom (21), Realtek (9), Intel (6) и Ralink (3). Тестирование производилось на двух наших тестовых стендах (1, 2) с помощью специальных переходников для таких карт на порты PCI-E и PCI соответственно.

Надо понимать, что 69 протестированных карт - это несколько сот (а может и тысяч) охваченных моделей ноутбуков, в которых эти карты используются, так как одна и та же карта может использоваться в нескольких десятках разных ноутбуков различных производителей.

В результате тестирования было выявлено и исправлено с десяток проблем. Все проблемные карты были отмечены в нашей базе данных оборудования. Большой вклад в тестирование WiFi карт внесли и наши пользователи, которые сделали пробы своих компьютеров. Ими было протестировано еще 165 различных моделей карт.

Самая популярный производитель WiFi карт на компьютерах наших пользователей — Atheros (AR9285 и AR9485). За ними идут, по убыванию популярности, Broadcom, Intel, Realtek и Ralink. Самые беспроблемные карты — Atheros и Intel. Больше всего проблем было выявлено с картами Broadcom. Для некоторых карт Realtek (например, RTL8723BE) нужно обновить ядро.

Найти нужную WiFi карту или любое другое интересующее вас устройство и посмотреть его статус поддержки можно с помощью поиска. Но лучше сделать пробу вашего компьютера и перейти на страницу карты из списка устройств в пробе. Так заодно можно проверить и другие устройства на компьютере.

• 

  WiFi карты

• 

  Тестовый стенд

• 

  Адаптеры на PCI-E и PCI

• 

  Каталог карт

Пришло время для очередного дайджеста «Точки РОСЫ», ведь с момента предыдущего прошел уже год.

Да, в прошлом выпуске мы спрашивали, с какой периодичностью выпускать наш журнал-дайджест, и там лидировали варианты «еженедельно» и «ежемесячно». Но, понятное дело, это неразумно — ведь за неделю у нас может и вовсе не быть ни одной новости, хотя может и несколько — ну для этого у нас есть и этот блог, на который можно подписаться и классически — по RSS/Atom, или через социальные сети — VK, FB, недавно заведенная официальная страница компании в G+ и давно самозародившееся неофициальное сообщество в G+.

А дайджесты и PDF-сборки статей интересны наверное тем, кто не сильно заинтересован в нашей работе, но изредка готов, без лишних переходов по гиперссылкам, возможно даже от отчаяния (интернета нет, но есть недочитанный PDF-файл), полистать его, чтобы ознакомится с нашей работой, и сложно сказать, с какой частотой их надо выпускать… но наверняка, о должен содержать не меньше десятка статей, с другой стороны, если больше ста страниц, то наверняка уже можно.

Исторически, именно PDF-файлами мы начинали публиковать «Точку Росы» на опеннете и ЛОРе, но с публикацией в там есть некоторые проблемы: почему-то начинается обсуждение, касающееся чего угодно — обложки, личного мнения о сотрудниках и нашей работе, о политике… обо всем, кроме собственно, содержания. Поэтому мы там точно не очень хотим там часто «светиться», чтобы не надоедать, и не раздражать собравшуюся публику.

Впрочем, наверно надо разделять вопрос о нужности PDF-дайджестов и публикации на ЛОР и opennet. Наверное, надо спросить именно об этом:

Нужно ли публиковать изредка (год/полгода) сборки «Точки РОСЫ» на LORe

Нужно ли публиковать изредка (год/полгода) сборки «Точки РОСЫ» на OpenNet-е.

Итак, перейдем собственно к журналу. Как обычно, это будет и вебжурнал в формате «подборка статей с обложкой», так и так и в олдскульном PDF-файле c сотней страниц.

В любом случае — «многобукф», 250K знаков, почти две сотни страниц.

Итак, в десятом выпуске «Точки РОСЫ»:

→ продолжить чтение…

В статье про групповые политики для Chromium в Linux мы упомянули, что json-файлы с политиками Chromium можно распространить по большому количеству машин с помощью программ управления конфигурацией типа Puppet или CFEngine. Но многие сисадмины считают эти программы слишком монструозными для подобных задач и предпочитают раздачу файлов по старому доброму SSH. Однако чтобы раздать файл множеству машин, придется уже написать небольшой скрипт на Shell. А поскольку раздача файлов — явно не единственная задача, которую захочется выполнить таким образом, то со временем у вас накопится куча Shell-скриптов, которая имеет тенденцию превращаться в свалку.

К счастью, имеются инструменты для более изящного использования SSH при выполнении задач на всех подвластных машинах. Одно из таких средств — это Rex. Никаких агентов на клиентских машинах, никаких сложных настроек — просто скрипты, выполняющие задаче на множестве компьютеров. Скрипты пишутся на языке Perl, но знать этот язык для выполнения большинства операций не обязательно. Rex предоставляет богатую библиотеку функций для выполнения типичных задач (копирования файлов, получения информации о системе и так далее), так что обычно скрипты умещаются в десяток строчек.

В этом году Rex перевалил за версию 1.0 и считается теперь вполне стабильным и надежным. А начиная с релиза 0.55.0, Rex официально поддерживает РОСУ (не без нашей помощи — в свое время мы делали обзор Rex для журнала «Системный администратор», было бы странно при этом не добавить в Rex поддержку наших дистрибутивов).

В ROSA Desktop Fresh пакет Rex уже есть в репозиториях и можно его установить через urpmi:

# urpmi Rex

А самую свежую версию всегда можно установить с сайта разработчика в одну команду:

# curl -L get.rexify.org | perl - --sudo -n Rex

Для совсем простых задач можно даже не писать скрипты, а командовать Rex прямо из консоли. Например, вот так можно скопировать файл test_policy.json в директорию /etc/chromium/policies/managed на машинах с именами client0, client1, … client10:

# rex -H client[0..10] -e 'upload "test_policy.json", "/etc/chromium/policies/managed"'

Поскольку Rex общается с клиентскими машинами по SSH, то на каждой машине должен быть запущен SSH-сервер, а программе необходимо передать логин и пароль для доступа (а лучше использовать авторизацию по ключу, чтобы не вводить пароль каждый раз).

Можно описывать задачи в скриптах. Например, создадим файл следующего содержания и назовем его Rexfile (Rex по умолчанию ищет файл с таким именем в текущей директории, так что можно его не указывать в параметрах вызова):

 user "your_user";
 password "your_password";
 
 task "get_os", "localhost", sub {
    say get_operating_system();
 };

Здесь мы определили задачу get_os, которая будет выполняться на нашей локальной машине («localhost») и будет печатать нам имя операционной системы. В начале файлы необходимо задать имя и пароль (либо ключ) для доступа к целевым машинам.

Теперь запустим Rex, приказав ему выполнить задачу get_os (и подавив вывод излишней информации с помощью опции -q):

$ rex -q get_os
RosaDesktopEnterprise

Как видим, в качестве имени ОС Rex извлек значение DISTRIB_ID из файла /etc/lsb-release (которое также можно получить, выполнив команду lsb_release -i).

В одном файле можно описывать несколько задач, а каждую задачу можно ассоциировать с множеством машин. Вовсе не обязательно ограничиваться копированием файлов и «игрушечными» задачами. Возможностей у Rex довольно много — можно управлять пакетами, сервисами, всевозможными настройками клиентских машин, проводить инвентаризацию оборудования и даже управлять облаками. Познакомиться со всеми этими возможностями можно разделе документации на сайте разработчика. Но учтите — в отличие от простых задач, более сложные могут потребовать написания более сложных скриптов на Perl, так что перлоненавистникам этот подход вряд ли понравится.

Представляем ROSA Enterprise Desktop X2 — новую версию операционной системы для корпоративного сектора. В состав дистрибутива входит прикладное программное обеспечение, решающее большинство типовых задач: многофункциональный офисный пакет, интернет-браузер, программы для работы с электронной почтой, обмена мгновенными сообщениями, просмотра и редактирования аудио- и видеофайлов и многое другое.

Дистрибутив основан на ROSA Desktop Fresh KDE, но предоставляет дополнительные гарантии стабильности — обновления, не являющиеся исправлениями уязвимостей и критических ошибок, попадают в ROSA Enterprise Desktop X2 только после тщательного тестирования и «обкатки» в ROSA Desktop Fresh.

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

→ продолжить чтение…

В ближайшую субботу в Питере пройдет ProfsoUX-2015 — динамичная конференция по юзабилити, UX (User eXperience), всем остальным смежным темам — проектной и продуктовой аналитике, тестированию и геймификации использования, крутым инструментам и эффективным процессам для всего этого.

Организуют конференцию сами эксперты из индустрии, т.е. там нет занудных академических докладов, дипломов студентов — только практика, только хардкор, только состоявшиеся профессионалы, рассказывают о самом bleeding edge дизайнерских трендов, новых, неведомых интерфейсов взаимодействия, живодерских методов экспериментов над пользователями и другими вкусными вещами.

Доклады будут хорошо подготовлены — там многоуровневый отбор, удаленное рецензирование материалов и аудирование докладчиков, фигни быть не должно. Ну, по крайней мере, ее точно будет мало. Организаторы решили улучшить качество, даже по сравнению с прошлыми годами — а оно и так было вполне отличным.

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

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

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

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

Мы, команда «РОСы», традиционно выступаем информационным партнером, снимаем видео докладов и публикуем обзоры конференции, так что если вы почему-то не в курсе — немедленно читайте:

• Blog:Точка_Росы/Обзор_юзабилити-конференции_ProfsoUX-2014
• Blog:Точка_Росы/ProfsoUX — юзабилити-конференция в SPB. Обзор ProfsoUX-2013, приглашение на ProfsoUX-2014

или сразу смотрите записи 2014 и 2013 годов.

Ну или хотя бы просмотрите пару-минутный ролик:

Что же касается нас, то от «НТЦ ИТ РОСА» будет несколько сотрудников UX Team, будет Стас Фомин — и нас тоже можно отловить нас можно отловить, и поговорить про развитие наших дистрибутивов и продуктов.

Как уже говорил, будем снимать видео, и может быть (как фишка ляжет), будет некоторая трансляция. Но не факт. И возможны совершенно разные факапы, так что если очень настроены что-то посмотреть — смотрите лично, ловите докладчика, задавайте вопросы.

Ну, а если совсем не можете быть в Питере, ну типа никак — ОК, тогда смотрите сотню докладов по юзабилити с разных конференций, с прошлых лет — и если у вас возникают интересные мысли, по просмотру доклада — не важно, критика или позитив, запишите их там в комментарии. Ведь темы практически не устаревают, очень хотелось бы, чтобы жизнь доклада продолжалась после конференции.

Update

Конференция прошла на ура, отличные доклады, дружелюбная атмосфера, wish you were here.

Мы уже обработали и опубликовали видео.

Вот обзорный ролик на пару минут:

А семь часов видеозаписей докладов — тут.