dadv: (Default)

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

Henry Lee



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

оригинал )

dadv: (Default)

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

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

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

DW

2016-12-25 12:11
dadv: (chuck)
Оригинал взят у [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)

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

dadv: (chuck)

Стандартная ситуация: локальная сеть с маршрутизатором, один публичный 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)

Поискал как-то утилитку, которая смогла бы в пакетном режиме подписывать заранее заданный 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)

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

dadv: (chuck)

Довелось поэкспериментировать с компрессией и шифрованием данных на системном уровне в 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

Profile

dadv: (Default)
Choose your future

June 2017

M T W T F S S
   1234
56 7891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom

Tags

Style Credit

Powered by Dreamwidth Studios