Nginx met Directadmin PHP bestanden caching uitzetten

[Zenda]

Goedemorgen,

Ik heb een VPS geïnstalleerd en dat ging allemaal goed.

Er draait Nginx op met Directadmin. Ik heb echter een probleem. De server cached PHP bestanden. Als ik een HTML bestand update zie ik de wijzigingen direct, bij de PHP bestanden niet. Dan duurt het een aantal minuten voordat ik de wijzigingen zie. Super vervelend.

Hoe zet ik dit uit? Ik heb op Google gevonden dat je dan apc.enable=0 moet toevoegen aan php.ini. Dat heb ik gedaan, met een service nginx restart maar ik zie die variable niet verschijnen bij phpinfo(). Ook lost het caching probleem niet op.

Heeft iemand hier ervaring mee?

[Khallouki]

Je moet PHP-fpm restarten niet nginx, en kijk of er geen memcached is enabled.

[Zenda]

Dank je wel voor je reply. Hoe restart ik PHP-fpm op CentOs7, met Nginx en Directadmin? Ik ben vrij noob hiermee, ik weet veel te vinden maar hier kom ik niet uit.

Al deze opties doen het ook niet:
https://serverfault.com/q...ow-do-you-restart-php-fpm

[Khallouki]

code:

systemctl restart php-fpm

Doet deze het niet? Dan heb je geen centos 7 draaien.
Kan je de output van deze command hier plakken?

code:

