wiki potrzebna od zaraz

Jak liczba obsługiwanych maszyn zrobi się większa niż jeden (lub dwadzieścia, jak to woli) to warto by było gdzieś zapisać pewne rzeczy związane z działaniem skryptów, konfiguracją usług oraz wielu innych ważnych i mniej ważnych rzeczy. Oczywiście można wszystko trzymać w plikach, a pliki w repozytorium, ale przy osiągnięciu pewnej masy zapisanych informacji zaczynają się trudności w dostępie do zgromadzonej wiedzy, szczególnie, że serwerów i usług raczej przybywa niż ubywa. Wydaje się, że rozwiązaniem jest postawienie wiki. I tak właśnie się stało, choć z przygodami.

Po pierwsze wiki to raczej filozofia budowy strony i trzymania informacji, a nie konkretne rozwiązanie programistyczne, co odkryłem z pewnym zdziwieniem, próbując dobrać taki soft, który spełniałby nasze wymagania. Na początek miało to być perlowe i pracować z postgresem. Korzystając ze strony Wiki Choice Wizard i wyklikując pracowicie poszczególne wymagania w pewnym momencie osiągnąłem grala: na liście pozostał tylko jeden soft o wdzięcznej nazwie mojomojo. Spełniało wszystkie wymagania a dodatkowo najmilsza możliwa licencja: BSD.

Instalacja poszła jak z płatka, problemy zaczęły się po chwili i były związane z założeniami. Na serwerze usługi są rozdzielone pomiędzy chrooty. W tej sprawie interesują nas 2 z nich. Pierwszym chrootem jest chroot zwany głównym webowym, w których działa nginx jako serwer proxujący. Założeniem było również to, że ma proxować urla do serwera działającego w innych chroocie na losowym porcie (bezpieczeństwo), czyli serwis pracujący w domena/wiki znajduje się na innym serwerze. Konfiguracja wygląda następująco:

location /wiki/ {
    proxy_pass         http://127.0.0.1:PORT/wiki/;
    proxy_redirect     off;


    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

Mojomojo zostało zainstalowane we własnych chroocie w którym jako serwer www zainstalowany został nginx i tu właściwie zaczęły się kłopty z mojomojo, które doprowadziły do zakończenia współpracy z tym softem. Nie potrafiłem zmusić mojomojo do pracy w taki sposób, żeby używał w ścieżce prefiksu „wiki”. Po prostu nic. Nie dał się. Chroot został skasowany.

Taki obrót sprawy spowodował, że wróciłem do wikimatrix w celu znalezienia kolejnego kandydata. Tym razem kryterium zostało zmienione: nadal wymaganą bazą danych miał być postgresql, ale też możliwość prefiksowania tworzonych odnośników. Nistety dla mnie wynik nie pokazał jedynego kandydata, ale pokazał za to mediawiki, którą na początku jak „zbyt dużą” skreśliłem.

Ponieważ MediaWiki jest napisana w php to trzeba było zainstalować również ten język, a ponieważ serwerem www jest nginx to php został puszczony w trybie fast_cgi z następującymi parametrami:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;


fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;


fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;


fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;


fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;


# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Tym razem proces instalacji i uruchomienia przebiegł dość spokojnie. W pewnym momencie brakowało php’owi pamięci no zagwostką były problemy z proxowaniem objawiające się tym, że serwis redirectował się na lokalne IP, czyli to na którym tak naprawdę pracował, co powodowało brak dostępu. Rozwiązaniem było dodanie do konfiguracje w głównym systemie linijki:
proxy_redirect off; i wszystko śmiga jak należało.

Następnym krokiem było włączenie autoryzacji basic http w celu ograniczenia dostępu do danych. Ten sposób autoryzacji jest wystarczający, a samo bezpieczeństwo hasła opiera się na tym, że wiki będzie dostępne tylko po ssl’u. Konfiguracja nginx’a w chroocie wiki wygląda następująco:

server {
    listen      PORT;
    server_name localhost;


    access_log  /var/log/nginx/mediawiki.access.log;


    location / {
        root /var/www/nginx;
        index index.php index.html index.htm;
        auth_basic "relam name";
        auth_basic_user_file path.to.htpasswd;
    }


    location ~ \.php$ {
        root /var/www/nginx;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:PORT;
        auth_basic "relam name";
        auth_basic_user_file path.to.htpasswd;
    }
}

Rzecz o której należy pamiętać to sposób kodowania hasła i o ile do tworzenia używamy apachowego htpasswd to trzeba użyć przełącznika -d w celu włączenia kodowania hasła za pomocą CRYPT – inne sposoby po prostu nie działają w nginx.

Skoro użytkownik pojawia się już na etapie dostępu do serwisu to należy go jako takiego zalogować i do tego wykorzystałem plugin HttpAuth.

Ostatnią rzeczą było schowanie przycisków logowania metodą dość toporną, ale prostą i skuteczną:
li#pt-anonlogin, li#pt-logout, li#pt-login, li#pt-anonlogout
{
display: none;
}