Что нужно помнить про Cloud IAM и Kubernetes RBAC в GKE

Чтобы разграничить права пользователей по namespace нужно использовать Kubernetes RBAC, т.к. Cloud IAM не позволяет гранулярно задать привилегии внутри namespace. Сделал простую роль для namespace (Role/RoleBinding) и кластерную роль для просмотра namespace, storageclass и прочих ресурсов, которые не имееют привязки к namespace.

процессе отладки возникла проблема что пользователь, который должен видеть список namespace и оперировать ресурсами в пространстве имён "abc-dev", смог создать ресурс в пространстве имён "xyz-dev". Если проверять через kubectl auth can-i create secret --as user@example.com --namespace xyz-dev то возвращает false, но при этом ресурс создаётся.

Тестер ёмкости аккумуляторов ZB2L3 V2.3s

 Это обзор бюджетного тестера ёмкости аккумуляторов ZB2L3 V2.3s. В интернете хватает обзоров похожих модулей, но в процессе проверки моего экземпляра я столкнулся с отличиями и решил написать об этом.

Что заявил в описании модуля продавец:

• Максимальное входное напряжение 15V (разрешение вольтметра 0.01V, точность 1%+0.02V)
• Максимальный ток 3A (разрешение амперметра 0.001A, точность 1.5%+0.008A)
• Напряжение окончания разряда 0.5V - 11.0V (точность установки 0.1V)
• Максимальная измеряемая ёмкость 9999Ah
• Автоматическое определение напряжения окончания разряда
• Отключение нагрузки при достижении напряжения окончания разряда

Debian 12.3 image release delayed

 По привычке запустил sudo apt update && sudo apt upgrade, но несколько пакетов ядра не смогло скачать:

Не удалось загрузить пакет.:

E: http://deb.debian.org/debian bookworm/main amd64 linux-image-6.1.0-14-amd64 amd64 6.1.64-1 is not (yet) available (403 Access denied - broken package [IP: 151.101.86.132 80])

E: http://deb.debian.org/debian bookworm/main amd64 linux-image-amd64 amd64 6.1.64-1 is not (yet) available (403 Access denied - broken package [IP: 151.101.86.132 80])

А в почте нашлось уведомление от Debian:

Эмуляция Google Cloud Storage

Для тестирования Spark с хранилищем S3 мы используем MinIO. Это позволяет запускать тесты локально в Docker не имея доступа к реальной инфраструктуре. Недавно дошли до тестирования Spark с Google Cloud Storage и мне довелось разрабатывать аналогичный тест.

В году этак 2019, я искал способ эмулировать GCS для тестирования приложений, но тогда ничего работающего не нашлось.

Электронная нагрузка 75W

Мой проект электронной нагрузки 300W (почитать можно тут, тут и тут) всё ещё не готов к повседневному использованию, хотя и перешагнул стадию "куча проводов на столе". Чтобы не сидеть без электронной нагрузки неопределенное время, собрал простенькую полностью аналоговую электронную нагрузку небольшой мощности  (100V / 5A / 75W).

За основу взята схема с форума cxem.net, но в моём варианте пересчитаны номиналы компонентов для тока до 5A. В итоге нагрузка может потреблять до 75W, а кратковременно и все 80W, но не стоит так делать.

Миллиомметр своими руками

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

По закону ома любое сопротивление можно вычислить зная ток и падение напряжения на сопротивлении. Для измерений буду использовать ток 100mA, который стабилизируется LM317 а чтобы избежать потерь на проводах буду использоваться подключение Кельвина. Падение напряжения на измеряемом сопротивление будет измеряться мультиметром.

Жертвы нагрузочного тестирования

Тестировал новую электронную нагрузку которая была подключена к двум блокам питания 20В, включенным последовательно, что в сумме давало 40В. Начал с одного ампера и постепенно прибавлял измеряя температуру на радиаторе (используется система охлаждения от какого-то процессора AMD).

При двух амперах температура радиатора была около 60°C, решив что температура невелика, продолжил увеличивать ток (не подумав о суммарной мощности). В итоге на 2.3A амперметры зашкалило а шунт вообразил себя лампочкой. Выключать нагрузку было бесполезно и пришлось выключать уже блоки питания.

Почему сгорел лабораторный блок питания

В процессе тестирования новой электронной нагрузки погиб мой лабораторный блок питания. Он успел отработать около 5 минут, после из него вышел весь "волшебный дым" и в комнате запахло "жареной" электроникой. Эти 5 минут ЛБП работал на максимальных для него 30V/3A (90W) т.к. мне нужно было убедиться что охлаждение электронной нагрузки справится с 90W тепла.

