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

Поиск причины

Первая мысль – “неужели где-то перемудрил с fail2ban‘ом?”, но его отключение ни к чему не привело. К счастью, поддержка подсказала номер AS, из которой могут исходить запросы роботов Яндекса – AS13238, что сильно облегчило поиск причины на своей стороне.

Получил список сетей Яндекса с помощью bgpq3 -4 -F '%n/%l, ' AS13238 и добавил следующее правило в nftables поближе к самому началу обработки всех новых соединений:

ip saddr {5.45.192.0/18, 5.45.202.0/24, 5.45.205.0/24, 5.45.215.0/24, 5.255.192.0/18, 5.255.197.0/24, 5.255.255.0/24, 37.9.64.0/18, 37.9.64.0/24, 37.9.87.0/24, 37.9.112.0/24, 37.140.128.0/18, 77.88.0.0/18, 77.88.8.0/24, 77.88.44.0/24, 77.88.55.0/24, 84.252.160.0/19, 87.250.224.0/19, 87.250.247.0/24, 90.156.179.0/24, 90.156.180.0/24, 90.156.181.0/24, 90.156.184.0/24, 90.156.185.0/24, 92.255.112.0/20, 93.158.128.0/18, 95.108.128.0/17, 141.8.128.0/18, 178.154.128.0/19, 178.154.131.0/24, 178.154.160.0/19, 185.32.187.0/24, 213.180.192.0/19, 213.180.199.0/24} meta nftrace set 1

Запустил nft monitor trace и, воспользовавшись тулзой по анализу robots.txt, тут же получил следующее:

trace id f15d4066 inet mangle PREROUTING packet: iif "isp" ether saddr 3c:c7:86:12:89:7a ether daddr 08:f1:db:e6:ac:3b ip saddr 5.255.253.45 ip daddr 10.217.4.5 ip dscp cs0 ip ecn ect0 ip ttl 50 ip id 3342 ip protocol tcp ip length 60 tcp sport 61996 tcp dport 443 tcp flags == 0xc2 tcp window 42300
...
trace id f15d4066 inet filter check_packets rule ct state new tcp flags != syn counter packets 0 bytes 0 goto bad_tcp_new_packet (verdict goto bad_tcp_new_packet)
trace id f15d4066 inet filter bad_tcp_new_packet rule meta l4proto tcp counter packets 0 bytes 0 reject with tcp reset comment "Invalid TCP packets" (verdict drop)

Ого, это интересно. Мы что-то дропнули вот тут:

# New TCP connections must be started with SYN packets.
#
# NEW but not SYN is the only invalid TCP flag not covered by the
# INVALID state. The reason is because they are rarely malicious packets,
# and they should not just be dropped, but might be an error or attack.
#
# For example, this may be just connections forgotten by conntrack module.
ct state new tcp flags != syn counter goto bad_tcp_new_packet

Пробую убрать это правило – и теперь действительно всё работает. Ещё интереснее. :)

Распространённая ошибка

Итак – проблема действительно на моей стороне. И это замечательно – меньше всего хотелось бы дебажить подобные вещи через поддержку своего провайдера.

Но вот только пока не очень понятно, в чём именно проблема: это ведь довольно стандартная рекомендация – reject’ить все новые TCP-соединения, у которых первый пакет не является SYN-пакетом. Да и что же тогда нам Яндексовый робот такое прислал, если это не SYN-пакет?..

Смотрим более внимательно в нашу трассировку – и видим там следующие TCP-флаги: tcp flags == 0xc2. 0xc2 – это 11000010, что, исходя из структуры TCP-пакета, является SYN + ECE + CWR. Отлично, теперь всё понятно – это вполне себе SYN-пакет, но только какой-то необычный, а правило у нас написано довольно тупо (tcp flags != syn) и совершенно на такой случай не рассчитано. При этом, если для iptables обычно даётся рекомендация вида iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP, где --syn на самом деле является шорткатом для --tcp-flags SYN,RST,ACK,FIN SYN, то для nftables (помимо в целом в разы более куцей информации по его конфигурации) даже официальная документация предлагает nft add rule filter input tcp flags != syn counter в качестве примера правила “to count packets that are not SYN ones” (как и во многих статьях в блогах, в которых правило представлено ровно в том виде, в котором оно используется у меня) – в результате чего возникает ощущение, что я могу быть далеко не единственным, кто столкнётся с этой проблемой (и именно это побудило меня написать данную статью).

Поэтому tcp flags != syn правильнее заменить на tcp flags & (syn|ack|rst|fin) != syn.

Explicit Congestion Notification

А что же всё-таки за такой необычный пакет к нам пришёл? ECE и CWR-флаги ведут нас к Explicit Congestion Notification – хм, интересно: про TCP congestion control я в курсе, а вот Explicit Congestion Notification – это для меня что-то новое. Отлично – значит день уже прожит не зря. :)

Вкратце, суть его заключается в следующем: если традиционно в TCP текущая загруженность канала определялась неявно через отслеживание количества пакетов, которые потерялись по дороге к адресату (были дропнуты роутером где-то в середине пути), то ECN добавляет возможность роутеру специальным образом маркировать пакеты, тем самым заранее уведомляя участников TCP-соединения о том, что канал перегружен, и он скоро начнёт дропать пакеты. Но, само собой, рекомендую почитать более полное описание.

Поэтому, видимо, дело в том, что недавно в Яндексе поменялась конфигурация серверов, на которых располагаются поисковые боты, и они стали устанавливать соединения с включенным ECN.

В итоге

Если вы, как и во многих руководствах по nftables, дропаете/reject’ите пакеты по правилу ct state new tcp flags != syn, то его необходимо заменить на ct state new tcp flags & (syn|ack|rst|fin) != syn – иначе когда-нибудь эта довольно подлая бомба замедленного действия сработает и у вас.

У меня дома стриггерился алерт: мой домашний сервачок (он же роутер) помимо всего прочего отслеживает количество уникальных от-forward’енных $src_ip + $dst_ip + $dst_port – и алертит, когда их количество превышает некоторый порог.

И вот за последние сутки с моего телефона + телефона жены 2560 + 4082 уникальных пар $dst_ip + $dst_port (где 602x22 ниже – это соединения на 22 порт на 602 разных IP-адреса):

kate-mobile.lan (4082 IP+port pairs): 3117 TCP (1534x443, 602x22, 261x80, 237x554, 220x53, 29x23, 28x983, 21x553, 20x179, 12x1443, 9x5222, 6x5228, 4x4460, 4x21, 2x571, 2x9243, 2x240, 2x383, 2x185, 2x260, 2x299, 2x237, 2x336, 2x131, 2x512, 1x464, 1x734, 1x4416, 1x371, 1x10, 1x863, 1x895, 1x759, 1x815, 1x178, 1x830, 1x271, 1x838, 1x707, 1x629, 1x174, 1x1003, 1x894, 1x3237, 1x887, 1x962, 1x603, 1x855, 1x241, 1x494, 1x540, 1x181, 1x352, 1x454, 1x373, 1x654, 1x56, 1x646, 1x175, 1x876, 1x810, 1x556, 1x395, 1x483, 1x697, 1x212, 1x34, 1x588, 1x348, 1x605, 1x680, 1x460, 1x401, 1x224, 1x143, 1x161, 1x104, 1x655, 1x872, 1x521, 1x459, 1x911, 1x705, 1x317, 1x377, 1x807, 1x323, 1x893, 1x866, 1x142, 1x1001, 1x170, 1x920, 1x843, 1x209, 1x463, 1x156, 1x569, 1x952, 1x701, 1x184, 1x597, 1x389, 1x647, 1x8543, 1x487, 1x624, 1x537, 1x814, 1x259, 1x578, 1x26, 1x904, 1x751, 1x652, 1x795, 1x234, 1x671, 1x45, 1x4477, 1x307, 1x635, 1x651, 1x227, 1x806, 1x752, 1x203, 1x220, 1x582, 1x568, 1x153, 1x844, 1x402), 965 UDP (379x443, 278x53, 116x554, 83x123, 38x22, 22x23, 7x2002, 6x983, 4x179, 2x4123, 2x512, 2x21, 2x553, 1x363, 1x652, 1x654, 1x1003, 1x299, 1x307, 1x377, 1x680, 1x807, 1x804, 1x966, 1x685, 1x240, 1x463, 1x655, 1x806, 1x45, 1x383, 1x336, 1x153, 1x260, 1x28, 1x241, 1x603)
mobile.lan (2560 IP+port pairs): 1899 TCP (814x443, 405x22, 171x554, 168x80, 160x53, 23x983, 18x179, 18x1443, 15x23, 10x553, 9x5222, 6x21, 5x7275, 3x5228, 2x19302, 1x759, 1x37, 1x629, 1x685, 1x581, 1x582, 1x10000, 1x142, 1x250, 1x846, 1x125, 1x872, 1x657, 1x8543, 1x604, 1x90, 1x727, 1x567, 1x911, 1x739, 1x810, 1x4477, 1x866, 1x26, 1x491, 1x10, 1x156, 1x626, 1x178, 1x422, 1x977, 1x155, 1x12, 1x402, 1x683, 1x21007, 1x306, 1x595, 1x184, 1x4416, 1x472, 1x14, 1x904, 1x166, 1x165, 1x753, 1x988, 1x4434, 1x11, 1x28, 1x317, 1x622, 1x535, 1x718, 1x686, 1x637, 1x207, 1x244, 1x153, 1x7000, 1x8443, 1x966, 1x383, 1x5223, 1x985, 1x161, 1x994, 1x395, 1x898, 1x39, 1x592, 1x6447), 661 UDP (307x443, 168x53, 81x554, 36x123, 24x22, 10x23, 6x983, 6x179, 4x19302, 3x553, 3x21, 1x153, 1x685, 1x626, 1x155, 1x592, 1x19000, 1x491, 1x306, 1x472, 1x125, 1x8443, 1x28, 1x966)

