Это архивная статья

На фото наш товарищ, Glauber Costa (Lord Glauber of Sealand), на Scylla Summit 2016:

Это архивная статья

Наш коллега, Lubomir Rintel, анонсировал выход NetworkManager версии 1.4. Новость уже обсуждалась на OpenNET.ru.

В этой версии продолжилась работа над манипуляциями с MAC-адресами, о которой мы вам уже рассказывали. Напомним, что использование полностью случайно генерируемого MAC-адреса имеет побочный эффект. Некоторые провайдеры привязывают авторизацию к MAC-адресу, поэтому постоянно выдавать случайный MAC будет не очень удобно для пользователя. Для этих случаев было предусмотрен режим работы, когда MAC генерируется случайно, но в дальнейшем в указанной сети не меняется. Подробнее об этом нововведении рассказал в своем блоге наш коллега, инженер Red Hat, Thomas Haller.

Это архивная статья

Коллеги-аналитики на Linux.org.ru удивляются, что в Fedora 25 Wayland будет по умолчанию.

Непонятно, чему удивляться, если мы планировали это достаточно давно, а используем уже с Fedora 24 (некоторые даже с Fedora 23). Все работает.

Конечно, все это происходило не само. Наши коллеги улучшали и продолжают улучшать поддержку Wayland в библиотеках и в DE. Например, недавно наш коллега, инженер Red Hat, Jonas Ådahl, добавил поддержку еще одной фичи Wayland в SDL2. Уже серьезно улучшена (и планируется улучшать и дальше, в соответствии с новым планом выпуска, о котором мы вам рассказывали) поддержка Wayland в GTK. Другой коллега, автор Xfce и инженер Red Hat, Olivier Fourdan, наоборот, предложил новую фичу в сам протокол Wayland.

Улучшается поддержка Wayland и в GNOME - полностью поддерживаются планшеты для рисования и улучшена поддержка в GNOME Mutter.

Наши друзья и коллеги занимались и разработкой модулей ядра и драйверов.

Eric Anholt, уже пару лет работающий на Broadcom над видеодрайвером VC4, начал в своем блоге на LJ регулярно постить новости разработки. Не пропала и идея SimpleDRM - независимый разработчик, Noralf Trønnes, подхватил упавшее знамя, и недавно опубликовал обновленный вариант.

Кстати, он же недавно продолжил работу над BSoD для Linux.

Если для ix86/x86_64 архитектур в графической подсистеме все уже более менее нормально, то для ARM еще есть темные области. Одна из них, о чем предупреждает нас наш коллега, Marcin Juszkiewicz, это системы с видеочипом PowerVR. Можно смело называть их безголовыми, т.к. графика там работать не будет. Если вы не разработчик, планирующий создать открытый драйвер для этого видеочипа, то остерегайтесь связываться с таким оборудованием!

Это архивная статья

Обычно на десктопах Linux для управления сетевыми настройками используется NetworkManager, поскольку он отлично справляется со своей работой и имеет GUI фронтенды для всех популярных графических окружений. Однако на серверах Linux его использование не целесообразно: он потребляет много ресурсов. NetworkManager занимает в оперативной памяти около 20 Мб, в то время как systemd-networkd и systemd-resolvd вместе меньше 2 Мб. По этой причине, по умолчанию серверные дистрибутивы Linux часто используют различные собственные демоны.

Таким образом возникает целый зоопарк скриптов и утилит: демон networking под Debian, который управляет конфигурацией сети через ifupdown, использующий файлы конфигурации хранящиеся в /etc/networing/interfaces.d и файл /etc/networking/interfaces, под CentOS network, который использует скрипты ifup и ifdown и, конечно же, свои файлы конфигурации находящиеся в /etc/sysconfig/network-scripts, netctl под ArchLinux. Всем известно, что Linux — конструктор, но почему бы такой простой и общей для самых различных систем вещи как настройка сети не иметь одинаковый вид?

` <>`__

Мы предлагаем начать использовать быстрый и простой демонsystemd-networkd, особенно в свете того, что многие дистрибутивы уже перешли на systemd, поэтому переключение на systemd-networkd не составит труда. На текущий момент systemd-networkd может заменить собой множество утилит и поддерживает, настройку сети как по DHCP (клиент и сервер) так и со статическими IP-адресами, мосты, туннели, VLANs, беспроводные сети (используя при этом wpa_supplicant).

