Kilka dni temu przyszedł czas na aktualizację systemu, w tym środowiska KDEmod (do wersji 4.5.2). Poczatkowo problemem był konflikt zależności – w systemie znajdowało się (i było wymagane przez niektóre programy) zmodyfikowane qt – czyli qtmod, a do wykonania aktualizacji potrzebne było „oryginalne” qt. Postanowiłem „zaryzykować”, odinstalowałem zmodyfikowaną wersję i pobrałem qt razem z KDEmod. Byłem przygotowany na wystąpienie pewnych problemów, ale trochę zaskoczyło mnie to, czego dotyczyły

Od razu mogę powiedzieć, że zamiana qtmod na qt nie miała większego wpływu na pracę systemu – wszystkie zainstalowane programy działają tak, jak powinny.

Jednak mimo wszystko start środowiska po aktualizacji nie udał się. Powitał mnie komunikat:

Call to lnusertemp failed {temporary directories full?}. Check your installation?

Wynikałoby z niego, że brakuje miejsca na pliki tymczasowe. Jednak nie – na systemowej partycji ponad 3GB wolnego miejsca. No to szukamy dalej – użytkownik jednego z forów poradził, aby sprawdzić uprawnienia dla katalogów /tmp oraz /var/tmp. Dla kilku osób okazało się to rozwiązaniem, ale u mnie problem dalej istniał (pomimo praw dostępu dla obu katalogów ustawionych na 777).

Rozwiązaniem okazało się usunięcie dowiązań ~/.kdemod4/cache-localhost.localdomain, ~/.kdemod4/socket-localhost.localdomain, oraz ~/.kdemod4/tmp-localhost.localdomain. Po restarcie zostały automatycznie odtworzone i środowisko wreszcie ruszyło

Od dość długiego czasu szukałem alternatywy dla Amaroka. Przeszkadzało mi w nim przede wszystkim to, że stał się „kombajnem” do zarządzania i odtwarzania muzyki. Zajmował dość dużo miejsca w RAMie, dziwnie zachowywał się podczas przeciągania na listę nowych utworów/katalogów oraz potrzebował chwili czasu na uruchomienie. Testowałem kilka innych programów, ale JuK zdecydowanie najbardziej przypadł mi do gustu.

Ogólnie można powiedzieć, że jego funkcjonalność jest bardzo zbliżona do wspomnianego Amaroka (odtwarzanie wielu formatów, wbudowana biblioteka mediów, edytor tagów oraz wyszukiwanie ich w Sieci, zarządzanie listami odtwarzania, etc.) Dodatkowo lekki interfejs (wyglądem zbliżony do Dolphina – na pierwszy rzut oka okno programu przypomina mi otwarty folder) estetycznie komponuje się z KDE.

W tym momencie jedynym zauważonym przeze mnie minusem jest statyczna belka tytułowa – brak na niej nazwy aktualnie odtwarzanej piosenki, cały czas mamy tam napis – nazwę programu). Przeszkadza to, gdy player jest zminimalizowany albo ukryty pod innymi oknami.

Poza tym JuK posiada dość ubogie możliwości konfiguracji – choć w porównaniu do Amaroka sporą część odtwarzaczy można nazwać „ubogimi” Dla niektórych będzie to wadą, ale bynajmniej nie dla mnie. Domyślny wygląd i ustawienia są intuicyjne, co na pewno jest plusem. Dlatego też wydaje mi się, że na dłuższy czas znalazłem dla siebie dobry odtwarzacz, a Amarok już poszedł w odstawkę

Podłączenie się do domowej sieci bezprzewodowej – w teorii czynność prosta i bezbolesna, a praktyce czasem bywa różnie Mnie zeszło dobrych kilkanaście minut, a wszystko przez daemona dbus do spółki z NetworkManagerem dostarczanym przez KDE.

Na „dzień dobry” powitał mnie brak uprawnień podczas próby uruchomienia NetworkManagera. Po krótkich poszukiwaniach ustaliłem, że konieczne jest dodanie dwóch wpisów:

• do pliku /etc/dbus-1/system.d/NetworkManager.conf

  <policy group="network">
       <allow send_destination="org.freedesktop.NetworkManager" 
              send_interface="org.freedesktop.NetworkManager"/>
  </policy>

