Onverklaarbaar Apache/PHP verschil tussen Debian en Ubuntu

[Verwijderd]

Ik ben gisteravond tegen een raar probleem aangelopen met een LAMP installatie bij Ubuntu en Debian.

Ik heb een kleine testsite draaien op een Ubuntu LAMP server, dit werkt allemaal prima in combinatie met mod_rewrite rules.

Nu heb een verse installatie van Debian Etch gedaan, ook een LAMP installatie met mod_rewrite waarbij mijn script ineens in een oneindige lus raakt.

Ik heb nog niet kunnen achterhalen via errorlogs waar de fout zit op de Debian installatie, dit wordt niet weergegeven helaas ondanks dat ik de instellingen hiervoor goed heb staan. Onder Ubuntu werkte de errorlogs op een of andere manier ook beter.


Ubuntu draait:

Apache 2.2.8
PHP 5.2.4-2


Debian draait:

Apache 2.2.3
PHP 5.2.0-8


Het zou toch niet mogen kunnen dat een versie verschil dergelijke problemen op kan leveren ? Dat is eigenlijk de vraag die ik heb.

[kalizec]

Heb je je configuratie bestanden al gecontroleerd?
Kun je het script in kwestie misschien opnemen in je topicstart (bij voorkeur in een code-tag).

[Verwijderd]

kalizec schreef op zondag 18 januari 2009 @ 13:44:
Heb je je configuratie bestanden al gecontroleerd?
Kun je het script in kwestie misschien opnemen in je topicstart (bij voorkeur in een code-tag).

MIjn config bestanden zijn in orde, ik heb ze zelfs nog overgescp-t.

Ik kan de code niet includen aangezien het om een complete testsite gaat en ik dus niet kan achterhalen waar de fout optreedt en waarom hij ineens optreedt. Dit lijkt wellicht lastig zoeken naar een oplossing op deze manier maar ik probeer uit te zoeken waarom dit op de Debian install gebeurt en niet op Ubuntu... de code is opzichzelf het probleem niet (als het goed is)

[gertvdijk]

Verwijderd schreef op zondag 18 januari 2009 @ 13:12:
Ik heb nog niet kunnen achterhalen via errorlogs waar de fout zit op de Debian installatie, dit wordt niet weergegeven helaas ondanks dat ik de instellingen hiervoor goed heb staan.

Welke instellingen bedoel je dan? Voor logging van rewrites heb je de RewriteLog directive.

Verwijderd schreef op zondag 18 januari 2009 @ 13:12:
Onder Ubuntu werkte de errorlogs op een of andere manier ook beter.

Loglevel anders?

Verwijderd schreef op zondag 18 januari 2009 @ 13:12:
Ubuntu draait:
Apache 2.2.8
Debian draait:
Apache 2.2.3
Het zou toch niet mogen kunnen dat een versie verschil dergelijke problemen op kan leveren ? Dat is eigenlijk de vraag die ik heb.

Dat versienummer mag inderdaad niets uitmaken. Immers, de documentatie voor mod_rewrite is voor 2.2.x helemaal gelijkgebleven.

Misschien iets stoms: heb je ook de .htaccess file(s) meegekopieerd? Omdat die 'verborgen' zijn vergeet ik die nog wel eens te kopiëren of mee te tarrren.

Verwijderd schreef op zondag 18 januari 2009 @ 13:47:
Ik kan de code niet includen aangezien het om een complete testsite gaat en ik dus niet kan achterhalen waar de fout optreedt en waarom hij ineens optreedt.

que Ik snap even niks van die redenering hier. Maar zonder voorbeelden van je config/script kunnen wij ook niet zoveel natuurlijk.

Verwijderd schreef op zondag 18 januari 2009 @ 13:47:
Dit lijkt wellicht lastig zoeken naar een oplossing op deze manier maar ik probeer uit te zoeken waarom dit op de Debian install gebeurt en niet op Ubuntu... de code is opzichzelf het probleem niet (als het goed is)

