dadv: (Default)
2017-06-07 11:34 pm
Entry tags:

Henry Lee

По мотивам народной шотландской песни:

Henry Lee



Приляг, приляг, милый Генри Ли )

оригинал )

dadv: (Default)
2017-04-05 06:39 pm

Тест

тест
dadv: (Default)
2017-01-02 05:16 pm

DW Announcement

Тестирую кросспостинг в ЖЖ через DW.

Заодно выдержка из новогоднего объявления от DW:

DW пережил огромный наплыв новых пользователей в последнюю декаду 2016, более 100000 новых аккаунтов и увеличение трафика на 25%. Многие из них из России и Украины.

dadv: (chuck)
2016-12-25 12:11 pm

DW

Оригинал взят у [livejournal.com profile] kika в валить-валить

Чтобы перенести в dreamwidth всю френдленту, надо при импорте
https://www.dreamwidth.org/tools/importer
указать импортировать список френдов, потом когда задание на импорт встанет в очередь, дождаться выполнения, пойти в http://www.dreamwidth.org/manage/circle/edit и поставить там галочки subscribe у всех, кого вы хотите читать.
Если у вас френдов в ЖЖ много и кликать на всех лень, то в консоли броузера можно выполнить вот это:
document.querySelectorAll("[id^='editfriend_edit_'][id$='_watch']").forEach(function(el){el.setAttribute('checked', 'checked');el.setAttribute('value', 1);})
И потом просто нажать кнопку Save changes.

Я пишу в LJ уже года три через dw на самом деле, просто убрал баннер трансляции из постов, поэтому этого было не видно. Наверное после устаканивания текущей бури в стакане и когда станет понятно что dw нормально справился с всплеском нагрузки, я трансляцию уберу. Не то чтобы я тут сильно подрывал и очень уж отчаянно плевал и уж тем более я не собираюсь в ближайшее время ехать в РФ (делать там совершенно нечего), но просто как-то неаккуратненько что-ли. Пусть меня читают только гебисты с прямыми руками и не крышующие ларьки, у которых дазы банных не "утекают" на рынок.


Надо будет тоже присмотреться к альтернативам. Не в ФБ же идти, в самом деле.
dadv: (chuck)
2016-10-16 01:08 pm

FreeBSD donation 2016

Отметил свой сороковой день рождения подарком $100 фонду FreeBSD через PayPal. Курс банка 63.29, что немного меньше прошлогоднего. URL прежний: https://www.freebsdfoundation.org/donate/ (биткойны принимают по-прежнему :-)

dadv: (chuck)
2016-10-04 11:28 am
Entry tags:

DNS, NAT и проброс портов

Стандартная ситуация: локальная сеть с маршрутизатором, один публичный IP, для выхода в мир используется NAT. Плюс на маршрутизаторе работает кеширующий DNS-сервер для локальной сети. Всё работает.

Однажды на одном из хостов локальной сети поселяется сервис, которому требуется пробросить статический диапазон портов UDP с внешнего IP. Казалось бы, какие могут быть проблемы?

А ведь DNS-сервер, выполняя запросы к внешним серверам, для исходящих запросов сам использует динамические UDP-порты и ожидает ответ на них. Например, ISC BIND под FreeBSD использует sysctl net.inet.ip.portrange.hifirst и net.inet.ip.portrange.hilast для определения диапазона таких эфемерных портов, по умолчанию это 49152-65535. Пока этот диапазон не пересекается с диапазоном проброшенных внутрь локалки портов, всё будет в порядке. Но стоит лишь пробросить, скажем, порты 40000-65535, и наступает катастрофа. В случае FreeBSD проброс портов "имеет приоритет выше" (выполняется раньше, чем доставка локальным приложениям) и проброс-то работать будет, но DNS-сервер остается без DNS-ответов на свои запросы, которые теперь уходят по пробросу локальному хосту, которому они и не нужны вовсе. И вся локальная сеть остаётся без локального DNS-сервиса.

Решением будет либо изменить диапазон проброшенных портов, если это допустимо для сервера в локальной сети, а если нет - изменить диапазон эфемерных портов для DNS-сервера. Кроме изменения системного дефолта, ISC BIND позволяет задать этот диапазон в собственной конфигурации:

use-v4-udp-ports { range 10000 30000; };

Аналогично для IPv6. Для защиты от некоторых типов атак, BIND каждый раз выбирает случайный порт из диапазона и рекомендуется, чтобы диапазон был достаточно большим, минимум 16384 портов (14 бит энтропии).

dadv: (chuck)
2016-08-13 05:48 pm

ЭЦП с ГОСТ 3410/3411 и подписывание PDF

Поискал как-то утилитку, которая смогла бы в пакетном режиме подписывать заранее заданный PDF заранее заданным сертификатом/ключом формата PKCS#12, в которых используются не варианты RSA/DSA, а отечественный ГОСТ, с внедрением подписи в PDF. И среди опенсорса ничего рабочего не нашел. Отсоединенную подпись (в отдельном от PDF файле) создать проблем нет просто командой openssl, но вопрос стоял о внедренной в PDF подписи.

Под Windows есть Adobe Acrobat и КриптоПро, при помощи которых можно проверять существующую подпись в файле PDF и подписывать самостоятельно при наличии ЭЦП, но мне хотелось найти путь с использованием открытого софта и автоматически, в пакетном, а не ручном режиме.

Нашелся BouncyCastle - опенсорс-криптопровайдер для Java, который с версии 1.50 умеет ГОСТ. Нашлась Java-библиотека iText PDF для манипуляций с файлами PDF, которая умеет создавать подписанные PDF и поддерживает использование криптопровайдера BouncyCastle вместо дефолтного Sun-овского, который ГОСТ не умеет.

И нашелся баг в исходниках iText всех версий, включая последние 5.5.9 и 7.0.0, из-за которого при подписывании PDF ГОСТ-ключом никаких ошибок не возвращается и генерируется PDF cо встроенной подписью, но битым хешем, отчего проверка подписи потом говорит "документ был изменён после подписывания". Участок кода itextpdf в 5.5.9 и 7.0.0, в котором сидит баг, практически идентичен, не менялся при смене версии.

После исправления бага (на самом деле полное исправление неизбежно сломало бы совместимость со старым кодом, так что в API добавлен новый метод для обходного пути) и добавления OID-ов для GOST3410 и ECGOST3410 в itextpdf у меня заработало пакетное подписывание PDF. Результат проходит проверку подписи в виндовом Adobe Acrobat с аддоном от КриптоПро, добавляющим Акробату поддержку ГОСТ.

Для этого требуется JRE или JDK с Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (тестировал с OpenJDK 1.6 и 1.7), BouncyCastle версии не ниже 1.50 (тестировал с 1.54), itextpdf-5.5.9.jar (патченный для поддержки ГОСТ) или новее.

И коротенькое консольное java-приложение (просто обвязка вокруг библиотек), которое можно взять тут: http://www.grosbein.net/signpdf/

Там же лежит описание использования в http://www.grosbein.net/signpdf/Readme.txt плюс готовый патченный itextpdf-5.5.9.jar, сами патчи и прочее.

dadv: (chuck)
2016-06-15 12:42 pm

ЖЖ-поиск умер, да здравствует ljsear.ch

Появилась реинкарнация поиска по архиву ЖЖ: http://ljsear.ch/
В настоящее время ищет по архивной копии, содержащей записи и обсуждения за 2000-2015 год и выдаёт ссылки на сам ЖЖ плюс даёт доступ к архивным копиям найденного, но "сохраненные копии" доступны только с не-российских IP во избежание блокировки поисковика цензурой.

dadv: (chuck)
2016-01-16 03:47 am

ZFS compression, sector size & recordsize

Довелось поэкспериментировать с компрессией и шифрованием данных на системном уровне в FreeBSD 9/i386. Шифрование делал через GELI, компрессию через ZFS. Обнаружил забавное. В моём случае контейнер для GELI расположен на медленной сетевой шаре (CIFS over 100Mbit/s & mtu=1500) и для уменьшения дополнительных тормозов от "read-modify-write" поигрался с размерами блоков.

