Red Hat Forum | Munich

В этот вторник, 15.01, в Мюнхене прошел Red Hat Forum. Я не стал пропускать эту однодневную конференцию по нескольким причинам. Во-первых, интересно было узнать что-то новое по поводу покупки “красной шляпы” IBM. Во-вторых, тут предоставлялась возможность крупным клиентам RedHat поделиться своим опытом и рассказать об успешних проектах, реализованных на этой системе. В-третьих, конференция содержала несколько достаточно интересных технических докладов о OpenShift, Kubernetes, контейнерах и вообще cloud-технлогиях и экосистеме.

Я помню, что еще лет 10 назад, когда я работал в SUSE, cloud не был такой горячей темой. Бум cloud-технологий произошел уже после. С тех пор, естественно, многое изменилось на рынке труда и технологиях, используемых в самих GNU/Linux системах. Уже сейчас, спустя каких-то 10 лет, я чувствую, что бежать за технологиями, притом не просто учить новое, но именно переучиваться, надо уметь все быстрей и быстрей.

На конференции был стенд и Microsoft. После того как в 2014 году их генеральным директорм стал Сатья Наделла, политика этой компании стала кардинально меняться. В лучшую сторону. То, что открытая модель разработки победила, сегодня уже понятно абсолютно всем, и даже Microsoft не является тут исключением. В прошлом году мне, как Linux разработчику, предлагали remote работу в ирландском отделении этой компании. Я отказался. И не потому, что не хочу remote, когда у меня трое детей дома, и не потому, что Microsoft был нашим главным конкурентом в 90е и 2000е, но потому, что несмотря на изменение своей политики, основные продукты остаются закрытыми. Понятно, что такой крупной компании очень тяжело перевести все на новые рельсы, но это… это не моя проблема 🙂

Одним из клиентов RedHat является Landeshauptstadt München. Было приятно встретить бывших коллег из LiMux Team. Но LiMux, как всем известно, основан на Kubuntu, а вот RHEL используется как основная ОС для инфраструктуры гос.учреждений в столице Баварии. И если LiMux-проект закрывается в конце следующего года, то с RedHat-серверов никто слазить у нас тут в городе не собирается. Напротив, полным ходом идет повсеместное внедрение контейнеров и cloud-технологий.

Что я могу сказать на последок? По поводу IBM ничего конкретного узнать мне не удалось. Зато я узнал о новых интересных проектах, используемых в cloud-экосистеме и возможностях, предоставляемые ими. Познакомился с новыми людьми, получил приглашение на работу и кучу geek-футболок 🙂 Конференция дала заряд мотивации и интерес к дальнейшему изучению cloud-технологий. В общем, я классно провел день и остался под впечатлением 🙂

The Linux Programming Interface: Russian edition

Случайно заметил в одном из российских интернет-магазинов перевод The Linux Programming Interface Майкла Керриска. Не удержался и сразу же заказал его 🙂
Русское издание по качеству практически не отличается от оригинала. Я уверен, что многие это оценят.
Про английскую версию я писал ранее.
Книга очень классная; пожалуй одна из лучших в моей библиотеке по системному программированию в GNU/Linux (подробно описывается работа с библиотечными функциями/вызовами, нюансы работы с памятью, shared libraries, несколько последних глав посвящены в том числе и сетевому программированию… и многое и многое другое). Книга содержит множество продуманных полнофункциональных программ, доступно иллюстрирующих все теретические концепции и будет очень полезна тем, кто уже хорошо знает язык С и хочет плотнее поработать с операционной системой.
Англоязычное издание этой книги вышло почти 7 лет назад. С тех пор kernel да и glibc претерпели немало изменений. Тем не менее, актуальность материал не утратил. Потому что во-первых, интерфейс API остается практически неизменным, т.е. разработчики его меняют очень осторожно. Причина тому – совместимость программ в userland с новыми версиями glibs и kernel. Во-вторых, изменения вносятся лишь в виде дополнений, но не как не изменений поведения и модификаций уже существующих интерфейсов. Кстати, для тех, кому интересно – вот тут можно посмотреть как менялись API от версии к версии. Занятное чтиво для ботанов %)

