Kolejny raz przyszło mi mieć przeboje z "najlepszym polskim usługodawcą" jakim kreuje się Home.pl
Tym razem klient próbował zmienić hosting z Nazwa.pl, gdzie wiele serwisów na jednej maszynie niestety skutecznie ją zabijało co objawiało się błędami 500 jednym za drugim. O ile z przegraniem plików nie było problemu, o tyle z plikiem .SQL o wielkości +/- 50MB udostępniany przez Home.pl phpMyAdmin sobie nie poradził.
Jako iż klient przerzucał serwis we własnym zakresie, skontaktował się z Home i otrzymał propozycję podesłania pliku do ich administratorów, którzy to wgrają plik do bazy lokalnie unikając timeoutu PHP. Jak poradzili tak zrobił. Czas reakcji administracji nie jest tematem przewodnim, ale i tak pozostawia wiele do życzenia. Niestety - baza używała kodowania w latin2, wygenerowany dump SQL był w UTF-8 i baza po stronie Home również takie miała kodowanie. Po prostym imporcie zamiast polskich znaków diakrytycznych pojawiły się znaki zapytania i inny dziwolągi.
Krótka walka z SET NAMES UTF8; czy też latin2 nic nie dała - kodowanie trzeba było ustawić przed importem. Prośba o zmianę kodowania do Home.pl przyniosła prośbę, o podesłanie pliku z już poprawnym kodowaniem. Po co ja się pytam? Przecież wystarczyło otworzyć plik, który już mają i dopisać SET NAMES UTF8; na samym początku dumpu? Niestety - nie budzit.
Klient pisze do nas o pomoc, handlowiec przekazuje mi - nie chcę mi się jeszcze raz robić dumpu 50MB bazy, przekodowywać i na nowo pchać plik w drugą stronę "łańcucha dowodzenia". Rozwiązanie, na przyszłość:
# mysql -h nazwa.serwera.sql -u uzytkownik -p
Enter password: #wpisujemy hasło
mysql> use nasza_baza_danych;
mysql> set names utf8;
mysql> source nasz_dump_sql.sql
Teraz zostaje już tylko poczekać, sprawdzić czy wszystko ok i zafakturować klienta. Hm ... to może jednak dobrze, że admini w Home są leniwi?
URL Trackback
Akurat tak się złożyło, że musiałem dzisiaj zalogować się na konto u jednego z większych hostingodawców, na które ostatni raz logowałem się jakieś 5-6 miesięcy temu. Logowanie jak logowanie - wpisuję login, wpisuję hasło ... nie działa?
Szybko w pamięci przeleciałem standardową listę nastu haseł, których używam. Skrzyżowałem je z różnymi wariacjami na temat loginu, połączyłem kilka haseł by wytworzyć prawdopodobnie to, które użyłem - nic. Następny przystanek, poczta!
Szybko udało mi się wyszukać mail z danymi technicznymi do konta - ftp, login, hasło ... "takie jak podane w momencie rejestracji". No nic - wracamy na stronę i wypełniamy formularz przypomnienia hasła. Klik klik, link w mailu, klikamy, ustawiamy nowe hasło, klik ... "hasło musi składać się z przynajmniej 8 znaków, dwóch dużych liter, jednej małej i jednego znaku specjalnego". Ok ... tego się nie spodziewałem.
Niby jest to dobra praktyka - zwiększa bezpieczeństwo danych etc. Do co ważniejszych informacji sam używam hasła z prawie 20 znaków (bruteforce może trochę potrwać), nie słownikowego (random) bez żadnych "ciągłości", z cyferkami etc. Niestety, bez dużych liter. W takim wypadku mam dwa wyjścia. Albo sobie hasło zapiszę gdzieś, żeby za pół roku nie kombinować, albo zmienię co trzeba i znowu je zapomnę. Ja mogę zapomnieć - Kowalski pewnie zapisze.
Zapisze na kartce, zapisze na poczcie, zapisze w notatniku on-line. Tym samym Kowalski, który używa na co dzień silnego hasła musi sobie nowe "silne" hasło gdzieś zapisać zmniejszając jego bezpieczeństwo. Ja rozumiem, że oni robią to w trosce o mnie - ale czy nie wystarczy, jeżeli pojawi się stosowny komunikat, że "hasło jest zbyt słabe by je zastosować". Szczególnie takie rozwiązanie śmieszy mnie w połączeniu ze wskaźnikiem trudności hasła poniżej, który pokazuje mi "trudne 4/5".
Pozostaje mi mieć nadzieję, że będę pamiętał o tych paru dodatkowych literkach dodanych do hasła. A jak nie, to za 5-6 miesięcy znowu przyjdzie mi wypełnić formularz przypomnienia.
URL Trackback
Home.pl jest jednym z nielicznych, popularnych, usługodawców, którzy udostępniają usługę CRON. No, prawie - jest to ich implementacja, która polega na okresowym wywoływaniu plików PHP, Perla, Pythona lub CGI - dzięki temu możemy zaimplementować np. automatycznie rozsyłający się newsletter etc.
W swojej dokumentacji Home.pl stwierdza:
Środowisko uruchomieniowe skryptów jest identyczne ze środowiskiem, w jakim uruchamiane są skrypty na serwerach wirtualnych. W praktyce wywołanie takie niewiele różni się od zwykłego wywołania GET po protokole HTTP.
Dla mojej małej główki równa się to z czymś takim:
telnet mojadomena.pl 80
GET /cron-hourly.php HTTP/1.1
Host: mojadomena.pl
Connection: Close
Co się jednak okazuje? Panowie z Home poszli na łatwiznę i nawet o tym nie wspomnieli - otóż CRON po prostu skanuje FTP w poszukiwaniu odpowiednich plików i wywołuje je przez interpreter CLI.
Efekt? Zmienna $_SERVER['HTTP_HOST'] ma złą wartość - zamiast mojadomena.pl znajdziemy tam home.pl - i tak, dowiedziałem się o tym "the hard way" kiedy nagle dostałem maila, który zamiast z adresu info@mojadomena.pl przyszedł z info@home.pl
Update - okazuje się, że problemem nie jest zła informacja w HTTP_HOST, ale jej .. brak. A w tym wypadku Home sam dodaje swoją domenę do adresu. Poniżej przykład wysyłanych informacji (wysłane print_r($_SERVER) na mój adres (zamieniłem login serwera na "LOGIN" w celu ochrony prywatności):
To: btm@anfo.pl
Subject: Cron na home
From: info@home.pl
Array
(
[QUERY_STRING] =>
[REQUEST_METHOD] => GET
[REMOTE_HOST] => localhost
[REMOTE_ADDR] => 127.0.0.1
[DOCUMENT_ROOT] => /
[SERVER_SOFTWARE] => IdeaCron
[SERVER_PROTOCOL] => HTTP/1.0
[GATEWAY_INTERFACE] => CGI/1.1
[PATH] => /bin
[TMP] => /tmp
[TMPDIR] => /tmp
[SERVER_ID] => LOGIN@home
[SERVER_NAME] => LOGIN.home.pl
[SERVER_ADMIN] => LOGIN@home.pl
[SCRIPT_NAME] => /cron-5min.php
[SCRIPT_FILENAME] => /cron-5min.php
[REQUEST_URI] => /cron-5min.php
[PATH_INFO] => /cron-5min.php
[PATH_TRANSLATED] => /cron-5min.php
[PHP_SELF] => /cron-5min.php
[REQUEST_TIME] => 1253531102
[argv] => Array
(
)
[argc] => 0
)
URL Trackback
Na wypadek gdyby ktoś miał konto na www.hosteurope.de lub u ich resellerów (np. hosting w eHost.pl.
Traf chciał, że przypadkiem skasowałem, zamiast przesunąć ważny folder - mały, bo mały, 300mb z 15gb serwera. Po pierwszych sekundach paniki przyszło opamiętanie - mam backup! Backup z przed 10 dni, akurat nic nie było zmieniane!
Niestety, backup zrobiłem z poziomu Virtuozzo i jak się okazuje, jest to obraz dysku. Po konsultacji z eHost, dowiedziałem się, że uprzejmi panowie z Niemiec jasne, że są w stanie odzyskać ten jeden folder za mnie. Za jedyne 25EUR za każde rozpoczęte 15 min pracy.
Zostaje jeszcze druga opcja - backup z teraz, restore starej kopii, zgranie plików, restore nowej kopii. Zgadnijcie, którą opcję wybrałem. Podpowiedzią może być godzina dodania notki ;-)
Małe podsumowanie:
- zrobienie backupu 15gb - 1:20h
- restore starego backupu - 1:13h
- zgranie plików - 0:15h
- restore nowego backupu - 1:13h
Czyli jestem jakieś4 godziny w plecy, ale jeżeli panowie w Niemczech mieli by to robić, to zakładam, że zajęło by to im z 2 godziny, czyli 200EUR. Odeśpię kiedy indziej ;-)
Notka nie ku przestrodze (F6! F6! To zawsze jest F6 w mc, nie F8!) i dla potomnych, bo niestety Virtuozzo nie ma informacji ile jeszcze zajmie operacja, a Google nie pomogło. Uwaga - podczas restore w panelu będzie pokazana zajętość dysku - skacze od 0% do 10% (1% co ~10 minut) a potem już skacze na tyle, ile de-facto zajmuje i trzeba ponownie uruchomić VPS!
URL Trackback
