RSS Feed

‘linux’ Category

  1. OpenVPN – No buffer space available (code=55)

    Maj 13, 2015 by 0verlord

    Klikam OpenVPNa dla klienta – musiał się podłączyć do bazy na hoście, ale że host był odfiltrowany od wszelkiego zła (tj. Internetu) trzeba było przepuścić ruch przez vpna.

    W skrócie dla niecierpliwych – taki komunikat oznacza, że wygenerowaliśmy pętlę routingu – np. że wypychamy do klienta (push) trasę do IP, która musi być dostępny normalnie, nie przez vpna – jeżeli serwer vpn ma ipka 1.2.3.4 a w konfigu OpenVPNa wypychamy trasę na ten ipek (push „route 1.2.3.4 255.255.255.0 192.168.1.1”) przez vpna, którego właśnie zestawiamy – tak się dzieje.
    Oczywiście to jest logiczne i naturalne, ale czasem ucieka w pogoni za Innym Lepszym Sensem i z powodu nadmiaru pracy.

    U mnie było tak, że początkowo baza stała na virtualce (konkretnie w LXC). Wtedy OpenVPN stał sobie na głównym hoście i pushował trasy do virtualki dla klientów. Prawie działało, bo ogólnie Firebird takich ustawień nie lubi z kilku powodów (opowieść na inną notkę). Natomiast wtedy OpenVPN się zestawiał.
    Szybka zmiana i „dostrojenie” konfiguracji i jak się okazało, wypchnąłem trasę na IP hosta, na którym stał OpenVPN. Stąd komunikat jak w temacie i ciągłe rekonekty i brak komunikacji.

    Czyli drogie dzieci – po takim komunikacie na kliencie, szukamy w konfigu, co to za jadowita trasa nam się wypycha, a nie powinna i w efekcie zapętla nam się routing.


  2. OTRS 2 i Magic number checking on storable string failed at blib/lib/Storable.pm

    Marzec 26, 2014 by 0verlord

    Dzisiaj króciutko o tym, jak naprawić błąd z tematu.
    OTRS to takie całkiem fajne narzędzie do zarządzania problemami, zgłoszeniami, czy innymi zdarzeniami. Alternatywy to np. Request Tracker, na którym jakiś czas temu (spory) działała infolinia Dialogu.
    Aktualna wersja OTRSa to bodajże 3.3, a niestety przyszło mi przywrócić „do celów archiwalnych” wersję 2.0.

    Na serwerze było zainstalowane Gentoo, w wersji -5 wstecz, php 5.2 i kilka innych fajnostek ;-). Po przegryzieniu się przez combo nginx+apache+mod_perl, dostawałem komunikat podobny do tego poniżej.

    Software error: Magic number checking on storable string failed at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 415, at ../..//Kernel/System/Cache/FileStorable.pm line 128
    

    Jak by zajrzeć do pliku FileStorable.pm, to w okolicach linijki 128 jest funkcja, która pokazuje wszystko co, co jest w cache, a co pasuje do zapytania.
    I WTEM! przypomniało mi się, że już kiedyś miałem podobny problem i rozwiązałem go tak samo, tj. kasując wszystko co jest plikiem w katalogu cache. Ponieważ na tym serwerze otrs był zainstalowany w /opt/otrs2,
    katalog z cache był w /opt/otrs2/var/tmp/.
    czyli krótkie:

    find /opt/otrs2/var/tmp -type -f -exec rm -f {} \; 
    

    i po problemie.


  3. Firebird, restore bazy i błąd „gbak: ERROR: could not find table/procedure for GRANT”

    Styczeń 22, 2014 by 0verlord

    Jeżeli przy odtwarzaniu bazy Firebirda dostajemy taki błąd jak w temacie, oznacza to, że nastąpiła korupcja 😉 . A dokładniej skorumpowała nam się baza security2.fdb.
    Jeżeli nie robiliście backupu, to trzeba sobie taką wypakować z instalatora i następnie dodać odpowiednich userów przy pomocy polecenia gsec.

    Log z próby
    gbak: restoring privilege for user SYSDBA
    gbak: ERROR:action cancelled by trigger (0) to preserve data integrity
    gbak: ERROR: could not find table/procedure for GRANT
    gbak: Exiting before completion due to errors


  4. Firebird fb_shash 1.0 – ściągnij stąd.

    Październik 21, 2013 by 0verlord

    Jest taki UDF do Firebirda, nazywa się jak w temacie, shash. Ale ostatnio zniknął z sajta producenta. Dlatego też możesz go ściągnąć stąd. Jest poczyszczony z objectów i binarek na tyle, ile miałem mocy przerobowych. Na zdrowie zatem.


  5. Diagnozowanie podstawowych problemów z wydajnością bazy Firebird

    Marzec 26, 2013 by 0verlord

    firebird logo

    O bazie Firebird już pisałem, konkretnie w tym poście, gdzie to jest wyjaśnione, po co należy robić gbak i odgbak (tj restore). A dzisiaj będzie o przypadku z życia i o tym, jak taki przypadek wyeliminować.

    Baza po jakimś czasie zaczęła zamulać. Proste zapytanie trwały nawet i kilkadziesiąt sekund. Przy okazji podstroiłem Apacha pod kątem wydajności, bo najpierw miałem niecne podejrzenie, że to właśnie tutaj jest problem. Po poprawkach w konfigu, firebird zaczął chodzić jakieś 30% szybciej, ale zamuła dalej była odczuwalna.

    Po konsultacji z mistrzami wymiataczami, został zarządzony gbak/restore bazy. Dla porządku, baza to Firebird SuperServer, w wersji 2.5.1, a wirtualizacja jest na LXC.

    Po restore, poprzednia prędkość bazy wróciła do normy, co kazało mi odświeżyć sobie info o poście, który wspominałem na początku wpisu. Jeżeli baza wróciła do siebie po restore, to znaczy, że nie zadziałało czyszczenie.

    W cronie regułka była – ale na wszelki wypadek ją odpaliłem z konsoli. Zapytała o usera i hasło do bazy… #fail.
    A to znaczyło, że sweep się nie wykonał, i baza nabrała rozmaitego śmiecia. Te śmieci wyczyścił gbak/restore. Co ciekawe, na innym serwerze mam dokładnie taką samą regułkę – i tam to działa (tak, sprawdziłem dzisiaj). Różnica jest tylko taka, że tam jest Classic, a na wirtualce SuperServer. Kocham takie niespójności…

    Przy okazji, taki problem można zdiagnozować szybciej, przy pomocy polecenia ‚gstat’.
    Na customowej instalacji z tarballa w Debianie, gstat jest tu: /opt/firebird/bin/gstat.
    Uruchamiamy go z parametrem -h i ścieżką do pliku bazy, np. tak:

    /opt/firebird/bin/gstat -h /var/db/bla.fdb

    Powinien pokazać coś podobnego do tego:


    Database "/var/db/bla.fdb"
    Database header page information:
    Flags 0
    Checksum 12345
    Generation 51183
    Page size 4096
    ODS version 11.2
    Oldest transaction 51141
    Oldest active 51142
    Oldest snapshot 51142
    Next transaction 51143
    Bumped transaction 1
    Sequence number 0
    Next attachment ID 104
    Implementation ID 19
    Shadow count 0
    Page buffers 21480
    Next header page 0
    Database dialect 3
    Creation date Mar 26, 2013 21:50:48
    Attributes

    Variable header data:
    Sweep interval: 0
    *END*

    Co nas interesuje z tej listy? Sweep interval – tutaj ustawiony na 0, czyli jak się można domyślić – jest wyłączony. Interesuje nas jeszcze ODS version (czyli on-disk structure), bo to pokazuje, która wersja bazy danych odczyta nasz plik z bazą. Na szczęście w przypadku pomylenia wersji, dostaniemy odpowiedni komunikat, że ODS jest niezgodny.
    Interesuje nas też konkretnie ta sekcja:
    Oldest transaction 51141
    Oldest active 51142
    Oldest snapshot 51142
    Next transaction 51143

    Tutaj mamy numerki, a żeby baza dobrze chodziła, różnica pomiędzy nimi nie może być większa niż 100, lub w innych manualach 200.
    Można to bardzo prosto sprawdzić – wystarczy przez jakiś czas nie włączać sweepa, potem go włączyć i zobaczyć.
    Z punktu wydajnościowego interesuje nas jeszcze parametr „Page buffers” – dla superservera z 4 GB ramu powinien być właśnie na takim poziomie jak u mnie. Ale np. w wersji Firebird Classic, wartość 5000 jest sensowna.

    Podsumowując,


  6. 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? 😉


  7. Debian testing, collectd, rrdtool plugin: rrd_update_r failed, minimum one second step i zatkane logi.

    Listopad 20, 2012 by 0verlord

    Ok, trafiłem bug w collectd, albo w Debianie testingu, albo w czymkolwiek. Chwilowo jestem za bardzo zarobiony, temat zgłębiać dokładniej. Za to umiem to naprawić ha! 🙂

    Ogólnie logi zapycha taki komunikat:

    Nov 20 21:52:21 baza collectd[7690]: rrdtool plugin: rrd_update_r (/var/lib/collectd/rrd/baza/df-root/df_complex-used.rrd) failed: /var/lib/collectd/rrd/baza/df-root/df_complex-used.rrd: illegal attempt to update using time 1353444741 when last update time is 1353444741 (minimum one second step)
    Nov 20 21:52:31 baza collectd[7690]: rrdtool plugin: rrd_update_r (/var/lib/collectd/rrd/baza/df-root/df_complex-free.rrd) failed: /var/lib/collectd/rrd/baza/df-root/df_complex-free.rrd: illegal attempt to update using time 1353444751 when last update time is 1353444751 (minimum one second step)
    Nov 20 21:52:31 baza collectd[7690]: rrdtool plugin: rrd_update_r (/var/lib/collectd/rrd/baza/df-root/df_complex-reserved.rrd) failed: /var/lib/collectd/rrd/baza/df-root/df_complex-reserved.rrd: illegal attempt to update using time 1353444751 when last update time is 1353444751 (minimum one second step)
    Nov 20 21:52:31 baza collectd[7690]: rrdtool plugin: rrd_update_r (/var/lib/collectd/rrd/baza/df-root/df_complex-used.rrd) failed: /var/lib/collectd/rrd/baza/df-root/df_complex-used.rrd: illegal attempt to update using time 1353444751 when last update time is 1353444751 (minimum one second step)

    Wygląda, jak by baza była za szybko odświeżana, stąd komunikat. Internet mówi, że takie coś często się dzieje, jeżeli chodzą dwie instancje collectd’a. Nie mój przypadek.

    Na co należy tutaj dokładnie popatrzeć, to plik z bazą rrd, który wskazuje na błędną konfigurację plugina sprawdzającego miejsce na dysku, tj. konkretniej defaultowy df.
    O co dokładnie chodzi? Ano o to, że plugin df sprawdza sobie /proc/mounts i co tam widzi w Debianie Testingu? Ano np. coś takiego:

    rootfs / rootfs rw 0 0
    (śmietnik)
    /dev/disk/by-uuid/(tutaj uid) / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
    (nieśmietnik)

    No więc plugin znajduje dwa razy „/” i aktualizuje zgodnie z planem. Aktualizacja jest za szybko, więc rrd zgłasza błąd.

    Jak to naprawić? Dodać konfig plugina wg instrukcji poniżej (bo defaultowo tenże plugin nie ma konfiguracji).
    Co to robi? Znajduje filesystem typu rootfs, po czym go ignoruje.

    <Plugin df>
    FSType "rootfs"
    IgnoreSelected true
    </Plugin>

    Tadam.{cokolwiek}.


  8. Debian Squeeze Apache i moduł suphp, który jednak działa

    Wrzesień 6, 2012 by 0verlord

    SuPHP to taki ładny wrapper poprawiający bezpieczeństwo serwera www, jeżeli gościmy na nim bandę dzikich skryptów a jeszcze dzikszych userów. Pozwala na uruchamianie skyptów php z takim uidem jak ma owner plików na serwerze. Proste, skuteczne. Oczywiście mniej wydajne niż php bez tego wynalazku, ale jak to zwykle bywa, jest to odwieczna walna: bezpieczeństwo kontra funcjonalność/wydajność.

    Jeżeli po instalacji modułu, skrypty dalej wykonują się z prawami usera www (np. w defaultowej instalacji: www-data) trzeba wyłączyć, powtarzam wyłączyć moduł php5. Restart apacza i działa.
    Niby to jest w dokumentacji i niby o tym czytałem, ale na działającym wcześniej serwerze, to mi już drugi raz umknęło i debugowałem jak ostatni baran :-/

    Zainstalować moduł:
    aptitude install libapache2-mod-suphp
    a2dismod php5
    a2enmod suphp
    /etc/init.d/apache2 restart

    A reszta to już manipulacja w konfigu:

    /etc/suphp/suphp.conf

    i czytanie loga w domyślnej lokalizacji:

    /var/log/suphp/suphp.log

    Sprawdzamy, umieszczając w katalogu, np. domowym public_html, np.taki „skrypt”.

    <?php system('/usr/bin/id'); ?>

    Efekt w przeglądarce powinien wyglądać jakoś tak:

    uid=1002(miszcz) gid=100(users) groups=1003(miszcz),4(mrocznaadministracja)

    Ku pamięci.

    EDIT: i oczywiście, jak już popełniłem posta, to znalazłem setkę tutoriali które mówią dokładnie to samo co ja teraz ;-). Odpowiedzią na źle zadane pytanie jest milczenie, po prostu.


  9. Linux-vserver, hit the barrier, reiserfs i jak to naprawić

    Sierpień 10, 2012 by 0verlord

    Linux-vserver zanim został uznany za przestarzały i zastąpiony containerami lxc był całkiem sensownym odpowiednikiem BSDowych jaili.
    W ostatnich wersjach z loopbackiem jest już całkiem używalny i pozwala na sensowną separację i zarządzanie zasobami dla rozmaitych usług.

    Tego posta piszę bardziej jako przypominajkę dla każdego, kto trafi na problem z filesystemem wewnątrz guesta, który objawia się losowymi problemami z dostępem, znikającymi plikami i urządzeniami i ogólnymi randomami w środku vservera.

    U mnie problemem okazała się interakcja reiserfsa i vservera. Kilka razy na dobę odlatywały różne części różnych guestów i ogólnie działy się złe rzeczy.

    Przyczyny i rozwiązania należy szukać na hoście. Dmesg najczęściej w takich przypadkach pokazywał, że plik, który akurat zniknął na gueście, jak to malowniczo określił mój kolega: „hitnął w barierkę”. Kawałek loga może wyglądać np. tak:

    [2053443.951267] vxW: [?ps?,12778:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.
    [2053445.370697] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d050980[#0,5] ?/dev/pts/2?.
    [2053445.370706] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d050980[#0,5] ?/dev/pts/2?.
    [2053445.371055] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.
    [2053445.371062] vxW: [?ps?,12801:#40052|40052|40052] did lookup hidden devpts:ffff88010d052600[#0,7] ?/dev/pts/4?.

    albo tak:

    808950.409850] vxW: [?ruby?,25311:#40052|40052|40052] did hit the barrier.
    [808950.409856] vxW: [?ruby?,25311:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808950.410268] vxW: [?ruby?,25311:#40052|40052|40052] did hit the barrier.
    [808950.410271] vxW: [?ruby?,25311:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808962.531726] vxW: [?ruby?,25807:#40052|40052|40052] did hit the barrier.
    [808962.531731] vxW: [?ruby?,25807:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.
    [808962.532145] vxW: [?ruby?,25807:#40052|40052|40052] did hit the barrier.
    [808962.532148] vxW: [?ruby?,25807:#40052|40052|40052] did lookup hidden md5:ffff88023dd97d90[#0,12536220] ?/usr/local/rvm/gems/ruby-1.9.3-p194/gems/mixlib-authentication-1.1.4/lib/mixlib/authentication?.

    W tym drugim przypadku kilka gemów przestało działać, wysadzając z ten sposób jedną z aplikacji railsowych. Poziom randomów powodował, że ilość hitów w google z błędami często spadała poniżej 1 (słownie: jednego) wyniku.

    Jak się okazało, jeżeli ma się reiserfsa, należy partycję, na której znajdują się fizycznie guesty zamontować z parametrem user_xattr. Tak to wygląda w moim fstabie:

    /dev/md5 /home reiserfs rw,user_xattr 0 0

    Dodajemy parametr w fstabie, wykonujemy mroczne zaklęcie:

    mount -o remount,rw,user_xattr /home

    (jeżeli nie pomoże, to rebootujemy hosta) i cieszymy się światem bez barrier ;-). A jak już nas spotka hit w barierę, to wykonujemy kolejne polecenie, które usuwa barierę.

    setattr -R --~barrier katalog/na/mainie

    A ogólnie,bariera to taki mechanizm niepozwalający na ucieczkę z guesta do innych zasobów. Można o tym dokładniej poczytać tu.


  10. backupninja, rdiff i ssh na innym porcie

    Lipiec 28, 2012 by 0verlord

    ninja z mieczem

    Backupninja, narzędzie do… backupu 😉 Jeżeli ktoś jeszcze nie zna, to polecam. Backupninja to taki podręczny zestaw dzikich skryptów, które zrobią za nas co trzeba. W sam raz na hosty, gdzie nie ma żadnej automatyki, a kopię by wypadało zrobić. No i się przy tym nie za bardzo napracować.

    Klika się to banalnie prosto, wystarczy uruchomić narzędzie, które nazywa się „ninjahelper” a następnie wybierać odpowiednie pozycje z menu.

    Generowanie właściwej konfiguracj jest banalnie proste – wybieramy katalogi które trzeba dodać (include=), potem te, których nie chcemy backupować (a jakże: exclude=), potem wybrać miejsce przeznaczenia (domyślnie – zdalny host) i kliknąć „test conn”, które nie robi nic innego jak testuje połączenie, generuje klucze ssh, dopisuje do authorized_keys itp. A jak wszystko działa, uruchamia rdiff-backup i przewala co trzeba i gdzie trzeba, czyli w tym przypadku nasze dane na serwer backupu.

    Ale co, jeżeli na hoście z backupem sshd wisi na dziwnym porcie (praktyka standardowa omijania skanów i bruteforcujących proste hasła botów) ?

    Piszę o tym, bo nie znalazłem w manualu rozwiązania – znalazłem je w kodzie. Interesująca nas sekcja konfiga wygląda tak:

    [dest]
    type = remote
    directory = /katalog/docelowy
    host = host_docelowy
    user = bekap
    sshoptions = -p 1234

    Ogólnie komentarz jest zbędny, konfig tłumaczy się sam. Ale znajdź pan „sshoptions” w którymś manualu :-P. Smacznego.