Z backupami to jest dziwna sprawa. Robi je tak na oko co trzeci-czwarty użytkownik, pozostali zapewne jeszcze nie mieli poważnej awarii. Po padzie dysku twardego, naszła mnie refleksja, że trzeba praktykę backupu zweryfikować. Nie straciłem bowiem żadnych danych, te spoczywały bezpiecznie na różnych, własnych i obcych dyskach.
Straciłem za to coś innego. Straciłem pięknie skonfigurowany i dostosowany całkowicie do moich preferencji system. Trzeci dzień po awarii, nadal nie wszystko działa tak jak powinno. Część rzeczy nie jest pilna, o części zapewne zapomniałem.Mam nadzieję kiedyś do tego artykułu wrócić, pokiwać głową z uśmiechem i stwierdzić: „Dziś moje kopie bezpieczeństwa są kompletne”. Tymczasem zapiszę tutaj, jak skonfigurować od początku do końca testowy serwer www.
Kiedyś już poruszałem tematykę własnego serwera LAMP. Od tamtego jednak czasu, zyskałem doświadczenie i usprawniłem sporo jego działanie.
Zacznijmy od podstaw – instalacja.
[code]sudo apt-get install apache2 php5-mysql mysql-server mysql-client libapache2-mod-php5 php5-gd[/code]
To jedno złożone polecenie pozwoli nam od razu cieszyć się działającym serwerem.
Podczas instalacji system zapyta nas o hasło [cci]root’a[/cci] do bazy danych oraz nazwę użytkownika systemu, z uprawnieniami którego ma wykonywać się proces serwera Apache. W moim przypadku jest to [cci]www-data[/cci]. Dlaczego to takie ważne?
Testujemy jego działanie otwierając w przeglądarce adres [code]http://localhost[/code]
Do tego przydać się mogą narzędzia kontroli wersji. Podczas rozwijania wtyczek WordPressowych do oficjalnego repozytorium korzystam przymusowo z SVN, podczas innych projektów – GIT.
[code]sudo apt-get install subversion git[/code]
Konfiguracja
Na początek załączmy moduły, które będziemy potrzebowali:
[code]a2enmod rewrite
a2enmod vhost_alias[/code]
Pierwszy z nich pozwala na modyfikację adresów URL i jest stosowany praktycznie w każdym systemie CMS – dzięki niemu adresy ładnie wyglądają. Drugi moduł będziemy wykorzystywać do testów stron, które nie są stawiane na WordPressie – generuje on adresy subdomenowe dla podkatalogów. Może brzmieć to na razie skomplikowanie, ale wrócę do tematu jeszcze w tym artykule.
Następnie w katalogu [cci]/etc/apache2/sites-available[/cci] tworzymy plik tekstowy o nazwie na przykład [cci]wptest[/cci]. Polecam wypełnić następującą zawartością:
Teraz tworzymy plik [cci]test[/cci] – konfigurację dla stron niewordpressowych:
Następnie przygotowujemy sieć katalogów i ustawiamy do nich uprawnienia:
[code]sudo chown www-data:www-data /var/www/ -R
sudo chmod g+s /var/www
sudo chgrp www-data /var/www
sudo setfacl -d -m group::rwx /var/www
mkdir -p /var/www/wptest/htdocs
mkdir -p /var/www/test/htdocs[/code]
W środowisku testowym warto ustawić opcję wyświetlania błędów w wykonaniu skryptu. Edytujemy plik [cci]/etc/php5/apache2/php.ini[/cci] i tam znajdujemy linię [code]display_errors = Off[/code] (u mnie jest to linia 480) i zamieniamy ją na [code]display_errors = On[/code]
Na koniec zaś restartujemy serwer Apache
[code]sudo service apache2 reload[/code]
Czego w systemie brakuje?
Mamy już prawie wszystko. Tylko system nie bardzo wie co z tym fantem zrobić. O ile radzi sobie, jeżeli do przeglądarki wpiszemy adres [cci]http://localhost[/cci], to z adresem typu [cci]http://ljasinski.wptest[/cci] kompletnie sobie nie radzi. Jak mu pomóc? Są dwie metody
1. Metoda łatwa, acz upierdliwa
Po prostu każdy wpis dodajemy jako nową linijkę w pliku [cci]/etc/hosts[/cci]. Będziemy więc tam mieli
[code]127.0.0.1 wptest
127.0.0.1 www.wptest
127.0.0.1 ljasinskipl.wptest
127.0.0.1 www.ljasinskipl.wptest
[/code] Łatwe do zapamiętania. A ponieważ co chwilę nie dodaje się nowej strony testowej, można z tym jakoś żyć. Tylko po co, skoro jest
2. Metoda ciut skomplikowana, acz wygodna po zastosowaniu
Takie set it and forget it. Polega to na zainstalowaniu lokalnego serwera DNS, który ruch dla subdomen [cci]*.wptest[/cci] i [cci]*.test[/cci] przekieruje na nasz lokalny serwer www. Zacznijmy więc od instalacji:
[code]sudo apt-get install dnsmasq[/code]
Następnie edytujemy plik [cci]/etc/dhcp/dhclient.conf[/cci]. Znajdujemy w nim linię [code]#prepend domain-name-servers 127.0.0.1;[/code] i usuwamy na jej początku znak [cci]#[/cci].
Kolejnym plikiem, który trzeba wyedytować jest [cci]/etc/dnsmasq.conf[/cci]. Tam, w odpowiednim miejscu (u mnie jest to linia 68), dodajemy wpisy[code]address=/.wptest/127.0.0.1
address=/.test/127.0.0.1[/code]
Dla pewności dobrze jest zrestartować komputer (choć w teorii wystarczyć powinno [code]sudo /etc/init.d/networking restart[/code] jako restart usług sieciowych). Po tym czasie powinniśmy już móc cieszyć się w pełni działającym serwerem testowym LAMP.
Jak to działa?
Domena [cci]wptest[/cci] i wszystkie jej subdomeny wskazują na katalog [cci]/var/www/wptest/htdocs[/cci], w którym należy zainstalować WordPressa – najlepiej jako multisite. Kompletny poradnik wraz z doborem pluginów do środowiska testowego – już w następnym odcinku.
Domena [cci]test[/cci] nie działa. Natomiast wszystkie jest subdomeny wskazują na podkatalogi [cci]/var/www/test/htdocs[/cci], stąd na przykład adres [cci]http://system.test[/cci] otworzy nam stronę w katalogu [cci]/var/www/test/htodcs/system[/cci].
A wy, macie jakieś swoje udoskonalenia czy triki konfiguracyjne do serwera testowego? Dajcie znać.
Leave a Reply