Geolokalizacja, czyli sprawdzamy skąd pochodzi dany IP

Patryk Kuźmicz 3 komentarze

Tworzysz serwis WWW i chciałbyś mieć możliwość sprawdzenia z jakiego kraju jest użytkownik, lub przykład bardziej dotyczący administratorów, chciałbyś sprawdzić z jakiego kraju są adresy IP pojawiające się w logach. Rozwiązaniem na to jest wykorzystanie geolokalizacji, czyli bazy danych która zawiera informację o puli IP oraz kraju z nią powiązaną. W Internecie znajdziesz kilka takich baz, my skupimy się na jednej która w wersji darmowej do wykorzystania w projektach (GPL/LGPL) daje nam dokładność rzędu 99.5%, jest to baza firmy MaxMind.

Kolejnym argumentem przemawiającym na korzyść tej bazy jest API, które jest dostępne na wiele platform:

  • C
  • Perl
  • PHP
  • Apache (mod_geoip)
  • Java
  • Python
  • C#
  • Ruby
  • MS COM
  • VB.NET
  • Pascal
  • Javascript

Od czego zacząć? W zależności od języka w jakim będziemy chcieli obsługiwać bazę musimy pobrać konkretny zestaw bibliotek lub modułów dla API, w przykładzie wykorzystam bazę w skrypcie PHP.

Pobieramy bazę Geo:

$ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz

Jeśli będziemy chcieli odczytać również miasto to musimy pobrać dodatkową bazę GeoLiteCity:

$ wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

Musimy jeszcze wypakować bazy i przenieść do odpowiedniej lokalizacji:

$ gzip -d GeoIP.dat.gz
$ gzip -d GeoLiteCity.dat.gz
# mkdir /usr/share/GeoIP
# mv GeoIP.dat /usr/share/GeoIP/GeoIP.dat
# mv GeoLiteCity.dat /usr/share/GeoIP/GeoIPCity.dat

Alternatywnym sposobem jest instalacja bazy danych GeoIP z repozytorium:

# apt-get install geoip-database

Ale należy wtedy mieć na uwadze to, że taka baza nie musi być aktualna, MaxMind podaje, że aktualizuję bazę raz w miesiącu, więc pobranie jej bezpośrednio ze strony daje większą gwarancję, że baza będzie świeża.

W przypadku kiedy baza będzie pracowała pod obsługą PHP, musimy zainstalować moduł php5-geoip (Ubuntu 10.04):

# apt-get install php5-geoip

Istnieje co prawda, możliwość wykorzystania bazy bez instalowania modułu, jest rozszerzenie PEAR do tego, ale jest w fazie BETA i za bardzo chyba nikt nie chce go rozwijać, dla zainteresowanych link.

Posiadając moduł do PHP i bazę w odpowiedniej lokalizacji, możemy napisać skrypt który zamieni podany adres IP na kraj oraz miasto, ja użyję print_r dla pokazania jakie informacje możemy uzyskać:

PHP
0
1
2
3
4
5
6
7
 
<?php
  $ip = $argv[1];
  print_r(geoip_country_name_by_name($ip));
  echo "n";
  print_r(geoip_record_by_name($ip));
?>
 

  • geoip_country_name_by_name - wymaga bazy GeoIP.dat
  • geoip_record_by_name - wymaga dodatkowej bazy GeoCity.dat

$ php ip.php www.varlog.pl
Poland
Array
(
[continent_code] => EU
[country_code] => PL
[country_code3] => POL
[country_name] => Poland
[region] => 29
[city] => Myszków
[postal_code] =>
[latitude] => 50.583301544189
[longitude] => 19.35000038147
[dma_code] => 0
[area_code] => 0
)

Dokładny opis wszystkich pozostałych funkcji modułu geoip, można znaleźć w dokumentacji.

Czerwcowe spotkanie OWASP [live stream]

Patryk Kuźmicz 1 Comment

Dziękujemy wszystkim oglądającym transmisję z krakowskiego spotkania OWASP Poland.

18:00 – 18:15 “OWASP News” – Przemyslaw Skowron
18:15 – 19:10 “Creating, obfuscating and analysis of JavaScript-based malware” – Krzysztof Kotowicz
19:15 – 20:00 “Network Forensic: what captured packets say” – Paweł Goleń

