Версия пакета: collectd-ping-5.10.0-alt1 Система: ALT Workstation x86_64 Не работает плагин ping. При запуске collectd в логах появляются такие ошибки (collectd при этом запускается успешно): collectd[2553]: plugin_load: plugin "ping" successfully loaded. collectd[2553]: ping plugin: ping_host_add (www.google.com) failed: Operation not permitted collectd[2553]: ping plugin: No host could be added to ping object. Giving up. Шаги воспроизведения: 1. Установить collectd collectd-ping 2. В файле /etc/collectd.conf раскомментировать следующие строки (изменить параметры Host, SourceAddress, Device на нужные значения): LoadPlugin ping <Plugin ping> Host "www.google.com" Interval 1.0 Timeout 0.9 TTL 255 SourceAddress "8.8.8.8" AddressFamily "any" Device "eth0" MaxMissed -1 </Plugin> 3. Запустить collectd (предварительно необходимо удалить строку LoadPlugin rrdtool, либо установить пакет collectd-rrdtool, см. баг https://bugzilla.altlinux.org/36950): # systemctl start collectd # systemctl status collectd
что показыват control ping ?
(Ответ для Alexey Shabalin на комментарий #1) > что показыват > control ping ? # control ping public
Это фича, нужно выдать collectd CAPABILITY для ping. Читайте документацию, там всё есть.
выдаётся через unit systemd для collectd
Вообще хорошо бы вместо такого костыля сделать штатный механизм по управлению capabilities (возможно, на базе или навроде control).
(In reply to Anton Farygin from comment #3) > Это фича, нужно выдать collectd CAPABILITY для ping. Вы точно ничего не путаете? Странно, что ping'у не нужна, а collectd'у нужна.
Желающие могут поправить это поведение в liboping: The I<oping> library opens a raw socket to be able to send ICMP packets. On most systems normal users are not allowed to do this. This is why on most systems the L<ping(1)> utility is installed as SetUID-root. Since, when using this module, no external process is spawned B<this> process needs the appropriate permissions. This means that either your script has to run as superuser or, under Linux, needs the C<CAP_NET_RAW> capability. Но ping же у нас SGID'ный, так что не совсем честно говорить о том, что ему не нужны CAPABILITY. Нужны, просто они у него есть в момент запуска. Вот если сделать так: chmod 0711 /usr/libexec/ping/ping то и у нас ping работать не будет под обычным пользователем. в случае с collectd capability сбрасываются на стороне systemd, в самом collectd нет никакой поддержки управление capabilities, кроме проверок их наличия.
(Ответ для Michael Shigorin на комментарий #5) > Вообще хорошо бы вместо такого костыля сделать штатный механизм по > управлению capabilities (возможно, на базе или навроде control). Штатный механизм - это юниты systemd. Администратор, использующий collectd, должен понимать как его настраивать. Можно положить нужный юнит в пакет но я бы не хотел этого делать.
(Ответ для Anton Farygin на комментарий #8) > (Ответ для Michael Shigorin на комментарий #5) > > Вообще хорошо бы вместо такого костыля сделать штатный механизм по > > управлению capabilities (возможно, на базе или навроде control). > > Штатный механизм - это юниты systemd. > > Администратор, использующий collectd, должен понимать как его настраивать. > Можно положить нужный юнит в пакет но я бы не хотел этого делать. Можно положить в пакет collectd-ping дополнительный конфиг для юнита а /(lib|etc)/systemd/system/collectd.service.d/ping.conf с добавлением только одного нужного параметра. И все будет работать из коробки.
(In reply to Anton Farygin from comment #7) > Желающие могут поправить это поведение в liboping: > The I<oping> library opens a raw socket to be able to send ICMP packets. On > most systems normal users are not allowed to do this. This is why on most > systems the L<ping(1)> utility is installed as SetUID-root. Since, when using > this module, no external process is spawned B<this> process needs the > appropriate permissions. This means that either your script has to run as > superuser or, under Linux, needs the C<CAP_NET_RAW> capability. > > Но ping же у нас SGID'ный, так что не совсем честно говорить о том, что ему > не нужны CAPABILITY. Нужны, просто они у него есть в момент запуска. ping'у не нужны CAPABILITY, потому что ping использует другой механизм в ядре (ping socket). Судя по процитированному, collectd-ping написан давно и не умеет использовать этот механизм. Это объясняет разницу. В таком случае остаётся только сделать так, как предлагает Алексей.
Я не хочу делать из коробки так, как процитировал Алексей. Считаю такое поведение из пакета не правильным. Системный администратор сам должен принять решение о том, что бы настроить нужные capability, а не поставить готовое поведение из пакета. По мне так лучше пусть этот плагин заработает после донастройки, чем всему collectd молча дадут какие-то дополнительные привилегии.
(Ответ для Anton Farygin на комментарий #8) > (Ответ для Michael Shigorin на комментарий #5) > > Вообще хорошо бы вместо такого костыля сделать штатный механизм по > > управлению capabilities (возможно, на базе или навроде control). > Штатный механизм - это юниты systemd. Это механизм, зависящей от реализации pid 1, которая умеет SEGV'иться. Соответственно штатным в production он у нас не является (спроси ldv@).
А без systemd у collectd нет проблем с ping ;)
