wtorek, 11 listopada 2008

Zepsuło się - naprawiamy obsługę SQLite w PHP

Wczoraj chciałem napisać niewielki skrypt w PHP. Skrypcik malutki, ale byłby stosunkowo często wykorzystywany (jakieś kilka tysięcy razy na dzień :P). Aby zanadto nie męczyć MySQL'a postanowiłem spróbować wreszcie wykorzystać SQLite - bazę prostą, ale wygodną, szybką i posiadającą wystarczające możliwości. W końcu chodzi tylko o najzwyklejsze składowanie danych.

Kolejną sprawą było PDO, z którego również nigdy wcześniej nie korzystałem. Natrafiła się więc idealna okazja do nadrobienia zaległości i bliższego poznania obu ciekawych rozwiązań. Jakież było w związku z tym moje zdziwienie, gdy zauważyłem, że SQLite i PDO u mnie nie współpracują. Po wielu próbach okazało się, że winnym zaistniałej sytuacji jest brak rozszerzenia sqlite.so w mojej instalacji PHP. Trochę mnie to zdziwiło biorąc pod uwagę fakt, że w czasie instalacji serwera dodałem do niego chyba wszystko co było możliwe. Jak widać, byłem w błędzie ;P Nadróbmy więc stracony czas.

Niestety gotowej do podrzucenia w systemie biblioteki sqlite.so raczej nie znajdziemy. Trzeba ją w takim razie przygotować sobie samemu. Poniższe rozwiązanie znalazłem na forum PHPBuilder. Aby jednak wdrożyć je w systemie Fedora 9 konieczne jest dokonanie kilku kosmetycznych zmian. Pełny tutorial znajdziecie poniżej.

Z serwera PHP pobieramy najpierw plik SQLite-1.0.3.tgz (mirror). Komendą

pecl download sqlite

zawsze możemy pobrać najnowszą wersję. Archiwum rozpakowujemy, odpalamy terminal i wchodzimy do nowopowstałego katalogu SQLite-1.0.3. Po upewnieniu, że wewnątrz znajduje się plik config.m4 wpisujemy kolejno

phpize
./configure

Następnie w ulubionym edytorze tekstu otwieramy plik sqlite.c i dokonujemy stosownych podmian. Linię

static unsigned char arg3_force_ref[] = {3, BYREF_NONE, BYREF_NONE, BYREF_FORCE };

zamieniamy na

/* static unsigned char arg3_force_ref[] = {3, BYREF_NONE, BYREF_NONE, BYREF_FORCE }; */

zaś blok

function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, arg3_force_ref)
PHP_FE(sqlite_popen, arg3_force_ref)

na

function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, third_arg_force_ref)
PHP_FE(sqlite_popen, third_arg_force_ref)

Plik zapisujemy i zamykamy. Wracamy do terminala, logujemy się na konto root i wydajemy kolejne polecenia

make
make install
ls /usr/lib/php/modules/

Naszym oczom powinna ukazać się lista rozszerzeń PHP. Jeśli widzimy tam sqlite.so to znaczy, że wszystko poszło idealnie.

Tip: Instalator powinien sam przenieść nowe rozszerzenie do odpowiedniego katalogu. Jeśli jednak tego nie zrobi, musimy dokonać tego samodzielnie. Plik sqlite.so znajdziemy w naszym folderze roboczym w podkatalogu modules.

Póki co jednak PHP nie widzi nowego rozszerzenia, musimy jeszcze dopisać je do konfiguracji i zrestartować serwer Apache.

cd /etc/php.d/
cp pdo_sqlite.ini sqlite.ini
vim sqlite.ini

Zawartość pliku sqlite.ini zmieniamy odpowiednio z

; Enable pdo_sqlite extension module
extension=pdo_sqlite.so

na

; Enable sqlite extension module
extension=sqlite.so

i zapisujemy. Teraz pozostaje tylko wspomniane ponowne uruchomienie usługi httpd i SQLite zaczyna nam śmigać.

/etc/init.d/httpd restart

Dostępne od tej pory są zarówno fukcje sqlite_* jak i możemy obsługiwać bazy przez interfejs PDO.

Na koniec warto jeszcze wspomnieć o pewnych utrudnieniach związanych z korzystaniem z baz SQLite w PHP. Aby uniknąć różnych problemów z zapisem do bazy należy pamiętać nie tylko o ustawieniu uprawnień do niej na 666, ale również do katalogu, w którym jest przechowywana na 777! Jeśli o tym zapomnimy metoda PDO::errorInfo() zwróci komunikat błędu attempt to write a readonly database lub unable to open database file (szczególnie ten drugi niewiele mówi).

Trochę odbiegłem od planu, ale wolałem napisać powyższy artykuł już teraz żeby nie zapomnieć :) Kolejny w związku z tym będzie już tak jak wspominałem ostatnio o serwerze XMPP we własnej domenie. Czekajcie cierpliwie! Kiedyś może jeszcze napiszę co nieco o pracy z SQLite.

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

piątek, 24 października 2008

100% z domeny - #2 Integracja z Aplikacjami Google

Ciężko mi się znowu zabrać do pisania, ale... w końcu kiedyś trzeba się przemóc ;P I właśnie dziś postanowiłem tego dokonać. Tak więc... Witam po, hmm... raz, dwa, trzy... prawie półrocznej przerwie :) Ale zleciało. Na czym to stanęliśmy? Jeśli ktoś jeszcze pamięta, w maju rozpocząłem serię artykułów dotyczących domen internetowych. Rejestrowaliśmy już domenę w GoDaddy, parkowaliśmy ją w MyDomain i podpinaliśmy do własnego serwera. Teraz przyszedł czas na zrobienie z niej większego pożytku, bo przecież domena daje dużo, dużo więcej możliwości niż tylko kierowanie ruchu do naszego serwisu. W związku z tym dzisiaj przy wykorzystaniu bezpłatnych narzędzi od Google zrobimy coś ciekawszego.

Nie muszę chyba mówić, że posiadanie skrzynki pocztowej we własnej domenie (np. z nazwiskiem) to nie lada gadżet - żeby nie powiedzieć prestiż. Zawsze to jakieś wyróżnienie w tłumie ludzi korzystających ze standardowych domen udostępnianych przez portale internetowe. No dobra, może większości ludzi to obojętne. Ale nie mnie. I Wam pewnie też, skoro już to czytacie :) A co jakby tak jeszcze mieć we własnej domenie kalendarz, zbiór dokumentów, identyfikator komunikatora i stronę startową? I gdyby na dodatek były to usługi dostarczane przez Google? Bajka? Nie, rzeczywistość :)

Pewnie większość z Was wie o tym, że od dłuższego czasu Google udostępnia platformę zwaną Google Apps (lub bardziej po naszemu Aplikacje Google). Dzięki niej możemy korzystać na własny użytek oraz udostępniać innym popularne narzędzia tej firmy we własnej domenie. Google oddaje do dyspozycji trzy pakiety w ramach swojej usługi: Wersja standardowa, Wersja profesjonalna, Wersja dla szkół i uczelni. Zwykłych zjadaczy chleba zadowoli Wersja standardowa. Jest ona darmowa i posiada wszystko czego potrzebujemy.

Nowe konto Google Apps

Na początku przechodzimy na stronę Google Apps i klikamy wielki, niebieski button Porównaj wersje i zarejestruj się. Następnie wybieramy kolumnę Wersja standardowa i klikamy Zarejestruj się. Na zakładce Chcę używać istniejącej nazwy domeny zaznaczamy Administrator: jestem właścicielem tej domeny lub zarządzam nią, wpisujemy nazwę domeny i klikamy Zacznij teraz.

Następnie musimy wypełnić formularz podając swoje dane. Uzupełniamy tylko pola w sekcji Administrator konta. W polu Liczba użytkowników możemy podać w zasadzie dowolną ilość, jednak wydaje mi się, że 100 na pewno wystarczy. Zresztą podając liczbę mniejszą i tak system automatycznie przydzieli nam limit stu użytkowników ;P Klikamy Kontynuuj.

