Posts Tagged Linux

Wyświetlenie zawartości pliku od końca

Sie 6

Posted by Łukasz Stelmach in Linux | Comments off

Ostatnio zapragnąłem obejrzeć sobie zawartość z plikiem logu serwera Apache. Cel był następujący:

  • wybrać tylko określone linie przy użyciu polecenia grep
  • wyświetlić 20 ostatnich linii
  • wyświetlić je od końca, tak aby linie które pojawiają się na końcu były wyświetlane jako pierwsze

Dwa pierwsze punkty w realizacji są proste:

grep 'GET / ' access.log | tail -n 20

Teraz pozostaje odwrócić kolejność linii. Pierwsze moje skojarzenie to polecenie sort z przełącznikiem -r, czyli coś takiego:

grep 'GET / ' access.log | tail -n 20 | sort -r

Niestety, to nie zadziała. Dostaniemy nie odwróconą zawartość pliku, ale po prostu posortowany plik od wartości największej do najmniejszej.

Więc pozostaje dodanie numeracji do pliku (polecenie cut -n i posortowanie zawartości:

grep 'GET / ' access.log | tail -n 20 | cat -n | sort -rn

Efekt tym razem odpowiedni, ale jeszcze zostały dodatkowe linie z numeracją, można je usunąć za pomocą polecenia cut:

grep 'GET / ' access.log | tail -n 20 | cat -n | sort -rn | cut -f 2-

I koniec końców efekt jest zgodny z oczekiwaniami.

Przeglądając jeszcze dokumentację do polecenia cat zauważyłem jeszcze jedną komendę: tac, która działa jako odwrotność polecenia cat. Używając tej komendy, skrypt będzie wyglądał następująco:

grep 'GET / ' access.log | tail -n 20 | tac

I po sprawie :). Morał: warto czytać strony MAN, można zaoszczędzić sporo czasu, pisania i mocy maszyny.

Źródła

Tags: , , , , ,

Automatyczna kompilacja pliku LaTeX, czyli o monitorowaniu zmian w plikach

Lip 14

Posted by Łukasz Stelmach in LaTeX, Linux | Comments off

Spotkałem się z następującym problemem: w momencie wykonania modyfikacji pewnych plików lub katalogów chciałem wykonać określoną akcję. W moim przypadku chodzi o automatyczne utworzenie pliku PDF na podstawie plików źródłowych stworzonych w LaTeXu.

W przypadku Linuksa mamy do dyspozycji podsystem jądra o nazwie inotify, który pozwala na powiadamianie aplikacji o różnych zmianach mających miejsce w ramach systemu plików. Ponieważ jest to moduł pracujący w przestrzeni jądra systemu, nie ma potrzeby skanowania systemu plików w celu poszukiwania zmian. Wystarczy jedynie zarejestrować aplikację, podać jakie zdarzenia i pliki (czy też katalogi) mają być monitorowane i o resztę będzie się troszczyć sam systemu operacyjny.

Oczywiście, to że jądro udostępnia jakąś usługę i istnieją odpowiednie biblioteki systemowe nie rozwiązuje problemu (chyba że piszemy własną aplikację). Znalazłem dwie aplikacje, które działają w przestrzeni użytkownika i pozwalają na wykorzystanie inotify:

  • incron – narzędzie to przypomina trochę crona, do działania wymaga zainstalowanego serwera oraz klienta w którym będzie można definiować reguły monitorowania i postępowania z plikami, pozwala ono na zdefiniowanie zarówno co ma być monitorowane o raz jakie akcje (np. jakie skrypty uruchomić) w momencie wykrycia zmian w systemie plików
  • inotify-tools – dwa polecenie, z których jedno pozwoli wyświetlić informacje statystyczne o modyfikacjach w systemie plików (inotifywatch), a drugie wyświetli informacje o zmodyfikowanych plikach (inotifywait)

W moim przypadku incron jest za dużym rozwiązaniem, nie potrzebują także ciągłego monitorowania wybranych katalogów, jedynie na czas pracy z LaTeXem. Idealnym rozwiązaniem okazało się użycie polecenia inotifywait. Nasłuchuje ono na zamiany w wybranych plikach czy katalogach i w momencie ich wystąpienia kończy swoje działanie jednocześnie wyświetlając informacje o tym, co zostało zmienione. Posiada także możliwość pracy w trybie ciągłego nasłuchiwania, czyli informuje nas o zmianach bez kończenia działania, ale tutaj funkcja ta nie będzie potrzebna.

Więc czas na konkrety: instalacja pakietu w Ubuntu:

# aptitude install inotify-tools

Teraz czas na mały skrypt, który będzie odpowiedzialny za uruchomienie nasłuchiwania oraz wykonywanie odpowiednich poleceń:

1
2
3
4
5
6
7
8
9
#!/bin/bash

MONITOR_COMMAND="inotifywait -q -e modify  --format '%w%f' --excludei '.*temp.*' ."

while true
do
        OUTPUT=`$MONITOR_COMMAND` && \
                pdflatex -output-directory=out main.tex
done;

