Вышла новая статья о преимуществах использования systemd для администрирования серверов. В этот раз про systemd-networkd.

Обычно на десктопах 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 доступна для предзаказа!



Моя новая книга над которой я работал последние пол-года доступна для предварительного заказа на сайте издательства Apress.com. По плану она выходит 30 ноября 2016 года. Книга поможет подготовиться к экзамену Certified OpenStack Administrator от OpenStack Foundation. Также будет не бесполезна при подготовке к сертификации от Mirantis. Полное описание книги и оглавление - на сайте издательства.

Пришли новости, что 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 года в Брно. Приезжайте, обсудим текущее состояние и тенденции развития офисного пакета и его аналогов.




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

Последние несколько лет мэйнтейнером gettext является наш коллега, инженер Red Hat и участник Fedora Project, Daiki Ueno. За это время в gettext были внесены важные улучшения, благодаря которым нет никакой нужды использовать конкурирующее решение - intltool, разрабатывающееся в Launchpad с помощью bzr. Наш коллега, Matthias Clasen, в своем блоге постарался рассказать о преимуществах gettext. Вкратце, это большое количество понимаемых форматов (*.desktop, файлы Gtkbuilder, *.appdata.xml, *.metainfo.xml), включение и использование переведенных строк, и удобство подключения новых XML-форматов к gettext.

Peter Hutterer объявил, что libinput окончательно завершен. У него закончился TODO-список. Эта библиотека будет основным источником ввода для Wayland, поэтому это очень важно. Fedora перешла на libinput, как основной драйвер для X11 начиная с Fedora 22 - таким образом будет достигнут бесшовный переход на Wayland. Недавно, кстати, выпустили Wayland Protocols 1.5 - набор дополнительных протоколов для Wayland, и среди изменений есть относящиеся к touchpad. Немного опасаемся за будущее Wayland. В XMPP идея о базовом функционале и дополнительных функциях, реализуемых в виде необязательных к следованию им XEP, привела к тому, что гарантированно работали только базовые функции, и от протокола массово начали отказываться большие вендоры в пользу самописных, более функциональных решений.

Постепенно набирает скорость Vulkan. Наш коллега, инженер Red Hat и участник Fedora и Debian, David Airlie, предложил первый вариант Vulkan-драйвера для некоторых видеокарт AMD.

Новости о systemd больше не пугают революционностью. Недавно systemd дорос до версии 231. Основная работа, судя по ChangeLog, идет в направлении контейнеров и systemd-networkd. Интересно, что и systemd, и wayland стали настолько хороши, что GNOME в Fedora 24 теперь использует их практически незаметно для пользователя (обратите внимание на строку 259, где располагается процесс с PID 2147). А ведь нам уже говорили, что systemd --user планировали переработать.

Наши друзья из Parallels / OpenVZ наконец-то выпустили седьмую версию своего флагманского продукта. В этой версии, что особенно примечательно, было принято решение использовать KVM вместо самописного проприетарного гипервизора. Из других фич - использование CRIU для живой миграции контейнеров, еще меньшая разница между ядрами OpenVZ и RHEL, и постепенный отказ от утилиты vzctl в пользу virsh или аналогичных решений. И особенно хочется отметить последовательную реализацию плана по открытию своих технологий и увеличению прозрачности процесса. Вы знали, что у OpenVZ есть аккаунт на GitHub?

Решения, разработанные в Parallels, разбираются и другими вендорами, например Red Hat, где CRIU доступен как "technology preview" начиная с RHEL 7.2. В RHEL версия уже старовата, но попробовать можно. К сожалению не всегда к инженерам Parallels прислушиваются внимательно. Например, разработчики Parallels нашли ошибку в ядре года три назад, но тогда никто особо не заинтересовался. А вот недавно, та ошибка внезапно привлекла всеобщее внимание, т.к. с помощью Docker, который как некоторые ошибочно считают мегабезопасен, ее можно использовать на некоторых хостингах контейнеров. Сразу бы так.

Страницы