Na kolejnej stronie w części opisanej Twoje konto administratora, w polu Nazwa użytkownika podajemy swój login za pomocą którego będziemy uzyskiwać w przyszłości dostęp do panelu. Może to być przykładowo: admin, administrator, ale równie dobrze możemy podać też swoje imię lub nick. Nazwa ta będzie jednocześnie pierwszym kontem w systemie i będzie pełniła również funkcję naszego adresu e-mail. Po wpisaniu nazwy i ewentualnym zapisaniu się na newslettery dla Administratorów klikamy przycisk Akceptuję. Kontynuuj konfigurację. W tym momencie jesteśmy przerzucani na stronę główną naszego panelu.

Weryfikacja

Póki co nic nie jeszcze działa. Musimy skonfigurować naszą domenę do współpracy z Google Apps i zweryfikować jej posiadanie. W tym celu klikamy link Zweryfikuj posiadanie domeny widniejący tuż pod głównym paskiem nawigacyjnym w górnej części strony. Na kolejnej stronie z listy rozwijanej wybieramy Zmień rekord CNAME. Teraz należy udowodnić Google, że dodana właśnie do systemu domena należy do nas. W tym celu logujemy się na swoje konto w MyDomain, tworzymy nową subdomenę googleffffffff81a33ddf i ustawiamy jej rekord CNAME na google.com (bez żadnych www z przodu :)). Wracamy do panelu Google Apps i klikamy przycisk Weryfikuj. Zostaniemy przerzuceni na stronę główną i zobaczymy komunikat Sprawdzamy posiadanie domeny. Może to potrwać 48 godzin. Pozostaje czekać. Kiedy za dwa dni z panelu zniknie żółty, ostrzegawczy trójkącik będzie to oznaczało, że domena już działa. W miedzyczasie możemy zacząć uruchamiać poszczególne usługi.

Tip: O tym jak zarządzać domeną w MyDomain pisałem tutaj w części Wstępna konfiguracja.

Aktywujemy pocztę Gmail

Na stronie głównej panelu odszukujemy blok E-mail i klikamy pod nim Uaktywnij e-mail. Na kolejnej stronie wyświetlone zostaną instrukcje. Logujemy się na konto MyDomain i przechodzimy do zarządzania domeną. W części Email Forwarding wyłączamy aliasy pocztowe zaznaczając pole Disable forwarding (jeśli tego nie zrobimy serwer MyDomain będzie nadal przechwytywał pocztę i nic nie dotrze do Google). Klikamy Update, a potem Continue. W części DNS Management usuwamy wszystkie wpisy MX (jeśli takowe istnieją) i dodajemy nowe według tabeli na stronie Google. Każdy wpis zatwierdzamy przyciskiem Update.

Tip: Przy wpisywaniu (tudzież kopiowaniu) nazw serwerów Google należy bezwzględnie pamiętać o kropkach NA KOŃCU nazwy. Jest to bardzo ważne.

Po dopisaniu wszystkich rekordów wracamy na stronę panelu Google i klikamy przycisk Kroki te zostały wykonane. Zostajemy przeniesieni na stronę główną, gdzie teraz w sekcji E-mail widzimy informację Aktualizowanie.... Po około dwóch dniach poczta powinna zacząć już nomalnie funkcjonować.

Jedną z ciekawszych opcji dostępnych dla administratorów Google Apps jest możliwość uruchomienia serwera Google Talk z loginami (identyfikatorami) we własnej domenie. Gmailowy Google Talk działa w oparciu o standardowy protokół Jabbera (XMPP). Z komunikatorem w ramach Google Apps nie jest już tak różowo. Komunikacja przy użyciu własnego loginu ograniczona jest tylko do sieci Google. Nie dogadamy się więc np. z użytkownikami serwera @jabber.org. Jest jednak sposób, aby to naprawić i łączyć się bez problemów z osobami korzystającymi z innych serwerów. W kolejnym artykule pokażę właśnie jak tego dokonać.

Reaktywowałem ankietkę po lewej. Zapraszam do głosowania.

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

poniedziałek, 12 maja 2008

Nóż w plecy ;) - godzimy PHP z MS SQL

Nie wiem co Wy o tym sądzicie, ale dla mnie jakoś tak PHP i MS SQL nie pasują do siebie ;p No nie wiem, nie wiem. Może to przez moją delikatną niechęć do Microsoftu? Może. A może coś w tym jest, bo jakby nie patrzeć pehapca faktycznie nie tak łatwo namówić do współpracy z bazami MS. I vice versa. Niby ma PHP te biblioteki do pogaduch z SQL Serverem, a jednak trzeba im pomóc się dogadać.

Na zajęciach w WSB, ponad miesiąc temu, gdy zaczynaliśmy kombinować w PHP z bazą danych (SQL Serverem 2005 właśnie) nadarzyła się okazja do połączenia obu technologii. Szczęśliwie nasz wykładowca już kiedyś bawił się w te klocki i teraz przekazał nam swoją tajemną wiedzę :) Wszyscy zassali EasyPHP i ruszyliśmy do boju. Więc, jak to było?

Konfiguracja PHP pod Windows XP

Najpierw musimy dobrać się do pliku php.ini. W tym celu przy uruchomionym serwerze, w okolicach zegara odszukujemy ikonę EasyPHP. Klikamy na niej prawym przyciskiem myszy, wybieramy Configuration, a następnie PHP.


Plik konfiguracyjny otwiera się w nowym oknie Notatnika. Odszukujemy linię:

;extension=php_mssql.dll

i usuwamy z jej początku średnik. Na koniec oczywiście musimy zapisać zmiany oraz uruchomić ponownie Apache'a (prawoklik na ikonie w trayu i Restart lub Stop, a po chwili Start :)). Po tym PHP powinno być gotowe do współpracy.

Konfiguracja PHP pod Fedorą 7

Pod Fedorą sprawa wygląda zgoła inaczej. Tutaj nie wystarczy odkomentować linii w pliku konfiguracyjnym, a trzeba wzbogacić system o niezbędne pakiety - FreeTDS oraz php-mssql. Na szczęście tak się składa, że roboty nie ma wiele. Logujemy się na roota i z pomocą starego dobrego yuma instalujemy co konieczne:

yum install freetds php-mssql

Po zakończonej instalce upewniamy się, że nowe rozszerzenie zostało pomyślnie dodane do PHP. Wklepujemy w konsoli:

ls -la /usr/lib/php/modules/

i szukamy na liście mssql.so. Jeśli go tam brakuje to mamy problem, ale jeśli się pojawiło to znaczy, że PHP jest gotowe i można ponownie uruchomić Apache'a :)

Konfiguracja SQL Servera 2005

Teraz czeka nas trochę klikania - jak to na Windowsie ;p Uruchamiamy SQL Server Surface Area Configuration i klikamy Surface Area Configuration for Services and Connections. W nowym oknie rozwijamy drzewko po lewej i zaznaczamy Remote Connections. Teraz po prawej zaznaczamy Local and remote connections, poniżej upewniamy się, że aktywna jest opcja pierwsza (Using TCP/IP only) lub ewentualnie trzecia i zatwierdzamy zmiany przyciskiem OK. Zostaniemy poinformowani o konieczności ponownego uruchomienia serwera w celu wprowadzenia zmian. Oczywiście dajemy OK, ale jeszcze nie restartujemy niczego.

