Bekijk Volledige Versie : Advies SuPHP of Mod_ruid
Hallo Webhostingtalk,
Bij deze wil ik jullie een advies vragen. Ikzelf heb een server die standaard geinstalleerd is met SuPHP. Echter dit brengt uiteraard enkele beperkingen met zich mee:
- URL als http://hostname/~user werken niet meer, als het php-files zijn. Werkt uitsluitend via domeinnamen.
- php_value flag in .htaccess werkt niet meer.
Nu is de server die ik gebruik meer bedoeld voor persoonlijke sites, en geen hostingactiviteiten, dus de kans dat er lek spul op draait zoals oude Joomla's is kleiner dan wat er allemaal op een hostingserver draait.
Nu vraag ik me af, wat is jullie advies in de keuze?
Toen ik op shared hosting-niveau zat met mijn site draaide de server mod_ruid.
En weet iemand of die 2 beperkingen van SuPHP te omzeilen zijn? Of gaat dat tegen het beveiligingsprincipe in?
Jullie advies graag :)...
Het tweede is erg eenvoudig te omzeillen door je php_value's in een apart php.ini te plaatsen. Dat kan met Suphp, en is per account mogelijk.
Het eerste weet ik even zo gauw niet meer.
Yourwebhoster
13/11/09, 11:01
- php_value flag in .htaccess werkt niet meer.
Je kan voor elke gebruiker een aparte php.ini gebruiken waarbij je alle settings kan aanpassen, nadeel is dat dit alleen door de server admin gedaan kan worden maar in dit geval maakt dat niet zo heel veel uit.
eerste lossen wij op door by default ook "domeinnaam.tld.preview.domeintje.be" te configureren. In combinatie met een wildcard dns record werkt dat goed
Je kan voor elke gebruiker een aparte php.ini gebruiken waarbij je alle settings kan aanpassen, nadeel is dat dit alleen door de server admin gedaan kan worden maar in dit geval maakt dat niet zo heel veel uit.
hier en daar een beetje aaien, en je kan zonder problemen de php.ini vanuit de vhost laten oppakken. Of je het wilt is een ander verhaal :)
Je kan voor elke gebruiker een aparte php.ini gebruiken waarbij je alle settings kan aanpassen, nadeel is dat dit alleen door de server admin gedaan kan worden maar in dit geval maakt dat niet zo heel veel uit.
Gewoon een kopie van de bestaande php.ini uit: /usr/local/etc/php5/cgi/php.ini met je wijzigingen ergens plaatsen? Maar waar?
/usr/local/directadmin/data/users/gebruikersnaam/php5
Vervolgens in DA bij Custom HTTPD Configurations > Gebruiker > onderstaande regel toevoegen:
suPHP_ConfigPath /usr/local/directadmin/data/users/gebruikersnaam/php5
Tip: Kijk ook eens in de KB van Directadmin (http://help.directadmin.com/)....
Yourwebhoster
13/11/09, 12:43
Hier heb je een mooi topic over hoe je het kan doen:
http://www.directadmin.com/forum/showthread.php?t=29483
Je kan de stukken overslaan om het om te zetten van cli naar cgi als je het direct als cgi geïnstalleerd heb.
Ik lees dit:
http://help.directadmin.com/item.php?id=176
Waarmee je de Paranoid mode van SuPHP verlaat. Maar is dit niet wat gevaarlijker?
Ga voor mod_ruid. Dit werkt sneller dan suPHP en je hebt geen last van gebruikers die je opnieuw moet opvoeden omdat zij handleidingen volgen, waarin staat dat ze mapjes op 777 moeten zetten, hetgeen bij suPHP meteen een 500-error geeft. Ook cachers werken niet met suPHP.
Over welke cachers heb je het Randy?
Maar aangezien mod_ruid niet meer wordt ontwikkeld, brengt dit geen veiligheidsgaten met zich mee?
Over welke cachers heb je het Randy?
Alle cachers (eaccelerator, APC, xcache etc).
Over welke cachers heb je het Randy?
Maar aangezien mod_ruid niet meer wordt ontwikkeld, brengt dit geen veiligheidsgaten met zich mee?
Cobol is ook zo goed als uitontwikkeld en toch gebruikt iedereen het nog. Het Alfabet heeft al eeuwen geen extra letters gekregen en toch gebruikt iedereen het. Omdat er geen nieuwe versies zijn, wil het niet zeggen dat iets slecht is.
Er zijn nog wel wat ontwikkelingen aan mod_ruid. Kees op dit forum heeft onlangs nog een versie bijgewerkt, waarin nu ook een chroot opgenomen is op /home/$user. Je kunt er zelf overigens prima wijzigingen in aanbrengen. Het zijn een paar regeltjes C. Iedere HBO'er informatieca moet dit kunnen. Dat is het leuke aan open source.
Magento en suPHP gaf hier trouwens wat problemen. Met name na het updaten via Magento Connect. Rechten bleken toch niet altijd geod te staan. Met mod_ruid heb ik hier geen problemen mee. Opcode caching gebruik ik overigens niet. Enkel memcached, waarbij alle sessies ook in het geheugen gaan (globaal op de server, niet specifiek in Magento). EN dat werkt snel (http://www.ispi.eu).
Is DirectAdmin ook goed te combineren met mod_ruid?
Het wordt officeel niet door Direct Admin ondersteund, SuPHP wel.
Voor mod_ruid hoeft er in DirectAdmin geen ondersteuning te zijn, voor suphp wel, vandaar. Mod_ruid werkt prima in combinatie met DirectAdmin en eender welk ander controlpanel.
Is DirectAdmin ook goed te combineren met mod_ruid?
Ja, geheel probleemloos. Het is erg gebruiktvriendelijk, rechtenproblemen behoren daarna vrijwel allemaal tot het verleden.
Ik heb zowel suPHP als mod_ruid gebruikt (de laatste nog in gebruik). SuPHP is echt veel trager en brengt ook complicaties mee voor je DirectAdmin installatie (je moet een CLI binary ernaast houden omdat DirectAdmin dat verwacht).
mod_ruid is veel simpeler van opzet en daarmee veel krachtiger. En hangt ook absoluut niet in de weg van DirectAdmin. Het voordeel is dat alles binnen een vhost onder de user draait, eventuele andere talen die je via mod's in Apache hangt draaien dus ook onder de eigen user (in ieder geval, dat lijkt mij: ik heb het niet getest).
Overigens: als je enkel eigen websites draait, lijkt het mij een beetje overbodig om meerdere gebruikers te hebben. Tenzij je scripts gebruikt die regelmatig lek kunnen zijn of zoiets.
/usr/local/directadmin/data/users/gebruikersnaam/php5
Vervolgens in DA bij Custom HTTPD Configurations > Gebruiker > onderstaande regel toevoegen:
suPHP_ConfigPath /usr/local/directadmin/data/users/gebruikersnaam/php5
Tip: Kijk ook eens in de KB van Directadmin (http://help.directadmin.com/)....
Ik voeg hem toe, met Magic Quotes op Off
Vul bovenstaande regel in in DA Admin bij HTTP Configuration:
suPHP_ConfigPath /usr/local/directadmin/data/users/arien/php5
het pad klopt prima, ik restart httpd (apache) en reload hem zelfs..
Maar phpinfo() op bewuste domain blijft aangeven dat hij op ON staat?
Hoe kan dat?
marsipulami
15/11/09, 14:25
Vind hij wel de extra php.ini? wanneer je phpinfo() doet?
Ik voeg hem toe, met Magic Quotes op Off
Vul bovenstaande regel in in DA Admin bij HTTP Configuration:
suPHP_ConfigPath /usr/local/directadmin/data/users/arien/php5
het pad klopt prima, ik restart httpd (apache) en reload hem zelfs..
Maar phpinfo() op bewuste domain blijft aangeven dat hij op ON staat?
Hoe kan dat?
Heb je wel het juiste domein aangepast?
Wat is het pad naar de php.ini volgens phpinfo?
Edit: Heb je ook je php.ini gekopieerd naar bovenstaande lokatie? (just checking :X)
marsipulami
15/11/09, 18:15
Er even voor het gemak vanuit gaande dat hij de tut die yourwebhoster postte gebruikt heeft zou hij ook voor iedere user een ini aangemaakt moeten hebben :p
Een deel van die howto komt bij ons vandaan; de php.ini die in /usr/local/directadmin/data/users/username/ komt te staan wordt gelezen BOVENOP de andere .ini(s). Je kunt dus alleen de delen plaatsen die je wilt aanpassen.
Ik had inderdaad de volledige php.ini gekopieerd met daarin SuperGlobals uit.
Misschien dat dit het was. De location in phpinfo() bleef zoals het is trouwens.
Inmiddels heb ik de hosting die er meer vanaf weet maar de opdracht gegegeven om mod_ruid te installeren. Die workarounds voor de beperkingen van suPhp vind ik maar niks ;).
Overigens: als je enkel eigen websites draait, lijkt het mij een beetje overbodig om meerdere gebruikers te hebben. Tenzij je scripts gebruikt die regelmatig lek kunnen zijn of zoiets.
Better safe than sorry. :)
De kans op een lek kan dan wel kleiner zijn met enkel eigen websites, toch is het erg vervelend als een lek gelijk alle sites plat kan leggen. Zeker als het met relatief weinig moeite tegen te gaan is (mod_ruid).
Sorry, ben newbie dus misschien domme vraag.
Maar volgens mij zijn al deze workarounds alleen uitvoerbaar als je DA zelf hebt draaien, of niet? Ik heb een vandaag een hostingaccount geactiveerd met suphp en kom er nu achter dat ik niet meer bij de backoffice van mijn afflistore site kan komen (/admin)... :unsure:
Is dit nog op te lossen of moet gewoon op zoek naar een andere provider?
Yourwebhoster
04/12/09, 21:43
Backoffice? Admin gedeelte bedoel je? Weet je zeker dat je alles overgezet hebt en aangepast hebt? En krijg je een fout en zo ja wat?
Controleer anders de logboeken, suphp voert php anders uit en heeft geen direct anders werkende PHP functies. Het kan natuurlijk ook zijn dat een bepaalde PHP module nodig is en niet geladen wordt.
chown -R $user:$user admin/
chmod -R 755 $user:$user admin/
De laatste kan netter, maar dan moet je wat meer switches toepassen. Enkel directorys moeten op 755, files kunnen op 700/711. $user wel vervangen door de juiste gebruiker op je systeem. In de logfiles kun je vinden op welke bestanden het specifiek vaudt gaat :)
Nou ja... ik probeer het ongewizjig nog ene keer en alles doet ut...:o
Zoals ik al zei: newbie he..:whistling:
Wel top om te zien dat er hier snel wordt gereageerd op topics.
bedankt!