В статье мы рассмотрим, как активировать systemd-networkd и начать его использовать и в чем его основные преимущества перед остальными демонами.

Запуск systemd-networkd

Несмотря на страсти кипевшие вокруг внедрения systemd, многие популярные дистрибутивы Linux стали использовать этот менеджер служб и поставлять его по умолчанию. Поэтому, вероятно, ваша система уже содержит всё необходимое для включения systemd-networkd. Необходим systemd версии 210 и выше.

Проверить версию можно с помощью команды:

$ systemctl --version

Чтобы использовать, запустите следующие две службы и включите их работу при загрузке системы (отключив при этом другие демоны управляющие конфигурацией сети):

$ systemctl enable systemd-networkd
$ systemctl start systemd-networkd
$ systemctl enable systemd-resolved
$ systemctl start systemd-resolved

Конфигурирование

В качестве примера переключения рассмотрим перенос конфигурации сети по умолчанию в CentOS (/etc/rc.d/init.d/network initscript) на systemd-networkd.

Полностью аналогичо переезд можно осуществить для Fedora и, с небольшими изменениями, для других дистрибутивов. Конфигурационные файлы systemd-networkd находятся в директории /etc/systemd/network. Доступны следующие типы:

• .link – описывают физические параметры каждого интерфейс: имя, MAC, MTU и другие
• .network – описывают параметры сети: IP, маршруты, DNS и другие
• .netdev – описывают виртуальные интерфейсы, мосты

Конфигурация для примера: два интерфейса со статическим IP в LAN и WAN.

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 04:01:40:23:1f:01 brd ff:ff:ff:ff:ff:ff
    inet 188.166.46.238/18 brd 188.166.63.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a03:b0c0:2:d0::69:7001/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::601:40ff:fe23:1f01/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 04:01:40:23:1f:02 brd ff:ff:ff:ff:ff:ff
    inet 10.133.248.54/16 brd 10.133.255.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::601:40ff:fe23:1f02/64 scope link
       valid_lft forever preferred_lft forever

Конфигурационные файлы для CentOS (или Fedora): можно найти в директории /etc/sysconfig/network-scripts

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE='eth0'
TYPE=Ethernet
BOOTPROTO=none
ONBOOT='yes'
HWADDR=04:01:40:23:1f:01
IPADDR=188.166.46.238
NETMASK=255.255.192.0
GATEWAY=188.166.0.1
NM_CONTROLLED='yes'
IPV6INIT=yes
IPV6ADDR=2A03:B0C0:0002:00D0:0000:0000:0069:7001/64
IPV6_DEFAULTGW=2A03:B0C0:0002:00D0:0000:0000:0000:0001
IPV6_AUTOCONF=no
DNS1=2001:4860:4860::8844
DNS2=2001:4860:4860::8888
DNS3=8.8.8.8

Необходимо создать 4 файла в директории /etc/systemd/network/

$ cat /etc/systemd/network/90-external.link
[Match]
MACAddress=04:01:40:23:1f:01
[Link]
Name=eth-outer

$ cat /etc/systemd/network/90-internal.link
[Match]
MACAddress=04:01:40:23:1f:02
[Link]
Name=eth-inner

$ cat eth-external.network
[Match]
Name= eth-outer
[Network]
DHCP=no
Adress=188.166.46.238/18
Adress=2A03:B0C0:0002:00D0:0000:0000:0000:0069:7001/64
Gateway=188.166.0.1
Gateway= 2A03:B0C0:0002:00D0:0000:0000:0000:0000:0001
DNS=2001:4860:4860:8844
DNS=2001:4860:4860:8888
DNS=8.8.8.8

$ cat eth-internal.network
[Match]
Name=eth-inner
[Network]
Address=10.133.248.54/16

Вот и всё: конфигурация сети завершена. Теперь можно перезапустить сервис:

systemctl restart systemd-networkd

$ networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           n/a         n/a
  2 eth-outer        ether              routable    configured
  3 eth-inner        ether              routable    configured

Другие типы сетей:

DHCP

В данном примере сконфигурируем DHCP IPv4 и IPv6; IPv6 если не нужен, можно исключить.