• oraz do pliku /etc/dbus-1/system.d/nm-applet.conf

  <policy group="network">
       <allow own="org.freedesktop.NetworkManagerUserSettings"/>
       <allow send_destination="org.freedesktop.NetworkManagerUserSettings"
              send_interface="org.freedesktop.NetworkManagerUserSettings"/>
   
       <deny send_interface="org.freedesktop.NetworkManagerSettings.Secrets"/>
  </policy>

Drugiego z plików nie było w systemie. Dlaczego? Ano dlatego, że jest częścią pakietu network-manager-applet, czyli appleta do zarządzania połączeniami dla… Gnome To nam akurat nie przeszkadza, bo w przeciwieństwie do jego odpowiednika z KDE, ta aplikacja działa dokładnie tak jak powinna.

Kolejnym krokiem jest zmiana daemona zarządzającego połączeniami. Od teraz nie będzie to network, a networkmanager. Edytujemy plik /etc/rc.conf pamiętając, że networkmanager musi być uruchamiany po daemonie hal:

DAEMONS=( ... !network hal networkmanager... )

W moim przypadku adres IP jest przydzielany dynamicznie, więc w sekcji INTERFACES wyłączamy wszystkie dotychczasowe konfiguracje połączeń:

#eth0="dhcp"
#wlan0="dhcp"
INTERFACES=(!eth0 !wlan0)

W między czasie warto pamiętać o dodaniu użytkownika do odpowiednich grup (network, networkmanager) oraz zatrzymaniu daemona network i restartowaniu dbus lub networkmanager po dokonaniu zmian w plikach. Przypominam o tym, bo sam straciłem trochę czasu i cierpliwości przez nieodświeżanie konfiguracji

Kiedy przebrniemy przez to wszystko, powinno udać nam się uruchomić nm-applet. Dalsza konfiguracja przebiega już bez niespodzianek – wystarczy podanie klucza WPA i mamy dostęp do Internetu.

Wydaje mi się, że opisałem najważniejsze rzeczy. Jednak prób (i błędów) związanych z tematem było na tyle sporo, że coś mogło mi umknąć. Tak czy inaczej ogólny zarys postępowania jest, mam nadzieję że komuś sie przyda

Kilka dni temu do naszego studenckiego mieszkania został podłączony Internet. Z racji chwilowego braku routera dostęp do Sieci ma ten, kto pierwszy dopadnie kabel (chociaż w sumie ja nie mam co narzekać, bo opisywany przeze mnie internet od Play’a nadal spisuje się dobrze). Niestety tylko komputer o adresie MAC zgłoszonym dostawcy może komunikować się ze światem, dlatego też musiałem „podszyć się” pod maszynę mojego współlokatora.

O klonowaniu MAC napisano już wiele, ale dla formalności przypomnę, co należy zrobić:

• zatrzymanie karty, dla której MAC ma być zmieniony
• zmiana adresu
• uruchomienie karty
• restart sieci

W konsoli możemy to zrobić wydając kolejno polecenia:

1
2
3
4

ifconfig eth0 down
ifconfig eth0 hw ether XX:XX:XX:XX:XX:XX
ifconfig eth0 up
/etc/rc.d/network restart

Wszystko będzie działać jak trzeba, tyle że po ponownym uruchomieniu systemu MAC wróci do swojej „fabrycznej” wartości. I wreszcie, po trochę przydługim wstępie docieramy do sedna dzisiejszego wpisu – daemona, który przy uruchomieniu systemu od razu zmieni MAC na bardziej nam odpowiadający

Poniżej zamieszczam jego kod (znaleziony na anglojęzycznym wiki ArchLinuksa)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/bash                                                                     
. /etc/rc.conf                                                                  
. /etc/rc.d/functions
 
case "$1" in
start)
      stat_busy 'Setting MAC address'
      if ifconfig eth0 hw ether XX:XX:XX:XX:XX:XX # your new MAC address
      then
              stat_done
      else
              stat_fail
      fi
      ;;
stop)
      stat_busy 'Restoring original MAC address'
      if ifconfig eth0 hw ether YY:YY:YY:YY:YY:YY # your old MAC address
      then
              stat_done
      else
              stat_fail
      fi
      ;;
