January 20, 2011

4 Comments

PLD Live Installer – wersja 0.24

Minęły jakieś cztery miesiące od wydania wersji 0.1 instalatora wersji Live systemu PLD Linux Titanium (dystrybucji znanej z bycia nieznaną, zaściankową i niepopularną, taką jak kraj z której się wywodzi). Muszę przyznać, że mimo tej niepopularności samego PLD Linux, instalator odniósł wymierny sukces. Było bardzo wiele miłych komentarzy, jeszcze więcej krytyki i ogromna ilość bug reportów i feature requestów – tylko dzięki tym reakcjom (szczególnie tym złym) instalator jest ciągle rozwijany i jak się nieskromnie przyznam, nabiera coraz ciekawszej formy. Wydaje się nawet troszkę bardziej dojrzały.

Wybierz medium

Nowości

Jak już wspomniałem, zaszło wiele zmian od wydania pierwszej wersji. Wiele z nich opisanych jest w ChangeLogu oficjalnej strony projektu, jednak chciałbym opisać co ciekawsze z nich tutaj na moim blogu.

  • ekran startowy informuje użytkownika o jego preferowanych wymaganiach. Pomysł skradziony z instalatora Ubuntu 10.10. Nie mogłem się za to zabrać, aż w końcu niedawno dostałem E-Maila od Kamila Mroczkowskiego z podobnym pomysłem. Przy starcie instalator sprawdza zatem czy mamy co najmniej 1GB RAMu, skanuje dyski i sprawdza czy wśród nich jest choć jeden większy niż 3GB oraz czy jesteśmy podłączeni do źródła prądu. Ta ostatnia opcja odświeżana jest w czasie rzeczywistym w momencie wyciągnięcia kabelka zasilającego. Oczywiście są systemy i dyski, które niepoprawnie pokazują swój stan zasilania oraz które nie są poprawnie wykrywane przez Solid framework
  • Wybierz medium

  • autopartycjonowanie – w 0.24 mamy do wyboru jeden defaultowy schemat partycji, 2GB na Swap i reszta to Linux. W kolejnych wersjach powinny dojść różne inne schematy autopartycjonowania. Jak na pierwszą wersję z tą opcją, wydawało mi się trochę przerostem dodawanie innych. Ten pomysł podrzucił mi Piotr Budny, jeden z najgłośniejszych krzykaczy i również developer PLD
  • dla bardziej zaawansowanych, mamy znany z wersji 0.1 system wyboru partycji. Wyrzuciłem niedziałający KPart partitionmanagera i zastąpiłem go przyciskiem uruchamiającym partitionmanagera – to również pomysł Piotrka. Miłym efektem ubocznym tego rozwiązania, jest jego łatwa konserwacja. Do tego sprawdzanie czy partycja jest odpowiednio duża by zainstalować na niej system wykonywane jest w tle w czasie rzeczywistym, a nie jak poprzednio po kliknięciu w Next – to na życzenie Pawła Gołaszewskiego
  • Wybierz medium

  • w ekranie użytkownika doszła opcja sprawdzania siły wybranego hasła – w sumie fajny ficzer, muszę przyznać. Kredyt za pomysł należy się Adamowi Karczewskiemu
  • instalator dorobił się funkcji automatycznego uaktualniania. Oznacza to, że jeżeli wkradnie się jakiś mały lecz uciążliwy błąd, nie trzeba będzie ściągać nowego ISO z poprawionym instalatorem, lecz przy uruchomieniu instalator poinformuje nas, że jest dostępna nowsza wersja i że można się uaktualnić. Jeśli zmiany są zbyt duże jednak, taka aktualizacja nie będzie zbawieniem. Użytkownicy wersji 0.22 nie powinni zatem czekać na update, bo go nie będzie
  • nowości jest więcej, ale większość to kosmetyka, jak np. możliwość wyboru czy chce się formatować partycję albo instalować bootloadera czy skorzystać z istniejącego, i nie będę się z nich spowiadał

Poprawki

  • chyba najczęściej zgłaszanym błędem był niedziałający przycisk restartu systemu po udanej instalacji – oznajmiam zatem, że jest już przeszłością
  • dzięki Bartłomiejowi Zimoniowi udało się też ograniczyć żarłoczność RAMu
  • ustawianie hasła dla roota i dopisywanie użytkownika do grupy wheel również było pożądaną opcją

Podziękowania

Osobiście chciałbym podziękować wszystkim zaangażowanym w rozwój instalatora, za wytrwałość w testowaniu i upór w zgłaszaniu błędów (bo ja lubię zapominać). Szczególnie upartym testerem był Sajmon z forum.pld-linux.org. Dzięki.

Bijcie! i do kolejnej wersji!

October 27, 2010

6 Comments

Upgrade MacPorts i czyszczenie śmieci

