Posts Tagged Linux

Cron a dzień miesiąca i dzień tygodnia

Lut 25

Posted by Łukasz Stelmach in Linux | Comments off

Za uruchamianie cykliczne zadań w systemach Linuksowych odpowiada demon cron. Jego konfiguracja odbywa się poprzez plik crontab, w którym są zdefiniowane jakie zdarzenie i kiedy mają wystąpić. Dokładna dokumentacja znajduje się w pliku MAN crontab(5). Przykładowy wpis może wyglądać następująco:

30 4 1,15 * 5 root /bin/backup

Poszczególne pola definiują, kiedy dana akcja ma zostać wykonana:

  • 30 – minutę
  • 4 – godzinę
  • 1,15 – dzień miesiąca (1 lub 15)
  • * – miesiąc (gwiazdka oznacza każdego miesiąca)
  • 5 – dzień tygodnia (piątek)
  • root – użytkownik, który ma wykonać akcję
  • /bin/backup – co ma zostać wykonane

Pomiędzy poszczególnymi zapisami jest stosowany spójnik „i”, czyli zapis powyżej oznacza: wykonania skryptu /bin/backup przez użytkownika root każdego miesiąca, w piątek oraz kiedy dzień miesiąca jest równy 1 lub 15 o godzinie 4:30.

I tutaj pojawia się mała niespodzianka, ponieważ ta definicja nie jest prawdziwa.

W dokumentacji można przeczytać coś takiego:

Note: The day of a command’s execution can be specified by two fields — day of month, and day of week. If both fields are restricted (ie, aren’t *), the command will be run when either field matches the current time.

Co oznacza (w wolnym tłumaczeniu):

Dzień wykonania danej komendy może zostać podany w dwóch polach: dzień miesiąca oraz dzień tygodnia. Jeżeli oba pola są zdefiniowane (czyli są tam wartości inne wartości niż „*”) dana komenda zostanie wykonana jeżeli do aktualnego będzie pasowało jedno z tych pól.

Czy definicja powyżej oznacza: wykonania skryptu /bin/backup przez użytkownika root każdego miesiąca, w piątek lub kiedy dzień miesiąca jest równy 1 lub 15 o godzinie 4:30.

Należy zapamiętać, że jeżeli podamy oba pola, to między nimi występuje spójnik „lub”.

Źródła

Tags: , , ,

Tworzenie kopii zapasowej plików przy użyciu aplikacji duplicity oraz duply

Lut 24

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

Wcześniej czy później każdy użytkownik komputerów musi zmierzyć się z problem robienia kopii zapasowych swoich plików.Istnieje wiele aplikacji, które mogą tutaj być pomocne. Jednakże tylko niewiele z nich spełnia moje wymagania:

  • możliwość szyfrowania kopii zapasowych (ważne, jeżeli korzystamy z jakiś publicznie dostępnych zasobów lub też przestrzeni dostarczanej przez dostawcę usług, czy też używamy nieszyfrowanego kanału komunikacyjnego)
  • kompresja plików (szybszy transfer danych oraz oszczędność miejsca docelowego)
  • obsługa różnego protokołów komunikacji (dla mnie najważniejszy jest FTP oraz SSH)
  • działanie w trybie nienadzorowanym (czyli możliwość uruchamiania skryptu automatyczna)
  • możliwość przywrócenia dowolnego pliku z różnych momentów czasowych
  • brak konieczności instalowania dodatkowej aplikacji po stronie pozwalającej na zapis danych

Niestety, takie narządzia jak tar, rsync nie spełniają przynajmniej części tych założeń. Inne narzędzia natomiast wymagają instalacji dodatkowego oprogramowania. Rozwiązaniem jest użycie duplicity.

Duplicity

Duplicity pozwala na tworzenie kopii zapasowej wybranych katalogów w postaci zaszyfrowanych plików oraz następnie zapisanie ich w jakiejś lokalizacji (zarówno zdalnej jak i lokalnej). Używa bibliotekę librsync, więc przyrostowe archiwa przechowują tylko faktycznie zmienione dane nawet części plików (czyli jak w pliku o wielkości 1GB zmienimy 100kB, to zapisane zostaną tylko te zmienione informacje a nie od nowa cały plik). Archiwa są szyfrowane przy użyciu GnuPG. Do przesyłania plików można użyć takich protokołów jak:

  • lokalny zapis
  • FTP
  • HSI
  • IMAP/IMAPS
  • RSYNC
  • S3 (zapis w usłudze Amazona)
  • SSH/SCP
  • TAHOE
  • WEBDAV/WEBDAVS

Duply

