PHP.ini wordt niet goed gesynchroniseerd

[FrankJ91]

Hallo,

Ik ben bezig met een opdracht waarbij beheerders via webinterface foto's, films en PowerPoints kunnen uploaden wat wordt getoond op een aantal grote informatieschermen.

Het probleem is dat klanten bij me komen en zeggen dat ze bestanden groter dan 2M niet kunnen uploaden. Dit is natuurlijk erg beperkt en dat moet veranderd worden.
Nu heb ik de phpinfo bestand laten draaien en zo de locatie opgezocht waar de php.ini file is opgeslagen.

Hierbij heb ik de volgende regels aangepast:

max_file_upload = 20M
max_post_size = 20M

Vervolgens de apache2 service gereboot en de phpinfo pagina opnieuw geladen. Echter zie ik dat max_file_upload nog steeds op 2M staat? Ik heb alles afgespeurd en extra gecontroleerd en het zal moeten werken. Weet iemand hoe dit kan?


P.S.: Ik zie nu dat er 2 PHP.ini's zijn? In Ubuntu zegt hij dat /etc/php5/cli/php.ini geladen is en op webinterface zegt hij dat de /etc/php5/apache2/php.ini geladen is? Heb ze beiden identiek gemaakt, maar dit lost het probleem van 2M niet op.

root@XIBO:/usr/bin# php -i | grep php.ini
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini

root@XIBO:/usr/bin# find / -name php.ini
/etc/php5/cli/php.ini
/etc/php5/apache2/php.ini


Weet iemand raad? Alvast bedankt!


Groet,

Frank

[ExploitSolo]

1. Schakel php uit,
2. Edit PHP.ini
3. schakel php in

[ShitHappens]

Inderdaad, want Apache en PHP runnen onafhankelijk van elkaar, door Apache te herstarten laad je bijvoorbeeld httpd.conf opnieuw.

[Woet]

FrankJ91 schreef op zondag 03 juli 2011 @ 00:01:
Hallo,

- snip -

Frank

De PHP settings heten upload_max_filesize en post_max_size, niet max_file_upload en max_post_size.

ExploitSolo schreef op zondag 03 juli 2011 @ 00:03:
1. Schakel php uit,
2. Edit PHP.ini
3. schakel php in

Geen idee waar jij het over hebt

[Voor 59% gewijzigd door Woet op 03-07-2011 00:11]

[Aganim]

In Ubuntu zegt hij dat /etc/php5/cli/php.ini geladen is en op webinterface zegt hij dat de /etc/php5/apache2/php.ini

Ter info: de eerste is het php.ini bestand voor wanneer je PHP in een console (CLI = CommandLine Interface )wilt uitvoeren, de tweede is voor de PHP versie die door Apache geladen wordt.

[FrankJ91]

Woet schreef op zondag 03 juli 2011 @ 00:10:
[...]


De PHP settings heten upload_max_filesize en post_max_size, niet max_file_upload en max_post_size.


[...]


Geen idee waar jij het over hebt

Zo staan ze er ook in

Upload_max_filesize

Heb dat alleen aangepast, niet van naam gewijzigd. Zit er al tijdje met te klooien dat ik gewoon gek wordt van die 2 rijtjes:P

[FrankJ91]

Aganim schreef op zondag 03 juli 2011 @ 00:17:
[...]

Ter infor: de eerste is het php.ini bestand voor wanneer je PHP in een console (CLI = CommandLine Interface )wilt uitvoeren, de tweede is voor de PHP versie die door Apache geladen wordt.

Okeee, dus het gaat alleen om de "/etc/php5/apache2/php.ini" file.
Dan weet ik dat ook weer. Ben zelf niet zo ervaren in programmering, maar het komt bij ons toch als een taak binnen bij netwerkbeheer. :\

Maar apache stoppen, php.ini wijzigen en apache starten is toch onzin? Bij een restart van de service zal hij als het goed is de nieuwe ini file moeten laden en toepassen.