FOSDEM 2K18

The Free Open Source Developers European Meeting (FOSDEM) 2018 happened over the weekend. FOSDEM is a fantastic conference where Free Software enthusiasts from all over Europe can meet together at once a year (more than 17000 MAC addresses were registered this time). I really like its clearly unique atmosphere. As usual, 2 amazing days in Brussels, Belgium…

The reason why I visit it again and again. It charges you. When you see all these developers, visit these talks/presentations, have so many conversation with contributors, get innovation ideas that are shared there. It motivates you to get a copy of The Linux Programming Interface & TCP/IP Guide and hack away your amazing Linux software 🙂
Most of the talks were recorded. That’s nice, but by watching it online you just get information, by visiting these talks in person and taking part in discussions, you get much much more.

This time I was there together with my LiMux colleagues from Landeshauptstadt München. By the way, as you maybe know, we’re going to share as much as we can until Munich migrates to Windows (unfortunately, because of bureaucratic reasons making software freely (share it) sometimes is not so easy as we want).

Like in last year FOSDEM was held in so-called “developer rooms”. First I planned to visit devrooms such as debugging tools, DNS/DNSSEC and security + encryption. That was my target when I planned my program. But as I noticed later I was not the only one who had the same plans to visit the same talks, hacking sessions and open discussions 🙂 That led to the free-places-problem in the devrooms and it made my program a bit more dynamic than I planned first 🙂 But get it right – that was absolutely no problem for me. Outside we also had very interesting conversations. I met ex-colleges, friends whom I knew from mailing lists and IRC only and of course a lot of openSUSE contributers.

I would like to thank FOSDEM’s staff, everyone who made it happen, who helped to organize it (I’m definitely going to send a feedback to you guys). Thanks GitHub for free coffee. Keep it going 🙂 I also have to say thanks for openSUSE’s Travel Support Program. It supports me to visit this amazing event (and not for the first time!). I’m going to visit FOSDEM again next year. My photos can be found here. See you next time 😉

GNU Screen v.4.5.0

I’m proud to announce the release of GNU Screen v.4.5. This time it’s mostly a bugfix release. We added just one new feature: now it’s possible to specify logfile name by using parameter -L (default name stays screenlog.0). Myself also spent some time to make source code a bit cleaner.

As you probably noticed we were going to release 4.5 until Christmas. Unfortunately, we could not do it because of some internal GNU problems. I apologise for that.

As usual, we merged some community patches from our bug tracing system (small patches also were presented in IRC) and I would like to thank everyone who contribute to Screen and helps us to test development git-version!

For openSUSE users: I updated our devel-package already. It’s soon in factory and, as usual, after openQA routine new package will be available in Tumbleweed.

Debian Packaging System: Tools and Fundamental Principles

16 августа проект Debian отметил свое 20-летие. Я являюсь большим поклонником этого проекта, и моим скромным подарком для всех русскоязычных пользователей к юбилею стал перевод пятой главы “Настольной книгаи администратора Debian”. Глава повествует о пакетной Debian-системе, инструментах и основных принципах их работы. На данный момент материал актуализирован для Wheezy.

Для меня лично этот проект (перевода) был интересен, потому что я какое-то время работал мейнтейнером в небольшой компании в Гёттингене. В мои обязанности входило создание и поддержка debian-пакетов для ПО, разрабатываемого в стенах компании, включая процесс обновления для всего дистрибутива + поддержка нескольких репозиториев. После переезда в Мюнхен в феврале этого года я больше этим не занимаюсь. Тем не менее, как видете, эта тема мне по-прежднему интересна 😉