Ik zou gewoon gaan debuggen en je niet blindstaren op een verschil tussen de 2.2.3-debian en 2.2.8-ubuntu. Misschien heb je wel een deprecated mod_rewrite optie gebruikt waarvan nu opeen de werking stuk is sinds 2.2.6 (ik zeg maar wat).

[ Voor 26% gewijzigd door gertvdijk op 18-01-2009 14:00 ]

[Verwijderd]

gertvdijk schreef op zondag 18 januari 2009 @ 13:56:
[...]

Welke instellingen bedoel je dan? Voor logging van rewrites heb je de RewriteLog directive.

[...]

Loglevel anders?

Staat hetzelfde zover ik weet / kan zien, dat is zo gek.

[...]

Dat versienummer mag inderdaad niets uitmaken. Immers, de documentatie voor mod_rewrite is voor 2.2.x helemaal gelijkgebleven.

Ja, kan daar dus echt niet zitten, tenzij Debian een "bad package" heeft... zoals ik al eerder eens heb meegemaakt.

Misschien iets stoms: heb je ook de .htaccess file(s) meegekopieerd? Omdat die 'verborgen' zijn vergeet ik die nog wel eens te kopiëren of mee te tarrren.

Ja, zeker meegekopieerd anders werkt de hele site niet Ik krijg het gevoel dat mod_rewrite toch anders werkt

[gertvdijk]

Verwijderd schreef op zondag 18 januari 2009 @ 13:59:
Ja, kan daar dus echt niet zitten, tenzij Debian een "bad package" heeft... zoals ik al eerder eens heb meegemaakt.

Geloof me, als Debian een bad package heeft van Apache dan gaan wel heel heel heel veel mensen gillen. Verder controleert het packagemanagement het package op echtheid en daarmee ook op integriteit. Ik draai zelf ook Debian Etch op een paar sites/servers met rewrites (veel) en ik heb nergens last van.
Maar goed, voor de zekerheid:

# md5sum /usr/lib/apache2/modules/mod_rewrite.so
692fcd2cffb7a66f4501803357ccdccf

is de md5sum van mod_rewrite op Version: 2.2.3-4+etch6.

[ Voor 4% gewijzigd door gertvdijk op 18-01-2009 14:04 ]

[Confusion]

Zonder de rewrite rule in kwestie valt er weinig over te zeggen. Bovendien vraag ik me nu af: waarom is de PHP versie relevant volgens jou?

[Verwijderd]

Confusion schreef op zondag 18 januari 2009 @ 14:06:
Zonder de rewrite rule in kwestie valt er weinig over te zeggen. Bovendien vraag ik me nu af: waarom is de PHP versie relevant volgens jou?

Dan zou je ook kunnen zeggen waarom zou het, als het in de rewriterules zit, bij 2.2.3 mis gaan en bij 2.2.8 goed ?

Dat is eigenlijk waar ik op doel.

[gertvdijk]

Verwijderd schreef op zondag 18 januari 2009 @ 14:42:
Dan zou je ook kunnen zeggen waarom zou het, als het in de rewriterules zit, bij 2.2.3 mis gaan en bij 2.2.8 goed ?

Dat is eigenlijk waar ik op doel.

gertvdijk schreef op zondag 18 januari 2009 @ 13:56:
[...] zonder voorbeelden van je config/script kunnen wij ook niet zoveel natuurlijk.

[...]

Ik zou gewoon gaan debuggen en je niet blindstaren op een verschil tussen de 2.2.3-debian en 2.2.8-ubuntu. Misschien heb je wel een deprecated mod_rewrite optie gebruikt waarvan nu opeen de werking stuk is sinds 2.2.6 (ik zeg maar wat).

Soms is het iets heel kleins. Zonder enige concrete voorbeelden van wat je doet kan je van ons natuurlijk ook niks verwachten he.

[Verwijderd]

gertvdijk schreef op zondag 18 januari 2009 @ 14:48:
[...]