Zamykamy wszystkie okienka, odpalamy SQL Server Management Studio i logujemy się. W oknie Object Explorer klikamy prawym przyciskiem myszy główną gałąź (tak, to ta z nazwą naszego hosta ;>), a następnie z menu kontekstowego wybieramy Properties. Otwiera się okno ustawień. Po lewej na liście Select a page zaznaczamy Security. Po prawej stronie widnieją teraz w czterech grupach ustawienia zabezpieczeń. W grupie Server authentication wybieramy SQL Server and Windows Authentication mode. Zatwierdzamy przez OK. Kolejny raz pojawi się komunikat dotyczący konieczności restartu. Wbijamy OK i lecimy dalej.

Wracamy do naszego drzewka. Rozwijamy teraz gałąź Security i klikamy prawym przyciskiem myszy na Logins. Z menu kontekstowego wybieramy New Login.... Przechodzimy do utworzenia nowego użytkownika dla PHP. Z sekcji Select a page wybieramy General. Po prawej podajemy nazwę usera, zaznaczamy opcję SQL Server authentication, ustalamy oraz potwierdzamy hasło dostępu i usuwamy zaznaczenie z checkboksa przy Enforce password policy. Przechodzimy do Server Roles (lewe menu). Na liście dostępnych ról zaznaczamy sysadmin i zatwierdzamy wszystko przez OK. Oczywiście można utworzyć i przypisać PHP osobną rolę, choćby ze względów bezpieczeństwa, jednak do zastosowań domowych przedstawiona konfiguracja powinna w zupełności wystarczyć.

Na koniec, wieńcząc nasze karkołomne zmagania z konfiguracją SQL Servera, uroczyście dokonujemy jego ponownego uruchomienia (eee... zrymowało się? ;p). Powtórnie popełniając prawoklik na najwyższej gałęzi drzewa Object Explorera wybieramy tym razem opcję Restart. Serwer zapyta jeszcze tylko czy aby na pewno chcemy mu to uczynić, na co odpowiemy soczystym Yessss.

I tak nie może być idealnie ;)

Mimo, że da się już w miarę normalnie korzystać z baz SQL Servera, PHP zwraca czasami podejrzane komunikaty typu:

Unicode data in Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier

Dotyczą one problemów z kodowaniem znaków w Unicode i najczęściej pojawiają się podczas wykonywania selectów z pól typu ntext w tradycyjny sposób:

mssql_connect('.', 'user', 'pass');
mssql_select_db('Northwind');

$q = mssql_query('select CategoryID, CategoryName, Description
from Categories');

while ($r = mssql_fetch_assoc($q)) {
echo $r['CategoryID'] . '. <strong>' . $r['CategoryName'] . '</strong> <em>' . $r['Description'] . '</em><br />';
}

mssql_close();

Rozwiązaniem może być tu np. wykorzystanie klasy COM zaproponowane w jednej z notek do manuala PHP:

$db = new COM('ADODB.Connection');
$dsn = 'DRIVER={SQL Server}; SERVER={localhost}; UID={user}; PWD={pass}; DATABASE={Northwind}';
$db->Open($dsn);
$rs = $db->Execute('select CategoryID, CategoryName, Description
from Categories');

while (!$rs->EOF) {
echo $rs->Fields['CategoryID'] . '. <strong>' . $rs->Fields['CategoryName'] . '</strong> <em>' . $rs->Fields['Description'] . '</em><br />';
$rs->MoveNext();
}


W kolejnym poście, jak wspomniałem ostatnio, wrócimy do grzebania przy domenach i zbratamy nasz adresik z wielkim Google oraz jego aplikacjami webowymi. Roboty z tym nie ma za wiele, jednak czasu też brak i pewnie nie uda mi się opublikować tekstu tak szybko jak teraz. Postaram się jednak żeby przerwa nie trwała zbyt długo. Pozdrawiam serdecznie i przypominam o ankiecie z lewej :)

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

niedziela, 11 maja 2008

100% z domeny - #1 rejestracja i parking

Witam po... ekhmm, krótkiej przerwie i zapraszam na ostatnio zapowiedziany pierwszy artykuł z cyklu poświęconego domenom. Chciałbym żeby tekst wyszedł krótki, treściwy i lekki, ale pewnie będzie jak zwykle :/ Dobra, więc do roboty.

To nie jest blog klasy żłobek administratora, więc daruję sobie tłumaczenie tak fundamentalnych podstaw jak "co to jest domena?" :) Na temat zalet posiadania własnej domeny również nie będę się zanadto rozwijał - tym z Was, którzy ich nie dostrzegają na pewno wzrok się poprawi o ile tylko dobrną do ostatniego odcinka mojego wywodu. Może nie przedstawię tu wszystkich plusów, bo pewnie sam ich wszystkich jeszcze nie znam, ale zgodnie z tytułem cyklu na pewno poznacie kilka nowych sposobów na wykorzystanie swoich domenek.

Dawno minęły już czasy, gdy posiadanie domeny było atrybutem tylko wielkich korporacji i portali internetowych. Teraz są tak tanie (no, może nie wszystkie), że mogliby je w Biedronce sprzedawać i to w sześciopakach ;p Pamiętam, jak jeszcze kilka lat temu, gdy dopiero wczołgiwałem się w tę branżę, popularne były wszelkiej maści subdomeny, aliasiki, czym krótsze tym lepsze. Pamiętam, bo sam z nich aktywnie korzystałem :) To były czasy, ehh... A teraz? Teraz byle leszcz może kupić własnego coma czy peelkę. I nie jest to wcale zasługa wyższego kieszonkowego. Codziennie widzę, jak grzyby po deszczu wyrastają nowe sajty, które po roku tracą swój szpanerski adres, bo admin regulaminu nie doczytał. Ahh! Teraz już wiem skąd ten milion ^_^ No ale dobra, wystarczy bajeczek. Przejdźmy do konkretów.

To od czego zacząć? Od rejestracji oczywiście. Obiecałem pokazać jak wyrwać tani adresik, więc ze względów oczywistych pod nóż pójdą domeny globalne - nie polskie, które wciąż kosztują więcej aniżeli powinny. I nie mam tu na myśli pierwszego okresu abonamentowego w promocyjnej cenie, na którą... niektórzy się nabierają :> Na zakupy wybierzemy się za ocean, do prawdopodobnie największego na świecie akredytowanego przez ICANN rejestratora domen globalnych - GoDaddy.


Od razu muszę zaznaczyć, że aby dokonać płatności za usługi GoDaddy powinniście się zaopatrzyć albo w kartę kredytową (lub też wirtualną kartę kredytową do płatności internetowych oferowaną m.in. przez Inteligo, mBank czy Lukas Bank) albo w konto PayPal, oczywiście doładowane, do czego i tak potrzebna będzie karta ;p Jak więc widać, nie ma mocnych i plastik to tutaj konieczność.

Tip: Rekomendowanym sposobem płatności jest PayPal - numer naszej karty przekazujemy tylko jednej firmie i w razie opróżnienia konta wiadomo od razu kogo pozwać ;) Nie oznacza to jednak, że GoDaddy nie jest godzien zaufania.

Rejestracja