Если во время чтения вы найдете опечатки, ошибки или просто корявый перевод, не стесняйтесь сообщить мне об этом (прям тут, в комментариях). Я слежу за обновлениями и с удовольствием учту вашу критику.
Исходники книги можно найти на github.com.

OBS and Jenkins: a bit about continuous integration and packaging

Трудно представить разработку крупного software-проекта без системы непрерывной интеграции. Они являются неотъемлемой частью инфраструктуры любой software-компании. Уже около года я использую параллельно две open source системы: Jenkins и OBS. Являются ли они взаимозаменяемыми, какая для каких проектов больше подходит и на какую стоит обратить внимание, я расскажу в этой небольшой статье. Задача, которую я ставил перед обоими системами, достаточно тривиальна для большинства software-компаний: пересборка новых RPM/DEB-пакетов после svn-/git-коммитов группы разработчиков, и скалыдвание их в определенном порядке в соответствующие репозитории.

Who is who?

Проект Open Build Service (первоначально openSUSE Build Service) был начат в главном отделении SUSE/Novell, как платформа для разработки дистрибутива openSUSE/SLE, и впервые был представлен на FOSDEM в 2006 году. Все компоненты OBS являются Free Software. Проект поддерживают такие организации и компании как Linux Foundation и AMD, а так же имеет большое дружное сообщество. Написан на perl/ruby/python.
Разработка Jenkins (первоначально Hudson) была начата в Sun Microsystems. Проект, как того и стоило ожидать, целиком написан на Java. Распространяется по MIT-лицензии.

OBS представляет из себя абсолютно самодостаточную development-платформу. Развернув её вы получите в свое распоряжение не только систему управления версиями, семантика которой идентична svn/cvs/git, но и репозиторий с новоиспеченными пакетами, который будет автоматически создан/обновлен после каждой удачной сборки. Jenkins в этом плане представляет из себя более модульную систему. Вам придется во-первых настроить svn/cvs/git-хранилище, во-вторых для создания репозитория придется также немного поколдовать (еще одно “shell-правило”). С другой стороны, если проект был создан до установки Jenkins, то это как раз то, что вам нужно, а вот интеграция такого проекта с OBS потребует доустановки специальных дополнений, синхронизирующих его хранилище с svn или git. Для обоих систем есть большое количество плагинов, расширяющих их возможности.

Time of build

OBS собирает пакет в свежем окружении выбранного дистрибутива, учитывая зависимости и архитектуру. Процесс сборки одного пакета длится около 3-5 минут (все это время уходит в основном на установку окружения). Это не гарантирует корректной работы пакета. Pre/Post-скрипты не запускаются, а это значит, что даже если вы успешно пересобрали пакет, он все равно может быть сломаным. К сожаленью, OBS так же не предусматривает добавление тестов, которые должен пройти пакет. Другими словами, стабильность работы пакета полностью ложится на плечи команды QA.
Кстати, изменив один файл в проекте, работая через WebUI, OBS запускает новый build-процесс, потому что воспринимает это как новый коммит (build-процесс запускается автоматически после каждого коммита). Таким образом, если вам надо будет изменить более одного файла, вы постоянно будете обрывать предыдущий build-процесс, начатый после предыдущего коммита автоматически. При сборке RPM это не так критично, но в случае сборки DEB-пакетов, где, к примеру, номер версии пакета находится в двух файлах и должен быть одинаковым, это будет происходить постоянно. Чтобы этого не происходило используйте osc, где у вас есть время подумать после исправления первого файла и перед изменением второго, и лишь после этого сделать коммит.

Jenkins не предоставляет каких-либо специальных вкусняшек для сборки пакетов. Собирать их можно самым обычным образом через dpkg -deb или rpmbuild. У этого метода есть одно преимущество – скорость сборки. На один пакет уйдет паку секунд. Для этого надо просто создать каталог со структурой, который будет иметь пакет. Pre/Post-скрипты так же запущенны не будут, так что удачи при тестировании.
Стоит отметить, что хоть обе системы и не тестирует новоиспеченные пакеты, мы можем добавить целую группу shell-правил (при использовании Jenkins) или просто написать скрипт, используеющий osc (при использовании OBS), так или иначе эмулирующих эти тесты.

Resources

В связи с тем, что OBS является более профессиональной системой, специально заточенной для сборки пакетов, он сначала создает псевдосистему, в которой после и происходит сборка пакета. Это дает незаменимое преимущество при разработке сложных систем, состоящих из группы пакетов (дистрибутивов). Тут, как я писал выше, учитывается и архитекрура, и связи с другими пакетами, которые уже установленны в системе. Как вы понимаете, для развертывания такой системы нужны ресурсы. Для каждой сборки OBS требует один CPU_CORE. К примеру, вам надо собрать два разных пакета для Debian и Ubuntu, для 32- и 64-битной архитекруры. Для параллельной сборки понадобится 8 ядер. Я не знаю точно сколько разработчики советуют использовать RAM для каждой сборки, но по моему наблюдению меньше одного гигабайта на один build-процесс лучше не выделять.
Jenkins не соберет пакет для ARM или PowerPC, он так же не скажет вам, что файл с таким именем создать нельзя, потому что в системе уже существует файл с таким именем, и принадлежит он другому пакету. Если вы занимаетесь разработкой проекта, установка которого никак не влияет на систему (к примеру, не будут измененны/перезаписанны системные файлы), то Jenkins’ом вполне можно обойтись. Это может быть, к примеру, Java-проект, код которого протестирует Jenkins во время сборки, соберет проект, после чего мы получим jar-архивы, и положит эти jar-архивы в пакет. При установке все эти архивы будут просто скопированы в нужный нам каталог. Для сборки такого проекта не нужна псевдосистема, разворачиваемая OBS’ом для каждого пакета, следовательно нам не надо ждать 3-5 минут и тратить на это такие ресурсы. Нам надо просто запаковать наш каталог в deb или rpm-архив. Jenkins сделает это за пару секунд, даже если вы выделите ему всего один гигибайт на все про все.

Conclusion

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

openSUSE :: eGalaxTouch X.Org input driver in Open Build Service

Let’s start by saying that the eGalaxTouch is a X.Org input driver developed by EETI for their touch screens.
Here you can download the suitable driver for your Linux Kernel and architecture. After untar it you will get a directory named eGalaxTouch32 or eGalaxTouch64. Inside this directory you can find a setup.sh script. This complicated script will handle the entire instalaton proccess. It works fine, but the script blasted files and symbolic links all over the filesystem, and there is no way to clean it. As a packager I want to use more professional mechanism to install or remove it. So I built a RPM/DEB packages for that.

How it works?

There are just 4 things that you needed to care about: egalax_drv.so, the binary driver used by the X.Org server; eGalaxTouch, the utility for calibrating and setting preferences; TKCal, a lower level utility for setting options in the hardware; and script also add some information about new configuration to X.Org config-file (I changed it: package create the new config file called /etc/X11/xorg.conf.d/50-egalax.conf).

Section "InputDevice"
        Identifier "EETI"
        Driver "egalax"
        Option "Device" "/dev/ttyS1"
        Option "Parameters" "/var/lib/eeti.param"
        Option "ScreenNo" "0"
EndSection

As you can see I use /dev/ttyS1. EGalaxTouch support S232, USB, PS2, and I2C controllers. So, if you use, for example, USB, you have to change device-string like this:

        Option "Device" "usbauto"

X -version

Here is also one important thing what you have to know: X.Org server and input drivers/modules should have same versions (support same API). EGalaxTouch driver contain modules for different X.Org versions. That means, that package have to check X.Org version during installation to know which input module should be used. I tested package on openSUSE 11.4/12.1 and Ubuntu 10.04 and it looks stable. Anyway, let me know if it will not works for you.