Aplikacją uzupełniającą duplicity jest skrypt o nazwie duply. Jest to skrypt który jest wrapperem na duplicity. Pozwala on na uproszczenie konfiguracji, ułatwia uruchamianie tworzenia kopii zapasowej z poziomu crona czy też linii poleceń. Charakteryzuje się:

  • pozwala na trzymanie konfiguracji backupu w pojedynczym profilu
  • wykonywanie skryptów przed i po rozpoczęciu wykonywania kopii zapasowej

Pliki z konfiguracja dla każdego profilu znajdują się w katalogu ~/.duply/<nazwa profilu>. Znajdują się tam wszystkie pliki potrzebne do wykonania oraz odzyskania kopii zapasowej. Wyjątkowo jest traktowany użytkownik root. Jeżeli istnieje katalog /etc/duply to w przypadku uruchomienia skryptu z poziomu tego użytkownika on zostanie sprawdzony, a nie jego katalog domowy.

Instalacja potrzebnego oprogramowania

Instalacja potrzebnego oprogramowania w systemie Debian i pochodnych:

Instalacja duplicity oraz klienta FTP ncftp:

# aptitude install duplicity ncftp

Instalacja gpg używanego do szyfrowania backupu:

# aptitude install gnupg

Instalacja skryptu duply niestety jest ręczna. Należy pobrać odpowiedniej archiwum ze strony Duply na Sourceforge, następnie rozpakować oraz przegrać do katalogu /usr/local/bin (instalajca na przykłądzie wersji 1.5.1.5):

p2:~# wget -q "http://downloads.sourceforge.net/project/ftplicity/duply%20%28extended%20ftplicity%29/1.5.1.5/duply_1.5.1.5.tgz?use_mirror=sunet"
p2:~# tar xzvf duply_1.5.1.5.tgz
duply_1.5.1.5/
duply_1.5.1.5/duply
duply_1.5.1.5/gpl.txt
p2:~# cp duply_1.5.1.5/duply /usr/local/bin/

Konfiguracja profilu kopii zapasowej

Pierwszy krokiem będzie utworzenie pary kluczy prywatnego i publicznego, które posłużą do szyfrowania backupu.

Oto przykładowe wygenerowanie klucza. Polecenie gpg zadaje kilka pytań potrzebnych do określenie jakiego rodzaju klucz chcemy wygenerować. Można pozostać przy wartościach domyślnych.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
p2:~# gpg --gen-key
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.  
There is NO WARRANTY, to the extent permitted by law.              

Please select what kind of key you want:
   (1) DSA and Elgamal (default)        
   (2) DSA (sign only)                  
   (5) RSA (sign only)                  
Your selection? 1                      
DSA keypair will have 1024 bits.        
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)                  
Requested keysize is 2048 bits                    
Please specify how long the key should be valid.  
         0 = key does not expire                  
      <n>  = key expires in n days                
      </n><n>w = key expires in n weeks              
      </n><n>m = key expires in n months              
      </n><n>y = key expires in n years              
Key is valid for? (0)                            
Key does not expire at all                        
Is this correct? (y/N) y                          

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:                
    "Heinrich Heine (Der Dichter) <heinrichh @duesseldorf.de>"              

Real name: Backup Key
Email address:
Comment:
You selected this USER-ID:
    "Backup Key"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++.++++++++++++++++++++++++++++++.++++++++++++++++++++>.++++++++++...........................................+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 276 more bytes)
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++++++++++++++++++++++++++++++++++++++++++.+++++.+++++++++++++++..+++++.....++++++++++.+++++.+++++..+++++++++++++++.+++++++++++++++..+++++.+++++++++++++++.+++++>.+++++.+++++>+++++>+++++.............................................+++++^^^
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 5528280A marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   1024D/5528280A 2010-02-24
      Key fingerprint = 5073 7073 E651 0794 3759  27DF 4E47 5605 5528 280A
uid                  Backup Key
sub   2048g/B321C256 2010-02-24

Na co należy zwrócić uwagę:

  • rodzaj klucza: DSA and Elgamal
  • ważność klucza: 0 = key does not expire (czyli klucz nigdy nie straci ważności)
  • podanie informacji opisowych o kluczu
  • ustawienie silnego hasła chroniącego klucz prywatny
  • podczas generowania klucza może pojawić się informacja o braku danych losowych, należy wtedy albo poczekać trochę, albo popisać coś na klawiaturze czy wykonać kilka innych operacji które posłużą do wygenerowania danych losowych
  • trzeba zapamiętać numer klucza, który posłuży potem do jego identyfikacji: w przykładzie jest to: 5528280A (linia 52 lub 58)

W każdej chwili można sprawdzić jakie klucze są zdefiniowane:

1
2
3
4
5
6
p2:~# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/5528280A 2010-02-24
uid                  Backup Key
sub   2048g/B321C256 2010-02-24

Teraz można przystąpić do tworzenia profilu przy użyciu duply. Aby uzyskać pomoc, zawsze można użyć polecenia:

# duply usage

