ஒரு server-ஐ புதிய VPS-க்கு பாதுகாப்பாக மாற்றுவது எப்படி?

ஒரு server-ஐ புதிய VPS-க்கு rehearsed cutover முறையில் மாற்றுதல்

ஒரு server-ஐ புதிய VPS-க்கு மாற்றும்போது, அதை வெறும் நகலாகக் கருதாமல், திட்டமிடப்பட்ட cutover-ஆகக் கையாளவும். புதிய server-ஐ புதிதாக உருவாக்கவும், தரவுகளை இருமுறை sync செய்யவும், DNS-ஐ மாற்றும் முன்பே புதிய server அதன் சொந்த IP முகவரியில் சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்தவும். அதன் பிறகு DNS பதிவுகளை மாற்றவும், புதிய server சரியாகச் செயல்படுவது உறுதியாகும் வரை பழைய server-ஐ அப்படியே வைத்திருக்கவும். தரவுகளை நகலெடுப்பது எளிதான பகுதி. செயல்பாடுகளின் வரிசைமுறையே இந்த மாற்றம் சிக்கலின்றி நடக்குமா அல்லது செலவு வைக்குமா என்பதைத் தீர்மானிக்கிறது.

இந்த வழிகாட்டி, ஒரு web application, database மற்றும் TLS (transport layer security) certificate இயங்கும் ஒரு Linux server-ஐ மாற்றுவதை உள்ளடக்கியது. இது பெரும்பாலான single-server அமைப்புகளுக்குப் பொருந்தும். இதில் இரண்டு hosts சம்பந்தப்பட்டிருப்பதால், ஒவ்வொரு உதாரணத்திலும் அது எந்த host-ல் இயங்குகிறது என்பது குறிப்பில் கொடுக்கப்பட்டுள்ளது. முகவரிகள் ஆவணப்படுத்தப்பட்ட வரம்புகளிலிருந்து எடுக்கப்பட்டுள்ளன: 198.51.100.10 என்பது பழைய server, 203.0.113.20 என்பது புதிய server.

தொடங்குவதற்கு முன் முழு runbook-ஐயும் படிக்கவும். முதல் படியான DNS TTL-ஐக் குறைக்கும் செயலை, நீங்கள் முக்கியமாகக் கருதும் மாற்றத்திற்குச் சில நாட்களுக்கு முன்பே செய்ய வேண்டும்.

எதையும் கட்டமைக்கும் முன் பட்டியலைச் சரிபார்க்கவும்

நீங்கள் விவரிக்காத ஒரு server-ஐ மீண்டும் கட்டமைக்க முடியாது. பழைய server என்னென்ன பணிகளைச் செய்கிறது என்பதை எழுத ஒரு மணிநேரம் செலவிடுங்கள். ஏனெனில், migration-க்குப் பிறகு தோல்வியடையும் விஷயம் எப்போதும் யாரும் கவனிக்காத ஒன்றாகவே இருக்கும்: ஒரு cron job, firewall விதிவிலக்கு, அல்லது application directory-க்கு வெளியே இருக்கும் environment file.

பழைய server-ல் இவற்றை இயக்கி, அதன் வெளியீட்டைப் புதிய server-லிருந்து அணுகக்கூடிய இடத்தில் சேமித்து வையுங்கள்.

# old server: packages you asked for, not the dependencies they pulled in
apt-mark showmanual > ~/inv-packages.txt

# old server: what runs now, and what starts at boot
systemctl list-units --type=service --state=running --no-pager > ~/inv-services.txt
systemctl list-unit-files --state=enabled --no-pager >> ~/inv-services.txt
systemctl list-timers --all --no-pager > ~/inv-timers.txt

# old server: what is listening, on which address and port
sudo ss -tulpn > ~/inv-ports.txt

# old server: human accounts, skipping the system ones
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd

apt-mark showmanual என்பது பயனுள்ள பட்டியலாகும், ஏனெனில் இது dependency-ஆக வந்த அனைத்தையும் நீக்கிவிடும். ஐந்து ஆண்டுகள் பழமையான server-ல் முழுமையான dpkg --get-selections கட்டளையை இயக்கினால், அது இரண்டாயிரம் வரிகளைக் காட்டும், ஆனால் அதன் நோக்கம் குறித்து எதுவும் சொல்லாது.

திட்டமிடப்பட்ட பணிகள் (Scheduled work) இரண்டு இடங்களில் மறைந்திருக்கும், எனவே இரண்டையும் சரிபார்க்கவும். மாதத்திற்கு ஒருமுறை மட்டுமே இயங்கும் ஒரு job-ஐ, migration முடிந்த ஆறு வாரங்களுக்குப் பிறகுதான் நீங்கள் கண்டறிவீர்கள்.

# old server: per-user crontabs, then the system drop-ins
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -lu "$u" 2>/dev/null | sed "s/^/$u: /"; done
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

அடுத்து, சாதாரண கோப்புகள் அல்லாத பகுதிகள்: firewall விதிகள், certificates, databases மற்றும் நீங்கள் உண்மையில் நகர்த்த வேண்டிய தரவின் அளவு.

# old server
sudo ufw status verbose        # or: sudo nft list ruleset
sudo certbot certificates
sudo -u postgres psql -c '\l'  # or: sudo mysql -e 'SHOW DATABASES;'
sudo du -xh --max-depth=1 / | sort -h

certbot certificates ஒவ்வொரு certificate பெயர், அது உள்ளடக்கும் domains, அதன் காலாவதி தேதி மற்றும் வட்டில் உள்ள கோப்புகளின் பாதைகளை அச்சிடும். அந்த வெளியீடுதான் உங்கள் TLS சரிபார்ப்புப் பட்டியல் (checklist). du -x ஒரே filesystem-க்குள் இருக்கும், எனவே அது mounted backup volume-க்குள் சென்று பத்து மடங்கு பெரிய அளவைக் காட்டாது.

இரண்டு விஷயங்கள் server-க்கு வெளியே இருப்பதால் எப்போதும் மறந்துபோகின்றன. முதலாவது, உங்கள் server-ன் IP address-ஐ allowlist-ல் வைத்திருக்கும் மூன்றாம் தரப்பு நிறுவனங்கள்: payment gateway, managed database, SMTP relay அல்லது partner API. புதிய server-க்கு புதிய IP address இருப்பதால், cutover-க்கு முன்பே அந்த allowlists-ல் புதிய IP-ஐச் சேர்க்க வேண்டும், பிறகு அல்ல. இரண்டாவது, நீங்கள் உருவாக்காத DNS பதிவுகள், உதாரணமாக பழைய IP-ஐக் குறிப்பிடும் MX record அல்லது SPF record.