restart)
      $0 stop
      $0 start
      ;;
*)
      echo "Usage: $0 {start|stop|restart}"
esac

Plik zapisujemy w /etc/rc.d/, np. pod nazwą set-hw-addr. Teraz wystarczy tylko dodać daemona do /etc/rc.conf w taki sposób, aby uruchamiał się przed interfejsem sieciowym:

DAEMONS=(... set-hw-addr network ...)

Na koniec dodam tylko, że podłączanie dwóch komputerów (przy pomocy switcha) o tym samym MAC do sieci to nie jest dobry pomysł (sprawdzone doświadczalnie)

W myśl pewnego stwierdzenia ludzie dzielą się na tych, którzy robią kopie zapasowe i na tych, którzy dopiero zaczną je robić Ja należę do tych pierwszych, co ważniejsze dane staram się backupować. Niedawno skrypt, który wykonuje za mnie całą pracę przeszedł modyfikacje, a jego ostatnią wersją mam zamiar się podzielić z Wami.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/bash
 
CREATE=`date +%F`
DELETE=`date +%F -d"-28 day"`
 
#usunięcie najstarszego backupu
if [ -e ./backups/backup_$DELETE.tar.gz ]
then
  rm ./backups/backup_$DELETE.tar.gz
fi
 
#zrzut bazy danych
/usr/local/mysql/bin/mysqldump -A -uXXXXX -pXXXXX > ./dump_$CREATE.sql
 
#pakowanie zawartości konta
tar --exclude-tag-all=backup.sh -zcvf ./backups/backup_$CREATE.tar.gz ./
 
#usunięcie zrzutu bazy danych
rm ./dump_$CREATE.sql
 
#wysłanie kopii na inny serwer
scp ./backups/backup_$CREATE.tar.gz remote:~/backups/hosting
 
#usunięcie najstarszego backupu na zdalnym serwerze - odpowiednik linii 7-11
ssh remote "if [ -e ./backups/hosting/backup_$DELETE.tar.gz ]
then
  rm ./backups/hosting/backup_$DELETE.tar.gz
fi
exit"

Na początek ustalamy aktualną datę, która będzie występować w nazwach plików, oraz datę kopii, która jest najstarsza i zamierzamy się jej pozbyć. Skrypt wykonuje się u mnie raz na tydzień, więc zmienną $DELETE, pomniejszam o 28 dni. Dzięki temu na serwerze zawsze pozostają cztery ostatnie kopie (aktualnie wykonana i trzy poprzednie; czwarta zostanie usunięta).

Po usunięciu jednego z archiwów (jeśli oczywiście istnieje) zabieramy się za tworzenie bieżącej kopii. Na początek zrzut wszystkich naszych baz do pliku. Służy do tego narzędzie mysqldump. Przyjmowane opcje to kolejno:

• -A – zrzut wszystkich dostępnych baz danych
• -u – nazwa użytkownika baz danych
• -p – hasło dla ww. użytkownika

Następnym krokiem jest tarowanie i kompresja zawartości katalogu domowego. Tu bardzo pomocna okazała się opcja –exclude-tag-all. Powoduje ona pominięcie katalogu, w którym znajduje się plik o nazwie podanej jako wartość tej opcji. Zapisując skrypt pod nazwą backup.sh w katalogu ./backups osiągnąłem to, co zamierzałem – folder, w którym lądują kopie nie jest dołączany do archiwum.

Dla porządku usuwam jeszcze plik z bazami danych. Został zarchiwizowany, więc nie musi już leżeć w katalogu głównym mojego konta.

W tym momencie z grubsza wszystko jest gotowe. Tyle że backup trzymany w tym samym miejscu, co reszta danych chroni mnie tylko przed własnymi „błędami” – przypadkowym usunięciem/nadpisaniem plików. W razie awarii dysku czy podobnej sytuacji i tak nie będę miał dostępu do kopii (wiem że administratorzy też archiwizują dane, ale ich uzyskanie może chwilę potrwać). A skoro mam możliwość wysłania ich na inny serwer, to czemu z niej nie skorzystać?

Na sam koniec pozostaje usunięcie najstarszej kopii z zapasowego serwera. Wykonujemy mniej więcej to samo, co na początku skryptu, tylko że po zalogowaniu się na wspomniane konto.