Wyświetli ono informacje o sposobach użycia duply.

Utworzenie nowego profilu system_backup

# duply system_backup create

Spowoduje to utworzenie pliku z konfiguracją backupu w /root/.duply/system_backup/conf. Teraz należy przystąpić do edycji pliku conf, który będzie zawierał dane potrzebne do przeprowadzenia tworzenia kopii zapasowych. W pliku tym jest zdefiniowanych jest szereg zmiennych, które posłużą do definiowania zachowania duplicity.

Pierwszym elementem jest zdefiniowanie klucza GPG, który zostanie użyty do szyfrowania kopii zapasowej:

2
3
GPG_KEY='5528280A'
GPG_PW='A tu trzeba podać hasło do klucza'

Można zdefiniować poziom kompresji czy też przekazać inne parametry do GPG:

7
GPG_OPTS='--compress-algo=bzip2 --bzip2-compress-level=9'

Kolejnym elementem potrzebnych do zdefiniowanie jest miejsce, gdzie należy zapisać naszą kopię bezpieczeństwa. Jak można zabaczyć w opisie pliku, wybór jest duży. Tutaj zostanie zdefiniowana lokalizacja udostępniania przez FTP:

40
41
42
TARGET='ftp://<serwer_backupu>/< ścieżka na serwerze>'
TARGET_USER='użytkownik FTP'
TARGET_PASS='hasło użytkownika'

Zarówno nazwę użytkownika jak i hasło można podać w zmiennej TARGET, ale nie zalecam tego. W takim przypadku mogą się te wartości pojawić np. podczas przeglądania listy procesów, co pozwoli na ich poznanie przez innych użytkowników naszego serwera.

Teraz czas na zdefiniowanie, jaki katalog ma podlegać backupowi:

45
46
# base directory to backup
SOURCE='/'           # ścieżka do katalogu, który ma być backupowany

I to w sumie już wszystko Można już uruchomić proces robienia kopii zapasowej. Warto się jeszcze zapoznań z kilkoma innymi opcjami, ale nie jest to konieczne.

Powyżej do robienia kopii zapasowej został wybrany katalog główny (root), co powoduje że podlegają temu wszystkie pliku na komputerze, łącznie z takimi katalogami jak /proc, /dev czy /tmp. Możemy wyłączyć takie pliki (w przypadku pseudosystemu plików /proc jest to nawet konieczne) tworząc w profilu plik exclude i umieszczając w nim odpowiednie ścieżki, które mają zostać ominięte. Więcej szczegółów jak definiować taki nazwy można znaleźć w dokumentacji MAN duplicty(1), w sekcji FILE SECTION.

Można także określić, ile infomracji ma zostać wyświetlone podczas wykonywania kopii zapasowej. Do wyboru mamy wartości od 1 do 9:

58
59
60
# verbosity of output (5 for gpg errors, 9 for bug fixing)
# default is 4, if not set
VERBOSITY=5

Kolejnym parametrem, który warto ustawić jest rozmiar pojedynczego pliku jaki będzie używało dupliciyt. Im mniejszy plik tym ich więcej musi znaleźć się w pojedynczym katalog (miałem przypadek gdzie było ponad 5000 plików), a i większy rozmiar tym potencjalne większe prawdopodobieństwo wystąpienia problemów podczas jego przesyłania przez sieć internetową. Ponieważ ja będe używał sieci intranetowej, ustawię wielkość pojedynczego pliku na 100MB:

88
89
90
91
92
93
# sets duplicity --volsize option (available since v0.4.3.RC7)
# set the size of backup chunks to VOLSIZE MB instead of the default 25MB.
# VOLSIZE must be number of MB's to set the volume size to.
# Uncomment the following two lines to enable this setting.
VOLSIZE=100
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

Należy zwrócić uwagę, że parametry podane w tym miejscu zostaną już bezpośrednio przekazane do polecenia duplicity, w związku z tym do dokumentacji do tej aplikacji można dokładnie sprawdzić co możne się tutaj znaleźć. Poniżej opiszę jeszcze kilka parametrów, które zdarzyło mi się używać.

Jeżeli mamy kiepskiej jakości połączenie internetowe, możemy zwiększyć ilość razy jaką duplicity będzie podejmowało w celu zapisania pliku na zdalnym serwerze:

99
DUPL_PARAMS="$DUPL_PARAMS --num-retries 10"

Podczas łączenie się przy użyciu protokołu SSH nie zawsze jest możliwość przerprowadzenia uwierzytelnienia przy użyciu kluczy. Wtedy stajemy przed problemem automatycznego podania hasła przez duplicity. Jeżeli użyjemy opcji --ssh-askpass to wtedy zostanie podjęta próba zalogowania się na konto przy użyciu hasła znajdującego się w zmiennej środowiskowej FTP_PASSWORD. W przypadku używania skryptu duply jest to tożsame z ustawieniem parametru TARGET_PASS w pliku konfiguracyjnym:

