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ń.

Fedora 17

W Fedorze 17 nie znajdziemy już pliku /etc/rc.local, ale ustawienie max_user_watches możemy skonfigurować w inny sposób. Edytujemy plik /etc/sysctl.conf i na jego końcu dopisujemy:

fs.inotify.max_user_watches = 100000

Zapisujemy i... tyle.

No more DVDs - instalacja Fedory z dysku twardego

Kilka dni temu znowu walczyłem z instalacją Fedory. Napędy DVD w laptopach bywają różne. Mój bez dwóch zdań kwalifikuje się do tej grupy, z której nikt napędu dostać by nie chciał. Problemy z zapisem, problemy z odczytem, masa problemów ogółem. Kiedy instalacja nie powiodła się "enty" raz zacząłem myśleć o innych metodach. Jedną z opcji była instalacja z dysku komputera i o tym dzisiaj napiszę. Opis dotyczy instalacji Fedory 14.

Zanim zabierzemy się za instalację potrzebne nam będzie kilka rzeczy:

• obraz instalacyjnego DVD Fedory (tak, plik .iso),
• folder images wydobyty z powyższego obrazu,
• partycja na dysku, której nie będziemy formatować w czasie instalacji,
• istniejąca instalacja Fedory z działającym Grubem.

Wspomniana partycja nie musi być pusta. Może to być np. partycja /home, której zazwyczaj się nie formatuje. Potrzebna jest działająca instalacja Fedory, aby dobrać się do Gruba i dodać pewne niezbędne wpisy. Może to być oczywiście dowolna instalacja, najpewniej poprzednia poprzednia wersja systemu - dlatego warto zabrać się za przygotowania do instalacji z dysku zanim jeszcze zaoramy (czyt. przeformatujemy) partycję systemową.

Najpierw należy skopiować obraz instalacyjnego DVD na partycję, której nie będziemy ruszać w czasie instalacji. Jak wspomniałem może to być /home. Ja obraz umieściłem w swoim katalogu domowym /home/sdr.

W tym samym folderze, w którym umieścimy ISO Fedory wklejamy katalog images (cały katalog wraz z zawartością - nie tylko samą zawartość).

Teraz uruchamiamy konsolę i logujemy się na konto roota. Montujemy ściągnięty plik .iso i kopiujemy z niego dwa niezbędne do rozruchu pliki:

$ su --
$ mount /home/sdr/Fedora-14-i386-DVD.iso /mnt/ -ro loop
$ cd /mnt/isolinux/
$ cp initrd.img vmlinuz /boot/

Pliki kopiujemy do /boot. Następnie edytujemy plik konfiguracyjny Gruba

$ vim /boot/grub/grub.conf

i dodajemy na samym końcu następujące linie (patrz też: aktualizacja na końcu tego posta):

title Fedora ISO
kernel /boot/vmlinuz
initrd /boot/initrd.img

Zapisujemy plik i wychodzimy z edytora. Teraz pozostaje tylko sprawdzić nazwę partycji, na której trzymamy obraz instalacji (w moim przypadku /home). Pomoże w tym polecenie

$ df -h
System plików rozm. użyte dost. %uż. zamont. na
/dev/sda6 9,9G 4,4G 5,0G 47% /
/dev/sda8 62G 24G 35G 42% /home

W ostatniej kolumnie (zamont. na) szukamy punktu montowania naszej partycji i odczytujemy nazwę w systemie plików (pierwsza kolumna). U mnie to /dev/sda8. Trzeba zapamiętać tę nazwę oraz nazwę folderu, w którym leży obraz jeśli nie umieściliśmy go bezpośrednio pod /home. W moim przypadku nazwa katalogu to sdr.

Wszystko już gotowe do instalacji. Teraz można zrestartować system i po ponownym uruchomieniu w Grubie wybrać pozycję "Fedora ISO". Uruchomi się instalator. Gdy zostaniemy zapytani o wybór źródła instalacji należy wybrać instalację z dysku twardego. Instalator poprosi o wybór partycji, na której zapisaliśmy obraz instalacji. Wybieramy nazwę odczytaną wcześniej z konsoli (dla mnie to /dev/sda8). Jeśli obraz umieszczony jest w dodatkowym katalogu to w polu pod listą partycji należy wpisać nazwę tego katalogu. U mnie obraz leżał w /home/sdr, więc wpisałem sdr. Wystarczy sama nazwa katalogu. Po zatwierdzeniu wyboru instalacja dalej przebiega w typowy sposób.

Polecam tę metodę, można oszczędzić sobie sporo nerwów z napędem i kasy na zakup płytek, które potem i tak tylko leżą i się kurzą ;) Żegnajcie srebrne krążki!

W czasie swojej instalacji, czyli jeszcze zanim posiadłem tę cenną wiedzę, posiłkowałem się tym poradnikiem. Dziękuję.

Fedora 17

Instalując Fedorę 17 napotkałem na problem uniemożliwiający start instalatora w przedstawiony powyżej sposób. Nie instalowałem wcześniej Fedory 15 i 16, więc ich problem również może dotyczyć. Na szczęście rozwiązanie okazało się dość proste. Trochę inaczej wygląda wpis do pliku konfiguracyjnego GRUBa (/boot/grub/grub.conf). W drugiej linii należy ręcznie wskazać położenie obrazu płyty instalacyjnej. W moim przypadku wygląda to następująco:

title Fedora ISO
kernel /boot/vmlinuz repo=hd:/dev/sda8:/sdr
initrd /boot/initrd.img

Poza tym nie musiałem robić niczego więcej, aby instalator uruchomił się.

Wiem, że "bateria jest stara lub uszkodzona"

Co tu kryć, określenie "nowy" już nie bardzo pasuje do mojego laptopa. Również bateria swoje przeszła i pojemność jej nie ta. Od jakiegoś czasu po (re)instalacji Fedory w okolicach obszaru powiadomień zaczął mi się pojawiać komunikat systemowy przypominający o tym fakcie. Wygląda on mniej więcej tak (wersja angielska):


Jestem świadom kondycji mojego sprzętu jednak na wymianę baterii się nie zanosi, a komunikat uparcie pojawiał się przy każdym uruchomieniu systemu. Jeszcze do niedawna można było go wyłączyć za pomocą przycisku "Nie informuj mnie o tym więcej" (czy jakoś tak). Niestety po którejś aktualizacji ten jakże pomocny przycisk zniknął. Oto jak teraz można się pozbyć denerwującego komunikatu.

Uruchamiamy "Edytor konfiguracji" (gconf-editor) i przechodzimy w drzewie widocznym po lewej do gałęzi /apps/gnome-power-manager/notify. W prawej części okna wyświetlone zostaną klucze, których wartości można zmienić.


Odnajdujemy klucz low_capacity i usuwamy znajdujące się przy nim zaznaczenie. Zamykamy okno. Podczas kolejnego uruchomienia systemu komunikat o zużytej baterii nie powinien się już pojawiać. Jeśli system nadal uparcie będzie wyświetlał komunikat warto zainteresować się też kluczem perhaps_recall.