Поставил себе PCAPdroid на телефон, и выяснилось, что WhatsApp (я им совсем не пользуюсь – установлен по необходимости):

• За последний месяц съел 23 MB Wi-Fi трафика.
• За сегодняшний день съел 92 MB Wi-Fi трафика.
• Постоянно открывает соединения на разные IP и всякие мутные порты (ssh, ntp, ftp).

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

Как-то более глубоко исследовать эту ситуацию, честно говоря, нет желания (да и наверняка он подобными сканированиями занимается только изредка, чтобы не привлекать к себе лишнего внимания) – поэтому всё выше написанное исключительно JFYI, без каких-либо интересных подробностей.

P.S.: Большая просьба не воспринимать это как очередную рекламу в пользу всем известного мессенджера, который сейчас активно продвигается – все совпадения случайны.

C/C++ extension

Если погуглить, то наиболее частая рекомендация сводится к использованию VS Code с расширениями C/C++ и Makefile Tools с примерно следующим .vscode/c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",

            "includePath": [
                "${workspaceFolder}/arch/x86/include/generated",
                "${workspaceFolder}/arch/x86/include",
                "${workspaceFolder}/include",
                "${workspaceFolder}/**"
            ],
            "forcedInclude": [
                "${workspaceFolder}/include/generated/autoconf.h"
            ],

            "dotConfig": "${workspaceFolder}/.config",
            "configurationProvider": "ms-vscode.makefile-tools",
            "compileCommands": "${workspaceFolder}/compile_commands.json",

            "compilerPath": "/usr/bin/gcc",
            "intelliSenseMode": "linux-gcc-x64",

            "cStandard": "gnu11",
            "cppStandard": "gnu++11"
        }
    ],
    "version": 4
}

В итоге оно работает, но очень ограниченно: навигация по коду постоянно тормозит и либо вовсе не находит часть символов, либо для части функций находит только их объявление в заголовочном файле, но не реализацию – и нормально работать в таком режиме просто невозможно, т. к. постоянно приходится переключаться на обычный поиск по содержимому файлов.

clangd

Но, как оказалось, у вышеупомянутых расширений от Microsoft есть очень достойная альтернатива в виде расширения clangd, которое работает поверх полноценного language server’а clangd. И это очень хорошая альтернатива, особенно учитывая то, что с относительно недавних пор ядро Linux поддерживает сборку clang’ом.

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

Приступаем к работе

Клонируем репозиторий:

git clone git@github.com:torvalds/linux.git

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

cp "/boot/config-$(uname -r)" .config

Устанавливаем пакеты, которые нам понадобятся для сборки:

• Fedora: sudo dnf install bc bison clang clangd elfutils-libelf-devel flex lld llvm make ncurses-devel openssl-devel xz zstd
• Ubuntu: sudo apt install bc bison clang clangd flex libelf-dev libncurses-dev libssl-dev lld llvm make xz-utils zstd

В .vscode/settings.json задаём общие настройки проекта:

{
    "[c]": {
        "editor.tabSize": 8,
        "editor.insertSpaces": false,
        "editor.detectIndentation": false,
        "editor.rulers": [80, 100]
    },
    "files.associations": {
        "*.h": "c"
    },

    "files.exclude": {
        "**/modules.order": true,
        "**/.*.*.cmd": true,
        "**/*.a": true,
        "**/*.o": true,
        "**/*.ko": true,
        "**/*.mod": true,
        "**/*.mod.c": true,
        "**/*.symvers": true
    }
}

Далее устанавливаем расширение clangd – либо через интерфейс VS Code, либо с помощью команды code --install-extension llvm-vs-code-extensions.vscode-clangd.

И я очень рекомендую добавить следующий параметр в настройки VS Code, в котором после -j указать количество ядер в вашем процессоре, т. к. по какой-то причине clangd по умолчанию при индексации использует только часть из них, что на таком большом проекте, как ядро Linux, приводит к невероятно долгой первичной индексации:

{
    "clangd.arguments": ["-j", "10"]
}

clangd ожидает, что в корне проекта у нас будет файл compile_commands.json, в котором будут указаны опции компиляции каждого *.c-файла проекта. Именно благодаря этому файлу он может правильно проиндексировать код. Поэтому запускаем следующую команду:

make -j "$(nproc)" LLVM=1 compile_commands.json

… и идём заниматься своими делами – работать оно будет довольно долго.

Как только make отработает, и у нас появится compile_commands.json, открываем в VS Code любой *.c-файл, чтобы стриггерить clangd – и он тут же начнёт индексировать наш проект (в status bar будет соответствующая информация о прогрессе индексации). Тут тоже придётся подождать какое-то время, но только в первый раз – при последующем переоткрытии проекта оно будет подхватываться гораздо быстрее.

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

Работа с кодом ядра из MacOS

В качестве рабочего инструмента у меня MacBook Pro M1 и, казалось бы, это не самая удобная конфигурация для того, чтобы копаться в исходниках ядра, но, к счастью, это не так.

Устанавливаем OrbStack и создаём себе виртуальную машину:

orbctl create ubuntu kernel

При этом, несмотря на то, что OrbStack поддерживает эмуляцию x86 через Rosetta, в ней нет необходимости, т. к. при сборке ядра мы можем использовать кросс-компиляцию.

Заходим на нашу виртуальную машину:

orb

и клонируем наш репозиторий.

Добавляем в самое начало ~/.vscode/ssh/config следующую строку:

Include ~/.orbstack/ssh/config

А затем с помощью расширения Remote - SSH подключаемся VS Code’ом к нашей виртуальной машине и выполняем все действия, которые были перечислены в предыдущем разделе, но за одним исключением – при вызове make необходимо указать ARCH=x86, чтобы наша ARM’овая виртуалка собрала ядро под целевую архитектуру (x86-64):

make -j "$(nproc)" LLVM=1 ARCH=x86 compile_commands.json

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

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

Ликбез по организации памяти в Linux

Смотреть на счётчики ядра без понимания, что именно они измеряют, нет никакого смысла – поэтому начнём с описания базовых принципов того, как оно вообще работает под капотом (упрощая – иначе нужно писать не статью, а целую книгу).

Free-память

Пожалуй, первое, о чём стоит упомянуть – так это о том, что если вы посмотрите на систему, которая проработала какое-то ненулевое количество времени не вхолостую, то у неё, как правило, будет очень маленькое количество free-памяти. И это полностью нормально, т. к. под free-памятью Linux понимает именно память, которая полностью свободна, и в ней ничего не хранится. Но это слишком ценный ресурс, чтобы просто так простаивать без дела – и ядро всегда пытается использовать всю свободную память с пользой и занять её какими-нибудь кэшами, которые будут ускорять работу системы, но при необходимости всегда могут быть быстро освобождены. Поэтому, как правило, на большинстве систем всю свободную память занимает page cache.

Page cache

Если вы напишете программу, которая записывает в файл какие-то данные, а затем эта (или даже другая) программа будет его читать, то можно заметить интересную особенность: даже если файл очень большой (гигабайты), но меньше объёма свободной памяти, то и операции записи, и операции чтения из файла будут происходить очень быстро – гораздо быстрее, чем может работать диск под ними.

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

Данная подсистема ядра называется page cache, и смысл её работы (упрощённо) следующий: при работе с любым блочным устройством все (если специально не попросить обратного – см O_DIRECT в open(2)) операции чтения и записи происходят через page cache. Если ядру необходимо считать какую-то информацию с диска, то оно считывает её в page cache страницами по 4 KiB, и уже затем доступ к данным происходит через него. При записи также сначала информация попадает в page cache, и только потом асинхронно сбрасывается на диск (если не попросить это сделать досрочно через вызов fsync(2)). Это приводит к интересной особенности – в общем случае, когда нет memory pressure (о нём поговорим ниже), запись всегда происходит мгновенно (т. к. мы по сути пишем в память, а не на диск), а вот чтение может быть долгим (если файл ещё не закэширован в page cache).

