Category: it

Category was added automatically. Read all entries about "it".

Book

Всё, что вам нужно знать про noSQL

http://pages.cs.wisc.edu/~jhe/eurosys17-he.pdf

Neither RocksDB, which is optimized for SSDs, nor LevelDB is able to saturate device resources. Figure 3b shows that RocksDB is only able to use a few more NCQ slots than LevelDB, despite RocksDB’s use of multi-threaded compaction to increase SSD parallelism

Ну то есть БД не в состоянии загрузить современный диск. Я как-то писал давно - а как это так, что в бенчах noSQL они никогда не сравнивают их IOPS с тем, что показывает iometer и аналоги? А вот оно, там совершенное позорище, они на однотредовые диски (и однотредовых клиентов) рассчитаны все.

Так что если вы вдруг найдёте непозорный noSQL, который выжимает из SSD его паспортный IOPS, пишите :)
Book

Звонок другу - Помощь зала

Никогда такого не было, что юникс долбоёбы не умеют в апи, и вот опять. У нас тут минипроблема - гит внезапно не умеет в символические ссылки на винде.

Можно конечно руками насоздавать directory junctions, но это как бы не очень хорошо так как исходные символические ссылки в индексе гит показывает удалёнными из ворктри. Или дать несчастным пермишенов, но это тоже чревато.

Надо чтобы работало "везде" и без ссылок. Суть токова.

Есть монорепа с ~5 приватными пакетами npm, ну и там есть общий код, который сейчас реквайрится через ./shared/foo. Делать это иначе, чем 5 пакетами, мы не можем, ну и пакеты не могут реквайрить .., поэтому shared это симлинк, но см. выше.

Одно из решений - делать зависимый пакет и ставить его через npm install ../shared (оно потом прописывается в пекедж-жсон).

Но тут есть 2 проблемы:

1. Как дебажить? Руками создавать симлинки в node_modules? Хочется чтобы WebStorm работал без приседаний
2. Мы тут всё прибиваем гвоздями через yarn install --frozen-lockfile. Соответственно эта зависимость тоже будет "постоянно" прибиваться и локфайл надо будет обновлять.
Book

Вопрос залу

Как известно, более-менее вменяемых способов аутентифицировать HTTP Request Body есть всего 2:
- Mozilla Hawk
- AWS4

Есть ещё 2 невменяемых:
- Oauth-идиоты что-то там надумали в FAPI2, но во-первых это ещё не релиз а во-вторых я не могу продраться через их сепульки
- Способ, который придумали в UK OpenBanking

Невменяемые способы хороши, но не hipster friendly. Есть ещё совсем невменяемые типа делать всё на коленках поверх RS256 JWT.

Короче, выбор пал на AWS4. Теперь внимание на экран.

https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html говорит, что есть Signed payload option. Как её заюзать? Проблем две:

1. Есть либы по созданию, но не верификации "подписи" (*-наци внутри меня мне не нравится, когда MAC называют digital signature, но такова жизнь).
2. Эти либы всё равно не создают сами x-amz-content-sha256

Вариантов решения несколько:

1. Найти где-то готовую реализацию
2. Налепить на коленках поверх npm i aws4
3. Найти референс-реализацию на левом языке и тестировать нашу реализацию против неё

И вот вопрос залу.

Как быть.

Upd: в Ноде внезапно npm i aws4 умеет генерить x-amz-content-sha256, если написать service: 's3'. А в localstack нет кода, парсящего их x-amz-date, которая ISO8601 без разделителей.

Upd2: Postman внезапно создаёт и "подписывает" x-amz-content-sha256. Хороший мальчик!
Book

Получение публичных ключей из текущего ssh-agent

ssh-add -L внезапно выводит список ключей из текущего SSH-агента. Вопрос в том, есть ли способ установить ключ из ссш-агента в текущий authorized_keys. Ну то есть вариант ssh-add -L >>~/.ssh/authorized_keys но работающий если файла нет или если ключ уже есть.

Только приседать и писать скриптик? Там же не так просто:

(umask 0077 ; mkdir -p .ssh; ssh-add -L >>.ssh/authorized_keys)

Это наверное если без проверки и если все ключи из агента сразу добавлять
Book

Neovim в CentOS 8

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

Ну вот в CentOS 8 инженеры redhat/ibm обычные дятлы в EPEL сделали минимально рабочий vim, с какими-то минимальными плагинами, чтобы можно было работать, но не было проблемы свистопердежа и обмазывания сотнями говна.

Ну и это всё можно вставить в неовим (также из EPEL), и там оно, понятное дело, продолжает работать. А neovim нужен чтобы юзать плагины из VSCode.

В-общем вот:

dnf install neovim python3-neovim awesome-vim-colorschemes vim-{airline,gitgutter}

mkdir -p ~/.local/share/nvim/site/pack/хуй/start/ и туда клонируем coc.nvim и vim-polyglot (ну или vimplug, но это так сказать лишний indirection при сомнительной пользе против обновляющего KISS bash-скрипта)

В результате получается божественно короткий ~/.config/nvim/init.vim:

set runtimepath+=/usr/share/vim/vimfiles
set mouse=a
colorscheme PaperColor
let g:coc_disable_startup_warning = 1

Далее делаем :CocInstall нужным LSP-плагинам и собственно всё.

Ну и это всё работает если дефолтовый терминал доведён до ума передачей из путти putty-256color вместо xterm, и при необходимости .tmux.conf:

set-option -g default-terminal "screen-256color"
set-option -g mouse on
set-option -sg escape-time 10

Ну и там coc можно дальше обмазывать хоткеями, но мне лень.
Book

Очередной Bikeshed

https://docs.microsoft.com/en-us/windows/apps/winui/winui3/

Я тут не очень соображаю, так что могу писать чушь, но интересно следить за процессом.

WinUI 3 is the path forward for all Windows apps—you can use it as the UI layer on your native UWP or Win32 app, or you can gradually modernize your desktop app, piece by piece, with XAML Islands.

All new XAML features will eventually ship as part of WinUI. The existing UWP XAML APIs that ship as part of the OS will no longer receive new feature updates.

Тут надо понять что есть огромное количество говна и палок, которые никто не использует.

User32 никто не использует, потому что там контролы прибиты координатами, и надо писать свой лейаут менеджер

MFC никто не использует, потому что это ёбаный C++98 и макросы вокруг Gui32. With MFC in Visual Studio 2015, you can create dialogs that the user can resize. Т.е. какой-то dynamic layout есть, но см. выше.

WinForms никто не использует, потому что это ёбаный C#. Как там с лейаутом, мне неизвестно. Судя по "Create amazing and highly customizable user experiences with the DevExpress Form Layout component." всё примерно также как выше - т.е. встроенный лейаут может и есть, но реально юзабельно только с third party components.

GTK c Glide и Qt c QML находятся, как я понимаю, находятся здесь. И там и там лейаут есть, и вроде как достаточно для того чтобы не было сторонних лейаут-менеджеров.

После WinForms MS решили видимо показать кузькину мать, в результате в что WPF лейаут не просто есть, а с блекджеком и шлюхами, матрицами поворота и прочим инструментарием чтобы делать не просто формочки, а GUI, автокад-фотошоп. В результате WPF никто не использует, потому что а) сложна б) глючно - я так понимаю из-за очень большого количества фич происходит комбинаторный взрыв и нужная комбинация скорее всего не работает.

Поэтому они пошли взад и придумали UWP, который не так убог, как WinForms, но не так сложен, как WPF. Но его тоже никто не использует, ибо это не просто C#, а C# с винстором. Да ещё и прикручен к номеру билда винды.

Поэтому они решили

а) открутить UWP от номера билда - т.е. поддерживать все фичи на всех билдах
б) сделать какую-то поддержку интеграции с лигаси
Book

PKI CA на смарт-карте на основе TPM - часть 3

Часть 1 - tpmvscmgr
Часть 2 - генерация корневого сертификата и настройка openssl сapi.dll engine

