NetBSD

    Jak długo serwer był niedostępny?

    Po dzisiejszej wichurze, która spowodowała wyłączenie prądu w nocy, chciałem się dowiedzieć jak długo go nie było. Nie jest to takie trudne jeżeli w domu ma się serwer chodzący 24h na dobę i oprócz mierzenia uptime’u monitorujemy także downtime. O paczce downtime przy okazji dodania jej do pkgsr-wip pisałem jakiś czas temu.

    Pierwsze co nam będzie potrzebne to zainstalowanie paczki downtimed – http://dist.epipe.com/downtimed/. Używając pkgsrc paczka jest w wip/downtimed.

    Po wydaniu polecenia downtimes dostajemy listę przerw w działaniu serwera:

    crash 2015-04-01 00:48:28 -> up 2015-04-01 02:22:27 =    01:33:59 (5639 s)

    Do tego czasu w moim przypadku należy dodać 27 minut ponieważ tyle mi UPS podtrzymuje całą szafkę teletechniczną ze switchem serwerem i innymi urządzeniami.

    A teraz pobawmy się bardziej danymi z downtimed. Za pomocą jednego zgrabnego „one-line’ra” możemy przeliczyć jak długo nasz serwer „leżał”.

    downtimes | awk {'print $10'} | sed 's/^.//' | paste -sd+ - | bc | awk '{print $1/60}' | awk '{print $1/60}' | awk '{print $1/24}'

    Robimy co następuje powyższym poleceniem:

    1. Wywołujemy downtimes produkując kolumnę z odnotowanymi przerwami
    2. Wynik przekazujemy do awk, które pokazuje nam tylko 10 pole (pola liczymy co spację) – czyli liczbę sekund ile trwało wyłącznie serwera
    3. Kolumnę z sekundami (i początkowym nawiasem) przekazujemy do sed’a przy pomocy, którego kasujemy nawiaz z pierwszego znaku. Ściślej rzecz ujmują zamieniamy pierwszy znak w każdej linijce na nic, ostatecznie dostajemy kolumnę sekund
    4. Kolumnę z sekundami przekazujemy do polecenia paste z parametrem -sd+ co powoduje sklejenie kolumny w jeden string oddzielony znakami + (znak „-” za -sd+ jest wymagany przy używaniu BSD paste, przy GNU paste można bez -)
    5. Gotowy string który ma postać ciągu sekund oddzielonego plusami przekazujemy do kalkulatora bc, który wykona dodawani.
    6. Otrzymaną sumę liczby sekund dzielimy przy pomocy awk przez 60 otrzymując minuty
    7. Otrzymane minuty ponownie dzielimy przez 60 otrzymując godziny.
    8. Na koniec wynik w minutach dzielimy przez 24 otrzymując ilość dni , kiedy serwer był niedostępny.

    Powyższe polecenie na moim domowym serwerze daje wynik 7.74633 dnia, czyli ponad 7,5 dnia.

    Włóżmy ten wynik w jakiś kontekst, aby się przekonać czy to dobry wynik czy nie. Akurat przeciwieństwem downtimed jest uptimed (surprise, surpise!) , który mierzy czas działania serwera i kilka innych ciekawych rzeczy jak rekordowe uptime’y oraz jaki był w tym momencie zainstalowany system, a także sumaryczną ilość dni ile działał serwer. Przy okazji możemy sprawdzić czy nasze obliczenia przy pomocy downtimed sprawdzą się.

    Na dzień dzisiejszy uprecords (komenda do wywołania statystyk) u mnie wygląda tak:

    dom# uprecords
    #               Uptime | System                                     Boot up
    ----------------------------+---------------------------------------------------
    1   102 days, 14:03:21 | NetBSD 6.1.4_PATCH        Tue Jul  8 16:37:50 2014
    2    81 days, 05:59:55 | NetBSD 6.1.4_PATCH        Fri Apr 18 10:33:21 2014
    3    80 days, 01:40:20 | NetBSD 6.1.5_PATCH        Sat Jan 10 22:07:27 2015
    4    68 days, 12:05:30 | NetBSD 6.1.0_PATCH        Mon Sep  9 21:51:38 2013
    5    44 days, 23:30:13 | NetBSD 6.1.5_PATCH        Wed Nov 26 19:51:24 2014
    6    44 days, 07:09:29 | NetBSD 6.1.0_PATCH        Sat Dec  7 11:02:04 2013
    7    41 days, 14:10:24 | NetBSD 6.1.0_PATCH        Fri Jan 31 22:46:29 2014
    8    38 days, 16:54:02 | NetBSD 6.0.0_PATCH        Sun Nov 25 23:59:36 2012
    9    37 days, 20:55:24 | NetBSD 6.0.0_PATCH        Sat Jan 12 12:13:53 2013
    10    37 days, 14:33:08 | NetBSD 6.1.0_PATCH        Fri Jun 21 23:19:00 2013
    ----------------------------+---------------------------------------------------
    ->  23     6 days, 11:12:42 | NetBSD 6.1.5_PATCH        Wed Apr  1 02:27:59 2015
    ----------------------------+---------------------------------------------------
    1up in     2 days, 21:08:28 | at                        Fri Apr 10 10:49:08 2015
    t10 in    31 days, 03:20:27 | at                        Fri May  8 17:01:07 2015
    no1 in    96 days, 02:50:40 | at                        Sun Jul 12 16:31:20 2015
    up   876 days, 17:53:56 | since                     Sun Nov  4 00:02:44 2012
    down     7 days, 18:44:01 | since                     Sun Nov  4 00:02:44 2012
    %up               99.120 | since                     Sun Nov  4 00:02:44 2012

    Wg uptimed serwer na ponad 876 dni był nieosiągalny przez 7 dni i prawie 19 godzin, co stanowi SLA na poziomie 99.12% :) Całkiem nieźle jak na domowy serwer!

    Sprawdźmy jeszcze czy wyniki downtimed i uptimed nie róźnią się zbytnio, czyli czy 7 dni 18 godzin i 44 minuty to mniej więcej 7.74633. Ponownie przy pomocy bc konwertujemy tym razem godziny do systemu dzisiętnego.

    dom# echo "scale=5; 44/60" | bc
    .73333
    dom# echo .73333+7 | bc
    7.73333

    Całkiem blisko, ale jak blisko? :) Poraz trzeci użyjmy bc aby policzyć procentową różnicę między tymi wartościami:

    dom# bc
    scale=5
    7.74633-7.73333
    .01300
    7.74633+7.73333/2
    11.61299
    .01300/11.61299*100
    .11100

    Różnica 0.11% czyli w zasadzie pomijalna. Za to zabawa w konsoli przednia :)

     

     

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Ogólne

    Końcówka roku 2014 z kamerą samochodową

    Wszędzie teraz podsumowania roku, rzeczy najlepsze, najgorsze itd. Moje podsumowanie roku, a właściwie ostatnich miesięcy roku 2014  będzie miało dodatkowo wartość edukacyjną – jedź bezpiecznie!

    Jak wiadomo posiadanie kamery samochodowej przyciąga nieszczęśliwe i niebezpieczne sytuacje. Nie inaczej jest w moim przypadku. Co prawda, żadnej mega kraksy nie nagrałem całe szczęście, ale niebezpiecznych wyprzedzeń, czerwonych świateł, stłuczek, zwierząt na drodze podczas trzech miesięcy używania kamerki trochę było.

    Poniżej moja mała kompilacja z życzeniami wyobraźni i bezpieczeństwa na drodze w nowym roku!

     

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (2 votes cast)
    VN:F [1.9.22_1171]
    Rating: +1 (from 1 vote)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Gry/Games

    Dead Space – nadrabiam zaległości.

    Dawno dawno temu w 2008, EA wydało Dead Space. Nie aż tak dawno temu w Humble Bundle, bo zaledwie w 2013 nabyłem drogą kupna paczkę z Dead Space. A już teraz całkiem niedawno na przełomie 2014 i 2015 zaczynam nadrabiać tą siedmioletnią zaległość!

    Dodatkowo, ShadowPlay w paczce sterowników od GeForce’a całkiem fajnie działa dlatego od czasu do czasu na moim profilu w Twitch , możecie pooglądać jak mi idzie.

    Jestem po całych 40 minutach frustrującego ginięcia i w końcu umiem chyba w to grać. Potwory atakują, nie ma na razie żadnych niekomfortowych sytuacji, które zniechęcają do grania (Amnesia – patrzę na Ciebie). Zdrowa adrenalina od czasu do czasu jest wpompowywana do mózgu. Poniżej pierwszy raz kiedy nie opanowałem myszy. Tani chwyt gro, ale udany!

    Czego to ja jeszcze nie umiałem? Ach tak. Używanie „stasis” (zastój, hipostaza?). Tutorial mi zasugerował mi, że mogę spowolnić czas, a tak naprawdę mogę spowolnić czas danego przedmiotu. Dlatego  pierwsze podejście do używania zastoju wyglądało tak… (wstawcie tu dowolny mem z Picardem i facepalmem)

    Creme de la creme. Walka! Znowu tutorial i głos w radiu – oszczędzaj amunicję! No to oszdzędzałem, cały czas. Było trudno, ale dojście, walnięcie, odejście przy jednym potworku dawało rezultaty, przy trzech lub czterech ginąłem raz za razem. Po postrzeleniu w kończyny, już łatwiej a amunicji wcale nie tak mało. Przy którymś z kolei zgonie, w podpowiedziach na ekranie ładowania dowiedziałem się, że zastój działa także na potwory. Wyposażony w tą wiedzę w końcu mogę komfortowo grać dalej. Poniżej moment w którym nauczyłem się walczyć :)

    Jeżeli tak jak ja lubisz grać z dużym opóźnieniem w gry o uznanej renomie, bez czekania na kontynuacje, za przyzwoitą cenę (Mass Effect przeszedłem także w 2014 roku :) to zapraszam do odwiedzania mojego bloga. Od czasu do czasu zapostuję jakiegoś strucla, którego każdy już przeszedł ;)

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Ogólne

    NetBSD w OVH na dedykowanym serwerze

    OVH oferuje dedykowane serwery w przystępnych cenach, zwłaszcza z linii kimsufi. Przy okazji posiada ich tyle, że swego czasu zablokowali możliwość kupowania nowych, ponieważ klienci starszych maszyn nie przedłużali umów, tylko kupowali nowe maszyny za niższą cenę i z lepszymi parametrami.

    Nastał czas migracji jednej maszyny (Pentium III Xeon) z 2010 roku na nową (Core 2 Duo). I tu zaczynają się problemy, ponieważ w roku 2010 w OVH było coś takiego jak vKVM, czyli podłączone zasoby fizycznego serwera poprzez Qemu, z możliwością użycia dowolnego ISO i instalacji czego dusza zapragnie. Pomny takich możliwości, nowy serwer został zakupiony i przesiadka ze starego z funkcjonującym NetBSD i kilkoma usługami wydawał się banalna. Niestety OVH jakiś czas temu nie mówiąc nic nikomu zrezygnowała z vKVMa dając do dyspozycji dość szeroki wachlarz dystrybucji, niestety bez NetBSD.

    ovh1

    Muszę tu z uznaniem zauważyć, że od 2011 roku nie musiałem wchodzić do panelu zarządzającego, ponieważ system osiągnął imponujący uptime 1012 dni po czym padł mu zasilacz i musiał zostać wymieniony, tracąc cały uptime :)

         #               Uptime | System                                     Boot up
    ----------------------------+---------------------------------------------------
         1   1012 days, 07:06:5 | NetBSD 5.99.37            Thu Jul 21 08:36:46 2011
         2   216 days, 23:27:49 | NetBSD 5.99.37            Wed Dec  8 12:34:48 2010
         3    64 days, 16:47:53 | NetBSD 5.99.37            Sun Aug 15 20:59:35 2010
         4    30 days, 02:34:48 | NetBSD 5.99.37            Mon Nov  8 09:59:07 2010
         5    19 days, 20:31:45 | NetBSD 5.99.37            Tue Oct 19 14:18:21 2010
         6     7 days, 15:07:02 | NetBSD 5.99.37            Wed Jul 13 17:28:44 2011
         7     4 days, 05:54:32 | NetBSD 5.99.37            Wed Aug 11 14:31:49 2010
    ->   8     0 days, 00:03:21 | NetBSD 5.99.37            Tue Apr 29 09:02:03 2014
    ----------------------------+---------------------------------------------------
    1up in     4 days, 05:51:12 | at                        Sat May  3 14:56:35 2014
    no1 in   1012 days, 07:03:3 | at                        Sat Feb  4 15:08:55 2017
        up   1355 days, 19:34:0 | since                     Wed Aug 11 14:31:49 2010
      down     0 days, 22:59:33 | since                     Wed Aug 11 14:31:49 2010
       %up               99.929 | since                     Wed Aug 11 14:31:49 2010

    Wymiana zasilacza

    Oczywiście takie standardy jak Apache, MySQL, Postfix, Dovecot, BIND itp. można przenieść na dowolną instalację, ale jest zasadnicza różnica między przeniesieniem configów (dzięki bardzo poukładanemu filesystemowi NetBSD) a przeniesieniem i poprawieniem każdej jednej ścieżki. Dodatkowo czas gonił bo pierwszego maja stary serwer miał zostać wyłączony.

    Szczęśliwie OVH w razie padu systemu daje możliwość uruchomienia go w trybie rescue. Jest to tryb w którym system bootuje się z sieci, na maila dostajemy tymczasowe hasło roota, a wszystkie slice’y/partycje możemy sobie podmontować i sprawdzić co tam nie gra, względnie przenieść gdzieś dane i zaorać stary system nowym z listy.

    System rescue jest wystarczający do zainstalowania jakiegokolwiek innego systemu z ISO wg. własnych potrzeb. W przypadku *BSD mamy właściwie dwa sposoby. Pierwszy to odpalenie rescue w trybie freebsd (musi być zainstalowany najpierw jakiś FreeBSD z listy). W tym trybie dostajemy dostęp do partycji na obydwóch dyskach fizycznych z obsługą FFS2. Po założeniu partycji FFS i rozpakowaniu setów z ISO NetBSD (można użyć drugi dysk jako tymczasowe miejsce na ściągnięcie setów, ponieważ rescu jest w trybie do odczytu tylko), właściwie mamy działający system. Pozostaje kwestia bootloadera, którego z FreeBSD nie zainsytlujemy. FreeBSD nie ma binarnej kompatybilności z NetBSD (w drugą stronę taka kompatybilność istnieje).

    Niesprawdzony sposób to zrzucenie z innego NetBSD pierwszych 446 bajtów z bootowalnego dysku.

    dd if=/dev/wd0d of=/tmp/netbsd_boot.dump bs=446 count=1

    Dlaczego 446? Dlatego, że po wgraniu na inny dysk będzie tam tylko kod rozruchowy. Zrzucenie 512 bajtów zrzuca cały disklabel, który kiedy nie jest identyczny spowoduje sieczkę na dysku.

    dd if=/tmp/netbsd_boot.dump of=/dev/ada0s1 bs=446 count=1

    To powinno po restarcie poprawnie wybootować NetBSD z pierwszego dysku . Oczywiście trzeba pobawić się w „ślepą inżynierię” aby wykryć wszystkie urządzenia, nazwy interfejsów sieciowych i po ponownym wybootowaniu w trybie rescue, odpowiednio wyedytować pliki konfiguracyjne. Ja używałem do tego prostych skryptów uruchamianych z rc.local lub z crona po wybootowaniu i wpisujących wynik do pliku, np:

    @reboot         dmesg >> /root/dmesg.txt

    Drugim sposobem jest instalacja z ISO przy pomocy Qemu. W tym celu uruchamiamy rescue linuksowe. Jest to jakis zmodyfikowany Debian. Jeżeli dysponujemy ilością RAM około 4GB możemy sobie system przerzucić do RAMu i dodatkowo mieć ISO w RAM.

    mount -t tmpfs -o size=4000m tmpfs /mnt
    mkdir /mnt/var
     mkdir /mnt/var/cache
     mkdir /mnt/var/lib
     mkdir /mnt/var/run
     mkdir /mnt/usr
     mkdir /mnt/lib
    rsync -a /var/cache/ /mnt/var/cache/
     rsync -a /var/lib/ /mnt/var/lib/
     rsync -a /var/run/ /mnt/var/run/
     rsync -a /usr/ /mnt/usr/
     rsync -a /lib/ /mnt/lib/

    rsync chwilę potrwa.

    mount -B /mnt/var/cache /var/cache
     mount -B /mnt/var/lib /var/lib
     mount -B /mnt/var/run /var/run
     mount -B /mnt/usr /usr

    Voila! Mamy Linuxa w ramie w trybie RW.

    Ściągamy teraz najnowsze dostępne ISO gdzieś do /mnt

    cd /mnt && ftp -a ftp://ftp.fr.netbsd.org/pub/NetBSD/iso/6.1.4/NetBSD-6.1.4-amd64.iso
     (albo wget ftp://ftp.fr.netbsd.org/pub/NetBSD/iso/6.1.4/NetBSD-6.1.4-amd64.iso)

    Potrzebujemy jeszcze Qemu

    apt-get update
     apt-get install qemu

    Fajne jest to że OVH ma swój mirror repozytorium Debiana więc idzie to szybko. Dodatkowo serwer ftp NetBSD we francji chyba także jest w OVH :)

    2014-04-29 19:55:36 (10.8 MB/s) – `NetBSD-6.1.4-amd64.iso’ saved [347023360]

    Przygotowania skończone, uruchamiamy Qemu ze ściągniętym ISO i dyskiem fizycznym jako pierwszy dysk twardy:

    qemu-system-x86_64 -net nic -net user -m 1G -alt-grab -localtime  -k en-us -cdrom \
     /mnt/NetBSD-6.1.4-amd64.iso -hda /dev/sda  -vnc :0

    Jeżeli nie dostaniemy żadnych błędów w konsoli, znaczy się, że działa i możemy się zalogować na nasz IP w OVH przez VNC. Jeżeli instalujemy system 32 bitowy zamiast qemu-system-x86_64 uruchamiamy po prostu qemu.

    NetBSD bootuje się w OVH

    Instalacja NetBSD przez VNC

    Należy przeprowadzić standardową instalację, i wstępnie skonfigurować system do działania. Można np. spróbować skonfigurować wszystkie podstawowe karty sieciowe (wm,bge0,fxp0,re0 itp.), jeżeli trafimy w tą właściwą to po restarcie z dysku NetBSD powinien zacząć odpowiadać na ping. Oczywiście trzeba otworzyć ssh, dodać użytkownika albo pozwolić rootowi się logować. Mi udało się dostać do systemu za drugim podejściem. Pierwszy raz zrobiłem literówkę w bramie :) Ustawienia sieciowe oczywiście bierzemy z systemu rescue, są identyczne z normalnym systemem. W przypadku droższych serwerów może być jeszcze potrzeba zmiany w fstabie z emulowanego wd0 na rzeczywisty sd0. W moim przypadku, jako że serwer posiada dyski SATA, zarówno w Qemu jak i fizycznym NetBSD dyski widniały jako wd0.

    No i to tyle. Powyższy sposób z Qemu może być stosowany do każdego ISO, np. Windows Server czy dowolnej dystrybucji Linuksa. Do Windows 7 lub 2008 trzeba doinstalować jeszcze kvm (apt-get install kvm)

    Przy okazji na koniec mała dygresja, o tym jak szybko rynek reaguje na takie zmiany i braki jak zrezygnowanie z vKVM. Szukając informacji i materiałów odnoście tego zagadnienia natrafiłem na kilka stron które w przedziale 20$-35$ oferują instalację dowolnego lub z innej listy systemu operacyjnego – głównie Windows. Przykłady:

    http://winstaller.org/

    https://www.pozzo-balbi.com/products/custom-installation.

    A u mnie macie za darmo i po polsku ;)

    Podziękowania dla morr‚a za pomoc przy pierwszych próbach z instalacją bez Qemu :)

    BONUS: porównanie dmesga z maszyny w Qemu i fizycznego serwera po instalacji – http://maciejewski.org/temp/dmes_ovh_qemu_i_bm.txt

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
    Windows

    Windows 7 on boot partition larger than 2 TB on RAID 5

    Well, that took me a while to setup correctly so it’s worth to mention it here.

    My setup was 4x 1TB SATA disk on RAID 5 which is almost 3TB space. If You want to create one large partition and be able to boot from it Windows 7 – here is how:

    You will need – UEFI mainboard with option to boot from UEFI: DVD, Windows 7 64 bit. Now:

    1. Create Volume in RAID BIOS
    2. Boot from UEFI: DVD (not BIOS DVD) Windows 7
    3. Select Custom
    4. On screen with Your huge empty space press SHIFT + F10 – cmd.exe will pop up
    5. type diskpart
    6. type list disk and identify your huge empty space number
    7. type select disk 0 (or other number that You identify as Your Volume)
    8. type clean
    9. type convert gpt
    10. type exit
    11. type exit once again to close cmd.exe window
    12. click refresh
    13. Chose Your volume and follow installation as usual.

    After installation, Windows should boot on <2TB Volume with no problem.

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    In English

    Kill It! (UNIX way)

    I’ve got heavy load on one box. What is strange it operate normally, despite this load:

    load averages: 153.11, 152.41, 150.74
    866 processes: 150 runnable, 712 sleeping, 4 on CPU

    This ~720 processes ware snmpd in some strange loop of checking if snmpd is working.

    I can’t kill it globally witk pkill , but kill -9 PID works. I don’t want to manually type 720 pids and don’t want to restart machine, so here comes unix way to kill 720 processess:

    ps uax | grep snmpd | awk '{print $2}' | xargs kill -9

    Results?

    load averages: 0.04, 10.8, 59.5
    98 processes: 95 sleeping, 3 on CPU

    Back to normal state!

    Mondays… ;)

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Fun

    One line to know where your users are on vacation :) (if they use company mail on vacation)

    Assuming You use dovecot 2.x and stores logs in /var/log/maillog:

    cat /var/log/maillog | grep Login: | awk '{print $10}' | sed 's/rip=//g' | sed 's/,//g' >> /tmp/1.txt && sh -c 'for line in `cat /tmp/1.txt`; do geoiplookup $line; done' | sort | uniq | awk '{print $4 $5}'

    gives You unique locations of every user login. You can also grep for specific login instead of all of them :)

    If You are not rotating Your logs it will take some time to return results.

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: +1 (from 1 vote)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Job / Praca

    Hylafax i wiele modemów oraz róźni odbiorcy.

    Mój system faksowy rozrasta się, aktualnie obsługuje 5 numerów a w planach są kolejne dwa. Jak na razie w dwa miesiące odebrał ponad 1500 faksów i działa bez zarzutu.

    Dokładając modemy oczywiście modyfikacji uległ plik z konfiguracjami FaxDispatch i skrypty konstruujące maile z faksami w formacie png.

    Skrypt z tego wpisu teraz jest w osobnych plikach, każdy dla innego numeru. Każdy z tych skryptów wykorzystuje też osobny katalog tymczasowy (/tmp/faxX) aby w przypadku odbierania faksów jednocześnie pliki z obrazkami nie pomieszały się, lub nie zostały nadpisane. Eksportowanie zmiennych $SENDER i $FILE jest także uzupełnione o kolejny numer aby nie było niejasności i błędów w dostarczeniu.

    Teraz najciekawsza zmiana – instrukcja CASE w pliku FaxDispatch.
    FILETYPE=pdf;
    SENDTO=fax_pdf@***.pl;
    TEMPLATE=pl;
    case "$DEVICE" in
    tty00)  echo $FILE > /tmp/FILE; echo $SENDER > /tmp/SENDER; /tmp/convertmime.sh;         SENDTO=fax_pdf@***.pl;;
    ttyU0)  echo $FILE > /tmp/FILE2; echo $SENDER > /tmp/SENDER2; /tmp/convertmime2.sh;      SENDTO=;;
    ttyU1)  echo $FILE > /tmp/FILE3; echo $SENDER > /tmp/SENDER3; /tmp/convertmime3.sh;      SENDTO=;;
    ttyU2)  echo $FILE > /tmp/FILE4; echo $SENDER > /tmp/SENDER4; /tmp/convertmime4.sh;      SENDTO=;;
    ttyU3)  echo $FILE > /tmp/FILE5; echo $SENDER > /tmp/SENDER5; /tmp/convertmime5.sh;      SENDTO=;;
    esac

    Pierwsze 3 linijki to standardowa konfiguracja jeśli nie zachodzi żaden CASE, co właściwie nie powinno się zdarzyć, ale w razie jakby co (np nieoczekiwana zmiana nazwy portu) fax zostanie dostarczony na mail fax_pdf@**.pl jako pdf.

    Następnie CASE działający na zmiennej $DEVICE, która odpowiada portowi RS232 w NetBSD. Każdy CASE wyrzuca nazwe pliku oraz nadawce do właściwego pliku, z którego później korzysta convertmimeX.sh do skonstruowania maila. Dodatkowo modem na tty00 oprócz dostarczenia faksu w formie obrazka wysyła ten sam faks w formacie pdf.

    System działa bardzo stabilnie, duże znaczenie ma zapewne jakość modemów oraz użytych przejściówek USB-RS232. W moim przypadku kable USB wpięte obok siebie, blokowały losowo któryś modem. Kiedy wpięte są co drugi port USB wolny – wszystko działa bez zakłóceń.

    Na razie półka modemowa wygląda jak na zdjęciu poniżej, ale kiedy dojdą dodatkowe dwa modemy trzeba będzie pomyśleć o ładniejszej organizacji :)

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Ogólne

    The Rocky Road To Raspberry Pi

    (Przepraszam wszystkich fanów piłki nożnej za mylący tytuł, ale SEO FTW! Sorry ;) Jeżeli lubicie blogi techniczne  to możecie czytać dalej ;)

    Zatem, stało się, po prawie trzech miesiącach i ciągłym odkładaniach terminu dostawy – wczoraj przybyła paczka z moim Raspberry Pi ! Historię mojego oczekiwania najlepiej obrazuje screen z Thunderbirda z korespondencją od firmy Farnell z której to paczka dzisiaj dotarła.

    RPI faktycznie jest nie wielkich rozmiarów, jeżeli by był bardziej płaski z powodzeniem mieściłby się do przegródki w portfelu pomiędzy kartami bankomatowymi.

    Teraz pozostało skompletowanie pozostałego wyposażenia – karty SD, i przejścia z HDMI na VGA lub DVI. Zasilacz już mam (ładowarka od komórki microUSB :)

    O kolejnych postępach i osiągach na pewno poinformuję :)

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    Job / Praca

    Administrowanie może być ładne i wygodne!

    Szukając alternatywy dla SNORT + BASE natrafiłem na SNORBY. Snorby to tak samo jak Base frontend dla Snorta, z tym, że napisany w rubym i jest po prostu ładny. Wszystko się kręci, przyciemnia, przelatuje z jedno w drugie, dodatkowo ma kilka fajnych funkcji jak generowanie raportów pdf czy wysyłanie powiadomień mailem.

    Co mnie szczególnie zaskoczyło to instalacja, faktycznie (przynajmniej na NetBSD) przebiegła tak jak jest pokazana w kilku krokach na stronie Snorbyego. Klonujemy najnowszą wersję przy pomocy gita, edytujemy podstawowe informacje i dostęp do bazy MySQL, uruchamiamy server na porcie 3000 – gotowe :)

    Oczywiście trzeba dosintalować bardzo dużo składników samego rubiego (to się chyba naywa „gems” ? – nigdy nie miałem do czynienia z rubym :), część znajduje się w pkgsrc, część ruby sam doinstaluje przez wydanie komendy „bundle install”. w katalogu ze snorbym.

    Jedyna rzecz, którą musiałem poprawić ręcznie to zrobić dowiązanie z /usr/pkg/bin/ruby193 do /usr/pkg/bin/ruby ponieważ bez tego snorby mówił że nie wie gdzie jest ruby i nie mógł odpalić „workera”, który co jakiś czas zbiera informację z bazy i aktualizuje dashboard.

    Co do snorta, to konfiguracja łącząca go ze snorbym jest banalnie prosta. Trzeba tylko dodać w konfigu, aby oprócz zapisywania do pliku lub bazy danych, zapisywał też do bazy snorbiego :) To wszystko.

    Po chwili w zależności jakie reguły mamy zainstalowane i co snort nałapie, wszystko powinno być ładnie odwzorowane w snorbym, gdzie już można wygodnie sobie przegladać raporty, zerkać do środka ramek, sprawdzać czy jakiś host nie za bardzo nam bruździ itp.

    Porównując czystą instalację snorta i logowanie do plików a wizualizację przy pomocy Snorbiego właściwie nie ma co porównywać :)

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    Related Posts with Thumbnails
    Add your widget here