Ostatecznie mamy kopię baz danych spakowaną razem z całą zawartością folderu domowego (wyłączając katalog ./backups) i dodatkowo wysłaną na zewnętrzny serwer. Teraz wystarczy dodać zadanie do crontab‘a, np.

0 10 * * 2 ./backups/backup.sh

i (dopóki nic złego się nie dzieje) można zapomnieć o całej sprawie, a kopia wykona się co wtorek o 10 rano

Informacja

Autorem kodu, na którym częściowo oparłem swój skrypt, jest Filip Cierpich.

.bashrc – główny plik konfiguracyjny jednej z najpopularniejszych powłok systemowych dla Linuksa. Umożliwia nam personalizację Bash’a, aby jak najlepiej dostosować go do swoich potrzeb. Zazwyczaj wraz z upływem czasu wydłuża się jego zawartość, użytkownicy dodają wpisy ułatwiając sobie późniejszą pracę. W tym poście mam zamiar podzielić się moim .bashrc. Ameryki na pewno nie odkryję, bo wszystkie przedstawione przeze mnie rzeczy znalazłem wcześniej w Sieci, ale liczę, że ktoś jeszcze ich nie spotkał i okażą się przydatne

Na początek podaję całą zawartość mojego pliku. Za moment zajmę się omówieniem poszczególnych jego fragmentów.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# Check for an interactive session
[ -z "$PS1" ] && return
 
export EDITOR=nano
 
# wyświetlanie daty przy każdym poleceniu w historii
export HISTTIMEFORMAT="| %d/%m/%y %T | "
 
# kolorowanie plików man
export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'                           
export LESS_TERMCAP_so=$'\E[01;44;33m'                                 
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'
 
#aliasy
alias ls='ls -ahl --color=auto'
alias pacman="sudo pacman-color"
alias grep='grep --color'
alias r='sudo su'
alias ..='cd ..'
alias x='startx'
alias c='clear'
alias mount='sudo mount'
alias umount='sudo umount'
alias play="sudo wvdial play"
alias sh='sudo shutdown -h now'
 
 
#konfiguracja wiersza poleceń
if [[ $( whoami ) == root ]]; then
  PS1="\[\033[0;34m\][\u@\h] \[\033[0;33m\][ \t ] \[\033[0;31m\][ \w ] \[\033[0m\] \n >> "
else
  PS1="\[\033[0;32m\][\u@\h] \[\033[0;33m\][ \t ] \[\033[0;31m\][ \w ] \[\033[0m\] \n >> "
fi
#domyslna
#PS1='[\u@\h \W]\$ '
 
# autouzupełnianie poleceń poprzedzonych przez 'sudo'
if [ "$PS1" ]; then
  complete -cf sudo
fi
 
# 10 najczęściej używanych poleceń
topten () {
    history | awk '{a[$6]++ } END{for(i in a){print a[i] " " i}}' | sort -rn | head
}
 
# blokowanie > jeżeli plik istnieje
set -o noclobber

Na początek linia 2. – standardowa opcja sprawdzająca, czy Bash jest uruchomiony w trybie interaktywnym.

Linia 4. to ustawienie domyślnego edytora – Vim, Kate, Nano… co kto lubi

7. linia związana jest z poleceniem history. Określa format daty, która będzie dodatkowo wyświetlana przy każdym wpisie na liście ostatnio używanych komend.

W liniach od 10. do 16. zawarte są opcje kolorowania składni plików manuala. Bardzo pomocne, bo nagłówki, wszystkie opcje i opisywane parametry są wyróżnione, przez co tekst nie zlewa się w niewyraźną całość. O samym kolorowaniu nie będę się rozpisywał, krótko i treściwie zostało to już przedstawione pod tym adresem.

Kolejne kilkanaście linijek to aliasy – głównie dodanie parametrów, które i tak za każdym razem byłyby przeze mnie dopisywane, ewentualnie skrócenie niektórych nazw poleceń. Niektórzy dodają nawet aliasy będące najczęściej popełnianymi przez nich literówkami (np.: alias gerp=’grep –color’). Można i tak, grunt żeby ułatwić sobie życie