Вскрыв корпус ЛБП для ремонта я увидел сгоревшую дорожку от трансформатора до диодов моста. Ради уменьшения нагрева были установлены диоды шоттки SB560 (60V 5A) - в теории это давало полуторный запас прочности. Прозвонка диодов показала что два их четырёх закоротило и это привело к выгоранию дорожки (мощность трансформатора 250W и спалить дорожку ему не составило труда).

Проблема с обновлением rpi-eeprom в Raspbian Bookworm

У меня есть принт-сервер для HP LaserJet 1018 на базе Raspberry Pi B+ в котором установлен Raspbian и CUPS. В конце октября я без проблем обновил эту систему с Raspbian Bullseye до Raspbian Bookworm, но сегодня при установке обновлений выдало ошибку:

Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up raspi-firmware (1:1.20231024+ds-1+rpt2) ...
stat: cannot read file system information for '/boot/firmware': No such file or directory
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package raspi-firmware (--configure):
 installed raspi-firmware package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of rpi-eeprom:
 rpi-eeprom depends on raspi-firmware; however:
  Package raspi-firmware is not configured yet.

dpkg: error processing package rpi-eeprom (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.142) ...
Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom

Варианты получения двухполярного питания

Недавно наткнулся на описания микросхемы ICL7107, которая является основой многих мультиметров прошлых лет и не требует значительной обвязки, и решил собрать на её базе миллиомметр. Эта микросхема требует двухполярное питание +5V/-5V и для быстрой проверки я использовал два блока питания на 5V, которые были соединены последовательно, а средняя точка выполняла роль общего провода (земли).

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

Первые шаги с OpenTofu

Из-за недавней смены лицензии Terraform возникла неопределенность с его дальнейшей судьбой в коммерческих проектах. В качестве ответа был создан форк OpenTofu, который будет развиваться под эгидой Linux Foundation и я попробовал оценить готовность OpenTofu с точки зрения drop-in replacement для Terraform.

Насколько мне известно, OpenTofu был форкнут с Terraform 1.5.5 (последняя версия под лицензией MPL) и никакой разницы с Terraform 1.5.x быть не должно. Я тестировал два последних релиза OpenTofu (1.6.0-alpha2 и 1.6.0-alpha3) и на первый взгляд достаточно создать алиас terraform на tofu чтобы все просто заработало, но всплыли нюансы.

Почему перегорает предохранитель при включении трансформатора

Столкнулся с перегоранием предохранителя на входе разделительного трансформатора при его включении в сеть без нагрузки. Изначально был установлен быстрый предохранитель на 1A (в маркировке указана буква "F") и его хватило на несколько таких включений.

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

Чтобы проверить эту теорию на практике, собрал схему для регистрации пускового тока - тороидальный трансформатор мощностью 10VA подключён к выходу разделительного трансформатора через шунт 0.1Ω. При токе в 1A на шунте будет падение напряжения в 0.1V. Бросок тока буду регистрировать осциллографом, второй канал который подключен параллельно сопротивлению. Использование разделительного трансформатора продиктовано соображениями безопасности, к тому же запрещается подключать осциллограф к сети без дифференциальных щупов (у меня таких не водится из-за значительной цены последних).

Доработка импульсного блока питания

Попросили оживить игрушечную гоночную трассу от которой был утерян блок питания. На коробке с игрой указано 6V, но после подключении лабораторного блока питания заметил два момента:

• машинки ехали задом-наперед (т.е. у родного блока питания минус был на центральном контакте, а плюс - на кольце)
• машинки ехали довольно медленно, даже если "давить газ в пол"

Поменяв полярность и подняв напряжение до 8V играть стало веселее, но все же достаточно первым нажать на газ и просто держать до последнего круга - никакого соревновательного момента нет. Поднял напряжение до 9V и на закруглении трассы машинки стали слетать если не притормозить. Играть стало заметно интереснее.

BTRFS warning (device dm-X): block group XXXXXXXXXX has wrong amount of free space

При загрузке виртуалки с Linux стала появляться ошибка связанная с BTRFS - "BTRFS warning (device dm-X): block group XXXXXXXXXX has wrong amount of free space", где dm-X - устройство device mapper на котором находится BTRFS, а XXXXXXXXXX - номер блока файловой системы.

Sep 22 09:01:35 vbox kernel: Btrfs loaded, crc32c=crc32c-intel
Sep 22 09:01:35 vbox kernel: BTRFS: device fsid 683a86c5-a6f1-4b68-b0f9-5330e443a1e4 devid 1 transid 1769033 /dev/mapper/debian--jessie--vg-docker scanned by btrfs (191)
Sep 22 09:01:36 vbox kernel: BTRFS info (device dm-2): using crc32c (crc32c-intel) checksum algorithm
Sep 22 09:01:36 vbox kernel: BTRFS info (device dm-2): flagging fs with big metadata feature
Sep 22 09:01:37 vbox kernel: BTRFS info (device dm-2): disk space caching is enabled
Sep 22 09:01:37 vbox kernel: BTRFS info (device dm-2): enabling ssd optimizations
Sep 22 09:01:48 vbox kernel: BTRFS warning (device dm-2): block group 71072481280 has wrong amount of free space
Sep 22 09:01:48 vbox kernel: BTRFS warning (device dm-2): failed to load free space cache for block group 71072481280, rebuilding it now

