Гэта заключная частка артыкула, вось пачатак
У мінулы раз я напісаў аб тым, як рэалізаваў маніторынг прылад, зараз гаворка пойдзе аб кіраванні. У дыскусіях з "тэхнарамі" з боку Замоўца я часта сустракаюся з абмежаваным успрыманнем магчымасцяў такіх маленькіх прылад (з невысокімі рэсурсамі памяці і прадукцыйнасцю), шматлікія лічаць што "максімум што нам запатрабуецца гэта адправіць reboot, для чагосьці больш сур'ёзнага - адправім брыгаду" .
Але практыка паказвае, што гэта не зусім так. Вось невялікі пералік частых тыповых задач:
- Сеткавая дыягностыка і ўхіленне. За ethernet-портам Вашага роўтара звычайна «жыве» іншая жалязяка, у якой свой унутраны ip-адрас. Часам, яе можна (трэба) "попингать". Або кіраванне тунэлем - калі на роўтары, які працуе праз 3G-мадэм раптам не паднімаецца тунэль, але сам роўтар мы бачым.
- Сістэмнае абслугоўванне. Абнаўленне прашыўкі, апгрэйд службовых скрыптоў.
- Эквілібрыстыка. Гэта можна было б назваць "скрыўленнямі", але паняцце "эквілібрыстка" як, цытую, «здольнасць цыркавога артыста ўтрымліваць раўнавагу пры няўстойлівым становішчы цела» - падыходзіць больш. Падобныя сітуацыі ўзнікаюць з прычыны абмежаванасці бюджэту заказчыка. Ніжэй прывёў пару прыкладаў, але т.я. прамога стаўлення да тэмы апавядання яны не маюць, вынес іх у нататкі
Wi-Fi маніторынгМодная апошнія пяць гадоў тэма ў асноўным сярод федэральных сетак рытэйла. Вы павольна шпацыруеце па гандлёвых залах, а Ваш мабільнік з уключаным Wi-Fi у спробах «прысмактацца» да нейкай сеткі рэгулярна рассылае пакеты Probe Request, якія можна аналізаваць, з мэтай Вас палічыць: як часта Вы прыходзіце ў гэтую краму, па якіх траекторыям гуляеце і гэтак далей. Далей дадзеныя збіраюцца, аналізуюцца, малююцца цеплавыя карты і менеджэры за такія карцінкі "выбіваюць" грошы ў кіраўніцтва або інвестараў. Ну а пакуль….«грошай няма, але вы трымаецеся…», а вынік(рэальны) ужо трэба паказаць, уключаецца старая добрая песня «Так-так, потым мы вядома паставім ціскі і ўсё што пажадаеце, але зараз трэба паказаць Замоўцу вынік! Дарэчы забыліся сказаць, Заказчык дазволіў наша абсталяванне падключаць да свайго хотспоту праз вайфай, але на агульных пачатках, проста як быццам мы гасцявыя кліенты». І вось прыходзіцца рабіць роўтэраў-эквілібрыстаў – паднімаецца некалькі WiFi сабітэрфейсаў, адным з якіх ён чапляецца за хотспот, а другім маніторыць навакольнае асяроддзе, сутаргава выгружае вынік tcpdump-а ў сябе ж, далей змесціва файла пакуе ў архіў і рызыкуючы памерці ад. спрабуе выплюнуць змесціва на фтп-сервер. Нядзіўна, што роўтэр-эквілібрыст часта "зрываецца" і яго неяк даводзіцца выдалена "рэанімаваць".
радыусТут апісаць сітуацыю прасцей прыкладна такім сцвярджэннем замоўца: «Мы хочам дэцэнтралізаваную сетку хотспотаў, якія б працавалі на абсталяванні мадэль якога загадзя не вядомая, праз каналы, але якія мы яшчэ не ведаем. Ах, забыліся сказаць, мы не толькі жадаем паказваць рэкламу кліентам, але і аналізаваць усё вакол месцы ўсталёўкі хотспота. Не, мы пакуль не ведаем навошта, але прыдумаем, не сумнявайцеся, мы ж змаглі прыдумаць гэтую ідэю»
І трэба не забываць, што ў сілу масу нявызначаных загадзя абставінаў, кіраванне павінна ажыццяўляць у нестандартных умовах, калі мы не можам падлучыцца да роўтара наўпрост праз ip: порт і змушаныя проста чакаць праявы актыўнасці ад яго. Калі абстрагавацца, то дыялог паміж серверам і роўтэрам можна ўявіць вось так:
- Маршрутызатар: прывітанне. я роўтэр вось такой, ці ёсць для мяне задачы ?
- Сервер: роўтэр вось такой я цябе зарэгістраваў, што ты жывы. Вось задача: пакажы мне вынік каманды ifconfig ?
- Маршрутызатар: прывітанне. я роўтэр вось такой, у мінулы раз ты прасіў паказаць вынік ifconfig, вось ён. Ці ёсць для мяне задачы?
- Сервер: роўтэр вось такой я цябе зарэгістраваў, што ты жывы. Задач для цябе няма.
Самае цікавае пытанне: а якім чынам выдалены роўтар можа даслаць пэўны аб'ём інфармацыі? У мінулай частцы я апісваў, што на роўтары з-за абмежаванасці рэсурсаў варта толькі "зрэзаны" wget, які працуе толькі праз GET і нічога больш, няма ні фтп-кліента, ні curl. Дакладней, нам патрэбен універсальны спосаб, незалежна ад асаблівасцяў зборкі выявы. Я спыніўся на выкарыстанні wget. Дакладней, ну як «спыніўся» - у мяне проста не было выбару 🙂
Адразу агаворкаМаё рашэнне па кіраванні працоўнае, не моцна абмежаванае і я ўпэўнены - крывое, нават калі яно задавальняе большасць маіх заказчыкаў. Як бы можна было зрабіць па розуме – напісаць невялікую ўтыліту, якая праз 80-ы порт шле POST-ам бінарныя дадзеныя. Уключыць яе (ўтыліту) у склад прашыўкі роўтара і ўжо з дапамогай bash-а звяртацца да яе. Але рэальнасць такая, што: а) трэба хутка б) магчыма трэба рабіць усё на існуючым "заапарку роўтэраў" у) "не нашкодзь!" - калі роўтар працуе і выконвае іншыя задачы, старайся ўносіць змены, якія не закрануць існуючы функцыянал.
Пяройдзем да рэалізацыі. Дапусцім ваш заказчык хоча з zabbix, перазагружаць роўтэр лёгка і нязмушана, "пстрычкай мышы". Сёння мы пачнем апісанне рэалізацыі з заббікса.
У меню "Адміністраванне" -> "Скрыпты" дадаем новы скрыпт. Называем яго "Reboot", у якасці каманды прапісваем "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Далей: Меню "Маніторынг" -> "Апошнія дадзеныя" -> "Пстрычка правай кнопкай мышы на трэба вузле сеткі". Вось дык вось будзе выглядаць меню пасля дадання скрыпту.
Адпаведна, скрыпт reboot.php кладзем у дырэкторыю /usr/share/zabbix (у Вас яна можа быць іншая, я выкарыстоўваю каранёвую дырэкторыю zabbixa).
Абмоўка для бяспекіДля нагляднасці тлумачэння ў скрыпце я выкарыстоўваю толькі id роўтара, але не карыстаюся паролем. У працоўнай версіі так рабіць не рэкамендуецца! Чаму так зрабіў я: таму што вялікае пытанне - дзе захоўваць паролі да роўтэраў? У самым 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, дзе:
message=`ifconfig` - Мы зменнай $message даем вынік вываду каманды ifconfig
wget « - наш скрыпт a.php, які рэгіструе роўтэры і прымае паведамленні ад іх
u=user&p=password!&m=$message - уліковыя дадзеныя і значэнню зменнай запыту m - прысвойвае змесціва зменнай $message
-O /tmp/out.txt - выснова ў файл /tmp/out.txt нам у дадзеным выпадку не патрэбен, але калі не паказваць дадзены параметр, wget не спрацоўвае
Чаму гэта крыва працуеТаму што гэта патэнцыйная дзірка ў бяспецы. самая бяскрыўдная памылка, якая можа здарыцца - гэта калі ў выснове вашай каманды да прыкладу будзе сімвал "&". Таму трэба фільтраваць і ўсё, што адпраўляецца з роўтэраў і ўсё што прыходзіць на сервер. Дааа, мне сорамна, праўда. У сваё апраўданне магу толькі напісаць - што ўвесь артыкул прысвечаны таму, як кіраваць роўтэрамі з нявызначанай загадзя прашыўкай, з нявызначанымі загадзя каналамі сувязі.
Ну і зачын на будучыню: пакуль не разабраўся, як стандартнымі сродкамі zabbix-а адлюстроўваць вынікі(напрыклад вынік выканання каманды), якія прыходзяць на сервер.
Нагадваю, што ўсе зыходнікі можна забраць з Git-рэпазітара, па адрасе:
Крыніца: habr.com