Od dawna używam MacPorts, bo cenię sobie takie command-line programy jak wget czy lftp. Nie znam lepszego sposobu pod Makiem, jak sobie je skompilować właśnie używając MacPorts. Problem jedynie w tym, że robiąc upgrady, MacPorts nie usuwa starych wersji, ani nawet plików tymczasowych. Po dłuższym czasie może się okazać że /opt zajmuje już sporą część dysku. U mnie sprawa wyglądała tak:

macbookpro:~ root# du -sh /opt/
772M	/opt/

Sporo, szczególnie, że naprawdę nie używam wiele więcej z MacPorts niż te wyżej wymienione programy. Taki stan miałem po wykonaniu:

port upgrade outdated

kiedy to się zorientowałem, że kiedy stary pakiet przechodzi w stan deactivated nie jest usuwany. Bummer! Na szczęście port umożliwia ręczne czyszczenie takich “śmieci”. Oto krótki sposób jak to zrobić.

Na początek sprawdźmy co się stanie jeśli usuniemy wszystkie pliki tymczasowe z buildroota pakietów:

port clean --all installed

Po tej operacji zwolniło się u mnie trochę ponad 200MB.

macbookpro:~ root# du -sh /opt/
532M	/opt/

Teraz możemy usunąć nieaktywne porty:

port -f uninstall inactive

Kolejne 200MB mniej na dysku:

macbookpro:~ root# du -sh /opt/
332M	/opt/

Należałoby zatem zapamiętać sobie te komendy i wykonać za każdym razem kiedy robimy upgrade pakietów.

Na koniec jeszcze parę przydatnych komend:

port -f activate pakiet@wersja - aktywuje konkretny pakiet
port installed - listuje wszystkie zainstalowane pakiety
port installed inactive - listuje zainstalowane lecz nieaktywne pakiety
port installed active - i vice-versa
port selfupdate - autouaktualnienie samego programu port i jego bazy portów

Bijcie!

September 16, 2010

5 Comments

PLD Live z graficznym instalatorem – czy czymś w tym rodzaju

Że niby co mną kierowało…

Kiedyś, jakieś pół roku temu, zagadał mnie pewien gostek. Wirtualnie znamy się już parę dobrych lat, stąd też czasami lubię poczytać jego marudzenie. Los chciał, że padło na PLD i jakież to żałosne, że zwykły użytkownik nie może sobie jakoś prosto zainstalować tego systemu. Było już wtedy CRI, był też ChrInst, ale mimo to, coś mu tam nie wychodziło i do tego chyba ma/miał awersję do takich tekstowych instalatorów. Ja mu się tam szczerze mówiąc nie dziwie. Czasami człowiek chce coś prostego.

Wybierz medium

Zacząłem sobie krótko po tej rozmowie dłubać w Qt4 i API KDE4 i pisać nad jakimś łatwym konfiguratorem środowiska mojej płytki live. Ot, miało to wyglądać tak, że użytkownik uruchamia sobie LiveCD i mu wyskakuje taki prosty asystent, który w paru prostych krokach skonfiguruje mu tą płytkę, żeby mógł zacząć pracować. Program nawet działa, ale projekt jest totalnym FAILem. Oparte na API KDE i jego KCM modułów musiało przegrać z wyobrażeniem o prawdziwym konfiguratorze (coś jak kiedyś pldconf, tylko że graficzne). Nie mniej jednak, doświadczenie zdobyte przy tej dłubaninie pozwoliło pomyśleć nad czymś bardziej twórczym. Trzeba było napisać instalator.

Założenia są proste

Instalator ma być prosty, a swą budową ma przypominać cep. Żeby to założenie spełnić, trzeba mieć coś co działa u większości ludzi – LiveCD. To przecież gotowy system.

A teraz partycje

Wystarczy go tylko odpowiednio spreparować i przekopiować na wyznaczone przez użytkownika medium. Proste! I tak naprawdę instalator nie robi niczego innego. W paru prostych krokach pozwala użytkownikowi wybrać dysk, partycję, nazwę użytkownika i nazwę swojego komputera, a następnie zaczyna czarować w tle te wszystkie czary, które zaawansowani użytkownicy PLD robią ręcznie. Oczywiście to co się dzieje wewnątrz do najprostszych rzeczy nie należy. Trzeba przecież założyć, że użytkownik jest debilem (wybaczcie, to nic osobistego) i sprawdzać kilkakrotnie czy to co on w ogóle zaznaczył ma sens i nie koliduje z jakimiś innymi ustawieniami. Jeśli wszystko jest ok, to już wtedy zostaje zrobić sobie kawę i się zrelaksować aż do momentu, gdy instalator krzyknie, że coś poszło nie tak, albo jeszcze gorzej, że instalacja zakończyła się pomyślnie.

Ok, to już mamy. Co dalej?

Instalator w formie jaką opisałem wyżej jest już dostępny do pobrania wraz z najnowszą kreacją PLD Live z KDE4 4.4.5 (oficjalna strona projektu). Doskonale zdaję sobie jednak sprawę, że dla niektórych bardziej wymagających, mimo to początkujących, użytkowników to za mało.