Zacznijmy od założenia nowego konta. Na stronie głównej znajduje formularz logowania, a pod nim link Create a New Account, klikamy. Wypełniamy wszystkie pola, np według wzoru (w pole Call-in PIN wpisujemy dowolne 4 cyfry, prawdopodobnie ta opcja nigdy się nie przyda; adres e-mail podajemy prawdziwy, GoDaddy nie rozsyła niezamówionej poczty - patrz sekcja Stay Informed! - a jedynie informacje na temat naszych zamówień) i klikamy button CREATE A NEW ACCOUNT. Jeśli wszystko poszło dobrze, zostajemy automatycznie zalogowani. Na stronie głównej, w specjalnym polu wpisujemy nazwę pożądanej domeny, z długiej listy rozwijanej wybieramy interesujące nas rozszerzenie i klikamy GO!. Jeśli wybrana domena okaże się wolna ujrzymy stosowny komunikat oraz jej aktualną cenę. GoDaddy często organizuje promocje, w których różne domeny można nabyć praktycznie za grosze, mimo że zwykle i tak są bardzo tanie. Klikamy Proceed to Checkout. O ile dostępne są jeszcze inne rozszerzenia dla naszej domeny GoDaddy nie omieszka nas o tym poinformować na kolejnej stronie. Zakładam, że na razie nie jesteśmy zainteresowani, więc klikamy Continue to checkout.... Docieramy wreszcie do strony, na której wybieramy okres na jaki chcemy zarejestrować naszą domenę (Registration Length), czy domena ma być automatycznie odnawiana przed wygaśnięciem (Auto-Renew Protection - Manual jeśli nie chcemy, aby GD sam pobierał sobie kasę z naszego konta), czy chcemy do niej dodatkowo płatny certyfikat poświadczający własność (Certified Domain) oraz możemy od razu ustawić własne rekordy NS, by wydelegować domenę na serwery, na których będziemy nią zarządzać. Oczywiście możemy pozostawić tutaj domyślne serwery GD, które również umożliwią nam zaawansowaną obsługę domeny, jednak proponuję ustawić własne. Dzięki temu wydelegujemy naszą domenę do serwerów MyDomain, o których opowiem nieco później. Klikamy więc link click here to set nameservers i na kolejnej stronie wypełniamy odsłonięte pola tak jak na załączonym obrazku.

ns1.mydomain.com
ns2.mydomain.com
ns3.mydomain.com
ns4.mydomain.com

Przewijamy stronę do dołu, zaznaczamy No thanks. I'm ready to checkout i klikamy przycisk CONTINUE.

Trafiamy ostatecznie do kasy. Tutaj warto sprawdzić czy wszystko zgadza się z naszymi ustawieniami. Można, a nawet trzeba również wprowadzić specjalny kod promocyjny, dzięki któremu dodatkowo obniżymy cenę domeny. Skąd wziąć kod? Z pomocą przychodzi Google i magiczne zapytanie :) Można wykorzystać pierwszy lepszy, atrakcyjnie wyglądający kodzik (np. OYH1), ale czasem warto chwilę pomyśleć czy jakiś inny obniżający cenę konkretnego rozszerzenia do określonego poziomu nie da nam więcej. Finalnie wybrany kod wpisujemy w pole If you have a promo or source code enter it here oraz zatwierdzamy klikając button Apply Code. Po przeładowniu strony od razu widać o ile obniżyła się należność. Teraz pora na jej uregulowanie. W punkcie Select Your Payment Method zaznaczamy PayPal, poniżej w punkcie trzecim oba checkboksy i klikamy Checkout Now. Zostajemy przeniesieni na stronę PayPal, gdzie po prawej stronie logujemy się na swoje konto. O ile dobrze pamiętam (nie mam ilustracji), po zalogowaniu zostaniemy poproszeni jeszcze o potwierdzenie dodania GoDaddy do listy zaufanych kontrahentów. Na koniec wracamy do strony GD, gdzie weryfikujemy swoje dane do billingu i ponownie klikamy Checkout Now. Z naszego konta PayPal ściągana jest należność i zostaje wyświetlony komunikat potwierdzający pomyślne zakończenie operacji. Klikamy Back to My Account i wracamy na stronę główną swojego konta. To tyle jeśli chodzi o rejestrację.

Teraz słówko na temat panelu zarządzania domenami w GoDaddy. W lewym menu odszukujemy sekcję My Products, a pod nią link Manage Domains. Klikamy. Po chwili widzimy listę posiadanych domen, zaś nad nią szereg opcji. Zaznaczamy checkbox przy naszej domenie, a następnie klikamy opcję Contact. Naszym oczom ukazuje się kilka zakładek z formularzami umożliwiającymi zmianę danych wyświetlanych w bazie WHOIS. Aby nie bawić się w żmudne wypełnianie każdego z nich, zaznaczamy opcję Update all contact types with this contact information :) To oszczędzi sporo pracy. Po zmianie danych klikamy OK, a w panelu pokazuje się komunikat o konieczności odczekania chwili zanim zmiany zostaną wprowadzone. W taki sam sposób zmienia się adresy nameserwerów, przedłuża okres abonamentowy czy przenosi domenę do innego konta w GD.

W międzyczasie GoDaddy wysyła do nas kilka maili: potwierdzenie zamówienia, potwierdzenie rejestracji i informację o zmianie danych WHOIS. No właśnie. Poza niskimi cenami GD ma jeszcze jednego wielkiego plusa - rejestracja jest natychmiastowa, a nowe domenki właściwie już po kilku godzinach są widoczne globalnie. Sugeruję dokonywanie rejestracji wieczorem. W nocy DNSy polskich providerów się odświeżą i kiedy rano wstaniecie wszystko będzie już działało :) A wracając do powiadomień, otrzymujemy również list od PayPal z potwierdzeniem zapłaty. W tym miejscu kończy się proces rejestracji. Może opis zajmuje trochę miejsca, jednak to tylko przez jego poziom szczegółowości - krok po kroku. W rzeczywistości wszystko trwa mniej niż kwadrans.

Parking

Czas na podpięcie domeny do nowych nameserwerów i wstępną konfigurację rekordów DNS. Naszą domenę w czasie rejestracji wydelegowaliśmy na zewnętrzne serwery firmy MyDomain. Teraz musimy jeszcze ją tam zaparkować. W tym celu przechodzimy na stronę MyDomain i celem założenia nowego, bezpłatnego konta klikamy banner z napisem Open an account today. Naszym oczom ukazuje się wielki, paskudny formularz rejestracyjny ;p Nie ma się jednak co zrażać, gdyż naprawdę warto mieć tutaj konto. Wypełniamy wszystkie pola, zaznaczamy na dole checkbox i klikamy Create an Account (należy pamiętać o podaniu poprawnych danych; jeśli wprowadzone dane okażą się nieprawidłowe, nasze konto zostanie usunięte, a wraz z nim wszystkie zaparkowane domeny - tego chyba nie chcemy?). Zostaje utworzone nasze konto i lądujemy w swoim panelu zarządzania. Odszukujemy wytłuszczone zdanie To manage domains not registered with us i klikamy w znajdujący się tuż obok link click here. Na kolejnej stronie klikamy button Add Domains. Następnie w polu tekstowym wpisujemy nazwy domen, które chcemy dodać do swojego konta (jedna na linię). Wszystkie domeny powinny mieć wcześniej ustawione rekordy DNS zgodne z serwerami MyDomain. Klikamy Add. Domeny zostają dopisane do DNSów MD. Klikamy link Add Services, aby aktywować pakiet narzędzi do obsługi domeny. Na kolejnej stronie klikamy CHECK OUT, a następnie zaznaczamy pole Registration Agreement po lewej stronie i ponownie klikamy przycisk COMPLETE ORDER. Nasze zamówienie jest przetwarzane. Może dziwnie to wygląda, bo przy zamówieniu pisze, że pakiet narzędzi jest wykupywany na rok, ale w rzeczywistości jest on ważny w całym okresie obsługi danej domeny przez serwis MyDomain. Wszystko to oczywiście bezpłatnie. Po przetworzeniu zamówienia otrzymujemy indywidualny jego numer, który raczej do niczego się nam nie przyda. Klikamy CONTINUE. Widzimy podsumowanie zakupów, klikamy Goto My Account. Znowu trafiamy na stronę główną naszego panelu. Tak jak poprzednio klikamy link click here, a następnie Refresh Display, aby zobaczyć świeżo dodaną do konta domenę. W międzyczasie otrzymujemy maile z potwierdzeniem dodania domeny oraz zamówienia pakietu narzędzi do jej obsługi. Domena została zaparkowana.

Wstępna konfiguracja

