Bekijk Volledige Versie : Belangrijke bug in DA 1.43 met mod_ruid2!
Er zit een bug in Directadmin 1.43 die voor problemen kan zorgen als je mod_ruid(2) gebruikt.
Het blijkt dat dit stukje niet meer naar de users httpd.conf gecopieerd wordt:
<IfModule mod_ruid2.c>
RMode config
RUidGid user user
RGroups apache access
</IfModule>
Ik dacht zelf eerst iets fout gedaan te hebben maar heb het zojuist op 2 andere servers getest waar mod_ruid goed op draait. Het euvel doet zich dus voor met zowel mod_ruid2 0.9.7 alsook 0.9.8 en het probleem ligt aan DA.
Nadeel hiervan is dat indien er webscripts nu iets naar de servers schrijven, dit als "apache:access" gebeurt i.p.v. als "user:user". Het is me niet bekend in hoeverre dit invloed kan hebben op betalingsscripts, webshops etc. maar het lijkt me niet wenselijk.
Het euvel doet zich alleen voor als er een nieuw domein aangemaakt wordt. Dan wordt dus de httpd.conf van de user overschreven en de bovenstaande code voor al zijn domeinen staat er dan niet meer in.
Hetzelfde doet zich dus ook voor als je de configs gaat rebuilden.
DA support is hiervan al per email op de hoogte gebracht.
dennis0162
25/03/13, 09:25
Dat is geen bug, het is de bedoeling dat je mod_ruid via Custombuild 2.0 installeert.
Er staat nu in de templates:
|*if HAVE_RUID2="1"|
<IfModule mod_ruid2.c>
RMode config
RUidGid |USER| |GROUP|
RGroups apache |SECURE_ACCESS_GROUP|
</IfModule>
|*endif|
Wat je kan doen is de templates naar de map custom kopiëren en dan if er tussen uit halen.
Handig is anders, aangezien veel installaties rekenden op dat ruid regels al in de default configs zaten. Nu is het een if om een if, nergens voor nodig lijkt mij.
Het is wel degelijk een bug. Custombuild 2.0 is nog in beta en ik heb Custombuild 1.2 draaien zoals velen.
John heeft ook per email bevestigt dat het een fout is die er waarschijnlijk in geslopen is vanwege de wijzigingen voor Custombuild 2.0 en dat er naar gekeken wordt.
Ik ga er dus ook van uit dat er een fix komt voor de custombuild 1.2 gebruikers.
Ik heb net de fix gezien op DA, dat komt daar ook ongeveer op neer. Alleen dan die "if have ruid2=1" en de endif daarvan moet weg. Maar ik vraag me af waarom ze het niet origineel gelaten hebben of beter gedaan.
Daarnaast weten er een hoop dit nu niet. En je zult ook de files weer moeten restoren naar user:user want er zullen vast scripts zijn die inmiddels bestanden naar apache:access hebben gewijzigd.
Immers, sinds de update naar DA 1.43 draait apache gewoon als apache user, niet meer als de gebruiker.
Heb je een beetje veel servers wordt dit dus veel handmatig werk, hetgeen niet nodig zou moeten zijn, daarom ben ik ook niet gecharmeerd van deze workaround, want een fix is het niet.
dennis0162
25/03/13, 15:51
Met wat find regeltjes kan je alles goed chownen.
Het is ook wel aan te raden om de werking van mod_ruid en een hoop andere dingen te testen na de installatie.
Na installatie, logisch ja, maar het werkte goed en was getest.
Maar testen jullie dan ook na elke DA update de werking van mod_ruid?
En ik weet dat het met wat regeltjes goed te chownen is, maar het zou niet nodig hoeven zijn. Je krijgt nu door een foute in een DA update een boel handmatig werk. Zijn toch 4 templates en die chown regels die je voor elke server moet gaan uitvoeren.
@Dennis: Met nakijken na de update had je het vermoedelijk ook niet gezien aangezien het probleem zich pas ging voordoen bij het aanmaken van een nieuw domein of het rewriten van alle configs.
Er is inmiddels een fix uitgekomen:
http://www.directadmin.com/features.php?id=1438
Straks staan de pre-release binaries er op en kan dat gebruikt worden, anders zit dit in een nieuwe DA update als die uit komt.
dennis0162
26/03/13, 15:25
Daar heb je gelijk in; ik ging even uit van een nieuw systeem.
Ik gebruik hier gelukkig custom templates (gebruik niet die van PCextreme bij subdomeinnamen zit er een bug in).
Custom templates? Die heb je toch al een tijdlang niet meer nodig sinds de ifmodule voor mod_ruid2 standaard verwerkt zit in de DA templates? Of heb je er nog een andere reden voor?
Custom templates? Die heb je toch al een tijdlang niet meer nodig sinds de ifmodule voor mod_ruid2 standaard verwerkt zit in de DA templates? Of heb je er nog een andere reden voor?
Wij gebruiken het aangezien we niet op een bepaald IP voor een bepaalde site op poort 80 willen luisteren. Het is met name een design keuze bij ons.
dennis0162
26/03/13, 16:47
Custom templates? Die heb je toch al een tijdlang niet meer nodig sinds de ifmodule voor mod_ruid2 standaard verwerkt zit in de DA templates? Of heb je er nog een andere reden voor?
Klopt, maar er zitten nog wat custom dingen in op sommige servers vandaar.
Custom templates? Die heb je toch al een tijdlang niet meer nodig
Ik verhuur nogal wat niet-standaard dingen en daar zijn ze nog steeds heel handig voor.
Ja oke, als er wat zaken niet-standaard danwel custom gebruikt worden is dit wel weer logisch te noemen.
Ik heb dit probleem ook gehad met mijn DA 1.43 server en heb het als volgt opgelost.
- Pre release binaries installeren, hiermee is het voor de nieuwe users sowieso opgelost
- Alle users waarbij het fout gegaan is suspenden en daarna weer unsuspenden, zo maakt hij een nieuwe httpd.conf voor de users aan
Dit is neem ik aan toch een goede oplossing?
Yourwebhoster
29/03/13, 08:07
- Alle users waarbij het fout gegaan is suspenden en daarna weer unsuspenden, zo maakt hij een nieuwe httpd.conf voor de users aan
Dit is een handigere oplossing:
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq #rewrite httpd configs
/usr/local/directadmin/dataskq #herstart httpd, DirectAdmin doet dit nooit direct met de vorige tally.
Hiermee voer je een rewrite voor alle gebruikers uit.
Ik had overigens in mijn reactie ook al geschreven dat je de pre-release binaries kon gebruiken.:)
De echo regel die yourwebhoster schrijft, wordt ook aangegeven in de help sectie van DA bij de handleiding voor installatie van pre-release binaries.
Degenen die geen lifetime license hebben en dus geen prerelease binaries kunnen gebruiken, kunnen in elk geval de oplossing met het kopiëren van de virtual_host2 files gebruiken.
brammetjeh
23/04/13, 20:42
Bedankt mensen dit werk prima om het probleem te verhelpen. Echter na dit gedaan te hebben is mijn multiserver setup niet meer opearationeel.
Krijg de melding : Unable to get api result. Check your configuration options
Dit was voor de update nog niet zo. Dit schijnt iets te maken te hebben met api_with_password= in de user.conf
Volgens de debug mode zou deze op =no staan maar wanneer ik in /usr/local/directadmin/data/users/admin/user.conf kijk staat deze gewoon op =yes
Dus wie kan me helpen. Hopenlijk krijg ik mn multi setup weer omhoog.
Firewall en dergelijke heb ik allemaal goed staan... het probleem doet zich alleen voor na de update. zelfs wanneer ik downgrade maakt ie weer prima connectie.
Yourwebhoster
23/04/13, 21:31
Probeer met nano of vi wat je had te verwijderen en voer het opnieuw in. Dit heeft te maken met een encoding probleem die kan optreden als je het met de browser aanpast. Daarna even da herstarten.
brammetjeh
23/04/13, 21:54
Ik heb nano gebruikt voor alle eventuele wijzigingen.
Verder staat de admin (user.conf) standaard op api_with_password=yes dus goed alleen geeft de deboug mode anders aan
Volgens de debug mode zou deze op =no staan maar wanneer ik in /usr/local/directadmin/data/users/admin/user.conf kijk staat deze gewoon op =yes
Dat ziet er naar uit alsof DA zich verslikt heeft, dat had ik laatst ook met php. Die stond op ON terwijl Debug vond dat ie op OFF stond, dat heb ik toen opgelost door het uit te schakelen, opslaan en weer aan te zetten.
Ik denk dat je in jouw situatie het snelst geholpen bent door even de multi setup uit te schakelen en weer aan te schakelen, of als dat niet werkt, even de multi setup te verwijderen en daarna opnieuw aan te maken.
brammetjeh
24/04/13, 11:33
Helaas heb ik dit ook al geporbeerd maar gaat niet goed dus de situatie blijft onveranderd.
Iemand een idee of de zelfde ervaring?