Net::Ping & root

[Hans R. Steiner]

Не могу никак разобраться чего-то я не понимаю...

но что точно понимаю - очень не хочется Apache от рута пускать...

модуль Net::Ping

пример кода:

$p = Net::Ping->new("icmp");
$p->bind($my_addr);
foreach $host (@host_array) {
  print "$host is ";
  print "NOT " unless $p->ping($host, 2);
  print "reachable.\n";
  sleep(1);
}
$p->close();

результат:

Software error:

icmp ping requires root privilege at /var/www/cgi-bin/cfradmin.pl line 41

For help, please send mail to the webmaster (root@194.6.218.106), giving this error message and the time and date of the error.

Вот :/

[Ineu]

Цитата:

perldoc Net::Ping If the "icmp" protocol is specified, the ping() method sends an icmp echo message to the remote host, which is what the UNIX ping program does. If the echoed message is received from the remote host and the echoed information is correct, the remote host is considered reachable. Specifying the "icmp" protocol requires that the program be run as root or that the program be setuid to root.

А непременно надо icmp? Может лучше другим методом попробовать?

[Hans R. Steiner]

Ну... меня, в принципе, вполне устраивает и самый простой вариант

$p = Net::Ping->new();
print "$host is alive.\n" if $p->ping($host);
$p->close();

но есть одно НО - не понимаю почему, но машины с FreeBSD, он не

видет, в то время как, на icmp они откликаются. echo (7/tcp/udp)

я открыл, но все равно их не видно да и открывать

дополнительные порты, как-то не хочется...

[Ineu]

Hans R. Steiner писал(а) Tue, 05 September 2006 12:02

Ну... меня, в принципе, вполне устраивает и самый простой вариант $p = Net::Ping->new(); print "$host is alive.\n" if $p->ping($host); $p->close(); но есть одно НО - не понимаю почему, но машины с FreeBSD, он не видет, в то время как, на icmp они откликаются. echo (7/tcp/udp) я открыл, но все равно их не видно да и открывать дополнительные порты, как-то не хочется...

Ну... тогда можно попробовать SYN, в nmap'е он хорошо работает. Хотя, согласно perldoc, при SYN-скане обрабатывается только ACK, а не RST, как в nmap... А при закрытом порте как раз RST и получаем

На худой конец можно периодически сканить сеть тем же нмапом и складывать результаты в доступный для апача файл...

[Hans R. Steiner]

Нда... ужас... в таком варианте, проще через system сделать...

там и nmap, и пинги/арпинги различные... :/

[Ineu]

Hans R. Steiner писал(а) Tue, 05 September 2006 13:08

Нда... ужас... в таком варианте, проще через system сделать... там и nmap, и пинги/арпинги различные... :/

Можно. Но и там кое-где нужны рутовские права. Через sudo, разве что

Тут еще один нюанс - как долго будет отрабатывать этот скрипт? Если надо проверить, живы ли 2-3 хоста, вариант скана по запросу подходит, а если надо просканить сеть */24? В то же время, пуская нмап каждую минуту, получаем статистику давностью в минуту. Если машины не вкл/выкл постоянно, то вариант вполне подходящий, имхо. Пользователь получает информацию мгновенно, актуальность ее достаточно высока.

[Hans R. Steiner]

Ну... в данном случае, речь идет не о подсети /24, а о списке

адресов, который в последствии, может быть много больше /24.

Сеть у меня сейчас /16. 8/

Загвоздка еще в том, что мне это нужно в реалтайме и не каждую

минуту, а только по запросу. К примеру, проверить, живы ли

сервера, жывы ли все сервисы, которые к ним привязаны, на сколько

загружен канал до них (касательно проверки загруженности канала,

способов, кроме icmp, не знаю)... проверить, жив ли абонент,

какие до него потери... По сути, я для себя (и для тех.поддержки

и для начальства) пишу вэб-интерфейс (красивый и удобный)... вот!

[Ineu]

Цитата:

касательно проверки загруженности канала, способов, кроме icmp, не знаю

ttcp

Цитата:

Загвоздка еще в том, что мне это нужно в реалтайме и не каждую минуту, а только по запросу.

Ну... пользователь может и не иметь представления о том, что что-то происходит каждую минуту

