Apache start niet meer na upgrade van PHP

[Verwijderd]

Hallo,

Net probeerde ik php up te graden naar 5.3.1. Alleen krijg ik nu zodra ik apache opstart de volgende foutmelding:

httpd: Syntax error on line 54 of /etc/apache/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: lo_import_with_oid

Het lijkt te liggen aan postgresql. Zodra ik php compileer zonder postgresql is deze foutmelding weg en start apache normaal. Ik heb postgresql ook al upgedate naar 8.4.1, maar dit haalt ook niets uit. Ik installeer PHP met deze configure regel:

code:

./configure --enable-shared --enable-inline-optimization --with-gd --with-png-dir=/usr --with-zlib --with-jpeg-dir=/usr --enable-ftp --with-libxmldir=/usr --enable-exif --with-openssl=/usr/ --enable-zend-multibyte --enable-sqlite-utf8 --with-freetype-dir=/usr --with-kerberos=/usr --with-mcrypt=/usr --enable-sockets --with-pear --enable-bcmath --with-pgsql=/usr/local/pgsql --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --with-apxs2=/usr/local/apache2/bin/apxs --disable-posix --with-curlwrappers --enable-zip --with-mime-magic --enable-gd-native-ttf --enable-mbstring=all --with-xsl --enable-pdo --with-pdo-mysql=/usr/local/mysql --with-sqlite=shared --with-pdo-sqlite

Ik draai apache 2.2.13, Ubuntu 8.04.3 LTS. Heeft iemand enig idee wat dit kan zijn? En hoe ik dit kan fixen?

[CrankyGamerOG]

wat staat er in je apache error log? in dit geval heeeel handig

heb je wel eerst de oude php binarys weg gehaald ? en een make clean gedraaid voor de make en make install?

Je lijkt tegen een bug aan te lopen

http://old.nabble.com/-Bu...php-pgsql-td24737734.html

[ Voor 77% gewijzigd door CrankyGamerOG op 23-11-2009 14:53 ]

[Verwijderd]

Ja ik heb php verwijderd. En make clean e/d. Het haalt allemaal niks uit.

[Kees]

Waarom apache+php niet uit de repository getrokken?

[Verwijderd]

Kees schreef op maandag 23 november 2009 @ 15:05:
Waarom apache+php niet uit de repository getrokken?

Je bedoelt via apt-get?

[Kees]

ja, eventueel een testing release pakken als je graag de nieuwste php wil

[Verwijderd]

Ja, ik dacht altijd dat je dan een hele oude versie van php kreeg. Ik gebruik apt-get eigenlijk alleen voor kleinere dingen. En ook omdat ik dan niet alle configure dingen zelf kan uitkiezen, en dat ik dan niet weet waar het komt te staan op mijn systeem.

[lordgandalf]

debian en ubuntu hebben gewoon apache2 en php5 en zelfs mysql5 dus zo oud is dat tegenwoordig ook niet meer het is inderdaad niet de allerlaatste release maar daar heb je testing of zelfs unstable voor dus zelf compilen is niet echt nodig imho

[CrankyGamerOG]

Verwijderd schreef op maandag 23 november 2009 @ 15:13:
Ja, ik dacht altijd dat je dan een hele oude versie van php kreeg. Ik gebruik apt-get eigenlijk alleen voor kleinere dingen. En ook omdat ik dan niet alle configure dingen zelf kan uitkiezen, en dat ik dan niet weet waar het komt te staan op mijn systeem.

jah maar de configure van de php uit apt is heul compleet hoor

[Verwijderd]

CrankyGamerOG schreef op maandag 23 november 2009 @ 16:18:
[...]

jah maar de configure van de php uit apt is heul compleet hoor

Ja, nouja, ik heb bij het installeren via apt-get altijd het idee van dat je zomaar wat doet, dat het zomaar ergens neergeplempt wordt op je systeem, met misschien allerlei dingen die ik niet nodig heb, en misschien de dingen die ik juist wel wil weer niet. En dat je dan op het laatst een soort van met plakband aan elkaar geknoopt systeem overhoudt waarvan je totaal niet meer weet wat er allemaal op staat.