பழைய root filesystem-ஐ clone செய்வதற்குப் பதிலாக ஏன் புதிதாக உருவாக்க வேண்டும்

புதிய VPS-ல் முழு root filesystem-ஐயும் clone செய்வது விரைவானதாகத் தோன்றலாம்; ஆனால், அது சிக்கல்களை உருவாக்கும் வரை மட்டுமே. பல ஆண்டுகளாகப் பயன்பாட்டில் உள்ள ஒரு root filesystem-ல், ஆவணப்படுத்தப்படாத கையால் திருத்தப்பட்ட config கோப்புகள், தற்போது இல்லாத repository-களிலிருந்து பெறப்பட்ட packages மற்றும் பழைய தளத்தின் virtual hardware-க்கு ஏற்ப அமைக்கப்பட்ட boot setup போன்றவை இருக்கும். நீங்கள் இடம்பெயரக் காரணமான சிக்கல்களையும் சேர்த்து, அனைத்தையும் அப்படியே புதிய இடத்திற்கு மாற்றுகிறீர்கள்.

புதிதாக உருவாக்குவது முதல் நாளில் மெதுவாகத் தெரிந்தாலும், அதன் பிறகு ஒவ்வொரு நாளும் செலவைக் குறைக்கும். தற்போதைய release-ஐ நிறுவி, அடிப்படை hardening-ஐச் செய்துவிட்டு, தரவுகளை மட்டும் நகர்த்துங்கள்: application directory, site configs, database dump, certificates மற்றும் user uploads. உங்களால் விளக்க முடியாத எதையும் புதிய சூழலுக்குக் கொண்டு வர வேண்டாம். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டுதலைப் பின்பற்றி புதிய server-ஐத் தொடங்குங்கள். பின்னர், inventory-ல் உள்ள ஒவ்வொரு service-ஆக ஒவ்வொன்றாகச் சேர்த்து, ஒவ்வொன்றையும் உறுதிப்படுத்திய பிறகு அடுத்ததற்குச் செல்லுங்கள்.

Image அல்லது snapshot restore எப்போது சரியான தீர்வாகும்

மீண்டும் கட்டமைப்பதற்கு (rebuild) ஒரு நேர்மையான விதிவிலக்கு உண்டு. பழைய server boot ஆகவில்லை என்றாலோ, அல்லது அந்த application-ஐ இனி யாரும் source-லிருந்து மீண்டும் உருவாக்க முடியாது என்றாலோ, provider image அல்லது snapshot restore-ஐப் பயன்படுத்துவது நடைமுறைக்கு ஏற்ற தீர்வாகும். இதற்கு சில வரம்புகள் உள்ளன: இது ஒரே provider-க்குள் மட்டுமே செயல்படும், பெரும்பாலும் ஒரே plan family-க்குள் மட்டுமே இயங்கும். ஏனெனில், restore செய்யப்பட்ட disk அந்த platform-ன் virtual devices மற்றும் network naming-ஐ எதிர்பார்க்கும்.

இயங்கிக்கொண்டிருக்கும் ஒரு server-ன் snapshot-ஐ எடுக்கும்போது, நேரலையில் இருக்கும் database-ன் file-level copy-ல் ஏற்படும் அதே consistency சிக்கல்கள் இதிலும் ஏற்படும். Image restore-ஐ ஒரு migration திட்டமாக கருதாமல், ஒரு மீட்பு நடவடிக்கையாக (recovery route) மட்டுமே கருதுங்கள். ஒரு திட்டத்தை உருவாக்கும் முன் snapshot ஏன் backup-க்கு இணையானது அல்ல என்பதைப் படித்துப் பார்க்கவும்.

கோப்புகள் எவ்வாறு நகர்கின்றன: SSH வழியாக rsync

பழைய server-லிருந்து புதிய server-க்கு கோப்புகளைத் தள்ள (push), பழைய server-ல் rsync கட்டளையை இயக்கவும். பழைய server-ல் ஏற்கனவே தரவுகள் இருப்பதால், sudo அனுமதியுடன் அனைத்தையும் வாசிக்க முடியும் என்பதால், இந்த முறை எளிதானது.

# old server: dry run first, and read what it says it will do
sudo rsync -aHAX --dry-run --itemize-changes \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

# old server: the real bulk pass
sudo rsync -aHAX --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

Flags மிக முக்கியம். -a கோப்புகளின் அனுமதிகள் (permissions), நேர முத்திரைகள் (timestamps), symbolic links மற்றும் உரிமையாளர் விவரங்களைப் பாதுகாக்கிறது. -H hard links-களைத் தனித்தனி நகல்களாக மாற்றாமல், அப்படியே பராமரிக்கிறது. -A POSIX ACL-களை (access control lists) நகலெடுக்கிறது, -X extended attributes-களை நகலெடுக்கிறது. இந்த கடைசி இரண்டையும் பயன்படுத்தாவிட்டால், கோப்புகள் ஒரே மாதிரியாகத் தெரிந்தாலும், அவற்றின் செயல்பாடு மாறுபடலாம். ஏனெனில், SELinux labels மற்றும் ACL-கள் extended attributes-ல் மட்டுமே சேமிக்கப்படுகின்றன.

பெரும்பாலான தோல்விகளுக்கு இரண்டு காரணங்கள் உள்ளன.

Trailing slash தரவுகள் எங்கு சேரும் என்பதைத் தீர்மானிக்கிறது. /srv/app/ என்பது அந்த directory-க்குள் உள்ள உள்ளடக்கங்களைக் குறிக்கும். /srv/app என்பது அந்த directory-யையே குறிக்கும். இதில் தவறு செய்தால், புதிய server-ல் /srv/app/app உருவாகிவிடும். இதனால், application-க்குத் தேவையான கோப்புகள் தவறான பாதையில் இருப்பதால், அவை கிடைக்கவில்லை என்று பிழை காட்டும்.