Хотя и пишет что "rebuilding it now", но за несколько дней ничего не изменилось. В Linux fsck для BTRFS это заглушка, которая ничего не делает и потому придётся исправлять вручную.

Как зарядить Huawei Band 6 без кабеля

Разрядился фитнес-браслет Huawei Band 6, а родной кабель для зарядки забыли в другом городе. Выйти из ситуации можно если знать полярность подключения питания к браслету, но распиновку в Интернете я найти не смог.

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

Обновление электронной нагрузки

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

Чтобы вся эта конструкция не каталась по столу снизу прикреплены приборные ножки из резины. Для измерения тока и напряжения реализовано четырёх-проводное подключение.

Электронная нагрузка не поддерживает заданный ток

В процессе тестирования электронной нагрузки на большой мощности (больше 220W при подключении к автомобильному аккумулятору) заметил что нагрузка не поддерживает заданный ток и он заметно изменяется по мере прогрева силовой платы.

Сначала было подозрение на схему ЦАП, которая представляет собой 8-битный R-2R из резисторов 1% точности, но замер напряжения на выходе не показал отклонений во время работы (колебания в десятые доли милливольта я не беру во внимание).

Электронная нагрузка 300W

Начинал этот проект больше года назад, но тогда он был собран практически полностью по схеме из этого видео. Печатная плата была изготовлена методом ЛУТ (Лазерно-Утюжная Технология) по макету из видео (спасибо Артуру за исходники платы). В моём случае применены 4 полевых транзистора IRFP054NPBF, которые без проблем держат ток 20A при напряжении 15V на входе нагрузки (ограничение мощности в 300W, которое связано с максимальной рассеиваемой мощностью корпуса транзисторов TO-247). Еще пришлось увеличить номинал керамических конденсаторов в цепи обратной связи ОУ (Операционный Усилитель) с 1nF до 100nF (с 1nF была паразитная генерация начиная с определенной мощности).

Регулировка мощности делалась переменным резистором и этого полностью хватало для проверки блоков питания, но в случае разрядки аккумуляторов для проверки их ёмкости нужно было следить за напряжением и вовремя отключать силовую часть. В доработанном варианте схемы измерения ёмкости использовалось реле, которое замыкало вход ОУ на землю при достижении минимального напряжения - это отключало силовую часть нагрузки.

Обновление Nextcloud 25 с Debian Bullseye до Debian Bookworm

Неспеша обновляю хосты с Debian Bullseye до Debian Bookworm и на той неделе столкнулся с ситуацией когда не получилось привычным способом обновить сервер с установленным Nextcloud 25.

В Bookworm поставляется PHP 8.2 который не поддерживается в Nextcloud 25, а сначала обновить Nextcloud до 26 в Debian Bullseye тоже нельзя, т.к. в Nextcloud 26 удалена поддержка PHP 7.4.

В этом случае придется следовать процедуре ручного обновления, предварительно обновив дистрибутив до Debian Bookworm в котором уже PHP 8.2.

Midnight Commander 4.8.30

Собрал пакеты Midnight Commander 4.8.30 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):

• Debian Buster (i386, amd64, armel, armhf, arm64)
• Debian Bullseye (i386, amd64, armel, armhf, arm64)
• Debian Bookworm (i386, amd64, armel, armhf, arm64)
• Debian Sid (i386, amd64, armel, armhf, arm64)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Xenial (i386, amd64, armhf, arm64)
• Ubuntu Bionic (i386, amd64, armhf, arm64)
• Ubuntu Focal (amd64, armhf, arm64)
• Ubuntu Jammy (amd64, armhf, arm64)
  

Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.

Использование PCRE2 для поиска не включено, т.к. в этом случае пакет не собирается в Ubuntu Trusty. В апреле следующего года будет EOL для Ubuntu Trusty и можно будет собрать пакет с поддержкой PCRE2.

HashiCorp сменил лицензию своих продуктов с MPL на BSL

Новость про смену лицензии появилась еще на прошлой неделе, но только сегодня дошли руки разобрать ленту и расстроиться. Из важного я вижу два абзаца:

End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp. Partners can continue to build integrations for our joint customers. We will continue to work closely with the cloud service providers to ensure deep support for our mutual technologies. Customers of enterprise and cloud-managed HashiCorp products will see no change as well.

Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.

