Cat-dark

Как у меня появилась собака

... Чуть больше года вместе со мной под одной крышей обитает рыжая хаски. Примерно через месяц ей исполнится семь лет. Под катом небольшая история о том, как вообще так случилось.

Collapse )
Cat-light

Редкий баг в PostgreSQL (на самом деле нет)

... Перетащили в бинарном виде базу данных PostgreSQL 12 с RHEL 7.7 на Ubuntu 20.04 LTS. На первый взгляд всё завелось без проблем. А вот на второй... приходит ко мне удивлённый разработчик и показывает:

SELECT id,client_id FROM блаблабла WHERE client_id = 'Abrakadabra';
 id | client_id
----+-----------
(0 rows)

но при этом

SELECT id,client_id FROM блаблабла WHERE client_id like '%Abrakadabra';
 id  |  client_id   
-----+--------------
 123 | Abrakadabra
(1 row)

Долго думали. Потом разработчик на всякий случай решил сделать REINDEX. Как ни странно, помогло. Ну и я в чатик "https://t.me/pgsql" с криком "Нафа-а-а-аня!". Там мне быстро ответили. Говорят, да, есть такая багофича. Проявляется крайне редко, поэтому во всяких там change log-ах и прочих мануалах её нет. Преимущественно репортят подобное те, кто сидят на красной шапке и её клонах. После обновления glibc (откуда Postgres берёт локали) что-то ломается в индексах, если в них задействованы текстовые поля. Поэтому их нужно ручками перестраивать после подобного обновления glibc. Что мы, собственно, и сделали.

М-дя. "Редкие грабли". Но я не мог на них не наступить!

Cat-light

Какие сейчас есть нормальные GSM-шлюзы?

Задача.

Я параноик, поэтому всякие банковские и прочие чувствительные сервисы привязываю к SIM-карте:


  1. номер которой никто не знает;

  2. на которой "непротухающий" тариф без абонентской платы;

  3. официально оформленной на моё имя;

  4. физически не покидающей пределы моей квартиры.

Но мне таки иногда требуется получать с таких SIM-карт SMSки. И случается, что в этот момент я нахожусь где-то вне дома.

Прямо сейчас для решения я использую Android-телефоны с установленными на них софтинами типа RelayME, Notify2Jabber и иже с ними. Оно, конечно, работает. Но мне не очень нравится как. То батарейка вспучится / разрядится, то телефон Wi-Fi сеть потеряет, то ещё что-нибудь в этом же духе. Хочется чего-то более надёжного.

Присматриваюсь к каком-нибудь GSM <-> SIP Gateway. Но там тоже не всё хорошо. По определению все эти железки будут кустарно-китайского производства. Но к некоторым прилагается также ещё до безобразия кривой софт.

А также случаются неочевидности наподобие таких. Например, DBLTek / GoIP умеют работать только в режиме 2G. Соответственно, теле-квашную симку в Нерезиновске в него уже не вставить.

Соответственно, вопрос к залу. Может быть кто-то из вас встречал относительно нормальный GSM-SIP шлюз на четыре SIMки, который умеет работать в 3G и с не сильно у***щным софтом в комплекте? Меня интересует только пересылка входящих SMSок с SIMки в Jabber или на электропочту / телеграм и т.п. Голос не нужен.

Cat-light

Ковидобесие продолжается

Ну шо. Очередной этап ковидобесия.

https://www.sobyanin.ru/koronavirus-resheniya-19-10-21

Особенно меня в этом всём умиляют два момента.

Первый вот этот.

Требование о переходе на удаленную работу не распространяется на вакцинированных и переболевших работников.

Отсюда следует что?


  • Не вакцинируйся и кайфуй себе на удалёнке, а не мотайся в душный офис по переполненному метро как дурак.

  • Если заболел, то сиди дома тихо и не жужжи, врачей не вызывай и никому не рассказывай. Ровно по этой же самой причине. Вариация: нажрись "терафлю" и постарайся "продержаться до выходных", а там возьми отпуск за свой счет.

А второй вот этот.

По правде говоря, мы надеялись, что в начале осени пенсионеры вернутся в Москву с дачных участков и обязательно выберут время, чтобы сделать прививку. К огромному сожалению, этого не произошло.

А-ха-хах! Вот тут был стратегический просчёт, ящетаю. Надо было перед выборами платить 10 килорублей не всем подряд, а только вакцинировавшимся. И для бюджета экономия, и для пенсионеров мотивация. А так бабло нахаляву всем раздали, конечно, дураков добровольно чипироваться нет.

В общем, как всегда. Традиционный способ борьбы с тараканами: быстрее бить их тапком.

Cat-light

Очередная багофича в Juniper SRX

... Ну вы уже поняли, насколько горячей любовью я их "обожаю".

Дано. Техническая площадка. На ней контроллер домена MS AD. IPSec-тоннель до другой площадки. Там еще один контроллер MS AD. На Juniper SRX между площадками в полисере разрешено всё и в обе стороны. Примерно так.

