Bekijk Volledige Versie : ProFTPd instelling voor owners?
Hoi,
Ik heb sinds kort een dedicated met DA en ProFTPd. Nu werkt alles prima behalve 1 dingetje met schrijfrechten.
Voorbeeldje: Ik kan Joomla uploaden met FTP. Dat gaat prima en alles wat ik zelf via FTP heb geupload kan ik ook aanpassen.
Echter als ik via Joomla (dus via het script) iets installeer dan kan ik er met FTP niks meer mee (niet wijzigen, ook de rechten niet).
Blijkbaar wordt aan alles wat via het script wordt geupload toegewezen aan een andere owner.
Het zal vast een kleine instelling in ProFTPd zijn maar ik kan het niet vinden. Iemand een idee?
Bedankt alvast!!!
Je kan inloggen via SSH en dan chown -R <bestand> <user>
dennis0162
07/02/10, 20:51
Een bestand wat geupload wordt via een PHP script krijgt de user/groep apache mee.
Het bestand kan je aanpassen via SSH chowen chown user:groep bestand.ext of door in te loggen op DirectAdmin en via de file manager de knop "reset owner" gebruiken.
Als je voor goed van deze problemen af wilt moet je mod_ruid installeren. Elke user krijgt haar eigen user en groep, tevens een stuk veiliger.
martinvandebelt
07/02/10, 20:52
Komt omdat het dan onder verschillende users gaat draaien.
Kijk eens naar mod_ruid.
Dank, ik wil er idd gewoon voor altijd vanaf, anders kan ik elke keer als iemand iets in Joomla installeert de boel gaan aanpassen. Ik ga zo even kijken naar mod_ruid!
Dit is inderdaad lastig, de bestanden die via websited aangepast worden zijn van Apache, niet van de user. Via de Filemanager in DirectAdmin kun je de rechten goed zetten (users) of zelf via SSH alles chownen, maar je blijft bezig.
Zet je server om naar suPHP (oud, traag) of mod_ruid zodat apache-processen onder de user draaien in plaats van via de user apache. Je bent dan van deze problemen af. Met mod_ruid hoef je ook nooit meer een bestand '777' rechten te geven omdat apache - en dus php - onder de user draaien en altijd schrijfrechten zullen hebben.
Nou, blijkt dat suPHP er al op stond. Ik heb via Google gezocht naar welke instellingen ik waar moet aanpassen maar kan niks vinden.
Dit staat er in de httpd:
<IfModule mod_suphp.c>
suPHP_Engine On
suPHP_UserGroup webapps webapps
SetEnv PHP_INI_SCAN_DIR
</IfModule>
Ik heb veel gelezen over de voors en tegens van suPHP en mod_ruid, maar omdat suPHP er nou eenmaal al opzit zal ik het hier maar mee moeten doen. Iemand een idee wat ik hier dan moet instellen?
IfModule... Als de module bestaat, dan...
Omdat het in de configuratie staat hoeft het nog niet te zeggen dat suPHP ook daadwerkelijk gebruikt wordt. suPHP raad ik trouwens ook af, het brengt meer problemen dan oplossingen en is ook nog eens relatief traag.
Om te controleren of je suPHP hebt, plaats een php.ini bestand. Onder 'Server API' zie je dan cgi/fastcgi staan voor suPHP, of Apache wanneer je PHP als Apache module gebruikt. (of mod_ruid, maar dat is nu niet het geval en wordt default niet door DirectAdmin ondersteund).
Andere optie is onderstaand commando via SSH:
cat /usr/local/directadmin/custombuild/options.conf | grep php
Dit is wat er staat via de SSH:
#PHP settings. default_php possible values - 4 or 5
default_php=5
php4_cli=no
php4_cgi=no
php5_cli=yes
php5_cgi=no
phpmyadmin=yes
php6_cli=no
php6_cgi=no
php_ini=no
php_ini_type=recommended
Bij de PHP info onder Server API staat:
Server API Apache 2.0 Handler
Zou er dan geen suPHP op staan?
Ik heb in mijn enthousiasme wel deze code gedraaid:
http://help.directadmin.com/item.php?id=176 (http://help.directadmin.com/item.php?id=176)
Kan dat kwaad als er überhaupt geen suPHP op stond?
Bij de PHP info onder Server API staat:
Server API Apache 2.0 Handler
Zou er dan geen suPHP op staan?
Nee, want dan stond er cgi/fastcgi.
suPHP raad ik trouwens ook af, het brengt meer problemen dan oplossingen en is ook nog eens relatief traag.
Noem die problemen dan eens, ik heb al een gehele ruime tijd geen problemen met suPHP.
Dit is wat er staat via de SSH:
#PHP settings. default_php possible values - 4 or 5
default_php=5
php4_cli=no
php4_cgi=no
php5_cli=yes
php5_cgi=no
phpmyadmin=yes
php6_cli=no
php6_cgi=no
php_ini=no
php_ini_type=recommended
Zou er dan geen suPHP op staan?
I.d.d., er draait nog geen suPHP.
marsipulami
08/02/10, 18:16
Noem die problemen dan eens, ik heb al een gehele ruime tijd geen problemen met suPHP.
Daar ben ik dan ook wel benieuwd naar. Draai het tot nu toe zonder problemen
Dan heb ik toch geen suPHP :-) , maar het probleem blijft dat geuploade files (FTP) een andere user hebben dan via Joomla geïnstalleerde files (apache).
Ik ga even verder zoeken op mod_ruid, ik heb daar ondertussen veel goede dingen over gelezen (behalve dan wat problemen die ontstaan ivm phpmyadmin en squirrelmail).
Ik moet toch iets want nu moet ik telkens via DA alle rechten goed zetten als iemand iets installeert.
Ik laat wel even weten wat ik gedaan heb!
Don't mess up :lovewht:
Een andere optie die je kunt gebruiken zijn access-groups met de standaard PHP-instellingen. Hier weet ik eigenlijk te weinig van. Misschien dat Wouter meeleest?
Noem die problemen dan eens, ik heb al een gehele ruime tijd geen problemen met suPHP.
Zie de bijlage. v0.1ß
Geen zin om verder de typgeit uit te hangen. Lunchtime nu.