Вообще, page cache – это невероятно универсальный и крутой механизм, который используется практически повсюду. К примеру:

1. С помощью него можно за-mmap(2)‘ить файл в память и работать с ним так, как будто вы работаете с обычной памятью. При этом ОС автоматом будет подгружать данные, когда вы обращаетесь к конкретному участку памяти и даже больше – ещё до того, как попытаетесь обратиться – за счёт механизмов prefetching.
2. Знаете ли вы, как программы загружаются на исполнение? Наивный (и на первый взгляд логичный) ответ звучал бы так, что ядро выделяет блок памяти и считывает туда бинарь с диска, а затем передает управление на исполнение. Но на самом деле всё устроено гораздо интереснее: когда вы запускаете какое-либо приложение, Linux по сути просто mmap(2)‘ит бинарник в память процесса – и передаёт управление на нужную инструкцию, а дальше уже по мере того, как процессор прыгает по этим инструкциям, подгружает данные в page cache и отдаёт оттуда. Поэтому даже очень толстые бинари потребляют небольшое количество памяти, если по факту исполняется только небольшая часть их кода. Правда, есть и другой side effect: в случае memory pressure (см. ниже) система может сбросить page cache загруженных бинарей, и даже если у вас в системе нет swap-файла, у вас будут точно такие же задержки, как и в случае, когда ОС выгрузила ваши данные на диск.

Очень рекомендую почитать Linux Page Cache for SRE для более глубокого погружения в тему.

Buffers

Вот этот счётчик, на удивление, является самым запутанным по сравнению со всеми остальными. Вся информация, которая сходу гуглится по нему, довольно противоречивая, а в документации и вовсе написано “Relatively temporary storage for raw disk blocks shouldn’t get tremendously large (20MB or so)” – при том, что я регулярно вижу как он показывает гигабайты.

Но на самом деле всё довольно просто: в ранних версиях Linux ту работу, которую сейчас выполняет подсистема Page Cache, выполняли две отдельные подсистемы. Теперь это уже не так, но в /proc/meminfo сохранено старое поведение, и счётчики Cached и Buffers отображают статистику разного типа кэшей:

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

Другими словами:

• Cached увеличивается в результате следующих команд: cat /dev/urandom > out, cat big_file > /dev/null;
• Buffers увеличивается в случае ls -laR / > /dev/null и dd if=/dev/sda of=/dev/null bs=10M status=progress.

Анонимная память

Технически, page cache – это страницы памяти, которые кэшируют содержимое блочного устройства и таким образом привязаны к нему. В противоположность page cache’у существует анонимная (anonymous) память, у которой нет никакого backing-файла, и которая существует сама по себе.

Если не вдаваться в лишние в данном случае детали, то правильнее всего будет сказать, что анонимная память – это по сути вся userspace-память процессов: стек, глобальные переменные и куча.

shmem (shared memory)

Под shared memory подразумеваются следующие вещи:

1. Анонимные блоки памяти, которые создаются с помощью mmap(2) + MAP_ANONYMOUS | MAP_SHARED для совместного использования несколькими процессами.
2. tmpfs – виртуальная файловая система, которая полностью находится в памяти. К примеру, /run – это tmpfs. Некоторые дистрибутивы также монтируют tmpfs в /tmp – поэтому никогда не сохраняйте туда большие файлы! Для этого существует /var/tmp, который всегда лежит на диске.
3. POSIX IPC API (shm_overview(7), sem_overview(7)), которое на самом деле в Linux реализовано поверх того же tmpfs, который монтируется в /dev/shm.

Кстати, интересный и очень неочевидный факт: в Linux все файловые системы работают поверх page cache’а – и по этой причине всё, что вы размещаете в tmpfs, засчитывается как page cache. Просто это такой несколько необычный page cache – под которым нет никакого файла, а есть только “закэшированные” страницы в памяти.

swap

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

При этом, когда процесс обращается к памяти, которая выгружена в swap, ядро не сразу перемещает эту память из swap’а в оперативную. Вначале оно просто подгружает нужные страницы в память, не удаляя их из swap’а (чтобы в случае чего можно было быстро опять от них избавиться, если их не успеют поменять) – такое состояние страниц называется swap cached.

Есть ещё различные дополнительные варианты, в число которых входит zswap – когда перед реальным swap’ом строится in-memory cache, в котором выгруженные страницы хранятся в сжатом виде. Очень интересная вещь – рекомендую.

Вообще, тема (необходимости) swap’а – довольно холиварная и тянет на отдельную статью. Поэтому я мог бы тут порекомендовать почитать, к примеру, In defence of swap: common misconceptions.

Page tables

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

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

Более подробно про page tables можно почитать в документации к ядру.

Active/inactive/unevictable

Вся анонимная, page cache и swap cache-память классифицируется на:

• active – страницы, к которым недавно производился доступ;
• inactive – страницы, к которым давно никто не обращался;
• unevictable – страницы анонимной памяти, которые нельзя выгрузить в swap. Как правило, это страницы, которые явно были залочены в памяти через вызов mlock(2).

В случае нехватки памяти ядро старается в первую очередь избавляться от inactive-страниц и только потом уже переходить к active-страницам.

Упрощённо, деление на active/inactive происходит следующим образом:

1. У каждой страницы есть accessed-бит (на уровне page table).
2. Если ядро обрабатывает доступ к странице по какой-либо причине, то проставляет этот флаг.
3. Если процесс обращается к странице, минуя ядро, то тогда этот флаг проставляет MMU.
4. Ядро периодически сканирует страницы и если видит выставленный accessed-бит, то зануляет его + promote’ит данную страницу из inactive в active.

Более подробно про этот механизм можно почитать в документации к ядру.

При этом важно отметить, что не стоит воспринимать inactive-страницы как “страницы, к которым не было доступа в течение N секунд” – это работает не так. Цель деления на active/inactive не в том, чтобы иметь хронометрическую статистику по активности страниц, а в том, чтобы приоритизировать все имеющиеся страницы для reclaim’а. Поэтому данное деление на самом деле очень условное и больше отражает относительную востребованность страниц между собой, нежели фактическую. Общее представление о механизме балансирования страниц между этими двумя списками можно получить тут.

slab, kmalloc, vmalloc

Чтобы выполнять свою работу, ядру необходимо где-то аллоцировать память под различные структуры, в которых оно хранит текущее состояние системы. Для этих целей в ядре есть slab-аллокатор, суть которого заключается в следующем: под наиболее часто используемые структуры (пример – структура, описывающая процесс, task_struct) заводится свой пул, к которому можно обратиться и попросить аллоцировать память под новый объект. При этом когда мы возвращаем объект в пул, память не освобождается сразу (из расчёта, что через мгновение может прийти запрос на новую аллокацию), и таким образом в slab-аллокаторе, как правило, находится некоторое количество памяти, которую можно в любой момент быстро освободить, если она понадобится в другом месте.

Помимо этого, сам тип объекта в slab’е может быть помечен как reclaimable – т. е. что он по сути является кэшем, и такие объекты можно при необходимости удалить. Пожалуй самый типичный пример таких объектов – это dentry/inode-кэши, которые, в отличие от page cache’а, кэшируют уже не данные, а метаданные файлов и содержимое директорий. Благодаря им, когда вы делаете что-то вроде open("/a/b/c/d/e", ...), системе не нужно каждый раз проходиться по всем директориям в поисках конечного файла (при этом кэшируются также и негативные результаты поиска).

Как правило, slab-аллокатор используется для структур, которые создаются часто и в большом количестве, но если нужно просто аллоцировать что-то по месту, то используется kmalloc() (по смыслу напоминающий malloc(3)), который на самом деле является надстройкой над slab-аллокатором. А для выделения больших блоков памяти (но без гарантий физической последовательности страниц) используется vmalloc(), который уже никак не связан со slab’ом и аллоцирует память напрямую из buddy-аллокатора.

Более подробно про типы аллокаторов можно почитать в документации к ядру. Посмотреть разбивку по текущему использованию slab’а можно командой slabtop -sc.

Reclaimable-память и memory pressure

В процессе своей работы ядро мониторит текущее состояние памяти и:

1. Вытесняет неиспользуемую память в swap, чтобы её можно было использовать с большей пользой (к примеру, под page cache);
2. Проактивно освобождает память, если есть признаки того, что скоро она может закончиться;
3. Агрессивно освобождает память, если её осталось совсем мало.

С этой целью в ядре:

1. Есть конфигурируемые пороги на количество свободной памяти, которые триггерят проактивное и агрессивное освобождение (reclaim) памяти. Проактивное – когда память заранее reclaim’ит выделенный background-тред; агрессивное – когда уже сами процессы вынуждены тратить своё процессорное время на reclaim, чтобы найти свободную страничку памяти.
2. Есть представление о том, что в случае нехватки памяти можно сбросить все кэши, о которых шла речь выше (правда, если это грязный page cache, то его сначала придётся записать на диск).
3. Есть деление на active и inactive-память, и ядро старается в первую очередь вытеснять inactive-страницы.

Общий принцип работы memory pressure очень хорошо описан в Linux Performance Tuning: Dealing with Memory and Disk IO + перевод – рекомендую почитать.

Kernel stack

Как вы, вероятно, знаете, у каждого треда в рамках процесса есть свой стек. Но, что интересно, на самом деле у него их два – user space и kernel space. Помню, когда-то давно мне казалось, что системный вызов – это как вызов API некоторого сервиса: мы послали запрос, его положили в очередь на обработку, а нас поставили на паузу, пока на той стороне не найдут время его обработать. Но ядро работает не так. :) Когда вы делаете системный вызов, то происходит переключение контекста – и по сути продолжается работа вашего треда – только уже выполняется код ядра, который обрабатывает системный вызов, и этому коду нужен свой стек для работы.

Кстати, потребление CPU как раз по этой причине делится на user и system: т. е. это и правда время работы конкретного процесса/треда (task в терминах ядра), но в разных контекстах.

Мониторим /proc/meminfo

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

Сразу скажу, что не буду в рамках этой статьи пытаться ставить какие-то особо амбициозные цели замониторить всё, что только можно с максимальной детализацией – и ограничусь той информацией, которую даёт нам /proc/meminfo. NUMA, zones, huge pages, фрагментацию и пр. тоже учитывать не будем – это переусложнит задачу, а реальная необходимость в этом есть только в довольно специфичных случаях.

К счастью, в плане сбора метрик всё уже сделано за нас – Prometheus Node Exporter высвечивает все счётчики из /proc/meminfo в виде метрик node_memory_*. А вот с интерпретацией получившихся значений придётся поработать самим: во-первых, часть из них пересекается по учитываемым ими страницам памяти – и не всегда очевидно, что именно нужно вычитать/суммировать, чтобы получить разбивку, а во-вторых, документация к ним местами крайне расплывчатая, и сходу не всегда понятно, что именно они считают.

Поэтому вооружаемся документацией, исходниками и информацией, представленной выше – и идём смотреть, что же мы можем отсюда почерпнуть.

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

Memory usage

Первым делом попробуем сделать график максимально общей картины с высоты птичьего полёта, на котором отделим “реально используемую” память от всякого рода кэшей:

• Free = MemFree
• Caches = Cached - Shmem + Buffers + KReclaimable
• Used = MemTotal - Free - Caches

Used memory

Тут детализируем всю память, которая не является кэшами:

• Anonymous = AnonPages
• Slab = SUnreclaim
• Swap cached = SwapCached
• zswap = Zswap – память, которую потребляет подсистема zswap
• Page tables = PageTables + SecPageTables
• Kernel stacks = KernelStack
• vmalloc = VmallocUsed - KernelStack (в современных ядрах kernel stack выделяется через vmalloc)
• percpu = Percpu
• shmem = Shmem

Caches

Здесь более детально отобразим, какие именно кэши сколько у нас занимают:

• Page cache = Cached - Shmem
• Buffers = Buffers
• Slab = SReclaimable
• Misc = KReclaimable - SReclaimable

Запускаем sync && echo 3 > /proc/sys/vm/drop_caches (см. документацию) – и наблюдаем, как много из этих кэшей система может освободить на самом деле (спойлер: далеко не всё).

При этом стоит отметить, что может быть и обратная ситуация – когда reclaimable памяти на самом деле больше, чем видно на первый взгляд. Очень показательным примером такого случая являются zombie memory cgroups.

Unknown

Как бы нам ни хотелось детализировать абсолютно всю память, на 100% это сделать невозможно – просто потому, что некоторые аллокации делаются напрямую из buddy-аллокатора и не крутят никакие счётчики. Поэтому какая-то часть выделенной памяти (как правило, небольшая) будет вне наших подсчётов, и важно тут не забыть про неё:

Unknown = MemTotal - MemFree - (AnonPages + SwapCached + Zswap + SUnreclaim + VmallocUsed + PageTables + SecPageTables + Percpu) - (Cached + Buffers + KReclaimable)

Тут, кстати, будет не лишним уточнить, что же такое на самом деле MemTotal. При запуске ядро обнаруживает всю память, доступную в системе, и под каждую физическую страницу создаёт структуру struct page, которыми затем оперирует buddy-аллокатор. MemTotal при этом отражает общий размер памяти, доступный для аллокации, т. е., грубо говоря, количество struct page, умноженное на размер страницы (и не включает в себя память, занятую самим buddy-аллокатором, а также зарезервированную под аппаратное обеспечение и память, в которой находится код ядра). Именно поэтому он всегда меньше размера физической памяти.

Available memory

Здесь у нас будет всего одна метрика – MemAvailable. Она представляет из себя оценочное количество памяти, которое доступно приложениям для аллокации без ухода в swap.

Вычисляется она следующим образом: берутся все свободные страницы, к ним добавляется весь page cache и reclaimable-память ядра + делаются поправки на watermark’и memory pressure и тот факт, что абсолютно всю память по-reclaim’ить всё равно не получится, т. к. по факту какая-то её часть всё равно нужна для нормальной работы системы.

Memory swappiness

Тут попробуем отобразить, как ядро видит пользовательскую память с точки зрения возможности reclaim’а:

• Active anonymous = Active(anon)
• Inactive anonymous = Inactive(anon)
• Active page cache = Active(file)
• Inactive page cache = Inactive(file)
• Unevictable = Unevictable

Page cache writeback

На этом графике будем наблюдать за объёмом грязного page cache’а и тем, как система справляется с синхронизацией его страниц на диск.

• Writeback = Writeback – объём грязного page cache’а, который в данный момент пишется на диск
• Dirty = Dirty – грязные страницы, которые пока только ждут своей очереди

Swap usage

• Cashed = SwapCached – закэшированные в памяти страницы swap’а
• zswapped = Zswapped – объём памяти, выгруженный в zswap
• Swapped out = SwapTotal - SwapFree - SwapCached - Zswapped – выгруженная (и не закэшированная) на диск память

zswap

Тут у меня есть свой zswap exporter, который позволяет дополнительно следить за:

1. Степенью сжатия, которую мы на самом деле получаем;
2. Заполнением zswap-пула;
3. Причинами, по которым страницы пролетели мимо zswap.

Результат

В итоге получаем вот такую красоту:

Согласованность данных

Это может быть довольно неочевидным, но счётчики, которые выдаёт /proc/meminfo (наравне со многими другими файлами в proc/sysfs), могут быть несогласованными между собой. А именно: при сборе статистики ядро атомарно читает/считает отдельные значения, но не берёт какую-либо блокировку, которая гарантировала бы согласованность полученных значений. Это осознанный компромисс разработчиков ядра, чтобы сбор данных для мониторинга (для которого такая несогласованность обычно не критична) не замедлял работу системы. Поэтому стоит учитывать данный факт, если вы используете их для каких-то более ответственных целей, нежели рисования графиков (к примеру, при вычитании одних чисел из других периодически могут получаться отрицательные значения).

Наглядный пример: изменение nr_huge_pages + surplus_huge_pages + free_huge_pages всегда производится под hugetlb_lock, но вот при сборе статистики ядро полагается исключительно на атомарное чтение отдельных long-переменных.

Заключение

Выше мы с вами мониторили всю систему целиком. Это, безусловно, очень интересно, но сразу же возникает желание пойти дальше – и видеть, какой именно сервис триггерит то или иное движение на графиках. И это можно сделать благодаря systemd + cgroups! systemd нарезает всю систему на понятные группы процессов (у которых, в отличие от pid’ов, есть человеческое имя и, что самое важное – их конечное количество) – и если вы готовы к кратному увеличению количества метрик, то можно мониторить каждый сервис в отдельности, что выводит observability вашей системы на качественно новый уровень.

В рамках данной статьи я не буду пытаться покрыть всё, до чего могу только дотянуться – поэтому лишь намекну на такую возможность – возможно когда-нибудь это станет темой очередной статьи. А пока лишь могу поделиться своим exporter’ом, которым сам пользуюсь для этой цели – server-metrics. На данный момент он писался без мысли о том, что им может пользоваться кто-то кроме меня, но возможно для кого-то он сможет послужить источником вдохновения или рабочим примером того, как можно организовать такой мониторинг.

Посмотрел повнимательнее – curl открывает сайты бодро, Firefox – тоже, а вот в Яндекс Браузере по прежнему таймаут соединения без каких-либо объяснений причин в сетевой вкладке Developer Tools.

Ну что ж, Developer Tools ничего не говорят – пойдёмте смотреть в Wireshark, что там такого интересного происходит…