$ cat /etc/systemd/network/wired-dhcp.network
[Match]
Name=eth*

[Network]
DHCP=ipv4
DHCP=ipv6

Подключение типа «Мост»

Сначала создает конфигурацию виртуального интерфейса:

$ cat /etc/systemd/network/bridge.netdev
[NetDev]
Name=br0
Kind=bridge

$ cat /etc/systemd/network/bridge.network
[Match]
Name=br0

[Network]
DHCP=ipv4

И настраиваем интерфейс для подключения:

$ cat /etc/systemd/network/wired.network
[Match]
Name=eth*

[Network]
Bridge=br0

Недостатки (не актуальны, по большему счету, для серверов)

1. Не будет работать без systemd.

2. Нет ни CLI ни GUI фронтендов. И NetworkManager, и netctl не страдают таким недостатком. Например, для подключения к WiFi вам понадобится командная строка. Не совсем актуально для сервера.

3. Для первого подключения к WiFi необходимы root права.

Однако это не совсем недостаток, так как в будущем к этой беспроводной сети подключение будет происходить автоматически.

4. Если быть не осторожным, то пароль от WiFi может храниться в открытом виде в истории команд. но этого можно легко избежать несколькими способами: временно отключить запись команд в историю (для bash: set +o history, set -o history), использовать shell не запоминающий историю (например dash) или просто вручную удалить пароль из истории.

Бенчмарк

Тестируется скорость получения адресов по DHCP, Network manager and dnsmasq отключены.

Софт:

— CentOS 7 — kernel-3.10.0-327.28.3.el7 — systemd 219 — ISC DHCP client daemon and dhclient-script 4.2.5

systemd-networkd

$ systemctl start systemd-networkd
$ journalctl -u systemd-networkd.service
Sep 01 13:04:41 localhost systemd[1]: Starting Network Service...
Sep 01 13:04:41 localhost systemd-networkd[4085]: Enumeration completed
Sep 01 13:04:41 localhost systemd[1]: Started Network Service.

Sep 01 13:04:41 localhost systemd-networkd[4085]: eth0: DHCPv4 address 192.168.1.114/24 via 192.168.1.1
Sep 01 13:04:41 localhost systemd-networkd[4085]: eth0: Configured

Меньше чем за секунду.

ISC DHCP

$ time dhclient -v eth0
Interface up - dhclient
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp2s0/94:de:80:1a:da:af
Sending on   LPF/enp2s0/94:de:80:1a:da:af
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x5b763f4d)
DHCPACK from 192.168.1.1 (xid=0x5b763f4d)
bound to 192.168.1.115 -- renewal in 20662 seconds.


real        0m2.243s
user        0m0.042s
sys        0m0.216s

Среднее время после нескольких попыток составило 2.5 секунд.

Заключение

В виду активного использования systemd различными топовыми дистрибутивами Linux можно заключить, что, всё же, сообщество стремится к унификации основных системных функций. К ним относится, в том числе, конфигурирование сети, а systemd, в свою очередь, предлагает удобное, быстрое и функциональное решение. И пусть пока это решение сталкивается с проблемой отсутствия GUI для десктопных систем, но для Linux серверов оно, возможно, станет стандартом «де-факто» и заменит кучу легаси демонов и отдельных утилит. Это сделает Linux гораздо более удобным для контейнеризации и использования на виртуальных машинах.

Приятно видеть, что предлагаемый функционал systemd оценивается по достоинству, и им активно пользуются.

Это архивная статья

Представители Docker на своем стенде на прошедшем недавно Red Hat Summit раздавали футболки с провокационным текстом:

Ушлые журналисты из TheRegister заметили, и постепенно начал разгораться скандал. Как многим показалось, таким образом представители Docker Inc. выражали неприязнь к тому, что Red Hat в проекте Atomic используют патченную версию Docker. Наш коллега, Dan Walsh, был вынужден написать пост с разъяснениями:

Версия Docker, используемая в Project Atomic, уже некоторое время содержит серию патчей, отсутствующих в апстрим. Каждый раз, когда мы добавляем патч, это добавляет нам работы по его поддержке, так что мы бы предпочли не добавлять никаких патчей. Мы всегда стремимся включать все наши патчи в апстрим, и делать это публично.

