проверка конфигурации оборудования на ftp &

[doncelab]

Здравствуйте. Имеется шаблон привязываемый к оборудования Cisco для сбора основных параметров. Маршрутизаторы сами копируют конфигурацию каждый день на FTP сервер под proftpd. Как можно осуществить проверку существования файла и его дату созданию?
Я так понял что нужно поставить Zabbix агента на сервер, создать другой шаблон, но как связать их ведь у меня много оборудования и брать их наименования которое равно конфигурации на сервере FTP?

[Azag]

Наверно легче написать отдельный скрипт

[tuban]

+1
Ежели это Cisco, можно копировать конфиги через snmp RW.

[doncelab]

Создал элемент данных внешняя проверка с ключом cisco_file_exists.pl[{shortName}.cfg] в котором используется ключ shortName, но эта конструкция не заработала. Или может нельзя использовать ключ в других элементах данных?

[sadman]

Нельзя. Только макросы.

[doncelab]

Все получилось. Сделал элемент данных внешняя проверка с ключом cisco_file_created_date.pl[conf, {HOST.NAME}.cfg]

#!/usr/bin/perl -w

$num_args = $#ARGV + 1;
if ($num_args != 2) {
    print "\nUsage: cisco_file_exists.pl directory filename\n";
    exit;
}

use warnings;
use strict;
use File::stat;

my $filename = "/var/ftp/cisco/$ARGV[0]/$ARGV[1]";

if(-e $filename){
   my $info = stat($filename);
   print $info->mtime;
}else{
}

[sadman]

Оверхед большой на компиляции перловки при такой простой операции. Тем более с подгрузкой модуля и прагмами strict/warning.

Можно вот так изобразить cisco_file_created_date.sh:

stat -c %Y "/var/ftp/cisco/$1/$2" || echo -1

Если файла нет, то получите -1, противном случае - timestamp последней модификации.

[yukra]

Оверхед большой на компиляции перловки при такой простой операции. Тем более с подгрузкой модуля и прагмами strict/warning.

Можно вот так изобразить cisco_file_created_date.sh:

stat -c %y "/var/ftp/cisco/$1/$2" || echo -1

Если файла нет, то получите -1, противном случае - timestamp последней модификации.

Лучше написать на перле\питоне\любом-другом-языке 100 строк и быть уверенным что они работают правильно, чем 5 на баше и не быть ни в чем не уверенным.

[sadman]

Лучше написать на перле\питоне\любом-другом-языке 100 строк и быть уверенным что они работают правильно, чем 5 на баше и не быть ни в чем не уверенным.

Во-первых - это не обязательно баш, во-вторых - что тут криминального? stat вызывается тот же, что и перловке.

А на перловке я писал - между 5.05 и 5.20 вполне себе можно нахватать obsolete operator warnings. Судя же по втыканию прагм в середину кода - лучше уж строка на sh, чем на таком перле.

[yukra]

Во-первых - это не обязательно баш, во-вторых - что тут криминального? Stat вызывается тот же, что и перловке.

Не тот же, а тот, который окажется у вас в path. А какой там окажется, и окажется ли - вопрос к администратору сервера.

Про прагмы в середине и остальное стиль - согласен, но я все таки за абстрактный скрипт на перле, вместо абстрактного скрипта на баше\шелле.

[sadman]

Не тот же, а тот, который окажется у вас в path. А какой там окажется, и окажется ли - вопрос к администратору сервера.
Про прагмы в середине и остальное стиль - согласен, но я все таки за абстрактный скрипт на перле, вместо абстрактного скрипта на баше\шелле.

Я так понимаю, что вопрос встал о пристрастиях, потому что не могу себе представить ситуацию, в которой на абстрактной системе стоял бы абстрактный перл со знаком качества и гарантирующий что-то кроме того, что он запустится, к тому же работающий лучше, чем шелльная утилита stat, входящая в GNU CoreUtils (не знаю, уж кому понадобится делать вариации).

