Якщо коротко, то ashift = степінь 2-ки результат якого дорівнює block size. Для нових дисків block size = 4K, тому, ashift = 12 (бо 2^12=4096). Для старих дисків все ще використовується ashift = 9. Чим більше ashift тим буде продуктивніше працювати пул, бо за 1 раз буде більше зчитуватися даних. Але є і інша сторона – зайняте місце. Справа в тому, що якщо у вас багато маленьких файлів, по декілька КБ, то при виборі більшого ashift’y буде більше зайнятого місця. В середньому (якщо порівнювати з ashift=9) це буде в 3 рази більше зайнятого місця. Тому, при виборі ashift треба бути уважним. Головний нюанс в тому, що ashift можна змінити лише при створенні zfs pool.
[NAT] Log sessions
В данній статті розглянемо, як можна логувати сесії NAT в різних файерволах.
iptables
Тут є декілька варіантів, почнемо з найнадійнішого:
conntrack -E --event-mask NEW --any-nat >> /var/log/nat_log
Є ще класичний варіант
iptables -t nat -I PREROUTING 1 -j LOG
iptables -t nat -I POSTROUTING 1 -j LOG
iptables -t nat -I OUTPUT 1 -j LOG
але, як пишуть у мережі, частина пакетів може не попадати в лог, якщо використовувати маркування або додаткову обробку.
pf
Є застарілий проект , який працює виключно на BSD-системах (на Solaris – ні)
ipfw
Тут мені не вдалося нічого знайти.
[jira] Slack alerts
Зʼявилася задача повідомляти про ticket’и jira у slack. На вигляд завдання просте, але є нюанси. google каже, що треба створити новий app у slack’y, згенерувати webhook URL, створити новий webhook у jira вставити його туди.
І… воно не працює. Точніше, якщо тестово відправлєш через curl, то все приходить у slack, а якщо через jira – то отримуєш 400 помилку. Щоб дізнатися, що саме не так, треба ввімкнути debug для webhook’ів у jira. Робиться це так:
[Для початківців] Розслідування однієї помилки SPF
Нещодавно до мене звернувся один користувач з проблемою SPF. Його поштовий сервер видава помилку на прийом пошти від одного домену baddomain.com:
Not authorized by SPF
При цьому, клієнт каже, що якщо перевірити цей baddomain.com на https://mxtoolbox.com, то там немає жодної помилки.
outrun: execute a local command using the processing power of another Linux machine
Знайшов нещодавно досить цікавий проект, який дозволяє використовувати потужності віддаленого сервера, не встановлюючи при цьому ПЗ (програмного забезпечення) на ньому.
Припустимо, у вас є якесь ПЗ, але вам не вистачає потужності поточного серверу, але є інший сервер. При цьому, на іншому потужнішому сервері зовсім не треба ставити це ПЗ, достатньо поставити лише outrun:
pip3 install outrun
Які обмеження при використанні:
- Linux only (насправді, можна ще і BSD, але можуть бути нюанси)
- підтримка fuse (ось із-за цього і обмеження Linux/BSD)
- ssh root access (так, бо після запуску на віддаленій машині виконується chroot)
Домашня сторінка
Ventoy: just add another ISO
Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files.
With ventoy, you don’t need to format the disk over and over, you just need to copy the ISO/WIM/IMG/VHD(x)/EFI files to the USB drive and boot them directly.
You can copy many files at a time and ventoy will give you a boot menu to select them (screenshot).
You can also browse ISO/WIM/IMG/VHD(x)/EFI files in local disks and boot them.
Official site https://www.ventoy.net/en/index.html
GitHub page https://github.com/ventoy/Ventoy
[dns] Fallback resolving
Є досить специфічне завдання: шукати запис у локальному DNS, а якщо його немає, то робити запит до іншого NS’y. Здавалося б, задача проста, але є нюанси. Якщо у вас немає такої зони DNS, то це працює, але що робити, якщо сама зона є, але записів немає? Тоді DNS сервер верне відповідь NXDOMAIN і fallback не спрацює. Зараз ця тема дуже актуальна, особливо, якщо у вас є внутрішній домен в зоні “.dev“. Тут є 2 варіанти:
[mysql] skip/stop replication by condition
Нещодавно дізнався, що у mysql є функціонал зупинки реплікації за умови. Правда, ця умова досить обмежена, але все ж таки, її можна застосувати з хистрістю. Наприклад, у вас є сервер, який трохи відстає і ви знаєте, що є проблемний запит, який треба пропустити. Це можна автоматизувати.
mysql>START SLAVE UNTIL MASTER_LOG_FILE = 'mysql-bin.0000028', MASTER_LOG_POS = 3846213;set gtid_next="XXX";begin; commit;set gtid_next = "AUTOMATIC";start slave;
Ми знаємо заздалегідь позицію проблемного запиту (mysql-bin.0000028, position=3846213) і саму транзакцію (ХХХ). Реплікація доходить до цього запиту, зупиняється, а далі класично виконується skip для GTID-реплікації.
[Linux]IPSet + iptables = destroy, create, error
Зіштовхнувся з однією проблемою при використанні iptables разом з ipset, а саме, коли перечитуєш правила, отримуєш помилку:
ipset v7.10: Set cannot be destroyed: it is in use by a kernel component
ipset v7.10: Set cannot be created: set with the same name already exists
Експерементальним шляхом було визначено, що після онулення правил неможливо одразу (мабуть, ще висять у памʼяті) видалити записи у ipset, треба зачекати. Тобто, потрібна от така констукція:
[FreeBSD] Деякі нюанси про net.inet.ip.forwarding
Прочитав у розсилці по FreeBSD, що виявляється, є відмінність, як саме вмикати forward’інг і правильно це робити (саме у FreeBSD) через
gateway_enable="YES"
у /etc/rc.conf. Чому? Пояснення залишу цитатою, без перекладу: