எழுத்தாளரை உடைக்காமல் VPN கண்காணிப்பு பதிவை சுழற்றுங்கள்

VPN ஆரோக்கியச் சோதனை நிமிடத்திற்கு ஒரு வரியைச் சேர்ப்பது அமைதியாக இரண்டாவது கடமையை உருவாக்குகிறது: அந்த வரிகள் வட்டிலிருந்து எவ்வாறு வெளியேறுகின்றன என்பதை முடிவு செய்வது. சுரங்கப்பாதையைச் சரிசெய்வது அந்தக் கடமைக்கு எதுவும் செய்யாது, கோப்பின் பெயரை மாற்றுவது பழைய விவரிப்பை இன்னும் வைத்திருக்கும் செயல்முறையைத் திருப்பிவிடாது. முதலில் இலக்குக் கேள்விக்கு பதிலளிக்கவும், பின்னர் எழுத்தாளர் அதைத் திறக்கும் விதத்திற்கு சுழற்சியைப் பொருத்தவும்.

சுழற்சிக் கொள்கைக்கு முன் இலக்கைத் தேர்ந்தெடுக்கவும்

தங்கள் வெளியீட்டை ஏற்கனவே இதழுக்கு அனுப்பும் systemd அலகு தக்கவைப்பை ஒரே இடத்தில் வைத்திருக்கிறது. journald SystemMaxUse மற்றும் MaxRetentionSec போன்ற வரம்புகளைச் செயல்படுத்துகிறது, எனவே அங்கு பதிவு செய்யும் கண்காணிப்பாளர் கூடுதல் வேலையின்றி வரம்பைப் பெறுகிறது. அதன் அருகில் இரண்டாவது வரம்பற்ற கோப்பைச் சேர்ப்பது பயனின்றி பராமரிப்பை இரட்டிப்பாக்குகிறது.

அர்ப்பணிக்கப்பட்ட கோப்பு தனது இடத்தைப் பெறுவது வேறு ஏதாவது அதைப் படிக்கும்போதுதான்: பாகுபடுத்தி, தணிக்கை ஏற்றுமதி அல்லது நிலையான பாதையை எதிர்பார்க்கும் பக்கம். அந்த முடிவெடுத்த பிறகு, கோப்பிற்கு உரிமையாளர், பயன்முறை மற்றும் சுழற்சிக் கொள்கை ஒன்றாக எழுதப்பட வேண்டும், ஏனெனில் மூன்றும் ஒரு தொகுப்பாக மட்டுமே சரியானவை. யாரும் உருவாக்கக்கூடிய பாதையே யாரும் மாற்றக்கூடிய பாதையும் ஆகும், எனவே அடைவு அனுமதிகளும் அதே குறிப்பில் வரும். இவை அனைத்தையும் சோதனைக்கு அருகில் எழுதுங்கள், அடுத்த திருத்தம் அதே உண்மைகளிலிருந்து தொடங்கும்.

எழுத்தாளருக்குப் பொருந்தும் தொகுதியை எழுதுங்கள்

ஒவ்வொரு அழைப்பிலும் பாதையைத் திறந்து, ஒரு வரியைச் சேர்த்து, வெளியேறும் எழுத்தாளரிடமிருந்து தொடங்குங்கள். அந்த முறை செயல்முறையின் எந்த ஒத்துழைப்பும் இல்லாமல் சுழற்சியைத் தாங்குகிறது, ஏனெனில் அடுத்த இயக்கம் அந்தப் பாதையில் தற்போது உள்ள கோப்பைத் திறக்கிறது. கீழேயுள்ள தொகுதி ஒரு வாரத்திற்கான பதிப்புகளை வைத்து, எழுத்தாளருக்குத் தேவையான உரிமையாளர் மற்றும் பயன்முறையுடன் கோப்பை மீண்டும் உருவாக்குகிறது:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