Maargoed,

Ik installeer 5.3.0 zo wel weer even, hopelijk werkt dat wel.

[ Voor 12% gewijzigd door Verwijderd op 23-11-2009 16:28 ]

[smokalot]

Verwijderd schreef op maandag 23 november 2009 @ 15:13:
Ja, ik dacht altijd dat je dan een hele oude versie van php kreeg.

Je gebruikt een twee en een half jaar oude (LTS) release van ubuntu, maar je wilt wel de nieuwste versie van de software gebruiken?

Verwijderd schreef op maandag 23 november 2009 @ 16:23:
[...]

Ja, nouja, ik heb bij het installeren via apt-get altijd het idee van dat je zomaar wat doet, dat het zomaar ergens neergeplempt wordt op je systeem,

jij denkt dat het team van debian en ubuntu die zich bezig houden met het packagen van apache minder nadenken over de plek waar het geinstalleerd wordt dan jijzelf?

met misschien allerlei dingen die ik niet nodig heb, en misschien de dingen die ik juist wel wil weer niet.

Jij denkt dat eerdergenoemd team geen rekening houdt met de wensen van hun gebruikers? Of ben jij een heel erg niet-typische gebruiker? Waarom niet eerst kijken of er een voldoende complete versie in de repo's zit, en pas als dat niet zo is verder kijken?

En dat je dan op het laatst een soort van met plakband aan elkaar geknoopt systeem overhoudt waarvan je totaal niet meer weet wat er allemaal op staat.

Als jij alles netjes via je package manager doet kun je er van uitgaan dat alles goed samenwerkt, er is immers goed over nagedacht door het team aan packagers, en er zijn vele duizenden gebruikers die alles netjes testen. Je packagemanager kan je een heel duidelijk overzicht geven van wat er allemaal geinstalleerd is.

Als je dan echt zelf php wilt compileren, kun je het beste alsnog zelf een .deb bouwen en die met je packagemanager installeren. Dan geef je de packagemanager de mogelijkheid te doen waar het voor gemaakt is: je software beheren.

[Verwijderd]

Soms heb je gewoon speciale wensen voor je software, zo moet ik PHP hebben zonder postix.
En PHP is wel het laatste wat ik via de officiële repository zou halen!

Iemand heeft iets ontdekt wat gewoon dom is!