Я не юрист и не разбираюсь во всех тонкостях лицензирования, но для меня это выглядит плохо. Еще хуже, чем смена лицензии на продукты Elastic или отказ от публицации всех исходников у RedHat (я почти не пользуюсь этими продуктами и не сильно расстроился). У Gruntwork есть пост по поводу смены лицензии Terraform и как это изменение повлияет на их клиентов.

Что делать дальше? Ну например зафиксировать версии продуктов HashiCorp на тех, которые еще выпущены под лицензией MPL (например Terraform 1.5.5). Но такая фиксация в будущем обернется трудностями с исправлениями уязвимостей (в первую очередь актуально сетевых сервисов вроде Vault и Consul) и возможно к созданию форков.

Не работает vagrant ssh в Windows 10

 Если после успешного создания виртуальной машины в Vagrant вы не можете зайти в нее через SSH, то проверьте какую версию ssh она использует (vagrant ssh --debug). В Windows 10 появился встроенный клиент SSH (c:\Windows\System32\OpenSSH\ssh.exe) и если он установлен (его можно удалить), то скорее всего будет ругаться на права доступа к приватному ключу:

W:\test>c:\Windows\System32\OpenSSH\ssh.exe -i .vagrant\machines\default\virtualbox\private_key -p 2222 vagrant@127.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '.vagrant\\machines\\default\\virtualbox\\private_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".vagrant\\machines\\default\\virtualbox\\private_key": bad permissions
vagrant@127.0.0.1: Permission denied (publickey).