Казалось бы, чего ещё желать? Но контроллеры всё равно друг друга не "видят". Вроде AD номинально и работает, но как-то "с пердежом и рвотой". А всё почему? Потому что в Juniper встроен и по умолчанию включен ALG (Application Layer Gateway). И просто "application any, permit" ему мало. Надо либо явно указывать что именно ты хочешь permit, либо отключать его к какой-то там матери применительно к MS RPC:

set security alg msrpc disable

Ох уж эти железки, которые искренне считают, что они умнее сисадмина.

Cat-angry

Juniper + IPSec + MTU = баги

Хотите еще багов ждунипера? Их есть у меня. Наступил на очередную пачку. Причём, практически на ровном месте.

Вводные следующие.

Есть IPSec-тоннель с шифрованием AES256GCM. Для семейства шифров со счётчиком Галуа (GCM) не требуется подпись пакета, поэтому при MTU физического линка равному 1500, overhead будет составлять всего 54 байта: 20 на новый IP-заголовок ("обёртка"), 8 на заголовок ESP, 16 на Initialization Vector и 10 на всякую служебную информацию для ESP. Таким образом, MTU для виртуального ST-интерфейса при таком выборе шифра может быть вплоть до 1446 байт.

Ну ок, не подозревая дурного, настраивают примерно так.

... и нихрена не работает. По симптомам, типичная проблема поломки механизма Path MTU Discovery: мелкие пинги бегают, большие теряются, HTTPS не работает.

Лезу проверять. Так и есть. Juniper SRX вот ни разу не удосуживается вернуть Fragmentation Needed (ICMP type=3 code=4) хосту из локальной сети, который пытается послать через тоннель пакетик общей длиной 1500 байт. Ну охренеть. Продолжаю экспериментировать.

Сперва просто убираю директиву "mtu" из настроек ST-интерфейса. Всё работает. Почему? Да он просто начинает втихаря фрагментировать ESP-пакеты, которые потом так же молча собираются с другой стороны. Ну охренеть два раза. Почему тогда в первом случае не стал фрагментировать так же втихаря?

Ладно. Копаюсь дальше. Включаю в настройках "security ipsec vpn" директиву "df-bit copy". Вау, работает! Немного странновато, правда (об этом ниже). Но во всяком случае, Fragmentation Needed уже возвращается. Хотя судя по документации, эта настройка вообще не про то.

Дальше веселее. У меня дома в качестве роутера установлен старенький SRX100H2 с 12-й версией прошивки (свежее для него просто не существует). Там работает всё как надо. То есть я не выставляю никаких "df-bit copy", железко чётко соблюдает MTU и возвращает Fragmentation Needed. А вот Juniper SRX-345 с прошивкой 15.1 ведёт себя вот так вот по-свински. Видать, в новых версиях устранили старые неработающие баги и добавили новых работающих. На более свежих прошивках пока что нет возможности проверить. Хотя, говорят, в офис уже притащили "лабораторный" SRX. Если лапки дойдут, посмотрю как на нём.

Но это только первый баг. Есть ещё и второй.

SRX как-то очень загадочно считает MTU для интерфейса внутри тоннеля. Я выше упоминал, что для таких шифров он должен быть 1446 байт. Сам Juniper же почему-то настаивает на значении 1438 байт. Во всяком сучае, именно столько он присылает в ICMP type 3. Но и это ещё не всё.

Если одновременно включить "df-bit copy" и "mtu 1446", то Juniper в ICMP type 3 присылает уже 1428 байт! Можжевельник, я вот не понял. Если ты типа умнее меня и лучше меня умеешь считать оверхеды, то какого хрена ты меняешь свое мнение после того как я задам MTU на "внутреннем конце" тоннеля? И какого хрена ты выставляешь там своё значение, даже пусть бы моё и якобы неправильное?

В общем, как всегда. Чем дальше, тем страшней. Похоже, софт для этих Juniper-ов пишут не просто индусы, а индусы под кайфом, за которыми никто даже близко не потрудился проверить. Я не знаю как это по-другому можно объяснить.

Leopard

Мимолётная мысль #57

... Время от времени какой-нибудь ребёнок на улице проявляет интерес к моей собаке. Я тогда подзываю её, разрешаю погладить, немного рассказываю про особенности породы и напутствую никогда не заводить такую же в городе. Стандартный вопрос, который мне всегда задают: как зовут собаку.

Я, конечно, отвечаю. Но какая им разница как её зовут? Ну вот правда? Что изменится от того, что он(а) узнает имя собаки? Она ко мне-то далеко не всегда приходит пока не пошуршишь чем-нибудь в кармане. К чужому человеку не пойдёт и подавно. А от детей в принципе старается держаться как можно дальше.

... 2014й год. Доллар стоит 34 рубля. Проезд на метро 22 рубля (если покупать билет на 60 поездок). "Биг Мак" можно купить за 89 рублей. Моя зарплата составляет X килорублей, так что я могу себе позволить поехать с подругой на пару недель в Италию или Испанию и останаливаться там в 4х-звездочных отелях.

