Aktualizace router OS

[rsaf]

Používám TR-069 server GenieACS pro HUA ONT. Celá konfigurace (podobně jako v SNMP) je uložena systémem objekt-tag-hodnota, takže třeba jedno firewallové pravidlo je uložené jako hromada záznamů

Kód: Vybrat vše

Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Enable true 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Order 7 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Description accept SSH 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Target Accept 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.TargetChain 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Log false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourceInterfaceGroup all 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourceInterface 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourceInterfaceExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestInterfaceGroup all 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestInterface 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestInterfaceExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestIPRange 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestIPExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourceIPRange 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourceIPExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.Protocol 6 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.ProtocolExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestPortList 22 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.DestPortExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourcePortList 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.SourcePortExclude false 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.ConnState 
Device.Firewall.X_MIKROTIK_Filter.Chain.1.Rule.7.ConnStateExclude false

V registrech jsou i různé stavové informace, třeba:

Kód: Vybrat vše

Device.DeviceInfo.SoftwareVersion 6.43.4
Device.DeviceInfo.ModelName RBD52G-5HacD2HnD
Device.DeviceInfo.ProductClass hAP ac²
Device.DeviceInfo.X_MIKROTIK_SystemIdentity N176-HomeGW


GenieACS si dokáže na základě filtrů (filtr je možné postavit na hodnotě nějakých tagů) na každé zařízení naaplikovat nějaké "presety", které mohou přidat/smazat/upravit jednotlivé tagy, aplikovat soubor s firmware nebo aplikovat "provision".
Provision je potom v podstatě javascriptový kód, který dokáže číst a aplikovat jednotlivé hodnoty a jinak dělat cokoliv co javascript umí, vč. např. dotazů na externí webserver (json data...).

Pokud např. chci, aby si uživatelé parametr svých domácích wifi AP (ssid, wpa klíč) mohli nastavovat sami přes klientskou zónu, tak na pár řádku napíšu kousek kódu, který z dotazujícího-se AP vytáhne MAC adresu nebo identitu, doptá se webserveru (klienstské zony) jestli má pro tohle AP nastavení a pokud ano, tak ho aplikuje (nastaví odpovídající tagy). Systém sám si kontroluje, co je reálně nastaveno a co se tam pokouším poslat, takže pokud se opakovaně nastavuje něco co již nastavené je, na zařízení se nic neprovádí.
V zařízení se nastavuje inform interval - jak často se spojuje se serverem. Pokud jsou ale nastaveny odpovídající parametry, může se server spojovat i aktivně se zařízením. Server může mít jednotlivé úlohy pro zařízení "ve frontě"...
Celkově jsem usoudil, že nějaká alespoň trošku úplná implementace protokolu CWMP je nad mé síly, takže se musim "spokojit" s hotovým ACS serverem a jeho možnostmi.

[P3k8]

Po niekolkych upravach aj toto fungovalo:
https://youtu.be/3zYBvRxp_lg

[okoun]

rozlišený to nemám. Tahaji si všichni to samí resp. se dotazujou na stejnou url ale je to php server takže si na základně IP která o script žádá lze přes nějakej seznam vygenerovat výstup pro konkrétní RBčka. To samí to verzování aby si prostě třeba poupgradoval jenom něco na konkrétní verze atd.. Jo a ještě mám v url jako get parametr kterej rozlišuje jestli jde o CPE, AP, backbone a nebo homeAP atd.. takže ten script může brát v potaz i tohle. například http://example.com/konfigurace.php?type=cpe na kterou se dotazujou jenom CPE jednotky a podobný věci. Je třeba uvážit jak to dělat a jak postavit ten dotaz pro fetch a co vůbec chce člověk rozlišovat. Lze samozřejmě použít jenom rozlišení typu a na základě toho vygenerovat novej fetch s novym url a to pak ještě dodatečně spustit znova aby se nasimulovala doplňková komunikace. Předpokládám že právě tohle řeší TR-069 který naváže spojení se serverem a může si několikrát za sebou vyměnit informace což by bylo lepší ale aktuálně vůbec nevím jak tohle udržet v jednom spojení skrz php protože se mi nechce používat ty hotový systémy pro TR-069. Ale zatim jsem to nějak moc nezkoumal, nemám na to čas a není to aktuálně nutný. Problém taky je že většinou TR-069 se používá pro autokonfiguraci a dál už ne takže většina tutoriálů a popisů je právě na prvotní nastavení ale já bych chtěl přes to posílat různý stavy routeru.

