RSS Feed

Posts Tagged ‘konfig’

  1. LMS i parser.so #2

    Marzec 25, 2011 by 0verlord

    A jednak da się w, nazwijmy to, LMS WAY (TM). Parser.so, jak donosi dokumentacja, ma kilka stałych, dla których nie potrzeba generować zapytania. Są to odpowiednio tablice CUSTOMERS, NODES i NETWORKS ze zdefiniowaną listą pól.
    Czyli zamiast
    { result = zapytanie }
    Można od razu przejść do właściwego efektu zapytania, np. zapytanie z poprzedniej notki może wyglądać tak:
    {for (r=0; r<number(NODES); r++)}\
    # {NODES[r].owner}:{NODES[r].ownerid}
    {NODES[r].mac}-{NODES[r].ip}
    {/for}\

    Tylko w wersji 1.11.11 nie wiedzieć czemu, predefiniowane zapytanie jest generowane błędnie, trzeba czekać na deweloperów, albo poprawić sobie samemu w pliku:
    modules/parser/extensions/sql.h

    i przekompilować demona. W 1.11.12 to też nie działa, ale na forum już jest zgłoszony bug, może w cvsie nafixują.

    Jeżeli ktokolwiek ma wątpliwości, dlaczego lepiej stosować rozwiązania natywne a nie swoje własne zapytania, odpowiedź nasuwa się sama – w przypadku fuckupa przy upgrade do kolejnej wersji, będzie można na forum obsobaczyć developerów 😉 A tak, przy próbie zgłoszenia buga ojebią nas, bo komu by się chciało ogarniać cudze selecty.

    A tak bardziej serio, przy usunięciu wszystkich nienatywnych rozwiązań z LMSa, przed aktualizacją trzeba tylko czytać changeloga, a nie czekać na kogoś, kto nam poprawi zamotkę w zapytaniach. Przejęcie po kimś rozwiązania natywnego jest dużo prostsze w ogarnięciu, bo chociażby można poczytać dokumentację żeby skumać jak to działa, a nie się habilitować z zawartości cudzych zakrętów w mózgu.

    Po to ludzie piszą narzędzia, żeby inni mogli a nich korzystać, a nie – psia mać – koło od nowa wymyślać. Dość jęczenia [:


  2. LMS i parser.so

    Marzec 25, 2011 by 0verlord

    Dzisiaj będzie o LMSie i jednej ciekawostce, którą trafiłem ostatnio.

    Demon LMSa (lmsd) ma taki ciekawy moduł, nazywa się parser.so. Przy odrobinie samozaparcia i przeczytania dokumentacji, da się generować z bazy różności przy wykorzystaniu czegoś, co się nazywa Tscript. Język jak język, trzeba się nauczyć.

    No i przy okazji upgrade z 1.10 do 1.11, odziedziczyłem generatory adresów mac z bazy. Wyglądały mrocznie, joiny, left joiny, inner joiny, ograniczenia do networków zaszyte w selectach, ogólnie porażka. Nie wiem, czy w 1.10 nie działały takie rzeczy jak lms-makemacs, ale jeżeli tak, to ten, kto klikał LMSa wtedy ewidentnie chciał się popisać umiejętnością składania nikomu do niczego nie potrzebnych zapytań SQLa. Cóż, można i tak.

    Chwilowo musiałem wykorzystać tamte skrypty, więc trzeba było wygenerować listę maców do skryptu odpalającego regułki filtrów.
    Ostatecznie zapytanie wyglądało tak:

    SELECT INET_NTOA(ipaddr) AS ip, mac, name FROM macs LEFT JOIN nodes ON nodeid = nodes.id

    LMSd generował pusty plik, a debug mówił, że się wydupca na linijce z zapytaniem. Usuwając ‚AS ip’ pomagał o tyle, że zapytanie nie pluło błędem, natomiast kolumna nie nazywała się IP, więc dalsza część skryptu jej nie łapała.

    Szybki debug innych LMsów pokazał, że mam podobne zapytania z klauzulami AS cośtam, tyle, że nie są one na pierwszej pozycji zaraz za selectem. No to zmieniłem zapytanie na
    SELECT mac, INET_NTOA(ipaddr) AS ip

    i wygenerowało mi przepiękny plik.
    Parser.so ty wuju ;->


  3. automatyczne generowanie podobnych wpisów w pliku strefy w bind9

    Grudzień 16, 2010 by 0verlord

    Jeżeli generujemy dużo wpisów dla wielu klas, a nie mamy jakoś ochoty na pisanie skryptów typu np.:

    for i in seq 2 254`; do 'echo $i IN PTR rev dla klasa.$i.' >> plik_strefy; done
    

    Można użyć sprytnej dyrektywy $GENERATE. Tak, jest o niej napisane w dokumentacji, ale dokumentacja to przecież ostatnie miejsce gdzie się takich rzeczy szuka prawda?

    Plik strefy wygląda wtedy tak:

    $TTL 21600      ; 6 hours
    @       IN      SOA     ns1.host.net.pl. root.host.net.pl.     (
                                    2010121601     ;serial
                                    3600           ;refresh
                                    900            ;retry
                                    3600000        ;expire
                                    3600           ;minimum
                                    )
    
            IN      NS      ns1.host.net.pl.
            IN      NS      ns2.host.net.pl.
    
    1       IN      PTR     gw-1.2.3.host.net.pl.
    $GENERATE 2-254 $ IN PTR ip-1.2.3.$-host.net.pl.
    255     IN      PTR     nobodyshere.host.net.pl.
    

    Interesujące są dopiero wpisy poniżej IN NS. Taki krótki plik strefy odpowiada na każde zapytanie o reva dla klasy 3.2.1.in-addr.arpa.
    Oczywiście można robić różne zakresy, np.

    $GENERATE 100-200 $ IN PTR ip-1.2.3.$-host.net.pl.
    

    Powyższy wpis wygeneruje rewy dla adresów od 1.2.3.100 do 1.2.3.200.
    Małe – a cieszy.

    Tej dyrektywy można też używać w standardowym pliku strefy, nie tylko w dla revów.