Това е финалната част на статията, ето началото
Последния път писах за това как внедрих мониторинг на устройството, сега ще говорим за управление. В дискусиите с "технари" от страна на Клиента често се срещам с ограничено възприемане на възможностите на такива малки устройства (с ниски ресурси на паметта и производителност), мнозина смятат, че "максимумът, от който се нуждаем, е да изпратим рестартиране , за нещо по-сериозно - ще изпратим бригада" .
Но практиката показва, че това не е съвсем вярно. Ето малък списък от обичайни типични задачи:
- Мрежова диагностика и отстраняване на проблеми. Зад Ethernet порта на вашия рутер обикновено „живее“ друго желязо, което има свой собствен вътрешен ip-адрес. Понякога може (трябва) да се „пингува“. Или управление на тунел - ако тунелът внезапно не се издигне на рутера, работещ през 3G модема, но виждаме самия рутер.
- Системно обслужване. Актуализация на фърмуера, надграждане на сервизни скриптове.
- Еквилибристика. Това може да се нарече "перверзии", но понятието "въжеиграч" като, цитирам, „способността на цирков артист да поддържа баланс в нестабилна позиция на тялото“ - приляга по-добре. Такива ситуации възникват поради ограничения бюджет на клиента. Дадох няколко примера по-долу, но оттогава не са пряко свързани с темата на разказа, слагам ги в бележките
wifi мониторингМодна тема през последните пет години, предимно сред федералните търговски вериги. Вие бавно се разхождате из търговските зали и вашият мобилен телефон с включен Wi-Fi, в опит да се „прилепи“ към някоя нишка от мрежата, редовно изпраща пакети Probe Request, които могат да бъдат анализирани, за да изчислят за вас : колко често идвате в този магазин, по какви траектории ходите и т.н. Освен това данните се събират, анализират, изготвят се топлинни карти и мениджърите „избиват“ пари от ръководството или инвеститорите за такива снимки. Междувременно .... "няма пари, но се дръж ...", а резултатът (реален) вече трябва да се покаже, добрата стара песен "Да, да, тогава разбира се, че ще доставим cisco и каквото искате, но сега трябва да покажем на клиента резултата! Между другото, забравиха да кажат, че Клиентът е разрешил нашето оборудване да бъде свързано към неговата точка за достъп чрез Wi-Fi, но на общо основание, все едно сме гост клиенти. И сега трябва да направите еквилибристни рутери - няколко WiFi подинтерфейса се издигат, единият от които се придържа към горещата точка, а вторият наблюдава околната среда, трескаво разтоварва резултата от tcpdump в себе си, след това пакетира съдържанието на файла в архив и рискува да умре от "преяждане", опитвайки се да изплюе съдържанието на ftp сървъра. Не е изненадващо, че еквилибристният рутер често се „разваля“ и по някакъв начин трябва да бъде „реанимиран“ дистанционно.
радиусТук е по-лесно да се опише ситуацията с нещо като това изявление на клиента: „Искаме децентрализирана мрежа от горещи точки, която да работи на оборудване, чийто модел не е известен предварително, чрез канали, но все още не знаем кои. О, забравихме да кажем, че искаме не само да показваме реклами на клиентите, но и да анализираме всичко около мястото за инсталиране на гореща точка. Не, все още не знаем защо, но ще го измислим, не се колебайте, успяхме да излезем с тази идея.
И не трябва да забравяме, че поради много несигурни обстоятелства предварително, управлението трябва да се извършва в нестандартни условия, когато не можем да се свържем с рутера директно през ip: порт и сме принудени просто да чакаме да се появи активност от то. Ако се абстрахираме, тогава диалогът между сървъра и рутера може да бъде представен така:
- рутер: Здравейте. Аз съм такъв и такъв рутер, има ли задачи за мен?
- сървър: такъв и такъв рутер, регистрирах те, че си жив. Ето предизвикателството: покажете ми резултата от командата ifconfig?
- рутер: Здравейте. Аз съм такъв и такъв рутер, последния път, когато поискахте да покажете резултата от ifconfig, ето го. Има ли задачи за мен?
- сървър: такъв и такъв рутер, регистрирах те, че си жив. За вас няма задачи.
Най-интересният въпрос е: как отдалечен рутер може да изпрати определено количество информация? В последната част описах, че рутерът, поради ограничените ресурси, има само "съкратен" wget, който работи само чрез GET и нищо друго, няма ftp клиент или curl. По-точно, имаме нужда от универсален начин, независимо от характеристиките на монтажа на изображението. Спрях се да използвам wget. По-точно, как „спрях“ - просто нямах избор 🙂
Веднага резервацияМоето решение за управление работи, не е много ограничено и съм сигурен, че е криво, дори и да отговаря на повечето ми клиенти. Как би било възможно да го направите разумно - напишете малка помощна програма, която изпраща двоични данни чрез POST през 80-ия порт. Включете го (помощна програма) във фърмуера на рутера и използвайте bash за достъп до него. Но реалността е, че: а) трябва бързо б) вероятно трябва да направите всичко на съществуващия "зоопарк от рутери" в) "не навредете!" - ако рутерът работи и изпълнява други задачи, опитайте се да направите промени, които няма да засегнат съществуващата функционалност.
Нека да преминем към изпълнението. Да приемем, че вашият клиент иска от zabbix да рестартира рутера лесно и естествено, с „щракване на мишката“. Днес ще започнем описанието на изпълнението със zabbix.
В менюто "Администриране" -> "Скриптове" добавете нов скрипт. Наричаме го "Рестартиране", като команда пишем "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Следва: Меню "Мониторинг" -> "Последни данни" -> "Щракнете с десен бутон върху желания хост". Ето как ще изглежда менюто след добавяне на скрипта.
Съответно, ние поставяме скрипта reboot.php в директорията /usr/share/zabbix (може да е различно за вас, аз използвам основната директория na zabbixa).
Отказ от отговорност за безопасностЗа яснота на обяснението в скрипта използвам само идентификатора на рутера, но не използвам паролата. В работната версия това не се препоръчва! Защо направих това: защото големият въпрос е къде да съхранявам паролите за рутери? В самия zabbixe в "инвентар"? Противоречива практика. Като опция: ограничете външния достъп до самия файл reboot.php
reboot.php файл
<?php
// присваиваем параметры с консоли переменным
$user = $argv[1];
// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля.
//$password = $argv[2];
$conn=new mysqli("localhost","db_user","db_password","db_name");
if (mysqli_connect_errno()) {
exit();
}
$conn->set_charset("utf8");
// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>Всъщност всичко. Въпросът „как да получите резултата от изпълнението на командата от страна на устройството“ остава отворен. Нека разгледаме задачата, използвайки командата ifconfig като пример. Към устройството може да бъде изпратена следната команда:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, където:
съобщение=`ifconfig` - присвояваме резултата от изхода на командата ifconfig към променливата $message
wget " - нашия a.php скрипт, който регистрира рутери и получава съобщения от тях
u=потребител&p=парола!&m=$съобщение - идентификационни данни и стойността на променливата на заявката m - присвоява съдържанието на променливата $message
-O /tmp/out.txt - в този случай не се нуждаем от изход към файла /tmp/out.txt, но ако този параметър не е указан, wget не работи
Защо това работи погрешноЗащото това е потенциална дупка в сигурността. най-безобидната грешка, която може да се случи, е ако резултатът от вашата команда например съдържа символа "&". Следователно е необходимо да се филтрира всичко, което се изпраща от рутерите и всичко, което идва на сървъра. Да, срам ме е, наистина. В моя защита мога само да напиша, че цялата статия е посветена на това как да управлявате рутери с недефиниран фърмуер, с недефинирани комуникационни канали.
Е, засегнах бъдещето: все още не съм разбрал как да отразявам резултатите (например резултата от изпълнение на команда), които идват на сървъра с помощта на стандартни zabbix инструменти.
Напомням ви, че всички източници могат да бъдат взети от хранилището на Git на адрес:
Източник: www.habr.com