Plesk ma miedzy innymi tą jedną wadę, że nie da się założyć z poziomu panelu więcej niż jednego konta FTP. Nie mówię tu o tzw. użytkownikach web, tylko o normalnych kontach FTP. Wyobraźmy sobie sytuację: chcemy założyć dla naszych klientów konta FTP gdzie będą mogli nam wgrywać pliki, do których nie będzie dostępu z www i nie inni klienci nie będą mieli do nich dostępu. Niestety, w tym zakresie Plesk jak na razie daje plamę i nie umożliwia zakładania takich kont. Podobno ta funkcjonalność miała wejść już w wersji 9, ale jak do tej pory nie weszła (obecnie używam wersji 9.2.2).

Na szczęście można to obejść, choć niestety musimy użyć w tym celu linii poleceń. W wersji dla Debiana wygląda to mniej więcej tak: (more…)

Jakiś czas temu zaktualizowałem Pleska na swoim serwerze (no dobra, admin mi zaktualizował) do wersji 9.2. Pośród nowości najbardziej spodobała mi się nowa opcja w ustawieniach ochrony antyspamowej: greylisting. Spam mailowy przestał istnieć w 99,99% a SpamAssassin w zasadzie nie ma nic do roboty. Co to jest greylisting? Podaję za Wikipedią:

Greylisting (lub graylisting) to metoda ochrony kont poczty elektronicznej przed spamem. Serwer poczty, który używa metody greylistingu, odrzuca maile od nierozpoznanych nadawców przy pierwszej próbie ich dostarczenia. Ponieważ odrzucenie maila realizowane jest poprzez zwrócenie serwerowi nadawcy kodu błędu oznaczającego tymczasowe problemy z odebraniem maila, to jeśli taka wiadomość została przesłana ze stałego serwera poczty, to zgodnie ze specyfikacją protokołu pocztowego, serwer ten po pewnym czasie (zależnym od ustawień serwera nadawcy) ponowi próbę wysłania wiadomość, która tym razem zostanie przyjęta przez serwer odbiorcy. Jeśli poczta pochodzi z serwera rozsyłającego spam, na ogół nie jest wysyłana ponownie. Na ogół takie serwery działają tymczasowo w celu uniemożliwienia ich identyfikacji i umieszczeniu w DNSBL. (more…)

Od jakiegoś czasu wśród moich serwerów pojawił się jeden działający w oparciu Plesk postawiony na Debianie. Generalnie jestem zadowolony z tego rozwiązania, ale oczywiście od czasu do czasu napotykam na różne kwiatki (choć rzadko). Jednym z takich kwiatków okazał się PEAR (choć to nie jego wina, tylko Pleska).

W czym rzecz? Ano w tym, że niby mam PEAR, ale nie działa. Tzn. można instalować pakiety, ale za diabła żaden skrypt PHP nie może uzyskać dostępu do plików PEAR. Próba uruchomienia poniższego skryptu

<?php
require ("PEAR.php");
?>

kończy się tak:

Zacząłem więc po kolei sprawdzać w czym rzecz. Najpierw odpaliłem phpinfo().

include_path
PEAR znajduje się w include_path, czyli w /usr/share/php, więc powinno chodzić. No ale nie chodzi.

open_basedir
No to jesteśmy (prawie) w domu. Nadrzędna wartość open_basedir jest OK – zawiera /usr/share/php, ale LOKALNA już nie – i dlatego nie działa.

Rozwiązanie

Trzeba przygotować sobie plik vhost.conf o zawartości analogicznej do poniższej i wgrać go do katalogu /var/www/vhosts/domena.com/conf/. Jest to jedyne rozwiązanie żeby na trwałe zmienić konfigurację dla wybranego vhosta (bo musimy zmienić LOKALNĄ wartość). Broń Boże wprowadzać zmainy w pliku httpd.include!

<Directory /var/www/vhosts/domena.com/httpdocs>
php_admin_flag safe_mode off
php_admin_value open_basedir "/var/www/vhosts/domena.com/httpdocs:/tmp:/usr/share/php"
</Directory>

Na koniec trzeba powiadomić Pleska o tym, że zmieniła się konfiguracja serwera. Robimy to takim poleceniem:

/usr/local/psa/admin/bin/websrvmng -a

Podobno nie trzeba po tym nawet Apache’a restartować, ale bez tego mi nie działało. Dlatego dorzucamy jeszcze to:

/etc/init.d/apache2 restart

I teraz wszystko pięknie hula!