Pozostając na stronie zawierającej wykaz naszych domen, klikamy link Forwarding/DNS Management obok domeny do skonfigurowania. Przenosimy się na stronę konfiguracji domeny. Jest ona podzielona na kilka sekcji. U samej góry wyświetlany jest stan rekordów NS. MyDomain okresowo sprawdza czy rekordy te wskazują prawidłowe serwery nazw. Niżej widzimy ramkę URL Forwarding. Tutaj możemy ustawić na jaki adres mają zostać przekierowane wszystkie wywołania naszej domeny jeżeli chcemy by działała tylko jako zwykły alias. Nam się ta opcja jednak nie przyda, dlatego zaznaczamy checkbox Disable Forwarding i klikamy przycisk Update. Widzimy komunikat o pomyślnej zmianie ustawień, klikamy Continue.

Po powrocie na stronę konfiguracji przechodzimy do ustawień Email Forwarding. To akurat bardzo fajna opcja dla osób, które chciałyby mieć aliasy pocztowe we własnej domenie, ale nie posiadają konta hostingowego. Tutaj możemy ustawić sobie na sztywno wszystkie aliasy lub od razu aktywować funkcję catch-all, która przekaże całą pocztę dla domeny na jeden wskazany adres. Należy pamiętać, że każdą zmianę na liście adresów potwierdzamy przez kliknięcie buttona Update.

Zdecydowanie najważniejszą częścią strony konfiguracyjnej jest jednak ramka DNS Management. To właśnie tutaj możemy bawić się rekordami DNS naszej domeny. Na razie zajmiemy się tylko jednym rodzajem rekordów - typu A - zaś inne omówię przy okazji kolejnych odcinków. Rekord typu A pozwala nam na przypisanie domeny do konkretnego adresu IP (tylko i wyłącznie IP). Dzięki niemu możemy np. na MyDomain zarządzać pocztą, a ruch WWW przekazywać dalej do innego serwera. I tak właśnie teraz zrobimy. Najpierw trzeba wydobyć adres IP naszego serwera WWW. Jeśli posiadamy konto z dedykowanym IP (np. konto w nazwa.pl) to używamy właśnie tego adresu. Natomiast jeżeli nasze konto współdzieli IP z innymi użytkownikami na serwerze, będziemy musieli trochę pokombinować. Najprościej jest jeśli nasze konto WWW obsługujemy przez cPanel. Domyślnie wyświetla on na stronie głównej Shared Ip Address (lub po prostu IP), z którego korzystamy. Kopiujemy ten adres i wklejamy na MyDomain do pola IP Address rekordu A. Klikamy Update. Rekord zostaje ustawiony.

Teraz tylko trzeba w panelu konta WWW podpiąć domenę. Pokażę to znowu na przykładzie cPanelu. Na stronie głównej wybieramy ikonę Parked Domains (można też wybrać Addon Domains jeśli chcemy podpiąć domenę pod konkretny katalog na serwerze). W polu New Domain Name wpisujemy nazwę naszej domeny i klikamy Add Domain!. Domena zostaje zaparkowana i od tej pory prowadzi do naszego konta WWW :)

Tip: Jeżeli chcesz otrzymywać pocztę ze swojej domeny na skrzynki skonfigurowane w panelu konta hostingowego, musisz na stronie konfiguracji MyDomain w sekcji Email Forwarding wyłączyć aliasy pocztowe (zaznaczyć pole Disable forwarding i zatwierdzić przyciskiem Update)! W przeciwnym wypadku MyDomain będzie przechwytywało całą pocztę i nie dotrze ona do Twojego serwera. To samo tyczy się opcji URL Forwarding. Powinna ona zostać wyłączona jeśli ustawione są rekordy A, CNAME lub NS.

Na stronie konfiguracji MyDomain dostępne są jeszcze dwie opcje: New Subdomain oraz Wildcard DNS Records. Pierwsza z nich umożliwia dodanie subdomeny, a następnie zarządzanie nią w taki sam sposób jak domeną główną. Druga zaś ustala w jaki sposób traktować wywołania nieistniejących subdomen. O tym jednak powiemy sobie kiedy indziej ;)

Kolejny artykuł poświęcę problemowi współpracy PHP z... ekhmm, MS SQL Server 2005, a po tym zapraszam na drugi odcinek cyklu 100% z domeny. Zintegrujemy w nim nasz adresik z usługami Google Apps. W najbliższym czasie chciałbym też może przeprowadzić jakiś mały kursik, więc zapraszam do głosowania w ankiecie na tematykę takowego. Dajcie znać co Was interesuje :)

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

czwartek, 28 lutego 2008

Lepsza baza - instalujemy serwer PostgreSQL

Dzisiaj krótka piłka - mam nadzieję :) Chyba najczęściej spotykanym systemem baz danych występującym w sieci w kwartecie z Linuksem, Apaczem i PHP jest MySQL. Nie jest to jednak jedyny i - jak się również okazuje - dla każdego najlepszy system. Takie jest przynajmniej moje zdanie :P Ja przykładowo szukałem jakiś czas temu alternatywy dla mojego sql'a, pozwalającej na komercyjne wykorzystanie w swoim projekcie. Nie będę się tutaj rozmieniał na drobne, ponieważ różne osoby różnie widzą możliwość komercyjnego użycia baz MySQL, a nie to jest tematem posta. Postanowiłem wykorzystać system baz danych PostgreSQL, który ze względu na swoją absolutną wolność i brak podziałów dostępnych licencji na różnego typu zastosowania, nie zmusza mnie do myślenia czy mogę na jego użyciu zarabiać czy nie. Postgres ma jeszcze jedną poważną zaletę - jest dostępny prawie wszędzie tam gdzie MySQL. Jest tak dzięki jego integracji z cPanelem, którego stosuje obecnie wiele firm hostingowych, zarówno tych oferujących swoje usługi odpłatnie jak i tych darmowych.


Niestety prawda jest taka, że niebieski słonik często zostaje przez użytkowników pomijany i przegrywa w starciu z delfinkiem ;P Nie ma się jednak co dziwić - większość oskryptowania dostępnego na rynku jest pisana pod MySQL'a, a instalując takie wyjątki jak popularne phpBB czy WikiMedia obsługujące również bez problemu Postgresa i tak odruchowo wybierany jest produkt Sunowski. Nie ma jednak co płakać - być może nadejdą lepsze dni dla PgSQL'a. Tymczasem zakończę swój wywód i przejdę szybko do sedna sprawy, dla której się tutaj dziś zebraliśmy ;)

Tak jak wspomniałem wykorzystanie bazy postgresowej na serwerze z cPanelem nie stanowi większego problemu - ot, klik, klik i nowa baza jest gotowa. Trochę inaczej to wygląda, gdy chcemy sami napisać aplikację korzystającą z systemu spod znaku słonia i musimy ją jakoś przetestować na localu zanim wypuścimy do sieci (no chyba, że stawiamy na całkowity hardcore i testujemy wszystko live: save, ftp, refresh :P Jeśli należysz do takiej grupy webmajstrów, to informuję iż źle trafiłeś). Wówczas koniecznością staje się (zupełnie jak w przypadku MySQL'a) instalacja serwera baz na lokalnym komputerze. Pojawia się tylko jedna mała przeszkoda - PgSQL nie wchodzi w skład XAMPPa, ani żadnego innego znanego Krasnala (przynajmniej ja nic o tym nie wiem) ;o Omgz! W takiej sytuacji pozostaje ręczna instalka. Już za chwilę będziecie wiedzieć jak to uczynić sprawnie i bezstresowo pod Fedorą.

Odpalamy terminal i logujemy się na roota. Instalujemy serwer baz, stosowny moduł dla PHP i phpPgAdmina:

yum install postgresql php-pgsql phpPgAdmin

Tip: Jeśli już wcześniej zainstalowano PHP (np zgodnie z moim tutorialem) i użyto do tego polecenia php\* to php-pgsql i phpPgAdmin powinny być już zainstalowane. Nie zaszkodzi jednak dodać ich do powyższego polecenia - najwyżej yum je sobie pominie.

Po zakończonej instalacji najpierw inicjalizujemy bazę, a następnie odpalamy serwer, logujemy się na użytkownika postgres i włączamy narzędzie psql:

service postgresql initdb
/etc/init.d/postgresql start
su postgres
psql

Tip: Przed logowaniem można sprawdzić w /etc/shadow czy użytkownik taki został utworzony podczas instalacji. Nazwa usera może aczkolwiek nie powinna różnić się od powyższej.

Tworzymy własnego użytkownika (login do bazy) - uwaga: operujemy tutaj zapytaniami sql'owymi, więc pamiętaj o średnikach na końcu linii!

create user sdr;

Ustawiamy hasło i nadajemy wszystkie uprawnienia, dzięki którym użytkownik otrzyma władzę absolutną nad serwerem :) Takie rzeczy to oczywiście tylko na localu - na serwerach dostępnych w sieci należy nadawać użytkownikom tylko takie uprawnienia jakich potrzebują (kwestia bezpieczeństwa). Podając hasło koniecznie umieść je w apostrofach:

