Есть задача управлять платой электронной нагрузки через микроконтроллер. Чтобы делать это нужно подавать напряжение от 0V до 0.5V на вход операционного усилителя, который управляет силовыми транзисторами. Это задача для цифро-аналогового преобразователя (ЦАП), но ни один из микроконтроллеров, которые есть у меня под рукой, не содержат ЦАП.
Варианты действий:
На днях столкнулся с очень старой проблемой (открыта 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
На следующей неделе попробую внедрить в один из проектов и посмотреть.
Нужно обработать отчёт сканеров уязвимостей, который CI сохраняет в CSV и HTML. Внутри CSV файла есть следующие колонки
Нужно в CI показать краткий отчет со списком найденных уязвимостей, важностью и в каких компонентах есть данная уязвимость.
Чтобы скачать объект из 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
Несколько лет использовал 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
Периодически сталкиваюсь с устареванием 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, т.е. все ссылки строятся относительно "корня" (например: hostname:port/login, hostname:port/public/script.js, и т.д.).
И есть желание проверить сможет ли Nginx прозрачно проксировать запросы добавляя префикс каждому сервису чтобы не пришлось менять внутренности самих сервисов.
Сразу скажу что существует более надежное и простое решение - дать каждому сервису собственный поддомен, но это бывает сложно с точки зрения процессов: одобрение доменных имён, новые записи в DNS, SSL сертификаты и т.д.