Zmontowane video pojawi się wkrótce. Stay tuned ;-)

Czerwcowe spotkanie OWASP

Patryk Kuźmicz Leave a Comment

Już w najbliższy czwartek 10 czerwca (jutro), o godzinie 18:oo w Wydziale Fizyki i Informatyki Stosowanej AGH odbędzie się spotkanie OWASP. Tak jak poprzednio, spotkanie jest zorganizowane wspólnie z ISSA Polska. Oprócz ciekawych prelekcji będzie kilka niespodzianek m.in. konkurs z nagrodami prosto z USA. ;-)

agenda spotkania:
18:00 - 18:15 ... "OWASP News" - Przemyslaw Skowron
18:15 - 19:10 ... "Creating, obfuscating and analysis of JavaScript-based malware." - Krzysztof Kotowicz
19:15 - 20:00 ... "Network Forensic: what captured packets say" - Paweł Goleń

Tworzenie, zaciemnianie i analiza złośliwego kodu JavaScript - Krzysztof Kotowicz

o prelegencie: Web developer, specjalizuje się w tworzeniu rozwiązań e-commerce oraz portali internetowych z wykorzystaniem PHP 5. Freelancer, pracuje także w polskim portalu medycznym Medycyna Praktyczna. Jego głównym obszarem zainteresowań są zagadnienia bezpieczeństwa aplikacji internetowych oraz usprawnienia procesu tworzenia oprogramowania.

abstrakt
Ataki malware'u na przeglądarki nieświadomych internautów stają się coraz powszechniejsze. Wciąż powstają nowe techniki pozwalające obejść filtry stosowane przez producentów oprogramowania zabezpieczającego. Z kolei filtry są coraz lepsze, powstają też nowe narzędzia - walka trwa. Na prezentacji dowiecie się, jak włamywacze usiłują utrudnić pracę analizatorom ich kodu i jak reverserzy sobie z tym radzą. Nacisk zostanie położony na słabości narzędzi automatycznych - będziemy usiłowali uniknąć wykrycia przez jsunpack i Capture-HPC, oszukamy też popularny unpacker Deana Edwardsa.

Network Forensic: co mówią schwytane pakiety - Paweł Goleń

o prelegencie: Obecnie pentester zajmujący się głównie testowaniem aplikacji internetowych. W międzyczasie dla rozrywki zajmuje się (nie tak bardzo) innymi tematami jak analiza malware czy network oraz computer forensic.

abstrakt
Na poprzednim spotkaniu OWASP rozmawialiśmy o malware, między innymi o atakach "drive-by downloads". Tym razem kontynuacja tematu, prezentacja pokazuje co o tego typu incydentach można dowiedzieć się z zapisanego ruchu sieciowego. Jak na jego podstawie odtworzyć przebieg zdarzeń?

Miejsce spotkania

Wydział Fizyki i Informatyki Stosowanej AGH
Kraków, ul. Reymonta 19, budynek D-10
Sala: A (aula)

Zapraszamy serdecznie wszystkich zainteresowanych.

Dla tych którzy nie będą mogli przybyć na miejsce, spróbujemy nadać transmisję na żywo ze spotkania, więcej informacji (link do streamingu) podamy jutro na stronie varlog'a w okolicy godz. 18.oo.

Testuj, zanim będzie za późno

Patryk Kuźmicz 1 Comment

Oddając do użytku skończoną platformę, powinieneś znać jej możliwości, wiedzieć jaki jest w stanie obsłużyć ruch bez palenia procesorów, kart sieciowych czy dysków, znać miejsca potencjalnie podatne na “wąskie gardła”, wiedzieć czy i gdzie znajduję się z angielskiego tak ładnie nazywany SPoF (Single Point of Failure), wiedzieć o niej tak dużo jak się da. Oczywiście najlepiej byłoby gdyby, platforma była łatwo i bez ograniczeń skalowalna, bezawaryjna, bezobsługowa, samowystarczalna i robiła jeszcze kawę... ale na szczęście jesteśmy realistami i wiemy, że takie w naturze zbyt często nie występują, a przynajmniej nie powstały od razu, tylko były dopieszczane długimi godzinami, tak więc na ma co się zniechęcać, tylko trzeba usiąść i pomyśleć co zrobić, żeby mogło być lepiej, a od czego zacząć? Od naszych “ulubionych” testów.