sudo-ன் கீழ், tilde (~) என்பது root-ன் home directory-யைக் குறிக்கும். sudo rsync-க்குள் -e 'ssh -i ~/.ssh/id_ed25519' என்று எழுதினால், அது உங்கள் home directory-க்கு பதிலாக /root/.ssh-ல் key-ஐத் தேடும். key அங்கு இல்லையென்றால், SSH Permission denied (publickey) பிழையைக் காட்டும், rsync rsync: connection unexpectedly closed பிழையுடன் வெளியேறும். எனவே, key-ன் பாதையை முழுமையாகக் குறிப்பிடவும். பாதையைச் சரிசெய்த பிறகும் அந்த authentication பிழை தொடர்ந்தால், publickey தோல்விக்கான காரணங்களைச் சரிபார்க்கவும். புதிய server-ல் உள்ள directory அனுமதிகளும் அடுத்ததாகச் சரிபார்க்கப்பட வேண்டியவை.

உரிமையாளர் (ownership) விஷயத்தில் ஒரு முடிவை எடுக்க வேண்டும். root-ஆக இயக்கும்போது, rsync இயல்பாகவே பெயர் அடிப்படையில் உரிமையாளர் மற்றும் குழுவை மாற்றும். எனவே, பழைய server-ல் www-data-க்குச் சொந்தமான கோப்பு, புதிய server-ல் www-data-க்குச் சொந்தமானதாக மாறும் (numeric UID வேறாக இருந்தாலும்). இதுவே ஒரு rebuild-க்குத் தேவையானது. இலக்கு server-ல் கணக்குகள் (accounts) இல்லாத கோப்பு முறைமையை நகலெடுக்கும்போது மட்டுமே --numeric-ids-ஐச் சேர்க்கவும். அதன் பிறகு ls -ln மூலம் முடிவைச் சரிபார்க்கவும். ஏனெனில், கணக்கு இல்லாத UID-க்குச் சொந்தமான கோப்புகள் வெறும் எண்ணாகவே காட்டும், அதை வாசிக்கும் எந்த service-க்கும் அனுமதி மறுக்கப்படும்.

பழைய server இன்னும் traffic-ஐக் கையாண்டுகொண்டிருக்கும்போதே, சில நாட்களுக்கு முன்பே bulk pass-ஐ இயக்கவும். இதை எத்தனை முறை வேண்டுமானாலும் செய்யலாம்: rsync மாறிய கோப்புகளை மட்டுமே அனுப்பும் என்பதால், இரண்டாவது முறை சில நிமிடங்களில் முடிந்துவிடும். cutover window-க்குள் செய்யப்படும் இறுதி pass-ல் --delete-ஐச் சேர்க்கவும், அப்போதுதான் பழைய server-ல் நீக்கப்பட்ட கோப்புகள் புதிய server-லிருந்தும் நீக்கப்படும்.

# old server: final pass, inside the window, after the app has stopped writing
sudo rsync -aHAX --delete --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

--delete என்பது source-ல் இல்லாத கோப்புகளை destination-லிருந்து நீக்கும். எனவே, தவறான source பாதையுடன் --delete-ஐப் பயன்படுத்தினால் destination directory காலியாகிவிடும். ஒவ்வொரு முறையும் முதலில் --dry-run-ஐப் பயன்படுத்திச் சோதிக்கவும். நீண்ட நேரப் பரிமாற்றங்கள் உங்கள் laptop-ன் SSH session துண்டிக்கப்படும்போது நின்றுவிடலாம், எனவே பழைய server-ல் tmux அல்லது screen-க்குள் இவற்றைத் தொடங்கவும். பழைய server இன்னும் பயனர்களுக்குச் சேவை வழங்கிக்கொண்டிருக்கும்போது, network bandwidth அதிகமாகப் பயன்படுத்தப்பட்டால் --bwlimit=20M-ஐச் சேர்க்கவும்.

தரவுத்தளம் எவ்வாறு நகர்கிறது: ஒரு நேட்டிவ் டம்ப் (native dump)

தரவுத்தளம் என்பது கோப்புகளின் அடைவு (directory) அல்ல, அது அவ்வாறு தோன்றினாலும் கூட. இது கோப்புகளின் தொகுப்பு, நினைவகத்தில் உள்ள நிலை (in-memory state) மற்றும் write-ahead log ஆகியவற்றின் கலவையாகும். தரவுத்தளம் குறிப்பிடும் தருணங்களில் மட்டுமே இது சீரானதாக (consistent) இருக்கும். எனவே, அதன் சொந்தக் கருவியையே பயன்படுத்தவும்.

PostgreSQL-க்கு இரண்டு டம்ப்கள் தேவை, ஏனெனில் roles என்பவை cluster முழுமைக்கும் பொதுவானவை மற்றும் pg_dump அவற்றை உள்ளடக்குவதில்லை:

# old server
sudo -u postgres pg_dumpall --globals-only -f /var/backups/globals.sql
sudo -u postgres pg_dump -Fc -f /var/backups/appdb.dump appdb

# new server: restore in this order
sudo -u postgres psql -f /var/backups/globals.sql
sudo -u postgres createdb -O appuser appdb
sudo -u postgres pg_restore -d appdb --no-owner /var/backups/appdb.dump

globals.sql-ஐத் தவிர்த்தால், அனைத்து அட்டவணைகளும் மீட்டமைக்கப்படும், ஆனால் எந்தவொரு application role-ஆலும் அவற்றை வாசிக்க முடியாது. ஏனெனில் GRANT கூற்றுகள் இல்லாத ஒரு பயனரைக் குறிப்பிடுகின்றன. -Fc custom archive format-ஐ எழுதுகிறது, இதை pg_restore மட்டுமே வாசிக்க முடியும்; இது பிற்காலத்தில் குறிப்பிட்ட அட்டவணைகளை மட்டும் மீட்டெடுக்க உதவுகிறது. அதே major version அல்லது புதிய பதிப்பிற்கு மீட்டெடுக்கவும். உதாரணமாக 17-லிருந்து 16-க்கு பின்னோக்கிச் செல்வது ஆதரிக்கப்படுவதில்லை. pg_restore எதையும் எழுதும் முன்பே, கோப்பு தலைப்பில் (file header) உள்ள unsupported-version பிழையைக் காட்டி archive-ஐ நிராகரித்துவிடும்.

MySQL மற்றும் MariaDB ஒரு கட்டளையைப் பயன்படுத்துகின்றன, அதில் இயல்பாக இல்லாத நான்கு விருப்பங்கள் (options) உள்ளன:

# old server
sudo mysqldump --single-transaction --routines --triggers --events \
  --databases appdb > /var/backups/appdb.sql

# new server
sudo mysql < /var/backups/appdb.sql

--single-transaction, எழுதுபவர்களைத் தடுக்காமல் சீரான snapshot-ஐ எடுக்கிறது, ஆனால் இது InnoDB அட்டவணைகளுக்கு மட்டுமே பொருந்தும். அதே தரவுத்தளத்தில் உள்ள ஒரு MyISAM அட்டவணை இத்தகைய உத்தரவாதம் இன்றி நகலெடுக்கப்படும், எனவே டம்பை நம்புவதற்கு முன் உங்கள் storage engines-ஐச் சரிபார்க்கவும். --routines, --triggers மற்றும் --events ஆகியவை இயல்பாகவே முடக்கப்பட்டிருக்கும். அதாவது, ஒரு சாதாரண டம்ப் உங்கள் தரவை மீட்டெடுக்கும், ஆனால் உங்கள் stored procedures மற்றும் scheduled events-ஐ அமைதியாக விட்டுவிடும். தரவுத்தள பயனர்கள் மற்றும் அவர்களின் உரிமைகள் (grants) mysql system database-ல் உள்ளன. ஒரு --databases appdb டம்ப் அதைத் தொடாது, எனவே புதிய server-ல் CREATE USER மற்றும் GRANT மூலம் அவற்றை மீண்டும் உருவாக்கவும். MariaDB 11, mariadb-dump போன்றே அதே கருவியை வழங்குகிறது மற்றும் mysqldump-ஐ ஒரு symbolic link-ஆக வைத்திருக்கிறது. எனவே, ஆகஸ்ட் 2026 நிலவரப்படி, எந்தப் பெயரைப் பயன்படுத்தினாலும் அது வேலை செய்யும்.

SQLite என்பது ஒரே ஒரு கோப்பு, application எழுதும்போதே அதை நகலெடுத்தால், அது சிதைந்த (torn) கோப்பாக மாறிவிடும். அதற்குப் பாதுகாப்பான வழிமுறை இதோ:

# old server
sqlite3 /var/lib/app/app.db ".backup '/var/backups/app.db'"

எந்த engine-ஆக இருந்தாலும், டம்பை நம்புவதற்கு முன் அதைச் சரிபார்க்கவும். வட்டு (disk) நிறைந்ததால் பாதியிலேயே நின்ற ஒரு டம்பை மீட்டெடுத்தால், அது எந்தப் பிழையும் காட்டாது; ஆனால் டம்ப் எங்கு துண்டிக்கப்பட்டதோ, அதுவரை மட்டுமே தரவு இருக்கும்.

# old server: a complete mysqldump ends with a line reading "-- Dump completed on ..."
tail -n 3 /var/backups/appdb.sql

# new server: after restore, count rows in a table whose size you know
sudo mysql -e 'SELECT COUNT(*) FROM appdb.orders;'

இயங்கும் நிலையில் உள்ள database-ஐ ஏன் rsync செய்யக்கூடாது

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

கோப்புகளை நகர்த்த இரண்டு பாதுகாப்பான வழிகள் உள்ளன. Database-ஐ நிறுத்திவிட்டு, நகலெடுத்து, மீண்டும் தொடங்கலாம்: இது சரியான மற்றும் எளிமையான முறை, ஆனால் நகலெடுக்கும் நேரம் வரை downtime இருக்கும். அல்லது இயங்கும் server-ன் physical copy-க்காக உருவாக்கப்பட்ட கருவியைப் பயன்படுத்தலாம். PostgreSQL-க்கு pg_basebackup உள்ளது; இது server-உடன் ஒருங்கிணைந்து செயல்படுவதால், நகல் சீரானதாக (consistent) இருக்கும்:

# new server: pull a physical copy from the old one
pg_basebackup -h 198.51.100.10 -U replicator -D /var/lib/postgresql/16/main -X stream -P

இதற்கு REPLICATION attribute கொண்ட ஒரு role மற்றும் பழைய server-ல் அதற்கு இணையான pg_hba.conf entry தேவைப்படும். எனவே, இது dump எடுப்பதை விட கூடுதல் அமைப்பு வேலைகளைக் கொண்டது. database மிகப் பெரியதாக இருந்து, dump மற்றும் restore செய்ய போதிய கால அவகாசம் இல்லாதபோது இது பயனுள்ளதாக இருக்கும். சாதாரண single-server migration-க்கு dump முறையே சிறந்தது.

Cutover-க்கு பிறகு அல்ல, அதற்கு முன்பே certificates-ஐ மீண்டும் உருவாக்கவும்

TLS certificate என்பது IP முகவரியுடன் அல்ல, domain பெயருடன் பிணைக்கப்பட்டுள்ளது. எனவே, certificate கோப்புகளை எந்த சிக்கலும் இன்றி நகர்த்த முடியும். ஆனால், renewal செயல்முறை எளிதாக நகராது. Certbot-ன் இயல்பான HTTP-01 challenge, சான்றிதழ் வழங்கும் அமைப்பிடம் (certificate authority) port 80 வழியாக ஒரு கோப்பை எடுக்குமாறு கேட்கும். DNS புதிய server-ஐச் சுட்டிக்காட்டும் வரை, அந்த கோரிக்கை பழைய server-க்கே செல்லும். இதனால் புதிய server-ல் renewal தோல்வியடையும்.

முதல் வழி, ஏற்கனவே உள்ள certificates மற்றும் அவற்றின் renewal நிலையை நகலெடுப்பதாகும். அவை காலாவதியாகும் தேதி வரை எந்த server-ல் இருந்தாலும் செல்லுபடியாகும்.

# old server
sudo rsync -aHAX -e 'ssh -i /root/.ssh/id_ed25519' \
  /etc/letsencrypt/ root@203.0.113.20:/etc/letsencrypt/

/etc/letsencrypt/renewal/-ன் கீழ் உள்ள ஒவ்வொரு கோப்பும் அந்தச் சான்றிதழை வழங்கிய authenticator plugin-ன் பெயரைக் கொண்டிருக்கும். எனவே, புதிய server-லும் அதே plugin-ஐ நிறுவவும் (உதாரணத்திற்கு python3-certbot-nginx). இல்லையெனில், தெரியாத authenticator என்ற பிழையுடன் முதல் renewal தோல்வியடையும். renewal சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்தவும்:

# new server, after DNS has moved
sudo certbot renew --dry-run

இரண்டாவது வழி, DNS-01 challenge-ஐப் பயன்படுத்தி புதிய server-ல் புதிய certificate-ஐ உருவாக்குவதாகும். இது TXT record மூலம் கட்டுப்பாட்டை உறுதிப்படுத்துகிறது மற்றும் port 80-ஐத் தொடுவதில்லை. பெயர் இன்னும் பழைய server-ஐச் சுட்டிக்காட்டிக்கொண்டிருக்கும்போதே, migration-க்கு முன்பே இதைச் செய்ய முடியும். உங்கள் DNS provider-ஐ automate செய்ய முடிந்தால், இதுவே சிறந்த முறையாகும். DNS-01 challenge மூலம் certificates-ஐ உருவாக்குதல் பகுதியில் plugin மற்றும் credential அமைப்பு பற்றி விவரிக்கப்பட்டுள்ளது.

எந்த வழியைத் தேர்ந்தெடுத்தாலும், DNS-ஐ மாற்றாமல் புதிய server எதைக் காட்டுகிறது என்பதைச் சரிபார்க்கவும்:

# your laptop
echo | openssl s_client -connect 203.0.113.20:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

-servername என்பது SNI (server name indication)-ஐ அனுப்புகிறது. இதுதான் web server சரியான virtual host-ஐத் தேர்ந்தெடுக்க உதவுகிறது. இதைத் தவிர்த்தால், அந்த IP-க்கான இயல்பான (default) certificate மட்டுமே கிடைக்கும். இது ஒரு பெரிய சிக்கலாகத் தோன்றலாம், ஆனால் உண்மையில் அது ஒரு mismatch மட்டுமே.

DNS TTL-ஐ மாற்றத்திற்கு சில நாட்களுக்கு முன்பே குறைக்கவும்

DNS மாற்றத்தின் போது கவனமாக இருந்தாலும், சில நேரங்களில் பிழைகள் ஏற்படுவதுண்டு. ஏனெனில், இதில் உள்ள காலதாமதம் (delay) கட்டமைப்பிலேயே உள்ளது; அதை கடைசி நேரத்தில் குறைக்க முடியாது. ஒரு resolver உங்கள் A record-ஐ cache செய்திருந்தால், அதற்கு வழங்கப்பட்ட TTL (time to live) முடியும் வரை அது பழைய தகவலையே வழங்கும். பத்து நிமிடங்களுக்கு முன்பு பழைய TTL மதிப்பில் cache செய்யப்பட்ட record-க்கு, இப்போது TTL-ஐக் குறைப்பது எந்த மாற்றத்தையும் ஏற்படுத்தாது. அந்த resolver பழைய TTL முடியும் வரை பழைய மதிப்பையே வைத்திருக்கும்; அதன் பிறகுதான் புதிய, குறைந்த TTL மதிப்பை அறிந்துகொள்ளும். எனவே, மாற்றத்திற்கு (cutover) குறைந்தது ஒரு முழு பழைய TTL காலத்திற்கு முன்பே TTL-ஐக் குறைத்துவிட வேண்டும். ஒரு நாள் முன்பே செய்வது பாதுகாப்பானது. இதில் உள்ள நுணுக்கங்கள் உங்களுக்குப் புதியவை என்றால், records, resolvers மற்றும் caching பற்றிய விளக்கம் உங்களுக்குப் பயனுள்ளதாக இருக்கும்.

கீழே உள்ள எண்கள் TTL-லிருந்து கணக்கிடப்பட்டவை, இவை அளவீடுகள் அல்ல.

[
  {
    "label": "TTL 3600 s (common default)",
    "ttl_seconds": 3600,
    "worst_case_stale_minutes": 60
  },
  {
    "label": "TTL 900 s",
    "ttl_seconds": 900,
    "worst_case_stale_minutes": 15
  },
  {
    "label": "TTL 300 s (lowered for cutover)",
    "ttl_seconds": 300,
    "worst_case_stale_minutes": 5
  },
  {
    "label": "TTL 60 s (short window)",
    "ttl_seconds": 60,
    "worst_case_stale_minutes": 1
  }
]

3600 வினாடிகள் TTL கொண்ட ஒரு A record, நீங்கள் மாற்றத்தைச் செய்த பிறகும் 60 நிமிடங்கள் வரை பயனர்களை பழைய IP-க்கு அனுப்பக்கூடும். இதை 300 வினாடிகளாகக் குறைத்தால், அந்த அதிகபட்ச காலதாமதம் 5 நிமிடங்களாகக் குறையும். இந்த எண்களை ஒரு உறுதிமொழியாகக் கருதாமல், குறைந்தபட்ச அளவீடாகக் கருதுங்கள். சில resolvers தங்களுக்கென ஒரு குறைந்தபட்ச TTL-ஐக் கொண்டுள்ளன, அவை மிகக் குறைந்த TTL மதிப்புகளைப் புறக்கணிக்கலாம். சில application runtimes, ஒரு process இயங்கும் காலம் முழுவதும் resolved address-ஐ cache-ல் வைத்திருக்கும். எனவே, உங்கள் மாற்றத்திற்கு முன்பே தொடங்கிய ஒரு client, restart செய்யும் வரை மீண்டும் DNS-ஐப் பார்க்காமல் இருக்கலாம்.

குறைக்கப்பட்ட TTL நடைமுறைக்கு வந்துவிட்டதா என்பதைச் சரிபார்க்க, உங்கள் cache-ஐப் பார்க்காமல், authoritative விடையைப் பார்க்கவும்:

# your laptop: ask the zone's own nameserver, so no cache is involved
dig +short NS example.com
dig +noall +answer @$(dig +short NS example.com | head -n1) example.com A

அந்த விடை வரியின் இரண்டாவது புலம் (field) வினாடிகளில் உள்ள TTL ஆகும். அதன் பிறகு, மக்கள் பெரும்பாலும் மறந்துவிடும் records-ஐச் சரிபார்க்கவும்: பழைய server-ல் IPv6 இருந்தால் AAAA record, CNAME-க்கு பதிலாகத் தனி A record-ஆக இருந்தால் www பெயர், server-ஐக் குறிக்கும் ஏதேனும் MX record, பழைய IP-ஐக் கொண்ட SPF record, மற்றும் புதிய முகவரிக்கான reverse DNS (PTR) record. server மின்னஞ்சல் அனுப்பினால், மாற்றத்திற்கு முன்பே உங்கள் provider-ன் control panel மூலம் PTR-ஐ அமைக்கவும். ஏனெனில், மின்னஞ்சலைப் பெறும் server-கள் இதைச் சரிபார்க்கும். PTR விடுபட்டிருந்தால், மற்ற அனைத்தும் சரியாகத் தெரிந்தாலும், சில மணிநேரங்களுக்குப் பிறகு மின்னஞ்சல் நிராகரிக்கப்படும்.