alter user sdr password 'sR4tATa7A';
alter user sdr superuser;
alter user sdr createrole;
alter user sdr createdb;
alter user sdr createuser;

Na koniec tworzymy naszemu userowi domyślną bazę danych, do której będzie automatycznie logowany po uruchomieniu psql'a.

create database sdr owner sdr;

Wychodzimy z psql'a i wylogowujemy się z konta postgres:

\q
exit

Teraz czas na zmianę ustawień logowania. Jeśli pominiemy ten krok, mogą pojawić się problemy z logowaniem np do phpPgAdmina. Edytujemy stosowny plik konfiguracyjny serwera:

vim /var/lib/pgsql/data/pg_hba.conf

Tip: Przed wprowadzeniem zmian w pliku warto wykonać jego kopię zapasową.

Na końcu pliku znajduje się taka oto niby tabelka:

# TYPE  DATABASE    USER    CIDR-ADDRESS   METHOD

# "local" is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 ident sameuser
# IPv6 local connections:
host all all ::1/128 ident sameuser

Aby wszystko grało jak należy, musimy zmienić zawartość ostatniej kolumny (METHOD) z ident sameuser na md5. Podmieniamy wartości we wszystkich trzech wierszach, otrzymując:

# TYPE  DATABASE    USER    CIDR-ADDRESS   METHOD

# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

Zapisujemy wszystkie zmiany z pliku i restartujemy serwer.

/etc/init.d/postgresql restart

Teraz można zalogować się do phpPgAdmina.

Na zakończenie dzisiejszego artykułu wspomnę jeszcze tylko o jednej (istotnej m.in. dla użytkowników MediaWiki) sprawie związanej z instalacją różnego rodzaju oskryptowania wykorzystującego bazy PostgreSQL. Czasami może występować błąd w instalacji i skrypt może wypluć dziwny dla niektórych błąd związany z tsearch2 (skrypt wymaga zaimplementowanej funkcjonalności pełnego indeksowania tekstu). Ja takowy problem napotkałem w czasie instalacji właśnie MediaWiki na localu. Należy wówczas odpalić terminal, przejść do katalogu /usr/share/pgsql/contrib i upewnić się czy istnieje tam plik tsearch2.sql (jeśli nie, trzeba dociągnąć yumem pakiet postgres-[wersja]-contrib - gdzie [wersja] to oczywiście nasza wersja Postgresa). Następnie logujemy się na swojego usera i ładujemy wspomniany plik do bazy, w której chcemy zainstalować MediaWiki:

psql [nazwa_bazy_dla_wiki] < tsearch2.sql

Psql poprosi nas o hasło. Wpisujemy je i ponawiamy próbę instalacji.

Kolejne kilka postów poświęcę na zabawy z domenami. Następnym razem zobaczymy jak tanio zarejestrować nową domenę i gdzie ją wydelegować, aby... wykorzystać do granic możliwości. Czekajcie cierpliwie ;D

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

czwartek, 7 lutego 2008

Lepszy Apache - wprowadzamy małe zmiany w httpd.conf - #2 vHosty

Witam w drugiej części mojego małego tutorialu dotyczącego modyfikacji httpd.conf :) Trochę wody w rzece upłynęło od ostatniego artykułu, ale wiadomo co było tego powodem: standardowo brak czasu, zajęcia o wyższym priorytecie, odrobinka lenistwa, no i oczywiście sesja ;p Ale do rzeczy. Poprzednio pisałem o tym jak wpuścić Apache'a do katalogów userów przy pomocy userdir_module. Dzisiaj część druga mojego wywodu.

Czymże są wirtualne hosty (vhost)? Tak najprościej mówiąc, vhosty dają nam możliwość utrzymywania na jednej maszynie wielu niezależnych domen. Na nich opiera się praktycznie cały hosting tego świata - wirtualny oczywiście. Dzięki nim Onet i Nasza-klasa mogą stać na jednym serwerze ;) Pokrótce - na czym to wszystko polega? Idea jest prosta: parkujemy domenę na serwerze i podpinamy ją pod swój public_html, uzyskując tym samym dostęp do niego za pomocą fajnego www.mojsexiadresik.pl, a nie paskudnego www.okropnyadresmojegoprovidera.com.pl/~mojasexistronka/ ;p Kwestię parkowania domeny sobie tutaj pominiemy i zajmiemy się tylko podpięciem jej pod wybrany katalog. No dobra, ale ktoś zapyta jak podpiąć domenę, której nie ma? Słuszna uwaga. Cały problem ominiemy poprzez wykorzystanie fikcyjnej domeny i wymuszenia na Fedorze przekierowania jej na localhost. Już mówię jak to zrobić, sprawa jest na prawdę banalna.

Po pierwsze - trzeba włączyć na Apache'u mod UserDir (tutorial). Będę opisywał wszystko na przykładowej, utworzonej w ostatnim artykule stronie http://localhost/~sdr/, więc kto nie czytał powinien nadrobić zaległości (a arty miały być niezależne od siebie ;D).

Jeżeli wszystko działa jak należy i po wpisaniu w przeglądarce powyższego adresu naszym oczom ukazuje się wielkie Hello world!, możemy przystąpić do edycji pliku konfiguracyjnego. Logujemy się na roota i otwieramy plik.

vim /etc/httpd/conf/httpd.conf

Około linii 180 odszukujemy coś co nazywa się

LoadModule vhost_alias_module modules/mod_vhost_alias.so

Linia nie powinna być zahaszowana, ale jeśli jest inaczej, usuwamy sprzed niej znak #. Następnie przechodzimy w okolice linii 954, gdzie rozpoczyna się sekcja konfiguracji vhostów. Kilka linii niżej zobaczyć można pierwszy z dwóch interesujących nas tutaj fragmentów.

# Use name-based virtual hosting.

Bezpośrednio pod nim umieszczamy dodatkową linijkę.

NameVirtualHost 127.0.0.2:80

Należy zwrócić szczególną uwagę na podany IP pętli zwrotnej (localhosta). Nie wpisujemy 127.0.0.1 (jak to standardowo czynimy w celu uzyskania dostępu do bieżącego komputera), ale 127.0.0.2 - to ważne. Jeszcze nie wiem dlaczego, ale kiedy wpisywałem u siebie jedynkę, miałem potem różne śmieszne problemy.

Tip: Od razu zaznaczę, że dla każdego kolejnego vhosta przyporządkowuje się następny numerek w ostatnim oktecie adresu. Ważne, aby wszytkie vhosty były kierowane na inne adresy (127.0.0.2, 127.0.0.3, itd). Konieczne jest też dodanie po adresie numeru portu. Zawsze wpisujemy domyślny 80. Kolejne adresy można dopisywać jeden pod drugim.

Teraz przechodzimy jeszcze niżej. Zapewne w oczy rzuca się Wam przykładowy blok konfiguracyjny vhosta.