Wszystko ok... tylko, że platforma którą zrobiłeś nie daje się łatwo przetestować, jest to rozwiązanie szyte na miarę, nie istnieje żadne automagiczne narzędzie (przetestuj_moja_platforme.sh) które uruchomione coś przemieli, pomieli i wypluje jednoznaczny wynik, tak to zła wiadomość... Yhyy, ja też zawsze szukam wymówek, ale nie oszukujmy się, co stoi na przeszkodzie by opierając się nawet na istniejących rozwiązaniach spróbować stworzyć własne? Nie mówię tutaj o napisaniu swojego jMeter’a, czy ab... ale bardziej o odpowiednim zestawieniu kilku prostych i dobrze nam znanych aplikacji. Czasami okaże się, że wystarczy (time, cat, netcat). A jeśli potrafisz szukać informacji (zakładam, że tak) to znajdziesz przykłady skryptów np. w Perlu, które tworzą socket, wysyłają coś i pobierają odpowiedź, ubierz to w pętlę, dodaj forkowanie, dorzuć jakiegoś if’a całość opakuj funkcjami time i już masz proste narzędzie do testowania, nie przejmuj się tym, że nie jest to rozwiązanie profesjonalne (who cares?), ważne, że dzięki niemu będziesz posiadał informację, której jeszcze chwilę temu nie miałeś. Podejdź do całości procesu w ten sposób, że lepiej jest posiadać wyniki obarczone nawet sporym błędem niż żadne. Orientacyjne wartości też będą dla Ciebie wskazówką, dodatkowo podczas jednego testu, może okazać się, że poznasz wyniki dla zupełnie innego, np. testując aplikację uda Ci się tak obciążyć serwer, że pojawi się problem z dostępem do dysku lub skończy się pamięć.

Wszystkie wyniki zapisuj, otwórz plik tekstowy, kopiuj i wklejaj wszystko do niego, argumenty wywołania, zbędne informacje, po prostu wszystko jak leci... Może Ci się wydawać, że zapamiętasz część danych, ale po setnym uruchomieniu wszystko ma prawo się pomieszać. Jeśli nazbierasz wiele próbek to spróbuj zrobić wykresy z tego, jeśli znasz rrdtool to użyj go, jeśli tworzenie baz RRD to czarna magia dla Ciebie, to przenieś wszystkie dane do arkusza kalkulacyjnego i zrób w nim wykres, to nie jest żaden obciach, że używasz OpenOffice, czy Excel, bądź skuteczny, a nie “poprawny”. Zauważysz, że czasami dopiero po zobrazowaniu dużej ilości zebranych danych widać, że aplikacja działa doskonale, ale dla 25 użytkowników, natomiast powyżej tej liczby wydajność spada dwukrotnie. Nie wszystko widać od razu.

Testuj tak by jak najbardziej możliwie odwzorować realne warunki pracy, np. jeśli chcesz sprawdzić swoje dyski na które będą lądowały ładowane zdjęcia od użytkowników, to nie kopiuj na nie filmów, nie licz ile czasu to zajmie, kopiuj dużo małych plików, zbliżonych rozmiarem do zdjęć, bo jeśli nie zachowasz podczas testów w miarę realnego odwzorowania sposoby pracy, to Twoje wyniki nie są nic warte. Zawsze staraj się testować w taki sposób, by jak najbardziej możliwie zbliżyć się do realnej pracy systemu.

Po co to wszystko? Nie dlatego, że ktoś wcześniej czy później poprosi Cię o te dane, ale po prostu dla własnego spokoju, by wiedzieć, że nie stworzyło się potwora, do którego będziemy musieli przyszywać kolejną rękę wraz z dodaniem funkcjonalności. Musimy wyrobić w sobie nawyk, by znać dość dobrze możliwości systemów które uruchamiamy, bez tych podstawowych informacji nie możemy skutecznie nimi zarządzać, ponieważ taka administracja sprowadza się do usuwania awarii a nie do zapobiegania im, a znając ograniczenia, nawet nie dokładne, ale przybliżone, da to nam informację po jakim czasie będziemy musieli zastanowić się nad dokupieniem kolejnego serwera, lub wykonaniem optymalizacji. Wszystkie zebrane informacje powinny być przede wszystkim wykorzystywane przy monitorowaniu usług, jeśli sprawdzasz czy usługa dana działa, to sprawdź przy okazji jak wygląda jej wykorzystanie, porównaj to z wynikami testów i będziesz wiedział czy to właśnie już trzeba pisać zamówienie na serwer, czy dopiero po wakacjach... ;-)