Heb het nog even getest met andere instellingen, zoals memory limit e.d. maar die wordt ook niet doorgevoerd. Het ligt dus aan de hele php.ini file.

[NMe]

Geen programmeerprobleem, zie Waar hoort mijn topic?

PRG>>NOS

[ShitHappens]

Maar doe je nou ook de PHP service opnieuw starten? Indien nee, wel doen.

[FrankJ91]

Ik herstart apache2 via service apache2 restart. Voor jou ben ik nog even wezen Googlen, maar ik zie geen aparte PHP service die je kan herstarten.

"PHP is a scriping language which hooks into the Apache Webserver (apache2) in Ubuntu. In order to "restart" PHP (to load in your new php.ini configuration, for example) you actually need to restart Apache."

[Grvy]

ShitHappens schreef op zondag 03 juli 2011 @ 00:52:
Maar doe je nou ook de PHP service opnieuw starten? Indien nee, wel doen.

lolwhut? Dat kan helemaal niet. PHP is geen service.

[Thralas]

FrankJ91 schreef op zondag 03 juli 2011 @ 01:01:
Ik herstart apache2 via service apache2 restart. Voor jou ben ik nog even wezen Googlen, maar ik zie geen aparte PHP service die je kan herstarten.

Dat is ook voldoende - PHP is met een standaardsetup onderdeel van Apache (mod_php).

(Tenzij je een heel exotische fastcgi-setup hebt, maar dat heb je niet)

Ik kan je toch enkel aanraden om nog eens goed te kijken naar de output van phpinfo() en de daarin genoemde config file (/etc/php5/apache2/php.ini). Probeer desnoods even een andere optie te wijzigen, om te zien of dat wel lukt.

[FrankJ91]

ik pruts er al sinds 3 uur vanmiddag mee, maar het lijkt wel alsof hij de php.ini totaal niet uitleest. Zelfs als ik:

; Enable the PHP scripting language engine under Apache.
; http://php.net/engine
engine = On ---> engine = Off

verander, blijft phpinfo gewoon werken. Vandaar dat ik het gevoel heb dat php naar een andere locatie kijkt?

[Osiris]

ShitHappens schreef op zondag 03 juli 2011 @ 00:52:
Maar doe je nou ook de PHP service opnieuw starten? Indien nee, wel doen.

Wat dacht je van mod_php?

Ik heb nog nooit van een "PHP service" gehoord. Is dat iets voor onder Windows ofzo?

FrankJ91 schreef op zondag 03 juli 2011 @ 01:11:
ik pruts er al sinds 3 uur vanmiddag mee, maar het lijkt wel alsof hij de php.ini totaal niet uitleest. Zelfs als ik:

; Enable the PHP scripting language engine under Apache.
; http://php.net/engine
engine = On ---> engine = Off

verander, blijft phpinfo gewoon werken. Vandaar dat ik het gevoel heb dat php naar een andere locatie kijkt?

Heb je Apache al wel eens he-le-maal gestopt? Een simpele restart geeft namelijk volgens mij slechts een kill-signaaltje, maar als de daemons daar verder geen zin in hebben, dan blijven ze nog gewoon draaien onder de oude configuratie.

Dus ik zou zeggen: stop Apache eens 100%, doe een `ps aux | grep apache` om te checken of alles écht dood is en start 't geheel daarna weer op.

[Voor 58% gewijzigd door Osiris op 03-07-2011 01:13]

[Anoniem: 26306]

Osiris schreef op zondag 03 juli 2011 @ 01:12:

Ik heb nog nooit van een "PHP service" gehoord. Is dat iets voor onder Windows ofzo?

Je zou PHP-FPM wel zo kunnen zien Werkt erg fijn met bijvoorbeeld nginx.
Maar dat is vast niet wat hij bedoelt.

[Thralas]

