கட்டுரை அடைவு
நேற்று மதியம், நான் சர்வரில் அட்மினர் தரவுத்தள மேலாண்மைக் கருவியை உள்ளமைத்துக் கொண்டிருந்தேன். அட்மினர் இலகுவானது மற்றும் பயன்படுத்த எளிதானது; பல சார்புநிலைகளைக் கோரும் phpMyAdmin போலல்லாமல், ஒரே ஒரு PHP கோப்பு அந்த வேலையைச் செய்துவிடுகிறது . நான் அதிகாரப்பூர்வ இணையதளத்திலிருந்து சமீபத்திய பதிப்பைப் பதிவிறக்கம் செய்து, அதை சர்வரில் பதிவேற்றி, அனுமதிகளை அமைத்து, அதைச் சோதித்துப் பார்க்கத் தயாராக எனது உலாவியைத் திறந்தேன்.
பிறகு, எல்லாம் இருண்டு போனது.
F5 விசையை பலமுறை அழுத்தியதால் என் விரல்கள் வலிக்க, நான் பக்கத்தை மூன்று முறை புதுப்பித்தேன். அப்போதும் ஒன்றும் நடக்கவில்லை. நான் உலாவியின் டெவலப்பர் கருவிகளைத் திறந்தேன்; அது 200 OK பிழையைக் காட்டியது, ஆனால் பதில் பகுதி காலியாக இருந்தது. நான் முற்றிலும் திகைத்துப் போனேன். என்னதான் நடக்கிறது?
நான் ஒரு கணம் யோசித்தேன். இது கோப்பு அனுமதிச் சிக்கலாக இருக்குமோ? சரிபார்த்தேன், அது 755 ஆக இருந்தது. இது PHP பதிப்பு பொருந்தாமையாக இருக்குமோ? சரிபார்த்தேன், அது PHP 8.2, அது சரியாகத்தான் இருக்கிறது. கோப்பிலேயே ஏதேனும் கோளாறு இருக்குமோ? நான் ஒரு புதிய நகலைப் பதிவிறக்கம் செய்து, அதன் மீது மேலெழுதினேன், ஆனாலும் அது இன்னும் காலியாகவே இருக்கிறது.
விவரிக்க முடியாத ஏதோ ஒரு காரணத்திற்காக, என் பெயரை மாற்றிப் பார்த்தால் என்ன என்று எனக்குத் தோன்றியது.
நான் adminer.php என்பதை adminer1.php எனப் பெயர் மாற்றி, பக்கத்தைப் புதுப்பித்தேன்.
அணுகல் வெற்றிகரமாக இருந்தது.
நான் உண்மையிலேயே திகைத்துப் போனேன். அதே கோப்பு, அதே நிரல், அதே சேவையகம், ஆனால் பெயரை மட்டும் மாற்றுவதன் மூலம் அதை அணுக முடிகிறதா? இது என்ன விதமான புரியாத தர்க்கம்?
adminer.php கோப்பு காலியாக உள்ளது.
பின்னர் தான் இது ஏதோ மூடநம்பிக்கை அல்ல, PHP கேச்சிங் தான் இந்தப் பிரச்சனைக்குக் காரணம் என்பதை நான் உணர்ந்தேன்.
OPcache, அதாவது Opcode Cache, என்பது PHP-க்கான ஒரு செயல்திறன் மேம்பாட்டு நீட்டிப்பாகும். இதன் கொள்கை எளிமையானது: PHP ஒரு விளக்கமொழி (interpreted language), மேலும் ஒவ்வொரு கோரிக்கைக்கும், செயல்படுத்தப்படுவதற்கு முன்பு PHP குறியீடு opcode-ஆகத் தொகுக்கப்பட வேண்டும். OPcache, தொகுக்கப்பட்ட முடிவை நினைவகத்தில் தற்காலிகமாகச் சேமித்து வைக்கிறது. இதனால், அடுத்தடுத்த கோரிக்கைகள் மீண்டும் தொகுக்கப்படாமல், தற்காலிகமாகச் சேமிக்கப்பட்ட பதிப்பை நேரடியாகப் பயன்படுத்த முடிகிறது. இதன் விளைவாக, செயல்திறனில் குறிப்பிடத்தக்க முன்னேற்றம் ஏற்படுகிறது.
ஆனால், பிரச்சனை அங்கேயேதான் இருக்கிறது.
முன்னதாக, adminer.php "கோப்பு காணப்படவில்லை" என்று காட்டியது (நான் தவறான கோப்பைப் பதிவேற்றியிருந்தேன்), மேலும் OPcache அந்தத் தவறான உள்ளடக்கத்தின் தொகுக்கப்பட்ட முடிவைத் தற்காலிக நினைவகத்தில் சேமித்திருந்தது. பின்னர், நான் adminer.php-ஐ சரியான குறியீட்டைக் கொண்டு மாற்றினேன், ஆனால் OPcache அதைப் புறக்கணித்து, நினைவகத்திலிருந்து பழைய தற்காலிக நினைவகச் சேமிப்பைத் தொடர்ந்து படித்தது. இதன் விளைவாக, ஒரு வெற்றுப் பக்கம் அல்லது பழைய பிழைச் செய்தி தோன்றியது.
நீங்கள் அதன் பெயரை adminer1.php என மாற்றும்போது, அது OPcache-க்கு முற்றிலும் புதிய கோப்புப் பாதையாக மாறி, அதைச் சரியாக மீண்டும் ஏற்றித் தீர்க்கும்.
நீங்கள் ஏற்கனவே ஒரு புதிய புத்தகத்தை வாங்கியிருந்தாலும், நூலகத்தின் அட்டையில் பழைய புத்தகத்தின் அழைப்பு எண் அப்படியே இருப்பது போன்றது இது. நீங்கள் அதை அலமாரியில் தேடிப் பார்க்கும்போது, நிச்சயமாக அது காலியாக இருக்கும். ஆனால் நீங்கள் புத்தகத்தின் தலைப்பை மாற்றினால், நூலகம் உங்களுக்காக ஒரு புதிய அட்டையை உருவாக்கும், அதன் பிறகு நீங்கள் அதைக் கண்டுபிடிக்க முடியும்.
காரணம் 1: OPcache கேச் வெற்று இடங்களை ஏற்படுத்துகிறது
அதை எவ்வாறு சமாளிப்பது?
PHP-FPM சேவையை மறுதொடக்கம் செய்து, OPcache கேச்-ஐ அழிக்கவும்.
# 查看正在运行的PHP版本
php -v
# 重启对应的PHP-FPM（例如PHP 8.5）
sudo systemctl restart php8.5-fpm
# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpmமறுதொடக்கம் செய்த பிறகு, கோப்பின் பெயரை மீண்டும் adminer.php என மாற்றி, வலைப்பக்கத்தைப் புதுப்பிக்கவும் (உலாவியை வலுக்கட்டாயமாகப் புதுப்பிக்க Ctrl+F5 ஐ அழுத்துவது பரிந்துரைக்கப்படுகிறது), இதன்மூலம் சிக்கல் தீர்க்கப்பட்டுவிடும்.
ஆனால், கதை இன்னும் முடியவில்லை.
PHP-FPM-ஐ மறுதொடக்கம் செய்த பிறகு, நான் adminer.php கோப்பை மீண்டும் பழையபடி மாற்றி, பக்கத்தைப் புதுப்பித்தேன், ஆனால் அது இன்னும் வெற்றுப் பக்கமாகவே இருந்தது. நான் முற்றிலும் திகைத்துப் போனேன்.
காரணம் 2: Nginx உள்ளமைவு விதி கட்டுப்பாடுகள்
இது இரண்டாவது சாத்தியமான காரணத்திற்கு வழிவகுக்கிறது.
Nginx உள்ளமைவு கோப்பில் adminer.php-ஐ கட்டுப்படுத்தும் சிறப்பு விதிகள் இருக்கலாம்.
நான் முன்பு HestiaCP பேனலில் Fail2Ban-ஐ உள்ளமைத்து , ப்ரூட்-ஃபோர்ஸ் தாக்குதல்களைத் தடுப்பதற்காக adminer.php கோப்பிற்கு ஒரு துல்லியமான பொருத்த விதியை எழுதினேன் . அந்த விதி, adminer.php என்ற கோப்புப் பெயரை நிரலில் நேரடியாகக் குறிப்பிட்டிருந்தது. எனவே, நீங்கள் அதன் பெயரை adminer1.php என மாற்றியவுடன், இந்த Nginx விதியை மீறி அதைச் சாதாரணமாக அணுக முடிந்தது.
பிழையைச் சரிசெய்யும் முறை எளிமையானது: Nginx உள்ளமைவில் நிரலில் நேரடியாக எழுதப்பட்ட உள்ளீடுகளைத் தேடுங்கள்.
sudo grep -rn "adminer.php" /etc/nginx/`location = /adminer.php { … }` போன்ற விதிகளை நீங்கள் கண்டால், Nginx இந்தக் குறிப்பிட்ட கோப்புப் பெயரைச் சிறப்பாகக் கையாளுகிறது என்று அர்த்தம். அதை நீக்கிவிடவும் அல்லது மாற்றியமைக்கவும்.
காரணம் 3: PHP பிழை காட்சி அமைப்புகள்
மூன்றாவது காரணம் சற்று நுட்பமானது.
PHP ஸ்கிரிப்ட் இடைமறிக்கப்பட்டாலோ அல்லது ஒரு பிழையை ஏற்படுத்தினாலோ, பக்கம் பிழைக் காட்சியை முடக்கிவிடும் (display_errors = Off). ஒரு உற்பத்திச் சூழலில், PHP இயல்பாகவே பிழைகளை மறைத்து, ஒரு வெற்றுப் பக்கத்தைக் காண்பிக்கும். "./adminer.php" கோப்பைச் சேர்க்க முயற்சிக்கும்போது, உங்கள் உள்ளீட்டுக் கோப்பு (எ.கா., index.php) ஏதேனும் காரணத்தால் செயலிழந்தால், பக்கம் வெறுமனே வெற்றுப் பக்கமாக மாறிவிடும்.
இந்தச் சூழ்நிலையில், பிழைப் பதிவேட்டைச் சரிபார்ப்பதே மிகவும் நம்பகமான முறையாகும்:
# 查看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வெள்ளைத்திரை தோன்றியதற்கான உண்மையான காரணத்தை அந்தப் பதிவேடு உங்களுக்குத் தெரிவிக்கும்.
உண்மையைச் சொல்லப்போனால், error.log-ஐச் சரிபார்த்தபோதுதான் நான் இறுதியாகப் பிரச்சினையைக் கண்டுபிடித்தேன். adminer.php இல்லாத ஒரு PHP நீட்டிப்பை அழைத்துக் கொண்டிருந்ததும், display_errors முடக்கப்பட்டிருந்ததும் தெரியவந்தது. அதனால் பக்கம் வெற்றுப் பக்கமாக இருந்தது, ஆனால் error log அதைத் தெளிவாகப் பதிவு செய்திருந்தது.
தீர்வுகள் மற்றும் பிழைத்திருத்த வழிமுறைகள்
இந்தச் சம்பவம் என் மனதில் ஆழமான தாக்கத்தை ஏற்படுத்தியுள்ளது.
தொழில்நுட்பச் சிக்கல்கள் பெரும்பாலும் மேலோட்டமாகத் தோன்றுவது போல் எளிமையானவை அல்ல. ஒரு வெற்று adminer.php கோப்பு, முதல் பார்வையில் ஒரு கோப்புச் சிக்கலாகத் தோன்றலாம், ஆனால் ஆழமாக ஆராய்ந்தால் அது ஒரு கேச்சிங் சிக்கலாக இருக்கலாம், இன்னும் ஆழமாகச் சென்றால் அது ஒரு உள்ளமைவுச் சிக்கலாக இருக்கலாம், மேலும் அதற்கும் மேலாக அது நிரலிலேயே உள்ள ஒரு சிக்கலாகவும் இருக்கலாம்.
நீங்கள் ஒரு நிரலாளர் இல்லையென்றால், இந்த விஷயங்கள் உங்களுக்குத் தொடர்பில்லாதவை என்று நினைக்கலாம். ஆனால் யோசித்துப் பாருங்கள்: நீங்கள் பயன்படுத்தும் ஒவ்வொரு செயலியிலும், நீங்கள் பார்வையிடும் ஒவ்வொரு வலைப்பக்கத்திலும், திரைக்குப் பின்னால் இதே போன்ற ஒரு அமைப்பு இயங்குகிறது. கேச்சிங், உள்ளமைவு, பிழை கையாளுதல்—இந்தக் கருத்துக்கள் உண்மையில் எல்லா இடங்களிலும் உள்ளன.
நம்மைப் போலவேதான். பல நேரங்களில், நாம் வெளிப்படுத்தும் தள்ளிப்போடுதல், பதட்டம், எரிச்சல் போன்ற 'அறிகுறிகள்' மேலோட்டமாகப் பார்க்கும்போது சோம்பேறித்தனம் போலத் தோன்றலாம். ஆனால், ஆழமாக ஆராய்ந்து பார்த்தால், அவை தெளிவற்ற இலக்குகள், மேலும் தீவிரமாக முயற்சித்தல், தோல்வி பயம், இன்னும் ஆழமாக, குழந்தைப்பருவ அனுபவங்களால் உருவான ஒரு மனநிலை ஆகியவற்றால் ஏற்படக்கூடும்.
உண்மையான மூல காரணத்தைக் கண்டறிந்தால் மட்டுமே சரியான மருந்தை பரிந்துரைக்க முடியும்.
இறுதியாக, நீங்களும் adminer.php கோப்பு காலியாக இருக்கும் சிக்கலை எதிர்கொண்டால், இந்த வரிசையில் சரிபார்க்கவும்:
முதலில், PHP-FPM-ஐ மறுதொடக்கம் செய்து கேச்-ஐ அழிக்கவும், பின்னர் Nginx உள்ளமைவைச் சரிபார்க்கவும், இறுதியாக error.log-ஐச் சரிபார்க்கவும்.
பெரும்பாலான சந்தர்ப்பங்களில், சிக்கலைத் தீர்க்க முதல் இரண்டு படிகளே போதுமானவை.
நிச்சயமாக, அதுவும் வேலை செய்யவில்லை என்றால், error.log-ஐச் சரிபார்க்கவும்.
அது உங்களுக்குப் பதிலைச் சொல்லும்.
இதுவரை படித்த உங்களுக்கு இது பயனுள்ளதாக இருந்தால், தயவுசெய்து லைக் செய்து பகிருங்கள். புதிய தகவல்களை முதலில் பெற விரும்பினால், நீங்கள் என்னைப் பின்தொடரவும் செய்யலாம்!
என் கட்டுரையைப் படித்ததற்கு நன்றி. அடுத்த முறை சந்திப்போம்.
சென் வெய்லியாங்கின் வலைப்பதிவில் ( https://www.chenweiliang.com/ ) பகிரப்பட்ட "Adminer.php அணுகல் காலியாக உள்ளதா? பெயர் மாற்றம் சாதாரணமாக செயல்படுகிறதா? காரணங்களின் பகுப்பாய்வு மற்றும் சிக்கலை முழுமையாக தீர்க்க 3 படிகள்" என்ற கட்டுரை உங்களுக்கு உதவியாக இருக்கும் என்று நம்புகிறோம்.
இந்தக் கட்டுரையின் இணைப்பைத் தாராளமாகப் பகிரவும்: https://www.chenweiliang.com/cwl-34403.html