Don’t forget after installing the package and restarting X.Org Server also run eGalaxTouch and TKCal. This will let you calibrate the touchscreen. It takes a bit time to complete, but it increases the precision of the touch position.

Good luck and happy touching 🙂

SIGTERM != SIGKILL

Мы все знаем, что произойдет в UNIX/Linux системе, если мы сделаем

> kill 4055

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

> kill -9 4055

В чем разница? Это очень интересный момент, давайте рассмотрим его поподробнее. Программа kill по умолчанию шлет сигнал SIGTERM. Именно этот сигнал предназначен для завершения процесса, и в штатной ситуации процесс, получивший этот сигнал, завершается (см. man kill). Что именно должен сделать процесс описанно в файле signal.h стандартной библиотеки С.

Learn the UNIX/Linux command line

Знание команд и свободное владение интерпретатором shell всегда говорят о квалификации пользователя. Новички в GNU/Linux неправильно понимают назначение интерпретатора, и относятся к нему как к вынужденной мере, к которой приходится прибегать из-за отсутствия “нормальных” альтернатив. Более квалификацированные пользователи знают, что работа в консоли является самым быстрым и удобным средством для решения целого ряда задач. Не столь требовательный к ресурсам, более стабильный и быстрый… работу в shell хакеры уже давно возвели в ранг культуры и искусства, понятной лишь для своих.

AppStream meeting summary

На одном из обсуждений, которые мы провели на openSUSE Conference, была затронута тема о состоянии ПО для openSUSE. Главными проблемами, названными тогда, были 1) Отсутствие многих пользовательских программм, которые однако есть для других платформ и 2) Сложность установки ПО в openSUSE. Возможно кто-то возразит, что ничего сложного в установке через тот же zypper нет, а даже если есть, то всегда доступен YaST, в котором уж точно никаких проблем быть не должно… даже у новичка в мире GNU/Linux. Так-то оно так, но сообщество хочет иметь не просто дружелюбный к новичку в GNU/Linux дистрибутив, но к новичку в компьютерах вообще. Другими словами, обсуждение свелось к недоработке openSUSE в этом вопросе, поиску решений и выходов из этой ситуации…

alien: converting DEB => RPM

Вчера я хотел установить себе XMind, но на странице проекта не нашел rpm для своей openSUSE. Проект отдает предпочтение лишь Ubuntu/Debian-пользователям GNU/Linux. В репах zypper se XMind тоже ничего не нашел.

Программа alien представляет из себя конвертор форматов различных пакетных систем, используемых в UNIX/Linux. Удобно, если не хочется возиться со сборкой из исходников. Она есть у нас в репах.

FOSS and openness

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

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

Why do you use GNU/Linux?

Достаточно часто можно увидеть темы на форуме или в багзилле, как новички GNU/Linux оскорбляют его разработчиков. Не понимают, как работает та или иная его часть, не могут с этим разобраться, и в итоге виноватыми оказываются программисты. В этом они чем-то напоминают Script kiddie, которые так же умееют/желают лишь использовать готовые продукты. Как это работает их не интересует.

OpenSSH: using keys for access

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

Open Source в уни

Хорошая новость для всех сторонников свободного программиного обеспечения приходит из северной Баварии. Со следующего зимнего семестра профессор Dr. Dirk Riehle в университете Friedrich-Alexander-Universität (Нюрнберг) включит в свой курс лекции по изучению Open_Source. Основная задача на ближайшие 3 года будет заключаться в изучении философии open souce, а так же исследовании концепций разработки ПО с открытым исходным кодом в компаниях, занимающихся разработкой ПО. Будет так же специально создана платформа, схожая с Sourceforge, для разработки ПО для студетов. Компании Novell и Red Hat выступают в данной инициативе как спонсоры. Так же они будут финансировать докторские проекты на кафедре. Ежегодно эта инициатива будет принесить более тысячи высококвалифицированных программистов в мир open source.