Firefox frissítése lokális hálózaton központi szerverről

Ez az iromány nagyvállalati környezetben dolgozó rendszergazdáknak lehet segítség - otthoni környezetben, kisvállalatnál, pár számítógép esetében nem feltétlen érdemes alkalmazni. Azt mutatom be benne, hogyan lehet saját frissítőszervert létrehozni a Mozilla Firefox böngészőhöz, s azt automatizáltan működtetni.

Mi okunk lehetne rá, hogy saját szerverről frissítsünk? A Mozilla Firefox egy-egy frissítése nem túl nagy (a 83.0 verzió ~60MB), viszonylag gyorsan le is lehet tölteni, így mi értelme van, saját kézbe venni az irányítást? Több indokunk is lehet erre:

• viszonylag kicsi az Internet irányú sávszélességünk és többtucat/százas nagyságrendű gépen kell frissíteni (ekkor bedugulhat a "csövünk", s ideiglenesen meg is akadhatunk)
• egyedi frissítőfájlt hozunk létre (ez esetben a szkriptem nem jó hozzá)
• nem minden számítógépünk van kiengedve Internet irányba, de a saját webes alkalmazásainkat el kell érnünk vele

Esetemben az első indok volt releváns, százas nagyságrendben kell gépeken frissíteni rendszeresen, de a rendelkezésre álló Internet irányú sávszélességem korlátozott, ha egyszerre akarnának frissíteni, akkor könnyedén túl nagy adatforgalmat generálnak.

Szerencsére a Mozilla kínál megoldást erre a problémára, lehetőség van saját frissítőszerver üzemeltetésére. A leírást követve már csak be kell üzemelnünk és minden megy magától gondolhatnánk... Természetesen ez az írás nem jött volna létre, ha ez tényleg így lenne.

Maga a leírás remek és az alapokat tekintve valóban jól leírja mit kell tenni, azonban pár helyen rettentő hiányos, illetve nem megfelelő/félrevezető információkat tartalmaz. A linkelt leírást követve létre tudjuk hozni a szervert és kézi frissítéssel tudjuk teríteni a letöltött verziót (ne feledkezzünk meg a policies.json fájlról se, amit célszerűen csoportházirendből szórjunk ki a klienseinknek). Nyilván akkor nem megfelelő ez, ha mindig frissítenénk automatikusan, s így nekünk kell figyelni rá, hogy amikor jön új frissítés, letöltsük, s elkészítsük hozzá a megfelelő XML állományt. S ha már az XML állomány szóba került - ez a pont, ahol rossz információk szerepelnek a leírásban!

A leírást pontosan követve ugyanis beleszaladhatunk abba a hibába, hogy a kliens ugyan megtalálja a frissítő MAR fájlt, de az XML fájlban szereplő információk miatt ismét meg fogja próbálni letölteni miután frissült, s ezt így egy végtelen ciklusban teszi, folyamatosan frissíteni fog.

Rákérdeztem a Mozilla közösségi fórumán erre a dologra, de "természetesen" egy hét után se jött egyetlen árva reakció se a kérdésemre, így magamtól kellett kitalálni mi is folyik ilyenkor, mi lesz az az információ, ami megszakítja ezt az ördögi kört és a Firefox rájön, hogy már bizony felfrissült az aktuális verzióra.

Volt pár tippem mi lehet amit vizsgál frissítéskor a program, s kipróbálással igazoltam a feltevésem. A feltételezésem szerint a program a saját verziószámát és a buildID azonosítóját hasonlítja össze az XML fájlban szereplő adatokkal. Mikor a frissítő MAR fájlnak megfelelő értékeket írtam be, megállt a végtelen frissítési ciklus, s a Firefox az aktuális verziónál maradt.

Eddigre már kész volt az automatikus letöltő szkriptem, ami elkészíti a megfelelő XML fájlt is hozzá, s ezt kellett átírnom úgy, hogy a verzió mellett a megfelelő buildID is be tudjon kerülni. S bár a verziót nagyon könnyű összeszedni, ez utóbbi azonosító eléggé el van rejtve, s maga a MAR fájl nem is direktben tartalmazza. A kinyeréséhez behatóbb vizsgálat vált szükségessé, aminek során megtaláltam a Firefox mappájában lévő application.ini fájlt, ez tartalmazza a kérdéses értéket. De hogyan lehetne kiszedni ezt a fájlt a frissítő MAR fájlból? Szerencsémre a Mozilla Wiki elég jó leírással szolgál a fájl felépítéséről, bár ezzel együtt se túl egyszerű a feladat, mivel nem egyszerű tömörített fájlról van szó, hanem minden egyes fájl egyesével van betömörítve, külön indexelve a fájl végén.

A fájl leírása alapján az első 4 bájt adott (MAR1), majd a következő 4 bájt adja meg az index (tartalomlista) kezdőpozícióját. A kezdőpozícióra ugorva az első 4 bájt mondja meg mekkora az index teljes mérete, majd ezután következnek az egyes indexbejegyzések fix formában. Ez a fix forma nem túl bonyolult - 4 bájt mondja meg a kérdéses fájl kezdőpozícióját, 4 bájt a méretét, 4 bájt a fájltulajdonságokat, változó hosszban a fájl nevét, amit egy 0 értékű bájt zár le. A feldolgozás során kell megkeresni az application.ini fájlt, azt kimenteni és feldolgozni. Igen ám, de ez a fájl be van még tömörítve, tehát ki kell csomagolni mielőtt megkezdhetnénk a tartalmának vizsgálatát - ehhez a 7-zip konzolos verzióját használom.

Mindezen magyarázatok után következzen a szkript rövid ismertetése, függőségei. A szerver, amelyikre én feltettem, már eleve WSUS kiszolgáló, így a webkiszolgáló funkció (IIS) már működik rajta, nem kell hozzá külön másik webszervert kialakítani. Az IIS felületén mindössze egy új oldalt kell létrehozni, ahonnan ki fogjuk szolgálni a klienseinket. A szkriptben fontos, hogy ez a mappa jól szerepeljen, ide fogja letölteni a frissítőfájlt és elkészíteni az update.xml fájlt! A mappa pontos útvonalát a $localfolder változó értékeként kell megadni. Én 64 bites magyar verzióhoz készítettem el a szkriptet, úgy, hogy mindig a legújabb verziót szedi le, ami normál kiadású nem béta verzió (ezt úgy jelölik, hogy csak számot tartalmaz a verziószám). Ennek megváltoztatásához az $url változónál kell változtatni, illetve a szűrőfeltételt lehet módosítani pár sorral feljebb. Ha a szkriptben a megfelelő változtatásokat elmentettük, akkor még a 7z.exe és 7z.dll fájlok elérési útját adjuk meg neki, majd állítsuk be ütemezett feladatként, s akár meg is feledkezhetünk róla...

Ami még felmerülhet kérdésként, hogy mi van olyankor, ha különböző verziókhoz is szeretnénk frissítést kiszolgálni? Ilyenkor sajnos úgy tűnik, hogy még egy weboldalt kell létrehozni, vagy almappázni, s csoportházirendes szűréssel kiválasztani, hogy melyik Firefoxnak melyik frissítést adjuk, önmagától nem tudja kiválasztani a megfelelőt...