И geli init позволяет задать "размер сектора" в создаваемом GEOM, и ZFS позволяет задать размер блока (recordsize). Оказалось, что даже при отлично сжимаемых данных и включенной компрессии ZFS реально ничего не жмет, если размер сектора и recordsize одинаково равны 4096: zfs get compressratio всегда показывает 1.00 и всё работает довольно медленно, упираясь в сеть.

При том же размере сектора в 4k увеличение recordsize до 8k позволяет ZFS достичь compressratio до 2.0 и операции на хорошо жмущихся данных заметно ускоряются. Если при recordsize=8k уменьшить размер сектора до 512 байт, то на тех же данных степень компрессии взлетает до 16.0 и скорость обработки хорошо жмущихся данных, соответственно, взлетает в разы. Например, показания benchmarks/bonnie, который оперирует как раз такими данными, хорошо демонстрируют эффект.

Маленький "размер сектора" контейнера GELI не слишком хорош по разным причинам: и относительные накладные расходы на собственно шифрование возрастают, и совсем мелкие обмены шифрованными данными по сети через CIFS генерируют относительно высокие накладные расходы в TCP. Поэтому "размер сектора" GELI-контейнера увеличил обратно до размера страницы памяти 4k и выставил ZFS recordsize в 8k - при этом на моих характерных данных коэффициент сжатия получается около 1.85.

Это лишь первая серия тестов и, может быть, в итоге - и для других наборов данных - параметры придется поменять.

dir="/mnt/cifs"
size="100g"
poolopts="-O recordsize=8k -O atime=off -O compression=gzip-9 -o failmode=continue"
truncate -s $size $dir/backend
md=$(mdconfig -af $dir/backend)
geli init -s 4096 /dev/$md
geli attach /dev/$md
zpool create $poolopts es /dev/$md.eli

dadv: (chuck)
2016-01-14 05:06 pm
Entry tags:

Трудовые будни

Нарастил память у сервера, увеличив с 6G до 6+32=38G. Старый BIOS ругался на неподдерживаемые DIMM, но после обновления заработало всё, кроме одного 32-битного процесса.

Этот сервер работает под управлением FreeBSD 9.3-STABLE/amd64, но внутри себя, кроме всего прочего, крутит jail со спасенной со старой работы системой FreeBSD 4.11, в которой крутится фидонода 2:5006/1 с NNTP-гейтом и innd. И вот нормально работавший при 6G физической памяти innd после расширения стал падать при старте с руганью в лог news.err:

innd: SERVER cant malloc 909626760 bytes at line 146 of chan.c: Cannot allocate memory

Дело в том, что по умолчанию в FreeBSD9/amd64 предел datasize для 32-битных процессов составляет 512M (для 64-битных - 32G), а в innd, очевидно, слишком жадная автонастройка. Поднял системный предел для 32-битных процессов до 2G через sysctl compat.ia32.maxdsiz=2147483648 и проблема ушла.

dadv: (chuck)
2016-01-01 09:14 pm

Каникулы

Не мертво то, что в вечности пребудет,
Со смертью времени и смерть умрет.


© Лавкрафт

dadv: (chuck)
2015-12-28 08:24 pm

Заметки на манжетах: ISC BIND 9 & rndc.key

Открыл для себя, что named читает ключ rndc.key (нужен, в частности, чтобы работала команда rndc) только из каталога, заданного при компиляции пакета и не имеет опции командной строки для переопределения пути к ключу.

Например, пакет bind910 для FreeBSD 10 нынче собирается с путем конфигурационных файлов /usr/local/etc/namedb и это неудобно, если хочется запускать named в chroot, где иерархия /usr/local вообще не нужна. Средствами /etc/rc.conf можно переопределить путь к named.conf внутри chroot, но нельзя к rndc.conf. Можно это сделать настройками самого named.conf, хотя и неочевидным образом. Перед стандартной секцией options добавляем команды:


include "/etc/namedb/rndc.key";
controls { inet 127.0.0.1 port 953 allow { any; } keys { rndc-key; }; };


Первая команда подключает rndc.key по указанному пути, а вторая команда отменяет поиск его по вкомпилированному пути, включая использование только что подключенного ключа для rndc.

