Summary: | ping plugin: ping_host_add failed: Operation not permitted | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Alexander Makeenkov <amakeenk> |
Component: | collectd-ping | Assignee: | Anton Farygin <rider> |
Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | asy, at, cas, crux, ender, lav, ldv, mike, qa_viy, rider, shaba, viy |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Alexander Makeenkov
2020-02-17 15:25:53 MSK
что показыват 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 ;) |