[...]

Soms is het iets heel kleins. Zonder enige concrete voorbeelden van wat je doet kan je van ons natuurlijk ook niks verwachten he.

Doe ik ook niet, ik kan me alleen niet voorstellen waarom een stable LAMP moeilijk zou doen wanneer een andere LAMP install geen problemen er mee heeft.

Opzich best waanzin dat een rode auto beter zou rijden dan een witte.

[gertvdijk]

Verwijderd schreef op zondag 18 januari 2009 @ 14:52:
Doe ik ook niet, ik kan me alleen niet voorstellen waarom een stable LAMP moeilijk zou doen wanneer een andere LAMP install geen problemen er mee heeft.

Opzich best waanzin dat een rode auto beter zou rijden dan een witte.

Wat let je dan om beide versies te apt-get source 'en en vervolgens te diffen? Kom je niet veel verder mee vrees ik.
Je hebt gewoon te maken met verschillende upstream versies met ook nog eens in een ander smaakje. Je kan dit soort kleine dingen dan ook wel eens verwachten. Toch denk ik dat het gewoon een verkeerd gebruik is van de RewriteRule directive of tunnelvisie op de verschillen tussen apache2-ubuntu en apache2-debian in plaats van je te concentreren op algemeen debuggen.

[Verwijderd]

Ik kan je verzeker dan het niet bij de rewrite_rule ligt, reden ? Ik kan wat tests uitvoeren zonder enige rewrite rule in .htaccess en zelfs dan krijg ik nog een loop.

Raar probleem dus.

[Kees]

Wat voor een loop krijg je dan? Wordt je de hele tijd geredirect? Staat er dan een hostname oid fout waardoor je script denkt 'hier moet ik niet zijn, stuur maar weg, owh hij komt hier weer terug, stuur maar weg' of is het puur de rewrite rules?
En als je de testsite uit de roelatie neemt en het met een statische file probeert, gaat het dan wel goed?

[Confusion]

Verwijderd schreef op zondag 18 januari 2009 @ 14:42:
Dan zou je ook kunnen zeggen waarom zou het, als het in de rewriterules zit, bij 2.2.3 mis gaan en bij 2.2.8 goed ?

Als je de rewriterule geeft, kunnen we manieren geven waarop dat tot een loop zou leiden (voorzover je die er zelf niet bij geeft). Dan kan je vervolgens nagaan waarom een van die manieren op de ene machine voorkomt en op de ander niet.

Verwijderd schreef op zondag 18 januari 2009 @ 15:08:
Ik kan je verzeker dan het niet bij de rewrite_rule ligt, reden ? Ik kan wat tests uitvoeren zonder enige rewrite rule in .htaccess en zelfs dan krijg ik nog een loop.

Raar probleem dus.

Als je niet komt met de code die in een loop raakt en de bijbehorende Apache config, dan kunnen we je niet helpen. Ik weet nog steeds niet wat PHP er mee te maken heeft.

100 tegen 1 dat het een configuratie issue is.

[Verwijderd]

Kees schreef op zondag 18 januari 2009 @ 15:28:
Wat voor een loop krijg je dan? Wordt je de hele tijd geredirect? Staat er dan een hostname oid fout waardoor je script denkt 'hier moet ik niet zijn, stuur maar weg, owh hij komt hier weer terug, stuur maar weg' of is het puur de rewrite rules?
En als je de testsite uit de roelatie neemt en het met een statische file probeert, gaat het dan wel goed?

Statische file werkt prima, ik ga nog even wat met hostnames en document roots testen, het blijft vaag.

Confusion schreef op zondag 18 januari 2009 @ 15:32:
[...]

Als je de rewriterule geeft, kunnen we manieren geven waarop dat tot een loop zou leiden (voorzover je die er zelf niet bij geeft). Dan kan je vervolgens nagaan waarom een van die manieren op de ene machine voorkomt en op de ander niet.


