Virtual Server czyli serwer wirtualny, jest mechanizmem pozwalającym na przypisanie usług, zasad dla jednej lub kilku domen.

Cherokee do poprawnego działania potrzebuje przynajmniej jeden serwer wirtualny, nie ma limitu co do ich maksymalnej liczby. Domyślnie tworzony jest Default i nie można go usunąć. Kiedy żadana domena nie zostanie dopasowana do żadnego serwera wirtualnego, Cherokee użyje właśnie Default.

W tym menu mamy dostęp do:

1. Lista ustawień serwera wirtualnego
2. Dodać nowy serwer wirtualny
3. Sklonować serwer wirtualny

Klonowanie serwera wirtualnego ogranicza się do wybrania nowej nazwy i wybrania jaki serwer ma zostać sklonowany. Każde ustawienie zostanie zduplikowane. Jest to świetny sposób na tworzenie wielu podobnych serwerów wirtualnych. Możesz użyć istniejącego ustawienia jako szablonu.

Aby dodać nowy wystarczy wpisać nazwę oraz podać poprawny katalog główny ( Document Root ).

1. Document Root
   Informuje Cherokee z jakiego katalogu ma wyświetlać pliki. Zestaw wszystkich reguł ( Rules ) jest sprawdzany "od góry do dołu". Kiedy jedna reguła zostaje spełniona, serwer dopisuje żądaną scieżkę do podanej w Document Root.
   
   http://www.example.com/index.html odnosi się do /var/www/index.html
   Co znaczy, że sprawdzanie odbywa się od góry do dołu ? Na przykład masz katalog /chroniony, który jest chroniony hasłem, oraz rugułę o wyższym priorytecie dla /chroniony/cgi który ma podany CGI handler. W powyższych warunkach zapytanie na /chroniony/cgi/cos spowoduje również wywołanie uwierzytelniania ustawionego dla /chroniony
2. Nickname
   Jest to tylko i wyłącznie nazwa serwera wirtualnego. Domeny jakie są obsługiwane przez dany serwer wirtualny należy podać w odpowiedniej sekcji konfiguracji.

Lista ustawień jest najbardziej przydatną rzeczą z nich. Pozwala ona na ustawienie dowolnej opcji konfiguracyjnej wybranego serwera wirtualnego.

Poniżej dokładny opis każdej z powyżej widocznych opcji.

1. Directory Indexes
   Określa czego Cherokee ma szukać w momencie kiedy klient zarząda katalogu podając / na końcu scieżki. Zwraca pierwszy znaleziony na liście. Nie trzeba podawać pośrednich scieżek:
   
   index.html,index.txt,/cgi-bin/index.py
   
   Spowoduje uruchomienie skryptu CGI jeśli żadnen z index.html i index.txt nie zostanie znaleziony w danym katalogu.
   
   Jeśli dany wpis zaczyna się od / to użyta zostanie odpowiednia reguła tego samego serwera wirtualnego.

Pozwala na podanie domen, które są obsługiwane przez dany serwer wirtualny. Można podawać nazwy domen jak i wild card dla domen:

Pamiętaj, że kiedy Cherokee otrzyma zapytanie dla danej domeny, sprawdza on listy domen dla każdego podanego serwera, w pożądku malejącym serwerów wirtualnych według ich priorytetów. Jeśli znajdzie dopasowanie, zaczyna interpretować zbiór regół dla danego serwera wirtualnego.
Jeśli zadana domena nie zostanie nigdzie dopasowana, Cherokee zacznie ponownie wyszukiwać, tym razem po nazwach serwerów wirtualnych, według identycznych zasad jak opisane wyżej.
Dopiero kiedy żadne z powyższych nie zostanie spełnione, Cherokee zwróci błąd.

Ta sekcja pozwala Ci na ustawienie zasad zachowania w zależności od otrzymanego zapytania. W podsumowaniu widoczne są następujące pola:

1. Target: cel danej reguły, może to być sieżka, rozszerzenie pliku itd.
2. Type: typ reguły. Wyjaśnienie w następnych akapitach.
3. Handler: handler dla danej reguły.
4. Auth: informuje czy dla danej reguły zostało włączone uwierzytelnianie.
5. Final: jeśli jest włączone, to Cherokee po dopasowaniu przestanie przeszukiwać pozostałe reguły dalej, nawet jeśli któraś z nich pasuje do wzorca.

Dostępne są następujące typy reguł:

1. Directory: reguła będzie zastosowana dla katalogu i jego podkatalogów.
2. Extensions: definiuje regułę która ma zastosowanie dla każdego pliku o podanym rozszerzeniu, bez znaczenie na jego położenie.
3. Regular Expression: uzupełnienie Directory oraz Extensions. W zasadzie są tutaj dwie różnice:
   • Używa wyrażeń regularnych.
   • Możliwość przekazania parametrów ( zarówno pathinfo jak i query string ). W ten sposób jest możliwość ustawienia reguł bazujących na wartościach parametrów.
4. Header: pozwala na podjęcie danej akcji w zależności od nagłówków HTTP. Przydatne jest użycie wyrażeń regularnych.
5. GeoIP: dostępny jeśli włączono wsparcie dla GeoIP. Dzięki temu będziesz mógł podejmować akcję w zależności od pochodzenia użytkownika. Pamiętaj jednak, że jeśli użytkownik użyje proxy poza krajem w którym przebywa rozpoznanie nie będzie prawidłowe.
6. File Exists: zostanie użyte jeśli plik ( lub plik z listy ) będzie dostępny.

Bardzo ważne jest abyś zrozumiał że każda reguła ma swój priorytet. Im wyższy tym wyżej jest ona wylistowana. Aby zmienić priorytet wystarczy zmienić kolejność, przenosząc wybrane reguły na nowe miejsce ( metodą drag&drop ).

Każda z tych reguł musi mieć przypisany handler. Więcej informacji o handlerach tutaj.

Tutaj możesz podać katalog w katalogach domowych użytkownika, który ma zostać użyty jako główny dla nich. Na przykład, podany został katalog /www, każdy użytkownik będzie mógł publikować swoje strony w katalogu ~/www. Ta opcja jest wyłączona jeśli nie podano nazwy.

Istnieje kilka różnych sposobów na przekazanie błędu:

1. Default errors
2. Custom redirections
3. Closest match

Loggery są to moduły Cherokee, które zapisują informacje ( logi ) na dysk. Możliwe jest podanie celu i wybranie loggera. Jeśli dany serwer wirtualny nie ma skonfigurowanego loggera, nie będzie zbierał żadnych informacji.

Szerszy opis loggerów ich części dokumentacji.

Serwer wirtualny musi zostać skonfigurowany aby obsługiwał połączenia przez https. Przygotowany został poradnik jak generować klucze SSL.

Cherokee w pełni wspiera używanie różnych certyfikatów dla każdego serwera wirtualnego używając SNI (RFC 3564).

Chcąc używać HTTPS musisz pamiętać, że obowiązkowo musisz wypełnić pola Certificate oraz Certificate key, podanie CA List jest opcjonalne.

Jeśli masz kilka serwerów wirtualnych musisz skonfigurować Security dla każdego z nich z osobna. W tej chwili nie jest możliwe takie ustawienie aby część serwerów wirtualnych miało włączone a część wyłączone HTTPS. Może się to wydawać pozbawione sensu, ale skoro otwierasz port dla połączeń SSL, i pozwalasz na przyjmowanie zapytań o połączenie HTTPS to nie ma dobrego sposobu na odmówienie tego. Zarówno przełączenie się w tryb HTTP, jak i wyświetlenie błędu nie jest dobrym wyjściem z takiej sytuacji.