В итоге для того, чтобы установленный из портов/пакетов named в FreeBSD 10 работал в chroot так же, как до этого он работал в составе базовой системы FreeBSD 9 и ранее, в /etc/rc.conf остаётся прописать:

named_enable="YES"
named_conf="/etc/namedb/named.conf"
named_chrootdir="/var/named"
named_symlink_enable="YES"

dadv: (chuck)
2015-12-17 12:29 am
Entry tags:

Hetzner и eDNS

Оказалось, что немецкий хостер-лоукостер Hetzner в порядке защиты своей инфраструктуры от атак режет, в частности, входящие фрагментированные пакеты UDP, что в современном интернете частично ломает DNS-сервис. Проблема актуальна только тем, кто держит собственные DNS-серверы на физических или виртуальных серверах в Hetzner.

Детально проблема расписана в базе знаний ISC (наш случай - пункт 4. DNS queries/responses using EDNS are allowed, but UDP fragmentation and reassembly is broken), но решение достаточно простое - настроить свой DNS-сервер сообщать другим серверам не посылать требующие фрагментации ответы. Этакий аналог TCP adjust mss, но для DNS через UDP. Более крупные ответы будут доставляться сразу по TCP вместо UDP.

Для сервера BIND достаточно прописать в секции options:

options {
  edns-udp-size 1432;
}

dadv: (chuck)
2015-11-25 11:36 pm

FreeBSD donation 2015

В этом году пожертвования можно делать ещё и в биткойнах :-)
Но чего нет, того нет, так что $100 через PayPal ушло традиционно с рублевого счета с конвертацией по банковскому курсу 66.11

Адрес странички всё тот же: https://www.freebsdfoundation.org/donate
dadv: (chuck)
2015-09-25 11:54 pm

Единение с природой

Из экспедиционного дневника Б.Н. Стругацкого - экспедиция АН СССР 1960 г. по поиску места для строительства на Северном Кавказе большого телескопа:

Read more... )
dadv: (tusya)
2015-09-25 08:02 pm

Ад всегда рядом

И рассказанная история, и дискуссия о строгости законов в блоге ныне американской (бывшей советской) иммиграционной адвокатши достойны прочтения.

dadv: (chuck)
2015-07-31 07:53 pm
Entry tags:

Не всем йогурты одинаково полезны

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

На сервере работает два параллельных независимых процесса. Один раз в 5 минут опрашивает множество устройств в сети и за счет высокого параллелизма успевает опросить 2500+ устройств за одну минуту, снимая с каждого устройства одним запросом по нескольку десятков счетчиков и сохраняя эти данные во временных файлах на файловой системе.

Второй стартует тоже раз в 5 минут, но со смещением по времени относительно первого процесса и перемещает данные из временных файлов в базы RRD. До недавнего времени сервер работал под управлением FreeBSD 8.4-STABLE, но в связи с окончанием поддержки (EoS/EoL) восьмой ветки операционная система была обновлена до FreeBSD 9.3-STABLE. До обновления один полный цикл работы этого второго процесса занимал не более минуты, а после обновления он стал работать в 6 раз медленнее. Да и вообще, резкое замедление и уменьшение "отзывчивости" дисковой подсистемы стало заметно невооруженному глазу.

Довольно скоро обнаружил, что всё дело в системном параметре sysctl vfs.read_max, задающем предел для опережающего чтения для UFS в блоках файловой системы. В восьмой версии его значение по умолчанию 8, а в девятой 64. То есть, FreeBSD 8 при чтении одного блока из базы RRD может нагрузить диск чтением восьми блоков, засунув "лишние" данные в кеш, а FreeBSD 9 может нагрузить диск в восемь раз больше плюс занять больше места в кеше. Это может ускорить работу с файлами, когда реально требуется читать файлы целиком или большими кусками.

Но при обновлении RRD-файла выполняется чтение только небольшой части файла и ядерное опережающее чтение впустую нагружает диск и кеш ненужной работой. Уменьшил предел обратно до 8 блоков (старый дефолт) и производительность возрасла в 6 раз, вернувшись к старым значениям.