[...]

Als je niet komt met de code die in een loop raakt en de bijbehorende Apache config, dan kunnen we je niet helpen. Ik weet nog steeds niet wat PHP er mee te maken heeft.

100 tegen 1 dat het een configuratie issue is.

Het heeft toch weinig zin een een rewrite_rule te geven wanneer het probleem blijft optreden als ik de hele rewrite_rule(s) weghaal ??

[Confusion]

Verwijderd schreef op zondag 18 januari 2009 @ 15:45:
Het heeft toch weinig zin een een rewrite_rule te geven wanneer het probleem blijft optreden als ik de hele rewrite_rule(s) weghaal ??

Dan moet je dus andere relevante configuratie informatie geven. We zijn niet helderziend en, zoals ik al zei: honderd tegen 1 dat het een configuratie issue is.

[ Voor 13% gewijzigd door Confusion op 18-01-2009 15:49 ]

[gertvdijk]

Confusion schreef op zondag 18 januari 2009 @ 15:47:
Dan moet je dus andere relevante configuratie informatie geven. We zijn niet helderziend en, zoals ik al zei: honderd tegen 1 dat het een configuratie issue is.

Inderdaad. Als je het topic zelf al de titel geeft "Onverklaarbaar..." en zelf geen relevante informatie verschaft dan is het voor iedereen die dit leest nog veel onverklaarbaarder.

[Verwijderd]

Confusion schreef op zondag 18 januari 2009 @ 15:47:
[...]

Dan moet je dus andere relevante configuratie informatie geven. We zijn niet helderziend en, zoals ik al zei: honderd tegen 1 dat het een configuratie issue is.

Maar vind je dat dan zelf niet een beetje vaag "100 tegen 1 dat het een configuratie issue is" ? Lijkt me vrij duidelijk dat er ergens in dat stuk iets niet goed gaat, beetje makkelijk gokken dus.

De php.ini is al overgekopieerd om te testen, geen sjoegen. De mod_rewrite eruit.. zelfde issue.

JIj zegt configuratie ? Ik zeg iets met paths in de app... maar dat moet ik dus even onderzoeken aangezien dat opzich ook een stukje pre-configuratie is.

[Confusion]

Verwijderd schreef op zondag 18 januari 2009 @ 15:54:
JIj zegt configuratie ? Ik zeg iets met paths in de app... maar dat moet ik dus even onderzoeken aangezien dat opzich ook een stukje pre-configuratie is.

Precies, dat is dus ook een configuratie issue. Als je niet post wat er in dat script gebeurt aan redirects of wat dan ook en niet post hoe je Apache zijn paden resolved, dan kunnen we niets. Op dit moment is niet eens duidelijk of het hele script niet bereikt wordt (door bijvoorbeeld, zoals Kees beschreef, een voortdurende redirect door Apache) of dat je in dat script iets hebt staan waardoor telkens datzelfde script wordt aangeroepen.

[Verwijderd]

Het blijk in een query te zitten welke niet werkt op MySQL 5.0.32 (DEBIAN) en wel werkt op MySQL 5.0.51a (UBUNTU).

Door dit soort redenen zou je bijna Ubuntu runnen als productieserver... net even iets meer op de fixes gericht.

Ik weet dat er wat optimizers gefixt zijn tussen deze versies... zou er mee te maken kunnen hebben na wat babbelen met de MySQL devvers.

[gertvdijk]

Verwijderd schreef op maandag 19 januari 2009 @ 01:55:
Het blijk in een query te zitten welke niet werkt op MySQL 5.0.32 (DEBIAN) en wel werkt op MySQL 5.0.51a (UBUNTU).

Door dit soort redenen zou je bijna Ubuntu runnen als productieserver... net even iets meer op de fixes gericht.