#<VirtualHost *:80>
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>

Do takiego bloku jak widać można wpisać trochę różnych dyrektyw. Nam jednak na własne potrzeby wystarczą tylko te najważniejsze.

<VirtualHost 127.0.0.2:80>
ServerAdmin webmaster@sdr.lh
DocumentRoot /home/sdr/public_html
ServerName sdr.lh
ServerAlias *.sdr.lh
</VirtualHost>

ServerAdmin to adres e-mail admina serwera. W sumie można tu wpisać taki adres jaki tylko chcemy. Będzie on wyświetlany np na stronach błędów serwera.
DocumentRoot definiuje ścieżkę dostępu do katalogu, pod który chcemy podpiąć naszą domenkę.
ServerName - tutaj podajemy nazwę podpinanej domeny (bez żadnych gadżetów typu www czy http:// oczywiście ;]). Również tutaj wpisać możemy co nam się tylko spodoba, nawet bardzolubie.mojastronke ;p Możemy, bo tak jak wcześniej zaznaczyłem będziemy używać tego jedynie dla siebie. Jednak, aby nie przeginać zbytnio, wykorzystujemy tradycyjną domenę najwyższego poziomu (TLD), 2-literową. Najlepiej skorzystać z nieistniejącej domeny, ale o tym później. Ja wykorzystuję .lh - skrót od localhost.
ServerAlias to bardzo fajna opcja, która stosunkowo często przydaje się w prawdziwej sieci. Pełni ona rolę drugiej nazwy, ale częściej chyba jest wykorzystywana do uaktywniania tzw. wildcarda (krótko mówiąc, nakazuje serwerowi wychwytywać wszystkie nieistniejące subdomeny i przekierowywać żądania do domeny głównej - coś Wam to mówi? Taaak, aliasy www ;D).
ErrorLog i CustomLog służą odpowiednio do logowania w plikach dziennika błędów i każdej próby dostępu do jakiegokolwiek pliku na serwerze. Te dyrektywy pozwalają nam ustalić miejsce, w którym wszystko będzie się zapisywało.

Zapisujemy zmiany w pliku httpd.conf i restartujemy serwer. Gdy Apache wróci do siebie, otwieramy do edycji drugi plik.

vim /etc/hosts

To ważny plik systemowy, w którym zapisywane są na sztywno nazwy hosta i przypisane im adresy IP. Domyślnie znajduje się tam tylko jeden host - właśnie pętla zwrotna - gdyż cała reszta świata jest odsługiwana dynamicznie poprzez serwery DNS, tak? Plik powinien zawierać mniej więcej coś takiego:

# Do not remove the following line, or various programs
# that require network functionality will fail.
::1 localhost.localdomain localhost

Tip: Na samej górze zawarte jest bardzo istotne ostrzeżenie odnośnie usuwania umieszczonej w pliku domyślnej linii. Naprawdę, nie polecam. Możecie się zdziwić jak wiele od niej zależy :)

W każdym bądź razie, pierwsza linia za bardzo nas nie intersuje. My dopisujemy się pod spodem.
127.0.0.2 sdr.lh www.sdr.lh blog.sdr.lh


Każdy taki wpis (linia) jest zbudowany zasadniczo z trzech kolumn tekstu, oddzielonych od siebie znakami tabulatora. Pierwsza linia to IP, na który zostanie przekierowany ruch. Druga kolumna do nazwa domeny. Trzecia (i każda kolejna po tabulatorze) to alias dla nazwy domeny. Tutaj niestety nie działa gwiazdka (wildcard) i każda subdomena extra, która ma zostać przekierowana musi zostać wpisana na sztywno. Dobrze chociaż, że DNS nie ma takich problemów ;> Kiedy skończysz edycję pliku, zapisz zmiany i zamknij go.

Teraz można wykonać próbę. Wpisz do paska adresu przeglądarki sdr.lh, www.sdr.lh lub blog.sdr.lh. W każdym z przypadków powinieneś zobaczyć stronę Hello world! umieszczoną w swoim katalogu domowym.

Pozostaje jeszcze pytanie, po co vhosty na localu? Ano np po to, żeby móc sprawdzić działanie projektowanej witryny w warunkach rzeczywistych. Jeżeli piszemy CMS dla konkretnej strony dysponującej domeną np sdr.pl, to dużo łatwiej będzie nam się go testowało jeśli będziemy mogli go uruchomić w warunkach podobnych do tych naturalnych, czyli pod adresem sdr.lh zamiast localhost/~sdr/ - nieprawdaż?

No dobra, ale dlaczego nie powinienem używać do testów np domeny .pl? Odpowiedź jest prosta: ponieważ domena, którą sobie wybierzesz, nawet jeśli teraz nie istnieje, kiedyś może zostać zarejestrowana. Wówczas spotka Cię nieprzyjemna niespodzianka - zamiast właściwej strony, zobaczysz swoje Hello world! :) Zresztą możesz to sprawdzić już teraz. Wystarczy, że w pliku /etc/hosts zamiast sdr.lh wpiszesz np onet.pl :> Domena .lh nie istnieje i zapewne już nie powstanie, więc można z niej bezpiecznie korzystać.

Dzisiaj to by było na tyle. W kolejnym artykule, przedstawię instalację baz danych PostgreSQL na Fedorze. Z tym jest trochę trudniej niż z MySQL, ale tylko trochę :) Tymczasem zapraszam do głosowania w nowej ankiecie. Jednocześnie dziękuję za Waszą wiarę w tego bloga, którą potwierdzają wyniki poprzedniej sondy.

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

poniedziałek, 14 stycznia 2008

Lepszy Apache - wprowadzamy małe zmiany w httpd.conf - #1 UserDir

W tytule specjalnie umieściłem słowo małe, bowiem zmiany będą naprawdę kosmetyczne. Pomimo, że zaraz po instalacji Apache jest gotów do pracy, to jednak przydaje się kilka drobnych udogodnień, które sprawią że wszystko będzie śmigało tak jak my chcemy :)

Pierwszym takim udogodnieniem jest z pewnością userdir_module. Co nam daje? Ano sprawia, że każdy użytkownik systemu (mówię tu o Fedorce i innych dystrybucjach) otrzymuje możliwość przechowywania swojej strony we własnym katalogu domowym - np pod adresem http://localhost/~sdr/ widoczne są pliki utrzymywane w /home/sdr/public_html. Jest to bardzo wygodne rozwiązanie, bowiem jeśli administujemy typowym serwerem WWW to pewnie umożliwiamy też zdalny dostęp do konta poprzez protokół FTP. Wówczas bardzo łatwo ograniczyć dostęp użytkownika do katalogów innych niż jego własny home, poprzez zamknięcie go w jailu. Ale to temat na inną okazję :)

Jak konfigurujemy moduł userdir? Najpierw jako root otwieramy do edycji plik konfiguracyjny Apache'a. Robimy to poleceniem:

vim /etc/httpd/conf/httpd.conf

Około linii 185 powinien znajdować się wiersz:

LoadModule userdir_module modules/mod_userdir.so