Skrypt robi:

  • linia 3 – definicja wywoływania polecenia inotifywait:
    • -q – tryb cichy, nie wyświetla zbędnych informacji
    • -e modify – lista monitorowanych zdarzeń na plikach, tutaj tylko modyfikacja plików, ale można monitorować np. dostęp do nich, tworzenie, usuwanie, przenoszenie, zmiany metadanych
    • --format '%w%f' – format, w jakim ma być wyświetlona informacje o tym co się zmieniło, w tym przypadku nazwa pliku wraz z katalogiem, w którym się on znajduje
    • --excludei '.*temp.*' – jakich plików nie brać pod uwagę
  • linia 5 – rozpoczęcie pętli, nieskończonej
  • linia 7 – wywołanie polecenia inotifywait, polecenie to skończy działanie dopiero jak wykryje jakieś zmiany w monitorowanych plikach
  • linia 8 – wywołanie akcji, w moim przypadku kompilacja raportu

W zmiennej $OUTPUT znajdzie się lista zmodyfikowanych plików, więc w razie potrzeb można na niej wykonać określone akcje.

Skrypt ten będzie działał w nieskończoność, do momentu przerwania jego wykonywania. Dzięki niemu można mieć podgląd wygenerowanych dokumentów LaTeX prawie w czasie rzeczywistym.

Źródła

Tags: , , , , , ,

Automatyzacja wykonywania kopii bezpieczeństwa przy użyciu duply i duplicity

Maj 27

Posted by Łukasz Stelmach in Linux | Comments off

We wpisie Tworzenie kopii zapasowej plików przy użyciu aplikacji duplicity oraz duply opisałem, w jaki sposób skonfigurować aplikację duplicity wraz ze skryptem duply w celu wykonywania kopii zapasowych. Chciałbym teraz to trochę uszczegółowić, pod kątem automatycznego wykonywania kopii zapasowej.

Zakładam, że posiadasz już skonfigurowaną aplikację duply i możesz spokojnie za jej pomocą zrobić kopię wybranych plików. Teraz czas aby to zautomatyzować przy zachowaniu takich warunków:

  • kopia zapasowa ma być wykonywana raz dziennie (przyrostowa)
  • raz w tygodniu ma zostać uruchomione robienie pełnej kopii bezpieczeństwa
  • informacje z polecenia duply i duplicty powinny być zapisane w jakimś logu
  • chcemy zostawić sobie tylko dwa najnowsze pełne backupy

Więc do dzieła :).

Na początek zacznijmy od ostatniego punktu: zostawiamy tylko dwie ostatnie kopie bezpieczeństwa. Za takie zachowanie odpowiada definicja zmiennej MAX_FULL_BACKUPS w pliku conf definiującym dany profil duply:

52
53
54
55
# Number of full backups to keep. Used for the "purge-full" command.
# See duplicity man page, action "remove-all-but-n-full".
# defaults to 1, if not set
MAX_FULL_BACKUPS=2

Ustawienie tej wartości na 2 powoduje zostawienie tylko dwóch ostatnich pełnych kopii bezpieczeństwa (oczywiście, wraz z przyrostowymi backupami).

Co warto zauważyć, stare kopie bezpieczeństwa nie zostaną automatycznie usunięte podczas robienia kopii. Należy powołać polecenie duply odpowiednim parametrem, aby zostały one usunięte:

# duply PROFIL purge-full --force

Wywołanie samego polecenia purge-full spowoduje wyświetlenie informacji o tym co ma zostać usunięte, a dodanie do tego jeszcze przełącznika --force spowoduje usunięcie starych plików.

Teraz czas na zdefiniowanie lokalizacji, gdzie będą zapisywane logi z tworzenia kopii bezpieczeństwa. Załóżmy, że mają one znaleźć się w katalogu /var/log/duply, więc:

# mkdir -p /var/log/duply

Ostatnim krokiem będzie poinformowanie aplikacji cron kiedy ma uruchomić odpowiednie skrypty. Można to zrobić poprzez odpowiednią modyfikację pliku /etc/crontab lub też dodając nowy plik z definicją do katalogu /etc/cron.d.

Wybierzmy drugą opcję, czyli należy utworzyć plik /etc/cron.d/duply o takiej zawartości:

1
2
3
4
5
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

10 2 * * 0      root    (duply PROFIL full && duply system_backup purge-full --force; duply system_backup status) 2>&1 | tee /var/log/duply/duply-$(date +\%Y\%m\%d-\%H\%M\%S).log
10 2 * * 1-6    root    (duply PROFIL backup; duply system_backup status) 2>&1 | tee /var/log/duply/duply-$(date +\%Y\%m\%d-\%H\%M\%S).log