102
DUPL_PARAMS="$DUPL_PARAMS --ssh-askpass"

Podczas łączenie się przy uzyciu protokołu SSH duplicity wymaga dostępności serwera sftp. Przy normalnej konfiguracji serwera SSH na maszynie zdalnej usługa ta jest z reguły włączona i można z niej korzystać. Czasem jednak się zdarza, że nie jest ona skonfigurowana. W takiej sytuacji możemy serwer sftp uruchomić „ręcznie”:

105
DUPL_PARAMS="$DUPL_PARAMS --sftp-command 'sftp -s <pe łna ścieżka do polecenia sftp-server na zdalnej maszynie>'"

Jeżeli istnieje potrzeba włączenie jakiegoś dodatkowego katalogu do backupu, możemy to zrobić za pomocą przełącznika --include:

106
DUPL_PARAMS="$DUPL_PARAMS --include /etc"

Możemy także przekazać bezpośrednio do polecenia duplicity listę katalogów czy plików, które mają zostać wyłączone z backupu:

107
108
DUPL_PARAMS="$DUPL_PARAMS --exclude /tmp/\*\*"         # wyłączenie wszystkich plików z katalogu /tmp
DUPL_PARAMS="$DUPL_PARAMS --exclude \*\*/.svn/\*\*"    # wyłączenie z backupu wszystkich katalogów z plikami subversion

Uwaga! Użycie przełączników --include oraz --exclude utrudni odzyskanie kopii bezpieczeństwa. Zanim się uruchomi proces jej odzyskiwania, trzeba będzie przynajmniej zakomentować te wpisy.

Oprócz samej konfiguracji backupu możemy także zdefiniować, jakie akcje powinny być podejmowane zanim rozpocznie się tworzenie kopii zapasowej oraz po zakończeniu jej robienia.

Aby zostały wykonane polecenie przed rozpoczęciem procesu backupu należy w katalogu z profilem umieścić plik o nazwie pre. W pliku tym należy umieścić wszystkie polecenia jakie mają zostać wykonane. Należy pamiętać, że blik ten będzie interpretowany przez powłokę bash, więc musi z nią być kompatybilny. W pliku tym możemy np. umieścić polecenie zapisujące stan bazy danych w pliku tekstowym, możemy zatrzymać jakąś usługę czy wymusić jakieś akcje w używanych przez nas aplikacjach.

Po zakończeniu backupu zostaną wykonane polecenia znajdujące się w pliku post. Ten plik także zostanie wykonany przy użyciu powłoki bash. Możemy w nim np. skasować wcześniej utworzone pliki tekstowe, uruchomić zatrzymane usługi.

Jeżeli kopia zapasowa ma być wykonywana automatycznie przez użytkownika root, to warto teraz przenieść gotowy profil (w podanym przykładzie o nazwie system_backup) do katalogu /etc/duply:

# mkdir /etc/duply
# mv /root/.duply/system_backup /etc/duply/
# chown -R root.root /etc/duply
# chmod a-rwx,u=rw,u+X /etc/duply

Tworzenia kopii zapasowej

Po utworzeniu profilu można rozpocząć tworzenie kopii zapasowej:

# duply system_backup backup

Jeżeli nie wystąpi żaden bład, to powinny się pojawić komunikaty świadczące o rozpoczeciu procedury tworzenia kopii zapasowej, m.in.:

  • ścieżka profilu użytego do tworzenia kopii zapasowej
  • informacje o kluczu
  • rozpoczęcie wykonywania skryptów z pliku pre
  • rozpoczęcie tworzenia kopii zapasowej, lista dołączonych plików oraz informacje o zapisie poszczególnych plików do podanej lokalizacji
  • uruchomienie skryptu post
  • wyświetlenie informacji statycznych o utworzonej kopii zapasowej
  • zakończenie procedury

Pierwsze uruchomienie powyższego polecenie przeprowadzi pełny backup, każde kolejne tylko backup przyrostowy (w stosunku do poprzedniego).

Można także zauważyć, że w katalogu z profilem pojawi się dodatkowy plik gpgkey.<nr klucza>.asc. Plik ten zawiera dane o kluczu GPG użytym do szyfrowania kopii zapasowej. Tym samym zawartość pliku profilu jest w pełni wystarczająca zarówno do wykonania kopii zapasowej jak jej odzyskania. Należy zapisać profil w bezpiecznym miejscu, ponieważ bez dostępu do klucza prywatnego nie będzie możliwe odzyskanie danych z backupu.

Istnieją także wariancje polecenia backup:

  • bkp – wykonanie kopii zapasowej, ale bez wykonywania skryptów z plików pre oraz post
  • full – wymuszenie wykonania pełnej kopii zapasowej
  • incr – wymuszenie wykonania przyrostowej kopii zapasowej