Это известная проблема (#9433 и #9831) и достаточно указать Vagrant предпочитать бинарники из своего дистрибутива вместо системных

W:\test>set VAGRANT_PREFER_SYSTEM_BIN=0
W:\test>vagrant ssh
Linux bullseye 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Aug 14 11:56:53 2023 from 10.0.2.2
vagrant@bullseye:~$

Чтобы не задавать переменную каждый раз ее нужно прописать в список переменных для пользователя или всей системы.

Разное поведение плат Arduino при работе через последовательный порт

Собрал на макетных платах минимальную начинку электронной нагрузки и стал искать готовую программу для компьютера, которая имеет описанный протокол работы с железом. На GitHub нашелся проект Electronic_load_px100 у которого есть описание протокола.

Чтобы отладить работу с протоколом я взял свободную Arduino Leonardo и набросал для нее скетч, который эмулирует поведение электронной нагрузки. После отладки стал переносить код протокола в основной скетч уже моей электронной нагрузки (которая сделана на базе Freeduino 2009, аналога Arduino Duemilanove) и столкнулся с проблемой, что программа на компьютере больше не определяет что подключена электронная нагрузка.

ASRL/dev/ttyUSB0::INSTR
SerialInstrument at ASRL/dev/ttyUSB0::INSTR
probe
<class 'pyvisa.errors.VisaIOError'>
('VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.',)
VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.
error reading bytes
no answer
ko
No instruments found

Был уже поздний вечер и хотелось увидеть реальные показания и потому сразу попробовал поменять местами Freeduino и Arduino Leonardo - не помогло. Разные распиновки для I2C и не инициализируется периферия. Залил скетч эмулятора в обе платы и стал сравнивать их поведение - на Leonardo все просто работает, а на Freeduino - ошибка. Обратил внимание что отличаются названия портов - у Leonardo это /dev/ttyACM0, а у Freeduino это /dev/ttyUSB0, но почему на одном работает, а на втором - нет я не понял и пошел спать.

Минимальное напряжение AREF для ADC

Нужно было измерить линейность R-2R ЦАП после резистивного делителя (было интересно насколько просядет максимум сигнала и сохранится ли линейность). Исходный сигнал лежит в диапазоне от 0V до почти напряжения питания (в моем случае было 0V - 4.95V), но для моих целей нужно чтобы сигнал был в пять раз меньше (0V - 0.5V).

Измерения делались через АЦП Atmega32U4 (Arduino Leonardo) - у этого микроконтроллера есть несколько вариантов опорного напряжения АЦП:

• DEFAULT - 5V;
• INTERNAL - 2.56V;
• EXTERNAL - то, что подается на пин AREF;

Вначале попробовал вариант с 2.56V, но это в шесть раз больше чем максимум измеряемого сигнала и хотелось лучшей точности. Стал пробовать вариант EXTERNAL - подал на пин AREF 0.5V относительно земли и получил "зашкал" на АЦП - все значения были 1023 даже если на вход подавалось 0V. Вначале грешил на "кривую" ардуину и стал прозванивать пины микроконтроллера и сверяться с даташитом - никаких ошибок не нашёл.

А потом поднял напряжение AREF до 1V и оно заработало! В гугле на первой странице есть описание этой проблемы. Я не поленился и пошёл перечитывать даташит, но ничего про минимальное напряжение AREF в нем не нашёл. Если верить документации Arduino, то на AREF можно подавать от 0V до 5V и либо это целиком зависит от микроконтроллера, либо в документации стоит поправить.

Цифро-аналоговый преобразователь

Есть задача управлять платой электронной нагрузки через микроконтроллер. Чтобы делать это нужно подавать напряжение от 0V до 0.5V на вход операционного усилителя, который управляет силовыми транзисторами. Это задача для цифро-аналогового преобразователя (ЦАП), но ни один из микроконтроллеров, которые есть у меня под рукой, не содержат ЦАП.

Варианты действий:

1. использовать ШИМ (PWM) и ФНЧ (LPF);
2. собрать R-2R ЦАП используя сопротивления с высокой точностью;
3. микросхема ЦАП;

GitLab CI не выполняет after_script при таймауте

На днях столкнулся с очень старой проблемой (открыта 6 лет назад) в GitLab CI когда after_script не выполняется если джоба отвалилась по таймауту. В моём случае в after_script реализован сбор логов эфемерного окружения для end-to-end теста. Ирония в том что при успешном прохождении теста эти логи, как правило, никто не смотрит. А вот если тест упал, то начинают разбираться, а логов нету...

Первой мыслью было внедрить контроль времени в сам сценарий тестирования, но это не всегда бывает удобно или возможно. Например при нехватке ресурсов в кластере значительно возрастает время ожидания установки чартов и считать время придется придётся после каждой команды которая потенциально может стать "долгой".

Второй мыслью был timeout из coreutils:

$ timeout --kill-after=350s 300s ./test.sh

В принципе эта утилита не должна оставлять "осиротевших" процессов, но если запуск происходит вне контейнера, то дополнительно можно добавить systemd-run:

$ timeout --kill-after=350s 300s systemd-run --user --pty --same-dir --wait --collect ./test.sh

На следующей неделе попробую внедрить в один из проектов и посмотреть.

Выборка данных из CSV файла

Нужно обработать отчёт сканеров уязвимостей, который CI сохраняет в CSV и HTML. Внутри CSV файла есть следующие колонки

• Scanner
• Component
• Package
• Type
• Vulnerability ID
• Severity
• Installed Version
• Fixed Version

Нужно в CI показать краткий отчет со списком найденных уязвимостей, важностью и в каких компонентах есть данная уязвимость.

Скачать объект из GCS бакета без gsutil

Чтобы скачать объект из Google Cloud Storage (GCS) бакета необязательно устанавливать google-cloud-sdk или даже gsutil. При условии что токен можно получить у metadata server, то достаточно curl и jq

Пример ниже скачивает gs://GCS_BUCKET_NAME/tests/data.zip

AUTH_TOKEN=$(curl -fsSH 'Metadata-Flavor:Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq -r .access_token)

curl -X GET -H "Authorization:Bearer ${AUTH_TOKEN}" -Lo /tmp/data.zip https://storage.googleapis.com/GCS_BUCKET_NAME/tests/data.zip

Проверка подключения по IPv6 в Nagios

Несколько лет использовал www.google.com в Nagios чтобы проверять "связность" своих серверов с внешним миром по IPv6. На позапрошлой неделе сервера попали в "бан" и проверка перестала работать.

Поскольку www.google.com все же не предназначен для таких проверок, то переделал проверку на использование msftconnecttest.com. Для IPv6 вместо www.msftconnecttest.com нужно использовать ipv6.msftconnecttest.com.

Этот сервис использует Windows чтобы проверить подключение к Internet. Если при скачивании http://ipv6.msftconnecttest.com/connecttest.txt вы получаете строку "Microsoft Connect Test", то все IPv6 работает без ограничений.

$ /usr/lib/nagios/plugins/check_http -6 -H ipv6.msftconnecttest.com -u /connecttest.txt -s 'Microsoft Connect Test'
HTTP OK: HTTP/1.1 200 OK - 537 bytes in 0.012 second response time |time=0.012383s;;;0.000000;10.000000 size=537B;;;0

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05

Периодически сталкиваюсь с устареванием GPG ключа которым подписывается APT репозитарий google-cloud-sdk. Ошибка выглядит так:

Err:9 https://packages.cloud.google.com/apt cloud-sdk InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
Fetched 6,361 B in 1s (4,349 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
27 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.cloud.google.com/apt cloud-sdk InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Failed to fetch https://packages.cloud.google.com/apt/dists/cloud-sdk/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Some index files failed to download. They have been ignored, or old ones used instead.

Судя по выводу GPG старый ключ (7F92E05B31093BEF5A3C2D38FEEA9169307EA071) истёк еще в начале марта

$ gpg /usr/share/keyrings/cloud.google.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa2048 2021-03-01 [SC] [expired: 2023-03-02]
      7F92E05B31093BEF5A3C2D38FEEA9169307EA071
uid           Rapture Automatic Signing Key (cloud-rapture-signing-key-2021-03-01-08_01_09.pub)
sub   rsa2048 2021-03-01 [E] [expired: never     ]
pub   rsa2048 2020-12-04 [SC] [expired: 2022-12-04]
      59FE0256827269DC81578F928B57C5C2836F4BEB
uid           gLinux Rapture Automatic Signing Key (//depot/google3/production/borg/cloud-rapture/keys/cloud-rapture-pubkeys/cloud-rapture-signing-key-2020-12-03-16_08_05.pub) <glinux-team@google.com>
sub   rsa2048 2020-12-04 [E] [expired: never     ]

Назначение префикса URI для веб сервисов

Эта история из разряда "как не нужно делать". Изначально не планировал ее писать, но потратил некоторое количество времеми и хочется предостеречь других от хождения по граблям.

Имеется набор веб сервисов в которых не реализована настройка префикса URI, т.е. все ссылки строятся относительно "корня" (например: hostname:port/login, hostname:port/public/script.js, и т.д.).

И есть желание проверить сможет ли Nginx прозрачно проксировать запросы добавляя префикс каждому сервису чтобы не пришлось менять внутренности самих сервисов.

Сразу скажу что существует более надежное и простое решение - дать каждому сервису собственный поддомен, но это бывает сложно с точки зрения процессов: одобрение доменных имён, новые записи в DNS, SSL сертификаты и т.д.

Решение проблемы "sysctl: permission denied" при обновлении GitLab

У меня GitLab живёт в непривилегированном контейнере LXC и при очередной установке обновления появились ошибки связанные с отсутсвием прав менять настройки sysctl. Это ожидаемое поведение, т.к. на сервере много других контейнеров и я не хочу чтобы каждый из них мог крутить настройки ядра.

Ошибки выглядят пример так

  * gitlab_sysctl[kernel.sem] action create
    * directory[create /etc/sysctl.d for kernel.sem] action create (up to date)
    * file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] action create[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] backed up to /opt/gitlab/embedded/cookbooks/cache/backup/opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf.chef-20230331221328.890308
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] updated file contents /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf

      - update content in file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf from 09a346 to 3b0a60
      --- /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf    2017-06-21 13:47:53.000000000 +0300
      +++ /opt/gitlab/embedded/etc/.chef-90-omnibus-gitlab-kernel20230331-271264-19acez0.sem.conf       2023-03-31 22:13:28.886738600 +0300
      @@ -1 +1 @@
      -kernel.sem = 250 32000 32 262
      +kernel.sem = 250 32000 32 275
    * link[/etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf] action create (up to date)
    * execute[load sysctl conf kernel.sem] action nothing (skipped due to action :nothing)
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] sending run action to execute[load sysctl conf kernel.sem] (delayed)
    * execute[load sysctl conf kernel.sem] action run
      [execute] sysctl: permission denied on key "kernel.sem"

Чтобы избежать попыток "крутить" настройки ядра достаточно добавить параметр package['modify_kernel_parameters'] = false в /etc/gitlab/gitlab.rb и выполнить обновление конфигурации

$ cat <<_EOF_ | sudo tee -a /etc/gitlab/gitlab.rb
gitlab_kas['enable'] = false
_EOF_

$ sudo gitlab-ctl reconfigure

$ sudo gitlab-ctl restart

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

Мучение с no_proxy в hadoop-aws

Про боль с настройками прокси для разных приложений в своё время хорошо написали в блоге GitLab. Я лишь немного добавлю про комбинацию Docker, HTTP Proxy и Hadoop-AWS, который мы используем в Apache Spark для записи данных в объектное хранилище.

Ранее я уже писал про тестовое окружение в котором чтобы скачать что-либо за пределами VPC нужно использовать корпоративный прокси-сервер. На CI сервере прокси настроен в Docker и этого достаточно чтобы собирались образы. Настройки прокси пробрасываются внутрь контейнеров в виде переменных окружения (подробности тут). Чтобы прокси не использовался там где не нужно задана переменная окружения "no_proxy" в которой перечислены все исключения на сервисы тестируемого приложения, ядром которого является Apache Spark.

Убрать начальный ноль из месяца, часа, минуты или секунды в date

В генераторе данных для нагрузочного тестирования ETL используется команда date чтобы получить часы, минуты и секунды. По-умолчанию они имеют "0" в качестве префикса что с свою очередь приведет к ошибкам в "математике" bash

$ echo $(( 60 - $(date +%S) ))
-bash: 60 - 09: value too great for base (error token is "09")

Можно использовать sed чтобы убрать начальный ноль

$ echo $(( 60 - $(date +%S | sed -e 's/^0//') ))

Но на StackOverflow нашлось более красивое решение - использовать padding modifiers в date

$ echo $(( 60 - $(date +%-S) ))

Полный список модификаторов есть в man date.

Установка Prometheus Node Exporter на Raspberry PI 3 OpenELEC

Это пошаговое руководство описывает установку Prometheus Node Exporter v1.5.0 на Raspberry PI 3 с OpenELEC 9.2.8.

Скачиваем дистрибутив Prometheus Node Exporter для Linux с архитектурой armv7 (BCM2835 не поддерживает arm64) в /storage (в OpenELEC все пользовательские изменения должны сохраняться в /storage).

# cd /storage

# curl -fsSLO https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-armv7.tar.gz

# tar -xzf node_exporter-1.5.0.linux-armv7.tar.gz

# mkdir /storage/node_exporter/

# install -o root -m 755 node_exporter-1.5.0.linux-armv7/node_exporter /storage/node_exporter/node_exporter

# rm -fr /storage/node_exporter-1.5.0.linux-armv7 node_exporter-1.5.0.linux-armv7.tar.gz

Генератор данных для нагрузочного тестирования ETL

На текущем проекте для нагрузочного тестирования ETL нужен постоянный поток данных от телекоммуникационного оборудования. Размер сетей, тип и объём данных в метриках (сети 3g/4g/5g, оборудование разных вендоров) различается от клиента к клиенту и пока сетевики занимаются организацией доступа в сеть заказчика нужно определить системные требования и посчитать стоимость ресурсов чтобы заложить бюджет. Далее будет развёртывание окружения под клиента и оценка надёжности его работы сверх ожидаемой нагрузки (чтобы был запас по прочности на случай если у заказчика метрик станет заметно больше, чем планировалось).

Для функционального тестирования достаточно загрузить тестовый набор данных от клиента (чтобы убедиться что ETL корректно разбирает данные метрик), но это не подходит для нагрузочного тестирования, когда нужно проверить какую максимальную нагрузку выдержит система прежде чем мы перестанем соответствовать SLO (Service Level Objective).

Медленная сборка Docker образа

На прошлой неделе начались заметил очень медленную сборку Docker образов на базе Ubuntu. Скорость загрузки с archive.ubuntu.com / security.ubuntu.com была в районе 400kB/s и ping до этих хостов был в районе 250ms. Поскольку на аналогичную проблему жаловался и коллега, то маловероятно что проблема с моим подключением к Internet (тем более что speedtest.net не показал ничего криминального).

Решить эту проблему можно несколькими способами:

1. Использовать местное зеркало Ubuntu (потребует редактирования Dockerfile)
2. Использовать кеширующий прокси сервер в конфигурации APT (потребует редактирования Dockerfile)
   
3. Использовать альтернативный DNS сервер, который будет резолвить archive.ubuntu.com/security.ubuntu.com на IP адрес зеркала (при условии что в sources не используется HTTPS)

Времени было мало и потому пошёл путём наименьшего сопротивления - использовал аргумент --add-host для команды docker build

$ docker build --add-host=archive.ubuntu.com:<IP> \
               --add-host=security.ubuntu.com:<IP> -t image-name .

Пакеты всё ещё скачивает из Internet, но зато подходит для большинства случаев и не требует дополнительных сервисов.

YAML грабли

Есть мнение что YAML это простой и дружелюбный формат (этакий JSON с комментами), противоположное мнение тоже существует.

Сегодня наступил на грабли с Helm в котором функция toYaml теряет кавычки из значений и таким образом меняет тип данных. Этот баг завели еще 4 года назад, но закрыли без решения проблемы. Каждый выкручивается как может - мне пришлось заменить

{{- with .Values.extraEnvVars }}
{{- toYaml . | nindent 10 }}
{{- end }}

на вариант с range

{{- range .Values.extraEnvVars }}
- name: {{ .name }}
  value: {{ .value | quote }}
{{- end }}

В других случаях (вроде аннотаций) будут свои особенности.

Совместный доступ исходникам

Моя проффесиональная деятельность в основном связана с Linux, хотя последние 6 лет на рабочем компьютере установлена Windows. Я делал несколько попыток пользоваться WSL, когда он только появился в Windows, но каждый раз опыт был негативный. Частые зависания подсистемы Linux и приходилось перезагружать Windows. Не работал Docker и некоторые другие программы. В то же время у меня появилась виртуальная машина VirtualBox с Debian внутри, которая после нескольких обновлений работает и по сей день. Вначале я пользовался shared folders в VirtualBox чтобы была возможность запускать IDE в Windows, но запускать программы в Linux. Это работало, но с определенными проблемами.

Поскольку в Windows выполнялось только редактирование файлов, то рациональным решением стало переносом их на сторону файловой системы Linux, а Windows становилась клиентом. Для этого я настроил NFS сервер в Linux и подключал его через NFS клиент Windows. С таким подходом тоже были нюансы, но такая схема успешно продержалась до прошлого года. Определенную головную боль приносило создание директорий в Windows (т.к. при монтировании в Windows использовалась опция -o fileaccess=644, то директории создавались, но зайти в них было нельзя), но если создавать их в Linux, то все работало нормально. Еще где-то полгода назад появилась проблема с сохранением файлов из Windows (ругалось что файл занят и запись невозможна, но кроме Windows с этим файлом никто не работал) - возможно виноват какой-то из дополнительных "агентов", которые установлены на рабочем компьютере.

Midnight Commander 4.8.29

Собрал пакеты Midnight Commander 4.8.29 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):