Czasami naprawdę warto wykonać testy, chociażby po to by kupić sobie spokój, wiem, że to nie jest najciekawsze zajęcie, ale lepiej poświęcić trochę czasu na testy i wiedzieć co się dzieje, niż później w stresie w trybie natychmiastowym podejmować decyzje, rzadko kiedy słuszne...

- przepraszam za przynudzanie ;-)

Q&A - czym jest kod wyjścia programu?

Patryk Kuźmicz 1 Comment

Kod wyjścia programu jest wynikiem zakończenia naszej aplikacji. Jest to wartość która jest zwracana do środowiska systemowego i dzięki niej możemy się dowiedzieć, czy program zakończył się poprawnie, czy też nie. Najczęściej stosuje się kod = 0, exit(0) jeśli nie wystąpił żaden błąd, wartości różne od 0 (przedział 0-255) powinny sygnalizować nieprawidłowe działanie aplikacji. Ale co to nam daje w praktyce? Najprostszy przykład to np. uruchamianie polecenia i sprawdzenie wyniku:

$ touch test; cat test; echo $?
0

$? - w BASHu pod tą zmienną jest umieszczany kod wyjścia ostatnio uruchomiego programu (w tym przypadku: cat test), echo $? powoduje wyświetlenie go, jeśli wykonamy dwa razy pod rząd echo $?; echo $? to drugie polecenie echo zwróci kod wyjścia z pierwszego echo $?, więc nasz prawdziwy kod wyjścia zostanie nadpisany, jeśli chcemy kilka razy użyć tego samego kodu, powinniśmy przypisać go do zmiennej i operować na niej np. RET=$?; echo $RET; echo $RET;

Wróćmy do naszego przykładu widać, że kod wyjścia wynosi 0, program zakończył się poprawnie, sprawdźmy co się stanie, jeśli spróbujemy wyświetlić nieistniejący plik.

$ cat plik_ktorego_nie_ma; echo $?
cat: plik_ktorego_nie_ma: No such file or directory
1

Widać, że kod wyjścia wynosi 1, czyli już wiemy, że coś poszło nie tak, w tym przypadku plik po prostu nie istniał i sytuacja jest prosta.

Jak sprawić by nasz program zwracał odpowiedni kod wyjścia? Używa się do tego funkcji exit($kod_wyjścia), czyli w naszej aplikacji obsługujemy różne wyjątki i jeśli wiemy, że jakaś sytuacja jest niepoprawna, używamy np. exit(1), poniżej krótki Perlowy przykład:

Perl
0
1
2
3
4
5
6
 
#!/usr/bin/perl
 
$kod = $ARGV[0];
print "exit code: $kodn";
exit($kod);
 

Program, pobiera jako argument liczbę i kończy działanie ustawiając ją jako kod wyjścia, sprawdźmy:

$ ./showCode.pl 0
exit code: 0
$ echo $?
0

$ ./showCode.pl 40
exit code: 40
$ echo $?
40

Odpowiednio obsługując wyjątki w programie jesteśmy w stanie dowiedzieć się jaki był rezultat jego uruchomienia, czy wszyscy powiodło się, lub czy wystąpił jakiś problem, obsługa kodów wyjścia jest bardzo ważnym elementem i jeśli np. piszemy skrypt w którym jedne polecenie przekazuje swój wynik następnemu zawsze powinniśmy upewnić się czy polecenie zakończyło się poprawnie, przed uruchomieniem kolejnego.

VPS dla minimalistów

Marcin Sawicki 2 komentarze

Kilka dni temu pojawił się u nas test 2host.com, jako serwera VPS do wielu zastosowań. Szukając platformy dla siebie wybrałem yourwebhoster.eu - prawdopodobnie jest to reseller, niemniej spełnia kryteria które postawiłem, więc właśnie na tej ofercie poprzestałem.