Upewniamy się, że nie jest on przypadkiem zahaszowany (zakomentowany, tzn. czy na początku linii nie znajduje się znak #). Nie powinien.

Tip: Jeśli jest, naciskamy klawisz i, a następnie ustawiamy się kursorem (strzałki - jakby ktoś nie wiedział :>) za # i usuwamy go klawiszem Backspace (zapamiętać podstawy vima na przyszłość, bo nie będę powtarzał ;D).

W wierszu 337 odnajdujemy zakomentowaną notatkę odnośnie użytkowania modułu. Znajdują się tam wskazówki na temat praw dostępu dla poszczególnych katalogów. Tym zajmiemy się za moment. Kilka wierszy niżej można zauważyć pierwszy wpis konfiguracyjny dla modułu.

UserDir disable

Domyślnie powinien być zakomentowany. Jest tak ze względów bezpieczeństwa, gdyż włączony userdir mod umożliwia odgadnięcie istniejących nazw użytkownika systemu. Nie ma jednak wyjścia, albo wóz albo przewóz ;p Haszujemy linię.

#UserDir disable

Jeszcze niżej, tuż nad </IfModule> znajduje się druga dyrektywa. Ta jest domyślnie zakomentowana.

#UserDir public_html

Mówi ona serwerowi, gdzie ma szukać strony jeśli w przeglądarce wpisany zostanie adres z nazwą użytkownika systemu (np wspomniany http://localhost/~sdr/). Wartość public_html wskazuje na podkatalog public_html w katalogu użytkownika. Tutaj usuwamy znak # z początku linii. Z trybu edycji wychodzimy poprzez naciśnięcie klawisza Esc i wpisanie :wq oraz zatwierdzenie Enterem.

Teraz musimy utworzyć w katalogu domowym użytkownika (np /home/sdr) podkatalog public_html, który wykorzystamy do przechowywania naszej strony. Można od razu umieścić wewnątrz dokument index.html ze standardową zawartością i napisem Hello world ;)

Następnie ustawiamy stosowne prawa dostępu do katalogu, tak aby Apache nie miał problemów z pobraniem i wyświetleniem naszej witryny. Zgodnie z zaleceniami wspomnianej notatki:

# The path to the end user account 'public_html' directory must be
# accessible to the webserver userid. This usually means that ~userid
# must have permissions of 711, ~userid/public_html must have permissions
# of 755, and documents contained therein must be world-readable.
# Otherwise, the client will only receive a "403 Forbidden" message.

Tą sprawę najlepiej załatwić z konsoli. Wydajemy kolejno dwa polecenia:

chmod 711 /home/sdr
chmod 755 /home/sdr/public_html
ls -l /home/sdr/public_html

Ostatnie z powyższych poleceń wylistuje nam katalog, w którym znajduje sie index.html i inne pliki przeznaczone do udostępnienia w ramach strony. Dzięki temu możemy upewnić się czy na pewno wszystkie są zdatne do odczytu (standardowe prawa 664, lub -rw-rw-r-- w notacji literowej).

Jeżeli wszystko wygląda OK, możemy przystąpić do testu. Restartujemy Apache, uruchamiamy przeglądarkę i wchodzimy na stronę http://localhost/~sdr/, gdzie sdr to oczywiście nazwa użytkownika, w którego katalogu domowym umieściliśmy index.html. Napis Hello world widniejący w oknie przeglądarki potwierdzi pomyślne zakończenie operacji :)

Z małego how-to wyszedł trochę dłuższy tutorial, więc postanowiłem rozbić go na dwie części. Tego posta kończę na omówionym userdir, a w kolejnym odcinku pokażę jak na apaczu uruchomić vhosty i podpiąć pod swojego home'a wirtualne domeny.

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.

niedziela, 13 stycznia 2008

Podstawa - instalacja serwera Apache, PHP i MySQL na systemie Fedora

Od pierwszego posta upłynęło trochę czasu i może niektórym nasuwały się jakieś myśli, że jednak ten blog nie wypali czy coś. Niestety sporą rolę odegrał tu tradycyjnie brak dłuższej chwili wolnego czasu. Teraz postaram się to nadrobić, publikując dwa posty :)

Kiedyś, dawno temu, jak jeszcze pracowałem na Windows za lokalny serwer WWW służył mi wszystkim znany i mniej lub bardziej lubiany kombajn Krasnal ;) Czasy jednak się zmieniają, dojrzałem, przesiadłem się na Linucha, a tu zonk - Krasnala nie ma! Poszukałem więc czegoś podobnego i znalazłem pakiet XAMPP. Dziś jednak nie o nim będę pisał, spokojnie. XAMPP ma swoje zalety, jednak nie jest też idealnym rozwiązaniem, tym bardziej że użytkownicy Fedory mają pod ręką tak potężne narzędzie jak Yum :D Cóż to jest? Pokrótce wytłumaczę wszystkim, którzy nigdy nie mieli styczności z żadną linuksową dystrybucją. Yum to proste narzędzie uruchamiane w konsoli systemu ułatwiające znacząco instalację i aktualizację oprogramowania (w tym składników systemu). To najprostsza definicja - więcej można doczytać w sieci. Jak wiadomo, niektóre programy instalowane w systemie wymagają do pracy spełnienia zależności, czyli doinstalowania innych programów, bibliotek lub składników. Czasami jest to naprawdę uciążliwe, choćby ze względu na fakt, że te doinstalowywane elementy też mogą mieć swoje wymagania xD Brzmi groźnie? Możliwe. Jednak dysponując Yumem nie ma się czego obawiać - on wszystko zrobi za nas.

No więc, jak zainstalować i uruchomić ten cholerny serwer? :> Otóż wystarczy wejść do konsoli i wykonać dosłownie dwa proste polecenia:

1. Logujemy się jako root. Jest to konieczne jeśli chcemy dokonać w systemie jakichkolwiek poważnych zmian, a instalacja czegokolwiek takową bez wątpienia jest :)
su --

Wpisujemy hasło roota i naciskamy Enter.

2. Wpisujemy

yum install httpd\* php\* mysql\*

Teraz Yum zaczyna mielić. Odpytuje repozytoria czy mają jakiś soft, którego nazwa zaczyna się od httpd (Apache), php lub mysql. Jeśli znajdzie, po chwili naszym oczom powinna ukazać się piękna, obszerna lista z wynikami. Znajdziemy na niej szukane elementy wraz z istniejącymi dodatkami (biblioteki, rozszerzenia, moduły, etc). Na końcu znajduje się prośba o potwierdzenie chęci instalacji wyszczególnionych pozycji. Zatwierdzamy wpisując Y i naciskając Enter. Teraz komponenty serwera są pobierane i instalowane, a my mamy trochę czasu dla siebie :)

Tip: Gdyby podczas instalacji program się wysypywał, możliwe że jakieś pakiety gryzą się ze sobą. Wówczas jesteśmy zmuszeni do rezygnacji z jednego z nich. Rozpoczynamy wszystko od nowa, wpisując:

yum -x nazwa_paczki install httpd\* php\* mysql\*

Po zakończonej instalacji Yum wyświetli wyczekiwany komunikat Complete! i będziemy mogli rozpocząć korzystanie z WWW na własnym komputerze. To właśnie jeden z plusów instalacji komponentów serwera przez Yuma. Nie musimy martwić się o żadną dodatkową konfigurację. PHP i MySQL praktycznie od razu współpracują z Apachem.

WWW i MySQL można uruchomić kolejno poleceniami:

/etc/init.d/httpd start
/etc/init.d/mysqld start

Dodatkowo, w zależności od potrzeb korzystamy z parametrów restart i stop.

Z podstawowych informacji warto nadmienić też, że dostęp do phpMyAdmin uzyskujemy przez adres http://127.0.0.1/phpMyAdmin/, a zawartość głównego katalogu możemy przeglądać przez http://127.0.0.1 lub http://localhost (zależy od lokalnych ustawień systemu).

Pliki swojej strony WWW umieszczamy natomiast w katalogu

/var/www/html

Jeśli wszystko będzie w porządku, po uruchomieniu serwera i przejściu pod adres http://127.0.0.1 zobaczymy mniej więcej coś takiego:


To chyba byłoby tyle. W kolejnym odcinku napiszę jak można pobawić się ustawieniami dostępnymi w httpd.conf, czyli pliku konfiguracyjnym Apache'a.

PS. Udostępniłem możliwość komantowania dla każdego, nie tylko dla posiadaczy konta Google lub OpenID co teraz powinno być na standardowym wyposażeniu każdego internauty ;) Ostrzegam jednak, że brzydkie komentarze będą sukcesywnie usuwane.

Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.