В этой заметке мы постараемся описать все патчи, которые у нас есть:

• Объясним типы патчей.
• Опишем сами патчи.
• Приведем ссылки на обсуждения на GitHub и на PR.

Кое кто утверждает, что наш репозиторий Docker, это форк репозитория апстрим.

Что это значит - форк?

Я занимаюсь открытым ПО уже очень давно, и мое определение “форка” может быть устаревшим. Я полагаю, что “форк”, это враждебное действие, совершенное одной группой, чтобы заставить людей использовать и развивать их версию проекта, и игнорировать “оригинальную”. Например, LibreOffice форкнулся от OpenOffice, или ранее Xorg форкнулся от Xfree86.

Сейчас GitHub изменил значение форка. Если ПО разрабатывается на GitHub или аналогичной платформе, то каждый, кто хочет внести вклад, должен нажать кнопку “fork” и начать писать свои патчи. На момент написания этой заметки у Docker на GitHub есть 9860 форков, включая наш. Однако, по определению все пакеты в дистрибутиве, которые собраны с патчами, это форки. Red Hat поставляет ядро Linux, и я пока не слышал, чтобы это называли форком. Но если вы считаете, что любой проект, который поставляется с дистроспецифичными патчами, это форк, то и оно тоже “форк”.

Апстрим Docker даже основывается на том, что Ubuntu пропатчила AUFS патчами, которые никогда не были включены в апстрим. Т.к. RHEL и производные дистрибутивы не содержат этих патчей, то мы добавили поддержку бэкендов для Devicemapper, OverlayFS, и Btrfs, которые полностью поддерживаются апстримом ядра. Вот так должны работают дистрибутивы для серьезных задач: поставлять пакеты, собранные и сконфигурированные так, чтобы их можно было поддерживать долго.

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

Как я могу узнать подробности о патчах к конкретной версии Docker?

Все наши патчи описаны в файле README.md в соответствующем бранче нашего репозитория Docker. Например, если вы хотите посмотреть на патчи к docker-1.12, то обратите внимание на бранч docker-1.12.

Затем вы можете посмотреть на страницу со списком патчей к Docker, где есть информация про эти патчи.

Какие типы патчей включает Project Atomic?

Вот краткое описание типов патчей, которые мы используем, и инструкция по поиску информации про конкретный патч.

Бэкпорты из апстрима

Апстрим Docker Project, как правило, исправляет ошибки в следующей версии Docker. Это значит, что если пользователь столкнулся с ошибкой в docker-1.11, и мы предложили исправление в апстрим, то патч будет включен лишь в бранч master, и скорее всего никогда не будет бэкпортирован в docker-1.11.

Т.к. Docker выпускается с бешеной скоростью, то они будут предлагать пользователям обновиться до docker-1.12, когда он выйдет. Это хорошо, если пользователь хочет быть на острие разработки, но в ряде случаев новая версия приносит новые ошибки.

Например, в docker-1.11 сервис docker был разделен на три части: демон docker, containerd, и runc. Мы не считаем, что это изменение стабильно, чтобы поставлять его корпоративным пользователям сразу, как оно выйдет, хотя в этой версии и было множество исправлений для ошибок в версии docker-1.10. Много пользователей желают лишь получать обновления с исправлением ошибок, и не хотят тестировать все ПО снова каждые пару месяцев.

Другая проблема с поддержкой стабильной ветки ПО с быстро изменяющимися зависимостями, это что разработчики стабильной ветки вынуждены тратить время на проверку того, что их продукт остается стабильным каждый раз при обновлении зависимости. Это дорогостоящий процесс, и как результат зависимости обновляются нечасто. Это приводит к тому, что мы “выбираем (cherry-pick)” изменения из апстрима Docker и поставляем эти изменения со старыми версиями, чтобы исправлять ошибки, не обновляя или добавляя зависимости. Тот же подход мы применили, чтобы добавить capabilities в ядро Linux, подход, доказавший свою ценность для пользователей.

Патчи предложенные в апстрим

Мы также добавляем патчи, которые, как мы знаем, пользователи требуют прямо сейчас, но они еще не были включены в апстрим. Каждый патч, который мы добавляем в репозиторий Project Atomic, также предлагается на включение в апстрим-репозиторий Docker.