Tak samo jak poprzedni artykuł, również obecny nie jest w żaden sposób sponosorowany - wybrałem dostawcę który w 100% spełniał moje oczekiwania i opisałem swoje wrażenie z dotychczasowego użytkowania.

1. Przeznaczenie

Własne repozytorium kodu i przestrzeń na backupy. Tylko tyle i aż tyle. Chodziło o skonfigurowany po swojemu dedykowany system dla kilku użytkowników, tylko do szybkiego synchronizowania kodu. Więc wybór padł na przeznaczonego wyłącznie pod svn małego VPSa.

2. Co zadecydowało o wyborze?

Przede wszystkim cena i lokalizacja, kosztem innych parametrów. Zależało mi na stosunkowo niskich opóźnieniach (poniżej 50ms jest akceptowalne) i przyzwoitej pojemności dysku, co w tym przypadku jest spełnione. Żenująco niska ilość pamięci jest wystarczająca dla mojego zastosowania. Nie bez znaczenia był też wybór systemu -  chciałem Gentoo, a ta dystrybucja nie wszędzie jest oferowana (często dostępne są tylko binarne). Ponieważ do technologii OpenVZ mam mieszane podejście (ale to zupełnie osobny temat), pozostawał raczej tylko XEN.
Podsumowując: tanie Gentoo na XENie w Europie :)

3. Parametry serwera

•    Pamięć RAM – 128MB
•    Pamięć SWAP – 256MB
•    Dysk twardy – 25GB
•    Miesięczny limit transferu – 100GB
•    Procesor – 1x Intel® Xeon(R) CPU X3440  @ 2.53GHz
•    Ilość IP – 1x (Holandia)
•    Wybór dystrybucji: Centos, Debian, Fedora, Gentoo, Slackware, Ubuntu

4. Problemy

Napotkane problemy nie dotyczyły samej usługi, a raczej działania systemu przy tak ograniczonych zasobach.
Ze względu na minimalną ilość RAMu kompilacja kilku niezbędnych do pracy pakietów skończyła się interwencją OOM killera. Pomogło poszerzenie swapa na czas przygotowywania środowiska pracy.
Natknąłem się też na buga w ebuildzie xz-utils, aczkolwiek ustawienie XZ_OPT="--memory=128M" rozwiązało problem z kompilacją jednej z paczek.

5. Zarządzanie

Zarządzanie maszyną wirtualną odbywa się poprzez SolusVM, standardowo dostępny w pakiecie. W panelu nie ma żadnych nietypowych czy niespotykanych u konkurencji funkcji - przeinstalowanie systemu, stopowanie maszyny, statystyki, konsola (zweryfikowane - działa bezproblemowo), wszystkie udostępnione funkcje działają ok. W planie którego używam nie ma możliwości robienia backupów.
Jedyną rzeczą niedostępną z poziomu panelu jest ustawienie revdnsa.

6. Podsumowanie

W czasie normalnego korzystania system nie swapuje i 128MB w zupełności wystarcza - o to właśnie chodziło. Nie natknąłem się na żadne probelmy z działaniem samej usługi. Jako serwer kont shellowych i repozytorium svn dla kilkuosobowego, niezbyt dynamicznego projektu taki VPS sprawdza się zadowalająco, zważywszy że jego miesięczy koszt to niecałe 24pln.

Majowe spotkanie OWASP [live streaming]

Patryk Kuźmicz 2 komentarze

Mieliśmy przyjemność być na krakowskim spotkaniu OWASP Poland i dodatkowo mieliśmy możliwość przekazania Wam relacji na żywo. Jeśli nie mogliście nas oglądać, to nic straconego ;-) wkrótce pojawią się zmontowane filmy zawierające dwie prezentacje:

“Drive-by download attacks” – Filip Palian
“Detection and analysis of malicious web sites” – Łukasz Juszczyk

Więcej informacji już wkrótce... ;-)

Majowe spotkanie OWASP

Patryk Kuźmicz Leave a Comment

Już w najbliższy czwartek 13 maja, o godzinie 18:oo w Wydziale Fizyki i Informatyki Stosowanej AGH odbędzie się spotkanie OWASP. Tak jak poprzednio, spotkanie jest zorganizowane wspólnie z ISSA Polska. Oprócz ciekawych prelekcji będzie kilka niespodzianek.