“Jeszcze się taki nie narodził, co wszystkim dogodził.”

Dodaj się

Zatem jakie są dalsze plany? W chwili obecnej pracuję nad jakimś prostym sposobem autoupdate’u instalatora. Po uruchomieniu jest sprawdzana najnowsza dostępna wersja i jeśli coś nowego jest dostępne, to się uaktualniamy – a najlepiej, żeby użytkownik jak najmniej o tym wiedział. Od wyżej wymienionego gostka, dostałem też propozycje by może sprawdzać siłę ustawionego hasła – czemu nie, można. Jeszcze nie wiem jak, ale pewnie ktoś już kiedyś to wymyślił. Kusi mnie również by w jakiejś opcji dla zaawansowanych dodać możliwość instalacji minimalnego chroota, którego najpierw trzeba by było ściągnąć. Na różne okazje różne chrooty, bo jakoś nie za bardzo podoba mi się opcja z instalowaniem tego via poldka i wyłapywaniu błędów jakie sam poldek/rpm ze sobą niesie.

Na inne propozycje jestem otwarty. Na ręce do pomocy również. Sam mam bardzo mało doświadczenia w pisaniu aplikacji Qt4/KDE4 jak i równie mało w pisaniu instalatorów.

W sumie to mogę pomóc, ale nic nie obiecuję, tylko gdzie jest kod?

Kod jest u mnie. W moim prywatnym repozytorium. Nie publikowałem jeszcze w SVNie PLD i nie wiem do końca czy chcę to robić. PLD jako “twór” przecież jest zdania, że instalator jest zbędny, bo każdy z odrobiną oleju w głowie umie zainstalować sobie za pomocą chroota. Ja natomiast od jakiegoś czasu jestem zdania, że jest to tylko częściowo prawda, a sam chciałbym bardziej rozreklamować PLD i pokazać, że Polacy nie pingwiny. Także jeśli chcesz jakoś pomóc, zgłoś się do mnie – pogadamy.

Tipsy i tricksy

Na koniec mała podpowiedź dla tych, którzy zdecydują się zainstalować PLD używając graficznego instalatora, a przy okazji chcieliby soft ciut inny niż na LiveCD. Wystarczy zupdatować indeksy poldka, zainstalować co się podoba i dopiero wtedy, rozpocząć instalację. Ważne tylko, by nie odinstalować rzeczy potrzebnych instalatorowi.

Zapraszam.

November 16, 2009

10 Comments

PLD-Linux/Grub2/UUID

Krótkie HOWTO jak zrobić w PLD-Linux Grub2 i UUID.

Instalacja komponentów

# poldek -ivh util-linux-ng-initrd grub2 libblkid libuuid 

Przygotowanie systemu do działania z UUID

Edytujemy /etc/sysconfig/geninitrd i dodajemy wpis:

USE_BLKID=yes

Edytujemy /etc/fstab i zmieniamy przykładowy wpis:

/dev/sda3      /                       ext3    defaults                1       1

na

UUID=a060d854-e5b0-4940-987d-ca9e04c4c887       /                       ext3    defaults                1       1

gdzie a060d854-e5b0-4940-987d-ca9e04c4c887 to nasze UUID, które wzięliśmy wykonując:

# ls -l /dev/disk/by-uuid/

i patrząc co linkuje do naszego “sda3”. Teraz musimy wygenerować nowe initrd:

# geninitrd -f -v /boot/initrd-2.6.32-desktop-0.rc7.4.gz 2.6.32-desktop-0.rc7.4

Jeśli kernel, który używamy to 2.6.32-desktop-0.rc7.4.

Konfiguracja Grub2

Tutaj jest znacznie prościej niż w przypadku grub 1.

# grub-mkconfig -o /boot/grub/grub.cfg

To potrwa chwilkę po czym możemy (acz, nie musimy) wyedytować ten plik w celu kosmetycznych zmian (usunięcie zbędnych rzeczy, dodanie ciekawych rzeczy), u mnie wygląda to przykładowo tak:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry "PLD Linux Titanium with Kernel Desktop" {
	insmod ext2
	insmod gfxterm
	insmod vbe
	set root=(hd0,3)
	set gfxmode=1024x768
	set gfxpayload=1024x768x16
	linux	/boot/vmlinuz-desktop root=UUID=a060d854-e5b0-4940-987d-ca9e04c4c887 ro quiet splash=silent
	initrd	/boot/initrd-desktop
}
menuentry "PLD Linux Titanium with Kernel Desktop (recovery mode)" {
	insmod ext2
	set root=(hd0,3)
	linux	/boot/vmlinuz-desktop root=UUID=a060d854-e5b0-4940-987d-ca9e04c4c887 ro single 
	initrd	/boot/initrd-desktop
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

Następnie wykonujemy już tylko:

# grub-install --force --no-floppy /dev/sda
# reboot

Od tej pory system powinien korzystać z UUID, a przy starcie powinien meldować się Grub2. Oczywiście Grub2 można jeszcze dopieścić dodając mu grafikę (insmod png), ładne fonty (insmod font) itd.

To tyle. Mówiłem, że będzie krótko.
Bijcie!

November 8, 2009

8 Comments

Spadaj świnio!

świńska grypa

Prawdziwych przyjaciół poznaje się będąc świnią :-)