W przypadku robienia kopii zapasowych poprzez Internet, warto rozważyć instalację duplicty w wersji przynajmniej 0.6. Wersja ta przechowuje lokalnie informacje o plikach zapisanych na serwerze z backupem. Plik ten może mieć przy dużych archiwach sporą wielkość (w moim przypadku ponad 600MB). Wersje wcześniejsze przed przystąpieniem do robienia kopii zapasowych zawsze pobierały ten plik z serwera co drastycznie wydłużało czas robienie kopii zapasowej.

Automatyczne uruchamianie tworzenia kopii zapasowej

Najprostszym sposobem automatycznego wywoływania procedury backupowej jest dodanie odpowiedniego wpisu w aplikacji cron. W przypadku systemu Debian można utworzyć następujący plik /etc/cron.d/duply o takiej zawartości:

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

20 4 * * *   root    /usr/local/bin/duply system_backup backup

Spowoduje to uruchamianie procesu tworzenia kopii zapasowej codziennie o godzinie 4:20.

Więcej o automatyzacji robienia kopii bezpieczeństwa można przeczytać w tym wpisie: Automatyzacja wykonywania kopii bezpieczeństwa przy użyciu duply i duplicity.

Przeglądanie kopii zapasowej

  • Wyświetlenie listy aktualnie zapisanych plików:
    # duply system_backup list
  • Wyświetlanie listy plików zapisanych 2 dni temu:
    # duply system_backup list 2D
  • Wyświetlenie informacji o wykonany kopiach zapasowych:
    # duply system_backup status

Odzyskiwanie plików z kopii zapasowej

Oczywiście stworzenie samej kopii bezpieczeństwa nie jest wystarczające, trzeba jeszcze móc ją przywrócić. Szczególnie ważne jest sprawdzenie tego procesu w momencie gdy szyfrujemy naszą kopię bezpieczeństwa. W przypadku utraty kluczy użytych do szyfrowania kopia bezpieczeństwa będzie całkowicie bezużyteczna.

  • Odzyskanie całej kopii bezpieczeństwa (najnowszej):
    # duply system_backup restore < ścieżka do udziału na którym zapisać kopię>
  • Odzyskanie całej kopii bezpieczeństwa (sprzed 3 dni):
    # duply system_backup restore <katalog na kopię> 3D

  • Odzyskanie wybranego pliku/katalogu (najnowsza wersja)
    # duply system_backup fetch <co chcemy odzyskać> <katalog na kopię>

  • Odzyskanie wybranego pliku/katalogu (sprzed 3 dni)
    # duply system_backup fetch <co chcemy odzyskać> <katalog na kopię> 3D

Jak można zauważyć, podczas odzyskiwania danych zostaną przywrócone także uprawnienia do plików, odpowiedni użytkownicy (dlatego też najczęściej należy to robić jako użytkownik root).

Czyszczenie archiwum

Czasem się zdarza się, że tworzenie kopii zapasowej zostanie przerwane. Czy też z powodu błędu podczas kopiowania pliku, może błędu jakiejś aplikacji. Pozostają wtedy na serwerze docelowym pliki z tworzoną kopią zapasową, ale już nie da się ich użyć. Aby je skasować, można użyć komendy cleanup:

# duply system_backup cleanup

Spowoduje ona usunięcie niepotrzebnych plików z serwera na którym zapisujemy kopię zapasową.

Ograniczenie pasma sieci podczas backupu

Może się zdarzyć, że nie chcemy zajmować całego dostępnego pasma w celu zrobienia kopii bezpieczeństwa (może to kolidować z potrzebami innych użytkowników naszej sieci).

Ze względu na swoją konstrukcję, aplikacja duplicty do przesyłania danych wykorzystuje zewnętrzne narzędzia. W przypadku korzystania z protokołu SSH wykorzystywana jest aplikacji sftp. Pozwala ona na pobierania informacji o plikach oraz ich przesyłanie. W wersjach duplicty poniżej 0.5 do przesyłania danych było wykorzystywane polecenie scp.

I tutaj pojawia się pewien problem: sftp nie posiada możliwości ograniczenia przepustowości łącza. Na szczęście rozwiązanie jest dosyć proste, należy użyć do przesyłania zawartości plików polecenia scp. W pliku conf danego profilu kopii bezpieczeństwa należy dodać następującą linię:

DUPL_PARAMS="$DUPL_PARAMS --use-scp --scp-command '/usr/bin/scp -l 100'"

Spowoduje to wywołanie duplicty z dodatkowymi opcjami, które:

  • --use-scp – wymusi użycie aplikacji scp w celu przesyłania plików
  • -scp-command – poda jakie polecenie ma zostać wywołane jako komenda scp, dzięki czemu możemy podać w niej odpowiednie ograniczenia, na przykładzie ograniczenie przepustowości do 100kB/s

