MySQL: возможность подключения к localhost, но не к 127.0.0.1

Сегодня на Debian 9 столкнулся с проблемой что я не могу подключиться к 127.0.0.1, используя MySQL (MariaDB), хотя подключение через localhost работает.
Сначала я создал пользователя 'root'@'127.0.0.1':

mysql > CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY '<redacted>';
mysql > GRANT ALL PRIVILEGES ON *.* TO 'root'@'127.0.0.1' WITH GRANT OPTION;

Хэши паролей идентичны:

MariaDB [(none)]> select user,host,password from mysql.user;
+-----------+-----------+-------------------------------------------+
| user      | host      | password                                  |
+-----------+-----------+-------------------------------------------+
| root      | localhost | *B68A25C6C6C902646A985996A0716AD431CFA799 |
| root      | 127.0.0.1 | *B68A25C6C6C902646A985996A0716AD431CFA799 |
+-----------+-----------+-------------------------------------------+
2 rows in set (0.00 sec)
Продолжить чтение →

MacOS: sudo по отпечатку пальца

Тем кто часто работает с командной строкой, как и я, приходится каждый раз вбивать пароль при работе через sudo, что не так удобно, как отпечаток пальца, к которому нас приучили Apple с новыми версиями Mac Book :) Чтобы включить ввод пароля по отпечатку, нужно добавить в файл /etc/pam.d/sudo первой строкой: 
# sudo: auth account password session
auth       sufficient     pam_tid.so
Продолжить чтение →

How to scale kubernetes daemonset to 0?

В случае когда не хочется удалять daemonset, есть один интересный воркэраунд с использованием временного nodeSelector с несуществующим label, например: 
kubectl -n <namespace> patch daemonset <name-of-daemon-set> -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
После этой команды daemonset будет заскейлен в 0. Если нужно восстановить daemonset, то нам просто нужно удалить nodeSelector: 
kubectl -n <namespace> patch daemonset <name-of-daemon-set> --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
В стандартном варианте можно сделать бэкап daemonset и удалить его, а когда потребуется - восстановить: 
kubectl get daemonset <name-of-daemon-set> -n <namespace> -o yaml

Asterisk: определение региона по номеру телефона с использованием PHP и БД

Для реализации решения мы используем данные выписки из реестра российской системы и плана нумерации: https://rossvyaz.gov.ru/deyatelnost/resurs-numeracii/vypiska-iz-reestra-sistemy-i-plana-numeracii, PHP скрипт, который обрабатывает данные и заносит в БД. Скачиваем базу кодов: 
wget -N https://rossvyaz.gov.ru/data/DEF-9xx.html
wget -N https://rossvyaz.gov.ru/data/ABC-8xx.html
wget -N https://rossvyaz.gov.ru/data/ABC-4xx.html
wget -N https://rossvyaz.gov.ru/data/ABC-3xx.html
Создаем пользователя и базу данных: 
CREATE USER 'asterisk_reg_number'@'localhost' IDENTIFIED BY 'XXXXXXXX';
CREATE DATABASE IF NOT EXISTS `asterisk_reg_number_db` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
GRANT ALL PRIVILEGES ON `asterisk_reg_number_db`.* TO 'asterisk_reg_number'@'localhost';
Подключаемся к базе под созданным пользователем и создаем таблицу num: 
mysql -uasterisk_reg_number -p'XXXXXXXX' asterisk_reg_number_db

CREATE TABLE `num` (
`def` smallint(6) NOT NULL,
`start` int(11) NOT NULL,
`finish` int(11) NOT NULL,
`count` int(11) NOT NULL,
`operator` varchar(64) NOT NULL DEFAULT '',
`region` varchar(128) NOT NULL DEFAULT '',
`region_last` varchar(64) DEFAULT NULL,
`region_first` varchar(64) DEFAULT NULL,
KEY `a_b` (`def`,`start`),
KEY `a` (`def`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Перед подключением убедитесь что у вас в конфигурации my.cnf выставлен параметр log_bin_trust_function_creators = 1 иначе вы получите ошибку. Данный параметр можно выставить налету, но не забудьте прописать его в конфигурации my.cnf. Подключаемся под суперпользователем и создаем хранилку: Продолжить чтение →

Kubelet: Observed a panic: “invalid memory address or nil pointer dereference”

При добавлении CPU на ноду, kubelet не запускается, в логах видим ошибку, если выбрать последние записи: 
journalctl -u kubelet -n 1000

Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference
Проблема в том что скорее всего kubelet запущен с опцией --cpu-manager-policy=static, который фиксирует конфигурацию по CPU в файле /var/lib/kubelet/cpu_manager_state: 
cat /var/lib/kubelet/cpu_manager_state
{"policyName":"static","defaultCpuSet":"0-9","checksum":688938613}
Конфиг kubelet: 
/etc/systemd/system/kubelet.service
Продолжить чтение →

Антуан де Сент-Экзюпери «Маленький принц»

Люди забираются в скорые поезда, но они сами не понимают, чего они ищут, поэтому они не знают покоя, бросаются то в одну сторону, а то в другую… И все напрасно… Глаза слепы. Искать надо сердцем.

Отладка при неудачном деплое в Kubernetes c Helm Hook в GitLab CI

Используемое ПО: Gitlab CI, Helm, Docker, Kubernetes Цель: в случае неудачного деплоя, получить информацию о проблеме в CI, а не ходить в k8s или Kibana руками и не смотреть логи подов Вводная: для деплоя в кластер Kubernetes используется Helm версии 3 и Gitlab CI, отдельный сервер для сборки (не DinD), с которого доступен Kubernetes API. Данный вариант основан на ключе Helm --atomic, который осуществляет автоматический откат неудавшегося релиза. Идея в том, чтобы не запускать отдельно helm rollback, а использовать Hook с аннотацией pre-delete, которая перед удалением релиза запустит под и соберет логи с NOT READY подов, а далее с помощью after_script выведет данные логи в CI. К реализации... Продолжить чтение →

Тюнинг Direct I/O в OpenVZ контейнерах

По умолчанию запись во все файлы, открытые без флага O_DIRECT, осуществляется через write-back cache. Это не только уменьшает latency (время ожидания) записи данных на диск для приложения (системный вызов write() завершится, как только данные будут скопированы в write-back cache, не дожидаясь реальной записи на диск), но и позволяет планировщику I/O ядра эффективнее распределять ресурсы диска между процессами, группируя I/O запросы от приложений. При этом некоторые категории приложений, например, базы данных, сами эффективно управляют записью своих данных, выполняя большие последовательные I/O запросы. Поэтому зачастую такие приложения открывают файлы с флагом O_DIRECT, который указывает ядру писать данные в такой файл, минуя write-back cache, напрямую из памяти пользовательского приложения. В случае работы одной базы данных на хосте такой подход оказывается эффективнее, чем запись через кэш, поскольку I/O запросы от базы данных уже выстроены оптимальным образом и нет необходимости в дополнительном копировании памяти из пользовательского приложения в write-back cache. В случае работы нескольких контейнеров с базами данных на одном хосте данное предположение оказывается неверным, так как планировщик I/O в ядре Linux не может оптимально распределять ресурсы диска между приложениями, использующими Direct I/O. Поэтому по умолчанию в ядре OpenVZ Direct I/O для контейнеров выключено, и все данные пишутся через write-back cache. Это вносит небольшие накладные расходы в виде дополнительного копирования памяти из пользовательского приложения в write-back cache, при этом позволяя планировщику I/O ядра эффективнее распределять ресурсы диска. Продолжить чтение →