Комментарии 32
Если конфигурация полностью статическая, то можно и iptables обойтись. Я на firewalld пересел, когда появилась необходимость накатывать новые правила не убивая то, что уже есть mangle
и nat
(например, правила от docker daemon'а). Ну и разобравшись с его интерфейсом всё становится несколько удобнее для автоматизации (с тем же ansible), хотя некоторые их решения (типа exit code 0 и 1 в качестве true и false) — несколько бесят.
Также firewalld полезен при наличии роуминга ноута по разным сетям, но это к топику не относится.
##edit ОГО в 7.2 выпилили!
Сначала был, потом выпилили. Видимо, по просьбам трудящихся. Но если ставиться с kickstart'а, то разницы никакой, достаточно указать firewall --enabled --ssh
и firewalld
приедет в комплекте.
Наверно надо: systemctl start systemd-journal-gatewayd
Поскольку мы собираем демо-стенд, давайте переключим протокол приёма файлов с https на http. Для этого необходимо отредатировать стартовый сервис-файл /lib/systemd/system/systemd-journal-remote.service, заменив опцию listen-https на listen-http. Также будет полезно поправить /lib/systemd/system/systemd-journal-remote.socket, указав только интересующий нас адрес для биндинга демона.
Не надо там редактировать, надо читать документацию. И делать override в /etc/systemd/system/systemd-journal-remote.service
или `/etc/systemd/system/systemd-journal-remote.service.d/*.conf
Если замещать unit полностью — то по первому, если override куска — то по второму, естественно.
Даже если совсем лень читать документацию, можно воспользоваться встроенной командой: systemctl edit systemd-journal-remote.service. Она сама разберётся, что куда записать, чтобы обновления не откатили изменения :)
Я делал такую связку с грейлогом и конвертером системдишного JSONa в грейлоговский (journal2gelf), без возни с недопиленными journal-remote и journal-gatewayd.
Мне лично он очень нравится как замена init.d/upstart, но остальные компоненты честно говоря работают очень нестабильно. Хороший пример systemd-networkd, если сеть не поддерживает IPv6, и он как следствие отключен, то на серверах с DHCP интерфейсы могут быть в статусе «configuring» до 10 минут. И очень странные проблемы с systemd-resolved, когда два запроса подряд на один домен — один может вернуть нормальный ответ, а другой вернет пустой ответ.
А для логов, я все же предпочитаю использовать rsyslog или syslog-ng, которые из коробки поддерживают пересылку логов через TCP или UDP в syslog совместимом формате.
Systemd-networkd вроде как рассчитан только на простейшие конфигурации. Например, настроить сеть в контейнере или в VM.
Сам лично пользовался networkd на реальной машине, но иногда отваливалась сеть. Когда прочитал, что networkd как бы не для этого сделан, перешел на dhcpcd и с тех пор ни одного глюка не видел.
И при сборке из сорцов, если не указать --without-networkd, он собирается по умолчанию, что как бы намекает что авторами эта служба предполагается как основная.
1. Установить graylog
2. Выполнить команду (замените адрес и порт грейлога на свои):
echo '*.* @192.168.5.5:5140;RSYSLOG_SyslogProtocol23Format' >> /etc/rsyslog.conf && service rsyslog restart
Значительно информативней высылать с хоста сразу GELF.
Вам придется поставить питоновский модуль graypy и собственно сам скрипт journal2gelf.
А в первом случае ничего не нужно, сработает на чистой minimal установке всех ОС в journald.
У меня journal2gelf ломался на какой-то строчке лога… Не очень стабильная штука (((( fluent-bit с чтением напрямую из journald базы выглядит надежнее
а я думал что бинарный формат для быстрого поиска по индексам
Не уверен что для логов нужен веб-гуй, по мне лучше по ssh заходить и смотреть/грепать на месте
Может ли например приложение «сыпать» в лог не от своего имени? Если да, то это большая уязвимость.
Удаленное логирование в journald или Всё ещё «это вам не нужно»?