Category: it

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

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-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. Похоже, пора менять хостинг. Непонятно только на что именно.

Cat-light

Памятка по Mamonsu

В сентябре 2021 года вышла 3-ая версия инструмента для мониторинга БД PostgreSQL под названием Mamonsu. Теперь в ней есть аж шесть штук красивеньких экранов (screens). При развёртывании этого самого Mamonsu я регулярно хожу по граблям. Так что выпишу их, пожалуй, здесь, чтобы не забыть.

... В третьей версии разработчики опять поломали инсталляционные скрипты. Они прописывают в системе неправильный URL с репозиторием. Им уже завели репорты на эту тему: раз, два. Правильные URLы вот такие для стабильных дебиана и убунты соответственно:

deb [arch=amd64] https://repo.postgrespro.ru/mamonsu/debian bullseye main
deb [arch=amd64] http://repo.postgrespro.ru/mamonsu/ubuntu focal main

GPG-ключик для APT-а лежит у меня вот здесь, например.

... В конфигах демона вполне себе можно использовать подключение к базе посредством unix socket. Но для этого нужно в директиве "host" писать полный пусть к сокету. Например:

host = /run/postgresql/.s.PGSQL.5432

Если пользователь БД совпадает с именем uid-а, из-под которого работает демон, то пароль, как правило, можно не указывать.

... Mamonsu умеет отправлять все метрики в активном режиме (push). Если zabbix-сервер позволяет их принимать, то функционал "agent" в демоне можно выключить. Нехай не занимает лишний TCP-порт.

[agent]
enabled = False

... Если у вас уже есть отдельный шаблон, которым вы мониторите общие метрики операционной системы, то стоит отключить их отправку демоном mamonsu. Зачем вам дублировать одни и те же данные?

[system]
enabled = False

... Есть какой-то баг. Шаблон, сгенерированный в mamonsu 3.0.0, не лезет в Zabbix 5.0 с отлупом "Incorrect value for int field max_columns". Но при этом вполне себе нормально заходит в Zabbix 4, откуда его можно потом экспортировать и засунуть в Zabbix 5. Я им зарепортил. Посмотрим что ответят.

... Самое главное. Когда делаешь "mamonsu bootstrap", нужно обязательно (обязательно, Карл!!!) указывать ключ "-d" (имя базы данных). Таким образом, команда на bootstrap выглядит примерно так.

sudo -u postgres /usr/bin/mamonsu bootstrap -M mamonsu  -d mamonsu

Если этого не сделать, то он создаст схему и функции в базе данных по умолчанию, то есть в "postgres". Где потом будучи запущенным от непривилегированного пользователя, естественно, их уже не найдёт. Сколько же я раз наступил на эти грабли!

Странно, что разработчики не сделали наличие ключа "-d" обязательным наподобие ключа "-M". С одной стороны, ты админ, ты умный, ты должен соображать что творишь. С другой стороны, команда bootstrap без явного указания базы вообще не имеет смысла. Так как должна запускаться только от суперпользователя (как правило, его зовут postgres) и при этом писать ну уж точно куда угодно, но не в принадлежащую этому суперпользователю базу.

Зарепортил пожелание, посмотрим что скажут.

... А так вообще, хорошая софтинка. Удобная.

Cat-light

Впечатления от NextHop-2021

Послушал вчера конференцию Yandex NextHop-2021.

Четыре доклада из десяти мне даже понравились. То есть примерно одна треть этой конференции оказалась для меня полезной. Вполне неплохой выхлоп.

Что касается остальных докладов. Мне эти-то сведения на практике точно никогда не применить. А уж остальные-то и подавно. Не так много в мире компаний масштабов рылокниги или тындекса, где вот реально нужны все эти spine-leaf, top-of-rack, 400-гигабитные линки и прочие непотребства. Но вообще всегда интересно чего новенького успели напридумать яйцеголовые, особенно если кто-нибудь умеет доступным языком рассказать. Но, к сожалению, с последним пукнтом почти всегда возникают проблемы.

Насчет этого вашего Yandex.Cloud, я искренне не понимаю кому и зачем он хотя бы теоретически может быть нужен. Да, они там внедрили хренову тонну каких-то инновационных решений, но на хрена козе баян?

Оратор из Juniper-а — это вообще позорище ходячее. Сочинил один раз какой-то весьма посредственный доклад про квантовые ключи и торгует с ним хлебалом на каждой более-менее подходящей по тематике конференции.