• Debian Buster (i386, amd64, armel, armhf, arm64)
• Debian Bullseye (i386, amd64, armel, armhf, arm64)
• Debian Bookworm (i386, amd64, armel, armhf, arm64)
• Debian Sid (i386, amd64, armel, armhf, arm64)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Xenial (i386, amd64, armhf, arm64)
• Ubuntu Bionic (i386, amd64, armhf, arm64)
• Ubuntu Focal (amd64, armhf, arm64)
• Ubuntu Jammy (amd64, armhf, arm64)
  

Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.

По причине отсутствия доступа к серверу ночных сборок (которые не делались с прошлого года), я удалил их поддержку и пока не планирую возвращать ее в ближайшем будущем. Из приятного - добавлена поддержка Debian Bookworm, который уже на стадии заморозки.

P.S. Судя по истории моих правок странички https://midnight-commander.org/wiki/Binaries собирать каждый релиз новый mc я начал больше 11 лет назад.

Тест работает локально, но не работает в CI пайплайне

В процессе прикручивания Continuous Integration (CI) к приложению столкнулся с ситуацией когда end-to-end сценарий тестирования не работает в пайплайне. В то же время он корректно отрабатывает на локальной машине. У окружения CI отстутствует прямой доступ в Internet, но это не должно играть никакой роли т.к. сценарий написан таким образом, что приложение не предполагает ходить за пределы локальной машины.

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