В конце концов путь к stat можно и прямо прописать, если уж поставить целью сделать всё правильно. Или накидать десяток строк на цэ, чтобы уж точно быть уверенным, что делается нужный системный вызов, а не полагаться на обертку вокруг обертки, как в случае с File::stat .

Но, полагаю, что вы согласитесь, что static compiled executable будет всегда работать быстрее и менее ресурсоемко, нежели нечто, что предварительно компилируется на каждом запуске, стриктится и пр. и др.

Впрочем, разработчиков Zabbix shell не пугает и внешние скрипты они отфоркивают с помощью sh, а sysexec.

[yukra]

Я так понимаю, что вопрос встал о пристрастиях, потому что не могу себе представить ситуацию, в которой на абстрактной системе стоял бы абстрактный перл со знаком качества и гарантирующий что-то кроме того, что он запустится, к тому же работающий лучше, чем шелльная утилита stat, входящая в GNU CoreUtils (не знаю, уж кому понадобится делать вариации).

В конце концов путь к stat можно и прямо прописать, если уж поставить целью сделать всё правильно. Или накидать десяток строк на цэ, чтобы уж точно быть уверенным, что делается нужный системный вызов, а не полагаться на обертку вокруг обертки, как в случае с File::stat .

Но, полагаю, что вы согласитесь, что static compiled executable будет всегда работать быстрее и менее ресурсоемко, нежели нечто, что предварительно компилируется на каждом запуске, стриктится и пр. и др.

Мы же вроде не о perl vs stat, а о .pl vs .sh. В первом случая я за stat, во втором за .pl

Проблема .sh:

yukra@yukra-ThinkPad-X230 ~ $ cat 1.sh 
#!/usr/bin/env sh

asdfasgfgasd
echo ok
yukra@yukra-ThinkPad-X230 ~ $ ./1.sh 
./1.sh: 3: ./1.sh: asdfasgfgasd: not found
ok
yukra@yukra-ThinkPad-X230 ~ $ echo $?
0
yukra@yukra-ThinkPad-X230 ~ $

Это все конечно можно обложить проверками, но в итоге код получится еще менее красивым и сложноподдерживаемым чем на перле. На перле если мы забыли сказать "use Sub::module", забили поставить Sub::module на сервер, или еще что-то случилось (удалилась зависимость, недоработала система управления конфигурациями, кто-то ручками переложил модуль в более правильную, по его мнению директорию и тп) у нас "все умрет и все", а в случае .sh подобная ошибка может жить достаточно долго, пока кто-нить не найдет результаты неработоспособности и не разберется "почему такое безобразие творится".

Впрочем, разработчиков Zabbix shell не пугает и внешние скрипты они отфоркивают с помощью sh, а sysexec.

Сами же понимаете что это не лучшее решение, которое стоит перенимать.


Ps ну и раз уш пошла такая пьянка, то File::stat тут не нужен, ибо вполне хватит встроенной функции

#!/usr/bin/perl 

(-e $ARGV[0]) ? print ((stat($ARGV[0]))[9]) : print "-1";

[sadman]

Мы же вроде не о perl vs stat, а о .pl vs .sh.

Это вопрос диалектики ))
Тут и спора-то особого нет, мне просто интересно выяснить, что работает быстрее и устойчивей при остальных равных условиях. Будет перл обскакивать shell при запуске из под заббикса - ради бога, перейду в однострочниках на perl.

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

Относительного того, что касается прямого вызова перловского stat-а - я согласен. Это ускорит процесс и уменьшит энтропию системы. Насчет остального, повторюсь, что на мой взгляд, тут уже дело вкуса. Случайно удаленный лидирующий пробел в коде питона наврядли порадует пользователя.