Теперь надо залепить собственно CA. Полутайное знание - оно есть в доке но несколько неочевидно при прочтении - что у openssl ca есть аж 10 параметров, которые хорошо бы держать в openssl.conf, а не передавать каждый раз в коммандлайне. Они документированы, но тайность заключается в том, что некоторые значения опциональны в конфиге, но их тогда приходится указывать в коммандлайне. Так что если вы хотите более-менее DRY коммандлайн - то они де факто mandatory хоть формально в доке написано обратное.

Тайное знание - формат private_key в случае capi engine. И то что в serial.hex надо поместить 00 и перевод строки, но будут работать и некоторые другие варианты. index.txt надо создать пустым, но это документировано.

policy (и её зеркальное отражение в req, но об этом позже) - это самое страшное, что есть в любом PKI CA. Да и в любой схеме с подписями. Вам надо придумать набор claims (в терминах JWT), которые вы будете подписывать при выдаче сертификата. В терминах X.509 набор сlaims - это DN, Distinguished Name. Там куча абсурдных сведений типа степени разработанности ануса, и надо решить, какие из них вам нужны, какие нужны системе, в которой сертификат будет работать, а какие не нужны.

Вот Country и Organization Name вам точно НЕ нужны. Поскольку это внутренний CA, организация у вас одна, указывать её нет смысла. См. количество информации - если вероятность 1 то информации у нас 0. Страна тоже не особо нужна. Точнее, страна - это достаточно неудобный классификатор, даже если у вас реально есть несколько разных стран. Остаются Organization Unit и Locality. В-общем изначально решить, что вы будете указывать в OU и L, невозможно. Надо насоздавать всем сертов, а потом, во второй версии CA, понять, нужна ли вам какая-то схема классификации. Поэтому используйте OU или L. Я выбрал L, поскольку SSID это очевидно скорее L чем OU. Но реально надо понимать что это вам скорее всего не понадобится и на данном этапе добавлено на всякий случай.

Common Name как правило вы не выбираете сами, а его выбирает система, в которой используется сертификат. В случае WAP2 EAP-TLS в CN лежит IP. Ну и тут понятно, что вам скорее всего понадобится всего 1 сертификат с CN=IP для каждого IP. А если где-то понадобится 2 разных - то будете различать их по L/OU. Поскольку выдавать неуникальные DN - это моветон.

Итого в конфиг дописывается секция ca, определяющая, вы не поверите, дефолтовые параметры для команды openssl ca:
[ca]
default_ca = ca_section

[ca_section]
dir = MYCA
database      = $dir/index.txt
serial        = $dir/serial.hex
new_certs_dir = $dir/newcert
email_in_dn   = no
policy        = policy_ip_section
default_days  = 365

private_key   = 4 # "Certificate 4" из openssl engine -t -post list_certs 
certificate   = certs/ca.cert.pem
default_md    = sha256

[ policy_ip_section ]
localityName            = supplied
commonName              = supplied
В результате когда к вам придёт CSR, openssl проверит, что в нём есть клаймы L и СN, и выкинет все остальный клаймы, если их укажут при создании CSR. Это тоже документировано, но если вы не используете CSR, то непонятен смысл всего этого птичьего языка. Надеюсь, теперь понятно что такое OpenSSL CA Policy.

Теперь расскажу, где брать certs/ca.cert.pem. Его можно брать 2 путями:

1. Экспорт из certmgr. Это публичный ключ, т.е. экспортировать НУЖНО.

Пускаем mmc. Я предпочитаю добавлять снапины в пустой mmc. File - Add/remove snap-in. Добавляем туда Certificates. Потом в радиобаттоне - My user account.

Там заходим в Personal. Находим в списке наш CA, сгенерённый из powershell в Ч2. All tasks - export. Убеждаемся что приватный ключ экспортировать низя, так как мы это запретили. На следующем этапе выбираем base64, т.к. это PEM, формат, в котором все хотят. Проверяем через openssl x509 -noout -text -in ca.cer что опенссл всё распарсил.

