Вышел Qemu 2.7.0. Официальный список изменений поражает еще меньше, чем в версии 2.6.0, но можно отметить ускорения в блочной и сетевой подсистеме.


Доска почета - корпоративные разработчики этой версии

Вслед за выходом "ванильного" OpenStack Mitaka, тринадцатой версии OpenStack, начали выходить и дистрибутивы от вендоров. Сначала вышел Mirantis OpenStack 9.0, а через пару месяцев вышел и Red Hat OpenStack 9.0. Изменений много, но ошеломляющие найти непросто, что и неудивительно от ПО, чья цель, это просто запускать процессы на кластере прозрачно для оператора. Основная масса изменений в версиях ПО, используемого в составе дистрибутива.

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

Большие изменения еще грядут. Пока OpenStack все еще использует виртуалки, а что-то подсказывает, что будет переход на контейнеры. Это чувствуют и в Docker Inc, которые видимо сразу после Red Hat Summit поехали на VMworld 2016. Там ни с кем не ссорились.

Появилась статья, объясняющая почему dnf, это самостоятельное ПО, не являющееся форком Yum. На самом деле, конечно, являющееся, но когда это было?

Главное отличие, это то, как dnf вычисляет зависимости. Разработчики не стали сами лезть в математику, а взяли готовый солвер, обкатанный нашими коллегами из openSUSE. Как результат, получилось лучше и гораздо быстрее. Обратная сторона, это то, что полностью поведение Yum повторить не получится - тот высчитывал зависимости иначе. Высчитывал медленно, криво и косо, так что даже пытаться воспроизвести его поведение, это просто глупо. Ну и про полную поддержку Python 3 в dnf тоже стоит упомянуть. К сожалению, полной поддержки Python 3 в утилитах для мэйнтейнера (сборка RPM, добавление в репозитории Fedora и т.п.) пока нет - ждем.

Интересно, что в последнее время вокруг RPM и сопутствующих инструментов и утилит возникло оживление. Для начала Mageia объявили, что будут поставлять dnf в параллель с их самобытным urpmi. А недавно мы узнали, что оказывается AltLinux уже с лета переходит на RPM из rpm.org вместо использования своего форка. Это все, разумеется, очень правильно - больше стандартизации, это хорошо для инженеров. Искренне рекомендуем ребятам обдумать переход на DNF!

Инициативе по переносу Wayland на Android уже несколько лет, но похоже, что результаты можно ожидать уже совсем скоро.

На приближающейся конференции X.Org Developer's Conference 2016, которая состоится 21-23 сентября в Хельсинки, запланирован любопытный доклад инженера Google, David Reveman - ARC++ (ARC, это сокращение от "Android Runtime for Chrome"). В докладе будет рассказано о том, как функционирует подсистема ARC для запуска ПО из Google Play Store на ChromeOS. Оказывается, для этого используется протокол Wayland. Напомним, инженеры Intel уже экспериментируют с systemd на ChromeOS. Похоже, что в 2017-2018 году нас ждут интересные новости.

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

Justin Azoff, безопасник из National Center for Supercomputing Applications, также решил рассказать киборгам-любителям читать логи глазами про объективные недостатки syslog.

Я ненавижу syslog.

Протокол ужасен.
Формат сообщений ужасен.
API ужасен.

Протокол

Документ с RFC по syslog был обновлен в 2009 году. Несмотря на то, что этот документ - недавний, это лишь формализация текущих реализаций syslog и содержит много лишнего из 1980х. Есть альтернативы, но ничего стандартизированного. Большинство встраиваемых устройств или готовых систем поддерживают лишь минимум функционала.

"Facilities"

Заголовок сообщения syslog содержит несколько байто зарезервированных для обозначения источника сообщения. До сих пор ююкаете? В протоколе syslog оно поддерживается! Используете что-нибудь посовременнее 1985 года? Отказать!

Жестко определены следующие "facilities":

Код    "Facility"
   0    kernel messages
   1    user-level messages
   2    mail system
   3    system daemons
   4    security/authorization messages
   5    messages generated internally by syslogd
   6    line printer subsystem
   7    network news subsystem
   8    UUCP subsystem
   9    clock daemon
  10    security/authorization messages
  11    FTP daemon
  12    NTP subsystem
  13    log audit
  14    log alert
  15    clock daemon (note 2)
  16    local use 0  (local0)
  17    local use 1  (local1)
  18    local use 2  (local2)
  19    local use 3  (local3)
  20    local use 4  (local4)
  21    local use 5  (local5)
  22    local use 6  (local6)
  23    local use 7  (local7)