FrankJ91 schreef op zondag 03 juli 2011 @ 01:11:
Vandaar dat ik het gevoel heb dat php naar een andere locatie kijkt?

Doe eens een service apache2 stop en kijk dan of alle httpd-processen ook inderdaad gestopt zijn.

[Osiris]

Anoniem: 26306 schreef op zondag 03 juli 2011 @ 01:13:
[...]

Je zou PHP-FPM wel zo kunnen zien Werkt erg fijn met bijvoorbeeld nginx.
Maar dat is vast niet wat hij bedoelt.

Al die exotische zooi heeft vast z'n php.ini ergens anders staan dan /etc/php5/apache2/php.ini But I could be wrong

[Anoniem: 26306]

Osiris schreef op zondag 03 juli 2011 @ 01:16:
[...]

Al die exotische zooi heeft vast z'n php.ini ergens anders staan dan /etc/php5/apache2/php.ini But I could be wrong

Nee, dat klopt. Bovendien is PHP-FPM niet meer standaard in Debian en Ubuntu geloof ik. Zit zelfs (tijdelijk) niet meer in testing.

[FrankJ91]

Okee ik heb de service gestopt (en dan ligt de phpinfo idd plat, dus hij werkt wel ). Ik ga ervan uit dat de php module dus ook gestopt is. ps aux | grep apache heb ik uitgevoerd, maar geen idee wat dat allemaal inhoudt. Zo is alles goed gestopt?


root@XIBO:/etc/php5/cli# service apache2 stop
* Stopping web server apache2 ... waiting [ OK ]
root@XIBO:/etc/php5/cli# ps aux | grep apache
root 2601 0.0 0.1 8952 872 pts/0 S+ 01:17 0:00 grep --color=auto apache

Let niet op maplocatie, daar stond hij nog in van tijd terug. Pas de ini file aan in de apache2 directory.

[Voor 6% gewijzigd door FrankJ91 op 03-07-2011 01:23]

[naam]

De service van apache heet httpd. Dus met 'ps aux | grep httpd' zou je er als het goed is nu geen meer moeten zien.

Dat de 2 php.ini bestanden van elkaar verschillen komt omdat het in veel omgevingen wenselijk is om voor de cli van php andere instellingen te gebruiken dan voor de web-frontend (apache in jouw geval). Dit is echter makkelijk op te lossen door een symlink (symbolic link) te maken.

Om dit te doen verwijder je in de map '/etc/php5/cli' het bestand php.ini en vervolgens voer je het volgende commando uit: "ln -s ../apache2/php.ini" Dit maakt de symlink voor je. Hierna kan je apache opnieuw starten ("/etc/init.d/apache2 restart"). Apache gebruikt nu de nieuwe versie van php.ini en deze is nu dus voor zowel de CLI als voor de web-frontend hetzelfde aangezien ze beiden naar hetzelfde fysieke bestand (blocks op de schijf) refereren.

edit:

Mocht apache nu een fout geven, dan kan je "/etc/init.d/apache2 start" proberen. Dan komt dat waarschijnlijk doordat je net de apache service gestopt had.

[Voor 9% gewijzigd door naam op 03-07-2011 01:26]

[Thralas]

Je kunt de -cli config ook gewoon laten voor wat 't is. Het zijn immers niets voor niets losse files (ik heb bv. graag error reporting op de cli).

[FrankJ91]

Okeee heb dat aangepast, ty

Maar ik snap het probleem dan nog steeds niet.


PHPinfo:
Loaded Configuration File /etc/php5/apache2/php.ini
upload_max_filesize 2M 2M

/etc/php5/apache2/php.ini:
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 20M


Niemand eerder zoiets meegemaakt? Op Google vond ik ook dat het soms wel te maken kan hebben met tegenstrijdige opties in de .htaccess file. Alleen de .htaccess file is bij mij gewoon helemaal leeg. Ook in apache2.conf (httpd.conf is ook leeg), staat niks over PHP in.