Про то, как в гугле пять лет тому назад вообще упразднили отдел мониторинга сети, и как там у них автоматически создаются тикеты на RMA (замену неисправных деталей) в случае выхода из строя железок, конечно, занятно послушать. Но это не стоило размусоливать на 45 минут. Кинули бы просто понты за 5...10 минут, да и ушли под аплодисменты.

Про ZTP и Segment Routing Policy я вообще не осилил. Уснул.

SwitchDEV — это всё, конечно, хорошо и замечательно. Но кому он реально нужен помимо FAANG, непонятно.

Собственно, и всё остальное примерно в том же духе. Наверное, действительно полезной была только инфа про различные форматы / стандарты SFP-модулей и про проблемы их (не)совместимости с чипами / шинами коммутаторов. А-ля ликбез. Но опять же, лично мне такие SFPшки, про которые шла речь, вряд ли когда-либо доведется хотя бы просто в руках подержать.

Правда, по результатам пары докладов меня таки посетили интересные мысли, ближе к философским рассуждениям.

... Когда-то далеко в начале 2000-ых, возможно году в 2005...2007 (точнее уже не вспомню) я на NAG-е (nag.ru) читал статью о том, как один небольшой украинский ISP забубенил себе маршрутизатор ядра сети на amd64. Они тогда хвастались, что сами пропатчили драйвера Intel-евых сетевух дабы раскидать их очереди по 24 ядрам процессоров, чтобы добиться приемлемых показателей pps (packets-per-second). А наградой за их труды стало очень-очень быстрое схождение Full View BGP на скольких-то там не занятых под транзит трафика оставшихся ядрах.

С тех пор проходит больше десяти лет, и что мы видим? Яндекс строит пограничный (!) FireWall на... та-да-а-а-ам... Linux + Intel X86_64 ! Правда, с тех пор много воды утекло. Появилась магия в виде eBPF и DPDK. Но сам факт. Как поёт группа "Пикник", "Маятник качнётся, всё опять начнётся". Ну да, ну да... от чего уходили, к тому и вернулись. ASIC-и, уясики, это всё не то. Хочешь настоящей гибкости и настоящей вычислительной мощности — при всём богатстве выбора другой альтернативы нет. © Только x86_64, только хардкор.

... А другой доклад мне очень сильно напомнил метания между тем, как же распределить обязанности между различными компонентами той или иной системы. Например, Intel встраивает графику в ядро CPU. А NVidia наоборот, предлагает ускорять всё на свете на мощностях видеоадаптера. Вроде бы они заняли каждый свою нишу. Но!

Теперь NVidia всерьёз полезла на рынок телекома и всего что с ним связано. Они предлагают вместо "традиционного" сетевого интерфейса совать в сервер ещё один сервер, только маленький. ARM-based SoC (System on Chip). Они называют это "DPU": "Data Processing Unit". Который уже и кофеварка, и кофемолка, и кофевозделывательная плантация. От привычного сетевого интерфейса там остались разве что шина PCI-Express да частично принципы взаимодействия с ядром операционной системы.

Как всегда обещают углубить, улучшить, расширить, ускорить и всё в этом духе. Мол, теперь ваша сетевая карточка — это прям вот полноценный L3, может прокачивать через себя какие-то лютые PPS и не подавиться. А вам уже не нужно ничего знать, только кнопочки нажимать: опытные сетевые инженеры всё настроят централизованно вместо вас. И вам уже не нужны дорогущие TOR-свитчи (Top-of-Rack) для превращения L2 в L3, типа экономия. При том, что вы можете мутить MPLS, eVPN и прочие оверлейные сети прямо на адаптере, воткнутом в ваш сервер.

По мне так, "ну кому нужен бильярдный шар с растущими на нём волосами"? © Но не знаю. Может и правда взлетит. Народ жы ж сходит с ума по облакам. Ждём ответа от Intel, где сетевая карточка будет встроена в CPU, использовать штатную оперативную память, уметь писать прямо в процесс внутри виртуальной машины, а выводы будут разведены прямо с ножек процессора в разъём RJ-45... Зачем? А хрен знает. Но прикольно же!

... Сначала рылокнига героически делает крутейшее централизованное управление сетью. Потом так же централизованно её валит на шесть часов. Красота! "Может не надо, Шурик? Надо, Федя. Надо." ©

Ох уж этот новый дивный мир.

Cat-light

