Miks on Adminiser.php tühi? Ümbernimetamine toimib hästi? Põhjuse analüüs ja kolmeastmeline lahendus.

Eile pärastlõunal seadistasin serveris andmebaasi haldustööriista Adminer. Adminer on kerge ja hõlpsasti kasutatav; üks PHP-fail teeb töö ära, erinevalt phpMyAdmini , mis nõuab hunnikut sõltuvusi. Laadisin ametlikult veebisaidilt alla uusima versiooni, laadisin selle serverisse üles, seadsin õigused ja avasin brauseri, et seda proovida.

Siis läks kõik tühjaks.

Värskendasin lehte kolm korda, sõrmed valutasid nii paljudest F5 vajutamistest. Ikka ei midagi. Avasin brauseri arendustööriistad; see näitas viga 200 OK, aga vastuse sisu oli tühi. Olin täiesti jahmunud. Mis toimus?

Mõtlesin selle üle hetke. Kas see võiks olla failiõiguste probleem? Kontrollisin ja see oli 755. Kas see võiks olla PHP versiooni ühildumatuse probleem? Kontrollisin ja see on PHP 8.2, mis on korras. Kas fail ise võib olla vigane? Laadisin alla uue koopia, kirjutasin selle üle ja see on ikka tühi.

Mingil seletamatul põhjusel mõtlesin, et miks mitte proovida oma nime muuta?

Ma nimetasin adminer.php ümber adminer1.php-ks ja värskendasin lehte.

Juurdepääs oli edukas.

Olin siiralt hämmeldunud. Sama fail, sama kood, sama server ja sellele pääseb ligi ainult nime muutes? Mis müstiline loogika see on?

Tühja adminer.php faili probleem

Hiljem sain aru, et see polnud mingi ebausk; probleemi põhjustas PHP vahemällu salvestamine.

OPcache, lühend sõnadest Opcode Cache, on PHP jõudluse optimeerimise laiendus. Selle põhimõte on lihtne: PHP on interpreteeritud keel ja iga päring nõuab enne täitmist PHP koodi kompileerimist opkoodiks. OPcache vahemällu salvestab kompileeritud tulemuse mällu, võimaldades järgnevatel päringutel kasutada vahemällu salvestatud versiooni otse ilma uuesti kompileerimiseta, mille tulemuseks on märkimisväärne jõudluse paranemine.

Aga just seal probleem peitubki.

Varem kuvas adminer.php veateadet „Faili ei leitud” (laadisin üles vale faili) ja OPcache oli selle vale sisuga kompileeritud tulemuse vahemällu salvestanud. Hiljem asendasin adminer.php õige koodiga, kuid OPcache ignoreeris seda ja jätkas vana vahemälu lugemist mälust, mille tulemuseks oli tühi leht või vana veateade.

Kui nimetate selle ümber adminer1.php-ks, saab sellest OPcache'i jaoks täiesti uus failitee ning see laadib selle uuesti ja lahendab selle õigesti.

See on nagu oleksid juba uue raamatu saanud, aga raamatukogu kartoteegikaardil on ikka veel vana raamatu number. Kui sa seda riiulilt otsima lähed, on see muidugi tühi. Aga kui sa raamatu pealkirja muudad, loob raamatukogu sulle uue kartoteegikaardi ja siis saad selle üles leida.

Põhjus 1: OPcache'i vahemälu põhjustab tühje kohti

Kuidas sellega toime tulla?

Taaskäivitage PHP-FPM teenus ja tühjendage OPcache vahemälu.

# 查看正在运行的PHP版本
php -v

# 重启对应的PHP-FPM（例如PHP 8.5）
sudo systemctl restart php8.5-fpm

# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpm

Pärast taaskäivitamist nimeta fail tagasi nimeks adminer.php, värskenda veebilehte (soovitatav on vajutada brauseri värskendamiseks Ctrl+F5) ja probleem peaks lahenema.

Aga lugu pole veel läbi.

Pärast PHP-FPM-i taaskäivitamist muutsin faili adminer.php tagasi, värskendasin lehte, aga see oli ikka tühi. Olin täiesti hämmingus.

Põhjus 2: Nginxi konfiguratsioonireeglite piirangud