Эти типы патчей остаются в репозитории Project Atomic либо недолго, пока их рассматривают в апстриме на включение, либо навсегда, если апстрим отвергает их. Если мы не согласны с апстримом Docker и полагаем, что наши пользователи нуждаются в этих патчах, мы продолжаем применять их. В некоторых случаях, мы разрабатываем альтернативные подходы, например плагины для авторизации.

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

Подробный список патчей

Хотите знать больше о конкретном патче? Вы можете найти список патчей на нашей странице патчей к Docker.

Наш коллега, Андрей Маркелов, сообщает в своем блоге, что его новая книга по подготовке к экзамену Certified OpenStack Administrator доступна для предзаказа!

Пришли новости, что Rackspace выкупили за 4.3 миллиарда долларов США.

Как вы помните, слухи о покупке Rackspace ходили с 2014 года, и вот, наконец-то, они материализовались. Будем надеяться, что это хорошие новости для наших товарищей, трудоустроенных в RackSpace.

Это архивная статья

Сформирована программа конференции systemd.conf 2016. Среди выступающих как представители крупных корпоративных пользователей systemd (Bosch, n:stack / StackHut, NixOS, Facebook, например), так и компаний-разработчиков (например, Red Hat, Endocode, ProFUSION, Pengutronix, CoreOS, Canonical, Kinvolk). Интересно, остались ли те, кто считает, что systemd "ненужно" и "закопать"?

После выявления проблем с производительностью и после включения и поспешного отключения kdbus в Fedora Rawhide, разработка была свернута в пользу совершенно нового проекта - bus1. И вот, наконец-то, анонсировали его первую публичную версию.

Разработчики резко упростили реализуемый функционал перепозиционировав проект, как n-to-n шина сообщений с поддержкой multicast и unicast и с системой безопасности на базе capabilities. Это было бы аналогом Binder из Android, если бы тот умел multicast. Из-за поддержки multicast пришлось добавить функционал неизменности порядка сообщений, т.е. если сторона (или стороны) отправила пакет A, а затем B, то независимо от того, unicast это или multicast, адресат получит сначала A, затем B.

Neil Brown уже написал статью на LWN, под которой началось интересное обсуждение. Учитывая фиаско с kdbus, наверное не стоит ожидать быстрого включения функционала bus1 в дистрибутивы, но пока мы сохраняем осторожный оптимизм.

Ну и из смешного - в systemd включили systemd-mount. Напоминаем:

Если кто не в курсе, то идеи, что в systemd надо включить управление сетью, wpa_supplicant, минимальный shell, минимальный текстовый редактор (для работы с конфигами), монтирование, управление логинами, и пр. высказываются регулярно. Люди вокруг тут-же начинают шутить про emacs, а вот Lennart сразу-же задумывается и даже забывает про бокал пива в руке.

Это архивная статья

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

Сейчас разделение осуществляется на уровне сборки - Koji для secondary arch физически отделен. Предлагается объeдинить все работоспособные сборщики в одну точку входа. Сделать это предлагается постепенно - с Fedora 26 к имеющимся сборщикам для i686, x86_64, armv7hl добавится сборщик для aarch64, а с Fedora 27 добавятся сборщики для архитектур Power64 и s390.

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

Масла в огонь подлил наш коллега Rich W.M. Jones, который с радостью объявил, что вовсю идет процесс пересборки Fedora для новой процессорной архитектуры - RISC-V. Для архитектуры, считай, не существует физического оборудования (надо покупать FPGA и заливать туда прошивку проприетарными утилитами, работающими только под Windoz, либо использовать Qemu), и его неосторожное высказывание, что он надеется сделать ее основной архитектурой сборки еще больше разозлило тех, кто не желает терпеть проблемы от непопулярных архитектур. Для RISC-V уже есть поддержка в ядре Linux, в GCC, и в Glibc, но в остальном еще работы много. Например, только начали добавлять поддержку RISC-V в RPM. Так что опасения народа довольно понятны.

Мы будем следить за развитием событий.

Это архивная статья

Сформирована программа конференции LibreOffice Conference 2016, которая состоится с 7 по 9 сентября 2016 года в Брно.

Приезжайте, обсудим текущее состояние и тенденции развития офисного пакета и его аналогов.