Неочевидная подстава с Zabbix + TimeScaleDB

Очередной пример того, почему важно понимать что происходит "под капотом" в результате твоих действий, а не просто тупо что-нибудь настроить по инструкции из интернета.

Начиная с 5-й версии Zabbix поддерживает в качестве бэкенда связку PostgreSQL+TimeScaleDB. Мы эту штуку у себя гоняем, работает весьма неплохо. Но по собственной глупости влетел в одну засаду.

Дело в том, что при миграции с "ванильного" Postgres-а на TimeScaleDB специальный скрипт из комплекта Zabbix-а самостоятельно за сисадмина заботливо проставляет вот эти две "галочки" в настройках: "Override item history period" и "Override item trend period" (смотри скриншот).

Делает он это не просто так, и боже упаси вас их потом убрать. При этом никакой "защиты от дурака" не предусмотрено. В документации этот момент не оговорен. Если вы недостаточно внимательны, то скорее всего даже не заметите, что в настройках что-то поменялось. И впоследствии вы сможете снять эти галки, если захотите. Но тогда заббиксовский housekeeper и PostgreSQL сойдут с ума, нагадят вам много-много гигабайт ошибок в логах и могут даже вообще положить ваш Zabbix-сервер, если он не особенно мощный в плане железа. А вы будете сидеть и недоумевать что же произошло и почему.

А причина простая. После того, как TimeScaleDB упакует "старые" данные в архив, в нём уже нельзя ничего изменять (update / delete). Можно удалить этот chunk целиком. Но для этого все элементы данных должны иметь одинаковый "срок протухания". Поэтому после перехода на TimeScaleDB уже не получится выставлять различные сроки хранения для разных Item-ов и Trend-ов. Нужно будет принудительно причесать всех под одну гребёнку. Что и осуществляется выставлением вот этих двух настроек скриптом миграции.

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

Напоследок мелкая загадка линуксоидам. На первый взгляд очень простой вопрос. Вот скажите, имеет ли значение порядок записей в "/etc/hosts"? Например, есть ли разница между вот такими двумя вариантами:

192.168.1.1 myhost.foo.bar myhost
192.168.1.1 myhost myhost.foo.bar

?

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

Cat-light

VMWare призывает нарушать best practice

Немного холивара вам в ленту.

Вот ссылка на официальные рекомендации от VMWare в отношении гостевых виртуальных машин, работающих под Linux.

Цитата оттуда.

To change the hostname to a FQDN, run the command:
hostname system name.domain name
For example:
hostname server01.vmware.com

Ну да, ну да... Смотрим "man 1 hostname", где английским по белому написано.

The recommended method of setting the FQDN is to make the hostname be an alias for the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the hostname was "ursula", one might have a line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula

То есть, рекомендуется в имени хоста Linux-машины писать просто "myhost", затем в /etc/hosts дописать к нему рядышком FQDN. Тогда команда "hostname" без параметров будет выдавать "myhost", а "hostname -f" ответит "myhost.mydomain.foo".

В VM-твари же решили не заморачиваться с реализацией нормальных алгоритмов передачи подобной информации от гостя к хосту, поэтому советуют тупо забивать в hostname полную запись (FQDN).

Я и раньше-то недолюбливал поделки имени VMWare, а теперь ненавижу их ещё сильнее. Криворучки х**вы.

Cat-light

В Debian 11 слегка сломали LACP Bonding (802.3ad)

Если вы собираетесь обновляться с Debian 10 до Debian 11, и у вас имеются 802.3ad-агрегированные каналы (LACP Bonding), будьте предельно осторожны. Сеть может и не подняться после обновления.

В 11-м Debian-е (Bullseye) изменили логику работы скриптов ifenslave. Теперь, если он "видит" уже поднятый slave-интерфейс, то не будет добавлять его в bond. На эту тему был заведён баг в трекере. Поэтому если в 10-м Debian-е у вас был конфиг типа такого.

То в 11-м он "не взлетит". Надо убрать из него любые упоминания о физических интерфейсах и заменить "slaves" на "bond-slaves". Примерно так.

Больше подробностей здесь.

Всем работающих LACP-каналов.

Cat-light

Разобрался со swanctl, VICI, XFRM interface, route-based ipsec

