Bekijk Volledige Versie : Patch voor +FollowSymlinks, al iemand met mod_ruid2 getest?
Zoals hier te zien is:
http://www.directadmin.com/forum/showthread.php?t=42332&p=214681#post214681
heeft DA de patch van StevenC/Rack911 in een custombuild update mogelijkheid gebouwd.
Dit gaan er dan straks standaard in.
Zijn er nog dingen hierbij om aan te denken als je mod_ruid2 geinstalleerd hebt? Of anders gewoon voor de zekerheid even mod_ruid2 opnieuw erop zetten?
Verder vraag ik me af of SymLinksIfOwnerMatch hetgeen dan de enigeoptie wordt, hetzelfde kan als FollowSymlinks.
Als je bijv. naar Zen Cart kijkt dan kun je dit tegen komen.
## the following line is needed to allow Download-By-Redirect to work
Options +FollowSymLinks
Werkt die Download-by Redirect ook met die vervanger?
Ik heb recent een nieuwe server geinstalleerd met een verse DA-install waar ik de data van klanten van een andere server naar gekopieerd heb (backup/restore) en aan het aftesten ben alvorens live te gaan. De meeste sites gaan prima, maar bij een aantal grote problemen door deze 'patch' van DA. Van de 553 accounts zijn er zo'n 15 stuks die mis gaan.
Gebruikers hebben bijvoorbeeld in hun .htaccess
Options +FollowSymLinks
Voor ik de patch uitvoerde wilden deze websites niet (meer) draaien en kreeg ik de volgende foutmeldingen in de error log:
/home/gebruikersnaam/public_html/.htaccess: Option FollowSymLinks not allowed here
Na de fix:
/home/gebruikersnaam/public_html/.htaccess: Options not allowed here
Op het DA-forum gezien dat sommigen dan custom httpd bestanden gaat aanmaken (AllowOverride All invoegen), maar dat lost het probleem niet op. Van één van de goeroes op dat forum las ik dat hij het probleem naar de gebruikers verschuift onder het motto "dat werkt niet meer, los het maar op" maar zo ga ik niet met m'n klanten om.
Ik heb contact met één van de contributers van Custombuild, en hoop dat hij weet hoe dit opgelost kan worden maar wat mij betreft is deze patch dus niet oke. Ben blij dat ik dit niet op een productiemachine heb, ...
-----
Dat als reactie maar ook als vraag eigenlijk, afgeleid hiervan: heeft iemand anders dit ook meegemaakt en eventueel een oplossing er voor? Want kennelijk is het nu dus al 'default' in DA opgenomen (slechte zaak!) met als gevolg dat sites niet meer werken.
dennis0162
12/02/12, 15:13
Perl scriptje maken dat Options +FollowSymLinks weg haalt uit alle .htaccess bestanden?
Klopt, ik heb het na een test op een testmachine dus wel op een aantal productieservers gedaan en geen problemen gehad.
In de thread bij DA die over deze patch gaat, staat ook een scriptje wat er voor zorgt dat alle +FollowSymlinks vervangt door SymLinksIfOwnerMatch in de .htaccess bestanden.
Vooralsnog ben ik er geen problemen mee tegen gekomen.
Als je 'm weghaalt werken sommige sites niet meer, als je 'm vervangt door SymLinksIfOwnerMatch
Dan krijg je dus deze error bij sommige sites (zoals ik eerder ook aangaf):
/home/gebruikersnaam/public_html/.htaccess: Options not allowed here
Ik heb een aantal sites die compleet niet meer werken. Gelukkig (nog) geen productieserver... had 'm wel graag vandaag online gebracht, maar helaas. Het gebeurt vooral bij websites die ofwel geheel custom gebouwd zijn door klanten ofwel (in sommige gevallen) door/met Installatron geïnstalleerd zijn.
DA had deze 'patch' niet moeten doen, want het is gewoon standaard Apache gedrag waar ze nu op ingrijpen, mijns inziens.
dennis0162
12/02/12, 16:48
Je kan het eventueel aanpassen maar ik zou het zo laten staan.
File: /etc/httpd/conf/extra/httpd-directories.conf
<Directory /home>
AllowOverride all
#AllowOverride AuthConfig FileInfo Indexes Limit Options=Includes,IncludesNOEXEC,Indexes,ExecCGI,Mu ltiViews,SymLinksIfOwnerMatch,None
Options IncludesNoExec Includes SymLinksIfOwnerMatch ExecCGI
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Als er komt te staan Options not allowed here, denk ik dat de optie in de apache conf geblokkeerd wordt, ik heb er geen last van.
Controleer dit eens in je /etc/httpd/conf/extra/httpd-directories.conf daar zou nu onderaan dit moeten staan:
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit Indexes
Options -MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Als dat wat ik vet heb gemaakt nog steeds op Followsymlinks staat, is de foutmelding die jij nog krijgt te verwachten.
DA had deze 'patch' niet moeten doen, want het is gewoon standaard Apache gedrag waar ze nu op ingrijpen, mijns inziens.
Dat zie ik anders, het is toch een beveiligingsprobleem wat gefixed wordt.
En als je er geen gebruik van wilt maken kun je het bij mijn weten gewoon in de options.conf uitzetten.
Edit: Ah, net tegelijk aan het schrijven geweest met Dennis zie ik.
Hier geen enkele problemen ondervonden met de patch. Heb je secure_htaccess toevallig op yes staan/gezet? Als je deze post (http://www.directadmin.com/forum/showthread.php?t=42332&p=214681#post214681) bekijkt is dat niet nodig wat betreft de veiligheid.
This will allow the secure_htaccess option to be set to "no" (old httpd config setup), but still solve the linking issue with regards to security.
Once testing is under the belt for this patch, we'll set secure_htaccess=no as the default, and harden-symlinks-patch=yes as the default.
Heb hier alleen wat rechten van wat symlinks aan moeten passen omdat die niet meer werkten na de patch. +FollowSymLinks etc in htaccess geen probleem.
@Blacky - helaas, het staat er idd netjes in. Heb van pure ergernis de installatie overnieuw gedaan, nogmaals alles netjes bij gewerkt en hop,... weer hetzelfde probleem. Standaard install is, voorzover ik het nu begrijp, inclusief deze 'patch'.
@Arieh - ben ik niet met je eens, als dit een issue is (en ja, dat is het wel tot op zekere hoogte) dan moet dat door Apache aangepakt worden en niet 'gepached' in het CP. Maar da's een wellus-nietus discussie vrees ik :)
Ik wacht nog op de reactie van de custombuild contributer. Hij liet me al even kort weten dat het snel te fixen is. Dus,... ben benieuwd (en als dat zo is zal ik de fix hier ook plaatsen).
dennis0162
12/02/12, 21:36
Als je het snel wilt fixen staat toch in mijn post hierboven? Of lukt het daar ook niet mee?
dan moet dat door Apache aangepakt worden en niet 'gepached' in het CP.
Dat ben ik wel met je eens. Ik weet niet of dat al v.w.b. Apache zelf al gebeurt is, maar voor Cpanel heb je precies hetzelfde al.
Daar kun je deze optie ook gewoon uit of aanzetten via het controlepaneel net zoals in DA bij de options.conf.
Als apache niet snel genoeg is met beveiligen zul je voor je klanten, ook als controlepaneel, iets moeten doen. De beste oplossing is dan een fix te maken waarvan de gebruiker zelf kan kiezen of hij hem wenst te gebruiken of niet.
Omdat niet gebruiken onveilig is, is het standaard activeren van de patch een logische keuze.
Als je het snel wilt fixen staat toch in mijn post hierboven? Of lukt het daar ook niet mee?
Nee, helaas...
Probleem blijft bestaan.
Foutmelding in de errorlog blijft
/home/gebruiker/public_html/.htaccess: Options not allowed here
Omdat niet gebruiken onveilig is, is het standaard activeren van de patch een logische keuze.
Nou,... niet als VPS-gebruikers denken "heeeee een update", het installeren en vervolgens vinden dat jij de ellende die er uit voortvloeit mag gaan oplossen - gelukkig liep ik er zelf eerst tegenaan op een machine die nog niet productie draait.
Nou,... niet als VPS-gebruikers denken "heeeee een update"
Dat is dan ook niet het geval. Bij nieuwe installatie staat het standaard aan. Bij bestaande installaties gaat het niet aangepast worden.
Bij een reeds bestaande productiemachine die wel geupdate is staat wel de optie erbij maar niet actief:
harden-symlinks-patch=no
In mijn geval symlinkt httpd-directories.conf -> httpd-directories-old.conf.
Als ik in httpd-directories-old.conf op de betreffende server dit aanpas:
<Directory /home/*/public_html>
# AllowOverride FileInfo AuthConfig Limit Indexes
AllowOverride All
Options -MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Oftewel de "AllowOverride FileInfo AuthConfig Limit Indexes" weghaal en "AllowOverride All" gebruik. Maar volgens mij ben je dan weer terug bij af... Dit is het enige dat, na veel experimenteren, zoeken en lezen op het DA-forum, werkt. Op deze specifieke, vers geïnstalleerde, server.
Ik geloof dat ik niet echt blij wordt van deze situatie.
@Dennis0162 - jouw oplossing was dus heel dicht bij de waarheid :) Je hebt me uiteindelijk wel op het spoor gezet hiervoor.
Conclusie - nav de originele post van TS: het is kennelijk toch niet een patch die je zomaar moet uitvoeren en ook is de nieuwste DA-versie (die default dit heeft aanstaan) wat mij betreft een problematische release.
dennis0162
13/02/12, 12:23
Mooi dat het opgelost is. Ook even uitzetten in de custombuild, anders heb je het bij de volgende update weer aan staan.
Mooi dat het opgelost is. Ook even uitzetten in de custombuild, anders heb je het bij de volgende update weer aan staan.
Ja! Wat denk je, die staat uit :) !
Nou opgelost is het feitelijk niet, Brinkie heeft op deze manier de patch ongedaan gemaakt, hij heeft de gepatchte files ook gewoon verkeerd staan want....
In mijn geval symlinkt httpd-directories.conf -> httpd-directories-old.conf.
Bij mij ook, en bij mij staat dus in die httpd-directories-old.conf wel degelijk de vervanging naar SymlinksifOwnerMatch vermeld zoals ik vetgedrukt aangaf in mijn quote.
Dat betekent dus dat op een of andere wijze de patch niet volledig is uitgevoerd, anders had dat bij Brinkie ook in de post gestaan.
Apart verhaal.
Enige wat de patch doet is FollowSymLinks ombouwen naar SymLinksIfOwnerMatch in de apache broncode voor het compilen.
Wat secure_htaccess op yes zetten doet is -new gebruiken, uitgeschakeld wordt -old gesymlnikt.
Als je -old gebruikt en die fouten oplevert klopt er ergens iets niet, zonder patch of met patch; FollowSymLinks behoort dan gewoon te werken? Of ik mis iets.
dennis0162
13/02/12, 18:39
Klopt, ik denk dat hij de Symlink heeft verwijderd en daarom niet meer naar -new of -old wijst.
En daarom beide ook niet meer werkte bij hem.
Er zal iets anders fout moeten zijn gegaan want in bericht nr. #15 van hem schrijft ie nog dat de symlink er is en naar old verwijst (net zoals bij ons overigens).
Maar ergens moet iets fout zijn gegaan want bij anderen werkt het wel allemaal goed zo te lezen.
Heren - dat er iets fout is, is duidelijk. Maar wat er fout is/gaat is mij volstrekt onduidelijk ik heb gewoon conform de aanwijzingen van DA gewerkt (via de aanwijzingen in de knowledgebase). Ben nog in overleg met de custombuild contributor, want die begrijpt ook niet hoe het kan.
Misschien zit er toch nog een verschilletje tussen de aanwijzingen in de knowledgebase en de aanwijzingen die DA Administrator origineel in de betreffende thread op het forum heeft gegeven.
Ik hoop dat jullie er uit komen want als er inderdaad ergens een verschil of een foutje zit, wat dit probleem zou kunnen veroorzaken is het wel belangrijk dat het opgelost wordt.
Dus mochten jullie er t.z.t. uit komen, hoor ik het graag alhier. Succes alvast!
Dus samenvattend, wat moet ik nu doen om +FollowSymLinks snel werkend te krijgen voor 1 user?
Ik zat in hetzelfde schuitje. Nieuwe server geïnstalleerd, users verplaatst, nameservers gewijzigd, en gezeik!
Heb overal de +FollowSymLinks er gelijk uit geknipt met bash, maar 1 klant heeft nu klachten over zijn Drupal installatie..
Misschien ook leuk om even aan te geven hoe je het gefixed hebt voor als hier iemand weer eens tegenaan loopt.;)
Wij hebben hier de nieuwe versie draaien met mod_ruid2.
Werkt perfect.
Echter gaan installaties als drupal en wordpress miepen.
Wat we daar hebben gedaan is +followsymlinks vervangen voor: +SymLinksIfOwnerMatch.
En toen waren hier alle problemen verholpen.
Zo hebben wij dat ook gedaan. Ben benieuwd of Keizer dezelfde oplossing had.
Ben ook wel benieuwd hoe Keizer dat dan gedaan heeft want in ons geval werkte +followsymlinks vervangen voor +SymLinksIfOwnerMatch dus niet. Ik blijf in bepaalde gevallen problemen houden en kan dit alleen oplossen door de eerder aangegeven "oplossing" ..
Nou mijn fix is volgens mij geen fix zoals jullie hem willen zien, vandaar dat ik hem niet gepost heb :)
./build secure-htaccess no
in combinatie met
Options +SymLinksIfOwnerMatch