Oto co jest zdefiniowane:

  • definicja zmiennych środowiskowych używanych podczas wywoływania skryptów, ważne jest poprawne zdefiniowanie zmiennej PATH
  • linia 4 – definicja wywołania robienia pełnej kopii bezpieczeństwa, będzie ona wykonywana w każdą niedziele o godzinie 2:10, najpierw zostanie wykonana pełna kopia, następnie zostaną usunięte stare kopie bezpieczeństwa, zostanie wypisany status archiwum i to wszystko zostanie zapisane do pliku /var/log/duply/duply-DATA-GODZINA.log, gdzie DATA i GODZINA to odpowiednio data i godzina rozpoczęcia kopii bezpieczeństwa
  • linia 5 – wykonanie przyrostowej kopii bezpieczeństwa w każdy dzień tygodnia (poza niedzielą) o godzinie 2:10, następnie statusu archiwum, i podobnie zapisanie tych informacji w logu.

Od tej pory kopie bezpieczeństwa powinny wykonywać się automatycznie o zadanych porach.

Źródła

Tags: , , , ,

Przechwycenie strumienia wyjściowego wybranego procesu

Kwi 20

Posted by Łukasz Stelmach in Linux | Comments off

Czasem istnieje następująca sytuacja: musimy zobaczyć co dana aplikacja wypisuje na ekranie, ale jest ona uruchomiona na innym terminalu (do którego nie mamy dostępu) lub też działa w tle i jej komunikaty lądują w nicości (czyli /dev/null). Można to zrobić za pomocą polecenia strace. Polecenie to służy generalnie do śledzenia wywołań systemowych.

strace -f -e trace=write -e write=1,2 -p PID

Opis opcji konfiguracyjnych:

  • -f – śledzi także procesu potomne monitorowanego procesu
  • -e trace=write – śledzenie informacji zapisu
  • -e write=1,2 – deskryptory plików, dla których mają być śledzone zapisy (tutaj stdout i stderr)
  • -p PID – numer procesu, który ma być śledzony

Demonstracja

  1. Utworzyć skrypt o nazwie trace_test.sh
    1
    2
    3
    4
    5
    6
    7
    8
    9
    #!/bin/bash

    echo PID: $$

    for I in `seq 1 1000`
    do
    echo "Linia $I"
    sleep 2
    done

    Skrypt ten wyświetli numer PID z jakim został uruchomiony oraz bedzie wyświetlał komunikat co dwie sekundy.

  2. Uruchomić powyższy skrypt:
    $ bash ./trace_test.sh
  3. Należy teraz otworzyć drugą konsolę i wykonać w niej polecenie:
    strace -f -e trace=write -e write=1,2 -p PID

    W miejsce PID należy wpisać numer wyświetlony przez skrypt trace_test.sh. Przykładowy wynik działania:

    Process 14589 attached - interrupt to quit
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 5\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 35 0a                           Linia 5.          |
    Process 14598 attached
    Process 14589 suspended
    Process 14589 resumed
    Process 14598 detached
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 6\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 36 0a                           Linia 6.          |
    Process 14599 attached
    Process 14589 suspended
    Process 14589 resumed
    Process 14599 detached
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 7\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 37 0a                           Linia 7.          |
    Process 14601 attached
    Process 14589 suspended
    Process 14589 detached
    Process 14601 detached

Analiza takich danych może nie jest najłatwiejsza, ale zawsze dobrze mieć trochę więcej informacji :).

Źródła

Tags: , , , , ,

Konfiguracja serwera NFS 3 w Debianie

Kwi 11

Posted by Łukasz Stelmach in Debian/Ubuntu | Comments off

NFS jest często używanym sieciowym systemem plików. Jego implementacja jest domyślnie dostępna praktycznie we wszystkich dystrybucjach Linuksa, więc bardzo łatwo go zintegrować z systemem plików po stronie gościa.

W przypadku Debiana instalacja jest dosyć prosta, sprowadza się do zainstalowania odpowiedniego pakietu oraz zdefiniowania eksportowanych udziałów.

Serwer NFS jest umieszczony w pakiecie o nazwie nfs-kernel-server, więc pierwszym krokiem jest jego instalacja:

# aptitude install nfs-kernel-server

Konfiguracja udostępnianych udziałów jest przechowywana w pliku /etc/exports, więc należy tam umieścić odpowiednie wpisy:

/exports 192.168.0.0/24(rw,no_subtree_check)

Powyższy wpis powoduje, że udział /exports będzie dostępny dla wszystkich łączących się z sieci 192.168.0.0/24 w trybie odczytu i zapisu.

Aby uruchomić serwer NFS należy teraz wywołać skrypt startowy:

# /etc/init.d/nfs-kernel-server start

Podczas startu serwera na Debianie Lenny wystąpił mi następujący błąd (związany z używaniem nowszego jądra niż standardowo instalowane z dystrybucją):

Not starting NFS kernel daemon: no support in current kernel.

Aby rozwiązać problem, należy zmodyfikować skrypt startowy i zakomentować linię [cii]69[/cci]:

66
67
68
69
70
# See if our running kernel supports the NFS kernel server
if [ -f /proc/kallsyms ] && ! grep -qE 'init_nf(sd|     )' /proc/kallsyms; then
        log_warning_msg "Not starting $DESC: no support in current kernel."
#       exit 0
fi

Opis błędu można znaleźć na stronach Debiana: nfs-kernel-server: init script incompatible with kernel 2.6.32

Tags: , , ,

SN Google Plus