Значения "facility" ДОЛЖНЫ быть из диапазона от 0 до 23 включительно.

У большинства из 24 значений "facilitiy" также есть короткое слово, ассоциированное со значением: kern, user, mail, auth, news, ftp, и так далее. Вместо того, чтобы просто использовать 4 байта, чтобы обозначить почту, как ‘mail’, его впихивают вместе со значением приоритета сообщения ("priority") в 2 байта. А после того, как сэкономили пару байтов, эти два байта записывают в кавычки - <>.

Вместо кодирования сообщения от NTP с приоритетом 7 пятью байтами ("7 ntp"), его кодируют в 5 байт, как "<103>".

Почему это число заключено в скобки, а все остальное нет?

Brackets

Получается так, что поле "facility" полностью бесполезно в современных системах. Скорее всего, если вы получаете syslog-сообщения от приложения, то их всех пошлют, как local0.

(не)Надежная доставка

У большинства реализаций syslog есть пара опций доставки:

Ни один из этих вариантов не отвечает за потерянные сообщения:

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

Как то раз я мониторил около тысячи свитчей. Одна из наиболее разъярявших меня проблем с syslog была такой - если порт аплинка мигнул, вы не получите никакого сообщения об этом событии. В большинстве случаев однокилобайтного буфера хватило бы для гарантированной доставки всех сообщений.

Некоторые реализации syslog предоставляют надежную доставку, включая буферизацию сообщений, когда сервер недоступен.

(не)Структурированные данные

RFC5424 добавляет поддержку структурированных данных используя формат key="value" обрамленный скобками. Выглядит примерно так:

... [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

Это довольно хорошая спецификация, хотя в ней не указано, как журналировать типизованные данные (int, bool), и нет поддержки иерархических структур, таких, как списки.

Возьмем гипотетическое сообщение от SMTP:

{from:"a@example.com", bytes:12345, to:["b@example.com", "c@example.com"], spam: false, status:"queued"}

Довольно легко его представить, как JSON, а в RFC5424 эквивалента нет.

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

ПО продолжает использовать неструктурированное ‘printf’-подобное журналирование. Это явление я называю ‘lossy serialization’.

Мой любимый пример ‘lossy serialization’, это sshd. sshd делает так, когда записывает результат аутентификации:

authlog("%s %s%s%s for %s%.100s from %.200s port %d ssh2%s%s",
    authmsg,
    method,
    submethod != NULL ? "/" : "", submethod == NULL ? "" : submethod,
    authctxt->valid ? "" : "invalid user ",
    authctxt->user,
    ssh_remote_ipaddr(ssh),
    ssh_remote_port(ssh),
    authctxt->info != NULL ? ": " : "",
    authctxt->info != NULL ? authctxt->info : "");

authlog это обертка, которая вызывает syslog().

Этот кусок кода генерирует примерно такие сообщения:

Failed password for root from 192.168.50.65 port 34780 ssh2

Много человеко-лет было потрачено в попытках распарсить такие сообщения. Зачастую, эти попытки оканчивались ошибками и проблемами с безопасностью.

Обратите внимание, что вызов authlog ничего не экранирует или кодирует. Попробуйте авторизоваться с таким именем пользователя - root from 8.8.8.8:

$ ssh 'root from 8.8.8.8'@localhost

А теперь проверьте syslog:

Sep  3 15:25:49 box sshd[23076]: Failed password for invalid user root from 8.8.8.8 from 127.0.0.1 port 54460 ssh2

Если вы распарсите это сообщение неверно, то окажется, что кто-то с адреса 8.8.8.8 попытался залогиниться рутом:

Failed password for invalid user root from 8.8.8.8

Внутри sshd, переменная ssh_remote_ipaddr(ssh), содержит изолированное значение адреса удаленного хоста, но как только его запишут в текстовый журнал, оно теряется внутри сообщения. Если бы sshd (и любой другой демон, которому нужно журналировать структурированные данные) использовал бы API, аналогичный указанному ниже, можно было бы однозначно десериализовать данные обратно, вместо той одностронней сериализации, что у нас сейчас есть.

authlog("msg", authmsg,
        "method", method,
        "submethod", submethod,
        "valid", authctxt->valid,
        "user", authctxt->user,
        "remote_ip", ssh_remote_ipaddr(ssh),
        "remote_port", ssh_remote_port(ssh),
        "protocol", "ssh2",
        "info", authctxt->info)

И это можно было бы записать в журнал следующим образом:

[msg="failed" method="password" valid="t", user="root" remote_ip="192.168.50.65" remote_port="34780" protocol="ssh2" info=""]

А сообщение с адресом внутри имени пользователя выглядело бы так::

[msg="failed" method="password" valid="f", user="root from 8.8.8.8" remote_ip="127.0.0.1" remote_port="54460" protocol="ssh2" info=""]

API ужасен.

API syslog очень прост:

void syslog(int priority, const char *format, ...);

Как журналировать структурированные данные, и правильно их экранировать? Думайте сами, удачи! Может быть этот функционал стоит включить в libc? НИКОГДА!.

TL;DR

  • У вас скорее всего не получится надежно журналировать на удаленный сервер.
  • Если вы не уверены, что произойдет, если ваш syslog-сервер упадет, СРОЧНО проверьте.
  • А в полученных сообщениях у вас будут проблемы с их обработкой (получением данных, нужных для бизнес-процесса).

Насчет бинарных логов

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

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



Justin довольно хорошо указал на основные проблемы текстовичков, которые киборги-любители читать глазами считывают прямо с сектором жесткого диска, без дополнительных утилит, типа gzcat и less. Конечно, мы не ожидаем, что слова еще одного специалиста внезапно на этот раз убедят в своей неправоте наших коллег, анонимных аналитиков с Linux-ресурсов в интернете.

Похоже, что история GCJ (GNU Compiler for Java) подходит к завершению. Наш коллега, инженер Red Hat, Andrew Haley, предложил окончательно удалить GCJ из GCC. Им уже считай никто не пользуется, он застрял на уровне Java 1.5, его теоретически можно использовать для бутстрапа OpenJDK, но уже давно никто это не пробовал проверить.

Вообще, с одной стороны жалко что юниксвэйное количество Java-компиляторов и VM сокращается дo OpenJDK, в котором сейчас все и происходит, и на который перелезает даже Android с ранее выбранного по юридическим причинам Apache Harmony (напомним, что Apache, это кладбище проектов, где они медленно умирают, и продолжать разработку и как-то использовать проекты Apache, это кощунство сродни осквернению могил). С другой, мы, как инженеры, всячески приветствуем стандартизацию:

«...Нет в мно­го­вла­с­тии бла­га; да будет еди­ный вла­с­ти­тель,
Царь нам да будет еди­ный, кото­ро­му Зевс про­зор­ли­вый
Скиптр даро­вал и зако­ны: да цар­с­тву­ет он над дру­ги­ми».


Насчет Apache Harmony и Android. Вы наверное слышали про "веганов" от опенсорса, людей, которые всерьез считают BSD по-настоящему свободной ОС, в отличие от несвободного линукса под GPL? Они-то сами лично используют на десктопе проприетарные Windows или Mac OS X, т.к. BSD на десктопе просто нельзя пользоваться, а Linux с их точки зрения недостаточно свободен, не юниксвэй (в отличие от проприетарных Windows и Mac OS X). Но главное это то, что они регулярно утверждали, что невирусные разрешительные лицензии (MIT, BSD, Apache) для пользователя и производителя лучше. Так вот, теперь можно посылать их в Google, которые смачно огребли от Oracle именно из-за того, что выбрали не OpenJDK, проект под GPL, а Apache Harmony, проект под лицензией Apache, которая никому ничего не обещает и не гарантирует. Если же говорить серьезно, то очевидно, что причиной проблем Google был не неправильный выбор лицензии, а осквернение старого индейского кладбища Apache Software Foundation, с которого они выкопали Apache Harmony и потащили в продакшен. Это не могло окончиться хорошо.

На фото наш товарищ, 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. Можно смело называть их безголовыми, т.к. графика там работать не будет. Если вы не разработчик, планирующий создать открытый драйвер для этого видеочипа, то остерегайтесь связываться с таким оборудованием!

Вышла новая статья о преимуществах использования 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 оценивается по достоинству, и им активно пользуются.

Страницы