DNS-ஐ மாற்றும் முன் புதிய server-ஐ அதன் IP மூலம் சரிபார்க்கவும்

DNS பழைய server-ஐச் சுட்டிக்காட்டிக்கொண்டிருக்கும்போதே, புதிய server-ல் முழு application-ஐயும் உங்களால் சோதிக்க முடியும். ஒரு கோரிக்கைக்கு மட்டும் name lookup-ஐ பின்வருமாறு மாற்றியமைக்கவும்:

# your laptop: force one name to the new IP, for this request only
curl -sS --resolve example.com:443:203.0.113.20 \
  -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/

--resolve இணைப்பானது எங்கு செல்ல வேண்டும் என்பதை மட்டுமே மாற்றுகிறது. TLS certificate உண்மையான பெயருடனேயே சரிபார்க்கப்படுவதால், இது service-ஐ மட்டுமல்லாமல் certificate-ஐயும் உறுதிப்படுத்துகிறது. %{ssl_verify_result}, chain சரிபார்க்கப்பட்டதும் 0 என்று அச்சிடும்.

Browser-ல் தளத்தை உலாவ, உங்கள் laptop-ல் உள்ள /etc/hosts கோப்பிலோ அல்லது Windows-ல் உள்ள C:\Windows\System32\drivers\etc\hosts கோப்பிலோ ஒரு வரியைச் சேர்ப்பதன் மூலம் உங்கள் கணினி முழுமைக்குமான name lookup-ஐ மாற்றியமைக்கலாம்:

203.0.113.20 example.com www.example.com

பிறகு, ஒரு பயனர் பயன்படுத்துவது போலவே application-ஐச் சோதிக்கவும். உள்நுழையவும் (Log in). Database-லிருந்து தரவைப் படிக்கும் பக்கத்தை ஏற்றவும். தரவை எழுதும் படிவத்தைச் சமர்ப்பிக்கவும். கோப்பு ஒன்றை பதிவேற்றி, அது disk-ல் சேமிக்கப்பட்டுள்ளதா என உறுதிப்படுத்தவும். மின்னஞ்சலை அனுப்பும் செயல்பாட்டைத் தூண்டி, அது வந்து சேருகிறதா என்று பார்க்கவும்; ஏனெனில் புதிய IP-யிலிருந்து அனுப்பப்படும் outbound SMTP பெரும்பாலும் சிக்கல்களை ஏற்படுத்தலாம். சோதனையை முடித்தவுடன் hosts கோப்பில் சேர்த்த வரியை நீக்கிவிடவும். அதை அப்படியே விட்டுவிட்டால், மற்றவர்களுக்குச் சரியாகத் தெரியும் தளம் உங்களுக்கு மட்டும் ஏன் வேலை செய்யவில்லை என்று ஒரு மணிநேரம் தேட வேண்டியிருக்கும்.

Cutover செயல்முறை, படிப்படியாக

1. சில நாட்களுக்கு முன்பே: TTL மதிப்பைக் குறைக்கவும், bulk rsync-ஐ இயக்கவும், புதிய server-ஐ உருவாக்கி hosts override மூலம் சோதிக்கவும்.
2. குறிப்பிட்ட நாளில், பணி தொடங்கும் முன்: புதிய IP-ஐ அனைத்து மூன்றாம் தரப்பு allowlist-களிலும் சேர்க்கவும், புதிய server-ன் backup job சரியாக உள்ளமைக்கப்பட்டு உங்கள் repository-ஐச் சுட்டிக்காட்டுகிறதா என்பதை உறுதிப்படுத்தவும்.
3. பணியைத் தொடங்கவும்: பழைய server-ல் application-ஐ maintenance mode-க்கு மாற்றவும், இதனால் அது புதிய தரவுகளைப் பெறுவதை நிறுத்தும்.
4. இறுதி database dump-ஐ எடுக்கவும், பின் --delete பயன்படுத்தி இறுதி rsync-ஐ இயக்கவும்.
5. புதிய server-ல் dump-ஐ restore செய்து, services-ஐத் தொடங்கவும்.
6. --resolve மற்றும் hosts override மூலம் மீண்டும் சோதிக்கவும், இதில் ஒரு உண்மையான write செயல்பாடும் அடங்கும்.
7. A மற்றும் AAAA records-ஐ புதிய IP-க்கு மாற்றவும்.
8. இரண்டு server-களையும் கவனிக்கவும். பழைய server-ன் access log-ல் இன்னும் யார் வருகிறார்கள் என்பது தெரியும், TTL காலத்திற்குள் இந்த எண்ணிக்கை பூஜ்ஜியத்தை நோக்கி குறைய வேண்டும்.
9. Maintenance பக்கத்தை நீக்கவும்.
10. பழைய server-ஐ குறைந்தது ஒரு வாரத்திற்கு மாற்றங்கள் ஏதுமின்றி அப்படியே இயங்க விடவும்.

Maintenance mode படிநிலையைத்தான் பலரும் தவிர்க்கிறார்கள், ஆனால் இதுவே உங்களைப் பாதுகாக்கும் படிநிலை. புதிய database ஒரு write-ஐ ஏற்றுக்கொண்ட பிறகு, மீண்டும் பழைய நிலைக்குத் திரும்புவது என்பது அந்த write-ஐ இழப்பதாகவோ அல்லது புதிய database-ஐ dump செய்து பழையதில் மீண்டும் ஏற்றுவதாகவோ அமையும். சில நிமிடங்கள் read-only நிலையில் இருப்பது பெரிய பாதிப்பை ஏற்படுத்தாது. இரண்டு database-களிலும் write நடந்தால், அவற்றைச் சரிசெய்ய பல நாட்கள் தேவைப்படும்.

Rollback திட்டம்