Mała uwaga na koniec, u mnie ta zmiana spowodowała konieczność ściągnięcia z serwera wszystkich plików opisujących poszczególne archiwa (z sumami kontrolnymi).

Źródła

Tags: , , , , ,

Przegranie filmu z płyty VCD

Lut 21

Posted by Łukasz Stelmach in Linux | Comments off

Chciałem dzisiaj przegrać film z płyty VCD i okazało się to trochę bardziej skomplikowane niż początkowo mi się wydawało.

Początkowo sprawdziłem þlytę, znalazłem na niej pliki z rozszerzeniem dat więc stwierdziłem, że wystarczy przegrać taki plik. Niestety, nie dało się go odtworzyć przy użyciu aplikacji mplayer.

Drugie podejście polegało na użyciu polecenia ffmpeg. Niestety także nie zadziało.

Trzecie podejście do użycie aplikacji k3b w celu skopiowania płyty także nie zadziało (błąd związany z wieloma ścieżkami znajdującymi się na płycie).

Skończyło się łatwe podejście, więc trzeba było teraz trochę poszukać:

$ aptitude search vcd
p   vcdimager     - A VideoCD (VCD) image mastering and ripping tool
p   vcdtools      - Creates Video CD (VCD) filesystem images

Przeszukanie listy dostępnych pakietów w sowich wynikach wskazało na aplikację vcdimager, wiec trzeba ją było zainstalować:

# aptitude install vcdimager

Teraz kolej na sprawdzenie, jaki pliki binarne zostały zainstalowane i co może pomóc w zgraniu płyty:

$ dpkg-query -L vcdimager | grep bin/
/usr/bin/cdxa2mpeg
/usr/bin/vcd-info
/usr/bin/vcdimager
/usr/bin/vcdxbuild
/usr/bin/vcdxgen
/usr/bin/vcdxminfo
/usr/bin/vcdxrip

Najbardziej pomocna wydaje się aplikacji vcdxrip

Tutaj się pojawił problem, bardzo kiepska dokumentacja, zarówno w postaci plików man jak i dostępna na stronie aplikacji. Ale po krótkich poszukiwaniach udało mi się znaleźć rozwiązanie. Aby odczytać film z płyty wystarczy wydać następujące polecenie:

$ vcdxrip --nofiles -p

Spowoduje ono odczytanie zawartości płyty oraz zapisanie znalezionych na niej ścieżek w bieżącym katalogu w formacie MPEG.

Źródła

Tags: , , , , ,

Jakiego zarządcę operacji dyskowych wybrać dla maszyn wirtualnych

Lut 15

Posted by Łukasz Stelmach in Linux, RedHat Enterprise Linux, Wirtualizacja | Comments off

Dostępni zarządcy kolejkowania operacji I/O

W Linuksie (przynajmniej w RHEL 5) mam do wybory czterech różnych zarządców procesów (będzie po angielsku):

  • Completely Fair Queuing (CFQ)

    CFQ maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. CFQ is well suited for mid-to-large multi-processor systems and for systems which require balanced I/O performance over multiple LUNs and I/O controllers.

  • Noop

    The NOOP scheduler is a simple FIFO queue and uses the minimal amount of CPU/instructions per I/O to accomplish the basic merging and sorting functionality to complete the I/O. It assumes performance of the I/O has been or will be optimized at the block device (memory-disk) or with an intelligent HBA or externally attached controller.

  • Deadline

    The Deadline elevator uses a deadline algorithm to minimize I/O latency for a given I/O request. The scheduler provides near real-time behavior and uses a round robin policy to attempt to be fair among multiple I/O requests and to avoid process starvation. Using five I/O queues, this scheduler will aggressively re-order requests to improve I/O performance.

  • Anticipatory

    The Anticipatory elevator introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. This algorithm is intended to optimize systems with small or slow disk subsystems. One artifact of using the AS scheduler can be higher I/O latency.

    Agorytm zarządcy dyskowego anticipatory został usunięty w nowych wersjach jądra Linuksa. Ciągle jednak jest (i będzie dostępny) w wersji RHEL 5, która zawiera jądro w wersji 2.6.18.

Można to sprawdzić wydając poleceni:

# cat /sys/block/URZADZENIE/queue/scheduler
noop anticipatory deadline [cfq]

Aktualnie wybrany zarządca jest podany w nawiasach kwadratowych.

Zarządca kolejki I/O dla komputera hosta

W większości przypadków najlepsze efekty osiągnie się korzystając z aglgorytmu cfq. Pracuje on równie dobrze przy praktycznie wszelkich obciążeniach. Jeżeli natomiast jest ważniejsze zminimalizowanie opóźnień I/O kosztem ogólnej przepustowości, być może warto rozszerzyć algorytm deadline.