2021й год. Всё подорожало минимум в 1,5 раза, включая жильё в Нерезиновске. Баксы подорожали в два раза. Моя зарплата по-прежнему составляет X килорублей. На этот раз, правда, она 100% "белая". Но мне от этого ни горячо, ни холодно. Даже скорее противно от мысли, что тебя заставляют кормить всех этих разгоняющих мирные собрания silovikов и прочих коррупционеров. Деньги постоянно куда-то уходят, не задерживаются. Единственное, что изменилось с тех пор — появилась машина и собака. Но что-то я не верю, что это именно они являются главной причиной возросших трат.

Смотрю я на припаркованные возле соседних домов всякие "бэхи", ауди, мерседесы и думаю: чем-то я не тем занимаюсь. Ох, не тем.

cat-updown

Внезапно торкнуло

Меня внезапно торкнуло.

Вот есть механизм Path MTU Discovery. Типичный случай.

Клиент устанавливает HTTPS-соединение. Сервер начинает слать ему payload с флагом DF (Don't Fragment). Роутер где-то по дороге понимает, что пакет не протиснется через очередное звено маршрута, а фрагментировать пакет низззя потому что DF. Тогда он шлёт серверу ICMP-сообщение "Fragmentation needed" и говорит, мол, "кромсай на пакетики помельче". После чего всё благополучно бегает. Это если совсем на пальцах. И к слову о том, почему не стоит из соображений "безопасности" фильтровать ICMP.

Но тут я внезапно вспомнил, что сейчас уже почти на всех современных сетевых картах есть поддержка TCP Segmentation Offloading (TSO). И в ядре она практически всегда включена по умолчанию.

То есть, если вы натравите какой-нибудь tcpdump / wireshark и иже с ними на сетевой интерфейс и будете изучать исходящий трафик, то "без палева" внезапно увидите там пакетики длиной килобайта по четыре и шосукахарактерно с неправильной контрольной суммой. Это вот как раз оно и есть. Покромсает потом уже сама сетевая карта. И если хочется узреть "настоящую" длину кадра и контрольную сумму, то надо либо отключать offloading в драйвере интерфейса, либо снимать пакет с порта коммутатора. Кому интересно, подробнее есть вот здесь.

Но теперь я задумался: класть бороду под одеяло или на одеяло как TSO уживается совместно с Path MTU Discovery? То есть по идее, сетевая плата не сможет обработать входящее ICMP-сообщение "Fragmentation needed", она для этого недостаточно умная. Ядро его, конечно, получит и примет к сведению... но на что это повлияет, когда на кадры режет-то всё равно сетевуха? Этот вопрос отныне не будет давать мне спать ночами.

А задался я им вот почему. Тут шаловливые мои ручки решили "пооптимизировать" один IPSEC-тоннель и выставить на нем MTU=1446, дабы шифрованный туннелированный пакет вместе с оверхедом по-прежнему бы умещался в один кадр на сети провайдера. Но при этом отвалились HTTPS-ресурсы по одну из сторон тоннеля. И как прикажете понимать, это я вляпался в очередной баг ждунипера, или же просто Path MTU Discovery не работает одновременно с TSO?

Посидел бы со снифферами, но на боевой среде отлаживать это достаточно тяжело. Слишком много всякого говна трафика летает.

Cat-light

Памятка по APT и GPG в Debian-based

... Начиная с Debian 11 и Ubuntu 20 механизм "apt-key" признан официально устаревшим (deprecated). Сейчас предлагается самостоятельно брать GPG-keyring требуемого издателя и класть его в папочку "/etc/apt/trusted.gpg.d/". Проблема в том, что большинство разработчиков ещё не поменяли скрипты инсталляции и инструкции и по-прежнему выкладывают ключи для проверки подписи пакетов в виде ASCII (PEM-encoded) у себя на сайте, либо же вообще предлагают самостоятельно доставать их с HKP-сервера а-ля "hkp://keyserver.ubuntu.com".

Я сначала попробовал сам поупражняться в конвертировании этого добра в GPG-брелки, но он у меня всё время получался "не того" формата, который не хотел хавать APT. Всё дело в том, что я не знал про одно волшебное слово в заклинании. Ниже примеры правильных команд, которые работают.

Для доставания ключа с HKP-сервера (на примере clickhouse):

gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ch.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv E0C56BD4

Для конвертации из локального PEM-файла (на примере reaper):

cat gpg.23C0C625FCDF1F31.key | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/reaper.gpg --import

Я не знал про мантру "gnupg-ring:" в заклинании, пришось гуглить.

Моя личная коллекция готовых к раскладыванию GPG-брелков.

Azul
Cassandra
Clickhouse
Mamonsu
Reaper
Zabbix

С какой-то части провайдеров сейчас сервер "distro.staser.ru" (где лежат брелки по ссылкам выше) может не откликаться. У OVH опять какие-то проблемы со связностью до М9. Похоже, пора менять хостинг. Непонятно только на что именно.