agenda spotkania:
18:00 - 18:05 - "OWASP News" - Przemysław Skowron
18:05 - 18:00 - "Drive-by download attacks" - Filip Palian
19:05 - 19:50 - "Detection and analysis of malicious web sites" - Łukasz Juszczyk

Ataki drive-by download - Filip Palian

o prelegencie: Obecnie ekspert ds. monitorowania bezpieczeństwa IT w instytucji finansowej.

abstrakt
Pragnę zaprosić Państwa na prelekcję podczas której przedstawię problem szkodliwego oprogramowania w kontekście ataków drive-by download. Przede wszystkim będą Państwo mieli okazję dowiedzieć się kogo dotyczy problem, jaka jest jego skala, zobaczyć jak przebiega tego typu atak oraz jak możliwie skutecznie przeciwdziałać tego typu zagrożeniom. Zapraszam raz jeszcze i do zobaczenia! ;-)

Wykrywanie i analiza złośliwych stron internetowych - Łukasz Juszczyk

o prelegencie: zajmuje się bezpieczeństwem IT w CERT Polska/NASK, gdzie w ramach projektu HoneySpider Network pracuje nad wykrywaniem złośliwych stron WWW oraz atakami na aplikacje klienckie.

abstrakt
Prezentacja będzie traktować o sposobach wykrywania i analizy złośliwych stron WWW. Podczas prezentacji zostaną omówione techniki ataków oraz narzędzia służące do ich wykrywania, takie jak klienckie honeypoty. Nacisk będzie położony na mechanizmy działania złośliwego oprogramowania oraz na główne problemy towarzyszące ich wykrywaniu. Zostanie także zaprezentowana analiza najpopularniejszych wektorów ataku na aplikacje kliencki.

Miejsce spotkania

Wydział Fizyki i Informatyki Stosowanej AGH
Kraków, ul. Reymonta 19, budynek D-10
Sala: A (aula)

Zapraszamy serdecznie wszystkich zainteresowanych.

Moje spostrzeżenia z zabawy VPS'em

Patryk Kuźmicz 4 komentarze

Na rynku istnieje bardzo dużo firm hostingowych świadczących szeroki wachlarz usług. Zarówno jeśli chodzi o hosting stron WWW po serwery wirtualne czy dedykowane. Wybór platformy czasami nie jest takim prostym zadaniem na jakie wygląda, a znalezienie dobrego, taniego i stabilnego hostingu nie jest sprawą łatwą... Od czego powinniśmy zacząć? Na co powinniśmy zwrócić uwagę? Kwestia hostingu lub VPS'a jest decyzją indywidualną a wybór powinien być podyktowany naszymi wymaganiami i oczekiwaniami wobec usługodawcy.

Nie wiem jak często uda mi się kupić VPS'a do testów, aby podzielić się z Wami spostrzeżeniami, ale mam obecnie okazję przenosić kilka usług na serwer wirtualny znajdujący się w 2host.com i między innymi przy tej okazji powstaje ten wpis.

Zaznaczam, że nie jest to, żaden artykuł sponsorowany, a żadne informacje/dane nie są naciągane ;-) wszystko poniżej jest rzeczywistą próbą pokazania z czym mamy do czynienia.

1. Szukam VPS'a

Dlaczego VPS? Ponieważ taka forma jest w zupełności mi wystarczająca. VPS będzie służył jako serwer WWW, serwer SOCKS, czasami chciałbym udostępnić znajomym jakieś pliki... Czyli klasyczny serwerek do zabawy. Dlaczego nie dedykowany? Serwisy generują mały ruch, a ja nie potrzebuję pełnych zasobów serwera tylko dla siebie, nie zależy mi na tym czy strona załaduje się w 2 sekundy czy 1 sekundę, jestem w stanie z tym się pogodzić. Usługi dedykowane są znacznie droższe, a tak jak wspominałem jest to serwer do zabawy. Dlaczego nie hosting? ponieważ lubię wiedzieć co się dzieje aktualnie na serwerze, czasami chcę uruchomić jakiś skrypt, przetestować aplikację, a nie chcę być ograniczany przez usługodawcę. W moim przypadku VPS w pełni spełnia moje oczekiwania. Gdzie szukam? Szukam w miarę małej maszynki, nic wielkiego, tak więc w pierwszej kolejności www.lowendbox.com a następnie www.webhostingtalk.com. Te dwie strony to setki ofert, porównań, komentarzy użytkowników... udostępniają nieograniczoną liczbę informacji do przeanalizowania. ;-)

