Aktualizacja kontrolera Cisco WLC 2504

Aktualizacja kontrolera Cisco WLC 2504 nie jest zbyt trudna do wykonania, wymaga jednak dość solidnego i czasochłonnego przygotowania.

1. Dodać kontrakt na stronie cisco.com, by można było ściągnąć najnowszy soft dla kontrolera. Jeśli nie masz konta na cisco.com to spytaj o to dostawcę sprzętu, od którego kupiłeś kontroler – powinni pomóc. Następnie ustalić ścieżkę upgrade’u: nie wgrywaj „na pałę” najnowszej dostępnej wersji, bo może się okazać, że jest ona niedostosowana do danego kontrolera, lub należy zrobić najpierw upgrade pośredni.

Pamiętaj również, że jeżeli masz rozwiązanie do zarządzania sieciami typu Cisco NCS (obecnie zastąpione przez Cisco Prime), to aktualizacje kontrolerów również są wspierane do którejś wersji. Najnowsza możliwa może nie zadziałać w NCS, a upgrade do Prime niestety nie jest darmowy.

2. Ustalić z biznesem o jakiej porze i przez jak długi czas nie będzie dostępna sieć bezprzewodowa.

3. Zgrać backup konfiguracji używając serwera FTP. Można użyć postawionego u siebie serwera albo posłużyć się prostym programem typu Open TFTP Server i postawić tymczasowy serwer na swoim laptopie.

Aby zgrać aktualną konfigurację, należy:

– wejść w menu Commands
– z menu z lewej strony wybrać „Upload file”
– wpisać adres serwera FTP/TFTP, do którego chcemy zgrać konfigurację, podać login/hasło i nadać nazwę dla pliku
– wcisnąć przycisk Upload

Po chwili powinniśmy mieć na serwerze FTP plik z konfiguracją. W moim przypadku plik miał wielkość ~18 KB:

blog1_09

4. Opcjonalne: wyłączyć sieci WiFi na kontrolerze (przejść do WLANs, zaznaczyć wszystkie SSID-y, a następnie z menu po prawej stronie wybrać „Disable Selected”.

5. Wrócić do „Commands”, ale tym razem do „Download File”, z listy wybrać „Code” i wybrać sposób, w jaki kontroler ściągnie plik z nowszym firmware. Następnie kliknąć „Download” w prawej górnej części strony. Powinien pojawić się poniższy komunikat:

blog1_01

 

Następnie będzie kilka kolejnych komunikatów o aktualizacji oprogramowania, jak:

Writing new RTOS to flash disk.
Writing new APIB to flash disk.
Executing fini script.

… i jeszcze masa innych, których nie zdążyłem zobaczyć.

Ostatnim etapem wgrywania powinien być komunikat:

FTP File transfer is successful. Reboot the controller for update to complete. Optionally, pre-download the image to APs before rebooting to reduce network downtime.

blog1_06

6. Tak więc restartujemy kontroler, jak nam kazano: wchodzimy w Commands -> Reboot. Z dwóch dostępnych opcji musimy wybrać „Save and Reboot”, po czym oczywiście stracimy łączność z kontrolerem.

7. Opcjonalnie: po nawiązaniu łączności z kontrolerem należy włączyć sieci WiFi (analogicznie do kroku 4).

W moim konkretnym przypadku kontroler wstał po około dwóch minutach. Na wgranie softu na AP-ki trzeba było poczekać kilka kolejnych minut, przy czym pod tym kontrolerem miałem dwie lokalizacje połączone WAN-em (tryb H-Reap). Mimo to, wszystko poszło jak z płatka i po ok. 5 minutach można było się połączyć z sieciami WiFi. Całość operacji zajęła około 30-45 minut ale to tylko dlatego, że robiłem to po raz pierwszy i za każdym razem posiłkowałem się instrukcjami. Zdecydowanie więcej czasu zajmuje zrozumienie ścieżki upgrade’u, dodanie kontraktu do konta na cisco.com i pościąganie firmware’ów.

 

 

Aktualizacja Adobe Flash Player na bieżąco

Jak wiadomo, Adobe Flash Player jest w ścisłej czołówce, jeśli chodzi o znalezione podatności i potencjalne źródła wejścia do stacji zdalnej. Najlepiej świadczą o tym wydawane co chwilę poprawki do rzeczonego oprogramowania oraz lista podatności. Dotychczas radziłem sobie z uaktualnianiem Playera poprzez soft pozwalający mi zdalne instalowanie wcześniej przygotowanych paczek .msi. Fakt – przygotowanie takiej paczki chwilę zajmuje ale da się to jeszcze przeżyć – tak przynajmniej myślałem jeszcze miesiąc temu. Miarka przebrała się, gdy w ciągu ostatniego tygodnia czy dwóch Adobe wydało 3 wersje Playera, każda kolejna łamana w przeciągu kilku dni. Stwierdziłem w końcu, że mam dość zdalnej instalacji i czas wykorzystać funkcję atuo-aktualizacji, którą Adobe Flash Player przecież posiada.

Zacząłem nieco czytać i google’ować i oto do czego doszedłem. Aby update Adobe Flash Player sam aktualizował oprogramowanie na stacji musi być:

  1.  Folder C:\Windows\System32\Macromed\Flash (Windows x32) lub C:\Windows\SysWOW64\Macromed\Flash (Windows x64), w którym znajdują sie co najmniej dwa pliki:
    FlashPlayerUpdateService.exe
    oraz
    mms.cfg
    Zasada działania jest bardzo prosta: system odpala usługę z pliku .exe, która patrzy na plik konfiguracji (.cfg) i postępuje z instalacją lub nie. W pliku mms.cfg wystarczą dwie linijki tekstu:
    AutoUpdateDisable=0
    SilentAutoUpdateEnable=1
  2. Zadanie w harmonogramie zadań, które odpala usługę aktualizacji. Dla ułatwienia można stworzyć sobie przykładowe zadanie na jednej ze stacji, a następnie rozpowszechnić ją na innych stacjach poprzez funkcję Import/Eksport Harmonogramu Zadań.
    Trzeba pamiętać tylko o dwóch rzeczach:
    –  Akcja zadania będzie się różnić na x32 oraz x64 systemach – plik usługi jest gdzie indziej umiejscowiony.
    – Najlepiej, by zadanie było odpalane przez konto stacji, na której jest instalowana poprawka, czyli konto „SYSTEM”.
    Pozostałe ustawienia są w zasadzie bez znaczenia – możemy na przykład ustawić odpalanie usługi co godzinę każdego dnia. Adobe zapewnia, że usługa jest bardzo mało zasobożerna i zamyka się natychmiast po odpaleniu i sprawdzeniu dostępnych aktualizacji. Z moich obserwacji wynika, że tak faktycznie jest.

Zastanawiałem się też czy nie wyłączyć tego cholerstwa w ogóle albo nie zabezpieczyć się przed wykonywaniem niebezpiecznych skryptów przez wykorzystanie technologii „Click to play” ale niestety napotkałem opór ze strony biznesu. Jak zwykle zresztą.