Ahum.
Debian stable (Etch atm) is érg stable. Véél minder bugs dan een gemiddelde 'stable' Ubuntu release. En ja, versies blijven zoals die blijven en alleen bugs worden terug 'geport' naar die stable versie. Dat heeft zo zijn redenen.
Ik durf te wedden dat jouw query dus niet helemaal jofel is of expliciet features gebruikt uit >5.0.32. Daarnaast is de code om de query niet zuiver als je webserver daarmee in een oneindige loop raakt.

[Verwijderd]

gertvdijk schreef op maandag 19 januari 2009 @ 02:08:
[...]

Ahum.
Debian stable (Etch atm) is érg stable. Véél minder bugs dan een gemiddelde 'stable' Ubuntu release. En ja, versies blijven zoals die blijven en alleen bugs worden terug 'geport' naar die stable versie. Dat heeft zo zijn redenen.
Ik durf te wedden dat jouw query dus niet helemaal jofel is of expliciet features gebruikt uit >5.0.32. Daarnaast is de code om de query niet zuiver als je webserver daarmee in een oneindige loop raakt.

Deze bug zit er blijkbaar (volgens wat MySQL mensen) al een tijdje in. Moet dat dat in testing voor maanden voordat hij er eindelijk een keer in mag ?

Ik ben het met je Ubuntu visie echt totaal niet eens... Ubuntu is zeer stabiel en flexibeler dan Debian omdat het gewoon nieuwere packages heeft.

About the query... Gaat hierom: SeeniX in "[MySQL] SQL join doormiddel van referenc..."

Dit query leek me ook helemaal niet gek hoor !!

[gertvdijk]

Verwijderd schreef op maandag 19 januari 2009 @ 02:45:
Deze bug zit er blijkbaar (volgens wat MySQL mensen) al een tijdje in. Moet dat dat in testing voor maanden voordat hij er eindelijk een keer in mag ?

Mag ik er dan ook een bugreport bij? Dergelijke bugs worden wel degelijk gefixt. Bijvoorbeeld:

mysql-dfsg-5.0 (5.0.32-5)
Backported upstream patch for a bug that crashed the server when using certain join/group/limit combinations.

Verwijderd schreef op maandag 19 januari 2009 @ 02:45:
Ik ben het met je Ubuntu visie echt totaal niet eens... Ubuntu is zeer stabiel en flexibeler dan Debian omdat het gewoon nieuwere packages heeft.

Nieuwere packages betekent per definitie dat het minder is getest en dat er meer features in zitten die dus potentie hebben op nog meer bugs en compatibility issues. Het is niet voor niks dat iets een tijdje blijft hangen in unstable en later nog in testing totdat de kinderziekten eruit zijn. Debian stable is overigens wel een extreem voorbeeld van wat je noemt 'stable'.

Verwijderd schreef op maandag 19 januari 2009 @ 02:45:
About the query... Gaat hierom: SeeniX in "[MySQL] SQL join doormiddel van referenc..."

Dit query leek me ook helemaal niet gek hoor !!

Als zo'n relatief eenvoudige query de MySQL server op z'n gat laat gaan dan is dat een serious bug waard op bugs.debian.org en weet ik zeker dat iemand anders dit allang voor je had gevonden.
Hoe dan ook, dit verklaart nog helemaal niet waarom je webserver je blijft redirecten in een loop.

[ Voor 3% gewijzigd door gertvdijk op 19-01-2009 03:03 ]

[Verwijderd]

gertvdijk schreef op maandag 19 januari 2009 @ 02:56:

Als zo'n relatief eenvoudige query de MySQL server op z'n gat laat gaan dan is dat een serious bug waard op bugs.debian.org en weet ik zeker dat iemand anders dit allang voor je had gevonden.
Hoe dan ook, dit verklaart nog helemaal niet waarom je webserver je blijft redirecten in een loop.

Ik vind het een beetje lame om te zeggen dat het probleem alleen bij mij zou kunnen liggen. PHP gaat op zijn gat icm Apache omdat PHP niets met die query kan op MySQL... zo lijkt het momenteel.

