Как стать автором
Обновить

Комментарии 32

Кстати, а многие делают: yum remove firewalld и yum install iptables? :)
firewalld я пробовал когда только семёрочка вышла, но из-за отсутствия в нём (по крайней мере на тот момент) админки для Forward — удалил и с тех пор не пользуюсь. Предпочитаю FirewallBuilder
О! прикольный GUI для iptables! Спасибо
Он, к слову, не только для iptables

Если конфигурация полностью статическая, то можно и iptables обойтись. Я на firewalld пересел, когда появилась необходимость накатывать новые правила не убивая то, что уже есть mangle и nat (например, правила от docker daemon'а). Ну и разобравшись с его интерфейсом всё становится несколько удобнее для автоматизации (с тем же ansible), хотя некоторые их решения (типа exit code 0 и 1 в качестве true и false) — несколько бесят.


Также firewalld полезен при наличии роуминга ноута по разным сетям, но это к топику не относится.

да, хороший аргумент. Не задумывался в таком ключе:) Спасибо за повод изучить это.
Он разве стоит по-умолчанию в CentOS? В RHEL он точно есть, а свежеустановленная CentOS 7.x удивила отсутствием команды firewall-cmd.
Да, его молча выпилили из 7.2, хотя в 7.1 он был.

Сначала был, потом выпилили. Видимо, по просьбам трудящихся. Но если ставиться с kickstart'а, то разницы никакой, достаточно указать firewall --enabled --ssh и firewalld приедет в комплекте.

Опечатка — systemctl start /var/log/journal/remote

Наверно надо: 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 куска — то по второму, естественно.

замещать unit полностью

И потерять изменения при следующем обновлении пакета.

Нет, если мейнтейнеры дистрибутива не идиоты (подсказка: не идиоты). Читать man 5 systemd.unit:


/etc/systemd/system Local configuration
/run/systemd/system Runtime units
/usr/lib/systemd/system Units of installed packages

Даже если совсем лень читать документацию, можно воспользоваться встроенной командой: systemctl edit systemd-journal-remote.service. Она сама разберётся, что куда записать, чтобы обновления не откатили изменения :)

Я делал такую связку с грейлогом и конвертером системдишного JSONa в грейлоговский (journal2gelf), без возни с недопиленными journal-remote и journal-gatewayd.

Вот из-за таких корявостей (как например /var/log/journal) многие и недолюбливают systemd.

Мне лично он очень нравится как замена init.d/upstart, но остальные компоненты честно говоря работают очень нестабильно. Хороший пример systemd-networkd, если сеть не поддерживает IPv6, и он как следствие отключен, то на серверах с DHCP интерфейсы могут быть в статусе «configuring» до 10 минут. И очень странные проблемы с systemd-resolved, когда два запроса подряд на один домен — один может вернуть нормальный ответ, а другой вернет пустой ответ.

А для логов, я все же предпочитаю использовать rsyslog или syslog-ng, которые из коробки поддерживают пересылку логов через TCP или UDP в syslog совместимом формате.

Systemd-networkd вроде как рассчитан только на простейшие конфигурации. Например, настроить сеть в контейнере или в VM.
Сам лично пользовался networkd на реальной машине, но иногда отваливалась сеть. Когда прочитал, что networkd как бы не для этого сделан, перешел на dhcpcd и с тех пор ни одного глюка не видел.

Не уверен откуда такая информация. На официальном сайте systemd-networkd описан как системная служба для настройки сети.

Заголовок спойлера
systemd-networkd is a system service that manages networks.


И при сборке из сорцов, если не указать --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 базы выглядит надежнее

Спасибо за упоминание, не знал что fluent умеет читать из journald. Есть ещё journalbeat. Несколько месяцев назад там был неприятный баг, дублирующий сообщения. Но сейчас всё хорошо работает.
> Может быть немного спорным бинарный формат хранения файлов, но этот выбор был объяснен авторами ещё при первых анонсах journald (безопасность и дешевизна хранения, интеграция с systemd, принудительный единый формат, переносимость).

а я думал что бинарный формат для быстрого поиска по индексам

Не уверен что для логов нужен веб-гуй, по мне лучше по ssh заходить и смотреть/грепать на месте
А как в этом journald обстоят дела с безопасностью?
Может ли например приложение «сыпать» в лог не от своего имени? Если да, то это большая уязвимость.

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

простите, а просто настроить rsyslog не достаточно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий