Konfiguracja WordPress’a MU na nginx’a

Reguły przekierowań dla WordPress’a MU przy użyciu apache’a są opisane na stronie pomocy: Create A Network: .htaccess and Mod Rewrite. Poniżej widnieją te same reguły ale dla serwera nginx.

if ( $host !~ example\.coml$ ) {
    rewrite ^/wp-content/uploads/(.+) /files/$1;
}
rewrite ^/wp-admin/?$ /wp-admin/index.php last;
rewrite ^/wp-admin/network/?$ /wp-admin/network/index.php last;
rewrite ^/files/(.+) /wp-includes/ms-files.php?file=$1 last;
 
location / {
    try_files $uri /index.php?q=$request_uri&$query_string;
}

Oczywiście „example\.com” należy wymienić na domenę głównego serwisu.

Aktualizacja, ze strony wordpress.org znikły reguły dla apache’a:

#Wordpress Multi site
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
 
# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
 
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
#END WordPress Multi Site

logowanie .htaccess użytkownikami z psql’a

Apache pozwala na bardzo proste zabezpieczenie dostępu do serwisu z wykorzystaniem użytkowników znajdujących się w bazie danych, a dokładniej w tym przypadku w postgresie.

Oprócz modułu mod_auth należy dodać auth_pgsql oraz odpowiednio skonfigurować dane bazy:

AuthName "relam name"
AuthType basic
AuthBasicAuthoritative Off
Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user db_user
Auth_PG_pwd db_password
Auth_PG_database db_name
Auth_PG_pwd_table table_name
Auth_PG_uid_field field_username
Auth_PG_pwd_field field_password
Auth_PG_encrypted off
require valid-user

Jak widać na przykładzie podajemy dane dostępowe do serwera, bazy danych, tabeli i nazwy pól. Mam nadzieję, że konwencja którą przyjąłem jest łatwa do odgadnięcia gdzie należy wpisać odpowiednie dane.

Przy autoryzacji tego typu należy pamiętać, że hasło jest z przeglądarki wysyłane otwartym tekstem, więc na połączeniu nieszyfrowanym jest ono łatwe do przechwycenia.

sesje PHP w memcache’u

Pewien dość mocno obciążony serwer www (apache2) strasznie dużo zapisywał w katalogu sesji PHP. Na tyle dużo, że zaczeło to być problemem, jeszcze nie krytycznym, ale już zauważalnym.

Jednym z możliwych rozwiązań jest przeniesienie sesji do bazy danych, ale ze względu na specyfikę danych sesyjnych nie jest to szczególnie dobre rozwiązanie przy tej wielkości serwisu, a dodatkowo serwis korzysta z postgresa, więc wrzucanie w niego sesji jest jeszcze mniej polecane.

Rozwiązaniem zastosowanym, a które szczerze polecam jest memcache.

Instalacja jest banalnie prosta. Najpierw odpowiednie moduły na serwerze: (dla debianowaych):

sudo apt-get install memcached php5-memcache

Sprawdzamy czy serwer memcache wstał

netstat -ntlp | grep mem

oraz czy w używany php jest załadowany moduł memcache.

W konfiguracji php należy zmienić sposób przechowywania sesji oraz ustawić dane dostępowe do memchache’a:

;session.save_handler = files
session.save_handler = memcache
session.save_path="tcp://127.0.0.1:11211?persistent=1&weight=1&timeout=1&retry_interval=15"

Teoretycznie powinno zadziałać.

Niestety u mnie wystąpił następujący błąd:

Fatal error: session_start() [function.session-start]: Failed to initialize storage module: memcache (path: [...]/session) in /var/virtuals/[...].php on line 41

Który związany był z ustawianiem przez plik konfiguracyjny serwisu następującej wartości

ini_set("session.save_path",SESSION);

i dopiero po jej usunięciu wszystko zaczęło śmigać tak jak powinno.