Задержка ответа DNS до 5 секунд или более в GKE

Изначально эта проблема попала ко мне с описанием "Нестабильная работа Solr на всех окружениях". В админке Drupal сайта тестирование настроек Solr в большинстве случаев завершалось с ошибкой, но сам поиск хоть и очень медленно, но работал.

Сперва выполнил пробный запрос к Solr из одного из контейнеров чтобы подтвердить наличие проблемы - с приличной задержкой, но запрос выполнился. Повторил запрос в цикле и получилось что время выполнения запроса "скачет" от 100 миллисекунд до 12 секунд. Чтобы исключить проблемы с DNS попробовал подключиться к Solr по IP, а не по FQDN - запрос выполняется быстро. Повторяю тест используя IP вместо FQDN в цикле и результат находится в пределах 100 - 150 миллисекунд. Выходит что проблема в DNS, но пока не ясно виноват kube-dns или вышестоящий DNS сервер к которому обращается kube-dns. Попробовал обращаться к другим доменам, например www.google.com - поведение аналогичное. Описание проблемы меняется с "Нестабильная работа Solr на всех окружениях" на "Нестабильная работа DNS в GKE на всех окружениях".

SSH логин в GCP VM по паролю

Чтобы зайти на виртуальную машину через SSH в GCP удобно использовать команду gcloud compute ssh, но по умолчанию используются ключи, которые добавляются на уровень проекта, либо в саму виртуальную машину. Чтобы зайти с авторизацией по паролю нужно указать опцию --plain

$ gcloud compute ssh <instance> --plain --project <gcp-project> --zone <gcp-zone>

Такой подход удобен когда у виртуальных машин нет публичных IP адресов и можно подключаться используя Identity Aware Proxy (IAP) без промежуточных решений вроде AWS Workspace, bastion host или VPN.

Midnight Commander 4.8.26 для Ubuntu Hirsute

Добавил в свой репозитарий поддержку Ubuntu Hirsute (21.04) и собрал пакеты Midnight Commander 4.8.26 для архитектур amd64, armhf и arm64.

Новый GPG ключ для репозитария

Перевел свой репозитарий на новый GPG RSA/4096 ключ:

GPG key ID: 0x776F2A248D76B064
Fingerprint: F6DE 7A3E D638 7B13 0F55  E6FF 776F 2A24 8D76 B064

Если у вас установлен пакет tataranovich-keyring и вы своевременно устанавливаете обновления, то ничего делать не нужно - новый ключ уже должен быть установлен. Чтобы убедиться в этом проверьте что пакет tataranovich-keyring имеет версию 2021.05.17:

$ apt-cache policy tataranovich-keyring | head -n3
tataranovich-keyring:
  Installed: 2021.05.17
  Candidate: 2021.05.17

Установить или обновить пакет tataranovich-keyring:

$ KEYRING_VERSION='2021.05.17'
$ wget http://www.tataranovich.com/debian/pool/sid/main/t/tataranovich-keyring/tataranovich-keyring_${KEYRING_VERSION}_all.deb
$ sudo dpkg -i tataranovich-keyring_${KEYRING_VERSION}_all.deb
$ rm -v tataranovich-keyring_${KEYRING_VERSION}_all.deb

Failed to find a valid digest in the 'integrity' attribute for resource

Сбросили проблему с нерабочим поиском на статическом сайте. В консоли браузера несколько раз появляется ошибка "Failed to find a valid digest in the 'integrity' attribute for resource". В коде страницы для ресурсов используется механизм integrity и если хеш не сходится, то браузер не дает использовать "поддельный" ресурс. Осталось определить где его "подделали"...

Terraform провайдер libvirt в Debian Buster

Давно собирался попробовать управлять виртуалками в libvirt через Terraform. Для этого существует провайдер multain/libvirt. Для начала создам виртуальную машину с двумя дисками.

terraform {
  required_providers {
    libvirt = {
      source = "multani/libvirt"
      version = "0.6.3-1+4"
    }
  }
}

provider "libvirt" {
  uri = "qemu:///system"
}

variable "prefix" {
  description = "Resource name prefix"
  type        = string
  default     = "terraform-"
}

resource "libvirt_volume" "boot" {
  name = "${var.prefix}boot"
  size = 20*1024*1024*1024
}

resource "libvirt_volume" "data" {
  name = "${var.prefix}data"
  size = 20*1024*1024*1024
}

resource "libvirt_domain" "default" {
  name = "${var.prefix}default"
  vcpu = 1
  memory = 2048

  disk {
    file = "/var/lib/libvirt/images/debian-10.9.0-amd64-netinst.iso"
  }

  disk {
    volume_id = libvirt_volume.boot.id
  }

  disk {
    volume_id = libvirt_volume.data.id
  }

  boot_device {
    dev = [ "hd", "cdrom"]
  }

  network_interface {
    bridge = "dmz0"
  }
}

ImageMagick: attempt to perform an operation not allowed by the security policy `PDF'

 При попытке конвертировать набор сканированных страниц в PDF получил такую ошибку

$ convert *.jpg -auto-orient output.pdf  
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.

Решение проблемы нашел на stackoverflow

. Мне хватило только закомментировать строку <policy domain="coder" rights="none" pattern="PDF" />

$ sudo etckeeper vcs diff /etc/ImageMagick-6/policy.xml
diff --git a/ImageMagick-6/policy.xml b/ImageMagick-6/policy.xml
index 82a3d0b..73b8384 100644
--- a/ImageMagick-6/policy.xml
+++ b/ImageMagick-6/policy.xml
@@ -91,6 +91,8 @@
   <policy domain="coder" rights="none" pattern="PS2" />
   <policy domain="coder" rights="none" pattern="PS3" />
   <policy domain="coder" rights="none" pattern="EPS" />
+  <!-- Fix for: attempt to perform an operation not allowed by the security policy `PDF'
   <policy domain="coder" rights="none" pattern="PDF" />
+  -->
   <policy domain="coder" rights="none" pattern="XPS" />
 </policymap>

После этого набор картинок преобразовался без ошибок.