mě by zajímalo jak třeba řešíš to když vyšleš do CPE změnu hesla a nějaká CPE je dlouhodbě vypnutá třeba protože domácnost pozastavila na zimu a bude zapínat až na jaře no a ten problém je v tom že třeba za měsíc od poslání toho scriptu pro změnu hesla chceš poslat další script, takže pro CPE které v tom měsíci nebyly zapnuté ten první script už nedojde?

[rsaf]

Po niekolkych upravach aj toto fungovalo:
https://youtu.be/3zYBvRxp_lg

Sorry, ale takovouhle hovadinu si můžeš nasadit 2 routerů doma, ne na síť poskytovatele.
Update probíhá 1x za 7 dní, takže někdy budu čekat 6 dní na opravu kritické bezpečnostní díry, jindy se mi stane že se do routeru nahraje včera vydaná a vůbec nevyzkoušená verze. Pokud to pustím na všech routerech ve 4:00 ráno tak se velmi lehce stane, že těm pomalejším na konci sítě přeruším stahování, protože nějaký rychlejší někde po cestě už se restartuje.

[okoun]

nevim jestli je vůbec dobrá myšlenka řešit upgrade backbonu automaticky...
jinak 7 dní? některé ISP sítě to nemají do teď

[hol]

urcite by se nemelo nic dit samo bez moznosti to ridit. Mk chrli jednu verzi za druhou a bez dukladneho otestovani nic do produkce nesmi. I tak jsme se kolikrat spalili, napr. ted nedavno pri zmene kanalovani.

Primitivni metoda je, ze se upgrade spusti po nahrati balicku na interni fiktivni web mk repository pres klasicky upgrade v mk klientech. Druha je dude. Oboji ma mnoho ale.
Lepsi reseni nez tyto dve moznosti prave hledame

Podotazkou pak je, jak prip prvotni zmeny nastaveni zejmena schedulleru dostat co nejsnaze na vsechny mk v siti.

[hapi]

mě by zajímalo jak třeba řešíš to když vyšleš do CPE změnu hesla a nějaká CPE je dlouhodbě vypnutá třeba protože domácnost pozastavila na zimu a bude zapínat až na jaře no a ten problém je v tom že třeba za měsíc od poslání toho scriptu pro změnu hesla chceš poslat další script, takže pro CPE které v tom měsíci nebyly zapnuté ten první script už nedojde?

