ky0

Так же, как любой другой таймер.

Сначала скажите, кто у вас автоматически их обновляет.

Я бы задачу разбил на два этапа - сначала собираете find`ом все пути к файлам, потом натравливаете на получившийся список архиватор. И зачем -regex, который наверняка даёт оверхед, если можно просто искать по маске?

Сервер физически один, никаких балансировщиков, облачных сервисов и т.п. нет.

Горизонтально масштабировать, добавить балансировщики, облачные сервисы и т. п.

Стандартный набор проверки:

1. Юзер, из-под которого запускается.
2. Используемый шелл, переменные окружения, абсолютные пути.
3. Каталог, в котором выполняется.

Профессиональное решение: любой стабильный почтовый сервер + человек, достаточно хорошо в нём разбирающийся. Начать даже стоит, пожалуй, со второго.

Во-первых, хорошо было бы решить, по какому интерфейсу будет ехать трафик к шлюзу. Затем - обдумать, не получится ли, что ответ на пакет через один интерфейс уедет через второй - во многих дистрибутивах подобное поведение по умолчанию не обрабатывается.

Спешные конфигурения перед выездом с объекта - к неработающей хрени и второй, более вдумчивой, итерации.

1. Выгрепываете из вывода dig`а айпишники, пишете их в файл (не обязательно, можно просто в массив сохранить).
2. В цикле для каждого айпишника резолвите PTR-запись, записывая поочерёдно сначала айпишник, потом имя в файл.

Не вижу, если честно, тут особой сложности.

Если это виртуалка/контейнер - посмотрите логи хоста на предмет oomkiller`а.

https://access.redhat.com/solutions/23016

Конфиг ротейта-то покажите. По описанию похоже, что файл не пересоздаётся, а переименовывается "на лету", при этом файловый дескриптор остаётся старым, поэтому сервис и продолжает писать в него.

То, что вы хотите, решается настройкой логирования. Если использовать systemd-таймеры, то эта функциональность идёт "из коробки".

Ноутбук, линукс, ошибки ACPI при установке - ммм, классика... Что могло пойти не так?

В Гитлабе есть секреты, куда, помимо прочего, можно положить и SSH-ключи.

Но вообще, раз у вас на хостах уже запущены раннеры - значит, доступ уже есть и достаточно добавить пользователю gitlab-runner нужные права, например, через sudo.

Ну, так напишите простецкий скрипт, который бы складывал в какой-нибудь файл состояние и периодически сравнивал его содержимое с результатами пинга. Условно, если в файле 0, а пинг идёт - сообщать. Если в файле 1, а пинг не идёт - тоже.

Если у вас всё это в рамках единой инфраструктуры - то непонятно, зачем столько DNS-серверов. Современные роутеры вполне умеют либо форвардить запросы, либо и вовсе становиться slave-серверами. А раз источник один - не будет и никаких проблем вида "тут резолвится, тут не резолвится".

Не делайте ничего сложнее селектов через верморду, а лучше выкиньте её вообще.

pg_dump -U postgres -Fc merch_telegram_bot_db > test.backup
createdb -U postgres -E UNICODE merch_telegram_bot_db
pg_restore -U postgres -j 2 -d merch_telegram_bot_db test.backup