Zarządca kolejki I/O dla gościa

W przypadku systemów wirtualizowanych sytuacja nie jest już taka prosta. W dużej części przypadków opłacalne może być ustawienie zarządcy kolejki I/O jako noop. Jest to spowodowane tym, że nie ma potrzeby kolejkowania zapisów w dwóch warstwach, raz na systemie gościa a drugi raz na systemie gospodarza. Lepiej jest, gdy to gospodarz decyduje kiedy i jak zapisać czy odczytać dane z dysków. To system hosta ma informacje o wszystkich operacjach dyskowych ze wszystkich maszyn oraz posiada informacje o fizycznej charakterystyce dysków twardych.

Istnieją wyjątki od tej zasady wtedy, gdy system gości uzyskują dostęp do dysków poprzez protokół iSCSI lub też mają podłączone bezpośrednio urządzenie fizyczne. Wtedy powinny samodzielnie zarządzać kolejką I/O.

Konfiguracja domyślnego algorytmu kolejkowania

Zmiana algorytmu kolejkowania I/O w trakcie pracy systemu

Zmianę dokonujemy przy użyciu polecenia echo:

# cat /sys/block/URZADZENIE/queue/scheduler
noop anticipatory deadline [cfq]
# echo 'noop' > /sys/block/URZADZENIE/queue/scheduler
# cat /sys/block/URZADZENIE/queue/scheduler
[noop] anticipatory deadline cfq

Nowy algorytm będzie używany od razu, zmiana ta nie przetrwa restartu maszyny. Natomiast umożliwia wprowadzenie innego sposobu kolejkowania dla różnych urządzeń.

Aby zapewnić wprowadzenie tych zmian po restarcie maszyny, można dodać odpowiedni wpis do pliku /etc/rc.local

# echo "echo 'noop' > /sys/block/URZADZENIE/queue/scheduler" >> /etc/rc.local

Zmiana domyślnego algorytmu kolejkowania I/O

Zmiana domyślnego algorytmu kolejkowania I/O dla systemu Linuks polega na przekazania odpowiedniego parametru do jądra. Przypisujemy wartośc parametrowi elevator nazwę domyślnego algorytmu kolejkowania: noop, anticipatory, deadline oraz cfq.

Przykładowy wpis z pliku /boot/grub/grub.conf:

34
35
36
37
title Red Hat Enterprise Linux Server (2.6.18-8.el5)
root     (hd0,0)
kernel  /vmlinuz-2.6.18-8.el5 ro root=/dev/vg0/lv0 elevator=noop
initrd   /initrd-2.6.18-8.el5.img

Opis, w jaki sposób można modyfikować konfigurację GRUBa zarówno w dystrybucji RedHat jak i Debian można znaleźć we wpisie Konfiguracja dostępu do maszyny wirtualnej przy użyciu polecenia virsh lub xm.

Źródła

Tags: , , , , , , ,

Użycie serwera proxy przy pomocy polecenia tsocks

Lut 13

Posted by Łukasz Stelmach in Linux | Comments off

W sieciach intranetowych bardzo często nie mamy możliwości łączenia się z systemami udostępniającymi swoje usługi na niestandardowych portach. Przykładami takich usług może być:

  • radio internetowe
  • repozytorium kodu źródłowego (np. udostępnianie przez CVS)
  • zablokowany dostęp do portów SMTP czy POP3
  • i tak dalej, wymieniać można długo.

Jeżeli jednak mamy możliwość wykonywania połączeń przy użyciu SSH, jesteśmy w stanie otworzyć odpowiedni tunel, który umożliwi nam przekierowanie takiego połączenia poprzez niego i ominięcie zabezpieczeń.

Co jednak, jeżeli wybranej przez nas aplikacji nie można skonfigurować tak, aby używała do pracy tunelu? Jeżeli nie chcemy zmieniać konfiguracji całego systemu, tak aby korzystał z tunelu?

Ja miałem taki problem przy próbie połączenia się ze stacjami radiowymi przy użyciu aplikacji Rhythmbox. Chciałem aby ona łączyła się z każdą stacją radiową, a nie znalazłem możliwości konfiguracji połączania przy użyciu serwera proxy czy też tunelu.

Rozwiązaniem tego problemu jest użycie aplikacji tsocks, umożliwi nam przekierowanie połączeń przez utworzony tunel SSH.

Jak działa biblioteka tsocks?

Najprościej mówiąc, tsocks jest biblioteką, która przechwytuje połączenia z podanej aplikacji i przesyła je dalej wykorzystując serwer proxy typu SOCKS.