SNI, ESNI, ECH, WTF?

Для начала краткий ликбез: когда мы устанавливаем HTTPS-соединение, то, несмотря на то, что весь HTTP-запрос у нас шифруется, имя домена в TLS handshake идёт plain text’ом, т. к. оно необходимо для того, чтобы сообщить балансировщику, какой именно сайт вы хотите открыть (и для какого домена балансировщик, терминирующий TLS, должен выдать вам сертификат). Данное расширение TLS, в рамках которого передаётся имя домена, называется SNI (Server Name Indication).

Именно благодаря SNI Роскомнадзор может селективно блокировать HTTPS-ресурсы не по IP-адресам (задевая при этом ещё кучу других сайтов), а по доменным именам.

Так вот, давайте посмотрим, что нам расскажет Wireshark, когда мы набираем prometheus.io в адресной строке браузера.

Видим два DNS-запроса:

DNS Standard query 0x6d3e A prometheus.io
DNS Standard query 0x169c HTTPS prometheus.io

1. Стандартная A-запись – тут всё понятно и никаких сюрпризов;
2. А вот вторая необычная – HTTPS-запись. Я о такой даже и не слышал – как интересно. :)

Вот ответ DNS-сервера:

prometheus.io: type HTTPS, class IN
    Name: prometheus.io
    Type: HTTPS (65) (HTTPS Specific Service Endpoints)
    Class: IN (0x0001)
    Time to live: 277 (4 minutes, 37 seconds)
    Data length: 136
    SvcPriority: 1
    TargetName: <Root>
    SvcParam: alpn=h3,h2
        SvcParamKey: alpn (1)
        SvcParamValue length: 6
        ALPN length: 2
        ALPN: h3
        ALPN length: 2
        ALPN: h2
    SvcParam: ipv4hint=104.21.60.220,172.67.201.240
        SvcParamKey: ipv4hint (4)
        SvcParamValue length: 8
        IP: 104.21.60.220
        IP: 172.67.201.240
    SvcParam: ech
        SvcParamKey: ech (5)
        SvcParamValue length: 71
        ECHConfigList length: 69
        ECHConfig: id=131 cloudflare-ech.com
    SvcParam: ipv6hint=2606:4700:3030::6815:3cdc,2606:4700:3030::ac43:c9f0
        SvcParamKey: ipv6hint (6)
        SvcParamValue length: 32
        IP: 2606:4700:3030::6815:3cdc
        IP: 2606:4700:3030::ac43:c9f0

А вот наш TLS handshake с балансером, за которым находится prometheus.io:

TLSv1 Record Layer: Handshake Protocol: Client Hello
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 512
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 508
        Version: TLS 1.2 (0x0303)
        ...
        Extension: server_name (len=23) name=cloudflare-ech.com
            Type: server_name (0)
            Length: 23
            Server Name Indication extension
                Server Name list length: 21
                Server Name Type: host_name (0)
                Server Name length: 18
                Server Name: cloudflare-ech.com
        ...

Ого, всё ещё интереснее: несмотря на то, что мы идём на https://prometheus.io/, самому серверу мы в SNI указываем какой-то cloudflare-ech.com, который как раз нам выдал HTTPS DNS-запрос.

Идём гуглить – и узнаём, что HTTPS DNS-запись призвана:

1. Уменьшить latency загрузки сайта, т. к. сразу предоставляет A и AAAA-записи, а также список поддерживаемых протоколов (HTTP/2, HTTP/3).
2. Увеличивает безопасность соединения при первичном открытии сайта, когда в браузере ещё нет закешированного HSTS.
3. ECH stands for Encrypted Client Hello.

Когда-то давно я читал про ESNI (Encrypted Server Name Indication), который призван решить проблему plain text’овости домена в TLS, и даже не раз приходилось слышать, что Роскомнадзор блокирует ESNI как раз по той причине, то он не позволяет фильтровать HTTPS-трафик. Но вот ECH (Encrypted Client Hello), который по сути является логическим развитием ESNI, как-то проходил мимо меня – как что-то из ещё неопределённого будущего.

Почитав про ECH, мы узнаём, что схема работает следующим образом:

1. Браузер запрашивает HTTPS DNS-запись.
2. Данная запись помимо IP-адресов включает в себя публичный домен-заглушку cloudflare-ech.com + открытый ключ.
3. При установке соединения с сервером, браузер в SNI (в открытой части Client Hello) передаёт ни о чём не говорящий cloudflare-ech.com, а в закрытой – уже в зашифрованном виде, настоящий домен.
4. РКН видит это, расстраивается, что ему не видно конечный домен – и блокирует соединение.

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

Как обойти

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

Если же хочется какого-то более универсального решения, то достаточно вспомнить о том, с чего всё началось, а именно – с HTTPS-записи. Поэтому решение, которое выбрал я (по крайней мере пока) – это просто взять и заблокировать HTTPS DNS-запись на своём роутере. В моём случае это решается добавлением filter-rr=HTTPS в конфиг dnsmasq.

Имея такую конфигурацию, наш DNS-сервер, находящийся на роутере, будет reject’ить запросы HTTPS-записей, и браузер будет получать только обычные A и AAAA-записи, что вынудит его работать по старинке без всяких ECH. РКН будет видеть, что вы действительно заходите на незаблокированный ресурс и не будет резать соединение.

Ставить (а особенно обновлять) такие приложения руками – занятие неблагодарное, особенно когда их количество становится больше одного-двух – и хочется какой-то автоматизации. У меня таких программ около десятка, и довольно долгое время я пользовался различными наколеночными скриптами вроде этого для поддержания их актуальности. Но bash-скрипт – это всё-таки как-то несерьёзно, и поэтому всегда хотелось чего-то более управляемого в виде нормального приложения. Найти что-то готовое, что удовлетворяло бы всем моим потребностям, мне сходу не удалось – поэтому некоторое время назад решил пойти моим излюбленным путём и написать своё приложение под эту конкретную задачу.

binup

Пара недель кодинга по вечерам – и родилась утилита binup. Сегодня я зарелизил версию 1.0.0 и полностью перешёл на неё со своих скриптов. Буду рад, если получившаяся тула будет полезна кому-то кроме меня.

Вот как она работает: вы создаёте конфигурационный файл ~/.config/binup/config.yaml с примерно следующим содержимым, в котором описываете конкретное приложение (как его найти на GitHub):

tools:
  binup:
    project: KonishchevDmitry/binup
    release_matcher: binup-linux-x64-*

… запускаете binup install или binup upgrade – и тула устанавливает, либо обновляет указанные вами приложения.

Работает binup довольно просто: она нигде не хранит никакую информацию об установленных приложениях, а вместо этого при запуске смотрит на их текущий статус: если нужного бинарника нет, то устанавливает его; если же есть, то пробует запустить приложение с --version, чтобы определить текущую версию приложения и сравнить её с последним релизом на GitHub. Если же версию определить не удалось (к примеру, программа вовсе может не поддерживать флаг --version), то binup ориентируется на время модификации файла, которое при установке приложения задаёт равным времени модификации релиза.

Конфигурация

Вот пример конфигурационного файла со всеми доступными на данный момент опциями:

# Path where to install the binaries (the default is ~/.local/bin)
path: /usr/local/bin

tools:
  # Binary name
  prometheus:
    # GitHub project name
    project: prometheus/prometheus

    # Changelog URL (will be printed on app upgrade)
    changelog: https://github.com/prometheus/prometheus/blob/main/CHANGELOG.md

    # Release archive pattern:
    # * By default shell-like glob matching is used (https://docs.rs/globset/latest/globset/#syntax)
    # * Pattern started with '~' is treated as regular expression (https://docs.rs/regex/latest/regex/#syntax)
    release_matcher: prometheus-*.linux-amd64.tar.gz

    # Binary path to look for inside the release archive. If it's not specified, the tool name will be used.
    binary_matcher: "*/prometheus"

    # Post-install script
    post: systemctl restart prometheus

# If you have a lot of tools, you may hit GitHub API rate limits for anonymous requests at some moment.
# So it's recommended to obtain GitHub token (https://github.com/settings/tokens) and specify it here.
# No permissions are required for the token – it's needed just to make API requests non-anonymous.
github:
  token: $token

Последующее развитие

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

Пока что из наиболее явных потенциальных фичей видится поддержка GitLab, если возникнет такая необходимость (лично у меня пока что нет ни одного приложения с него), а также явно напрашивается генерация какого-то дефолтного release_matcher‘а в зависимости от текущей ОС и архитектуры.

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

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

На всякий случай сразу оговорюсь, что почти всё написанное ниже подразумевает, что у вас есть свой личный домен, с которого вы будете отправлять почту, т. к. ни один уважающий себя почтовый сервис не будет серьёзно относиться к письмам, отправленным с условного localhost’а, и будет (хотя бы периодически) расценивать их как спам. Домен стоит не так уж и дорого – конкретно в моём случае это 250 руб. в год, что является вполне приемлемой суммой даже для домашнего сервера.

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