See viib teise võimaliku põhjuseni.

Nginxi konfiguratsioonifailil võivad olla adminer.php-d piiravad erireeglid.

Ma seadistasin varem HestiaCP paneelil Fail2Bani ja kirjutasin adminer.php jaoks täpse vaste reegli, et vältida brute-force rünnakuid. Reegel kõvakodeeris failinime adminer.php, nii et kui sa selle ümber nimetasid adminer1.php-ks, said sa sellest Nginxi reeglist mööda minna ja sellele tavapäraselt ligi pääseda.

Veaotsingu meetod on lihtne: otsige Nginxi konfiguratsioonist kõvakodeeritud kirjeid.

sudo grep -rn "adminer.php" /etc/nginx/

Kui leiad reegleid nagu `location = /adminer.php { … }`, tähendab see, et Nginx käsitleb seda konkreetset failinime spetsiaalselt. Lihtsalt kustuta või muuda see.

Põhjus 3: PHP vea kuvamise seaded

Kolmas põhjus on peenem.

PHP skripti fail katkestatakse või see annab vea, aga leht keelab vea kuvamise (display_errors = Off). Tootmiskeskkonnas peidab PHP vead vaikimisi, kuvades tühja lehe. Kui teie sisestusfail (nt index.php) mingil põhjusel "./adminer.php" lisamise ajal kokku jookseb, muutub leht lihtsalt tühjaks.

Sellisel juhul on kõige usaldusväärsem meetod vealogi kontrollimine:

# 查看Nginx错误日志
sudo tail -n 20 /var/log/nginx/error.log

# 或者查看HestiaCP对应域名的error日志
sudo tail -n 20 /var/log/nginx/domains/adminer.domain.com.error.log

Logi näitab sulle valge ekraani tegelikku põhjust.

Ausalt öeldes leidsin probleemi lõpuks error.logi kontrollides. Selgus, et adminer.php kutsus välja olematu PHP laienduse ja display_errors oli välja lülitatud, seega oli leht tühi, aga vealogi salvestas selle selgelt.

Lahendused ja tõrkeotsingu sammud

See juhtum on mulle sügava mulje jätnud.

Tehnilised probleemid ei ole tihtipeale nii lihtsad, kui pealtnäha paistavad. Tühi adminer.php fail võib esmapilgul tunduda failiprobleemina, kuid sügavam uurimine võib paljastada vahemäluprobleemi, hiljem konfiguratsiooniprobleemi ja veelgi hiljem koodi enda probleemi.

Kui sa pole programmeerija, võid arvata, et need asjad pole sinu jaoks olulised. Aga mõtle sellele: igal rakendusel, mida sa kasutad, igal veebilehel, mida külastad, töötab kulisside taga sarnane süsteem. Vahemällu salvestamine, seadistamine, veakäsitlus – need mõisted on tegelikult kõikjal.

Täpselt nagu meie, inimesed. Tihtilugu võivad meie "sümptomid", nagu edasilükkamine, ärevus ja ärrituvus, pealtnäha laiskusena tunduda, aga sügavamale kaevudes võivad need olla tingitud ebaselgetest eesmärkidest, sügavamast kaevamisest, hirmust läbikukkumise ees ja veelgi sügavamal lapsepõlvekogemuste kujundatud mõtteviisist.

Ainult siis, kui oleme kindlaks teinud tegeliku põhjuse, saame välja kirjutada õige ravimi.

Lõpuks, kui teil tekib ka tühja adminer.php faili probleem, kontrollige seda järgmises järjekorras:

Esmalt taaskäivitage PHP-FPM ja tühjendage vahemälu, seejärel kontrollige Nginxi konfiguratsiooni ja lõpuks error.log-faili.

Enamikul juhtudel piisab probleemi lahendamiseks kahest esimesest sammust.

Muidugi, kui see ikka ei aita, siis kontrollige error.log faili.

See ütleb sulle vastuse.

Kuna oled siiani lugenud, siis kui see oli sulle kasulik, siis palun laigi ja jaga seda. Kui soovid esimesena uuendusi saada, võid mind ka jälgida!

Tänan teid minu artikli lugemise eest. Näeme järgmine kord.