This is an old revision of the document!
ISPConfig + PHP-FPM + aplikacije (DokuWiki, WordPress, …) 🎯 Namen dokumenta
Ta dokument opisuje:
zakaj pride do “permission” napak, čeprav so pravice pravilne
kako pravilno namestiti PHP aplikacije na ISPConfig
kako preprečiti ponavljanje istih napak pri novih straneh
Velja za:
DokuWiki
WordPress
Nextcloud
Laravel / Symfony
vse PHP aplikacije na ISPConfig + PHP-FPM
1️⃣ Povzetek problema (TL;DR)
Če uporabljaš:
ISPConfig
PHP-FPM
Apache ali Nginx
⚠️ NE SMEŠ uporabljati absolutnih poti v aplikacijskih konfiguracijah, npr.:
/var/www/clients/clientX/webY/web/…
Če to narediš, bo:
CLI kazal, da je vse OK
PHP is_writable() kazal OK
aplikacija (installer) pa bo še vedno javljala napake
2️⃣ Root cause (kaj je bilo v resnici narobe) Ključna kombinacija
ISPConfig uporablja open_basedir
PHP-FPM omeji dostop PHP-ja na določene poti
aplikacija (npr. DokuWiki) uporablja absolutne poti
aplikacija interno dela dodatne varnostne checke
➡️ Ti checki padejo, čeprav ima PHP pravice.
To NI klasičen permission problem, ampak:
konflikt med open_basedir in absolutnimi potmi
3️⃣ Tipični simptomi
Če vidiš kaj od tega, je skoraj zagotovo to ta problem:
DokuWiki datadir (pages) is not found or not writable
WordPress
ne more pisati v wp-content/uploads
random “permission denied”, čeprav so pravice pravilne
Splošno
PHP test skripta kaže WRITE=OK
installer ali aplikacija javi napako
po popravku pravic se NIČ ne spremeni
4️⃣ ZLATO PRAVILO (velja za vse aplikacije) ❌ NIKOLI na ISPConfig + PHP-FPM /var/www/clients/client1/web2/web/data
✅ VEDNO
relativne poti
ali poti znotraj document root-a
Primeri:
./data ./uploads ./cache ./files
5️⃣ DokuWiki – pravilna konfiguracija conf/dokuwiki.php $conf['savedir'] = './data'; $conf['basedir'] = '';
❗ Absolutne poti ne uporabljaj.
6️⃣ WordPress – enako pravilo
WordPress večinoma dela pravilno sam, težava nastane, če:
ročno definiraš poti
cache plugin nastavi absolutne poti
❌ Napačno define('WP_CONTENT_DIR', '/var/www/clients/client1/web2/web/wp-content');
✅ Pravilno define('WP_CONTENT_DIR', DIR . '/wp-content');
ali
define('WP_CONTENT_DIR', './wp-content');
7️⃣ Vedno preveri open_basedir (prvi korak) grep -R “open_basedir” /etc/php/*/fpm/pool.d/
Primer:
php_admin_value[open_basedir] = /var/www/clients/client1/web2/web:…
➡️ To pomeni:
PHP vidi samo te poti
aplikacija mora uporabljati relativne poti
8️⃣ Minimalni PHP sanity test (za vsako aplikacijo) sudo -u web2 php -r ' echo “CWD=”.getcwd().PHP_EOL; $path=“./data/pages”; echo “PATH=$path”.PHP_EOL; echo “is_dir=”.(is_dir($path)?“YES”:“NO”).PHP_EOL; echo “writable=”.(is_writable($path)?“YES”:“NO”).PHP_EOL; '
Če dobiš:
is_dir=YES writable=YES
➡️ PHP bo delal ➡️ če aplikacija še vedno jamra → konfiguracija aplikacije je napačna
9️⃣ Zakaj se zdi, da se “vrtimo v krogu”
Ker so bili:
✔ permissions pravilni
✔ owner/group pravilni
✔ PHP-FPM servis aktiven
✔ socket obstajal
Ampak:
❌ aplikacija je uporabljala absolutne poti
❌ open_basedir je to blokiral
To je najbolj zahrbtna napaka, ker:
sistemski admin vidi “vse OK”
aplikacija pa ima svoj varnostni model
🔟 Kako to preprečiti za VSE bodoče strani Priporočena praksa
V glavi vsakega projekta si zapiši:
Če je ISPConfig + PHP-FPM → nikoli absolutne poti v aplikaciji
To velja za:
Wiki
WordPress
Nextcloud
Laravel
Symfony
vse PHP CMS-e
1️⃣1️⃣ Kaj NE priporočam (razen če veš, kaj delaš)
odstranjevanje open_basedir
globalno rahljanje PHP omejitev
❌ slabša varnost ❌ ISPConfig update lahko vse povozi
1️⃣2️⃣ Orodje za prihodnost
Uporabi ali razširi skripto:
isp_dokuwiki_doctor.sh
Ideja:
en skript
preveri:
docroot
open_basedir
writable mape
absolutne poti v configih
➡️ 10 sekund diagnostike namesto 2 ur kroženja.