[ShitHappens]

Anoniem: 26306 schreef op zondag 03 juli 2011 @ 01:13:
[...]

Je zou PHP-FPM wel zo kunnen zien Werkt erg fijn met bijvoorbeeld nginx.
Maar dat is vast niet wat hij bedoelt.

PHP draait in Windows wel als service, welgemeende excuses.

[NMe]

ShitHappens schreef op zondag 03 juli 2011 @ 01:37:
[...]

PHP draait in Windows wel als service, welgemeende excuses.

Ook daar is het optioneel.

[8088]

FrankJ91 schreef op zondag 03 juli 2011 @ 01:22:
ps aux | grep apache heb ik uitgevoerd, maar geen idee wat dat allemaal inhoudt.

Dat kun je natuurlijk opzoeken. Wel zo verstandig om daar gelijk een gewoonte van te maken, want van het blindelings overnemen van commando's krijg je vroeg of laat een keer spijt.

naam schreef op zondag 03 juli 2011 @ 01:25:
De service van apache heet httpd.

Onder Red Hat e.d wel, maar niet onder Ubuntu (waar het hier om gaat), Debian e.d.

FrankJ91, kijk ook eens in de .ini bestanden die bij je extensies horen ("Additional .ini files parsed"). Wie weet wordt er daar iets overruled.

[FrankJ91]

Ok, dankjewel, ik heb gekeken in de additional ini files map (etc/php5/apache2/conf.d) (volgens phpinfo waar hij ze vandaan haalt "Additional .ini files parsed" ):

gd.ini mysqli.ini mysql.ini pdo.ini pdo_mysql.ini

Heb ze geopend, maar het zijn allemaal 2 regels waar gewoon extensies in vermeld worden:
; configuration for php GD module
extension=gd.so

Maar dit zijn dus gewoon extensies die PHP leert kennen en wat hij ermee moet. Daar kan het dus niet aan liggen. Ik snap er eerlijk gezegd niks van waarom hij de php.ini totaal niet uitvoert. Ik verander php.ini wel ff van naam, kijken of hij dan error geeft weet ik dus of die het echt wel inleest.

[naam]

8088 schreef op zondag 03 juli 2011 @ 01:43:
[...]

Onder Red Hat e.d wel, maar niet onder Ubuntu (waar het hier om gaat), Debian e.d.

Je hebt inderdaad gelijk, mijn fout. Ik ben in de war met een windows omgeving waarschijnlijk, daar heet de service van apache wel httpd. Mijn excuus

---

Weet je zeker dat je apache wel goed opnieuw hebt gestart? Dit kan je doen dmv '/etc/init.d/apache2 restart'

[FrankJ91]

Okee, ik heb php.ini van naam veranderd. phpinfo blijft werken, maar er staat bij loaded configuration file: none.

Het gaat dus echt om dat bestand. Ikzelf deed het via service apache2 restart maar dat werkt hetzelfde ga ik vanuit.

[8088]

Heb je gecontroleerd of upload_max_filesize en post_max_size slechts één keer in het bestand voorkomen?

[FrankJ91]

8088 schreef op zondag 03 juli 2011 @ 02:01:
Heb je gecontroleerd of upload_max_filesize en post_max_size slechts één keer in het bestand voorkomen?

Het komt er 1 maal in voor. Ik ga denk ik maar slapen, zal morgen wel weer verder kijken naar dit vreemde probleem.

Is het b.t.w. ook mogelijk om in Ubuntu te zoeken in bestanden? Dus dat hij upload_max_filesize zoekt via find ofzo in alle mappen of het ergens in terug te vinden is?

[8088]

Als je m'n eerdere raad opgevolgd had met betrekking tot het kopiëren van commando's had je deze vraag niet hoeven stellen Hint: grep.

[Voor 3% gewijzigd door 8088 op 03-07-2011 02:12]