Продолжаю свои изыскания на тему IPSec-а. На этот раз попал под раздачу "взрослый" Debian GNU/Linux со своим StrongSWAN. Захотелось посмотреть, можно ли организовывать "нормальную" удобную маршрутизацию через IPSec с Juniper-ом без использования GRE и Dummy-интерфейсов. Таки можно. Но требуется выполнение четырёх условий.


  1. Ядро 4.19 или более свежее.

  2. iproute2 версии 5.1.0 или более свежий.

  3. StrongSWAN версии 5.8.0 или более свежий.

  4. Конфиг для StrongSWAN писать в формате VICI, а не в "классическом" ipsec.conf

В актуальных версиях StongSWAN-а IKE-демон по имени Charon открывает UNIX-сокет, через который с ним могут общаться разные утилиты: давать команды и скармливать ему конфиги "на лету". В частности, для этого есть утилита "swanctl", плюс плагины для NetworkManager-а. Команды типа "ipsec блаблабла" нынче признаны устаревшими, поэтому ряд полезных фич через конфиг "ipsec.conf" попросту не поддерживается. Так что рано или поздно придется переходить на VICI / swanctl. Как оказалось, это совсем не больно, хотя немного помумукаться и пришлось.

Изначальная хотелка у меня была простая. Есть ноутбук, с которым я везде бегаю. Линуксовый, разумеется. Хочется прямо с него уметь цепляться в датацентр напрямую к Juniper-у. Чтобы не разворачивать дополнительно всякие сервера с OpenVPN и иже с ними. Собственно, рецепт ниже.

Сертификаты я генерировал при помощи старого доброго набора скриптов "Easy-RSA". Не смотрите на буквы "RSA", в эллиптику он тоже умеет. Как закачивать их на ждунипер, уже писал ранее. Далее просто куски конфигов как пример / шпаргалка / напоминашка. Я себе выделил "по-доброму" /29-подсеть. Дело вкуса. Понятно, можно делать как нравится.

Collapse )

Немного комментариев, на тему почему именно так, а не по-другому.

Выбор шифров. GCM-шифры являются более перспективными, не требуют аутентифицирующей подписи в ESP, соответственно дают меньший overhead. Но они доступны только в IKEv2. Раз уж берём IKEv2, то почему бы не взять более быстрые EC-алгоритмы вместо RSA. PRFSHA384 — потому что он захардкожен в Juniper-е и поменять там его нельзя. Если на противоположной стороне пытаться использовать что-то другое, то первая фаза просто не срастётся.

Директива "proxy-identity" в Juniper-е отличается от "traffic-selector" тем, что первая не добавляет автоматически маршруты в таблицы маршрутизации. Соответственно, её можно безболезненно применять для варианта "0.0.0.0/0". Что касается StrongSWAN-а, то там нужно обратить внимание на директивы "if_id_in" и "if_id_out". Это некий идентификатор интерфейса (линка), на который ссылаются XFRM-политики (можно посмотреть командами "ip -d link" и "ip xfrm policy"). Понятно, что оные циферки в настройках swanctl и iproute2 внезапно должны совпадать. Если такие директивы в конфиге swanctl есть, то он тоже не будет сам дописывать маршруты, а оставит их на совести iproute2. Поэтому тоже можно безболезненно писать "remote_ts = 0.0.0.0/0", а дальше уже разруливать средствами iproute2 так, как нам нравится.

Если выставлена настройка "start_action = start", то swanctl автомагически поднимет соединение в момент загрузки конфига. Но последнее тоже надо инициировать. Либо устанавливать пакетик "charon-systemd" (вот ни разу не очевидно), либо дёргать загрузку конфига ручками. Ну или через плагин для NetworkManager-а, кому что милее.

Пусть не смущает underlying interface = lo (dev lo) для настройки xfrm-интерфейса. Это глубоко пофигу, подойдет что угодно, главное чтобы он существовал. Эта настройка нужна только для сетевых карт, которые умеют в аппаратное ускорение (Offloading) IPSec. У вас такие есть? У меня тоже нет. Я даже не уверен, существуют ли таковые в природе.

MTU "внутри" тоннеля выставлен таким, потому что предполагается работа через провайдера, у которого для PPPoE почему-то спускается MTU=1480. Исходя из этого посчитан "внутренний" MTU. Тоннель, а не транспорт, потому что Juniper в Transport-mode IPSec попросту не умеет.

Вроде всё. Маловероятно, что мой опыт захочет повторить кто-нибудь ещё. Поэтому пишу больше для себя, на будущее. Но мало ли...

