Проверка подключения по 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 сертификаты и т.д.