ky0

Думаю, стоит сделать эти триггеры зависимыми от какого-то общего, типа "Устройство недавно было перезагружено" или "Устройство недоступно". Тогда в моменты ребутов триггеры линков активироваться не будут.

Даже в цодах бывает, что влан один на несколько клиентов, а вы от местного провайдера хотите высоких технологий...

Копать в сторону маршрутов до нужных ресурсов. Но вообще впн для такого не предназначен, на уровне HTTP работают прокси.

Зачем вам тут регулярные выражения, если можно просто погрепать по нужным названиям параметров и потом отчекрыжить лишнее каким-нибудь awk?

wifijammer, насколько я помню, умеет глушить на любом канале без перезапуска.

find у вас выдаёт список файлов. Очевидно, нужен какой-то цикл, в котором эти файлы будут участвовать по одному.

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

Баш наделён всеми необходимыми возможностями в сочетании с find. Конкретизируйте вопрос.

Частота проверок к выражению триггера отношения не имеет. Вам нужно настраивать именно последнее, указав что-нибудь типа nodata(86400)=1 или max(86400)<1 в зависимости от того, что отдаёт пинг в случае неудачи.

Наши EOL ASA 5500 как работали, так и продолжают.

Если имеется в виду Oracle Cloud - то по умолчанию правила фаерволла там настраиваются в двух местах, глобально в панели управления вашей виртуальной сетью, и непосредственно в iptables виртуалки.

Сколько раз уже были такие вопросы, и каждый раз одно и то же:

- Какую ОС выбрать?
- Ту, которую лучше знает ваш админ.
- Админ - это я.
- Нет, вы не админ и значит без разницы, что взгромождать.

1. Что-нибудь опенсорсное (но не российское, естессна).
2. Что-нибудь опенсорсное.
3. Ничего, потому что PKI - система, построенная на доверии удостоверяющим центрам, а в РФ, слава богу шифрования, их нет.

Можно погрепать ноль с символом конца строки.

Мониторинг должен быть комплексным. Вы сейчас только нашли виновника торжества - теперь настала пора лезть в потроха СУБД, отслеживать запросы, при необходимости профилировать или копать в сторону приложения, эти запросы генерирующие.

А может у вас просто СУБД фигово настроена, кто знает.

Поднимаете локальный HTTP-прокси и добавляете на него блэклист. Мимо прокси трафик наружу не выпускаете. То же самое можно сделать с помощью локального DNS-сервера, но значительно менее надёжно.

Нашли, на что переходить...

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