... Весьма символично, что талисманом всероссийской переписи населения выбран "Цыпа ВиПиН" (привет, VPN). Хотя, другой (не победивший) вариант под названием "Песец-переПисец" мне нравится намного больше. И похоже, не мне одному.

... Если к вам пришло что-то белое и пушистое, то знайте, для вас всё кончено. Это песец!!!11

Cat-light

ОколоITшный дыбр #21

... Мама пожаловалась, что дома "не работает интернет". Приехал. Действительно не работает. Но что совсем интересно, клиентские железки по DHCP почему-то получили адреса не из того VLAN-а. Хотел было разобраться детальнее, но ровно по той же причине не смог подцепиться к роутеру. Пришлось решить проблему по принципу "семь бед — один reset". После перезагрузки роутера всё тут же завелось.

И тут я смутно вспомнил, что на этом самом Mikrotik 951G еще до того, как перешил его в OpenWRT, уже ранее наблюдал эффект, когда при определённых условиях его встроенный свитч "переполняется" и начинает "подтекать". То есть, кадры из одного VLANа попадали в другой "мимо" маршрутизации. Специально сидел и ловил Wireshark-ом почему провайдер блокирует доступ в интернет (а там не с теми MAC-адресами ему кадры прилетали).

Но тогда я всё списал на глюкавость прошивки. Похоже, что таки не [только] прошивки. Видать, само железо тоже оставляет желать лучшего. А самое поганое, что у этого 951G нет "полностью независимых" логически портов, как у того же Mi Router и иже с ними. Оно всё по второму уровню идет через этот встроенный свитч. Роутер я, конечно, заменю. Но сам факт.

Теперь вот неспешно думаю, какой бы взять небольшой управляемый гигабитный коммутатор портов на 16. Чтобы без вентилятора, не шумный, и не сильно жручий электричество. И крайне желательно чтобы с L3. А то в Mi 3G портов всего три. Маловато будет.

... Раз уж вспомнил про коммутаторы. У меня прямо сейчас есть несколько Zyxel-ей. Да-да, именно Zyxel-ей, и именно коммутаторов. Оба проcтенькие совсем, но управляемые. Один с PoE, второй без. Так вот, какой же у них у**ищный интерфейс настройки! Это просто ахтунг какой-то. В веб-морде куча каких-то совершенно непонятных терминов. Какие-то менюшки. Просто сделать router-on-the-stick с ним превращается в увлекательнейший квест. Ни разу не понятно что делает та или иная "галка". Разные настройки VLANа рассованы по разным страницам. Вроде и железка ничего так, но этот отстойнейший интерфейс всё портит. Вот и чего они не сделают cisco-like cli? Непонятно. Тем более, что библиотеки для этого давным-давно есть и даже GNUтые.

... "Безопасники" в очередной раз отмочили. Поставили какой-то там "Nessus" и заявили, что 7-Zip из дистрибутива (Centos 7, ага) весь из себя "уязвимый" (ну да, архиватору жы ж жизненно необходимо быть неуязвимым со всех сторон). Поэтому мы его (7-zip) отовсюду снесём и пользоваться им не будем. А бэкапы будем паковать обычным ZIP-ом.

В очередной раз убеждаюсь, что вся эта "информационная безопасность" есть суть суходрочка для выбивания бабла из руководства / учредителей / акционеров / подведомственных организаций (нужное подчеркнуть). А мне теперь новая головная боль приехала: выбрать "правильный" архиватор для компрессии логов и бэкапов. Надо чтобы нормально паковал, имел шифрование с паролем из коробки, нормально скриптовался / автоматизировался. И чтобы, значит, всякие ихние Nessus и OpenVAS на него не ругались. Ну не на GZIP же идти. И не только выбрать, но и переписать все свои скрипты для создания и тестирования бэкапов. Сцуки.

... Чувствую, при слове "безопасность" я такими темпами скоро начну давать в рыло сразу, не разбираясь.

... Странные новости приходят. То якобы приостановили производство "Ковивака", то опровергли, мол, технологические линии переоборудуют. Ничего не понятно. Так будут его клепать или таки похоронили?

... 6 октября стартует очередной NextHop. Сам собираюсь послушать из дома. Ехать никуда не хочу.

... 29 сентября состоится вебинар по Tableau. Уж не знаю сколько оттуда я пойму, но поучаствовать тоже собираюсь. Чисто для общего развития.

Всем интересных событий и неуязвимых архиваторов.