fsckup #2 - cat: /tmp/doit.sh: No such file or directory

Patryk Kuźmicz 1 Comment

W codziennej pracy często potrzebujemy zrobić coś szybko, skopiować jakieś dane do obróbki, uruchomić jakieś parsery mielące tony megabajtów i zwracające jeszcze więcej śmie^H^H^H^Hdanych, albo skompresować film na telefon, żeby umilić podróż w tramwaju czy pociągu ;-) Często wybór miejsca gdzie będzie przeprowadzona operacja pada na /tmp/. No bo gdzie będzie lepsze miejsce dla naszego skrypciku który generuje tysiące plików jak nie w /tmp/.

No i wszystko jest ok... do czasu kiedy nie zabraknie nam zasilania, lub nie wykonamy restartu desktopa... Wiele dystrybucji Linuksa domyślnie usuwa zawartość /tmp/ przy starcie systemu i wtedy jest płacz... zgrzytanie zębów, wyrywanie klawiszy, bo nie ma wyników parsera, a po filmach też śladu nie widać... Pół biedy kiedy w /tmp/ nie było nic ważnego... ;-) jako ciekawe doświadczenie sami sprawdźcie co tam aktualnie macie i czy nie byłoby Wam czegoś szkoda gdyby wasz śmietnik został opróżniony ;-)

Jeśli jednak masz wewnętrzną potrzebę umieszczania plików w /tmp/, to lepszym sposobem jest stworzenie w katalogu domowym własnego tmp i pracowania na nim, a nie na systemowym, ale jeśli takie rozwiązanie Cię nie zadowala, to możesz spróbować wyłączyć automagiczne czyszczenie /tmp/. W Ubuntu cała magia znajduje się w pliku /etc/default/rcS i nazywa się TMPTIME. Wartość tej zmiennej określa jak stare pliki mają być usuwane podczas bootowania systemu, wartość 0 powoduje, że usuwane są wszystkie pliki, wartość 10, da nam pewność, że żadne pliki młodsze niż 10 dni nie zostaną skasowane, natomiast wartość ujemna -1 wyłączy całkowicie operację czyszczenia /tmp/ podczas startu (więcej info w manualach: man 5 rcS).

Ktoś się na to naciął? ręka w górę!

fsckup #1 - kopia (nie)bezpieczeństwa

Patryk Kuźmicz 2 komentarze

Chciałbym tym wpisem zapoczątkować nową serię artykułów nazwanych potocznie [fsckup/fakap/fackup/itd...]. Nie będą to wpisy w stylu kopiuj/wklej, a może zadziała, będą to raczej informacje spisywane w luźnej formie nawiązujące do starego przykazania, “ucz się na błędach”... oczywiście najlepiej cudzych ;-)

Czym jest fsckup? Wpadką? Niedopatrzeniem? Brakiem doświadczenia? Karą za pośpiech lub lenistwo? Chyba wszystkim po trochu. Każdemu z nas się zdarzają, niekiedy są to drobiazgi, a czasami doprowadzają do poważnych awarii. Nie ma chyba administratora któremu się nie pomyliły nigdy polecenia, lub nie przewidział niepoprawnego działania aplikacji i doprowadził do zatrzymania systemu.

fsckup, będzie zbiorem porad, wskazówek, lub bardziej oficjalnie - zbiorem dobrych praktyk.

Kopia (nie)bezpieczeństwa... tak nazwałem pierwszy wpis, ponieważ chcę poruszyć kwestię wykonywania backup’ów  lub synchronizacji danych. Każdy z nas wie, że doskonale do takich robótek nadaje się rsync. rsync jest świetnym narzędziem któremu nie można zbyt wiele zarzucić, ale też powinniśmy wiedzieć, że niepilnowany potrafi się rozpastwić w systemie i wyssać z niego ostatnie bajty pamięci oraz takty procesora.

Klasyczna sytuacja może wyglądać następująco, administrator robi synchronizację danych, ale, że chce mieć spójne dane (czasami nawet bardziej spójne niż to możliwe), więc uruchamia rsync’a z cron’a co kilka minut. System działa świetnie, rsync przesyła dane rozgrzewając switche, dyski kręcą się aż miło... ale nadchodzi czarny dzień i maszyna z rsynciem przestaje odpowiadać. Sprint do konsoli i logujemy się... po 30 sekundach mamy terminal, ps axuw i czekamy minutę na wynik (!@#$w%t^f&). Przeleciały 3 ekrany rsync’ów... Kończy się restartem serwera, bo killall -9 rsync “nie robi”.

Po restarcie za dużo już nie widzimy, ale chwila głębszego zastanowienia i coś nam zaczyna świtać, że ostatnio maszyna miała trochę więcej do roboty, bo doszły jakieś logi (albo inne dziwne avi^H^H^Hpliki), no i ze 100 plików do synchronizacji, serwer miał ich 1000... nikt nie lubi tej chwili kiedy zdaje sobie sprawę, że nie przewidział jednej rzeczy... synchronizacja danych może trwać czasami dłużej niż 5 minut.

rsync robił swoje i starał się jak najlepiej, ale odpalał się nowy proces synchronizujący pomimo, że poprzedni nie skończył swojej roboty i problem narastał, aż skończyły się zasoby w systemie. Czy można było uniknąć takiej sytuacji? Prawdopodobnie tak ;-) wystarczyło zastosować proste lockowanie na pliku, np. napisać krótki skrypt a’la takie coś:

Shell
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#!/bin/bash
 
if [ -f /tmp/rsync.lock ]
then
echo "SPADAM... NIE MOJA KOLEJ";
exit 1;
fi
 
touch /tmp/rsync.lock
 
echo "KOPIUJE KOPIUJE KOPIUJE";
rsync -avh --progres ...
 
rm /tmp/rsync.lock
 
exit 0;
 

Jedne zdanie wytłumaczenia, skrypt się uruchamia, sprawdza czy istnieje plik /tmp/rsync.lock, jeśli nie istnieje to tworzy go i przechodzi do synchronizacji danych, po niej plik usuwa, tak więc w przypadku kiedy synchronizacja trwa dłużej niż 5 minut, kolejny uruchomiony skrypt wykryje plik /tmp/rsync.lock i zakończy od razu działanie.

Gdy mamy już nasze narzędzie do synchronizacji/backupu, to podpinamy je do cron’a, a nie bezpośrednio rsync’a, dodatkowo robimy sobie STDOUT na maila w razie niepowodzenia (np. plik lock’a istnieje) i wiemy na bieżąco co się dzieje.

Oczywiście nie jest to doskonały skrypt, jest to bardziej przedstawienie samej idei. Skrypt może sprawdzać dodatkowo, czy działa w systemie już proces rsync i jeśli nie ma takiego a plik /tmp/rsync.lock jest starszy niż 30 minut to go może usuwać, może też zapisywać datę uruchomienia rsync’a, kod wyjścia, itd... każdy sam wie najlepiej jakie dodatkowe funkcje będą mu przydatne.

Prawda, że proste i skuteczne...? ;-)

haproxy - czyli z ruchem HTTP zabaw kilka

Patryk Kuźmicz 2 komentarze

Wyobraźmy sobie sytuację, że mamy serwis z dość dużą oglądalnością, wszelkie optymalizacje już zawodzą, programiści przepisali 50% zapytań SQL, administratorzy baz danych wrzucili 75% jej zawartości do pamięci RAM, memcache robi się czerwony od ilości GET'ów a serwis i tak działa coraz wolniej... rozkładamy ręce i szukamy rozwiązania do balansowania ruchu na kilka serwerów.

Jak przystało na dobrego szperacza google'owego na pewno natrafiamy na informacje o LVSie, Big IP, Apache w trybie proxy, później pojawia się też jakiś Nginx, aż w końcu może trafimy na informacje o haproxy i to właśnie o tym narzędziu będzie ten wpis.

haproxy - jak możemy wyczytać z dokumentacji, jest to reverse proxy TCP/HTTP dla środowisk wysokiej dostępności, potrafiące m.in:

  • route'ować pakiety HTTP na podstawie zawartych Cookie
  • przełączać ruch na inny serwer w przypadku wykrycia awarii
  • blokować requesty HTTP na podstawie analizy nagłówków
  • generować statystyki ruchu/usług
  • modyfikować nagłówki HTTP w locie (coś dodać, coś usunąć, coś zmodyfikować)
  • zatrzymać przyjmowanie nowych połączeń bez zrywania nawiązanych
  • i wiele wiele więcej

Opiszę prosty przykład konfiguracji haproxy, który będzie można użyć do balansowania ruchu HTTP do dwóch serwerów.

Schemat:

  • xen2 - serwer z HTTP Apache - 192.168.1.241
  • xen3 - serwer z HTTP Lighttpd - 192.168.1.242
  • xen4 - serwer z HTTP Nginx - 192.168.1.124
  • xen7 - serwer z haproxy - 192.168.1.220

Nie chcę opisywać sposobu instalacji haproxy, bo każdy wybierze swoją drogę, apt-get install haproxy, emerge haproxy, wget haproxy-1.3.17.tar.gz; ./configure; make; make install, itd... ja używam Ubuntu server 8.04.2 i środowiska wirtualnego XEN, więc u mnie był apt-get ;-) mając zainstalowane haproxy, możemy zacząć konfigurację:

# vi /etc/haproxy.cfg

  • global - ustawienia typu logowania, ilości maksymalnej połączeń, uid'a, gid'a, itd...
  • default - ustawienia domyślne dla wszystkich usług frontend/backed.
  • listen - sekcja właściwa która nas będzie interesowała w tym momencie

Nasza przykładowa konfiguracja wygląda następująco:

root@xen7:~# cat /etc/haproxy.cfg

global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
user haproxy
group haproxy
defaults
log global
mode http
option httplog
option dontlognull
retries 3
redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
option httpclose

listen xen 192.168.1.220:80
balance roundrobin
server xen2 192.168.1.241:80
server xen3 192.168.1.242:80
server xen4 192.168.1.125:80

Czyli mamy sekcję listen (nazwa usługi xen) słuchająca na adresie IP load-balancer'a, na potrzeby tego opisu tak może być, ale najlepiej jest każdą usługę (klaster) bindować do innego adresu IP, balance roundrobin oznacza, że requesty będą rozdzielane kolejno do każdego node'a xen2, xen3, xen4 i niżej jest już sama definicja node'ów, server xen2, 3, 4, oraz IP do których należy przekierować requesty.

Uruchamiany daemona (dla testów w trybie foreground i debug):

root@xen7:~# haproxy -dV -f /etc/haproxy.cfg

Available polling systems :
select : pref=150, test result OK
sepoll : disabled, test result OK
epoll : disabled, test result OK
poll : disabled, test result OK
Total: 4 (1 usable), will use select.
Using select() as the polling mechanism.

Tak wiem polling przy wykorzystaniu select(), nie jest tym co nas zadowala, ale dla testów może być ;-) najwidoczniej paczka w Ubuntu była skompilowana z wyłączonym epollem ;-(

W praktyce 3 requesty wyglądają tak:

macbook:~ jamzed$ lwp-request -Sde xen7|grep Server
Server: lighttpd/1.4.19

macbook:~ jamzed$ lwp-request -Sde xen7|grep Server
Server: nginx/0.5.33

macbook:~ jamzed$ lwp-request -Sde xen7|grep Server
Server: Apache/2.2.8 (Ubuntu)

W konsoli widzimy debug:

00000002:xen.accept(0003)=0005 from [192.168.1.182:54865]
00000002:xen.clireq[0005:ffff]: GET / HTTP/1.1
00000002:xen.clihdr[0005:ffff]: TE: deflate,gzip;q=0.3
00000002:xen.clihdr[0005:ffff]: Connection: TE, close
00000002:xen.clihdr[0005:ffff]: Host: xen7
00000002:xen.clihdr[0005:ffff]: User-Agent: lwp-request/5.810
00000002:xen.srvrep[0005:0006]: HTTP/1.1 200 OK
00000002:xen.srvhdr[0005:0006]: Server: nginx/0.5.33
00000002:xen.srvhdr[0005:0006]: Date: Fri, 19 Jun 2009 17:32:57 GMT
00000002:xen.srvhdr[0005:0006]: Content-Type: text/html
00000002:xen.srvhdr[0005:0006]: Content-Length: 151
00000002:xen.srvhdr[0005:0006]: Last-Modified: Wed, 30 Aug 2006 10:39:17 GMT
00000002:xen.srvhdr[0005:0006]: Connection: close
00000002:xen.srvhdr[0005:0006]: Accept-Ranges: bytes

przychodzący request (GET / HTTP/1.1) - nagłówki od klienta xen.clihdr i pełną odpowiedź serwera xen.srvhdr.

Takim sposobem udało nam się szybko zrobić w prosty sposób load-balancer HTTP, jest to tylko ułamek tego co potrafi haproxy, w kolejnym wpisie pokażę kilka operacji na nagłówkach HTTP oraz jak "kierować" ruch HTTP do konkretnych node'ów na podstawie żądań GET (rozdzielanie ruchu w zależności od typu obiektu).

A jakie są Wasze preferencje co do balanserów? LVS? A może jakieś sprzętowe?

Marcowe spotkanie OWASP - PHP [live streaming]

Marcin Sawicki 1 Comment

Dzięki uprzejmości organizatorów OWASP Poland Local Chapter, mieliśmy przyjemność udostępnić wszystkim chętnym, a nie mogącym zjawić się osobiście streaming online.

Agenda spotkania:

  • 5:00pm - 5:05pm ... "OWASP News" - Przemysław Skowron
  • 5:05pm - 6:10pm ... "SQL Injection: complete walktrough (not only) for PHP developers" - Krzysztof Kotowicz
  • 6:15pm - 7:20pm ... "Secure PHP framework" - Łukasz Pilorz

Dla tych którzy nie oglądali transmisji na żywo, wkrótce pojawi się wideo do obejrzenia, obecnie czeka na zmontowanie wraz ze slajdami w dużo większej jakości ;-) Więcej informacji wkrótce.

Natomiast wszystkim oglądającym dziękujemy bardzo za wirtualne uczestnictwo, zdajemy sobie sprawę, że jakość wideo pozostawiała wiele do życzenia, ale obiecujemy popracować nad tym ;-) mamy nadzieję, że uda nam się spotkać już w niedalekiej przyszłości ;-)

Hawk!

Tunelowanie ssh

Marcin Sawicki 9 komentarzy

Tunelowanie SSH jest przesyłaniem nieszyfrowanego ruchu TCP (np. POP3 czy HTTP) poprzez bezpieczny protokół SSH. Do czego to może się przydać? Przecież powszechnie używa się HTTPS, FTPS czy POP3S, czyli 'bezpiecznych' wersji znanych protokołów. Otóż tunelowanie ma jedna wielka zaletę: możemy przesyłać jakikolwiek ruch w postaci nieczytelnej dla podglądaczy, co więcej - możemy go przesyłać decydując o portach z których skorzystamy. Jak nietrudno się domyślić ominięcie blokady portów czy ukrywanie swojej sieciowej działalności to tylko niektóre z ciekawych zastosowań tunelowania... No, ale po kolei :-)

SSH na dowolnym porcie
Przede wszystkim potrzebujemy zewnętrznej maszyny, która będzie drugim końcem naszego tunelu. Dla wygody dobrze mieć na niej roota, aby tunelować porty poniżej 1024. W przypadku gdy mamy zablokowany ruch wychodzący poza portami (przykładowo) 80 (http) i 443 (https), możemy wystawić na naszym serwerze słuchające SSH na którymś z tych portów, na przykład dodając w /etc/ssh/sshd_config:

Shell
0
1
2
3
 
Port 22         #pozostawiamy sobie standardowy port ssh
Port 443        #dodajemy 443 (zwykle HTTPS)
 

Podglądcze HTTP
Chcesz ukryć przed swoim providerem, jakie strony odwiedzasz? Nic prostszego - zestawiamy tunel do serwera, po czym w ustawieniach przeglądarki konfigurujemy serwer SOCKSv5 na localhost:8080.

Shell
0
1
2
 
ssh user@box -D 8080
 

Zablokowany Jabber
Zablokowany port XMPP? Konfigurujemy aplikację analogicznie jak w powyższym przykładzie, tj. podajemy jako serwer Jabbera localhost, port 1337 ;)

Shell
0
1
2
 
ssh -f -L 1337:talk.google.com:5222 root@rootbox -N
 

SSH za NAT? Reverse SSH Tunneling
Potrzebowałeś kiedyś połączyć się do komputera w domu, stojącego za NATem, nie posiadającego publicznego adresu? Otóż jest na to prosty sposób.

Shell
0
1
2
3
4
 
1. z maszyny za NATem: ssh -R 1337:localhost:22 root@rootbox
2. z rootbox: ssh localhost -p 1337
3. z zewn maszyny: ssh root@rootbox; ssh localhost -p 1337;
 

Połączenie SSH z NATowanego adresu do serwera musi być cały czas nawiązane, warto więc pamiętać o ustawieniu KeepAlive Yes oraz reconnecie w wypadku zerwania sessji.

Z jakich sprytnych zastosowań tunelowania korzystacie?

Przenosimy vhost'y Lighttpd do bazy danych MySQL

Patryk Kuźmicz 2 komentarze

Ostatnio pisałem o spięciu vsftpd wraz z MySQL'em, kolejnym etapem ułatwiania sobie życie może być spięcie naszego serwera WWW z bazą danych, ułatwi to w przyszłości zarządzanie systemami hostingowymi. Jak wspominałem w poprzednim wpisie, przenoszenie konfiguracji do bazy danych posiada bardzo dużą zaletę jeśli chodzi o centralizację informacji. Możemy tak zaprojektować bazę danych, by przechowywać w niej zarówno vhost'y, użytkowników czy domeny. Takim systemem daję się później zarządzać bez problemów przez prostą stronę WWW, dodatkową zaletą jest to, że nasi użytkownicy mogą sami podpinać kolejne domeny, zakładać nowe konta, czy zmieniać hasła.

Dziś wypadło na Lighttpd + MySQL. Tradycyjnie zaczniemy od instalacji niezbędnych pakietów:

root@iDev:/home/jamzed# apt-get install lighttpd lighttpd-mod-mysql-vhost mysql-server mysql-client

Mając już działającą bazę danych, możemy przejść do założenia użytkowników i struktury tabel:

root@iDev:/home/jamzed# mysql -uroot -p

CREATE DATABASE lighttpd;
GRANT SELECT ON lighttpd.* TO lighttpd@localhost IDENTIFIED BY 'lighty123';