Linie od 32. do 36. to krótki warunek definiujący wygląd wiersza poleceń. Oprócz zazwyczaj spotykanych nazw użytkownika i hosta dodane są także aktualna godzina oraz bieżący katalog. Całość została przejrzyście pokolorowana. Dodatkowo po zalogowaniu się na konto root jego nazwa jest zapisana innym kolorem.

Następny warunek włącza uzupełnianie poleceń poprzedzonych sudo – czyli nadal działa nam nieoceniony klawisz TAB

Funkcja topten() zgrabnie wyciąga z historii najczęściej używane polecenia. Pomijając zawiłości awk można powiedzieć, że zapakowaliśmy w nią cztery polecenia, jedno po drugim opracowujące dla nas żądaną listę.

Ostatnia opcja uchroniła mnie już kilka razy przed utratą mniej lub bardziej ważnych danych. Blokuje bowiem nadpisanie istniejącego pliku przekierowanym na niego strumieniem. Przy próbie ww. działania zostaniemy poinformowani, że nie jest to możliwe.

Jeśli macie jakieś ciekawe tricki dodane do .bashrc i chcecie się nimi podzielić – zapraszam do komentowania

Dziś króciutki wpis – prezentacja ciekawej strony, na którą dziś trafiłem. Chodzi o zawarty w tytule wpisu serwis commandline.pl, czyli „Świat komend linuksowych”.

Adres warty dodania do zakładek, bo autor publikuje przydatne przykłady użycia konsolowych programów. Na pewno wszystkie napisane tam rzeczy można znaleźć w dokumentacji, ale przyznajmy szczerze – nie zawsze nam się chce przez nią przebijać A tak mamy pod ręką przykłady poleceń, które mogą nam zaoszczędzić trochę czasu i co nieco ułatwić życie.

Prezentowana lista jest całkiem spora – obejmuje zarówno narzędzia podstawowe (i wydawałoby się banalne) jak grep czy nawet mv, ale także tego programy równie przydatne, a już niekoniecznie tak proste w obsłudze (np. sed lub awk).

Myślę, że nawet zaawansowani użytkownicy Linuksa trafią tam na nowe dla nich rzeczy, a dla początkujących strona może okazać się nieocenioną pomocą

W home.pl mam wykupionych kilka domen – w sumie tylko jedna była zarejestrowana „normalnie”, pozostałe wziąłem w promocji i pewnie nawet nie będę ich przedłużał. Chociaż to akurat jest mało ważne. Muszę przedłużyć domenę globalną (.net), ale nikt nie powiedział, że zrobię to w home.pl, który tani na pewno nie jest…

Szybkie przejrzenie cenników kilku operatorów wyraźnie w dobrym świetle stawia OVH. Transfer domeny globalnej (co jest równoznaczne z jej przedłużeniem na kolejny rok) to koszt 24.39 PLN z VAT, a późniejsze prolongaty są o ok 5PLN droższe. Dla porównania w home.pl roczne przedłużenie kosztuje 61 PLN – lekko licząc wychodzi dwa razy drożej.

Co prawda moja domena jest już wygasająca (na dzień dzisiejszy pozostało 19 dni), ale home.pl nie robi przeszkód przy wykonywaniu transferu w takiej sytuacji. Dlatego też wczoraj wysłałem wniosek o wydanie AuthInfo. Prośba została rozpatrzona bardzo szybko, minęły chyba dwie godziny i dostałem oczekiwanego maila z kodem. Konsultant zapytał się przy okazji, czy może wiedzieć po co mi ten kod Troszkę wesoło mi się zrobiło, ale napisałem zgodnie z prawdą, że mam zamiar przenieść się do innego, tańszego operatora. Następny mail i pytanie, czy jestem zainteresowany indywidualną ofertą lub przedłużeniem na więcej niż rok. Okazało się, że jeśli zapłacę z góry za 3 lata to mogą mi zaproponować… 10% zniżki.

A teraz trochę prostej matematyki…

Na początek oferta home.pl (przedłużenie na 3 lata z góry)

• 3 x 61 PLN = 183 PLN
• zniżka wyniesie 18.30 PLN, czyli do zapłacenia pozostanie 164.70 PLN

Bierzemy pod lupę OVH (transfer, czyli przedłużenie na rok + koszt utrzymania przez kolejne dwa lata)