2. Co zadecydowało o wyborze?

W moim przypadku, była to duża ilość pamięci RAM oraz wysoki limit transferu w stosunku do ceny, kosztem lokalizacji (USA), co wiąże się z lagami rzędu ~140ms, ale tak jak pisałem, nie zależy mi na bardzo szybkim dostępie do usług, po prostu chce by strony działały, nie muszą się błyskawicznie ładować. Z drugiej strony lokalizacja USA pozwala mi na użycie tego serwera do oglądania filmów na platformie VOD Hulu ;-) Hulu sprawdza do jakiego kraju należy adres IP i na tej podstawie albo blokuje dostęp, albo wpuszcza.

3. Parametry serwera

  • Pamięć RAM - 512MB
  • Pamięć SWAP - 1024MB
  • Dysk twardy - 14GB
  • Miesięczny limit transferu - 10TB
  • Procesor - 4x Intel Xeon E5520 @ 2.27GHz
  • Ilość IP - 1x (USA)
  • Szeroki wybór systemów operacyjnych: (Fedora, Centos, Gentoo, Slackware, Debian, Ubuntu)

Jeśli chodzi o pamięć RAM, to w zupełności mi wystarcza, po uruchomieniu usług (Apache2 + MySQL), gidentd, sesja screen, cron, postfix serwer wykorzystuje około ~250MB. Zajętość dysku 1.7GB wraz z kontentem stron, sam system operacyjny zajmuje < 1GB na dysku. Procesory nudzą się vmstat pokazuje idle na poziomie 100%... Podczas ściągania plików udało mi się uzyskać transfer ~5MB/s. Transfer 10TB miesięcznie to bardzo dużo, zaokrąglając daje nam to mniej więcej 2200 pobrań filmu na płycie DVD.

4. Problemy

Instalacja Apache i PHP przebiegła bez większych problemów, szybko i sprawnie, całość z paczek. Z MySQL'em pojawił się drobny problem... nie mogłem poprawnie ustawić hasła, co się okazało, nie instalował się całkowicie poprawnie, dokładnie proces postinstalacji nie odbywał się tak jak należy...

100427 13:34:45 [Warning] The syntax '--log' is deprecated and will be removed in MySQL 7.0. Please use '--general_log'/'--general_log_file' instead.
/usr/sbin/mysqld: Can't create/write to file '/tmp/ibB6hkkO' (Errcode: 13)
100427 13:34:45  InnoDB: Error: unable to create temporary file; errno: 13
100427 13:34:45 [ERROR] Plugin 'InnoDB' init function returned error.
100427 13:34:45 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
100427 13:34:45 [Warning] Forcing shutdown of 1 plugins
* Starting MySQL database server mysqld                                                                                                             [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
root@yoursite:~# ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)

przyczyną był katalog /tmp

drwxr-xr-x  4 root root  4096 2010-04-27 13:37 tmp

Brakowało uprawnień do katalogu oraz sticky bit'a (+t), który pozwala wszystkim tworzyć pliki, natomiast usuwać je może jedynie właściciel. Ale chmod +t /tmp/ rozwiązał problem. Prawdopodobnie w template maszyny wirtualnej jest błąd ;-)

Kolejna rzecz z jaką się zmierzymy to strefa czasowa ;-) jest to serwer wirtualny, tak więc zegar działa w dom0, czyli maszynie głównej. Jeśli chcemy samodzielnie konfigurować swój czas musimy ustawić parametr w systctl'u:

echo "xen.independent_wallclock = 1" >> /etc/sysctl.conf

i po tym możemy już wykonać sysctl -p /etc/sysctl.conf. Od tej pory, mamy własny zegar ;-)

Nie udało mi się również zainstalować nowszego Ubuntu niż 9.04, podczas startu maszyna zgłaszała problemy z zamontowaniem partycji.

5. Support

Z supportem miałem do czynienia, gdy chciałem skonfigurować revDNS'a, pomimo takiej opcji w menu, okazuje się, że niezbędne jest ręczne wysłanie ticketa, tak więc napisałem krótkiego maila, podałem IP oraz domenę i zaznaczyłem stopień problemu jako niski. Po 4-ech godzinach otrzymałem informację, że ticket został zrealizowany i wpis powinien działać - działał.