USE lighttpd;

CREATE TABLE domains (
domain varchar(64) not null primary key,
docroot varchar(128) not null
);

Stworzyliśmy właśnie bazę danych lighttpd, dodaliśmy użytkownika lighttpd z hasłem lighty123 oraz stworzyliśmy tabelę domains (pierwsze pole zawiera domenę, drugie katalog w którym będzie umieszczona strona). Od razu możemy dodać jakiś testowy vhost:

root@iDev:/home/jamzed# mysql -uroot -p
USE lighttpd;
INSERT INTO domains VALUE('testowa.pl','/var/www/testowa.pl/');

Dodaliśmy właśnie pierwszą domenę do naszego systemu, przechodzimy teraz do konfiguracji lighttpd.

root@iDev:/home/jamzed# vi /etc/lighttpd/lighttpd.conf

Musimy dodać nasz moduł MySQL vhost do konfiguracji, robimy to dodając wpis w sekcji server.modules, całość powinna wyglądać mniej więcej tak:

server.modules              = (
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_mysql_vhost"
)

Przechodzimy teraz na koniec pliku z konfiguracją i dodajemy konfigurację do połączenia się z bazą danych:

mysql-vhost.db = "lighttpd"
mysql-vhost.user = "lighttpd"
mysql-vhost.pass = "lighty123"
mysql-vhost.sql = "SELECT docroot FROM domains WHERE domain='?';"
mysql-vhost.hostname = "localhost"
mysql-vhost.port = 3306

  • mysql-vhost.db - oznacza nazwę bazy danych
  • mysql-vhost.user - użytkownik na którego się łączymy
  • mysql-vhost.pass - hasło do bazy
  • mysql-vhost.sql - określamy nasze zapytanie SQL, odpowiedź musi być document root'em
  • mysql-vhost.hostname - host na którym działa baza danych
  • mysql-vhost.port - port na którym słucha nasza baza

Załóżmy teraz katalog /var/www/testowa.pl i stwórzmy plik index.html:

root@iDev:/home/jamzed# mkdir /var/www/testowa.pl
root@iDev:/home/jamzed# echo "testowa.pl" > /var/www/testowa.pl/index.html

Spróbujmy zrestartować serwer i sprawdźmy czy wszystko działa poprawnie:

root@iDev:/home/jamzed# telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET / HTTP/1.0
Host: testowa.pl

HTTP/1.0 200 OK
Content-Type: text/html
Accept-Ranges: bytes
ETag: "1628042861"
Last-Modified: Sun, 07 Mar 2010 15:45:17 GMT
Content-Length: 11
Connection: close
Date: Sun, 07 Mar 2010 15:46:35 GMT
Server: lighttpd/1.4.22

testowa.pl
Connection closed by foreign host.

Jak widać, połączenie z serwerem udało się, następnie wysłałem żądanie o stronę główną (/), prosząc o stronę dla hosta testowa.pl i w odpowiedzi otrzymałem ciąg znaków "testowa.pl", tak więc wszystko działa poprawnie. Zapraszam do głosowania w ankiecie:

[poll id="6"]

LOG-owanie myśli

Tadeusz Polak 3 komentarze

Chwilę czasu temu nurtował mnie fakt nieposiadania spisanych moich "szybkich myśli" w jednym miejscu. Często jeżdżąc samochodem, podróżując w pociągu, spacerując - ogólnie tam gdzie jestem - wpadałem na pomysły które w danej chwili wydawały mi się przydatne oraz te nad którymi będę mógł spędzić kolejne 10 minut aby stwierdzić czy warto zagłębiać się w temat, pech sprawiał że zostawiałem to na później i dalej zapominałem o "genialnych pomysłach" - potrzebowałem magazynu na te śmieci. To że jestem trochę leniwy i noszenie ze sobą notesu lub jakiejś kartki z długopisem sprawiało mi trudność, rozpocząłem poszukiwania odpowiedniego oprogramowania które spełni moje oczekiwanie w taki sposób aby nie zaburzuć ciągłości pracy w danym momencie - przynajmniej w pracy i w domu.
Przedstawione przezemnie poniżej narzędzie nie spełnia tego wszystkiego co napisałem ( w szczególności mobilnej strony, no może poczęści ) - ale dynamicznie się rozwija i pewnie wkrótce na większości platform się pojawi.

Kryteria jakimi się kierowałem w poszukiwaniu:

  • Bardzo szybki w działaniu
  • Prostota: najwięcej 1-2 kliknięcia, ale nie myszką ( bo to rozprasza ) - na klawiaturze
  • Grupy notek
  • Oprogramowanie mobilne
  • W późniejszym czasie : Synchronizacja on-line