logrotate கையேடு எண்ணிக்கையைத் தக்கவைக்கப்பட்ட சுழற்றப்பட்ட பதிப்புகளின் எண்ணிக்கையாக வரையறுக்கிறது, ஏழு நாள் வரலாற்றுக்கான உத்தரவாதமாக அல்ல, மேலும் daily என்ற சொல் வேலை இயங்கும்போது மதிப்பிடப்படுகிறது, தனது சொந்த திட்டமிடலாகச் செயல்படுவதற்குப் பதிலாக. பெரும்பாலான விநியோகங்களில் systemd டைமர் அல்லது cron பதிவு ஏற்கனவே அந்த அழைப்பைக் கொண்டுள்ளது, எனவே இரண்டாவதைச் சேர்ப்பதற்கு முன் எது உள்ளது என்பதைச் சரிபார்க்கவும். உரிமையைப் பொருத்துவது தக்கவைப்பு எண்ணிக்கையை விட முக்கியம். root-க்கு மட்டுமான பயன்முறையை சேவைக் கணக்கு எழுதும் கோப்பில் நகலெடுப்பது அடுத்த சுழற்சியில் பதிவை நிறுத்தும், தோல்வி மணிநேரங்களுக்குப் பிறகு பிழையாக அல்ல, காலாவதியான நேர முத்திரையாகத் தோன்றும். வேறு இடத்திலிருந்து தொகுதியை நகலெடுக்கும் முன் எழுத்தாளரின் பயனரை உறுதிப்படுத்தவும்.

ஒருபோதும் மீண்டும் திறக்காத எழுத்தாளருக்கு வேறு தீர்வு தேவை

திறந்த விவரிப்பை வைத்திருக்கும் நீண்டகால செயல்முறை மறுபெயரிடப்பட்ட inode-க்கு எழுதுவதைத் தொடர்கிறது. இடம் விடுவிக்கப்படவில்லை, தெரியும் கோப்பு வளர்வதை நிறுத்துகிறது, இது inode-ஐச் சரிபார்க்கும் வரை உடைந்த சுழற்சியாகத் தெரிகிறது. ஒன்று செயல்முறைக்கு மீண்டும் திறக்கக் கற்பிக்கவும், அல்லது சுழற்சியை மறுபெயரிடுவதற்குப் பதிலாக நகலெடுத்து வெட்டச் செய்யவும்.

மீண்டும் திறக்கும் பாதை மென்பொருள் ஆதரிக்கும் இடத்தில் தூய்மையானது: ஆவணப்படுத்தப்பட்ட சமிக்ஞையை அனுப்பவும் அல்லது ஆவணப்படுத்தப்பட்ட கட்டளையை இயக்கவும், செயல்முறையே புதிய கோப்பைத் திறக்கட்டும். மாற்று copytruncate , இது உள்ளடக்கத்தைச் சுழற்றப்பட்ட பெயருக்கு நகலெடுத்து பின்னர் அசலை அதே இடத்தில் வெட்டுகிறது, எனவே விவரிப்பு செல்லுபடியாகவே இருக்கும், ஆனால் நகலெடுத்தல் மற்றும் வெட்டுதல் இடையே விழும் எழுத்துகள் இழக்கப்படும்.

systemd தொடங்கும் அலகுகளுக்கு, StandardOutput -ஐ இதழுக்கோ கோப்புக்கோ இயக்கி, வாழ்க்கைச் சுழற்சியை அலகே வைத்திருக்கட்டும். அளவு வரம்பின்றி tee -a வழியாகச் சேர்ப்பது shell சுழற்சியே, இது செயலிழப்பின் போது ஒரு பகிர்வை நிரப்பும், ஏனெனில் தோல்வியடையும் சோதனை ஆரோக்கியமானதை விட மிக அதிகமாகப் பதிவு செய்யும்.

நேரங்காட்டிக்காகக் காத்திருக்காமல் சுழற்சியைச் சோதிக்கவும்

பிழைத்திருத்தப் பயன்முறை என்ன நடக்கும் என்பதைத் தெரிவிக்கிறது, எதையும் தொடுவதில்லை, இது திருத்தத்திற்குப் பிறகு பாதுகாப்பான முதல் இயக்கமாக அமைகிறது. திருப்தியடைந்த பிறகு உண்மையான சுழற்சியை கட்டாயப்படுத்தவும், பின்னர் அடுத்த பதிவு வரி மறுபெயரிடப்பட்ட கோப்புக்கு அல்ல, புதிய கோப்புக்கு விழுவதை உறுதிப்படுத்தவும்:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