Однако, как мы знаем, практика - критерий истины (даже понимание Маркса тут будет непротиворечиво). Поэтому я взял эту маленькую задачу и применил два условия: есть проверяемый файл и нет файла. Развал дискового массива с потерей 30% исполняемых файлов и удар ядренной бомбы имитировать не стал, вроде бы это топикстартера не интересовало. Если есть иные реальные условия на входе sh, которые поломают его вывод, но оставят такой же perl-код работоспособным - изложите. Покопаюсь чисто для себя, чтобы прокачать скилл.

Оба фрагмента кода достаточно страшные, но практически схожие:

$cat test.sh
#!/bin/sh
#if [ -f "./$1" ]; then stat -c %Y "./$1"; else echo -1; fi;
[ -f "./$1" ] && stat -c %Y "./$1" || echo -1

$cat test.pl
#!/usr/bin/perl
#use warnings;
#use strict;
(-e $ARGV[0]) ? (print ((stat($ARGV[0]))[9])) : print "-1";

Естественно, что один запуск даст грубую оценку времени выполнения, и не даст оценку потребления ресурсов, но всё же:

$ time ./test.sh exists.txt
1461216885

real    0m0.004s
user    0m0.000s
sys     0m0.000s
$ time ./test.sh nonexists.txt
-1

real    0m0.002s
user    0m0.000s
sys     0m0.000s

$time ./test.pl exists.txt
1461216885
real    0m0.004s
user    0m0.000s
sys     0m0.000s

$ time ./test.pl nonexists.txt
-1
real    0m0.004s
user    0m0.000s
sys     0m0.000s

Ну, вобщем, где-то они равны. Однако, скорее всего перл будет сильнее жрать память на старте. Ну, а если включить strict/warning, то время выполнения достигнет уже 0m0.009s.

[yukra]

Это вопрос диалектики ))
Тут и спора-то особого нет, мне просто интересно выяснить, что работает быстрее и устойчивей при остальных равных условиях. Будет перл обскакивать shell при запуске из под заббикса - ради бога, перейду в однострочниках на perl.

Быстрей - шелл, устойчивее - перл.

Относительного того, что касается прямого вызова перловского stat-а - я согласен. Это ускорит процесс и уменьшит энтропию системы. Насчет остального, повторюсь, что на мой взгляд, тут уже дело вкуса. Случайно удаленный лидирующий пробел в коде питона наврядли порадует пользователя.

это немного не тот случай, с тем же успехом мы можем в перле > на < поменять, а в шелле stat на cat. Питом эту "проблему" не прячет, а наоборот заявляет как фичу.

Однако, как мы знаем, практика - критерий истины (даже понимание Маркса тут будет непротиворечиво). Поэтому я взял эту маленькую задачу и применил два условия: есть проверяемый файл и нет файла. Развал дискового массива с потерей 30% исполняемых файлов и удар ядренной бомбы имитировать не стал, вроде бы это топикстартера не интересовало. Если есть иные реальные условия на входе sh, которые поломают его вывод, но оставят такой же perl-код работоспособным - изложите. Покопаюсь чисто для себя, чтобы прокачать скилл.

Я полностью согласен про практику, но не согласен "быстрей значит лучше". Реальных примеров сломать конкретно этот скрипт у меня конечно нет, потому что он слишком простой, но тут же на форуме я регулярно вижу людей с вопросами по шел-скриптам, которые работают не так, как они хотят, или не работают, а ошибок не показывают.

Оба фрагмента кода достаточно страшные, но практически схожие

Вот именно про это я и говорю:

yukra@yukra-ThinkPad-Edge-E330 /tmp/1 $ time ls 

real	0m0.002s
user	0m0.000s
sys	0m0.000s
yukra@yukra-ThinkPad-Edge-E330 /tmp/1 $ which time 
/usr/bin/time
yukra@yukra-ThinkPad-Edge-E330 /tmp/1 $ /usr/bin/time ls 
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 2144maxresident)k
0inputs+0outputs (0major+111minor)pagefaults 0swaps
yukra@yukra-ThinkPad-Edge-E330 /tmp/1 $