Aby biblioteka zadziałała poprawnie, należy ustawić odpowiedni zmienną środowiskową LD_PRELOAD, tak aby wskazywała na bibliotekę libtsocks.so. Spowoduje to jej wczytanie zanim jeszcze zostaną wczytane pozostałem biblioteki związane z aplikacją oraz to właśnie funkcje z niej zostaną użyte podczas łączenia.

export LD_PRELOAD=/lib/libtsocks.so

Oczywiście nie musimy tego robić ręcznie, pomocny będzie odpowiedni skrypt o nazwie tsocks napisany w bashu.

Konfiguracja tsocks

Aby biblioteka tsocks zadziałała poprawnie, należy przygotować odpowiedni plik konfiguracyjny, który będzie zawierał informacje potrzebne do przekierowania połączenia.

Plik konfiguracyjny o nazwie .tsocks.conf powinien znajdować się w katalogu domowym użytkownika. Plik ten w najprostszej formie zawiera tylko definicję serwera SOCKS oraz sieci lokalnych, z którymi należy łączyć się bezpośrednio. Dokładne informacje o formacie tego pliku i wszystkich parametrach można znaleźć na stronie MAN tsocks.conf(5). Przykładowy plik konfiguracyjny:

1
2
3
4
server = 127.0.0.1
server_port = 8075
server_type = 5
local = 192.168.1.0/255.255.255.0

Konfiguracja nakazuje łączyć się z serwerem SOCKS typu 5 (linia 3) nasłuchującym na porcie 8075 (linia 2) naszej lokalnej maszyny (linia 1), czyli połączyć się z tunelem stworzonym przy użyciu polecenia ssh. Połączenie z siecią lokalną 192.168.1.0/24 (linia 4) będę się odbywały bezpośrednio.

Zestawienie tunelu

Proste polecenie demonstrujące zestawienie tunelu przy wykorzystaniu aplikacji ssh:

ssh -D 8075 login@host

Jeżeli nie używamy uwierzytelniania opartego o klucze to jeszcze będziemy musieli podać hasło użytkownika na zdalnej maszynie. Po tej operacji klient SSH będzie nasłuchiwał na połączenia na porcie 8075 naszej lokalnej maszyny. Połączenia te zostaną przesłane przez tunel na maszynę zdalną i tam wysłane do serwerów docelowych. Tym sposobem został uruchomiony serwer proxy SOCKS.

Włączenie biblioteki tsocks

Ostatnim krokiem jest uruchomienie aplikacji, która ma korzystać w przezroczysty sposób z serwera SOCKS. Są dostępne trzy możliwości, przydatne w różnych okolicznościach. Do odpowiedniej konfiguracji systemu zostanie wykorzystany skrypt /usr/bin/tsocks. Dokumentacja do niego jest dostępna na stronie MAN tsocks(1).

Uruchomienie pojedynczej aplikacji

Najprostszą metodą na uruchomienie aplikacji jest użycie konstrukcji:

tsocks nazwa_aplikacji_do_uruchomienia

Spowoduje ustawienie zmiennej środowiskowej LS_PRELOAD i uruchomienie żądanej aplikacji. Aplikacji już powinna automatycznie korzystać z serwera proxy, nie będąc tego świadomą.

Konfiguracja uruchomionej powłoki

W ramach aktualnej powłoki możemy włączyć korzystanie z serwera proxy dla wszystkich aplikacji później uruchamianych. Korzystamy wtedy z polecenia:

$ source tsocks -on

lub też z jego krótkiej formy:

$ . tsocks -on

Spowoduje to odpowiednie ustawienie zmiennej środowiskowej LD_PRELOAD w aktualnej powłoce systemowej.

Wyłączenie serwera proxy następuje po wydaniu komendy:

$ source tsocks -off

lub też:

$ . tsocks -off

Należy zwrócić uwagę na wykorzystanie polecenia source. Jeżeli tego nie zrobimy, powłoka nie zostanie skonfigurowana poprawnie.

Aby sprawdzić czy mamy ustawione przekierowanie połączeń na serwer pośredniczący, używamy instrukcji:

$ tsocks -show
LD_PRELOAD="/usr/lib/libtsocks.so"

W wyniku jej wykonania zostania pokazana zawartość zmiennej środowiskowej LD_PRELOAD. Jeżeli zawiera ona ścieżkę do biblioteki libtsocks.so oznacza to, że mamy skonfigurowane połączenie z serwerem proxy.

Utworzenie nowej powłoki

Ostatnią możliwością jest utworzenie od razu odpowiednio skonfigurowanej nowej powłoki. Można to zrobić wywołując po prostu polecenie tsocks bez żadnych parametrów:

$ tsocks
$ tsocks -show
LD_PRELOAD="/usr/lib/libtsocks.so"

Wszystkie wywoływane aplikacje z tej powłoki będą łączyły się przy użyciu serwera proxy. Powłokę można opuścić wydając polecenie exit.

Źródła

Tags: , , , ,