வெளியீட்டை அந்த வரிசையில் படியுங்கள். பிழைத்திருத்தச் சுற்று கோப்பையும் அது நோக்கும் செயல்களையும் பெயரிட வேண்டும்; கட்டாய இயக்கம் எதிர்பார்க்கப்பட்ட சுழற்றப்பட்ட பெயரை உருவாக்க வேண்டும்; tail எழுத்தாளர் மீண்டும் இயங்கிய பிறகு புதிய பதிவைக் காட்ட வேண்டும். வளரும் df மதிப்பும் சுருங்கும் தெரியும் கோப்பும் மேலே விவரிக்கப்பட்ட விவரிப்புச் சிக்கலைக் குறிக்கும்.

பதிப்புகள் ஏற்கனவே இருக்கும்போது தக்கவைப்பு எவ்வாறு செயல்படுகிறது என்பதைக் காண கட்டாய இயக்கத்தை இரண்டு முறை மீண்டும் செய்யவும். பழமையான கோப்பை நீக்குவதே எதிர்பார்க்கப்பட்ட முடிவு, நீக்கம் இல்லாதது பொதுவாகச் சுழற்றப்பட்ட பெயரில் உள்ள எண்ணிக்கையோ வைல்ட்கார்டோ logrotate உருவாக்கியதுடன் பொருந்தவில்லை என்பதைக் குறிக்கும்.

பின்னிறக்கம் மற்றும் எழுதப்பட்ட பதிவை வைத்திருங்கள்

திருத்தத்திற்கு முன் முந்தைய தொகுதியைச் சேமித்து, எந்தத் திட்டமிடல் அதை இயக்குகிறது என்பதைக் குறிக்கவும், ஏனெனில் கோப்பை மீட்டெடுத்து நேரங்காட்டியை மீட்டெடுக்காத பின்னிறக்கம் அசல் சிக்கலின் பாதியை மீண்டும் உருவாக்கும். மீட்டெடுத்த பிறகு ஒருமுறை கையால் சுழற்றி, பின்னர் எழுத்தாளரின் கணக்கு பதிவுப் பாதையில் எழுத முடியும் என்பதை உறுதிப்படுத்தவும். சேவை systemd கீழ் இயங்கினால், அதன் வெளியீட்டு மறுவழியில் ஏதேனும் மாற்றத்திற்குப் பிறகு அலகை மீண்டும் ஏற்றவும், ஏனெனில் இயங்கும் செயல்முறை பழைய இலக்குக்கு எழுதிக்கொண்டே இருக்கும். அலகு தூய்மையாகத் திரும்பியது என நம்புவதற்குப் பதிலாக அடுத்த சில பதிவு வரிகளை நீங்களே படியுங்கள்.

பயன்முறை, உரிமையாளர், தக்கவைப்பு எண்ணிக்கை மற்றும் எதிர்பார்க்கப்படும் வட்டு பட்ஜெட்டைச் சோதனையின் அருகிலேயே பதிவு செய்யவும். பின்னர் சோதனை ஒரு முறை ஸ்கிரிப்டிலிருந்து டெமானாக மாறும்போது, சுழற்சிக் கொள்கையும் அதனுடன் மாற வேண்டும், அந்தக் குறிப்பே அடுத்த நபருக்கு எந்த அனுமானம் உடைந்தது என்பதைச் சொல்லும்.

இறுதியாக, பதிவு முடிவை மீட்டெடுப்பு முடிவிலிருந்து தனியாக வைத்திருங்கள். தோல்வியடைந்த சோதனை இணைப்பின் சொந்த மீட்டெடுப்புக் கொள்கையைப் பின்பற்ற வேண்டும், logrotate-க்குள் மறைந்திருக்கும் விதியை அல்ல, எந்தப் பதிவு ஏற்பாடும் இயங்கும் சுரங்கப்பாதையை மீண்டும் தொடங்குவதற்கான காரணமாக இருக்கக்கூடாது.