Вроде бы всё норм, но OpenSSL потом откажется этот серт брать. Запасаемся попкором - для этого нам понадобится способ 2, но до него нам ещё надо генерить CSR.
Book

PKI CA на смарт-карте на основе TPM

В продолжение темы о TPM: https://nponeccop.livejournal.com/669505.html

Решил я тут запилить WPA2-Enterprise, aka WPA2-EAP-TLS. А ему нужна PKI, PKI нужна CA, а CA нужно защищать свои ключи, в особенности корневой. Ну а чем его защищать, как не смарткартой?

Оказалось, что вообще нет способа сделать на винде CA, кроме стандартного решения на Windows Server. Ну а поскольку Windows Server у меня нету, и заводить его, чтобы было CA, как-то глупо, решил сделать решение на говне и палках. То есть на виндовом OpenSSL.

Но конечно "стандартным" путём мы не пойдём, а пойдём "правильным". То есть, опять ебаться!

В-общем в OpenSSL for Windows внезапно есть capi.dll. Качаем его, но они внезапно не умеют в подписанные инсталляторы, а GPG4Win то ещё говно и палки, так что вместо этого проверяем хеши.

На винде идущий из коробки certutil умеет считать sha256 файлов, а на сайте внезапно есть hashes.txt, и даже на HTTPS-сайте. В-общем проверил, что царь настоящий!

Дальше. У нас сходу 2 задачи:

1. Убедиться что capi есть в openssl engine -c
2. Убедиться что openssl engine -t -post list_certs рисует нужные сертификаты

Оба пункта не работают из коробки. И решение следующее:

- залепить openssl.cnf, чтобы capi грузился по дефолту
- запилить openssl.cmd, выставляющий переменные окружения

Батник сводится к:

set OPENSSL_CONF=%~dp0\openssl.cnf
set OPENSSL_ENGINES=%~dp0\engines-1_1

С openssl.cnf сложнее. Минимальный, решающий 2 задачи выше, выглядит так:
openssl_conf = conf_section

[conf_section]
engines = engine_section

[engine_section]
capi = capi_section

[capi_section]
init=1
Следующий этап - заставить работать openssl ca -engine capi -keyform engine

Там даже смешно, что все эти параметры недокументированные: -keyform engine это тайное знание, найденное методом тыка!

На самом деле даже то, что выше, собиралось по крупицам из постов вроде http://openssl.6102.n7.nabble.com/How-to-use-CAPI-engine-in-OpenSSL-1-0-0a-td11611.html

Upd: корневой серт тоже хез как генерить. Там внезапно не работает в новом павершелле но работает в старом

New-SelfSignedCertificate -CertStoreLocation "Cert:\CurrentUser\My" -FriendlyName "Bar" -Provider "Microsoft Base Smart Card Crypto Provider" -KeyProtection ProtectHigh -KeyUsageProperty All -Subject "CN=Foo CA" -KeyExportPolicy NonExportable -KeyLength 2048 -HashAlgorithm SHA256 -KeyUsage CertSign,CRLSign -TextExtension @('2.5.29.19={critical}{text}ca=1&pathlength=0','2.5.29.37={text}2.5.29.37.0') -KeySpec Signature
Book

Хвалёный Центос

Поломал тут я себе центос. Ну не то чтобы совсем поломал. В-общем у меня соединение из говна, и оно отпало как раз в тот момент, как отрабатывал пост-инсталляционный скрипт нового ведра.

В-общем пекедж есть, а vmlinuz в /boot нету. И переустановка kernel не помогает.

Но оказалось внезапно, что rpm -ql kernel говорит что там файлов и нет. А rpm -qf /boot/vm* для старых ядер говорит, что они внезапно принадлежат не kernel, а kernel-core.

В-общем перестановкой kernel-core полечилось. Интересно что в инете советуют всякую хуету. Ибо в rpm -q не умеют и неправильное заменяют на правильное, выходят и входят. Тьфу.