tak uvedl sem základ. Pokud to si to spojíš se systémem kde IP adresy máš tak můžeš jakoby "odškrtávat" hotový práce u jednotlivých IP či boardů. Jako hesla neměníme ale jde to. Většina věcí tam může bejt stále třeba jako změna DNS serverů kde se dá nejdříve ověřit jestli DNS je správné a pokud ne tak přepsat takže si to ty boardy můžou natahovat každou hodinu a kontrolovat. Pokud to dokážeš napsat do scriptu v mikrotiku (if (dns!=8.8.8. do=set dns) tak to nacpeš na server a vyřešeno. Může to tam bejt stále.

[okoun]

tak zrovna ty hesla jsou aktuální problém narozdíl od DNS který zrovna máš mít vyřešená již nějakým standartizovaným řešením ala DHCP, PPPoE....

[hapi]

to byl příklad.

Máš mít vyřešení verze už přes rok aby si neřešil hesla.

[hol]

to je svata pravda. Kdyz jsme u toho, pouzivate nekdo ssh klic misto hesla pro lokalniho admina? Je to bezpecnejsi? Co to ma za omezeni? Klasicky pristup pro usery jakoze techniky je pres radius.

[rsaf]

Máme více UBNT, takže to řešíme spíše tam... a upgrade děláme ručně přes aircontrol. Mám vytipováno několik (cca 35) testovacích zařízení tak, abych pokud možno pokryl všechny modely a všechny scénáře (AP/bridge CPE/router CPE), jsou to zařízení na dobře přístupných místech, ne úplně kritická a v místech, kde to máme dobře monitorované, máme tester u zákazníka nebo je tam třeba připojen náš technik... Do těchto zařízení nalívám FW v prvním kole na testování. Až se FW jeví jako stable, upgradujeme další zařízení postupně a víceméně náhodně, většinou upgrade trvá několik dní. Ze začátku naliju třeba 100 zařízení ve skupinkách po 20ti a počkám dva dny, potom po skupinkách zbytek. Vždy čekám a kontroluji, kolik je "mrtvol" - nechci ráno přivítat techniky s tím, že jsem včera při upgrade zabil 20 CPE.

[iTomB]

Hapiho verze a i ta z videa ma jednu velkou nevyhodu.
1. Co se stane, pokud se v jeden okamzik upgraduji 2 mikrotici. Jeden napajeci a druhy co je napajen? Ja tohle omylem udelal ruco, takze pak vyjezd a netinstall
2. Dalsi veci je obcasna zmena logiky (nedavno treba zmena frekvenci, drive bridge atd).

Ja to radsi resim tak, ze si na serveru pustit upgrade a dam mu rozsah co ma projit (davam vzdy jen 1 sektor routovany). System si najde vsechny zive IP nahraje do nich script a ten dela upgrade z meho serveru. Muzu resit upgrade pro platformu, ale i pro konkretni typ zarizeni (treba pro LHG60 jiny FW bez pro LHG ac.).
Jak se upgraduji vsechny mikrotici z rozsahu, tak se posle reboot klientskym a pak AP (reboot AP by zamezil upgrade klienta).
Script jeste upravi scheduler a po rebootu otestuje BIOS a pripadne udela upgrade a dalsi reboot. Nasledne po sobe uklidi (nezustane tam zadna cast scriptu atd)
Vyhoda tohohle reseni je, ze je vypadek cca do 2 minut celeho sektoru a i klientu.
Po upgradu radsi jeste rucne zkontroluju, zda je vse ok (pocet upgradovanych zarizeni a zda to sedi na pocet registrovanych).

[hapi]

a co ti brání v tom nechat si stahnout v jedný vlně balíčky a v druhý poslat reboot? Když máme takhle RBčka závislí na sobě tak upravuju ručně při instalaci čas scheduleru třeba na 10 minut od sebe.

Změna frekvencí.. no víš jak, já vim o těch změnách frekvencí, bylo to v changelogu a máme v jednotkách scanlist takže než se upgradoval firmware tak sem si tím stejným scriptem natahnul novej scanlist.

Tvůj system jsme měly taky ale nereflektuje RBčka za natem. Sektory updatuju ručně a vlastně celou backbone a pak přes noc nechám pustit updaty klientů. U klientů je jedno kdy se updatnou. Nemám s updaty problémy. Jasně že prvně klidně i ručně updatnu jeden komplet sektor a tejden sleduju co se děje. Ale už si nepamatuju kdy update nějaká jednotka nerozdejchala. Jako jo stává se to ale pak se ukáže že je vadná.

[iTomB]

Hapi, myslim ze celou dobu se tu resil upgrade hlavne paternich a AP + klienti, ne domaci AP.

Ja si tam muzu taky natahnout upgrade konfigurace. Ohledne domacich AP, tak to neni problem hodit do scheduleru. Cely pocatek je: stahni si soubor z web serveru a pust jej. Fakt neni problem to v domacich AP resit jinak. Ja chtel hlavne minimalizovat vypadek na siti, proto jsem to delal tak, aby sel 1 sektor vcetne klientu v jeden okamzik. Ne AP, po 2 minutach, jeden z klientu, pak zas dalsi atd. Klient i pres den pociti max 1 vypadek (pokud neni na trase, ktera se upgraduje coz moc nemam) a ty 2 minuty jsou pro nej ok. Dulezitejsi sektory udelam v noci, ci brzo rano, kdyz vidim, ze je tam 0 prutok. A vetsinou jeste zkontroluju jak se chova propustnost atd. Nekde, kde byli puvodne rozdilne verze, tak se pak srovnal prutok i k 90Mbit/s

Domaci AP reseni: Stahni si pres den info, zda je upgrade, stahni pripadne balicek, reboot nastav na noc. To je to nejmensi

[hol]

ukazuje nám to, že máme aktuální verzi stejnou, jako je na našem ugrade MK webu a přitom se to chce aktualizovat. Netušíte někdo, co je blbě?

Kód: Vybrat vše

/system package update> check-for-updates               
channel: current  installed-version: 6.43.4   
 latest-version: 6.43.4             
status: New version is available