ImageMagick vs WAMP vs LAMP vs me

Wczoraj i dziś miałem tę wątpliwą przyjemność walczyć z integracją PHP oraz ImageMagick zarówno na Linuksie jak i pod Windows. O ile pingwin nie stwarza większych problemów, o tyle na okienkach już tak łatwo nie jest. Wszystkiemu winne wydają się być kompilatory użyte do przygotowania binarek poszczególnych elementów całej tej układanki.

Jak wspomniałem, najprościej jest pod Linuksem, więc od niego zacznę. W moim przypadku pomogła sekwencja poleceń znaleziona na tym blogu.

$ yum install ImageMagick ImageMagick-devel
$ pecl install imagick
$ echo "extension=imagick.so" > /etc/php.d/imagick.ini
$ service httpd restart

Kolejno instalujemy ImageMagick z dodatkowymi narzędziami, następnie rozszerzenie z repozytorium PECL i włączamy je w pliku konfiguracyjnym PHP. Ostatnia komenda restartuje oczywiście Apache'a. Potem zostaje już tylko sprawdzić np. w phpinfo(); czy Imagick faktycznie działa. To tyle.

Jeśli chodzi o Windowsa to naszukałem się trochę więcej. A nawet jak już coś się znajdzie to szanse, że i u nas zadziała wynoszą 50%. Loteria. Dlatego też podaję od razu komplet linków do elementów układanki, które ze sobą współgrają:

• ImageMagick-6.5.9-0-Q16-windows-dll.exe
• php_imagick_ts.dll
• WampServer2.2a-x32.exe

ImageMagick instalujemy najlepiej do C:\ImageMagick. Podczas instalacji trzeba się upewnić, że zaznaczona jest opcja "Add to system path" - bez tego nie da rady. Oczywiście do ścieżki systemowej można IM dodać również po instalacji, ale to wykracza już poza temat posta.

WampServer instaluje się bez jakiejś specjalnej filozofii. Kiedy instalator zakończy pracę, kopiujemy bibliotekę php_imagick_ts.dll do folderu C:\wamp\bin\php\php5.3.8\ext i zmieniamy jej nazwę na php_imagick.dll. Teraz trzeba dopisać jeszcze rozszerzenie do php.ini. WampServer ma dwa pliki konfiguracyjne dla PHP (nie wiem który ważniejszy, więc dopisałem do obu).

• C:\wamp\bin\php\php5.3.8\php.ini
• C:\wamp\bin\apache\Apache2.2.21\bin\php.ini

W obu odszukujemy dość długą listę rozszerzeń kończącą się mniej więcej tak:

;extension=php_xmlrpc.dll
;extension=php_xsl.dll
;extension=php_zip.dll

i dopisujemy do niej extension=php_imagick.dll (bez średnika na początku linii). Zapisujemy pliki.

Na koniec pozostaje uruchomić ponownie system. Tak, system. Nie tylko serwer :)

Wszystko to instalowałem pod Windows XP.

Wprowadzony kod nie został zweryfikowany - problemy z weryfikacją dwuetapową Google

Czas na kolejnego posta wyjaśniającego zawiłości technologii, która zaskakuje nas każdego dnia prostymi rzeczami. Od jakiegoś czasu korzystam z weryfikacji dwuetapowej dla swojego konta Google. Prosta rzecz, a daje pewność, że nawet jeśli ktoś pozna moje hasło to i tak nie będzie mógł się zalogować. Fajnie? Fajnie było, ale tylko do czasu.

Cała patent opiera się na tym, że podczas logowania do swojego konta z nowej maszyny lub przeglądarki jesteśmy proszeni już nie tylko o swoje standardowe hasło, ale również o dodatkowy 6-cyfrowy kod. Kod ten może być generowany np. przez specjalną aplikację zainstalowaną w telefonie. Wpisujemy więc szybko kod, który ważny jest tylko jakieś 30 sekund i po pomyślnej weryfikacji wreszcie otrzymujemy dostęp do konta. Super. Tylko co, gdy kod wygenerowany przez aplikację nagle okazuje się nieprawidłowy?

No dobra, zdarza się. Próbujemy jeszcze raz. Hmm, znowu? To już chyba coś nie tak. I jeszcze ten komunikat:

Wprowadzony kod nie został zweryfikowany
(The code you entered didn't verify)

To jak? Nie mogli go zweryfikować (np. awaria systemu), czy po prostu jest nieprawidłowy?! Mniejsza z tym. Oczywiście chodzi o to, że kod jest nieprawidłowy. Ale dlaczego? Przecież taki mi się wyświetla. Postanowiłem skorzystać z kodów zapasowych trzymanych w bezpiecznym miejscu. Zalogowałem się, wyłączyłem kłopotliwy mechanizm i postanowiłem skonfigurować od nowa aplikację na telefonie. A nuż pomoże. Czytam znowu te wszystkie informacje o tym jak działa weryfikacja dwuetapowa, czytam sobie i... nagle mnie oświeca.

Kody generowane przez aplikację są zależne od czasu. Są więc generowane w jakiś sposób na podstawie zegara, bieżącej godziny. Rzut okiem na czas systemowy - 21:03, rzut okiem na czas w telefonie - 21:08. WTF? Albo coś się zrąbało w komputerze albo w telefonie. Aaaa... przecież już nie raz łapałem się na tym, że zegar mi na Androidzie śpieszy. Nie pomagała synchronizacja z operatorem, nie pomagały ręczne poprawki. I tak po jakimś czasie znowu szedł te kilka minut do przodu.

Ok. W takim razie kończę ponowną konfigurację mechanizmu weryfikacji na swoim koncie, cofam zegar w telefonie, odpalam aplikację, wpisuję kod na stronie... Voila! Jestem.

PS. Ostatecznie nie wiem z jakim zegarem powinienem mieć zsynchronizowany czas w telefonie żeby kody były generowane poprawnie, ale przypuszczam, że można się sugerować godziną podawaną przez serwery typu time.nist.gov, time.windows.com, etc. Póki co tak jest dobrze.

Unable to monitor filesystem - kłopot Dropboksa

Dalszy ciąg wyłączania denerwujących komunikatów w Gnome. No, może teraz jednak chodzi nie tyle o komunikat co o rzeczywisty problem z Dropboksem pojawiający się na mojej Fedorze (i z tego co widzę nie tylko na mojej i nie tylko na Fedorze).


Chodzi o powyższy "dymek", który informuje o niemożności śledzenia przez Dropboksa zmian we wszystkich plikach, które synchronizujemy. Wynika to z ograniczenia nałożonego przez samego Linuksa. Za liczbę plików, które można śledzić odpowiada ustawienie max_user_watches, którego wartość zapisywana jest w /proc/sys/fs/inotify/max_user_watches. Domyślna wartość wynosi 8192, co jest zbyt małą liczbą dla Dropboksa. Wydawać by się mogło, że wydanie zalecanego przez powyższy komunikat polecenia powinno załatwić sprawę. Kiedyś tak - teraz już niestety nie bardzo.

Po niedawnej reinstalacji Fedory okazało się, że domyślna wartość ustawienia przywracana jest przy każdym uruchomieniu systemu. Trzeba więc za każdym razem na nowo wydawać polecenie z konsoli i restartować Dropboksa albo... dodać to polecenie do listy poleceń wykonywanych przy każdym uruchomieniu systemu. W tym celu najlepiej zmodyfikować plik /etc/rc.local i na jego końcu dopisać:

echo 100000 | tee /proc/sys/fs/inotify/max_user_watches

Po kolejnym reboocie systemu Dropbox powinien być już zadowolony z nowych ustawień.