Deze bug is niet gebackport, zeker niet ! Ik heb net iemand gesproken welke enterprise repo's draait voor MySQL en mij vertelde dat Debian nog wel even laat wachten voordat ze daar uberhaubt packages vandaan willen halen voor stable.

Je opmerking over extreem stable kan ik zo onderuit halen door te zeggen dat Debian weer niet up-to-date is en ver achter aan het raken is op deze manier. Oud kan dan stable zijn maar wellicht niet meer meekomen met waar het mee zou moeten kunnen komen.

Ubuntu is in dergelijke gevallen gewoon support op te kopen indien het echt spaak loopt, kun je bij Debian weer een of andere consultant in huren die hetzelfde gaat doen als je zelf al deed.

It's all about choises.

[ Voor 3% gewijzigd door Verwijderd op 19-01-2009 03:10 ]

[gertvdijk]

Verwijderd schreef op maandag 19 januari 2009 @ 03:10:
Ik vind het een beetje lame om te zeggen dat het probleem alleen bij mij zou kunnen liggen. PHP gaat op zijn gat icm Apache omdat PHP niets met die query kan op MySQL... zo lijkt het momenteel.

Ik zeg niet dat het alleen aan jou ligt. Enige wat ik je duidelijk probeer te maken is dat je geen enkele of niet werkende vorm van error handling hebt blijkbaar. Verder blijft alles voor iedereen hier gissen, omdat je niet met concrete en relevante informatie komt.

Verwijderd schreef op maandag 19 januari 2009 @ 03:10:
Deze bug is niet gebackport, zeker niet ! Ik heb net iemand gesproken welke enterprise repo's draait voor MySQL en mij vertelde dat Debian nog wel even laat wachten voordat ze daar uberhaubt packages vandaan willen halen voor stable.

Again, niet concreet, geen bron.

Verwijderd schreef op maandag 19 januari 2009 @ 03:10:
Je opmerking over extreem stable kan ik zo onderuit halen door te zeggen dat Debian weer niet up-to-date is en ver achter aan het raken is op deze manier. Oud kan dan stable zijn maar wellicht niet meer meekomen met waar het mee zou moeten kunnen komen.

Ik zeg helemaal niet dat oud stabieler is. De laatste update voor 5.0.32 in debian is van Sun, 2 Nov 2008 22:59:32. Door het beleid van Debian strak door te voeren krijg je wel degelijk een stabieler systeem. Je weet immers waar je aan toe bent (main versienummer en dus features blijven gelijk) en developers hebben de tijd om bugreports te verwerken.

Verwijderd schreef op maandag 19 januari 2009 @ 03:10:
Ubuntu is in dergelijke gevallen gewoon support op te kopen indien het echt spaak loopt, kun je bij Debian weer een of andere consultant in huren die hetzelfde gaat doen als je zelf al deed.

Die Canonical support engineer gaat je heus niet verder kunnen helpen als je net zo weinig informatie geeft als je hier doet...

Verwijderd schreef op maandag 19 januari 2009 @ 03:10:
It's all about choises.

Ja, misschien kan jij dus beter een distro pakken die rolling releast. Dan krijg je dus at random ineens nieuwe versies waarin een bug kan zitten die je in veel grotere problemen kan brengen...

[Confusion]

Verwijderd schreef op maandag 19 januari 2009 @ 01:55:
Het blijk in een query te zitten welke niet werkt op MySQL 5.0.32 (DEBIAN) en wel werkt op MySQL 5.0.51a (UBUNTU).

Dan is de vraag: wat ga je de volgende keer dat je een topic start over een probleem anders doen?

Door dit soort redenen zou je bijna Ubuntu runnen als productieserver... net even iets meer op de fixes gericht.

Nieuwe versies != fixes. Nieuwere versies introduceren nieuwe bugs, wat de reden is waarom Debian Stable geen nieuwere versies doorvoert en hooguit bugfixes backport.

Ik ben nu inmiddels wel vrij benieuwd naar die query.