cat /etc/*release

[Zenda]

code:

]# systemctl restart php-fpm
Failed to restart php-fpm.service: Unit not found.

Output:

code:

CentOS Linux release 7.4.1708 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.4.1708 (Core)
CentOS Linux release 7.4.1708 (Core)

Op de VPS draait ook Nginx en DirectAdmin ter info.

Ik denk dat het ook iets te maken heeft met de versie? Hoe kom ik erachter wat de naam van de service is. Ik lees ook wel op fora dat het: php-fpm56.service kan zijn, o php-fpm5.service etc. Uiteraard heb ik er een aantal geprobeerd, maar niets werkt. Als er een manier is om erachter te komen welke service er is dan zijn we weer een stapje verder.

Erg bedankt voor je hulp zover.

[ Voor 25% gewijzigd door Zenda op 09-03-2018 10:20 ]

[Khallouki]

Zenda schreef op vrijdag 9 maart 2018 @ 10:14:

code:

]# systemctl restart php-fpm
Failed to restart php-fpm.service: Unit not found.

Output:

code:

CentOS Linux release 7.4.1708 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.4.1708 (Core)
CentOS Linux release 7.4.1708 (Core)

Op de VPS draait ook Nginx en DirectAdmin ter info.

Ik denk dat het ook iets te maken heeft met de versie? Hoe kom ik erachter wat de naam van de service is. Ik lees ook wel op fora dat het: php-fpm56.service kan zijn, o php-fpm5.service etc. Uiteraard heb ik er een aantal geprobeerd, maar niets werkt. Als er een manier is om erachter te komen welke service er is dan zijn we weer een stapje verder.

Erg bedankt voor je hulp zover.

Ik zie het al, je hebt helemaal geen php-fpm draaien.
Eens even kijken wat je hebt geïnstalleerd. Toon eens de output van deze command:

code:

yum list installed | grep php

[Evianon]

Als het een nieuwere VPS is, draait er wellicht Opcache op in plaats van het verouderde APC.

Dat kun je uitzetten door het bestand 10-directadmin.ini op te zoeken (bijv. /usr/local/php71/lib/php.conf.d/10-directadmin.ini voor PHP 7.1, als je PHP-FPM draait), en de opcache extensie en bijbehorende parameters uit te commenten als die er zijn.

Als dat het niet is, kun je misschien een linkje naar een phpinfo() bestand delen?

En als je PHP-FPM hebt draaien, dan is restarten met Directadmin normaal gesproken:

code:

systemctl restart php-fpm71

Voor PHP 7.1, en andere nummers voor andere PHP versies.

[Zenda]

code:

yum list installed | grep php

gaf terug:

code:

Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast

Toen heb ik yum makecache fast gedaan, maar als ik nu de grep php uitvoer dan geeft hij niets terug?!

Hier linkje phpinfo();

url adres verwijderd ivm indexing Google

[ Voor 23% gewijzigd door Zenda op 09-03-2018 11:30 ]

[Hero of Time]

Dan staat er blijkbaar geen php op.

Edit:
Ah, zooi in /usr/local. Dat zegt al een hoop en had al zo'n vermoeden door gebruik van DirectAdmin. Die zooi doet z'n eigen ding en voert alles buiten de package manager uit. Het wordt dan effectief een grote bende. Kan je geen ander beheerpakket kiezen voor de server?

[ Voor 80% gewijzigd door Hero of Time op 09-03-2018 10:37 ]

[Zenda]

Er staat wel PHP op, zie de phpinfo en PHP werkt gewoon

[Evianon]

Zenda schreef op vrijdag 9 maart 2018 @ 10:30:

code:

yum list installed | grep php

gaf terug:

code:

Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast

Toen heb ik yum makecache fast gedaan, maar als ik nu de grep php uitvoer dan geeft hij niets terug?!

Dat is normaal, DirectAdmin compiled en managed PHP zelf en niet via een package manager, dus komt het niet voor in je package manager.

Niets met yum gaan installeren / verwijderen / beheren wat te maken heeft met PHP in ieder geval, dan gaat het goed mis.

[Zenda]

Ok bedankt Evianon. Ik ga geen ander beheerpakket gebruiken Hero of Time. Ik wil graag PHP restarten ;-) Dan is mijn cache probleem opgelost met PHP bestanden, komt waarschijnlijk door de ttl van 120, die moet ik uitzetten en dan werkt het. Alleen moet ik PHP kunnen herstarten nu ))) Heb nginx en directadmin al opnieuw opgestart, maar ik kom er niet achter hoe ik PHP herstart...

[Hero of Time]

Evianon schreef op vrijdag 9 maart 2018 @ 10:38:
Niets met yum gaan installeren / verwijderen / beheren wat te maken heeft met PHP in ieder geval, dan gaat het goed mis.

Het is al goed mis door het gedrocht met de naam DirectAdmin.

Normaal gesproken hoef je php niet te herstarten. Het is geen service zelf, maar gewoon een module voor je webserver. Die voert de boel uit. maar met DA weet je niet wat het allemaal heeft gedaan en zit je dus met zit zooitje in een blackbox tenzij je precies weet wat het doet. En aangezien je DA gebruikt, denk ik dat je dat niet weet.

[Evianon]

Zenda schreef op vrijdag 9 maart 2018 @ 10:39:
Ok bedankt Evianon. Ik ga geen ander beheerpakket gebruiken Hero of Time. Ik wil graag PHP restarten ;-) Dan is mijn cache probleem opgelost met PHP bestanden, komt waarschijnlijk door de ttl van 120, die moet ik uitzetten en dan werkt het. Alleen moet ik PHP kunnen herstarten nu ))) Heb nginx en directadmin al opnieuw opgestart, maar ik kom er niet achter hoe ik PHP herstart...

Je kunt ook in DirectAdmin inloggen op het admin deel, naar Service Monitor gaan, en daar op restart drukken. Kun je meteen zien hoe je PHP service precies heet.

[Sneezydevil]

code:

systemctl restart php-fpm56

[Zenda]

dit zijn de services, maar ik zie nergens PHP staan..

EDIT

Ik heb via service monitor httpd hergestart en het heeft de PHP.ini opnieuw ingeladen. Nou, wat een werk maar wel weer wat geleerd vandaag Iedereen erg bedankt voor de hulp.

Het caching probleem (of wat het kan zijn) mbt php bestanden is nog niet opgelost. Wijigingen in HTML bestanden zijn direct zichtbaar, maar wijzigingen in PHP bestanden duren even voordat ze zichtbaar zijn.

Ik heb nu realpath_cache_ttl op 0 gezet in php.ini. Iemand anders nog ideeën daarover?

EDIT 2:

Toch gelukt, het had te maken met Zend OPcache. Die heb ik via .htaccess uitgezet (php_flag opcache.enable off) en wijzigingen aan PHP bestanden zijn nu direct zichtbaar!!!!!

Probleem opgelost, heel erg bedankt iedereen voor de hulp!!!

[ Voor 87% gewijzigd door Zenda op 09-03-2018 10:54 ]

[Evianon]

Hero of Time schreef op vrijdag 9 maart 2018 @ 10:41:
[...]

Het is al goed mis door het gedrocht met de naam DirectAdmin.

Wat is er volgens jou mis met de manier hoe DirectAdmin het doet dan? Het zelf compileren is juist ideaal. Volledige controle over PHP versies, meerdere versies (incl. 5 en 7) tegelijk draaien, strakke configuratie en daardoor mooi geïntegreerd met het web panel. Compileert het ook nog eens voor je eigen CPU, wat misschien nog een klein beetje performance winst kan opleveren. Nieuwe versies van PHP meteen kunnen draaien in plaats van wachten op de package manager.

Je moet even weten hoe het werkt, maar technisch zit het behoorlijk in elkaar en is het goed geregeld. Iets meer low-level als sommige andere control panels, maar ik vind de mogelijkheden die je daarmee krijgt wel fijn. Iets als een "bende" herken ik helemaal niet. Als je vervolgens tegelijk met een package manager met PHP gaat rommelen, dan wordt het wel een zooitje ja .

Zenda schreef op vrijdag 9 maart 2018 @ 10:45:
[afbeelding] dit zijn de services, maar ik zie nergens PHP staan..

Dan draai je inderdaad geen PHP-FPM maar mod_php en is httpd opnieuw opstarten genoeg.

[ Voor 12% gewijzigd door Evianon op 09-03-2018 10:56 ]

[Zenda]

Hehe wel of geen directadmin is een discussie opzich. Even on-topic blijven moderator

Probleem met PHP caching bestanden is opgelost door Zend OPcache uit te zetten in .htaccess!

[Khallouki]

Zenda schreef op vrijdag 9 maart 2018 @ 10:39:
Ok bedankt Evianon. Ik ga geen ander beheerpakket gebruiken Hero of Time. Ik wil graag PHP restarten ;-) Dan is mijn cache probleem opgelost met PHP bestanden, komt waarschijnlijk door de ttl van 120, die moet ik uitzetten en dan werkt het. Alleen moet ik PHP kunnen herstarten nu ))) Heb nginx en directadmin al opnieuw opgestart, maar ik kom er niet achter hoe ik PHP herstart...

Evianon heeft gelijk niets mee doen.
Oke dan kijken we welke PHP service we precies hebben draaien. Check eens:

code:

systemctl | grep php

[Khallouki]

Zenda schreef op vrijdag 9 maart 2018 @ 10:55:
Hehe wel of geen directadmin is een discussie opzich. Even on-topic blijven moderator

Probleem met PHP caching bestanden is opgelost door Zend OPcache uit te zetten in .htaccess!

Heh? Nginx gebruikt helemaal geen htaccess. Dat doet Apache.

[Evianon]

Zenda schreef op vrijdag 9 maart 2018 @ 10:55:
Probleem met PHP caching bestanden is opgelost door Zend OPcache uit te zetten in .htaccess!

Mooi! Het uitzetten van Opcache via .htaccess kost je wel een klein beetje performance. De Opcache module draait dan nog steeds mee, laadt bestanden, maar gebruikt die dan vervolgens weer niet omdat de .htaccess het weer uitzet. Als je de Opcache niet gebruikt kun je hem dus beter helemaal uitzetten, zoals in m'n eerste post hier staat.

Je draait mod_php dus dan staat het 10-directadmin.conf bestand uit m'n hoofd ergens op /usr/local/lib/php.conf.d/10-directadmin.ini, en anders even opzoeken met locate o.i.d.

Aangezien je zo te zien mod_php draait zou ik nog wel even checken of mod_ruid2 geïnstalleerd is, dat is belangrijk. Anders kunnen verschillende accounts elkaars bestanden lezen (bijv. als je verschillende klanten hebt, maar ook als je alleen maar eigen sites hebt wil je dat niet, want dan kan 1 gehackte site ook meteen alle data van andere sites lezen).

Dat kun je doen door tijdelijk het exec() commando toe te staan in je php.ini, en een bestandje met exec('whoami'); aan te roepen. De naam die je dan ziet moet gelijk zijn aan het DirectAdmin gebruikersaccount.

Omschakelen naar PHP-FPM is eigenlijk beter, maar dat is ook weer wat werk en volgens mij heb je wel weer genoeg bereikt vandaag

[Zenda]

Haha ik denk het wel, ik ga er later naar kijken. Dit is niet voor klanten, is een testomgeving .

[Hero of Time]

Zenda schreef op vrijdag 9 maart 2018 @ 10:55:
Hehe wel of geen directadmin is een discussie opzich. Even on-topic blijven moderator

Probleem met PHP caching bestanden is opgelost door Zend OPcache uit te zetten in .htaccess!

Je issue is juist veroorzaakt door dat gedrocht. Prima ontopic dus. Een standaard installatie van php vanuit je package manager geeft deze issues niet namelijk.

Evianon schreef op vrijdag 9 maart 2018 @ 10:53:
[...]

Wat is er volgens jou mis met de manier hoe DirectAdmin het doet dan?

Van alles, maar ik ga hier niet in detail. Dat kan je via DM vragen.

Het zelf compileren is juist ideaal.

Nee, te veel (ge)rommel ipv netjes de distro versie pakken.

Volledige controle over PHP versies, meerdere versies (incl. 5 en 7) tegelijk draaien,

Daar zijn aparte repo's voor die zich wel netjes houden aan de standaarden van de distro.

strakke configuratie en daardoor mooi geïntegreerd met het web panel.

Wat zelf zo lek is als een mandje en je feitelijk niet nodig hebt.

Compileert het ook nog eens voor je eigen CPU, wat misschien nog een klein beetje performance winst kan opleveren.

Juist, 'misschien'. De kans daarop, met de huidige CPU's, is het verschil niet te merken. Hooguit een duizendste van een nanoseconde dat het sneller kan zijn. Ja, misschien een hele kloktik sneller, nou...

Nieuwe versies van PHP meteen kunnen draaien in plaats van wachten op de package manager.

Package maintainer bedoel je. En daar is een heel goede reden voor. Verdiep je daar eens in.

Je moet even weten hoe het werkt, maar technisch zit het behoorlijk in elkaar en is het goed geregeld. Iets meer low-level als sommige andere control panels, maar ik vind de mogelijkheden die je daarmee krijgt wel fijn. Iets als een "bende" herken ik helemaal niet. Als je vervolgens tegelijk met een package manager met PHP gaat rommelen, dan wordt het wel een zooitje ja .

Ik heb zelf anders te veel gezeik meegemaakt en dingen die niet lekker werkte of andere dingen spontaan op z'n plaat ging door zo'n panel dat ik het verafschuw. Als professioneel Linux beheerder doe ik alles zelf op de manier hoe het bij de distro is bedoelt. Niks van een of ander pakket dat het weer op z'n eigen manier moet doen.

[Zenda]

Ik begrijp je insteek. Maar voor een noob als ik is DirectAdmin super gebruikersvriendelijk. Gemakkelijk domeinen beheren, DNS, nameservers, alles. En nu ik weet dat ik met DirectAdmin ook httpd kan restarten voor PHP.ini helemaal ideaal voor mij ))

PS: Dat Directadmin de oorzaak is van mijn issue is niet helemaal juist, want ik wist gewoon niet hoe het werkte. Dus er was geen probleem dan mijn onkunde Maar als ik nog een keer een professionele server nodig heb zal ik je aan je staart trekken

[ Voor 34% gewijzigd door Zenda op 09-03-2018 14:17 ]

[Hero of Time]

Zenda schreef op vrijdag 9 maart 2018 @ 14:15:
PS: Dat Directadmin de oorzaak is van mijn issue is niet helemaal juist, want ik wist gewoon niet hoe het werkte. Dus er was geen probleem dan mijn onkunde Maar als ik nog een keer een professionele server nodig heb zal ik je aan je staart trekken

Het is wel de oorzaak van je probleem, want standaard LAMP opzet heeft geen Zend Framework en daardoor dus geen OPcache draaien.

Als je echt met een control panel soort ding wilt werken, is Plesk nog wel de betere. Alleen is die betaald zo te zien. VPS aanbieders kunnen het als optie bieden om te gebruiken, dat wel. Kost het je niets, het zit bij de prijs voor je VPS inbegrepen.

Je kan alsnog DA blijven gebruiken, maar dan alleen voor het herstarten van services of aanpassen van configuratiebestanden. Voor de rest wil je liever packages van de distro gebruiken, ipv self-compiled software wat DA doet. Dit ivm security updates en zaken die mogelijk stuk gaan doordat je spontaan een nieuwe major versie krijgt.

[Zenda]

Ik ben niet van het bedrijf in kwestie, maar ik heb juist daarvoor gekozen omdat er stond 'volgens de Tweakers community': https://www.argeweb.nl/vps/ - iets naar beneden scrollen bij 'Ideale VPS'.

[Hero of Time]

Hmm, dat heb ik nergens gezien hier eigenlijk. Voor een onwetende klik-klik-klaar afnemer is het prima, maar zodra er iets is, hang je gelijk omdat je dieper het systeem in moet, zoals je hebt gemerkt.