[Boudewijn]

FrankJ91 schreef op zondag 03 juli 2011 @ 02:05:
[...]


Het komt er 1 maal in voor. Ik ga denk ik maar slapen, zal morgen wel weer verder kijken naar dit vreemde probleem.

Is het b.t.w. ook mogelijk om in Ubuntu te zoeken in bestanden? Dus dat hij upload_max_filesize zoekt via find ofzo in alle mappen of het ergens in terug te vinden is?

grep -r , eventueel met xargs uit te voeren op de output van find.

[FrankJ91]

Hmm ik heb grep onderzocht en uitgevoerd maar vind geen extra bestanden meer naast de example bestanden van PHP waar upload_max_filesize in voorkomt. Ook de gehele server gereboot in de hoop dat hij dan zal werken, maar helaas bood dit ook geen uitkomst.

In de php file van de applicatie wordt de max_filesize opgevraagd via:

$this->maxFileSize = ini_get('upload_max_filesize');

Ik snap niet wat de ini file kan tegenhouden.

[blaataaps]

Zit er een .htaccess-bestand bij?

[FrankJ91]

Ja die staat erin .htaccess, maar als ik hem open via nano staat er niks in.

Ohhh het volgende staat erin (niks te zien over php)


#
# Copyright (c) 2003-2010, CKSource - Frederico Knabben. All rights reserved.
# For licensing, see LICENSE.html or http://ckeditor.com/license
#

#
# On some specific Linux installations you could face problems with Firefox.
# It could give you errors when loading the editor saying that some illegal
# characters were found (three strange chars in the beginning of the file).
# This could happen if you map the .js or .css files to PHP, for example.
#
# Those characters are the Byte Order Mask (BOM) of the Unicode encoded files.
# All FCKeditor files are Unicode encoded.
#

AddType application/x-javascript .js
AddType text/css .css

#
# If PHP is mapped to handle XML files, you could have some issues. The
# following will disable it.
#

AddType text/xml .xml


root@XIBO:/# which php
/usr/bin/php

Moet dat niet php5 zijn??

[Voor 87% gewijzigd door FrankJ91 op 03-07-2011 14:17]

[Boudewijn]

Is dat niet een symlink ofzo dan? En gebruik aub quote tags en code tags .

[FrankJ91]

Okeee eindelijk heb het probleem gevonden.

Had de hele php.ini file leeggemaakt, hij bleef werken.
Vervolgens zette ik alleen de optie upload_max_filesize erin met de waarde erachter. Dat werkte wel.

Toen ik in de command line php intypte, gaf hij een syntax error op line 1. Hier stond [PHP], met vervolgens daaronder de gehele omschrijving enzo.

Heb dus de [PHP] tag verwijderd en de hele ini file wordt gelezen.

Dankjewel voor jullie hulp!

[Osiris]

Hm, die tag hoort er volgens mij wel in te staan hoor..

[FrankJ91]

Is dat zo??

Ik heb het systeem zelf niet geinstalleerd dus weet niet hoeveel de rest ermee geprutst heeft.

Maar jullie hebben het dus wel erin staan?

[Grvy]

volgens mij alleen met een # ervoor.

[Osiris]

Bij mij, Gentoo, niet hoor.

[b][green]user@server [/][blue]~ $ [/][/]grep "\[PHP\]" /etc/php/apache2-php5/php.ini
[PHP]
[b][green]user@server [/][blue]~ $ [/][/]

[FrankJ91]

Weet je wat het was, heb er nog even goed naar gekeken:
Er stond een spatie voor [PHP]. Daar kijk je natuurlijk al gauw overheen.

Maargoed het werkt prima. Ty!

[CAPSLOCK2000]

Wauw, goede vonst

[Anoniem: 103571]

te laat

[Voor 96% gewijzigd door Anoniem: 103571 op 05-07-2011 17:05]