" Patch taken from intrepid, allows us to default to using the system
provided timezone database insteam of the one bundled with PHP.
(LP: #279980)"

Deze 'patch' zorgde ervoor dat de Datetime Extensie niet langer werkt.
Zelfs het ontwikkel team van PHP heeft dit afgeraden. Maar dit heeft de mensen van Ubuntu niet tegengehouden om het toch te doen.
Resultaat? Een kapotte PHP Date extensie!

Voor systeem libs of andere programma's voldoen de officiële repositories prima, maar PHP en Apache doe ik liever zelf compileren.

[Verwijderd]

smokalot schreef op maandag 23 november 2009 @ 17:00:
[...]

Je gebruikt een twee en een half jaar oude (LTS) release van ubuntu, maar je wilt wel de nieuwste versie van de software gebruiken?

Dat heeft toch niks met mekaar te maken? Ik wil inderdaad de nieuwste versie van PHP, omdat hier allerlei bugs in gefixt zijn en nieuwe features en dergelijke.

Edit: En trouwens, hij is geen 2,5 jaar oud, maar 1,5.

[...]


Jij denkt dat eerdergenoemd team geen rekening houdt met de wensen van hun gebruikers? Of ben jij een heel erg niet-typische gebruiker? Waarom niet eerst kijken of er een voldoende complete versie in de repo's zit, en pas als dat niet zo is verder kijken?

Het gaat me om de versie van PHP. Voor zover ik het kan zien is de versie van php die in de package lijst staat 5.2.4.

Als je dan echt zelf php wilt compileren, kun je het beste alsnog zelf een .deb bouwen en die met je packagemanager installeren. Dan geef je de packagemanager de mogelijkheid te doen waar het voor gemaakt is: je software beheren.

Daar kan ik nog wel eens naar kijken. Al begrijp ik niet precies wat het voordeel van een .deb is. Maar misschien moet ik me er wat meer in verdiepen

offtopic:
Edit: halleluja http://ubuntuforums.org/s...03&highlight=checkinstall Dat is ook geen simpel iets om te doen.

[ Voor 7% gewijzigd door Verwijderd op 25-11-2009 22:27 ]

[Verwijderd]

Daar kan ik nog wel eens naar kijken. Al begrijp ik niet precies wat het voordeel van een .deb is. Maar misschien moet ik me er wat meer in verdiepen

Dat is meer iets voor professionele systeembeheerders

Het voordeel is dat je alles op een apart systeem compileert, test en packed voor je er live meegaat.
Omdat alles goed is getest is er minder kans op fouten, en het is ook veiler omdat je dan geen compilers op je productie server hebt staan. Wat een must is tegen Spambotjes en Rootkits.

Ook is het makkelijker als je meerdere systemen moet installeren

Hier wil ik me ook nog in gaan verdiepen, maar dan moet je wel tijd hebben

Het bied echt vele voordelen maar kost wat tijd om alles goed te krijgen.
Maar daarna kun je het build script gebruiken voor toekomstige versies.

[smokalot]

Verwijderd schreef op maandag 23 november 2009 @ 17:15:
Zelfs het ontwikkel team van PHP heeft dit afgeraden. Maar dit heeft de mensen van Ubuntu niet tegengehouden om het toch te doen.
Resultaat? Een kapotte PHP Date extensie!

Als je het niet eens bent met de beslissingen van het ubuntu team, lijkt dat me een goede reden om voor een andere distro te gaan. Als zo'n package echt zo belabberd is zal er vast ook wel een alternatieve repo zijn die een betere versie aanbiedt.

Er zitten veel voordelen aan een packagemanager die al zn software uit repos haalt:
- veiliger omdat het automatisch geupdate wordt bij securityproblemen
- veiliger/minder bugs omdat er meer ogen naar kijken
- veiliger/minder bugs omdat het beter getest wordt
- werkt beter met andere software op je systeem omdat het samen getest is
- makkelijker dan zelf compileren

[CAPSLOCK2000]

Verwijderd schreef op maandag 23 november 2009 @ 17:20:

Daar kan ik nog wel eens naar kijken. Al begrijp ik niet precies wat het voordeel van een .deb is. Maar misschien moet ik me er wat meer in verdiepen

Doe dat zeker want ik zit met gekromde tenen te lezen Ik zal proberen een tipje van de sluier op te lichten, maar let op, ik heb het hier alleen over het aspect "files & directories"; er zijn nog vele andere voordelen. Packagemanagement staat in mijn top drie van innovaties die Linux heeft gebracht. Als je de free-software gedachte bij Richard Stallman laat, dan komt het zelfs op de eerste plek.


Een packagemanager is juist de manier bij uitstek om te voorkomen dat je systeem na verloop van tijd een grote puinhoop wordt, en zeker als je nog iets anders wil doen dan die ene machine onderhouden.

Het is waar dat je een beetje controle opgeeft, bijvoorbeeld waar de files komen te staan, maar dat heeft ook voordelen. Als ervaren gebruiker kun je prima voorspellen waar de files terecht gaan komen, ook bij software die je nog nooit hebt gezien.
Als je die ervaring nog niet hebt (en je ook geen zin hebt om de handleiding te lezen ) kun je aan het systeem vragen waar je files terecht zijn gekomen.
Andersom kun je ook vragen bij welk softwarepakkete een onbekende file hoort.


Een ander aspect dat je moet begrijpen om packagemanagement te kunnen waarderen is dat Linux z'n files anders groepeert dan Windows. Onder Windows worden files per programma gegroepeerd, onder Linux op functionaliteit. Dus alle log files bij elkaar, alle configs bij elkaar, alle icoontjes bij elkaar, alle handleidingen bij elkaar, etc... Of dat een goed of een slecht idee is doet er even niet toe, het is de standaard en als systeembeheerder kun je je maar beter conformeren dan er tegen vechten.

Doordat al die locaties gestandariseerd zijn kunnen eventuele collega's snel de weg vinden.


Ik zie packagemanagement een beetje als een team van systeembeheerders die mijn computer voor me beheren. Er is iemand met verstand van Apache, iemand met verstand van mail, eentje met kennis van C compilers enzovoort. Ik zal zelf nooit een expert kunnen zijn op alle gebieden, maar gelukkig is er een hele hoop nuttige kennis in het package management systeem gestopt. 95% van de software op m'n computers is niet direct relevant voor de hoofdtaak, ik kan en wil me daar ook geen zorgen over maken. Gelukkig hoeft dat ook niet, want dat doet de distributie voor me.

Overigens kunnen er best goede redenen zijn om stukjes buiten het package management te te houden, bijvoorbeeld Apache en PHP. Als het productie-kritiek is en jij zelf een expert bent mag je het natuurlijk zelf doen, maar dan zul je zelf ook moeten zorgen dat de rest van het systeem niet in de war raakt.

[Verwijderd]

Dat het handig is, daar ben ik het helemaal mee eens. Ik gebruik het dan ook veel hoor, maar voor zulke belangrijke dingen niet.. Wat mij het mooiste zou lijken is dat wanneer er een nieuwe PHP uit is, dat ik gewoon kan doen apt-get update php, en dat ik dan de nieuwe php heb. Dát is de hoofdreden voor mij, dat ik het niet via de packagemanager installeer. Ik begrijp ook niet dat dat niet kan. Maar misschien is daar wel een reden voor die ik niet begrijp?

[hostname]

Verwijderd schreef op dinsdag 24 november 2009 @ 19:54:
Dat het handig is, daar ben ik het helemaal mee eens. Ik gebruik het dan ook veel hoor, maar voor zulke belangrijke dingen niet.. Wat mij het mooiste zou lijken is dat wanneer er een nieuwe PHP uit is, dat ik gewoon kan doen apt-get update php, en dat ik dan de nieuwe php heb. Dát is de hoofdreden voor mij, dat ik het niet via de packagemanager installeer. Ik begrijp ook niet dat dat niet kan. Maar misschien is daar wel een reden voor die ik niet begrijp?

Ubuntu probeert de stabiele distro stabiel te houden, en dat doe je niet door nieuwe versies toe te voegen, die bevatten immers weer bugs.
De oplossing is bijv. de debian testing/unstable release, alleen ik weet niet of er zoiets voor ubuntu is.

anyway, zelf zo'n package maken is een behoorlijke ramp. Heb het vanmiddag even geprobeerd in een VM met een eigen programmatje, maar wat er allemaal wel niet bij komt kijken...

[icewind1991]

php 5.3.x is hier te vinden voor ubuntu 9.10 en hier voor 8.10 (heb het zelf niet getest alleen effe ge googled)

[Verwijderd]

Verwijderd schreef op dinsdag 24 november 2009 @ 19:54:
Dat het handig is, daar ben ik het helemaal mee eens. Ik gebruik het dan ook veel hoor, maar voor zulke belangrijke dingen niet.. Wat mij het mooiste zou lijken is dat wanneer er een nieuwe PHP uit is, dat ik gewoon kan doen apt-get update php, en dat ik dan de nieuwe php heb. Dát is de hoofdreden voor mij, dat ik het niet via de packagemanager installeer. Ik begrijp ook niet dat dat niet kan. Maar misschien is daar wel een reden voor die ik niet begrijp?

De reden hiervoor is dat als je als systeembeheerder een werkend systeem hebt geïnstalleerd, dan wil je hem ook graag werkend houden. Oftewel: je wilt wel security updates, maar verder niks. Als je een systeembeheerder bent van een X aantal servers dan wordt je er behoorlijk ziek van als je na elke update eerst alles zou moeten nalopen of alles nog werkt.

Verder is het handmatig updates nogal een kut werk. Je moet zelf alle security mailing lists bijhouden en de release mailing lists. Daarna moet je alles weer opnieuw configureren + compilen waarbij er altijd een kans is dat het niet meer werkt (zoals nu), dit is bij productie server onacceptabel. Je wilt gewoon 1 commando uitvoeren en dat hij zelf uitzoekt welke security updates nodig zijn waarbij je het risico op een gebroken systeem minimaliseert.

Meestal heb je de nieuwe functionaliteit in een nieuwe apache release bijvoorbeeld ook helemaal niet nodig en had je net zo goed de stable versie uit de repo kunnen pakken.

[Frank-NL]

Verwijderd schreef op maandag 23 november 2009 @ 17:20:

offtopic:
Edit: halleluja http://ubuntuforums.org/s...03&highlight=checkinstall Dat is ook geen simpel iets om te doen.

Dat is een howto uit 2005!

hostname schreef op dinsdag 24 november 2009 @ 20:26:
anyway, zelf zo'n package maken is een behoorlijke ramp. Heb het vanmiddag even geprobeerd in een VM met een eigen programmatje, maar wat er allemaal wel niet bij komt kijken...

Hoe kom je erbij? Je gebruikt checkinstall ipv make install en je krijgt een DEB, simpeler kan niet.

code:

wget http://us3.php.net/get/php-5.3.0.tar.gz/from/this/mirror
tar xvfz php-5-3-0.tar.gz
cd php-5.3.0
./congigure
make
make test
checkinstall

[Verwijderd]

Heb je wel eens gezien wat voor debjes checkinstall produceert, ze hebben zeg maar de extensie .deb en je kunt ze ook met dpkg installeren maar dat is dan ook alles

Overigens is het niet echt heel moeilijk om een nieuwere versie van een bestaand package te bouwen. Een heel nieuw niet bestaand package bouwen kan inderdaad wel erg lastig zijn.

[Verwijderd]

Checkinstall heb ik één keer gebruikt, en toen eraf gegooid.
Wat een ramp is dat zeg, als je probeert een upgrade uit te voeren krijg je de ene na het andere conflict.

anyway, zelf zo'n package maken is een behoorlijke ramp. Heb het vanmiddag even geprobeerd in een VM met een eigen programmatje, maar wat er allemaal wel niet bij komt kijken...

Dit doe je ook niet even 123
Daar gaat tijd, voorbereiden en goed testen in zitten.

Maar persoonlijk heb ik dat er voor over.

PHP en Apache worden door de ontwikkelaars goed ontwikkeld en onderhouden.
Dus dat ik na een upgrade problemen krijg is erg klein, en ik doe voor alles in productie word genomen goed testen en controleren. Want "een goed goed geïnstalleerd software pakket bied geen garantie voor goed werkend programma". - Linux Magazine


Door een groot gedeelte zelf te compileren heb ik wel meer werk, maar daar kies ik ook voor.
Maar daardoor krijg ik wel: Een pakket wat ik (zonder de nodige aanpassingen) op elke systeem binnen de organisatie kan installeren, en wat is afgestemd op onze wensen.

En soms heb je geen andere keuze, omdat een programma niet in een repository te verkrijgen is

Het is waar dat je een beetje controle opgeeft, bijvoorbeeld waar de files komen te staan, maar dat heeft ook voordelen. Als ervaren gebruiker kun je prima voorspellen waar de files terecht gaan komen, ook bij software die je nog nooit hebt gezien.

Maar dan moet de pakket beheer zich wel aan de LSB regels houden

Zo installeert 'postgresql-7.4' executebles in lib

/usr/lib/postgresql/7.4/bin

Terwijl deze in beter in /usr/libexec kunnen worden geplaatst

Dit vond ik via een snelle Google actie: http://lists.debian.org/debian-devel/2005/05/msg00401.html