Rspamd уже давненько навчився зберігати дані по статистиці між рестартами, і от її накопичилося стільки, що роздивлятися стало цікаво.

Спад чистих листів наприкінці минулого року — це я відписався від об’ємних розсилок GlusterFS і Ceph. Добре видно те, як фільтр навчається — з часом ростуть обсяги листів, які викидаються відразу, а також тих, які грейлістяться чи помічаються як імовірний спам. Для цього, звісно, треба тягати листи з інбокса у каталог для спаму.

Зараз в інбокс пролізає мало що, листи помилково мітиться спамом також дуже рідко. Не уявляю, що б я робив без цієї системи фільтрації.

Сьогодні сталися дві дрібномасштабні, але дуже приємні для мене події.

По-перше, мій іграшковий проект по написанню альтернативного FUSE-клієнта для кластерної файлової системи GlusterFS тепло сприйняли й узяли під своє крило розробники GlusterFS, і тепер сам проект хоститься в їхній організації на GitHub’і. Приймаються pull-request’и, я типу головна людина по цьому проекту. Є шанси, що колись у майбутньому ця штука замінить добрий шмат коду GlusterFS більш простим рішенням.

По-друге, мій комміт уперше потрапив у апстрім ядра, і нова версія 4.6, яка зараз ще перебуває тільки на стадії третього реліз-кандидата, матиме трішки, але безпосередньо моєї праці.

Давно я так не грався.

Дано:

  • PBX з одним інтерфейсом і двома білими IP-адресами на ньому: 10.0.0.1 як primary і 10.0.0.2 як secondary (сірі адреси я взяв для прикладу);
  • SIP-провайдер, який дає два різні транки на дві різні IP-адреси PBX із двома різними обліковими записами, але при цьому адреса піра з боку провайдера SIP-транка однакова для обох транків і також біла: 192.168.0.1;
  • велике бажання різні облікові записи SIP-транків пускати через окремі адреси PBX, бо у провайдера таке security.

Якщо викинути зайвий інформаційний шум із ввідних даних, то виявляється, що ми хочемо, щоб один локальний процес (Asterisk) під’єднувався до 192.168.0.1:5060 через 10.0.0.1 і 10.0.0.2 залежно від того, який обліковий запис використовується.

Тобто, нам потрібен статичний L7-маршрут (!!!).

Звісно, ніякий ip route/ip rule так ніколи не зробить. Голий iptables — також. Але є одне але.

Ми можемо обхитрити систему і сказати, що для другого облікового запису SIP-транка Asterisk у якості host має використовувати не 192.168.0.1, а, наприклад, 172.16.0.1, і цього разу це має бути будь-яка сіра IP-адреса. А далі вступає в дію махінація з DNAT/SNAT:

*nat
…
-A OUTPUT -d 172.16.0.1/32 -j MARK --set-xmark 0x10/0xffffffff
-A OUTPUT -d 172.16.0.1/32 -j DNAT --to-destination 192.168.0.1
-A POSTROUTING -m mark --mark 0x10 -j SNAT --to-source 10.0.0.2
…

Тут відбувається таке:

  1. трафік, який іде на фейкову IP-адресу, маркується якоюсь міткою (число взяте зі стелі, як, власне, і сіра IP-адреса);
  2. потім у цих же пакетах підміняється адреса призначення на адресу піра SIP-транка;
  3. потім за встановленою раніше міткою підміняється адреса відправника так, щоб трафік ішов від імені secondary IP.

Таким чином, увесь трафік, який іде на 172.16.0.1, насправді йде на 192.168.0.1, причому від імені 10.0.0.2.

Вуаля — все працює. Без додаткових інтерфейсів, ip route/ip rule, tc (навіть tc уміє NAT, виявляється) тощо.

У попередньому записі я розповів про основні концепції, які ми використовуємо для балансування DNS-запитів від клієнтів. Тепер давайте подивимося, що змінилося за чотири місяці.
Читати далі »

Сьогодні я вам розкажу коротку казочку про systemd-networkd.

TL;DR: усе працює, але є нюанси, особливо в складних конфігураціях, тому краще поки використовувати дистрибутивні конфігурялки мережі.
Читати далі »

Не мала баба клопоту — пересетапила і домашній сервер з Убунти на Арч. Вийшло також доволі пристойно, хоча з певними особливостями.

Перша особливість полягає в тому, що за використання systemd-networkd для ввімкнення форвардінгу на інтерфейсі треба не забувати дописувати IPForward=yes у конфігах.

Друга особливість, на превеликий жаль, говорить, що в nftables, здається, поки що нема функції clamp mss to pmtu, а також mangle ToS. Ну, це пережити поки що можна.

Інші особливості, начебто, були успішно пройдені на першому пересетапленому сервері. Тепер у мене залишився тільки один бубунтосервер, але він від мене далеко, до того ж, не зовсім мій, і я не знаю, чи варто його взагалі чіпати.

P.S. Я ж був на морі, і все чекаю на фотки від товаришів, щоб хоч якось показати, як воно там було.

Як я й обіцяв, ми випустили в opensource балансувальник клієнтських DNS-запитів по UDP. Код можна брати тут, під катом трохи технічних деталей.

TL;DR: epoll, SO_REUSEPORT, ldns, pthreads, CRC64+hashtable.
Читати далі »

Схоже, переїзд на Арч пройшов доволі вдало. Заодно я перелопатив усі сервіси, які були на старому сервері, попереписував конфіги, дещо замінив, дещо підлаштував. Технічні деталі для охочих навожу під катом.
Читати далі »

Не секрет, що для особистих цілей у якості серверної платформи я використовую Ubuntu. У свій час мене на неї підсадив Фаркаллєр, і це справді виявився нормальний вибір: регулярні релізи, не протухший софт, стабільність, покращення тощо. Але з виходом 15.04 усе змінилося — я ще ніколи не бачив такого сирого дистрибутива. Задекларований перехід на systemd виконано щонайгірше: половина сервісів узагалі не конвертована, інтеграція з налаштуваннями мережі нікудишня, базові скрипти стали падати. Я б ще зрозумів, якби це трапилося на одному сервері, але якщо на кількох одночасно — це діагноз.
Читати далі »

Знадобилося тут видалити том GlusterFS, але без того, щоб грохнути фізично брік. Треба було просто звільнити на ньому місце. На томі жило кілька мільйонів дрібних файлів, терміни піджимали, рішення «в лоб не було».

У чому загвоздка: GlusterFS на бріку організовує дані хитрим способом. По-перше, відтворюється нормальна структура даних, така ж само, яку бачить користувач, коли монтує том. По-друге, створюється підкаталог .glusterfs, який містить хардлінки на ці файли, ну тільки з іншими назвами (відповідно до використовуваного алгоритму хешування). Якщо робити тупий rm -rf, find . -delete чи навіть rsync –delete, то нічого хорошого швидко не вийде, оскільки кожний файл буде видалятися як мінімум двічі (а то й більшу кількість разів), і місце на диску звільнятиметься тільки після видалення останнього хардлінка кожного файла.

Тому в голову прийшло спочатку робити truncate:

find . -type f -print -exec truncate --size=0 {} \;

А потім уже робити видалення пустих файлів:

rsync -av -H --progress --delete empty/ folder/

Тільки так можна швидко звільнити місце за наявності кількох мільйонів файлів із хардлінками.