Znalazłem - Tomboy - tą aplikację chciałbym Wam przestawić.
Dla tych co jej nie znają - jest to jedna z bardziej popularnych aplikacji do tworzenia notek, prostota jej działania oraz akceptacja styli daje znaczną przewagę nad innymi tego pokroju aplikacjami.
Dostępna dla Linux'a, OS X'a oraz Windowsa oraz w produkcji pod Androida oraz szkice pod iPhona.

W aplikacji tej można przypisać konkretne klawisze aby:

  • Tworzyły nowe notki
  • Pokazywały aktualne
  • Wyszukiwały we wszyskich

Przypisanie jednego klawisza np. funkcyjnego optymalizuje naszą pracę z notkami - w przypadku pracy na konsoli, tworzenia innych dokumentów nie rozpraszamy się wciskając wklejając co nas intersuje a zapisuje się nieśmiertelnym "Esc".

Aby całość miała smaczek - dochodzi do tego synchronizacja Online. W tym celu powstaje projekt Snowy napisany w pythonie i wykorzystujący Framework Django. Funkcjonalności w zarządzaniu:

  • użytkownikami oraz grupami użytkowników
  • tokenami dla użytkowników
  • notkami

A do tego wszystkiego można notki te przeglądać poprzez stronę WWW.

Możliwość przechowywania notek w różnych bazach: sqlite3, mysql, postresql oraz oracle daje nam wybór ulubionej bazy.
Snowy w swojej konfiguracji umożliwia:

  • zdefiniowanie listy notek na stronie użytkownika
  • czasy przechowywanych tokenów w celu aktywacji konta
  • capcha
  • osobne templaty dla notek
  • i wiele innych

Instalacja Snowy jest banalna. Oprócz tego co wymaga sama aplikacja należy uruchomić konfiuratora bazy danych który zapyta się o kilka istotnych (min. login admin oraz hasło ) rzeczy i wgra schematy.

python manage.py syncdb

na koniec:

python manage.py runserver

należy pamiętać - że domyślnie uruchamia się serwer na localhost:8000, aby to zmienić w parametrze należy podać pełną nazwę serwera:
np.

python manage.py runserver varlog.pl:4000

Aby nie być gołosłownym zapraszam do testowania synchronizacji notek: http://freebsd.com.pl:4000/
Po utworzeniu konta notki można przeglądać pod adresem: http://freebsd.com.pl:4000/<user>/notes

No i jak ? Daje rade ?

Rysujemy wykresy, czyli długofalowy monitoring serwerów

Patryk Kuźmicz 12 komentarzy

Administracja serwerami to nie tylko reakcje na wszelkie awarie, nieprzewidziane zdarzenia w systemie, czy restarty aplikacji. Administracja to przede wszystkim monitorowanie pracy serwerów zarówno podczas normalnych warunków (stałe obciążenie) jak i awarii (bardzo duże obciążenie, problemy z serwerem). Często o problemie dowiadujemy się gdy już wystąpi, a zdecydowanie lepiej byłoby gdybyśmy mogli w jakiś sposób przewidzieć, że w najbliższym okresie czasu coś może się stać, a w szczególności, żebyśmy byli w stanie zapobiegać tym najgłupszym awariom, związanych z brakiem zasobów, czy to miejsca na dysku, czy pamięci.

Możemy z łatwością monitorować parametry serwera i zapisywać wyniki do plików, ale nikt tego nie będzie analizował... dużej ilości danych zapisanych w postaci tekstowej nie potrafimy przetworzyć w sposób niezbędny do przewidzenia problemów, do tego doskonale nadają się wszelkie narzędzia potrafiące generować wykresy (munin, cacti, graphviz).

Generując wykresy z zebranych danych otrzymujemy możliwość analizy w czasie zmian w charakterystyce pracy naszego serwera, w godzinach dużego ruchu zobaczymy większe zużycie pamięci, powoli ubywające wolne miejsce z dysków, lub wykorzystanie pamięci zbliżające się do limitów. Dzięki temu będziemy w stanie przewidywać, co się stanie jeśli ruch zwiększy się 2x, albo czy możemy jeszcze uruchomić kolejny serwer gry Counter Strike.

Wraz z upływem czasu, zbierając kolejne informacje, będziemy w stanie ocenić obecną sytuację z tą sprzed miesiąca i na podstawie wykresu będzie na łatwo ocenić, czy przy normalnej pracy potrzebujemy rozbudowywać storage, pamięć, czy przenosić się na nowy mocniejszy serwer. Powiedziałbym nawet, że nie da się skutecznie administrować serwerami bez łatwego podglądu zmian parametrów pracy serwera. Codzienna obserwacja łatwych w analizie wykresów pozwoli nam reagować jeszcze przed wystąpieniem problemu, bo przyznacie sami, że zatrzymanie się serwera httpd z powodu braku wolnego miejsca na dysku jest idiotyczną awarią.