Rollback என்பது ஒரு செயல்முறை மட்டுமே: DNS பதிவுகளை மீண்டும் 198.51.100.10-க்கு மாற்ற வேண்டும். நீங்கள் முன்னதாகச் செய்த நான்கு விஷயங்களால் மட்டுமே இது சாத்தியமாகும்.

• பழைய server இன்னும் இயங்கிக்கொண்டிருக்கிறது, அதன் சேவைகளும் தரவுகளும் அப்படியே உள்ளன. நீங்கள் அங்கு தரவு எழுதுவதை (writes) மட்டுமே நிறுத்தினீர்கள், அதை decommission செய்யவில்லை.
• TTL இன்னும் குறைவாகவே உள்ளது, எனவே முன்னோக்கிச் சென்ற அதே வேகத்தில் பின்னோக்கிச் செல்வதும் சாத்தியமாகும்.
• நீங்கள் புதிய IP-ஐ third-party allowlists-ல் பழையதை நீக்கிவிட்டு மாற்றாமல், கூடுதலாகச் சேர்த்துள்ளீர்கள். பழைய முகவரியை நீக்கிவிட்டால், உங்கள் rollback பாதை payment gateway-ல் தோல்வியடையும்.
• புதிய server-ல் நீங்கள் அடையாளம் காண முடியாத எந்த தரவும் எழுதப்படவில்லை, ஏனெனில் இதுவரை நடந்தவை உங்கள் சொந்த சோதனைப் பரிவர்த்தனைகள் மட்டுமே.

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

இடமாற்றம் (migration) வெற்றிகரமாக முடிந்ததை உறுதிப்படுத்துதல்

தளம் இயங்கத் தொடங்கியவுடன் இடமாற்றம் முடிந்துவிடாது. பிற்காலத்தில் மட்டும் ஏற்படக்கூடிய சிக்கல்களைச் சரிபார்க்க வேண்டும்.

# new server
systemctl --failed
journalctl -p err -b --no-pager | tail -n 40
sudo certbot certificates
sudo systemctl list-timers --all --no-pager

systemctl --failed reporting 0 loaded units listed என்பது நீங்கள் எதிர்பார்க்கும் முடிவாகும். certbot certificates-ல் நீங்கள் எதிர்பார்க்கும் காலாவதி தேதிகள் (expiry dates) இருக்க வேண்டும், மேலும் list-timers-ல் உங்கள் பட்டியலில் உள்ள அனைத்து திட்டமிடப்பட்ட பணிகளும் (scheduled jobs) அடுத்த முறை இயங்கும் நேரத்துடன் காட்டப்பட வேண்டும்; காலியாக இருக்கக்கூடாது.

பிறகு, புதிய server-ஐ ஒருமுறை நீங்களாகவே reboot செய்து கவனியுங்கள். யாராவது ஒருவர் கைமுறையாகத் தொடங்கி, enable செய்ய மறந்த ஒரு service, அதிகாலை 3 மணிக்கு எதிர்பாராதவிதமாக reboot ஆகும் வரை சரியாக இயங்கும்.

# new server
sudo reboot

# your laptop, once it comes back
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Application containers-ல் இயங்கினால், இதே சிக்கல் வேறு வடிவில் வரும். ஏனெனில் reboot-க்கு பிறகு ஒரு compose stack மீண்டும் இயங்க, அதற்கு முறையான restart policy தேவை.

கடைசி சரிபார்ப்பு, தள்ளிப்போட எளிதானது ஆனால் மிக முக்கியமானது: backup பணி. backup எடுக்கப்படாத server-உடன் முடிவடையும் ஒரு இடமாற்றம், ஒரு ஆபத்தை நீக்கிவிட்டு மற்றொரு ஆபத்தை உருவாக்குகிறது. புதிய server-ல் backup-ஐ கைமுறையாக இயக்கி, அதிலிருந்து ஒரு கோப்பை மட்டும் தற்காலிக directory-க்கு restore செய்து பாருங்கள். நீங்கள் உண்மையில் சோதித்துப் பார்த்த restore வசதி கொண்ட ஒரு restic repository மட்டுமே, தேவைப்படும்போது உங்களுக்கு உதவும். பழைய மற்றும் புதிய server-களை ஒரு வாரம் ஒரே நேரத்தில் இயக்குகிறீர்கள் என்றால், ஒவ்வொரு host-ஐயும் அணுகவும் கட்டமைக்கவும் ஒரு சீரான வழிமுறை இருந்தால் மட்டுமே, அவை இரண்டும் பயன்பாட்டில் இருக்கும்போது அவற்றுக்கிடையே முரண்பாடுகள் ஏற்படாமல் தடுக்க முடியும்.

Cutover-க்கு பிறகு: பழைய server மற்றும் இறுதி நடவடிக்கைகள்

பழைய server-ஐ ஒன்று முதல் இரண்டு வாரங்களுக்கு அப்படியே வைத்திருக்கவும். நீங்கள் ரத்து செய்யவிருந்த திட்டத்தின் ஒரு மாத கட்டணம் மட்டுமே இதற்கு செலவாகும், ஆனால் இதுவே உங்களிடம் உள்ள ஒரே rollback வாய்ப்பாகும். அதன் பிறகு மீதமுள்ளவற்றை முடித்துவிடலாம்.

• புதிய server-ல் அதே hostname-ஐ உங்கள் ~/.ssh/config-ல் பயன்படுத்தினால், முதல் இணைப்பின் போது WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! பிழை ஏற்படும். ஏனெனில், அந்த பெயர் இப்போது வேறுபட்ட host key-ஐக் கொண்டு பதிலளிக்கிறது. மாற்றம் ஏன் ஏற்பட்டது என்பதை உறுதிப்படுத்திய பிறகு, ssh-keygen -R example.com மூலம் பழைய பதிவை நீக்கவும். இதை அவசரமாகச் செய்ய வேண்டாம், ஏனெனில் இதே எச்சரிக்கைதான் ஒரு interception தாக்குதலின் போதும் தோன்றும். ஒரு migration என்பது எந்தெந்த keys எவற்றை அணுக முடியும் என்பதை ஆய்வு செய்ய சிறந்த தருணமாகும்; இதற்கு சிறிய fleet-ல் SSH key மேலாண்மை உதவும்.
• பழைய server-ன் இறுதி snapshot அல்லது backup ஒன்றை எடுத்து, பழைய service provider-ன் தளத்திற்கு வெளியே பாதுகாப்பாகச் சேமிக்கவும்.
• பழைய IP-ஐ monitoring checks, SPF records மற்றும் மூன்றாம் தரப்பு allowlists ஆகியவற்றிலிருந்து அந்த வரிசையில் கடைசியாக நீக்கவும்.
• அந்த இறுதி நகல் வேறொரு இடத்தில் சரியாக வாசிக்க முடிகிறது என்பதை உறுதிப்படுத்திய பிறகு மட்டுமே பழைய திட்டத்தை ரத்து செய்யவும்.