Что же до реалтайма, то он достижим _только_ при постоянной связи узлов, например, при пинге/скане ежесекундно

Возьмите, например, тот же STP. Это все-таки не реалтайм, хотя задержки там намного меньше минуты, вплоть до секунды, если не ошибаюсь (в линуховой реализации).

Цитата:

жывы ли все сервисы, которые к ним привязаны, на сколько загружен канал до них...

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

Цитата:

проверить, жив ли абонент, какие до него потери...

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

Насколько оправдан реалтайм и сильно ли буду отличаться результаты других методов?

[Hans R. Steiner]

Цитата:

ttcp

Спасибе, буду смотреть

Цитата:

Ну... пользователь может и не иметь представления о том, что что-то происходит каждую минуту Что же до реалтайма, то он достижим _только_ при постоянной связи узлов, например, при пинге/скане ежесекундно Возьмите, например, тот же STP. Это все-таки не реалтайм, хотя задержки там намного меньше минуты, вплоть до секунды, если не ошибаюсь (в линуховой реализации).

Верно, пользователь может... но это не рационально... если я,

образно говоря, раз в месяц захожу на этот интерфейс, но при

этом, я хочу увидеть реальную ситуацию то... весь месяц, раз

в минуту, выполнять какой-то скрипт? а если таких задачь

множество или хостов FFFF?

В принципе, есть вариант такой:

16:10:10 заходит USER1

16:10:15 USER1 просит дать ему информацию

16:10:15 выполняется скрипт

16:10:16 результат пишется в TEMP

16:10:16 USER1 получает информацию

16:10:30 заходит USER2

16:10:36 USER2 просит дать ему информацию

16:10:36 информация берется из TEMP

16:10:37 USER2 получает информацию

16:11:01 USER2 просит дать ему информацию

16:11:01 выполняется скрипт

16:11:02 результат пишется в TEMP

16:11:02 USER2 получает информацию

Вот... как мне кажется, такой вариант, наиболее правельный, если

требуется получить "системы быстрого реагирования", содержащую

всегда актуальную информацию, но допускающую какую-либо

погрешность во времени.

Другими словами, операция должна выполняться по запросу пользователя, в том случае, если информация в кэше устарела, но

если же она все еще является актуальной, пользователь получает

информацию из кэша. Такой подход позволяет повысить актуальность

информации, снизить нагрузки на сеть и оборудование и избежать

повторения запросов одного типа, в единицу времени.

Цитата:

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

Ну... я с этим не соглашусь... демон, висящий на машине - это

еще одна программная часть, которая может упасть и за которой

надо следить. Если в качестве поставщика информации, выступает

ОДИН обьект то, это еще один вариант получить не достоверную

информацию в результате его сбоя. Данный вариант приемлем, но

только в случае, когда он должен выполнять какие-либо локальные

проверки и только в связке с удаленными поставщиками информации

(ping, arping и т.д.)

Цитата:

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

Опять же не согласен... для проверки жив ли абонент, достаточно

пинга...

[Ineu]

Hans R. Steiner писал(а) Wed, 06 September 2006 10:37

Верно, пользователь может... но это не рационально... если я, образно говоря, раз в месяц захожу на этот интерфейс, но при этом, я хочу увидеть реальную ситуацию то... весь месяц, раз в минуту, выполнять какой-то скрипт? а если таких задачь множество или хостов FFFF?

В конечном итоге, получаем вечную проблему масштабирования Допустим, требуется взаимодействовать с каким-то внешним устройством, датчиком, к примеру. Другого варианта, кроме опроса, у нас нет (предположим, что аппаратных прерываний устройство не умеет). А если датчиков FFFF? Не по тому ли принципу работают select и poll, только на ядерном уровне?

Цитата:

Другими словами, операция должна выполняться по запросу пользователя, в том случае, если информация в кэше устарела, но если же она все еще является актуальной, пользователь получает информацию из кэша. Такой подход позволяет повысить актуальность информации, снизить нагрузки на сеть и оборудование и избежать повторения запросов одного типа, в единицу времени.

Способ хороший, не спорю. Но если хостов FFFF, юзеру1 придется ждать результата довольно долго...

Цитата:

Опять же не согласен... для проверки жив ли абонент, достаточно пинга...

Согласен. Если нужен только один параметр, то достаточно пинга.