Метка: ops

Дано: ansible запускается с виртуалки VirtualBox, файлы при этом лежат на windows хосте и примонтированы в виртуалку. При попытке запуска ansible-playbook получаем:

[WARNING]: Ansible is in a world writable directory (/media/D_DRIVE/work/ansible), ignoring it as an ansible.cfg source.

Обсуждение проблемы и workaround есть тут: https://github.com/ansible/ansible/issues/42388

Надо добавить путь к конфигу в переменные окружения. Я в виртуалке работаю один, ansible у меня там тоже один — поэтому добавил ее сразу в /etc/environment:

Идем в /etc/environment и дописываем туда путь к конфигу:

ANSIBLE_CONFIG=» /media/D_DRIVE/work/ansible/ansible.cfg»

Применяем оттуда переменные до перезагрузки:

for env in $( cat /etc/environment ); do export $(echo $env | sed -e ‘s/»//g’); done

Готово, ansible продолжает ругаться, но при этом работает

Столкнулся с тем, что встряла входящая почта. Приходить приходит, но вся застревает в maildrop. В postqueue -p — тысячи писем. Беглый анализ логов показал, что предположительный виновник opendkim:

Oct 15 09:55:01 postnew opendkim[31282]: 221D962914: key retrieval failed (s=20161025, d=youtube.com): ‘20161025._domainkey.youtube.com’ query timed out

А вот дальше начались долгие и тяжелые поиски причины, собственно завязка такая — opendkim выдает query timed out

~# opendkim-testkey -d youtube.com -s 20161025 -v -v -v
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key ‘20161025._domainkey.youtube.com’
opendkim-testkey: ‘20161025._domainkey.youtube.com’ query timed out

а dig — нет )

# dig 20161025._domainkey.youtube.com TXT

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 20161025._domainkey.youtube.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44900
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;20161025._domainkey.youtube.com. IN TXT

;; ANSWER SECTION:
20161025._domainkey.youtube.com. 3599 IN TXT «k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0UfgFQF/Ms63E9cKpj+WdM5RepAYbfAT+h4iAzOb93Q7eVjNd0WabrALPs3qcUEKkrhpI1nlZtOofutG8l4VgslGn7+9ggc489LWyU+u674c3eRoErGOFRq0xV8xnG+Rf» «WKF+im0t4n/QGA2ZcdOIcIfevxyPHudcJipW0G8C6vMtBmQulAfN/SgE1/cugl6VBedZIYuynEF2ttqO9vDLy90/BctMBRJGyyj/CJR7gdLl655Y2+73BFvjhCIWroDrGa2io005Hh1nkReAY9Q2BPQ2K6O7TlIq3SGFVRuPIp0cszwwIjPTy3BP92X2NfiM4CZSPr9R02UfNyPYLQv4wIDAQAB»

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 15 11:01:48 GMT 2018
;; MSG SIZE rcvd: 475

Гугл говорит — ну так это дело ясное, opendkim ломится не на тот сервер — надо явно прописать Nameservers, прописываем:

Nameservers 8.8.8.8

Ноль эффекта. Пробуем 1.1.1.1 — так же ноль эффекта.

Подключаем тяжелую артиллерию:

tcpdump -i eth1 udp port 53 -n

Вау — запросы есть, и ответы приходят

