Osobom, które nie znają Plesk już tłumacze. Plesk to panel administratora serwera napisany w PHP sprzedawany często wraz z serwerami dedykowanymi czy wirtualnym pozwalający na zarządzanie całym hostingiem lub tylko konkretnymi z odsprzedawanych kont. Panelu głównie używa się do tworzenia nowych domen, skrzynek pocztowych etc. I tu pojawił mi się problem.

Jako iż jeden z moich klientów intensywnie używa poczty postanowiłem zmienić mu domyślny limit z 100mb na Unlimited. Prosta zmiana w panelu, tyle tylko, że pojawia się komunikat:

The size of this mailbox must not exceed the limit on amount of disk space allocated for mailboxes in this domain.

Ok, skrzynka jest większa niż maksymalny rozmiar dla domeny. Tyle że ... limit dla domeny ustawiony jest na Unlimited. Okazuje się, że najprawdopodobniej jest to jakiś błąd albo tłumacza albo programisty, bo limit dotyczy konfiguracji KLIENTA, a nie domeny.

Edycja danych klienta, w których to ustawiamy w/w limity nie odbywa się bynajmniej z poziomu kartoteki danego klienta, ale z Clients, gdzie zaznaczamy checkbox obok wybranego klienta i klikamy "Modify".

Ku potomnym, bo mi zajęło dwa dni ;-)

Jeżeli komuś nagle wyskoczy komunikat jak w tytule, informujący, że SquirrelMail nie może zapisać / odczytać pliku preferencji (defaul_pref lub też preferencje konkretnego konta) i jednocześnie mamy pewność, że folder istnieje, użytkownik serwera WWW ma prawa odczytu / zapisu i ogólnie wszystko wygląda ok to niech ... sprawdzi, czy przypadkiem na serwerze *nagle* nie włączono / zmienione open_basedir w konfiguracji PHP na takie, które uniemożliwia dostęp do tego katalogu...

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?

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.