Po krótce chcę Wam przedstawić narzędzie bardzo szybkie do wdrożenia, konfiguracja zajmuje < 10 minut, a po uruchomieniu będziemy mieli świetne statystyki... Przed Wami - Munin. ;-)

Instalacja Munin’a w Ubuntu
root@iDev:/home/jamzed# apt-get install munin

Munin składa się z dwóch podstawowych aplikacji, munin-node i munin:

  • munin-node - jest to daemon który wystawia dane dla podpiętych usług
  • munin - jest aplikacją która pobiera dane z node'ów
  • munin-cron - proces zbierający dane co 5 minut (dopisany do crontaba /etc/cron.d/munin)

Możemy mieć jeden centralny serwer z muninem i wiele munin-node'ów, z których będziemy pobierać dane. Po uruchomieniu daemon'a już następuje zbieranie danych, to co jest monitorowane określamy poprzez umieszczenie linku symbolicznego lub bezpośrednio skryptu/programu w katalogu /etc/munin/plugins/, standardowo znajdują się już podpięte usługi takie jak pamięć, cpu, interfejsy sieciowe, dyski. Munin dostarcza od razu po instalacji wiele gotowych skryptów, wszystkie znajdują się w katalogu /usr/share/munin/plugins/.

Konfigurujemy praktycznie jedynie htmldir (/var/www/munin), jest to katalog w którym będzie generowana strona z naszymi statystykami, jest to DocumentRoot który podajemy w konfiguracji serwera WWW, poniżej mamy listę podpiętych node'ów z których zbieramy statystyki. Prosta budowa munina pozwala na dopisywania różnych wtyczek samemu, wystarczy po prostu zwracać dane w takiej postaci:

root@iDev:/etc/munin/plugins# ./test
testowa.value 20

Przykładowy kod wtyczki może wyglądać następująco:

Perl
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#!/usr/bin/perl
 
if ( $ARGV[0] =~ /autoconf/ ) {
  print "yesn";
exit(0);
}
 
if ( $ARGV[0] =~ /config/ ) {
  print "graph_title Wartosc testowan";
  print "graph_vlabel testn";
  print "testowa.label testowan";
  exit(0);
}
 
$random = int(rand(100));
print "testowa.value $randomn";
exit(0);
 

Więcej szczegółów dot. pisania własnych pluginów znajdziecie tutaj: http://munin.projects.linpro.no/wiki/HowToWritePlugins.

Aby monitować nowe elementy należy podpiąć taki skrypt (np. ln -s /usr/share/munin/plugins/test /etc/munin/plugins/test), wykonać restart munin-node'a i wykresy powinny już automatycznie rysować się dla naszej nowej usługi. Możemy sprawdzić czy nowa wtyczka zwraca poprawnie dane:

root@iDev:/etc/munin/plugins# telnet 127.0.0.1 4949
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
# munin node at serwer_monitorowany
list
open_inodes test if_err_eth0 irqstats entropy mysql_slowqueries if_eth0 processes mysql_threads df interrupts swap mysql_bytes load cpu df_inode mysql_queries iostat open_files forks memory vmstat
fetch test
testowa.value 32

  • list - zwraca wszystkie podpięte wtyczki
  • fetch $nazwa_wtyczki - pobiera aktualne dane dla niej

Inny sposób to po prostu wykonanie polecenia munin-run:

root@iDev:/etc/munin/plugins# munin-run test
testowa.value 57

Wynik na wykresie prezentuje się następująco:

Możliwości tego co i jak monitorujemy są nieograniczone, a dane prezentowane na wykresach są bardzo łatwe w analizie, więc zachęcam Was wszystkich do korzystania z gotowych narzędzi i monitorowania wszystkiego co się tylko da. ;-)

[poll id="5"]

Zapraszam do dopisywania w komentarzach innych narzędzi których używacie do monitorowania oraz generowania wykresów.

Prawo jazdy a Internet

Patryk Kuźmicz 6 komentarzy

Jestem użytkownikiem Internetu, oprócz mnie jest wielu innych, ja włączam przeglądarkę, czy to Firefox, czy to Safari, wpisuję adres strony i po chwili mogę ją oglądać, ale są też tacy którzy włączają internet kliknięciem w magiczną niebieską literkę “e” i oglądają strony w wyszukiwarce… Czy to jest śmieszne? Może było, ale w dzisiejszych czasach nie jest i nie powinno być.