Пример настройки будет описан для Ubuntu, но завязок на конкретный дистрибутив, как таковых, не будет. В качестве имени домена везде ниже буду использовать example.com.

Postfix

В качестве почтового сервера будем использовать Postfix. Рекомендую почитать на сайте их документацию – она достаточно подробная и даёт понимание, как оно работает под капотом.

Итак, ставим пакет:

sudo apt install postfix

В случае с Debian/Ubuntu он запустит интерактивный скрипт dpkg-preconfigure, который сгенерит нам базовую конфигурацию. В отобразившемся диалоге выбираем “Internet Site” и вводим имя своего домена. Особого смысла в этой конфигурации для нас нет, т. к. мы всё равно ниже всё переконфигурим, и пожалуй единственное что от неё останется – это Debian-specific файл /etc/mailname, в который будет прописано имя нашего домена, чтобы его могли использовать почтовые клиенты.

У Postfix два основных конфигурационных файла:

• /etc/postfix/master.cf, который описывает, как именно будут запускаться различные демоны, из которых состоит почтовый сервер. Его лучше не трогать и менять только тогда, когда вы действительно знаете, что делаете.
• /etc/postfix/main.cf – в нём будут храниться все основные настройки.

Заменяем /etc/postfix/main.cf следующим содержимым:

# man 5 postconf

# See http://www.postfix.org/COMPATIBILITY_README.html
# Restart postfix server and look into /var/log/mail.log for complains about new defaults
compatibility_level = 3.8

# Used in default values of many variables. Specifies what domain to use for outbound mail
myhostname = example.com
mydomain = $myhostname

# Domains which will be delivered locally instead of forwarding to another machine
mydestination = localhost $myhostname

# Rewrite (possibly local) sender domain to our external domain
sender_canonical_maps = static:@$myorigin

# Interfaces to listen on
inet_interfaces = loopback-only

# Forward mail from local host only
mynetworks_style = host

# Redefine the default to disable NIS support
alias_maps = hash:/etc/aliases

# A little hardening
allow_mail_to_files =
allow_mail_to_commands =

# Relay mail only via TLS. Since it's too strict setting for generic server which should be able to send mail to any
# server on the Internet, it's reasonable when we send messages only to well-known servers like Gmail.
smtp_tls_security_level = verify
smtp_tls_CApath=/etc/ssl/certs

# Generate delayed mail warnings
delay_warning_time = 4h

# Errors to notify postmaster@ about
notify_classes = 2bounce, data, delay, policy, protocol, resource, software

Здесь необходимо прописать в myhostname ваш домен, а также перечислить в mydestination все домены, с которых локальные сервисы могут прислать почту.

Логика тут следующая: если в To: письма указано только имя пользователя (скажем dmitry), то Postfix автоматом понимает, что это письмо предназначено для нашего домена (локальной доставки), но если в качестве имени пользователя указано, скажем, dmitry@server, то необходимо проинструктировать Postfix, что server – это на самом деле тоже наш домен. Необходимость в этом возникает, к примеру, когда hostname вашего сервера (значение в /etc/hostname) отличается от почтового домена, и неправильно настроенная программа отправки почты может генерировать To-адреса используя это имя сервера.

Далее заводим пользователя postmaster:

sudo useradd -d /nonexistent -s /usr/sbin/nologin -r postmaster

Это well-known имя пользователя, которому Postfix будет посылать сообщения о различных ошибках (например, доставки почты).

Заменяем /etc/aliases следущим содержимым:

# man 5 aliases

root:   example@gmail.com
dmitry: example@gmail.com

Логика тут следующая: у нас есть два активных пользователя – root и dmitry, которым система может слать почтовые сообщения. В моём случае это преимущественно cron, который отсылает stdout/stderr своих джоб пользователю по почте, но, к примеру, их также шлёт sudo, если 3 раза неправильно ввести пароль. Данные директивы говорят Postfix о том, что необходимо принимать почту для этих двух пользователей не локально, а пересылать её на наш Gmail-ящик.

Если же Postfix не сможет доставить почту по данным адресам (Gmail отклонит её по какой-то причине), то информация об этом будет направлена пользователю postmaster.

Несмотря на то, что в main.cf у нас прописан /etc/aliases, Postfix будет считывать файл /etc/aliases.db, который является скомпилированным бинарным представлением этого конфига. Поэтому после каждой правки /etc/aliases необходимо запускать sudo newaliases, чтобы она создала /etc/aliases.db.

На этом базовая настройка закончена. Перезапускаем сервер и смотрим в его лог:

sudo systemctl restart postfix && sudo tail -f /var/log/mail.log

Проверка пересылки

Проверяем:

sudo apt install mutt
mutt -s 'Test mail' "$(whoami)" <<< 'Message body'

– письмо должно уйти на наш Gmail-аккаунт.

Проверка локальной доставки

Чтобы быть в курсе всех проблем с отправкой почты, я выставил пользователю root переменную окружения MAIL=/var/mail/postmaster: своего ящика у него всё равно больше нет (вся почта перенаправляется в Gmail), но зато теперь bash будет автоматически уведомлять меня о всех новых сообщениях пользователя postmaster.

Проверяем работу данной схемы:

1. Логинимся под root.
2. От любого пользователя запускаем mutt -s 'Test mail' postmaster <<< 'Message body'.
3. root’овый bash должен написать в терминал You have mail in /var/mail/postmaster.
4. Смотрим почту (к примеру, при помощи того же mutt).

SPF, DKIM, DMARK

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

Рекомендую почитать какой-нибудь tutorial по SPF/DKIM/DMARK, о которых пойдёт речь ниже, чтобы было понимание, что именно мы будем делать. К примеру, вот этот.

PTR

Первым делом стоит удостовериться, что у вашего сервера правильная PTR-запись. Не всегда есть возможность её поменять – у меня, к примеру, в силу определённых причин её нету, и мне (пока?) это не мешает, но почтовые сервисы на неё точно смотрят, и желательно, чтобы она указывала на ваш домен.

SPF

С помощью SPF мы зададим список IP-адресов, с которых можно отсылать письма от имени нашего домена.

Добавляем следующую DNS-запись:

example.com. IN TXT "v=spf1 a ~all"

которая разрешает отправлять их только с тех IP, в которые резолвится наш example.com. Я использую ~all вместо -all, т. к. в моём случае вряд ли кто-то будет заниматься спуфингом от моего имени, и в случае какой-то мисконфигурации я бы предпочёл получить свои письма в спам, чем не получить их вовсе.

Если вам хочется задать другие правила, то можно воспользоваться SPF-генератором.

DKIM

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

Реализовывать его будем с помощью OpenDKIM.

Ставим пакет:

sudo apt install opendkim

Генерируем ключи:

sudo opendkim-genkey --domain example.com --selector server --nosubdomains --restrict --directory /etc/dkimkeys

server здесь – это DKIM selector – произвольный идентификатор ключа. Нужен он потому, что их может быть несколько: у каждого сервера по ключу, либо в целях периодической ротации ключей.

Смотрим в /etc/dkimkeys/server.txt и прописываем получившуюся запись в DNS. Тут, правда, вас может ждать неудача: запись получается довольно длинная, и некоторые хостеры (к примеру, мой) просто отказываются её принимать. В таком случае можно сгенерировать чуть менее безопасный ключ, который будет меньшего размера:

sudo opendkim-genkey --domain example.com --selector server --bits 1024 --nosubdomains --directory /etc/dkimkeys

Проверяем, что всё прописалось правильно:

sudo opendkim-testkey -d example.com -s server -k /etc/dkimkeys/server.private

Меняем права на ключи:

sudo chown opendkim:opendkim /etc/dkimkeys/server.{private,txt}

и начинаем конфигурировать сам сервис.

В Debian/Ubuntu Postfix запускается в chroot’е, и если UNIX-сокет OpenDKIM-сервера будет находиться вне его, то они просто не смогут общаться между собой. Поэтому содаём следующую директорию:

sudo install -d -o opendkim -g postfix -m 710 /var/spool/postfix/opendkim
sudo chmod g+s /var/spool/postfix/opendkim

Создаём /etc/systemd/system/opendkim.service (конфигурация сервиса, которая поставляется с дистрибутивом, довольно странная – и лучше написать свою):

[Unit]
Description=OpenDKIM Milter
Before=postfix.service

[Service]
User=opendkim
NoNewPrivileges=true
MemoryDenyWriteExecute=true
ProtectSystem=true
PrivateTmp=true
ExecStart=/usr/sbin/opendkim

[Install]
WantedBy=multi-user.target

Заменяем /etc/opendkim.conf на:

Background no

Syslog yes
SyslogSuccess yes