• 24.39 PLN + 2 x 29.27 PLN = 82,93 PLN

Chyba nie ma sensu komentować tego porównania, decyzja jest oczywista. AuthInfo już mam, wpłata w OVH zaksięgowana, czekam na pojawienie się nowej domeny w panelu. Potem tylko wklepanie kodu i pewnie znów troszkę czekania na zatwierdzenie zmian. Jak na razie wszystko idzie dobrze, ale w razie pojawienia się problemów na pewno popełnię jakiś wpis przybliżający Wam sytuację.

A home.pl? Niech sobie trzyma swój cennik (i wspaniałe indywidualne oferty) dla innych klientów, ja ani trochę nie jestem zainteresowany. Skoro to samo mogę mieć dwa razy taniej i na dodatek w porównywalnej co do wielkości firmie (jestem pewien, że to nie organizacja-krzak, która z dnia na dzień zniknie z Sieci) to po co mam przepłacać?

Chyba każdy, kto korzysta z poczty elektronicznej zastanawia się, jak ułatwić sobie życie. Klienty pocztowe (Thunderbird, KMail, Outlook, etc.) na pewno pomagają utrzymać porządek, zwłaszcza gdy mamy kilka kont na różnych serwerach. I pewnie normalnie korzystałbym z któregoś z nich, gdyby nie Gmail. Według mnie ma wszystkie funkcje, których wymagam od klienta pocztowego. I jeszcze trochę więcej Stosowanie etykiet zamiast folderów oraz grupowanie rozmów w wątki to dwie główne cechy, które działają na korzyść webowego interfejsu od Google, a z którymi „zwykłe” programy nie zawsze radzą sobie tak, jakbym chciał.

Obsługa etykiet

Mechanizm etykiet jest według mnie wygodniejszy od tradycyjnych folderów. Lepiej jest mieć jedną wiadomość oznaczoną odpowiednimi etykietami, niż kilka jej niezależnych kopii, które po prostu zajmują miejsce. Co prawda wielu ludzi narzeka na taki sposób oznaczania wiadomości, pewnie z powodu przyzwyczajenia do folderów. Ale zależy, co kto lubi

Korzystając z klienta poczty, próbującego dostosować się do struktury Gmaila, wiadomości oznaczone kilkoma tagami mam widoczne w kilku folderach. Jest to jak najbardziej logiczne, ale nie do końca wygodne. Mając otwartą wiadomość nie da się szybko dodawać/usuwać etykiet, można tylko kopiować albo przenosić maile między folderami. Poza tym mając otwartą wiadomość nie wiem jakimi innymi tagami jest ona w danej chwili oznaczona. Za to w Gmailu wszystko od razu widać na pierwszy rzut oka. Dodatkowo można rozwinąć listę dostępnych etykiet i – zaznaczając lub odznaczając wybrane opcje – masowo tagować korespondencję.

Grupowanie rozmów w wątki

To drugi najważniejszy argument przemawiający za Gmailem. O ile rozmówcy używają opcji „Odpowiedz…”, to wszystko będzie pięknie się grupowało, a przeglądanie rozmowy będzie przypominało czytanie archiwum komunikatora. W kliencie pocztowym (bawiłem się co nieco tym wbudowanym w Operę oraz KMail‘em) wygląda to z grubsza podobnie, ale mimo wszystko nie zawsze mogę się połapać co i jak. Po prostu w Gmailu jest bardziej przejrzyste.

Gmail przez www

Wydaje mi się, że optymalnym rozwiązaniem jest dla mnie obecna sytuacja – Gmail pobiera pocztę ze pozostałych moich kont, jednocześnie filtrując ją i przydzielając odpowiednie etykiety. Skonfigurowałem też wysyłanie – po prostu z listy wybieram sobie adres, który ma być nadawcą wiadomości. Dzięki temu webmail od Google z powodzeniem pełni funkcję klienta poczty, do którego mam dostęp z dowolnego komputera.

O VirtualHost i konfiguracji tego mechanizmu powstało już wiele artykułów i blogowych wpisów. Mimo wszystko postanowiłem poruszyć ten temat i opisać, jak można je uruchomić w ArchLinux.