11:05:45.772081 IP 144.76.68.186.30286 > 216.239.34.10.53: 37169% [1au] TXT? 20161025._domainkey.youtube.com. (60)
11:05:45.795999 IP 216.239.34.10.53 > 144.76.68.186.30286: 37169*- 1/0/0 TXT «k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0UfgFQF/Ms63E9cKpj+WdM5RepAYbfAT+h4iAzOb93Q7eVjNd0WabrALPs3qcUEKkrhpI1nlZtOofutG8l4VgslGn7+9ggc489LWyU+u674c3eRoErGOFRq0xV8xnG+Rf» «WKF+im0t4n/QGA2ZcdOIcIfevxyPHudcJipW0G8C6vMtBmQulAfN/SgE1/cugl6VBedZIYuynEF2ttqO9vDLy90/BctMBRJGyyj/CJR7gdLl655Y2+73BFvjhCIWroDrGa2io005Hh1nkReAY9Q2BPQ2K6O7TlIq3SGFVRuPIp0cszwwIjPTy3BP92X2NfiM4CZSPr9R02UfNyPYLQv4wIDAQAB» (464)
11:05:45.796262 IP 144.76.68.186.23689 > 192.112.36.4.53: 62833% [1au] DNSKEY? . (28)
11:05:45.821559 IP 192.112.36.4.53 > 144.76.68.186.23689: 62833*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)
11:05:45.821755 IP 144.76.68.186.63995 > 199.7.91.13.53: 33914% [1au] DNSKEY? . (28)
11:05:45.833611 IP 199.7.91.13.53 > 144.76.68.186.63995: 33914*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)
11:05:45.833814 IP 144.76.68.186.42019 > 202.12.27.33.53: 53753% [1au] DNSKEY? . (28)
11:05:45.848947 IP 202.12.27.33.53 > 144.76.68.186.42019: 53753*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)
11:05:45.849195 IP 144.76.68.186.9289 > 198.41.0.4.53: 19115% [1au] DNSKEY? . (28)
11:05:45.855702 IP 198.41.0.4.53 > 144.76.68.186.9289: 19115*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)
11:05:45.856003 IP 144.76.68.186.33889 > 193.0.14.129.53: 31594% [1au] DNSKEY? . (28)
11:05:45.861259 IP 193.0.14.129.53 > 144.76.68.186.33889: 31594*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)
11:05:45.861547 IP 144.76.68.186.36263 > 199.9.14.201.53: 50292% [1au] DNSKEY? . (28)
11:05:46.017319 IP 199.9.14.201.53 > 144.76.68.186.36263: 50292*- 4/0/1 DNSKEY, DNSKEY, DNSKEY, RRSIG (1139)

но opendkim упорно отвечает query timed out.
Единственное, что что за пачка DNSKEY в запросе?? Вспоминаем, что пару дней назад Эшер в телеграме писал про смену ключей DNSSEC https://t.me/usher2/444

Начинаем гуглить в эту сторону — ценнейшая статья от редхэта:
https://www.redhat.com/en/blog/what-you-need-know-about-first-ever-dnssec-root-key-rollover-october-11-2018

Ок, проверяем dnsmasq — нового ключа нет (но если виноват он — почему не работало при указании явно внешнего сервера в Nameservers). Обновляем — ключ приходит, эффекта нет.

Ищем, какой ключ таки использует opendkim, после некоторых поисков обнаруживаем, что этот:

# cat /usr/share/dns/root.key
. 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1404118431 ;;Mon Jun 30 10:53:51 2014

Система обновлялась давно, нового ключа в списке нет.

Выясняем кто поставляет файл, и обновляем:

# dpkg -S /usr/share/dns/root.key
dns-root-data: /usr/share/dns/root.key

# apt-get install dns-root-data

И все тут же начинает работать:

# opendkim-testkey -d youtube.com -s 20161025 -v -v -v
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key ‘20161025._domainkey.youtube.com’
opendkim-testkey: key not secure
opendkim-testkey: key OK

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

До этого эти метрики смотрели в XenCenter — но это неудобно, т.к. сложно соотносить с бизнес-метриками из заббикса (с средним временем обработки запросов к примеру).

Метрики доступны начиная с XenServer 6.1:
https://support.citrix.com/article/CTX135033

Для их использования существует тулза rrd2csv — но для целей передачи значения из неё в заббикс она обладает рядом недостатков:

1. работает пока не прервут, выдавая метрики раз в заданное число секунд (по-умолчанию 5)
2. выплевывает результат в формате csv
3. работает только под root

Проблема 1 решается с помощью timeout.

Проблема 2 решается благодаря тому, что утилите можно передать в особом формате какие именно метрики хочется получить.
В итоге получается нечто такое:

# (timeout 1s rrd2csv AVERAGE:host::cpu_avg || true) | cut -f2 -d» » | tail -n 1

возвращает текущую среднюю загрузку процессора.

Для решения проблемы 3 — поставил получение этой метрики в крон с сохранением значения в файл:

 * * * * * (timeout 1s /opt/xensource/bin/rrd2csv AVERAGE:host::cpu_avg || true) | cut -f2 -d» » | tail -n 1 > /tmp/xencpu

а UserParameter в zabbix читает уж из него:

 UserParameter=xen.cpu,cat /tmp/xencpu