October 13, 2009

5 Comments

CGIWrapa ciąg dalszy – spersonalizowane php.ini

W poprzednim artykule nauczyliśmy się uruchamiać PHP z prawami użytkownika wykorzystując CGIWrap. W tym krótkim opisie, pokażę jak można dodatkowo spersonalizować php.ini dla każdego użytkownika, by zapewnić jemu jak najlepszą obsługę, ale również nie narażać swojego systemu na niepotrzebne ryzyko.

Trochę witaminy C nikomu nie zaszkodziło

Typową metodą by uzyskać spersonalizowane php.ini jest wyeksportowanie w jakiś sposób zmiennej środowiskowej PHPRC. W przypadku mod_php za pomocą SetEnv, w przypadku rewritów częstym sposobem jest definiowanie zmiennej w samym rewricie za pomocą E=PHPRC:${dir2owner:${…}} gdzie dir2owner jest RewriteMapą typu ‘prg’, która mapuje właściciela wykonywanego skryptu lub katalogu w którym znajduje się skrypt. Aż w końcu w przypadku cgi/fastcgi jest dodanie do wrappera shellowego odpowiedniej definicji export.


W przypadku CGIWrapa najlepszą metodą będzie po prostu wyeksportowanie PHPRC w samym kodzie CGIWrapa. Do tego celu sporządziłem następującego patcha:

--- fetch.c	2009-10-13 03:28:00.734065077 +0200
+++ fetch.c-new	2009-10-13 03:28:17.407378494 +0200
@@ -30,10 +30,13 @@
 	char *pathInfoString;
 	char *queryString;
 	char *userStr;
+	char *phprc;
+	char *phpdir;
 
 	DEBUG_Msg("\n");
 
 	userStr = (char *) 0;
+	phpdir = "/etc/php/users.d/";
 	//pathInfoString = getenv("PATH_INFO");
 	pathInfoString = getenv("PATH_TRANSLATED");
 	if ( pathInfoString )  /* use PATH_INFO */
@@ -44,6 +47,11 @@
 			DEBUG_Msg("Trying to extract user from PATH_TRANSLATED.");
 
 			userStr = GetPathComponent(1, pathInfoString);