Mode s
Domain example.com
Selector server
KeyFile /etc/dkimkeys/server.private

# Postfix chroots into /var/spool/postfix, so we have to create SGID directory there and use permissive umask
Socket local:/var/spool/postfix/opendkim/opendkim.sock
UMask 007

Добавляем в /etc/postfix/main.cf:

# DKIM signing
smtpd_milters = unix:opendkim/opendkim.sock
non_smtpd_milters = unix:opendkim/opendkim.sock

Проверяем, работоспособность всей схемы:

sudo systemctl daemon-reload && sudo systemctl restart opendkim postfix && sudo tail -f /var/log/mail.log
mutt -s 'Test mail' "$(whoami)" <<< 'Message body'

DMARK

Ну и последний штрих, который нам остался – это DMARK. Воспользуемся DMARK-генератором и получим следующую DNS-запись:

_dmarc IN TXT "v=DMARC1; p=quarantine; sp=none; aspf=s; adkim=s;"

Как и с SPF, для наших целей лучше подойдёт p=quarantine.

Email для aggregate/forensic reports не указываем, т. к. это опять-таки не наш случай:

• Aggregate Reports – это ежедневная рассылка XML-файлов, которая имеет смысл только если вы – какая-то большая организация и перенаправляете их в соответствующий сервис для последующего анализа.
• Forensic Reports и вовсе не поддерживаются в Gmail.

Заключительные шаги

После того, как мы всё настроили, самое время пойти посмотреть, что про наши письма думают почтовые сервисы:

1. Нажимаем на вертикальное троеточие в сообщении в Gmail и выбираем пункт “Show original” – там в самом верху будут статусы вида “SPF/DKIM/DMARC: PASS”, а также проверяем, что само сообщение не помечается красным флажком “No encryption” (в настройках Postfix мы указали отправку только по защищённому каналу). Есть ещё Google Postmaster Tools, но они выглядят какими-то полузаброшенными: дашборд с графиками объявлен устаревшим и упорно отказывается показывать хоть какие-то графики даже после того, как я в течение недели слал себе каждую минуту какие-то сообщения (утверждается, что они могут не отображаться при небольшом количестве сообщений); в Compliance status в итоге все зелёные кружочки у меня загорелись, но только спустя неделю.
2. Заходим на mail-tester.com и отправляем сообщение на адрес, который он нам предложит, используя команду вида mutt -s 'Test mail' test-m2rbwe4su@srv1.mail-tester.com <<< 'Message body'. Высокого рейтинга нам в нём ждать не стоит: он проверяет содержимое сообщения на спам (и тогда надо отсылать что-то реальное, чтобы не поджечь их лампочки), а также у нас нет MX-записи для входящей почты, что в его понимании выглядит крайне подозрительным. Но наша цель тут – не попытаться получить максимальный рейтинг по всем параметрам, а убедиться, что его устраивает всё, что касается только отправки писем.

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

Когда я писал свой тоннель, у меня было стойкое убеждение, что в качестве транспорта нужно прежде всего ориентироваться на UDP, а на TCP откатываться только в том случае, когда UDP перестаёт работать в силу тех или иных “причин”. И это вроде бы логично: в плане производительности для тоннеля UDP всегда предпочтительнее, т. к. он реализует именно то, что нам нужно – максимально тонкую обёртку над пакетами, а с TCP у нас начинается целый ворох проблем, начиная с TCP Meltdown и заканчивая head-of-line blocking.

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

BBR

BBR (Bottleneck Bandwidth and RTT) – это алгоритм TCP congestion control, разработанный в Google. В отличие от традиционных алгоритмов, которые ориентируются на потери пакетов, BBR пытается судить о загруженности канала, наблюдая за тем, как меняется скорость передачи данных и RTT. Сейчас сети уже не те, что были в 80-ых годах, и такой подход работает гораздо лучше, а особенно – в случае трансконтинентальных соединений, где у нас может быть довольно широкий канал, но при этом небольшой процент потерь пакетов является нормой (как в моём случае с дешёвым VPS).

В результате получается, что если у вас такой канал, где нередки небольшие потери пакетов, то это сильно сказывается на скорости TCP-соединения, т. к. эти потери расцениваются традиционными алгоритмами как сигнал к тому, что необходимо сбросить скорость до тех пор, пока они не сойдут на нет. К тому же, даже в случае когда потерь нет, но при этом TCP-соединение способно утилизировать весь канал передачи данных, традиционные алгоритмы склонны снижать скорость только тогда, когда буфер роутера (зачастую довольно большой) уже переполнен, и роутер начинает дропать пакеты, что по факту является сильно запоздалой реакцией, которая приводит к увеличению latency, а BBR как раз пытается этой ситуации избежать. Этой проблеме даже посвящен целый сайт bufferbloat.net.

Польза, которую BBR способен вам нанести по сравнению со стандартным CUBIC’ом, сильно зависит от многих факторов, но вот, к примеру, отчёты Amazon и Google, которые свидетельствуют о том, что после включения BBR у них стабильно улучшились bandwidth и RTT: Amazon, Google. В определённых случаях можно ожидать и кратного увеличения скорости TCP-соединения.

Т. к. BBR является алгоритмом TCP congestion control, то включается он на отправляющей стороне. Т. е., включив его на своём ноутбуке, вы улучшите upload данных, а чтобы улучшить download, он должен быть включён на сервере. При этом, само собой, включение его на одной стороне не требует какой-либо поддержки на другой, т. к. меняются только эвристики внутри TCP-протокола, а не сам протокол.

Критика

Не обошлось правда и без критики данного алгоритма. Всё дело в том, что по сравнению со стандартным CUBIC’ом, BBR ведёт себя достаточно агрессивно, и может получиться так, что если вы, скажем, включите его на своем Linux-ноутбуке и начнёте заливать большие файлы в сеть, то ваш BBR-ноутбук может запросто “задушить” TCP-соединения соседних устройств, использующих традиционные алгоритмы TCP congestion control (а в MacOS, к примеру, BBR и вовсе недоступен).

Есть инициатива в виде BBRv2, которая пытается решить эту проблему, но пока что в ядре используется первая версия, и надо эту особенность иметь в виду.

Эффект от BBR применительно к TCP-тоннелю

Так вот, почитав всё это, я с одной стороны обрадовался (какая многообещающая штука – надо пробовать!), а с другой – тут же взгрустнул: включать BBR нужно на конечных устройствах (сервер + клиент), а на роутере его включать бесполезно, т. к. при forwarding’е пакетов все эти алгоритмы по понятным причинам не задействованы. Но на серверную часть я повлиять не могу, а в качестве клиентской у меня ноутбук с MacOS, в котором BBR и вовсе нет. С другой стороны – подумал я – у меня ведь по факту два TCP-соединения: одно между ноутбуком и конечным сервером, а другое – между двумя точками тоннеля, которые находятся на Linux-серверах, и вот на это соединение я повлиять могу.

Чтож, попробуем… Включил его для TCP-соединения своего тоннеля – и тут же получил 2.5x скорость при скачивании файлов! Если раньше что с UDP, что с TCP-транспортом у меня абсолютным максимумом было 30 Mbit/s, то после включения BBR оно тут же скакнуло до 75 Mbit/s.

Лично я такие результаты объясняю себе следующим: гоняя тоннельный траффик по TCP, я маскирую все потери пакетов между двумя точками тоннеля для TCP-соединений, которые в него заворачиваются. И даже если они используют традиционные алгоритмы, основанные на потерях пакетов, то теперь они этих потерь не замечают и не сбрасывают скорость почём зря. Ну а дальше уже эти данные передаются по TCP-соединению тоннеля с BBR, который максимизирует скорость передачи данных.

В итоге я пришёл к следующему: если раньше я всегда в качестве транспорта использовал UDP, и переключение на TCP вызывало заметные глазу подтормаживания при загрузке страниц в браузере, то теперь, когда у меня TCP работает с BBR, картина поменялась на противоположную: UDP выдаёт вполне приемлемый результат, но если переключиться на TCP, то невооружённым глазом становится видно, что всё начинает подгружаться ещё быстрее. Учитывая то, что TCP-тоннель ещё и можно замаскировать под обычное HTTPS-соединение, получается, что в использовании UDP и вовсе нет смысла. Единственное, в чём UDP по прежнему обходит TCP + BBR – это в latency: если запустить ping и начать грузить канал, то в случае с UDP latency ping’ов практически не меняется, в то время как с TCP (с BBR и без) оно может увеличиваться до четырёх раз. Но т. к. это довольно синтетический тест, а при реальном использовании с браузером, как я описал выше, я вижу противоположные результаты, то для меня это не выглядит проблемой.

Включение

Включается BBR очень просто:

sysctl net.ipv4.tcp_available_congestion_control показывает список доступных алгоритмов. Скорее всего, по умолчанию BBR там не будет:

$ sudo sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic

– это потому, что не загружен соответствующий модуль ядра.

1. Загружаем модуль – modprobe tcp_bbr (или echo tcp_bbr > /etc/modules-load.d/bbr.conf, чтобы он загружался автоматом при старте системы).
2. Включаем BBR – sysctl net.ipv4.tcp_congestion_control=bbr (или echo 'net.ipv4.tcp_congestion_control = bbr' > /etc/sysctl.d/bbr.conf, чтобы он включался автоматом при старте системы). На всякий случай замечу, что, несмотря на префикс net.ipv4.*, включение происходит как для IPv4, так и для IPv6.

При этом его можно включить не для всех, а только для отдельных TCP-соединений, передав опцию TCP_CONGESTION в setsockopt(2). И даже у iperf есть опция -C bbr, с помощью которой можно протестировать поведение различных алгоритмов TCP congestion control конкретно для вашего случая.

Last, but not least

В процессе изучения всего вышеописанного я абсолютно случайно для себя узнал, что в то время как во всех современных дистрибутивах благодаря systemd уже давно в качестве queueing discipline по умолчанию включена fq_codel, которая считается наиболее оптимальным general purpose вариантом, то в Debian/Ubuntu меинтейнеры не смогли преодолеть свою внутреннюю бюрократию – и даже в самых современных Debian/Ubuntu по умолчанию используется pfifo_fast: они не включают в systemd-пакет его стандартный конфиг, но в то же время не смогли найти “правильное место”, куда можно было бы положить аналогичные разумные default’ы – и в результате используется значение по умолчанию, которое установлено в ядре.

pfifo_fast – это самая простая queueing discipline, которая никак не приоритезирует пакеты между различными сетевыми соединениями, и может получиться так, что самое активное из них будет сильно увеличивать latency всех остальных.

Поэтому рекомендую всем пользователям Debian/Ubuntu добавить /etc/sysctl.d/00-qdisc.conf со следующим содержимым:

net.core.default_qdisc = fq_codel

чтобы исправить это недоразумение.

gmailctl – это абсолютно потрясающая утилитка, которая позволяет вовсе не использовать web-интерфейс редактирования правил обработки почты и унести их в локальный конфиг. У неё свой язык описания правил (имеющий свои преимущества), который она затем преобразовывает в формат Gmail и заменяет все существующие фильтры на описанные в вашем конфиге (не забыв при этом показать аккуратный diff изменений).

Правила могут быть как очень простые:

{
  filter: {from: "linkedin.com"},
  actions: label("LinkedIn"),
}

так и довольно развесистые:

{
  filter: {or: [
    {and: [{from: "notifications@github.com"}, {subject: "[KonishchevDmitry/"}, {subject: "] Release"}]},
    {and: [{from: "cloud@support.yandex.ru"}, {or: [
      {subject: "You have been given a grant"},
      {subject: "Planned maintenance"},
    ]}]},
    {and: [{from: "noreply@market.yandex.ru"}, {or: [
      {subject: "Вы оформили и оплатили заказ"},
      {and: [{subject: "Заказ"}, {subject: "доставлен"}]},
    ]}]},
    {and: [{from: "mailer@sender.ozon.ru"}, {subject: "Вам понравился заказ?"}]},
    {and: [{from: "mosenergosbyt.ru"}, {subject: "Электронный счёт за"}]},
  ]},
  actions: delete(),
}

Увидев это чудо, я в тот же день переколбасил все свои правила и полностью перешел на gmailctl. Они по-прежнему занимают несколько экранов монитора, но зато теперь их можно организовать удобным мне образом, объявлять функции и переменные, ставить комментарии, отделять отступами и т. п. В общем, всё как в любых нормальных декларативных языках.

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

glibc

Первая мысль была довольно предсказуемой и понятной: “пойду-ка посмотрю, как собрать статически Rust’овый бинарь с glibc” – и, на самом деле, особых проблем с этим нет. Надо всего лишь сделать вот так:

RUSTFLAGS='-C target-feature=+crt-static' cargo build --release --target x86_64-unknown-linux-gnu

– и оно работает, программа запускается без проблем!

Но, если покопать эту тему чуть более подробно, то выясняется, что решение это на самом деле – так себе. Всё дело в том, что glibc так устроена, что она в принципе не особо предназначена для статической линковки: из-за NSS, iconv(3) и пр. она полагается на dlopen(3), и определённые функции стандартной библиотеки могут стриггерить, скажем, загрузку NSS-модуля, который является динамически разделяемой библиотекой, к тому же динамически слинкованной с glibc, что в свою очередь может привести к ситуации, когда у нас в адресном пространстве приложения будут загружены две glibc: статическая и динамически подгруженная через зависимость NSS-модуля, что в итоге может привести к разным интересным последствиям (к примеру, как они будут делить буферы stdout?). Внутри неё на самом деле есть различные подпорки, чтобы статическая сборка всё-таки нормально работала в большинстве случаев, но вот только гарантий, что она будет работать во всех возможных сценариях – нет.

В итоге, большинство людей сходятся в том, что статическую сборку с glibc лучше не использовать, т. к. мы тут идём против её дизайна и рискуем получить неожиданные последствия от таких действий. И самый оптимальный вариант тут – использовать для сборки Docker-контейнер с каким-нибудь заведомо не самым свежим LTS-дистрибутивом – и линковаться против glibc его версии.

Но также есть и другие варианты.

musl

Напомню, что Linux – это только ядро, а не операционная система. Интерфейсом к ядру являются системные вызовы, и поэтому ничто не мешает нам вместо glibc использовать что-то другое. Наиболее распространённом вариантом в данном случае является musl.

Честно говоря, я musl до этого момента ни разу не пользовался, т. к. мне всегда казалось довольно странным использовать что-то нестандартное вместо glibc – обязательно ведь где-нибудь что-нибудь будет работать по-другому, и можно нарваться на какие-нибудь неприятные сюрпризы в самый неподходящий на то момент. Поэтому всегда считал, что её использование имеет смысл разве что в embedded, либо где-нибудь вроде Alpine, где нам по какой-то причине хочется получить максимально компактный образ.

Но если смотреть с позиции статической линковки, использование musl вполне имеет смысл, т. к. для неё, в отличие от glibc, статическая линковка является абсолютно стандартным вариантом использования.

Поэтому (в случае Rust) выполняем:

rustup target add x86_64-unknown-linux-musl
cargo build --target x86_64-unknown-linux-musl

– и получаем то, что нам нужно. Правда, свои “но” тут тоже есть…

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

В результате чего нередки ситуации, когда наша программа, которая без проблем работала с glibc, вдруг перестаёт работать из-за того, что в musl DNS resolver не поддерживает ответы с большим количеством записей (на самом деле уже исправлено), либо работает в десятки (!) раз медленнее – раз, два, три (как правило, в случае интенсивной аллокации памяти из нескольких потоков одновременно, но также это может быть связано и с тем, что “раздутая” glibc использует AVX и прочие инструкции для оптимизации своих функций, а “простая и компактная” musl – нет), либо у вас какая-то специфическая конфигурация, в которой проявляются отличия в реализации glibc и musl. Ну и, понятное дело, musl не подойдет, если вам нужен NSS (к примеру, в случае с LDAP).

В итоге, я бы сказал, что если у вас в качестве приложения довольно простая command line-утилита, то скорее всего проблем не будет – и для простоты можно статически линковаться с musl, но если у вас какой-то навороченный/высоконагруженный сервис, то либо стоит быть готовым к сюрпризам, либо использовать более сложную конфигурацию вроде musl + mimalloc/jemalloc в качестве аллокатора.

Eyra

Если говорить о Rust, то на самом деле есть ещё один интересный вариант – Eyra. Данный проект ставит своей целью реализовать все функции стандартной библиотеки на Rust и линковаться в процессе сборки с ними.

Этот вариант я, честно говоря, даже не пробовал (уж больно молодой проект), но идея интересная и многообещающая.

Интересный факт

Я этого не знал, но, оказывается, ABI системных вызовов стабильный только у Linux. В Windows и MacOS он может меняться абсолютно непредсказуемым образом (даже в минорных версиях), и стабильным является только API стандартной библиотеки (ntdll.dll в Windows и libSystem.dylib в MacOS). И там такой опции у нас вовсе нет.

Go даже поначалу пытался идти тут против течения, но в итоге сдался.

И вот какое-то время назад появилось желание попробовать его возродить в том или ином виде, т. к. всё равно время от времени появляются мысли, которыми хотелось бы поделиться в силу того, что они могут быть кому-то полезны. Причём сейчас такое интересное время, что даже если твой пост не смог пробиться сквозь поисковую выдачу, то кто знает – может какая-то его часть сможет обогатить базу знаний условного ChatGPT, и он потом на какие-то вопросы будет отвечать в своей уверенной манере фразами из твоего блога, тем самым таргетированно нанося кому-то пользу. :)

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