drimi.eu

Często przy aktualizacji daty na serwerach zdarza się komunikat:

debian:/home/dreamer# hwclock –-systohc
select() to /dev/rtc to wait for clock tick timed out

Rozwiązanie problemu:

debian:/home/dreamer# –systohc –directisa –localtime

Ostatnio dość często w pracy wykonuję kopie zapasowe oraz automatyzację zadań. Troszkę swoich doświadczeń postanowiłem przerzucić na bloga Przed przystąpieniem do lektury dalszej części polecam zapoznać się z wcześniejszymi notkami związanymi z SSH:

• SSH bez hasła
• Połączenia VNC w tunelu SSH

Więc zaczynamy:

$ scp plik.txt user@serwer.com:~/
- polecenie skopiuje bezpiecznie plik.txt na serwer.com do katalogu domowego użytkownika user

Oczywiście nic nie stoi na przeszkodzie by ściągnąć jakiś plik przez scp ze zdalnego serwera:

$ scp user@serwer.com:~/plik.txt .
- polecenie skopiuje bezpiecznie plik.txt znajdujący się na serwerze serwer.com w katalogu domowym użytkownika user

Polecam zapoznać się z manualem scp. Z jego ciekawszych opcji
-r Kopiuje całe katalogi (rekurencyjnie).
-l limit limit transferu danych w Kb/s.

No tak ale kopiowanie katalogów przez scp trwa troszkę długo. O wiele szybciej kopię katalogu możemy zrobić następująco