Kiedyś chciałem móc jeździć samochodem i jedynym wyjściem zgodnym z prawem było zdobycie prawa jazdy, zapisałem się więc na kurs, odczekałem kulturalnie “swoje” w kolejce, regularnie uczęszczałem na zajęcia teoretyczne na których poznałem przepisy ruchu drogowego, a raczej kazano mi się ich nauczyć, a dopiero po opanowaniu teorii zacząłem jazdę z instruktorem prawdziwym samochodem po prawdziwych drogach, gdzie stwarzałem prawdziwe zagrożenie, oraz byłem narażone na prawdziwe kolizje. Po ukończeniu kursu i zdaniu egzaminów za pierwszym razem, wsiadłem sam do samochodu, przejechałem kilkaset metrów i zdałem sobie sprawę, że nie umiem jeździć.

Czytając wiadomości, czy rozmawiając z ludźmi coraz częściej mam wrażenie, że do poruszania się w Internecie powinny być wymagane uprawnienia, nie tylko dla własnego dobra, ale przede wszystkim innych użytkowników, analogicznie jak na drodze. Skojarzył mi się pewien cytat który w tej sytuacji znajduje odzwierciedlenie – “Są dwie naprawdę bezgraniczne rzeczy – Wszechświat i ludzka głupota, co do Wszechświata nie jestem całkiem pewien. Albert Einstein”. Nie od dziś wiadomo, że Internet to nie tylko przyjemności a także duże problemy, oszustwa związane z aukcjami internetowymi, oszustwa bankowe, kradzież danych osobowych, bluźnierstwa, pogróżki, pornografia, piractwo, etc. Każdy o tym wie! Każdy o tym słyszał, przeczytał, ale do wielu to nie dociera… być może to trochę nasza mentalność w tym przeszkadza, przecież mi się to nie przytrafi… chwila refleksji… i potwierdzenie, na pewno nie przytrafi, mam program antywirusowy… mam? chyba mam, świeci tam na dole na pasku… no i dla większego usprawiedliwienia, można sobie przypomnieć, że są też zainstalowane najnowsze łatki w systemie. Problem w tym, że to nie wszystko… te zabezpieczenia są nic nie warte, jeśli brakuje jednej rzeczy, umiejętności myślenia.

Czytając, że pani XYZ została oszukana przez spamera z Nigerii, który obiecał jej kokosy za kilka miesięcy w zamian za kilka tysięcy złotych, krzywo uśmiecham się pod nosem… i nawet sam nie wiem czy jej współczuję. Internet to nie jest magiczna skrzynka pełna dobrodziejstwa, czy życzliwych ludzi, Internet to doskonałe miejsce do przekrętów, to miejsce do zarabiania pieniędzy na naiwnych… Nikt tutaj nie rozdaje za darmo pieniędzy, nikogo tutaj nie obchodzi anonimowy obywatel, nikt tutaj nie wygrywa miliona dolarów tylko za to, że odebrał pocztę.

By móc korzystać swobodnie z Internetu, tzn. umieć wyczuwać zagrożenia, moim zdaniem niezbędna jest dobra edukacja… Wielu użytkowników intuicyjnie rozumie problem, nie klika w co nie trzeba, pomija strony które wyglądają na niebezpieczne, omija niebezpieczeństwo szerokim łukiem, ale wiele osób siadających do komputera totalnie nie zdaje sobie z tego sprawy, nie żyją siecią, nie czują tego, nikt ich nie uczył jak rozpoznawać spam… a w dużej mierze wystarczy przecież przełożyć daną sytuację na życie codziennie i podjąć właściwą decyzję. Odpowiednia edukacja, zaczynając od szkoły mogłaby ułatwić nieco bezpieczne poruszanie się w sieci, ale zajęcia musiałyby być prowadzone przez ludzi z kompetencjami a nie 50 letnich nauczycieli techniki przekwalifikowanych na super informatyków.

TV nagłaśniając oszustwa internetowe powoduje często jakieś lekkie paniki wśród ludzi, zamiast rzetelnie informować o zagrożeniu i sposobach minimalizowania… Komputery podatne na atak! Znaleziono lukę w oprogramowaniu! Złapano spamera! Przejęto botnet! itd… Nie twierdzę, że każdy musi być geekiem, żeby móc korzystać z Internetu, ale uważam, że każdy tak jak potrafi czytać, pisać, rozmawiać powinien zdawać sobie sprawę z zagrożeń jakie mogą go spotkać w Internecie, powinien się dwa razy zastanowić zanim poda swoje dane osobowe, trzy razy powinien przemyśleć zanim wyśle komuś pieniądze, a przede wszystkim powinien logicznie myśleć poruszając się w sieci i wiedzieć, że nikt tu nie jest bezpieczny.

Prezentowane powyżej treści są jedynie moją prywatną opinią, jeśli ktoś poczuł się urażony, lub stracił czas na czytanie, niech wie, że serdecznie NIE przepraszam.