Do czego może nam się przydać vHost? Przede wszystkim to możliwość lokalnego symulowania sytuacji na docelowym serwerze. Czasem zachodzi konieczność uruchomienia skryptu tak, jakby był podpięty bezpośrednio pod jakąś domenę, a nie zakopany głęboko w drzewie katalogów (a tak to zazwyczaj wygląda na lokalnym serwerze). Z tego też powodu przeniesienie projektu z localhosta na zewnętrzną maszynę może wymagać od nas zmian w strukturze folderów lub przebudowania fragmentów kodu. vHost pomaga uniknąć takich problemów, poprzez tworzenie wirtualnych domen widocznych tylko na lokalnym komputerze. Dzięki nim od razu możemy pisać tak, jakby wszystko działało na „prawdziwym” serwerze.

We wpisie posłużę się przykładem skryptu phpMyAdmin, zainstalowanym w katalogu /srv/http/phpmyadmin. Początkowo jest on dostępny poprzez adres http://localhost/phpmyadmin/.

Aby utworzyć vHost, wystarczy edycja trzech plików:

• /etc/hosts
• /etc/httpd/conf/extra/httpd-vhosts.conf
• /etc/httpd/conf/httpd.conf

/etc/hosts

Pierwszy z nich początkowo wyglądał u mnie tak:

127.0.0.1       notebook
127.0.0.1       localhost

gdzie notebook to nazwa komputera – ta sama, którą ustawialiśmy podczas instalacji w pliku /etc/rc.conf. Ewentualnie możemy ją sprawdzić, wklepując w konsolę

echo $HOSTNAME

Teraz wystarczy dopisać kolejną linijkę, definiującą nową nazwę domenową:

127.0.0.1       pma.local

W ten sposób określamy, na jaki adres IP skierować użytkownika po wpisaniu w oknie przeglądarki http://pma.local/.

httpd.conf

Kolejnym krokiem jest edycja pliku /etc/httpd/conf/httpd.conf. Trzeba znaleźć linijkę

#Include conf/extra/httpd-vhosts.conf

i ją odkomentować. To jedyna zmiana w tym pliku – aby nie robić sobie bałaganu w głównej konfiguracji, wszystkie wirtualne hosty będziemy definiować w specjalnie przeznaczonym do tego pliku.

httpd-vhosts.conf

Właśnie zabieramy się za jego edycję – dodajemy wpisy konfigurujące wirtualnego hosta:

1
2
3
4
5
6
7
8
9
10
11

NameVirtualHost *:80
 
<VirtualHost *:80>
    DocumentRoot /srv/http
    ServerName localhost
</VirtualHost>
 
<VirtualHost *:80>
    DocumentRoot /srv/http/phpmyadmin
    ServerName pma.local
</VirtualHost>

Pierwsza linia odpowiada za nasłuch portów. Bez niej (prawdopodobnie) działał będzie tylko pierwszy zdefiniowany host. Trzeba ją znaleźć (w httpd.conf lub httpd-vhosts.conf) i odkomentować.
Zastanawiacie się pewnie, po co właściwie potrzebne są linijki 3-6? Po wprowadzeniu zmian w pliku httpd.conf adres http://localhost/ przestał działać – wpisanie go powoduje przekierowanie na pierwszy utworzony vHost. Ta krótka wstawka przywraca go z powrotem do użytku. Oczywiście jeśli tworzymy kilka vHostów, to fragment opisujący localhost dodajemy tylko raz.

Kilka słów o definiowanych wartościach:

• DocumentRoot – określa bezwzględną ścieżkę do głównego katalogu skryptu lub projektu
• ServerName – domenowa nazwa, którą utworzyliśmy w pliku /etc/hosts

Dostępne są jeszcze dodatkowe opcje – ich opis można zobaczyć na stronach projektu Apache.

Zakończenie

Teraz pozostaje tylko restart serwera:

/etc/rc.d/httpd restart

i po wpisaniu w oknie przeglądarki adresu http://pma.local/ powinniśmy zobaczyć to samo, co pod adresem http://localhost/phpmyadmin/.

W ten sposób możemy tworzyć wpisy, które oprócz symulowania adresu domenowego będą po prostu krótsze, a przez to łatwiejsze do zapamiętania.