FAQ

ஒரு server-ஐ புதிய VPS-க்கு மாற்ற எவ்வளவு காலம் ஆகும்?

பயனர்களுக்குத் தெரியும் வகையிலான சேவை முடக்கம் என்பது பொதுவாக இறுதி database dump, இறுதி rsync செயல்முறை மற்றும் service தொடக்கம் ஆகியவற்றுக்கு மட்டுமே தேவைப்படும்; எனவே சிறிய application-களுக்கு 10 முதல் 30 நிமிடங்கள் வரை ஆகும். காலண்டர் அடிப்படையில் பார்த்தால், DNS TTL-ஐ மாற்றத்திற்கு முன்பே குறைத்து வைக்க வேண்டும் என்பதால் இதற்கு அதிக காலம் தேவைப்படும். பழைய TTL காலத்திற்கு முன்பே இதைச் செய்வது அவசியம், ஒரு நாள் முன்னதாகவே செய்வது பாதுகாப்பானது. தரவுகளை நகலெடுக்கும் பணியை சில நாட்களுக்கு முன்பே திட்டமிடுங்கள். இது இயங்கிக்கொண்டிருக்கும் server-ல் நடக்கும், மீண்டும் மீண்டும் செய்யும்போது கடைசியாக நகலெடுத்த பிறகு மாறிய தரவுகள் மட்டுமே மாற்றப்படும்.

இயங்கிக்கொண்டிருக்கும் MySQL அல்லது PostgreSQL database-ஐ dump செய்வதற்குப் பதிலாக rsync மூலம் நகலெடுக்கலாமா?

கூடாது. database ஒரே நேரத்தில் பல கோப்புகளில் எழுதும் நிலையில், rsync கோப்பு வாரியாக நகலெடுக்கும். இதனால் நகலெடுக்கப்பட்ட தரவு வெவ்வேறு நேரங்களில் உள்ள நிலைகளைக் கொண்டிருக்கும், இது database-ன் சரியான நிலையாக இருக்காது. இதனால் database தொடங்க மறுக்கலாம் அல்லது பிற்காலத்தில் query செய்யும்போது பிழைகள் ஏற்படலாம். pg_dump உடன் pg_dumpall --globals-only-ஐப் பயன்படுத்தவும், அல்லது mysqldump --single-transaction-ஐப் பயன்படுத்தவும், அல்லது database-ஐ நிறுத்திவிட்டு கோப்புகளை நகலெடுக்கவும். பெரிய PostgreSQL cluster-களுக்கு, pg_basebackup இயங்கிக்கொண்டிருக்கும் server-ன் சீரான physical நகலை எடுக்க உதவும்.

DNS-ஐ மாற்றுவதற்கு முன் புதிய VPS-ஐ எவ்வாறு சோதிப்பது?

உங்கள் கணினியில் name lookup-ஐ மாற்றியமைக்கவும். ஒருமுறை மட்டும் சோதிக்க, curl --resolve example.com:443:203.0.113.20 https://example.com/ புதிய IP-க்கு இணைப்பை அனுப்பும், அதே சமயம் உண்மையான பெயருக்கான certificate-ஐயும் சரிபார்க்கும். browser மூலம் சோதிக்க, உங்கள் laptop-ல் உள்ள /etc/hosts கோப்பில் 203.0.113.20 example.com-ஐச் சேர்க்கவும். பின் login, database read, form write மற்றும் file upload ஆகியவற்றைச் சோதித்துவிட்டு, அந்த வரியை நீக்கிவிடவும். certificate-ஐ மட்டும் ஆய்வு செய்ய, openssl s_client -connect 203.0.113.20:443 -servername example.com-ஐ இயக்கவும்.

நான் என்ன TTL-ஐ அமைக்க வேண்டும், எப்போது அதைக் குறைக்க வேண்டும்?

A மற்றும் AAAA records-ஐ 300 வினாடிகளாகக் குறைக்கவும். இதை மாற்றத்திற்கு (cutover) ஒரு முழு பழைய TTL காலத்திற்கு முன்பே செய்ய வேண்டும். உங்கள் மாற்றத்திற்கு முன்பே record-ஐ cache செய்த resolver, பழைய TTL முடியும் வரை பழைய மதிப்பையே வைத்திருக்கும். எனவே பழைய TTL 86400 ஆக இருந்தால், ஒரு மணி நேரத்திற்கு முன் குறைப்பதால் எந்தப் பயனும் இல்லை. migration முடிந்த சில நாட்களுக்குப் பிறகு, பழைய server-ன் access log அமைதியான பிறகு, TTL-ஐ மீண்டும் பழைய நிலைக்கு மாற்றவும்.

TLS certificate-ஐ நகலெடுக்க வேண்டுமா அல்லது புதிய server-ல் புதிதாக உருவாக்க வேண்டுமா?

இரண்டுமே சாத்தியம். /etc/letsencrypt/-ஐ நகலெடுப்பது ஏற்கனவே உள்ள காலாவதி தேதி வரை certificate-ஐச் செல்லுபடியாகும். ஆனால், புதிய server-லும் அதே certbot authenticator plugin-ஐ நிறுவ வேண்டும், இல்லையெனில் முதல் புதுப்பித்தல் (renewal) தோல்வியடையும். எனவே DNS மாற்றத்திற்குப் பிறகு certbot renew --dry-run-ஐ இயக்கி உறுதிப்படுத்தவும். DNS-01 challenge-ஐப் பயன்படுத்த முடிந்தால், புதிதாக உருவாக்குவதே சிறந்தது. இது TXT record மூலம் கட்டுப்பாட்டை உறுதிப்படுத்துகிறது மற்றும் DNS புதிய server-க்கு மாறுவதற்கு முன்பே செயல்படும். DNS மாறுவதற்கு முன் HTTP-01 challenge-ஐப் புதிய server-ல் பயன்படுத்த முடியாது, ஏனெனில் validation கோரிக்கை பழைய server-க்கே செல்லும்.