RSS Feed

Luty, 2013

  1. Avira unattended install i błąd 15 oraz 12

    Luty 16, 2013 by 0verlord

    avira logotyp

    Avira posiada przyjemnyprzyjemny tryb instalacji nienadzorowanej, czyli Avira Unattended Install. Uruchamia się odpowiedniego .execa z opcją /INF=ścieżka_do_pliku.inf, w konfigu podaje się ścieżkę do klucza licencyjnego i reszta dzieje się sama.

    W ogromnej większości przypadków instalator daje radę, ale od czasu do czasu nie ma ochoty się instalować i pluje do logów błędami.
    Zacznę na błędu 12. Tutaj akurat sprawa jest prawie trywialna, bo wystarczy uruchomić instalator, żeby zobaczyć przepiękne okienko mówiące o tym, że instalator nie ruszy wcześniej niż przed restartem. No to restartujemy. I działa.

    Błąd 15 jest trochę gorszy. Co ciekawe, mieliśmy z nim do czynienia tylko na Windowsach 7 Home. Wg supportu Aviry (a co, się kupuje licencję, to jest kogo atakować) ten numerek błędu oznacza „corrupted inf file”. Sprawdziliśmy – plik jest ok. Ma odpowiednie prawa dostepu – ma odpowiedniego właściciela. Ogólnie jego format jest poprawny, bo taki sam (patrząc na sumę md5) na Windowsie obok się odpala. Pierwsza linia supportu Aviry nie dała rady.

    Co mozna zrobić? Jedną z rzeczy, które nam pomogły, to wyłączenie tworzenia punktu przywracania systemu.
    UseSystemRestore=1

    Domyślnie ta wartość jest ustawiona na 1, co oznacza, że przy instalacji zostanie utworzony punkt przywracania systemu. Poniekąd słusznie. Jak by się coś złego stało, jest do czego wracać. Niestety wygląda na to, że na Windowsach 7 Home, tą opcję trzeba wyłączyć. Po zmianie rzeczonego wpisu na jakiś 80% przypadków instalator ruszył. Ale nie wszędzie.
    Jak się okazało, ten błąd to także inny objaw – tego, że Windows wymaga restartu. Może to nastąpić przy okazji instalacji aktualizacji, albo W Innych Przypadkach Wymagających Restartu. Koloryt lokalny Aviry. Ten problem rozwiązuje się sam przy kolejnym restarcie. Czyli jeżeli widzicie error 15 przy unattended installu – dwa restarty powinny ostatecznie załatwić sprawę.

    Logo AV ze strony producenta.


  2. Lex – aplikacja utraciła połączenie z zabezpieczeniem sieciowym i musi zostać ona zamknięta – jak naprawić

    Luty 14, 2013 by 0verlord

    Lex, aplikacja znana wszystkim prawnikom i nie tylko. Sprzedawana w modelu na ilość jednoczesnych dostępów. Zabezpieczenia, to sprzętowy klucz hasp z opcją sieciową, lub stanowiskowy. Zanim przejdę do omówienie przypadku, wyjaśnię ogólnie jak to działa.

    Lexa instaluje się jako udział sieciowy, i tak samo się go uruchamia. Przykładowo, mapujemy sobie na serwerze dysk L: do którego potem instalujemy aplikację, i potem ten sam dysk pozwalamy montować klientom. Klient odpala aplikację, aplikacja odpytuje sobie serwer klucza hasp, czy aby na pewno można klienta wpuścić i albo to robi – albo rzuca wyjątkiem o wykorzystanych wszystkich licencjach i rozłącza.

    Ale czasem dzieje się to, co jest w temacie tego posta. Wg supportu technicznego, który swoją drogą jest całkiem kompetentny – nastąpiła utrata łączności z serwerem klucza hasp. Tylko jak utraciło? O co w ogóle chodzi?

    W moim przypadku okazało się, że serwer czekał sobie na restart z powodu konieczności zainstalowania aktualizacji, a to z kolei powodowało wybuchy driverów, rozłączenie serwera klucza i inne „nieobsługiwane wyjątki krytyczne”.

    Sam restart serwera jednak nie pomógł – serwer klucza ciągle gubił połączenie. Przeinstalowałem te same drivery do haspa i problem ustąpił – widać coś się przy okazji aktualizacji pogubiło.
    Zato zanim przeklikałem drivery – regularnie o 6:30 rano uruchamiałem na serwerze skrypt restartujący usługę serwera hasp. Wyglądał jakoś tak (nie pamiętam jak się nazywa ten serwis, trzeba sobie samemu sprawdzić z cmd.
    sc stop <nazwa serwisu z sc list>
    sc start <nazwa serwisu>


  3. Firebird, gfix shutdown full, online i database shutdown

    Luty 9, 2013 by 0verlord

    Bardziej pisze tego posta ku pamięci własnej, a sytuację z Firebirdem miałem następującą:

    Firebird to taka baza, której od czasu do czasu trzeba zrobić backup i odtworzenie z niego bazy z kilku powodów:
    1. garbage collector przy backupie czyści fizycznie plik bazy ze zwolnionych stron, i z nieużywanego śmietnika – wtedy baza robi się mniejsza.
    2. jeżeli na bazie zachodzi sporo poprawek, może się okazać, że np. baza sobie chodzi, ale przy próbie jej odtworzenie dostaniemy konflikt np. na kluczach obcych, i może się okazać, że trzeba poprawiać ręcznie backup, żeby cokolwiek odtworzyć
    3. z jakiegoś dziwnego powodu, baza chodzi wydajniej po backupie/restore.

    Stąd też u klienta zaszła konieczność backup/restore bazy.
    Baza Firebirda na 4 tryby działania: normal, multi, single i full.
    Przełączanie się między nimi robi się przy pomocy gfixa i opcji -online i -shutdown. Żeby można było bez zgrzytu przegrywać sobie plik bazy, trzeba bazę przełączyć z tryb shutdown. I tak zrobiłem.
    gfix -shut fill -force 0 /plik/bazy.fdb
    Baza się zamknęła, połączenia teoretycznie zostały zakończone. Ubiłem fb_inet_servery (Firebird jest w wersji classic) i zdownowałem xinetd’a. Plik wrzuciłem na storage w stanie jakim był i chciałem zrobić gbaka. Baza po
    gfix -online normal /plik/bazy.fdb powiedziała, że baza jest shutdown. Que pasa? No więc po serii strace’ów okazało się, że wisi mi jeden proces fb_inet_server, który oparł się killallowi. Ubiłem go i baza wróciła.

    Potem znalazłem jeden post na serverfaulcie, z którego wynika, że takie rzeczy potrafią się dziać, jeżeli nie została zakończona jakaś transakcja. Ale dlaczego ta transakcja nie zareagowała na -online single a potem na -shut full ? Kto to wie.

    Czy ja już wspominałem, jak nie lubię firebirda? 😉