RSS Feed

Kwiecień, 2011

  1. Backupninja 0.9.8, backup mysqla w vserverze i bug

    Kwiecień 27, 2011 by 0verlord

    Objawia się tak: mamy sobie głównego hosta, i kilka guestów (vserverów). Na jednym z nich chodzi mysql. Dodajemy akcję do backupninja przy pomocy helpera, żeby nam robił dumpa wszystkich baz. Konfiguracja z ninjahelperem jest banalna, więc ją pominę. Error w debugu wygląda np. tak dla losowej bazy:
    Debug: su root -c "/usr/sbin/vserver mysql exec /usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names sugarcrm -r '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql'"
    Warning: mysqldump: Can't create/write to file '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql' (Errcode: 2)
    Warning: Failed to dump mysql databases sugarcrm

    Teraz ocb? Skrypt wykonujący backup, konkretnie ten (na Debianie):
    /usr/share/backupninja/mysql
    wydaje się nie zauważać, że wykonuje polecenie w środku vservera, więc nie ma tam katalogu podanego jako parametr do polecenia. To co widać powyżej, szuka katalogu
    /home/vservers/mysql/var/backups/mysql/sqldump
    ale w środku vservera, czyli jak byśmy zrobili na gueście katalog taki:
    /home/vservers/mysql/var/backups/mysql/sqldump
    widziany z poziomu maina jako
    /home/vservers/home/vservers/mysql/var/backups/mysql/sqldump
    to by się backup zrobił, ale szukać by go trzeba gdzie indziej.

    Jak to naprawić? Generalnie bez zagłębiania się w logikę kodu, i zdając sobie sprawę, że mogę popsuć coś innego, hackujemy sobie na szybko
    /usr/share/backupninja/mysql,
    linijka 287 i okolice.

    # Test to make sure mysqld is running, if it is not sqldump will not work
    $VSERVER $vsname exec su $user -c "$MYSQLADMIN $defaultsfile ping 2>&1 >/dev/null"
    if [ $? -ne 0 ]; then
    fatal "mysqld doesn't appear to be running!"
    fi
    if [ "$compress" == "yes" ]; then
    execstr="$VSERVER $vsname exec $DUMP | $GZIP $GZIP_OPTS > '$vroot$dumpdir/${db}.sql.gz'"
    else
    execstr="$VSERVER $vsname exec $DUMP -r '$vroot$dumpdir/${db}.sql'"
    fi
    else

    usuwamy ‚$vroot’ z linijek zaczynających się na execstr, i zostaje samo ‚$dumpdir’. czyli tutaj ‚/var/backups/mysql/sqldump’ czyli tak, jak ma być.
    I to wszystko. W ten sposób usuwamy /home/vservers z argumentu do vserver exec i już polecenie widzi odpowiedni katalog.

    Ciekawe, że nikt tego nie znalazł do tej pory, bo buga poprawiam drugi raz, pierwszy raz trafiłem go w Lenny’m i się pojawił po upgrade do Squeeze’a.


  2. Konfiguracja Nagiosa – dziedziczenie

    Kwiecień 18, 2011 by 0verlord

    W sumie, to takie HOWTO, ale nie HOWTO, bo jednak podstawową wiedzę o Nagiosie trzeba mieć, to taki esej o możliwościach konfiguracji Nagiosa. Tym razem będzie o dziedziczeniu i zmiennych.

    Po pierwsze: dziedziczenie.

    Nagios zapewnia całkiem ciekawe możliwości dziedziczenia. Każdy, kto zapoznał się z podstawami templatek (dyrektywa use), wie, że pomiędzy różnymi częściami konfiga można przekazywać wiele parametrów. Dokumentacja o tym nie wspomina, ale można je także nadpisywać. Na przykład:

    definiujemy templatkę ogólną hosta, nic szczególnego, żywcem wyjęta z dokumentacji:
    define host{
    name generic-host ; The name of this host template
    notifications_enabled 1 ; Host notifications are enabled
    event_handler_enabled 1 ; Host event handler is enabled
    flap_detection_enabled 1 ; Flap detection is enabled
    failure_prediction_enabled 1 ; Failure prediction is enabled
    process_perf_data 1 ; Process performance data
    retain_status_information 1 ; Retain status information across program restarts
    retain_nonstatus_information 1 ; Retain non-status information across program restarts
    check_command check_ping!120.0,15%!300.0,60%
    max_check_attempts 10
    notification_interval 0
    notification_period 24x7
    notification_options d,u,r
    contact_groups admins
    register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
    }

    a potem hosta:

    define host{
    use generic-host
    host_name mojhost.pl
    alias alias
    address 1.2.3.4
    parents gateway
    contact_groups admini,mroczniadmini
    }

    Ogólnie dokumentacja mówi o takich szablonach bardziej jako o sposobie, żeby nie w kółko nie pisać tych samych kawałków konfiga i tych samych dyrektyw. Ale sam mechanizm jest bardziej mroczny i przydatny. Jeżeli w templatce zdefiniujemy jakąś dyrektywę, ale jakiś host powinien mieć którąś opcję zdefiniowaną inaczej, można ją nadpisać. Na przykład tak:

    define host{
    use generic-host
    host_name mojhost.pl
    alias alias
    address 1.2.3.4
    parents gateway
    max_check_attempts 20
    contact_groups admini,mroczniadmini
    }

    W tym przypadku, nadpisujemy max_check_attempts. Gdybyśmy tego nie zdefiniowali, obiekt odziedziczyłby predefiniowaną wartość max_check_attempts 10 z definicji templatki (use generic-host.
    To jest proste, zapewne intuicyjnie wiele razy korzystaliście z takiego sposobu – teraz będziecie robić to świadomie ;-).

    Po drugie: zmienne.

    Ten mechanizm można także wykorzystać do przekazywania i nadpisywania zmiennych. W dokumentacji są to custom object variables.
    Poniżej opiszę, jak przekazać community snmp i jednocześnie zachować możliwość nadpisania go dla dowolnego hosta.

    Weźmy np. taką, uproszczoną do minimum, templatkę:
    define host {
    name generic-host
    register 0 # to templatka, więc 0
    _snmp_community blabla
    }

    i hosta wykorzystującego tą templatkę:

    define host {
    host_name testowy
    use generic-host
    _snmp_community bleble
    }

    I teraz, gdzie tutaj sztuczka magiczna?
    Ogólnie mamy dwa razy zdefiniowaną zmienną, _snmp_community (w Nagiosie każda wartość zaczynająca się od podkreślenia, _ to zmienna). Według zasad dziedziczenia ta, która została zdefiniowana ostatnia – wygrywa. Czyli nasz host ma ustawioną zmienną na bleble, a jeżeli nie nadpiszemy tej zmiennej – zostanie blabla. Ayt? 🙂 Tylko jak to teraz wstawić do definicji serwisu?

    Żeby uniknąć duplikacji zmiennych, Nagios automatycznie dodaje każdej prefix, w zależności od miejsca zdefiniowania. _HOST, _SERVICE i _CONTACT, czyli naszą zmienną _snmp_community, możemy w dowolnym innym miejscu konfiga odczytać jako $_HOSTSNMP_COMMUNITY$. Oczywiście trzeba uważać, żeby sobie tej zmiennej nie nadpisać w innym miejscu tej samej sekcji.

    Czyli teraz bierzemy definicję serwisu wykorzystującego community snmp, np. taką, i zamiast wpisywać do check_command po prostu community, wstawiamy tam naszą zmienną, np. tak jak w przykładzie poniżej:

    define service {
    host mojhost
    service_description snmp-uptime
    display_name SNMP System uptime
    check_command check_system_uptime!$_HOSTSNMP_COMMUNITY$
    use generic-service
    notification_interval 0 ;
    }

    W ten sposób ustawiamy community dla hosta tam, gdzie to wynika ze zdrowego rozsądku, tj. w definicji hosta, a serwisy już automagicznie biorą właściwą wartość.

    W następnych postach pokażę jeszcze kilka sztuczek optymalizacyjnych i organizacyjnych, np. jak optymalnie wykorzystać hostgroupsy.


  3. Neighbour table overflow – jak to naprawić

    Kwiecień 7, 2011 by 0verlord

    Dla niecierpliwych: do sysctl.conf lub innego odpowiednika wstawić następujące linijki:

    net.ipv4.neigh.default.gc_thresh1 = 4096
    net.ipv4.neigh.default.gc_thresh2 = 8192
    net.ipv4.neigh.default.gc_thresh3 = 8192
    net.ipv4.neigh.default.base_reachable_time = 86400
    net.ipv4.neigh.default.gc_stale_time = 86400

    i załadować:
    sysctl -p

    Dla bardziej cierpliwych: co to robi?
    gc_thresh* to limity wpisów w tablice arp w routerze.
    1 – oznacza limit wpisów w tablicę arp
    2 – „miękki” limit wpisów – jeżeli dojdzie do niego, kernel zacznie bardziej agresywnie czyścić tablicę arp
    3 – „twardy” limit – więcej nie bedzie – czytaj, host nie zostanie dopisany do tablicy i w związku z tym nie będzie do niego szedł ruch – czyli losowo zanikający net dla losowych komputerów może oznaczać problemy z przepełnieniem tablicy arp.


  4. Certyfikat SSL jeszcze nie ważny

    Kwiecień 1, 2011 by 0verlord

    już nie ważny, to rozumiem, natomiast jeżeli jeszcze nie jest ważny, należy sobie poprawić czas w systemie. Albo na serwerze.
    Bo może się np. zrobić taki offset przy korekcie:

    15 Aug 02:24:13 ntpdate[6750]: step time server 153.19.250.123 offset 335363401.428201 sec

    Data była ustawiona na 15 sierpnia roku 2000. 🙂 A wykryłem to przez padnięty openvpn, który tak bluzgał do loga:

    VERIFY ERROR: depth=1, error=certificate is not yet valid: /C=PL/ST=DL/L=WROC (ciach)