ky0

Пробовал добавлять пользователя в www-data группу и назначать группу www-data как первичную.

Так вы группе права-то тоже выдайте, как владельцу - и всё взлетит.

З.Ы. - я бы, наверное, для простоты наоборот бы сделал - ftp:www-data, вот так.

Сортируете в другую таблицу, первую удаляете, переименовываете. Но так делать не надо.

Если только для целей мониторинга - ставьте в каждом сегменте прокси (если, конечно, ваша система такое умеет).

А почему бы не конвертировать перед отправкой в какой-нибудь более подходящий формат?

Если уже мониторится доступность устройства - что мешает к тому же мониторингу прикрутить и ICMP-пинги? Сможете сохранять историю, строить графики и экспортировать данные в любой формате.

Есть общепринятый набор мер, существенно уменьшающих вероятность попадания писем в спам - обратная зона у IP почтового сервера, SPF/DKIM-записи, правильным образом настроенный релей.

Разумеется, внутренности сообщения тоже проверяются, но имхо, если все общие рекомендации выполнены и письмо - не откровенный спам, проблемы бывают достаточно редко.

Ссылки на ваш домен или на какой-то левый? Возможно именно домен, на который вы ссылаетесь считается у гугла подозрительным.

Зачем городить велосипед? На share.zabbix.com и просторах интернета есть несколько неплохих шаблонов - отчекрыжьте не нужное вам и всё.

man nice

Гуглите "континиоус деплоймент".

Сильно зависит от вида шифрования. CBC довольно серьёзно грузит процессор.

Если недостаточно ящиков бесплатного гугла - значит, организация достигла такого размера, при котором может позволить себе 5 долларов за аккаунт. Если нет - стоит пересмотреть стратегию развития.

Вариантов много, но по соотношению цена/качество оптимален гугл, остальное либо более энтерпрайзно (напр. Office 365), либо менее надёжно и влечёт за собой пляски с бубном или другие проблемы (Яндекс, мэйл.ру, локальный почтовик/эксчейндж).

Делаете локейшен/surfing с обработкой фреймворком и / - с какой-нибудь 403 ошибкой или редиректом.

1) Решается настройкой маршрутизации
2) Softether с RADIUS-авторизацией через LDAP-бэкенд

Для минорных версий можно подсунуть. Для мажорных:
https://www.postgresql.org/docs/10/static/pgupgrad...

Потому что ссылки на HTTP-ресурсы страницы, отдаваемой по HTTPS - это ошибка. Переделайте всё единообразно и проблем не будет. Либо отключите в браузере блокировку mixed content.

Пока не поздно, постарайтесь уговорить руководство на аутсорс. Самому в это вникать - прямая дорога в ад.