Подключаюсь к Spark UI и вижу что задание обработки данных напрочь отсутвует. Далее смотрю логи компонента, который отвечает за его создание, но там никакого криминала нет. Иду в контейнер Spark Worker и начинаю медитировать на логи, а точнее их практически полное отсутствие.

VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Столкнулся с тем, что Vagrant не может запустить виртуальную машину VirtualBox в headless режиме на Windows 10

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "df70e47d-8ba3-4103-b826-8bbfadff8794", "--type", "headless"]

Stderr: VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

К Vagrant эта проблема не имеет отношения, т.к. сама команда VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless завершается с такой же ошибкой

C:\Program Files\Oracle\VirtualBox>VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless
Waiting for VM "df70e47d-8ba3-4103-b826-8bbfadff8794" to power on...
VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Версия VirtualBox 6.1.40 r154048, если запускать виртуальную машину с GUI, то ошибки не вознимает. В качестве решения попробовал перезагрузиться и переустановить VirtualBox, но это не помогло. Сейчас под рукой нет другой Windows 10 чтобы проверить возникает ли проблема там.

На форуме VirtualBox есть тема с похожими симптомами (Unable to headless start and detachable start), но там речь про Windows 11 и я не уверен что это тот же случай.

В баг трекере есть #17679 (Error on trying to run VM in headless mode), которому уже 5 лет. Во всех схожих случаях просят VBoxHardening.log, но никакие логи не появляются при этой ошибке.

В качестве временного решения сконфигурировал Vagrant запускать виртуальную машину с GUI.

Обновлено 15/01/2023: Попробовал запустить виртуальную машину на VirtualBox 7.0.4 - результат аналогичный. И логов все еще не пишет.

[Решено] Не устанавливается Vagrant на Windows

Не получилось установить Vagrant 2.3.4 на машинку с Windows 10 из-за ограничений UAC

Свойства файла выявили отозванный сертификат, которым подписан инсталлятор.

Без особой надежды сообщил о проблеме на форуме Hashicorp где оперативно указали на https://github.com/hashicorp/vagrant/issues/13051.

Выполнил команду certutil -URLCache CRL delete но сертификат все еще значится как отозванный. Попробую подождать до завтра, т.к. в комментариях было упоминание что спустя какое-то время все начинает работать.

Обновлено 12/01/2023

На следующий день проверил состояние сертификата - "This digital signature is OK".

Просто нужно было подождать некоторое время после очистки кэша CRL. После этого UAC не мешал установке Vagrant.