tar cpf - ./* | gzip | ssh user@domena.pl ‘cd ~/; \
cat - > kopia_katalogu-$(date “+%d.%m.%y-%H:%M”.tar.gz)’

Tym poleceniem zrobimy kopie katalogu, spakujemy ja gzip-em, prześlemy do serwera zdalnego do katalogu głównego i wrzucimy do pliku kopia_katalogu-{bierzaca-data}. Sposób dość szybki. Oczywiście nic nie stoi na przeszkodzie byśmy robili np. mirror katalogu na drugi serwer. Wtedy wklepujemy:

tar cpf - ./* | ssh user@domena.pl ‘cd /home/user/mirror; tar xf -’

Mam nadzieję, że podrzuciłem parę pomysłów i pobudziłem do dalszego testowania

Doinstalowujemy: ntpdate:

$ apt-get install ntpdate

Następnie dodajemy wpis co cron-a:

$sudo crontab -e

0 1 1 * * * ntpdate -u adres.serwera.ntp.pl && hwclock –systohc \
&& logger “Uaktualnilem czas” 1> /dev/null

Czyli każdego pierwszego dnia miesiąca o 1 uruchamiane bedzię polecenie ntpadate które zsynchronizuje nasz zegar z “adres.serwera.ntp.pl”. Następnie zostanie uruchomiony hwclock by zsynchronizować czas sprzętowy, a na samym końcu dodamy wpis do /var/log/messages o przeprowadzonym synchro. Serwery ntp można łatwo wyszukać w sieci, poniżej przedstawiam kilka adresów:

• tempus2.gum.gov.pl
• tempus2.gum.gov.pl
• ntp.task.gda.pl
• ntp.certum.pl
• time.atman.pl
• ntp.icm.edu.pl

Od czasu kiedy poznałem VNC (Virtual Network Computing) czyli system przekazywania ekranu ze zdalnego środowiska graficznego, moja praca stała się o wiele przyjemniejsza. Nie musiałem marnować czasu na dojazdy czy bieganie pomiędzy piętrami. Wystarczyło zainstalować serwery VNC u klientów i większość rzeczy mogłem wykonać ze swojego komputera.
Strona domowa VNC to www.realvnc.com
Wszystko sprawuje się dobrze o ile jesteśmy w tej samej sieci lub komputery klienckie mają publiczne adresy IP. Jednak co gdy musimy połączyć się do klienta znajdującego się za NAT-em?

Otóż z pomocą przychodzą nam tunele ssh. Wystarczy, że będziemy posiadali konto na routerze wykonującym NAT. W naszym przykładzie testowy.com. Więc jak wykonać takie połączenie? Załóżmy, że chcemy połączyć się z laptopa do klienta o adresie ip 192.168.1.5. W laptopie wpisujemy więc komendę:

$ ssh -L 3333:192.168.1.5:5900 user@testowy.com

I zatwierdzamy enterem. Zostaniemy poproszeni o podanie hasła do konta user, po czym tunel zostanie ustanowiony. No tak ale co to oznacza? Po oplcji L podajemy port_lokany:ip_hosta:port_hosta następnie login i nazwę/IP routera. Teraz możemy połączyć się z naszym hostem odwołując się do locahlosta na porcie 3333. Czyli w VNC w polu hosta wpisujemy localhost:3333. Tunel zajmie się resztą. Można pójść dalej i od razu ustawić klika przekierowań:

$ ssh -L 3333:192.168.1.5:5900 -L 3334:192.168.1.34:5900 -L 3335:192.168.1.95:5900 user@testowy.com

Po takiej operacji odwołując się po kolei do:

• localhost:3333 - otrzymamy połączenie z komputerem 192.168.1.5
• localhost:3334 - otrzymamy połączenie z komputerem 192.168.1.34
• localhost:3335 - otrzymamy połączenie z komputerem 192.168.1.95

Tego typu tunele można wykorzystywać także do innych celów, a możliwości jest naprawdę wiele np połączenie ze zdalnym pulpitem Windows za pomocą programu rdesktop. Wystarczy zmienić port docelowy na 3389.

Życzę przyjemnego kopania tuneli

Dziś do rodziny serwerów którymi się opiekuje dołączył Ślimaczek Maleństwo otrzymało taką nazwę ze względu na to iż jest najwolniejszą maszyną w grupie. Posiada procesor Intel Celeron 2.00, 256 MB DDR RAM-u oraz dysk SATA 160 GB. Podłączony jest do szkieletu z przepustowością 1Mb/s. Całą mocą sprzętu zarządza Ubuntu 7.04 server. Jego zadaniem będzie robienie i trzymanie backupów danych z innych serwerów, secondary MX, utrzymywanie baz danych na potrzeby testów, awaryjny serwer WWW, analiza logów z innych serwerów oraz testowania aplikacji sieciowo-bazodanowych pisanych w Perlu.
Na dzień dzisiejszy w rodzinie serwerów znajdują się takie nazwy jak:

• zozolek
• routerek
• tygrysek
• kapselek
• pocztówka
• slimaczek
• imq

No i oczywiście Laptop: Jomal. Może macie pomysły na nazwy dla nowych serwerów?

Często loguje się na różne serwery i wpisywanie hasła jest męczące a przy automatyzacji zadań często nie możliwe. Pozostawienie logowania bez zabezpieczenia oczywiście nie wchodzi w grę ;). Na szczęście z pomocą przychodzi nam uwierzytelnianie za pomocą kluczy - prywatnego i publicznego. Więc do dzieła.
By wygenerować klucze wydajemy w naszym systemie polecenie ssh-keygen -t rsa

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

Gdy skrypt generujący zapyta nas o hasło, wciskamy enter. Zostanie wtedy utworzony klucz bez hasła. Jak widać w wyniku tego polecenia zostały wygenerowane dwa klucze, jeden w pliku id_rsa (klucz prywatny który należy chronić i nikomu nie udostępniać), oraz id_rsa.pub(klucz publiczny).
Pozostało nam tylko wysłanie klucza publicznego do serwera na konto do którego chcemy się logować bez hasła. Wydajemy więc polecenie:

$ scp ~/.ssh/id_rsa.pub user@serwer:~/

Następnie logujemy się do zdalnej maszyny i umieszczamy klucz publiczny w ~/.ssh/authorized_keys

$ ssh user@serwer
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Od tej chwili przy logowaniu na tą maszynie nie będziemy pytanie o hasło, a zostaniemy uwierzytelnieni na podstawie klucza.
Nie powinno stosować się tej techniki do logowania na konta uprzywilejowane.

Co się stanie z poufnymi danymi, gdy ktoś ukradnie nam laptopa lub przenośny dysk? Co z naszymi danymi? Jak sie zabezpieczyć? Odpowiedzią może być szyfrowany system plików który pozwala na ograniczenie dostępu przez niepowołane osoby. A więc co nam będzie potrzebne:

• cryptsetup
• dmsetup

Pod Ubuntu wystarczy wpisać:

sudo apt-get install cryptsetup dmsetup

Po zainstalowaniu upewnijmy się czy posiadamy to co trzeba :

dreamer@jomal:~$ cat /proc/crypto | grep aes
name : cbc(aes)
driver : cbc(aes-generic)
name : aes
driver : aes-generic
module : aes

oraz

dreamer@jomal:~$ sudo dmsetup targets
crypt v1.3.0
striped v1.0.2
linear v1.0.2
error v1.0.1

Skoro wszystko OK idziemy dalej. W moim przypadku będę szyfrował partycje na zewnętrznym przenośnym dysku, która znajduję się pod adresem /dev/sdb1. Na początek dobrze jest jednorazowo zapełnić partycje losowymi danymi. Uwaga w tym momęcie utracimy wszystkie dane z tej partycji!

dreamer@jomal:~$ sudo dd if=/dev/urandom of=/dev/sdb1 bs=1M

Zapełnienie partycji trwa dość długo. Wszystko zależy od rozmiaru partycji. Proponuje przejść się na kawę lub obejrzeć cos w TV;)
Po zakończeniu przygotowujemy wolumin kryptograficzny poleceniem “cryptsetup -y create nazwa urządzenie”. Program zapyta nasz o hasło które będzie później używane do montowania partycji.

dreamer@jomal:~$ sudo cryptsetup -y create TAJNE /dev/sdb1
Enter passphrase:
Verify passphrase:
dreamer@jomal:~$

Możemy teraz za pomocą polecenia cryptsetup status crypted uzyskać informacje o woluminie.

dreamer@jomal:~$ sudo cryptsetup status TAJNE
/dev/mapper/TAJNE is active:
cipher: aes-cbc-plain
keysize: 256 bits
device: /dev/sdb1
offset: 0 sectors
size: 293073795 sectors
mode: read/write
dreamer@jomal:~$

Nadszedł czas na stworzenie systemu plików na partycji. Do wyboru mamy reiserfs, ext2, ext3… Każdy może użyć swojego ulubionego. Ja postanowiłem użyć ext3:

dreamer@jomal:~$ sudo mkfs.ext3 /dev/mapper/TAJNE

No tak ale dlaczego akurat /dev/mapper/TAJNE a nie /dev/sdb1? program cryptsetup zmapował dysk i właśnie w taki sposób do niego się teraz dostajemy.
Pozostało nam tylko zamoutowanie dysku do systemu plików. Utworzymy sobie katalog np /mnt/TAJNE i do niego podepniemy nasz nowy system plików.

dreamer@jomal:~$ sudo mkdir /mnt/TAJNE
dreamer@jomal:~$ sudo mount /dev/mapper/TAJNE /mnt/TAJNE

Teraz zapisując dane w /mnt/TAJNE trafiają na zaszyfrowany dysk
A co po restarcie maszyny? Należy wydać polecenia:

dreamer@jomal:~$ sudo cryptsetup -y create TAJNE /dev/sdb1
dreamer@jomal:~$ sudo mount /dev/mapper/TAJNE /mnt/TAJNE

Jeśli do partycja na dysku lokalnym można dodać wpis do /etc/crypttab

TAJNE /dev/sdb1 none

Wolumin będzie przygotowywany automatycznie podczas uruchamiania komputera. Oczywiście zostaniemy zapytani wcześniej o hasło. Należy jeszcze dodać do /etc/fstab informacje o systemie plików:

/dev/mapper/TAJNE /mnt/TAJNE ext3 defaults,errors=remount-ro 0 0

Jednak należy pamiętać, że stosowanie szyfrowanych partycji nie jest 100% zabezpieczeniem poufnych danych.

Wiele razy zdarzało mi się że któraś z usług przestała działać, a zanim to zauważyłem minęło dużo czasu (no chyba że była na tyle ważna, by userzy zorganizowali pochód z widłami i pochodniami ). Aby temu zapobiec napisałem proste skryciki, odpalane przez cron-a co 5 minut, które sprawdzały stan procesów i w czasie padu próbowały go podnieść. Więc do dzieła:
W pliku plik /etc/crontab dopisujemy

0-59/5 * * * * root run-parts /etc/cron.5min

Następnie tworzymy katalog /etc/cron.5min Właśnie w nim będą znajdowały się nasze skrypty. Tworzymy więc plik o nazwie test-http. Napiszemy w nim kod odpowiedzialny za pilnowanie Apache. Wpisujemy:

#!/bin/sh
ps auxw | grep httpd | grep -v “grep” | grep -v “test” >/dev/null
let wynik=$?

if [ $wynik -eq 1 ]
then
echo “Apache padl!”
/etc/rc.d/init.d/httpd restart
fi

Na koniec dla naszego pliku nadajemy prawa:

chmod 755 test-http

A następnie restartujemy cron-a. Dany skrypt można rozszerzyć o powiadamianie via mail lub SMS. Wszystko zależy od wyobraźni i zapotrzebowania