6. Zarządzanie

Zarządzanie maszyną wirtualną odbywa się poprzez WWW (SolusVM), który jest dostępny bez dodatkowych opłat. Z panelu możemy m.in.:

  • przeinstalować system,
  • dostać się do konsoli lokalnie,
  • sprawdzić zużycie transferu, pamięci, zajętość dysku
  • zmienić hasło na usera root
  • wykonać backup (opcja dodatkowa)

Wszystko odbywa się sprawnie i w łatwy intuicyjny sposób.

7. Podsumowanie

Przez tydzień używania serwera, nie spotkałem się z innymi problemami o których chciałbym napisać, serwer działa stabilnie, strony ładują się w sensownym czasie, nie zauważyłem też by maszyna czekała na zasoby. Tak więc do zastosowań "domowych", czy małego hostingu nadaje się świetnie. Jakość usługi w stosunku do ceny ~20PLN jest całkowicie zadowalająca, gdyby jeszcze tylko znajdował się w Europie... ;-)

A Wy gdzie preferujecie hosting? serwery VPS/dedykowane?

Q&A – jak wypakować katalog/plik z dużego archiwum?

Tomasz Ligocki Leave a Comment

Przypadkowe skasowanie pliku, to częste zgłoszenie, z jakim spotyka się administrator. Na ogół oczywiście nie jest to skasowanie pliku przez niego samego, a przez któregoś użytkownika. A im więcej użytkowników administrator ma na serwerach, tym prawdopodobieństwo takiego zdarzenia jest większe.

Każdy wie, jak wypakować  katalog/plik z archiwum - jeden szybko użyje do tego celu np. Midnight Commandera, znajdzie i wypakuje, co trzeba, inny ręcznie rozpakuje całe archiwum, przywróci co trzeba i usunie zbędne już dane, ale optymalnym rozwiązaniem rozwiązaniem w przypadku bardzo dużego archiwum jest wypakowanie tylko interesujących nas danych - nie tylko ze względu na czas odzyskiwania, ale również z powodu np. ograniczenia wolnego miejsca na dyskach, szybkości dysków, czy obciążenia pracującego systemu.

Narzędzie tar posiada oczywiście taką funkcjonalność, więc pokażę na krótkim przykładzie, jak:

1. Podglądamy archiwum:

$ tar tf archiwum.tar
archiwum/
archiwum/katalog2/
archiwum/katalog2/plik2.png
archiwum/katalog2/plik1.png
archiwum/katalog2/plik3.png
archiwum/katalog1/
archiwum/katalog1/plik2.png
archiwum/katalog1/plik1.png
archiwum/katalog1/plik3.png
archiwum/katalog3/
archiwum/katalog3/plik2.png
archiwum/katalog3/plik1.png
archiwum/katalog3/plik3.png

2. Rozpakowujemy wybrany katalog:

$ tar xvf archiwum.tar archiwum/katalog2/
archiwum/katalog2/
archiwum/katalog2/plik2.png
archiwum/katalog2/plik1.png
archiwum/katalog2/plik3.png

3. Rozpakowujemy wybrany plik:

$ tar xvf archiwum.tar archiwum/katalog3/plik1.png
archiwum/katalog3/plik1.png

4. Upewniamy się, że odzyskaliśmy to, co chcieliśmy:

$ ls -R archiwum/
archiwum/:
katalog2 katalog3

archiwum/katalog2:
plik1.png plik2.png plik3.png

archiwum/katalog3:
plik1.png

Powyższa logika działa również dla archiwów gzip (przełącznik 'z'), bzip2 (przełącznik 'j') itd.

Na koniec drobna uwaga (zdarzyło mi się odruchowo kilka razy popełnić ten drobny błąd) - przy rozpakowaniu należy użyć ścieżki względnej, a nie bezwzględnej, czyli bazując na przykładzie - należy użyć:

$ tar xvf archiwum.tar archiwum/katalog2/

zamiast:

$ tar xvf archiwum.tar /archiwum/katalog2/

Ale oczywiście w przypadku jego popełnienia narzędzie tar nas poinformuje o naszej niefrasobliwości. :)