+			phprc = (char *)malloc((strlen(phpdir) + strlen(userStr) + 1) *sizeof(char));
+			strcpy (phprc , phpdir);
+			strcat (phprc , userStr);
+			setenv("PHPRC", phprc, 1);
+			DEBUG_Str("Setting PHPRC to ", phprc);
 		}
 		else
 		{

(patch do ściągnięcia stąd)

Definiujemy sobie w ten sposób katalog w którym PHP będzie się spodziewać plików php.ini dla użytkowników (w tym przypadku jest to katalog /etc/php/users.d/$USER/, gdzie $USER to użytkownik systemu). Katalog można ustawić w zmiennej “phpdir” w patchu.

Z tą poprawką nie musimy już nic więcej przekazywać serwerowi Apache. Wystarczy podmienić poprawioną binarkę CGIWrapa i bez restartu Apache, cieszyć się spersonalizowanymi php.ini.

Użytkowników PLD-Linux ucieszy być może fakt, że patch jest już częścią dystrybucyjnego CGIWrapa od release 5.

Bijcie!

October 11, 2009

No Comments

Apache, vhosty za pomocą mod_rewrite i cgiwrap (czyli php wykonywane z prawami użytkownika) – HOWTO

Dzień dobry, smacznego, dobry wieczór i dobranoc (w zależności o jakiej porze czytasz te bzdury). Dawno nic nie pisałem, tym bardziej cieszę się zaprezentować coś choć w części interesującego. Zajmę się dość ciekawą kombinacją – Apache + mod_rewrite + cgiwrap.

Wymagania

Ponieważ używam standardowej konfiguracji PLD-Linux, jeśli chodzi o użytkowników, równie standardowa będzie konfiguracja Apache (co zarazem znaczy, że jest to bardzo specyficzna konfiguracja i wiem, że z inną konfiguracją poniższy opis nie będzie funkcjonować).

Wymagane są następujące komponenty:

  • Apache 2.2 + mod_rewrite
  • cgiwrap-4.1 + ten patch (lub jeśli używamy PLD-Linux – cgiwrap-4.1-4.*.rpm)
  • konta użytkowników w /home/users
  • strony użytkowników w /home/users/*/public_html
  • zdrowy, nie przepity, nie zaćpany rozum i chęć zrozumienia idei
  • dobra znajomość mod_rewrite (bo nie wszystko chce mi się tłumaczyć)

Apache + vhosty za pomocą mod_rewrite

Dlaczego nie po prostu mod_vhost_alias? W sumie tylko z dwóch powodów:
1. Po każdym wpisie nowego virtualhosta trzeba restartować Apache
2. Wpis zajmuje parę linijek, z lenistwa wolę pisać tylko 1 (mod_rewrite)

Reasumując plusy dodatnie i plusy ujemne tego przedsięwzięcia, mamy taką oto listę.

Plusy:

  • nie trzeba restartować Apache po dodaniu nowego vhosta
  • krótkie wpisy = mało zmarnowanego czasu
  • cachowanie vhostów – Apache mod_rewrite potrafi automatycznie cachować zmapowane rewrity by działać szybciej
  • użytkownik może sam sobie dodawać vhosty jeśli da mu się odpowiednie prawa/udostępni odpowiednią automatykę

Minusy:

  • brak wildcardów (niektórzy powiedzą, że to plus), czyli wpisów z gwiazdką ‘*’
  • niektóre niedogodności lub banalne ustawienia w mod_vhost_alias trzeba obchodzić kolejnymi zagmatwanymi rewritami
  • rewrite sam w sobie, można się pogubić :-)
  • wywołania http://domena.pl/~user nie działają (co dla niektórych też jest plusem)

Ulubionym edytorem tekstu edytujemy plik /etc/httpd/httpd.conf/00_mod_rewrite.conf i dodajemy następujące wpisy:

RewriteEngine On

RewriteMap      lowercase       int:tolower
RewriteMap      vhost txt:/etc/virtualhosts.map

RewriteCond     %{REQUEST_URI}  !^/icons/
RewriteCond     %{REQUEST_URI}  !^/error/
RewriteCond     %{REQUEST_URI}  !^/cgi-bin/
RewriteCond     ${lowercase:%{HTTP_HOST}}       ^domena.pl$
RewriteRule     ^/~(([a-z])[a-z0-9-]+)(.*)      http://$1.domena.pl$3 [R,L]

RewriteCond     %{REQUEST_URI}  !^/icons/
RewriteCond     %{REQUEST_URI}  !^/error/
RewriteCond     %{REQUEST_URI}  !^/cgi-bin/
RewriteCond     ${lowercase:%{HTTP_HOST}}       ^(.+)$
RewriteCond     ${vhost:%1}   ^(/.*)$
RewriteRule     ^/(.*)$ %1/$1   [E=VHOST:${lowercase:%{HTTP_HOST}}]

Krótkie wytłumaczenie. RewriteMap (/etc/virtualhosts.map) zawiera wpisy w formacie:

user.domena.pl		/home/users/user/public_html
domena2.com		/home/users/user150/public_html
itd...

Jaki typ RewriteMap wybierzemy jest obojętne. Ja wybrałem “txt” bo automat dodaje mi vhosty użytkowników. Dodatkowo nie pozwalamy nadpisywać aliasów dla ikon, stron z błędami oraz globalnego katalogu cgi-bin. Ponieważ URLe http://domena.pl/~user nie działają, a niektórzy na pewno będą próbowali się tak odwoływać do własnej strony, to przepisujemy te adresy na adresy typu http://user.domena.pl (pierwszy RewriteRule). Następnie już tylko mapujemy odpowiedni vhost do jemu przyporządkowanego (w RewriteMapie) katalogu.

Od tej pory mamy działające virtualhosty i możemy je używać bez problemu z mod_php.

CGIWrap – czyli php wykonywane z prawami użytkownika

Przypominam, że CGIWrap z patchem, którego udostępniam działa tylko z taką konfiguracją. Jest to spowodowane tym, że obliczam w CGIWrapie użytkownika na podstawie jego katalogu domowego i edytuje odpowiednio zmienne środowiskowe PATH_INFO oraz PATH_TRANSLATED.

Ulubionym edytorem tekstu edytujemy plik /etc/httpd/httpd.conf/01_mod_cgid.conf i dopisujemy następujące linie:

ScriptAlias /cgi-bin/ "/home/services/httpd/cgi-bin/"

<Directory /home/services/httpd/cgi-bin\>
        Options FollowSymLinks ExecCGI
</Directory\>

Action _phpwrap /cgi-bin/php-cgiwrap
AddHandler _phpwrap .php .php4 .php5

Jeśli ktoś nie chce odinstalować mod_php, to nie musi. Wystarczy, że odbierze mod_php przywiązanie do plików o typach zdefiniowanych dla _phpwrap.

Następnie dobieramy się po raz kolejny do pliku /etc/httpd/httpd.conf/00_mod_rewrite.conf i dodajemy:

RewriteMap      cgi     txt:/etc/cgi.map

<Files ~ "\.php$">
#CGIWrap
RewriteCond     %{REQUEST_URI}  ^/
RewriteCond     %{REQUEST_URI}  !^/icons/
RewriteCond     %{REQUEST_URI}  !^/error/
RewriteCond     %{REQUEST_URI}  !^/cgi-bin/
RewriteCond     ${lowercase:%{HTTP_HOST}}       ^(.+)$
RewriteCond     ${cgi:%1}       ^(/.*)$
RewriteRule     ^/(.*)$ %1/$1 [PT,E=REDIRECT_STATUS:200]
</Files>

Jeśli Apache wypluje nam coś o tym, że cgi nie działa ponieważ REDITECT_STATUS nie jest poprawnie ustawiony, to należy dodać go analogicznie do poprzedniego RewriteRule.
/etc/cgi.map zawiera wpisy w formacie:

user.domena.pl		/cgi-bin/php-cgiwrap/
domena2.pl			/cgi-bin/php-cgiwrap/
itd...

To chyba wszystko co należy skonfigurować. W razie problemów włączamy sobie:

RewriteLog      /var/log/httpd/rewrite_log
RewriteLogLevel 9

i oglądamy sobie co jest nie tak, jeśli problem jest w mod_rewrite. Jeśli problem jest w CGIWrapie, to jako handlera wybieramy np. php-cgiwrapd – wtedy dostaniemy output z debugiem.

Mam nadzieję, że o niczym nie zapomniałem, bo wpis ten traktuję głównie jako notkę do siebie ;-) Korzystając z okazji pragnę podziękować za pomoc zbyniowi i sparkiemu.

Bijcie!

October 30, 2007

4 Comments

Leopard (cd)

Time Machine

Ok. Wczoraj trochę zjechałem Time Machine za parę błędów. Dzisiaj dla odmiany postaram się zjechać TM jeszcze bardziej. Nie dała mi po prostu wczoraj spać. Ale zaprezentuję też rozwiązanie, które jak na razie działa bardzo dobrze.
Time Machine Error
Wczoraj w nocy, kładąc się spać pomyślałem, że skoro i tak nie korzystam z komputera śpiąc (hehe) mogę w końcu spokojnie zapuścić Time Machine na te tajemnicze 20Gb, które wykrył do backupu. Zaczęło się jak zwykle “pięknie”, preparing ok. 30min po czym ruszył z kopyta backupując jakieś 100kbps (co mnie bardzo zaskoczyło, że aż tak prędko to robi – przypominam, że wcześniej po ponad godzinie miał 160Kb!!). Zadowolony położyłem się spać przy uspokajającym szumie wentylatorów w laptopie (pełne obroty oczywiście). Jednak zanim zdążyłem zasnąć wentylatory przestały się kręcić i maszynka zaczęła cichutko działać tak przed siebie. Wstałem zobaczyć co to. Czyżby już backup został zakończony? TAK!! Z cudownym errorem (który mi się już w ciągu tych paru dni powtarzał, ale go ignorowałem) jaki widać na załączonym obrazku.
Time Machine Success
Naprawdę jest to uciążliwe, szczególnie, że już później wykrywał zawsze te 20Gb i więcej do backupu i jak mi się wydaje, zawsze by kończył ten backup błędem. Z pomocą przyszedł mi Disk Utility którym postanowiłem przeformatować na szybko partycję przeznaczoną dla Time Machine tym razem jednak wybierając ciut inny system plików HFS+ bez opcji Case-Sensitive (po prostu tylko HFS+ Journaled). Format trwał sekundkę lub dwie, załączyłem Time Machine po raz kolejny. Poprawnie wykrył, że na partycji nie znajdują się już żadne backupy i wyznaczył czas kolejnego backupu na za godzinę. Rano zauważyłem, że Time Machine zadziałał parę razy w nocy bez żadnego zgrzytu co potwierdziło też TM-GUI, które już miało trochę historii do pokazania (to nic, że tam się nic nie zmieniło ;-)). Mam nadzieję, że to naprawdę był problem nadgorliwego z mojej strony formatu partycji na HFS+ Case-Sensitive and Journaled (Time Machine oficjalnie tego właśnie nie wymaga) i że jest to po prostu błąd, który objawia się takimi brzydkimi błędami jak u mnie.
Time Machine GUI
Co jak co, skoro już TM działa poprawnie i jest wszystko cacy, to muszę przyznać, że jest bardzo fajnym narzędziem dzięki któremu mam trochę mniej zmartwień pracując na komputerze. Przejdę zatem do innych ciekawych zmian w Leopardzie.

Unix Certified

Co to tak w ogóle oznacza dla zwykłego użytkownika? Oznacza nie mniej nie więcej tylko tyle, że jesteśmy w końcu up-to-date z obecnym standardem, czyli jakakolwiek przesiadka na innego Uniksa (niech to będzie FreeBSD, Solaris, AIX, Hp-UX czy w końcu Linux) nie będzie dla nas taka bolesna (przynajmniej z poziomu konsoli). Między innymi dlatego też zmieniło się mapowanie klawiatury w Macintoshach. Teraz by napisać literkę “ż” wciskamy Alt+z, a nie jak do tej pory Alt+x – co ułatwia trochę pracę gdy często przesiadamy się z jednego systemu operacyjnego na drugi. Do tego wszystkiego dochodzi też lepsza optymalizacja do architektury intelowskiej (to już nie ma nic wspólnego z certyfikatem uniksa, ale jest miłym gestem ze strony twórców). Szczególnie ucieszą się posiadacze Intel Core 2 Duo gdyż Leopard w pełni korzysta już z możliwości 64bitowej architektury. Ja się w tej kwestii więcej nie wypowiadam bo mam tylko Core Duo 32bit. Kolejną nową i fajną rzeczą (którą każdy linuksowiec zna od wieeeelu lat) są…

Spaces

Czyli dobrze znane wirtualne pulpity, które oprócz tego, że ułatwiają ogarnięcie tych często fünfnastu naraz uruchomionych aplikacji, to jeszcze zupełnie inaczej wyglądają niż te znane z Linuksa (czy to z compizem i berylem w postaci cube’a czy też w postaci zwykłych prostokątów w standardowych iXach).
spaces

Dock

dock
Dock dorobił się nowego wyglądu. Jest teraz ładnie glossy co znaczy, że odbija każdy odbłysk innej aplikacji na sobie i wygląda trochę jak glazura cukrowa na pączkach z nadzieniem truskawkowym. Oczywiście komu ten nowy wygląd nie pasuje może łatwo wrócić do starego, bez tych wszystkich odbłysków:

#defaults write com.apple.dock no-glass -boolean YES
#killall Dock

stack
Doszła też bardzo fajna opcja – stacks. Pozwala ona w końcu mieć więcej aplikacji, dokumentów, czegokolwiek pod ręką w Docku, gdzie szybko i sprawnie można się do nich dobrać.
Do tego całkiem nieźle wygląda. Sposób wyświetlania można ustawić z pośród: fan (na obrazku), grid lub automatic (ustawia się na fan lub grid w zależności jak wiele elementów jest do wyświetlenia).

Tym jednak dość optymistycznym akcentem kończę mój wywód na temat Leoparda, mimo że wypadałoby napisać też coś o Dashboardzie, Safari i Terminalu, który w końcu ma zakładki. Ale po prostu mi się nie chce, szczególnie że przecież Apple sam sobie już robi niezła reklamę na swoich stronach. Bijcie!

October 29, 2007

18 Comments

Leopard

Leopard BoxOd paru dni (dokładnie od piątku 26.10) jestem posiadaczem nowego Mac OS X 10.5 pieszczotliwie przez niektórych nazywanego “Leosiem”, a którego ja nazywam jak jego twórcy – Leopardem. Jest to szóste wydanie flagowego produktu software’owego firmy Apple i za razem najnowocześniejszego (ooo ha, let the flame begin) systemu operacyjnego przeznaczonego na desktop. Posiada ponad 300 nowych funkcji w porównaniu do jego poprzednika – Tigera, i o ile nie będę tu pisał jakie to “bajery” i co za “eye candy” (bo od tego jest apple.com/macosx) Leopard posiada tak postaram się opisać pierwsze wrażenia, miłe i mniej miłe zaskoczenia i gołym okiem widoczne zmiany.

Instalacja

Upgrade
Instalacja

Jako, że wcześniej korzystałem z Tigera 10.4.10, postanowiłem zrobić mały backup swojego katalogu domowego i wykorzystać opcję upgrade do pierwszej instalacji Leoparda. Opcja o tyle fajna, że zachowuje wszystkie ustawienia, pliki, programy etc. ale mimo to warto zrobić wcześniej backup. Problem jaki natychmiast po tym wystąpił było przeraźliwe indeksowanie dysku przez procesy Cover Flow i inne takie miłe dla oka bajery, co skutkowało przycinaniem się Docka, Expose, Spaces i wszystkich tego typu programów z animowanymi wejściami/wyjściami. Wkurzało mnie to bardzo, więc postanowiłem przeformatować mój external HD i skorzystać z Time Machine jako programu backupującego, by od razu po tym, uruchomić ponownie instalacje tym razem jako…

Clean & Install

InstalacjaTa opcja działa podobnie jak upgrade z tą różnicą, że najpierw formatuje cały dysk docelowy a następnie instaluje już same Leopard-specific oprogramowanie. Plus tego ogromny bo, żadne pozostałości Tigera nie przeszkadzają w pracy i nie spowalniają działania systemu. W czasie instalacji mój external HD był ciągle podłączony do komputera, dzięki czemu po zakończeniu instalacji i pierwszym boocie z dysku Leopard automatycznie wykrył, że jedna partycja dysku zawiera backup zrobiony przez Time Machine i grzecznie pyta, czy chciałbym zaimportować wszystko, a może tylko jakąś wybraną część. Postanowiłem zaimportować wszystko, czyli wszystkie aplikacje, moje osobiste dokumenty, muzykę oraz ustawienia sieci i większości programów.Import najważniejszych rzeczy z backupuEfekt tym razem jest już znacznie lepszy. Dock i inne aplikacje animują się już błyskawicznie szybko, Cover Flow nie indeksuje przeraźliwie dysku, przez co praca jest miła i szybka, Spaces przeskakują płynnie i szybko z miejsca na miejsce a nawet jakby znany i lubiany Dashboard zyskał trochę na “speedzie”. To wszystko na moim MacBooku 1.1 z marną grafiką Intela i950GMA, więc to już naprawdę coś, że to wszystko się nie zakrztusiło z przesytu formy nad treścią. Dodatkowo oczywiście Time Machine automatycznie wykryło swoją partycje i co godzinę robi backup. Ale właśnie a`propos tego nieszczęsnego…

Time Machine

Program jak najbardziej genialny i prosty w obsłudze za razem. Jeśli chodzi o mnie, to zdecydowanie za prosty (w obsłudze i nie tylko) i na dodatek na tyle absorbujacy dyski twarde, że w czasie tego “przeźroczystego” backupu nie da się pracować na komputerze. Tzn. też tak nie do końca. Bywa po prostu czasami tak, że TM ni z gruchy ni z pietruchy (przynajmniej jeszcze nie doszedłem do tego dlaczego) zauważa strasznie duże zmiany na dysku, których przed godziną jeszcze nie widział, a które trzeba przecież zbackupować. Wynik jest taki, że do zbackupowania jest 15Gb danych (WTF!?), preparing to backup trwa ~50min a po bitej 1h 20min raptem 160Kb zostały zapisane na dysku zewnętrznym. Baaardzo dziwne. Do tego naprawdę jakakolwiek płynna praca na komputerze jest niemożliwa – dyski 100% odczytu, 100% zapisu. Jedyne wyjście jakie w tym widziałem to po prostu wyłączyć Time Machine i włączyć np. na noc. Niestety nie da się uruchomić Time Machine kiedy się tego chce. Po włączeniu program informuje kiedy on zrobi kolejny backup. Także przycisk “backup now!” można narysować sobie tylko na kartce. Nie da się również ustalić by backup wykonywany był raz dziennie o konkretnej porze (a’la cron job). Po prostu backup robiony jest co godzinę albo wcale. Tutaj Apple powinno jeszcze popracować nad tym. Mimo tego jest to przydatne narzędzie, a przede wszystkim restore utraconych danych jest bajecznie prosty.

cdn (tam wyżej)

October 3, 2007

27 Comments

Gadu Gadu, a Mac

Nie ma dobrego klienta Gadu Gadu na Maka. No nie ma, bij, zabij – nie ma.
Kadu ssie maksymalnie – pod linuksem troszkę mniej, ale jednak ssie. Adium to też tak nie za bardzo podchodzi pod kryterium dobrego supportu protokołu gg. Więc co tu brać? Idealnym rozwiązaniem tego problemu to w końcu całkowicie zrezygnować z Gadu Gadu – przecież ten protokół to jedno wielkie nieporozumienie – i resztę nieuświadomionych kontaktów przenieść sobie do jabbera (nie, broń boże do transportu-gg na jabberze, bo to ssie mocniej niż samo kadu). Ale niestety tak prosto nie jest w życiu, bo przekonać ludzi do zmiany komunikatora jest trudniej niż stanąć na rzęsach wśród rozgoryczonego tłumu moherowych beretów i namawiać do głosowania na inna partię niż to ojciec ich naczelny im nakazuje. Poza tym argument, że przecież “cała Polska używa Gadu Gadu w tym wszyscy moi znajomi” należy do tych niepodważalnych i ciężko konkurować z nim podając choćby takie, że jabber jest zdecentralizowany i open source… Ehh, nieważne. Z pewnością istnieje wiele innych komunikatorów dla Maka, które potrafią jakoś tam obsłużyć to nieszczęsne Gadu Gadu, ale że pamiętam czasy kiedy KDE było w wersji 2.0 (ba, to była wtedy nowość! ;-) ) i korzystało się wtedy głównie z konsoli to postanowiłem wrócić do EKG. Polecam wszystkim którzy nie boją się terminala. EKG ma jednak jeden problem – nie umie jakoś wizualnie powiadomić, że ktoś do nas napisał czy zaczął rozmowę jeśli akurat nie patrzymy się w to okienko lub jest całkowicie zakryte przez inne. Każdy Makowiec powinien jednak znać Growla. I właśnie Growl przychodzi nam z pomocą, bo jego growlnotofiera można zaprząc do współpracy z EKG. Wygląda to wtedy tak:
EKG + Growl
Prawda, że z takim czymś można już pracować? Mnie się podoba.