วิธีอัปเกรด Ubuntu 24.04 เป็น 26.04 บน VPS อย่างปลอดภัย

คุณจะอัปเกรด Ubuntu 24.04 เป็น 26.04 ได้เมื่อใด

คุณสามารถอัปเกรด Ubuntu 24.04 เป็น 26.04 บน VPS ได้เมื่อมีการปล่อย point release รุ่น 26.04.1 ซึ่งมีกำหนดการในวันที่ 27 สิงหาคม 2026 จนกว่าจะถึงเวลานั้น เซิร์ฟเวอร์ 24.04 จะไม่พบรุ่นใหม่ดังกล่าวโดยเจตนา Ubuntu 26.04 LTS (Resolute Raccoon) ได้รับการปล่อยออกมาเมื่อวันที่ 23 เมษายน 2026 แต่ Canonical จะเปิดเส้นทางการอัปเกรดจาก LTS ไปยัง LTS ก็ต่อเมื่อถึง point release แรกเท่านั้น เนื่องจากรุ่นดังกล่าวได้รวบรวมการแก้ไขบั๊กในการติดตั้งและการอัปเกรดที่พบในช่วงเดือนแรกๆ ไว้แล้ว

หากคุณรันคำสั่งตรวจสอบบนเครื่อง 24.04 ในช่วงต้นเดือนสิงหาคม 2026 คุณจะพบผลลัพธ์ดังนี้:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

นั่นไม่ใช่ความผิดปกติบนเซิร์ฟเวอร์ของคุณ ไฟล์ /etc/update-manager/release-upgrades มีค่า Prompt=lts บน Ubuntu Server ซึ่งหมายความว่าเครื่องมือจะเสนอเฉพาะรุ่น long term support ถัดไปเท่านั้น และจะเสนอต่อเมื่อมี .1 point release ออกมาแล้วเท่านั้น การตั้งค่า Prompt=normal จะทำให้คุณต้องไล่อัปเกรดผ่าน 24.10, 25.04 และ 25.10 ตามลำดับ ซึ่งเป็นรุ่น interim ที่หมดอายุการใช้งานไปแล้วทั้งหมด ให้คงค่าไว้ที่ lts แล้วรอต่อไป กำหนดการของ Canonical อาจมีการเปลี่ยนแปลงได้ ดังนั้นให้ตรวจสอบอีกครั้งหากผ่านวันดังกล่าวไปแล้วโดยไม่มีการอัปเดต

คำสั่งทุกคำสั่งด้านล่างนี้เป็นคำสั่งที่คุณต้องรันด้วยตนเองบนเซิร์ฟเวอร์ของคุณตามลำดับที่กำหนด การอัปเกรดรุ่นไม่สามารถทำซ้ำหรือทดลองบนเครื่องที่คุณกำลังอัปเกรดได้ เนื่องจากกระบวนการนี้จะแทนที่ kernel และ C library และจำเป็นต้องรีบูตเครื่องเพื่อให้การทำงานเสร็จสมบูรณ์

คุณควรทำการอัปเกรดหรือไม่?

Ubuntu 24.04 ได้รับการอัปเดตความปลอดภัยมาตรฐานจนถึงปี 2029 ดังนั้นเซิร์ฟเวอร์ที่ใช้งานจริงและทำงานได้ตามปกติจึงไม่มีกำหนดเวลาที่ต้องรีบเร่ง การอัปเกรดควรทำก็ต่อเมื่อคุณต้องการสิ่งที่มาพร้อมกับเวอร์ชัน 26.04 เช่น PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 หรือ kernel 7.0 การที่ "เลขเวอร์ชันเพิ่มขึ้น" ไม่ใช่เหตุผลที่ควรไปยุ่งกับเครื่องที่ให้บริการลูกค้าอยู่

ห้ามทำการอัปเกรดแบบ in-place หากเข้าข่ายกรณีใดกรณีหนึ่งต่อไปนี้:

• คุณไม่เคยเปิดคอนโซลของผู้ให้บริการ (VNC หรือ serial) และล็อกอินผ่านช่องทางนั้นมาก่อน คอนโซลดังกล่าวเป็นวิธีเดียวที่จะเข้าถึงเครื่องได้หาก SSH มีปัญหา และการพบว่ามันใช้งานไม่ได้ในขณะที่คุณถูกล็อกเอาต์นั้นถือว่าสายเกินไป
• คุณไม่สามารถยอมรับช่วงเวลาที่ระบบหยุดทำงาน (downtime) เป็นเวลาหนึ่งชั่วโมงได้ และไม่มีแผนการย้อนกลับ (rollback)
• stack ของคุณขึ้นอยู่กับ repository ของบุคคลที่สามที่ยังไม่ได้เผยแพร่สำหรับ resolute
• เซิร์ฟเวอร์ถูกสร้างขึ้นด้วยมือมานานกว่าสองปีและไม่มีใครทราบว่ามีอะไรอยู่บนนั้นบ้าง

ทางเลือกอื่นมักจะดีกว่า: ให้สร้าง VPS เวอร์ชัน 26.04 ขึ้นมาใหม่ ติดตั้ง stack ของคุณและกู้คืนข้อมูล จากนั้นจึงสลับ DNS เมื่อตรวจสอบแล้วว่าระบบตอบสนองอย่างถูกต้อง คุณสามารถเปิดเซิร์ฟเวอร์เครื่องเก่าทิ้งไว้จนกว่าเครื่องใหม่จะพิสูจน์ได้ว่าทำงานได้สมบูรณ์ และการย้อนกลับจะเป็นเพียงการเปลี่ยนค่า DNS แทนที่จะต้องกู้คืนระบบ หากคุณเลือกวิธีนี้ ให้เริ่มต้นด้วย สิบนาทีแรกบน VPS ใหม่ และสร้างเครื่องใหม่ให้ถูกต้องตามขั้นตอน

ขั้นตอนที่ 1: สำรองข้อมูลที่คุณสามารถกู้คืนได้จริง

ให้สำรองข้อมูลสองชั้นเนื่องจากแต่ละวิธีมีจุดอ่อนต่างกัน การทำ snapshot จากผู้ให้บริการจะครอบคลุมทั้งดิสก์และกู้คืนได้ภายในไม่กี่นาที แต่เนื่องจากเป็นการทำในขณะที่ฐานข้อมูลกำลังเขียนข้อมูล จึงเป็นเพียงการสำรองข้อมูลแบบ crash consistent ไม่ใช่ application consistent ส่วนการสำรองข้อมูลระดับไฟล์ด้วย restic ซึ่งเก็บไว้นอกเซิร์ฟเวอร์ จะช่วยให้คุณกู้คืนไฟล์รายไฟล์ได้ และมีสำเนาที่ปลอดภัยแม้บัญชีผู้ใช้ของคุณจะถูกล็อกก็ตาม

ให้ทำการ dump ฐานข้อมูลด้วยตนเองก่อนเสมอ การ dump เป็นวิธีเดียวที่จะเชื่อถือได้ในการสำรองฐานข้อมูลโดยไม่ต้องหยุดการทำงานของระบบ

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction จะให้ผลลัพธ์การ dump ที่สอดคล้องสำหรับตารางแบบ InnoDB เท่านั้น ส่วนตารางแบบ MyISAM จำเป็นต้องหยุดการทำงานของฐานข้อมูลก่อน ไฟล์ tarball /etc คือสิ่งที่คุณจะได้ใช้งานจริงเมื่อเกิดปัญหา เพราะมันเก็บไฟล์ config ทุกไฟล์ที่กระบวนการอัปเกรดอาจสอบถามคุณ

การสำรองข้อมูลที่คุณไม่เคยทดสอบกู้คืนถือเป็นเพียงการคาดเดาเท่านั้น ให้ลองดึงไฟล์ออกมาหนึ่งไฟล์เดี๋ยวนี้ ก่อนที่คุณจะมีความจำเป็นต้องใช้งานจริงภายใต้สถานการณ์กดดัน

ขั้นตอนที่ 2: แพตช์ 24.04 ให้สมบูรณ์ก่อน

do-release-upgrade จะปฏิเสธการทำงานบนระบบที่มีสถานะแพ็กเกจเสียหาย และการแพตช์ 24.04 เพียงครึ่งๆ กลางๆ จะทำให้การวิเคราะห์ความผิดพลาดในภายหลังทำได้ยากขึ้น

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

หาก dpkg --audit ไม่แสดงผลลัพธ์ใดๆ หมายความว่าไม่มีแพ็กเกจใดที่ถูกกำหนดค่าไว้ไม่สมบูรณ์ หาก apt-mark showhold ไม่แสดงผลลัพธ์ใดๆ หมายความว่าไม่มีแพ็กเกจใดที่ถูกล็อกเวอร์ชัน (pinned) ไว้จนขัดขวางการอัปเกรด ให้ปลดล็อกแพ็กเกจที่แสดงรายการด้วย sudo apt-mark unhold ตามด้วยชื่อแพ็กเกจ หรือยอมรับว่าการล็อกนั้นมีเหตุผลและหยุดดำเนินการที่ขั้นตอนนี้

ให้รีบูตเครื่องหากมีการเปลี่ยนแปลงเคอร์เนล เพื่อให้มั่นใจว่าคุณกำลังอัปเกรดจากเครื่องที่รันโค้ดเวอร์ชันเดียวกับที่ระบบรับรู้

[ -f /var/run/reboot-required ] && sudo reboot

จากนั้นตรวจสอบพื้นที่ดิสก์ ตัวอัปเกรดจะดาวน์โหลดชุดแพ็กเกจใหม่ทั้งหมดก่อนเริ่มการติดตั้ง และจะยกเลิกการทำงานพร้อมข้อความระบุชื่อไฟล์ระบบหากมีพื้นที่ไม่เพียงพอ

df -h / /boot

หากพื้นที่ว่างบน / ต่ำกว่าประมาณ 5 GB มักจะเกิดปัญหาขึ้น และหาก /boot มีพื้นที่ว่างต่ำกว่า 300 MB จะเกิดความล้มเหลวในภายหลังระหว่างการติดตั้งเคอร์เนลด้วยข้อความ No space left on device สาเหตุส่วนใหญ่มักเกิดจากเคอร์เนลเก่า ซึ่งสามารถล้างออกได้ด้วย sudo apt --purge autoremove

อีกหนึ่งสิ่งที่ควรหยุดก่อนเริ่มดำเนินการ: หาก การอัปเดตความปลอดภัยอัตโนมัติ ทำงานระหว่างการอัปเกรด ระบบจะถือครอง dpkg lock ไว้ และตัวอัปเกรดเวอร์ชันจะหยุดทำงานพร้อมข้อความ Could not get lock /var/lib/dpkg/lock-frontend ให้รัน sudo systemctl stop unattended-upgrades ก่อน แล้วจึงเริ่มกระบวนการอีกครั้งเมื่อเสร็จสิ้น

ขั้นตอนที่ 3: ตรวจสอบที่เก็บซอฟต์แวร์จากภายนอกและแพ็กเกจที่ถูกตรึงเวอร์ชัน (pinned packages)

do-release-upgrade จะปิดการใช้งานแหล่งที่มาของ apt ทั้งหมดที่ไม่ใช่ของ Ubuntu เนื่องจากแพ็กเกจที่สร้างมาเพื่อ noble อาจทำให้ระบบ resolute เสียหายได้ เครื่องมือนี้จะเปิดใช้งานแหล่งที่มาที่รู้จักอีกครั้งหลังจากนั้น และปล่อยให้แหล่งที่มาที่เหลือถูกคอมเมนต์ไว้ คุณควรทราบว่าคุณกำลังใช้งานอะไรอยู่ก่อนที่เครื่องมือจะตัดสินใจแทนคุณ

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 ใช้รูปแบบไฟล์สองแบบในไดเรกทอรีดังกล่าว ได้แก่ ไฟล์ .list แบบบรรทัดเดียวแบบเดิม และไฟล์ .sources รูปแบบ deb822 ที่มีฟิลด์ Types: และ Suites: การอัปเกรดจะปิดการใช้งานทั้งสองรูปแบบ ubuntu-security-status --thirdparty จะแสดงรายการแพ็กเกจที่ติดตั้งไว้ซึ่งไม่มีในคลังซอฟต์แวร์ของ Ubuntu ซึ่งเป็นจำนวนที่แท้จริงของซอฟต์แวร์ที่คุณติดตั้งเพิ่มเข้าไป สิ่งใดก็ตามที่อยู่ใน /etc/apt/preferences.d/ คือการตรึงเวอร์ชัน (pin) และการตรึงเวอร์ชันที่เขียนขึ้นสำหรับ noble จะยังคงเลือกแพ็กเกจเวอร์ชันเก่าบนระบบรุ่นใหม่ต่อไป

สำหรับที่เก็บซอฟต์แวร์จากภายนอกแต่ละแห่ง ให้ยืนยันว่าผู้ให้บริการได้เผยแพร่ซอฟต์แวร์สำหรับ codename ใหม่แล้วก่อนที่คุณจะเริ่มดำเนินการ ชุดซอฟต์แวร์ของ Docker จะแสดงอยู่ที่ https://download.docker.com/linux/ubuntu/dists/ และผู้ให้บริการรายอื่นก็เปิดเผยไดเรกทอรีในลักษณะเดียวกัน แหล่งที่มาที่ชี้ไปยังชุดซอฟต์แวร์ที่ไม่มีอยู่จริงจะแสดงข้อความนี้ในการเรียกใช้ apt update ครั้งแรกหลังจากการอัปเกรด:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

ให้คงสถานะปิดใช้งานแหล่งที่มานั้นไว้จนกว่าผู้ให้บริการจะเผยแพร่ซอฟต์แวร์ การแก้ไข codename ให้เป็นเวอร์ชันที่ผู้ให้บริการได้สร้างไว้จริง คือวิธีการที่คุณจะติดตั้งแพ็กเกจที่เชื่อมโยงกับไลบรารีของระบบที่ไม่ถูกต้อง

ขั้นตอนที่ 4: รันการอัปเกรดใน tmux แทนการใช้ SSH shell ปกติ

หากการเชื่อมต่อของคุณหลุดระหว่างที่ do-release-upgrade ทำงานใน login shell ปกติ กระบวนการจะได้รับสัญญาณ SIGHUP และหยุดทำงานระหว่างการแตกไฟล์ ส่งผลให้ dpkg อยู่ในสถานะกำหนดค่าไม่สมบูรณ์ และเซิร์ฟเวอร์อาจสูญเสีย network stack จนไม่สามารถเชื่อมต่อกลับได้ ให้รันกระบวนการภายใน terminal multiplexer แทน เพื่อให้กระบวนการยังคงทำงานอยู่บนเซิร์ฟเวอร์แม้ไคลเอนต์ของคุณจะตัดการเชื่อมต่อ

sudo apt install -y tmux
tmux new -s upgrade

ภายในเซสชันนั้น:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

ตัวอัปเกรดจะเริ่ม SSH daemon ตัวที่สองบนพอร์ต 1022 ก่อนที่จะทำการเปลี่ยนแปลงใดๆ และจะแจ้งให้คุณทราบ:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

มันจะไม่เปิด firewall ให้คุณสำหรับพอร์ตดังกล่าว เนื่องจากการเจาะช่องโหว่ใน firewall โดยไม่ได้รับอนุญาตอาจทำให้เกิดปัญหาที่ไม่คาดคิด ให้คุณเปิดพอร์ต 1022 ด้วยตนเองก่อนเริ่มดำเนินการ และปิดพอร์ตดังกล่าวเมื่อคุณใช้งาน sudo ufw delete allow 1022/tcp เสร็จสิ้น โปรดจำไว้ว่าผู้ให้บริการของคุณอาจมี firewall อีกชั้นในแผงควบคุม ซึ่งอยู่นอกเหนือการควบคุมของเซิร์ฟเวอร์

หากการเชื่อมต่อหลุดไม่ว่าด้วยเหตุผลใด ให้ล็อกอินกลับเข้ามาแล้วรัน tmux attach -t upgrade การอัปเกรดจะยังคงทำงานต่อไปในขณะที่คุณไม่อยู่

ขั้นตอนที่ 5: ตอบคำถามเกี่ยวกับไฟล์กำหนดค่าอย่างรอบคอบ

dpkg จะถามเฉพาะไฟล์ที่คุณหรือสคริปต์ได้ทำการแก้ไขเท่านั้น ดังนั้นทุกคำถามจึงหมายถึงไฟล์ที่คุณตั้งใจปรับแต่ง การกด Enter เพื่อข้ามไปเฉยๆ จะทำให้เซิร์ฟเวอร์ที่ปรับแต่งมาอย่างปลอดภัยกลายเป็นค่าเริ่มต้นโดยไม่รู้ตัว

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

ให้กด D ก่อนเสมอในทุกครั้ง อ่านสิ่งที่เปลี่ยนแปลง แล้วจึงเลือกเก็บเวอร์ชันของคุณไว้ด้วย N ค่าเริ่มต้นที่ระบบเลือกไว้คือ N ซึ่งเป็นคำตอบที่ปลอดภัยที่สุด เนื่องจากไฟล์ของคุณใช้งานได้จริงในปัจจุบัน ในขณะที่ไฟล์จากแพ็กเกจยังไม่เคยถูกรันบนเครื่องนี้มาก่อน

การเก็บไฟล์ของคุณไว้มีข้อแลกเปลี่ยนคือ คุณจะไม่ได้รับค่าเริ่มต้นใหม่ๆ ให้ทำการปรับจูนให้ตรงกันในภายหลัง เมื่อระบบกลับมาทำงานปกติและคุณไม่ได้อยู่ภายใต้ความกดดันด้านเวลา

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

ไฟล์แต่ละรายการที่แสดงคือเวอร์ชันของผู้ดูแลแพ็กเกจ ซึ่งจะถูกบันทึกไว้ข้างๆ ไฟล์ของคุณ ให้ตรวจสอบความแตกต่าง (diff) ทีละไฟล์และคัดลอกการตั้งค่าที่จำเป็นมาใช้ มีสองส่วนที่ต้องระมัดระวังเป็นพิเศษคือ /etc/ssh/sshd_config เพราะหากตอบผิดจะทำให้เซสชันของคุณหลุด และไฟล์กำหนดค่าของเว็บเซิร์ฟเวอร์ เพราะหากตอบผิดจะทำให้เว็บไซต์หยุดทำงาน

ในระหว่างการอัปเกรด ระบบจะถามว่าจะให้รีสตาร์ทบริการใดบ้างผ่าน needrestart ให้ยอมรับรายการทั้งหมด บริการที่ยังคงทำงานโดยอ้างอิงไฟล์ไลบรารีที่ถูกลบออกจากดิสก์ไปแล้ว อาจเกิดข้อผิดพลาด (crash) เมื่อมีการเรียกใช้งานในภายหลัง ในช่วงเวลาที่คุณไม่ได้เฝ้าดูระบบอยู่

ขั้นตอนที่ 6: รีบูตเครื่องแล้วตรวจสอบสถานะ

sudo reboot

เมื่อระบบกลับมาทำงาน:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a ควรรายงานผลเป็น Release: 26.04 และ Codename: resolute ส่วน uname -r ควรแสดงผลเป็น kernel เวอร์ชัน 7.0 สำหรับ systemctl --failed ควรแสดงรายการ unit เป็นศูนย์ หากมีรายการใดปรากฏขึ้น นั่นคือภารกิจถัดไปที่คุณต้องจัดการ และคำสั่ง apt update สุดท้ายจะทำการดึงข้อมูลอัปเดตที่ถูกเผยแพร่ออกมาหลังจากที่อิมเมจรุ่นดังกล่าวถูกสร้างขึ้น

การอัปเกรดจาก PostgreSQL 16 ไปยัง 18: คลัสเตอร์ที่ยังคงค้างอยู่โดยไม่รู้ตัว

Ubuntu 24.04 มาพร้อมกับ PostgreSQL 16 และ 26.04 มาพร้อมกับ PostgreSQL 18 การอัปเกรดจะติดตั้งเวอร์ชัน 18 ควบคู่ไปกับ 16 โดยไม่มีการย้ายข้อมูลของคุณ ชั้นการทำงาน postgresql-common ของ Debian จะสร้างคลัสเตอร์เปล่าใหม่สำหรับเวอร์ชันหลักเวอร์ชันถัดไปบนพอร์ตว่างถัดไป ดังนั้นเวอร์ชัน 16 จะยังคงใช้พอร์ต 5432 พร้อมข้อมูลทั้งหมดของคุณ ส่วนเวอร์ชัน 18 จะว่างเปล่าและทำงานอยู่บนพอร์ต 5433 แอปพลิเคชันของคุณจะยังคงติดต่อกับพอร์ต 5432 ต่อไปและดูเหมือนไม่มีอะไรผิดปกติ ซึ่งเป็นสาเหตุที่ทำให้ผู้ใช้หลายคนพบปัญหานี้หลังจากผ่านไปหลายเดือน

pg_lsclusters

หากมีคลัสเตอร์แสดงรายการอยู่สองรายการ หมายความว่าคุณยังไม่ได้ย้ายข้อมูล ให้ดำเนินการเมื่อคุณสามารถหยุดการทำงานของแอปพลิเคชันได้:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

ให้ลบคลัสเตอร์เวอร์ชัน 18 ที่ว่างเปล่าออกก่อน เนื่องจาก pg_upgradecluster จะไม่เขียนข้อมูลลงในคลัสเตอร์ปลายทางที่มีอยู่แล้ว วิธีการเริ่มต้นคือการ dump ข้อมูลจากเวอร์ชัน 16 แล้ว reload เข้าสู่เวอร์ชัน 18 ดังนั้นคุณต้องมีพื้นที่ว่างบนดิสก์ประมาณขนาดของฐานข้อมูล -m upgrade จะใช้ pg_upgrade แทน ซึ่งเร็วกว่ามากสำหรับฐานข้อมูลขนาดใหญ่ เมื่อเสร็จสิ้น ให้ตรวจสอบคอลัมน์ Port: คลัสเตอร์ใหม่จะเข้าควบคุมพอร์ต 5432 และคลัสเตอร์เก่าจะถูกหยุดการทำงานไว้ ให้คุณรันขั้นตอน analyze ด้วยตนเอง เนื่องจากคลัสเตอร์ที่เพิ่งโหลดข้อมูลใหม่จะยังไม่มีสถิติ และการคิวรีครั้งแรกจะทำงานช้า

ทดสอบแอปพลิเคชันกับคลัสเตอร์ใหม่เป็นเวลาสองสามวัน หลังจากนั้นจึงค่อยลบคลัสเตอร์เก่าออก:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

ไดเรกทอรีข้อมูลของคลัสเตอร์เก่าคือวิธี rollback ที่เร็วที่สุดที่คุณมี อย่าลบข้อมูลดังกล่าวในวันที่ทำการอัปเกรด

การย้ายจาก MySQL 8.0 ไป 8.4: ตัวเลือกที่ถูกถอดออกซึ่งทำให้เซิร์ฟเวอร์หยุดทำงาน

รุ่น 26.04 มีการเปลี่ยน MySQL จาก 8.0 เป็น 8.4 LTS ซึ่งมีการเปลี่ยนแปลงสองประการที่ส่งผลกระทบต่อเซิร์ฟเวอร์

ประการแรก mysqld จะปฏิเสธการเริ่มทำงานหากไฟล์คอนฟิกูเรชันมีตัวเลือกที่เวอร์ชันใหม่ถอดออกไปแล้ว default_authentication_plugin เป็นตัวเลือกที่พบบ่อย เนื่องจากคู่มือเก่าจำนวนมากแนะนำให้ตั้งค่านี้ บริการจะล้มเหลวและ journalctl -u mysql -n 50 จะระบุชื่อตัวแปรที่ไม่รู้จักนั้นโดยตรง ให้ลบบรรทัดดังกล่าวออกจากไฟล์ภายใต้ /etc/mysql/mysql.conf.d/ จากนั้นจึง sudo systemctl start mysql

ประการที่สอง ปลั๊กอิน mysql_native_password ไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้นใน 8.4 อีกต่อไป ส่งผลให้บัญชีที่ยังคงใช้งานปลั๊กอินนี้ไม่สามารถเข้าสู่ระบบได้เลย ให้ตรวจสอบในขณะที่คุณยังคงใช้งาน 8.0 อยู่:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

ให้ย้ายทุกบัญชีที่แสดง mysql_native_password ก่อนทำการอัปเกรด จากนั้นจึงอัปเดตรหัสผ่านในคอนฟิกูเรชันของแอปพลิเคชันของคุณ:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

หากไลบรารีของไคลเอนต์เก่าเกินกว่าจะรองรับ caching_sha2_password คุณสามารถเปิดใช้งานปลั๊กอินเก่ากลับมาใน 8.4 ได้โดยการเพิ่ม mysql_native_password=ON ไว้ภายใต้ [mysqld] ให้ถือว่าวิธีนี้เป็นเพียงสะพานเชื่อมชั่วคราวที่มีกำหนดเวลาสิ้นสุด เนื่องจากปลั๊กอินดังกล่าวจะถูกถอดออกอย่างถาวรในอนาคต

PHP 8.3 ถึง 8.5: vhost ของคุณชี้ไปยัง socket ที่ไม่มีอยู่จริง

Ubuntu 24.04 มาพร้อมกับ PHP 8.3 และ 26.04 มาพร้อมกับ PHP 8.5 แพ็กเกจเหล่านี้จะติดตั้งลงใน path ที่ระบุเวอร์ชันไว้ และไม่มีกระบวนการใดแก้ไขไฟล์ตั้งค่า web server ของคุณโดยอัตโนมัติ vhost ของ nginx ที่ระบุ fastcgi_pass unix:/run/php/php8.3-fpm.sock; จึงชี้ไปยัง socket ที่ไม่มี process ใดสร้างขึ้น ส่งผลให้ทุกคำขอ PHP ตอบกลับเป็น 502 และ log ความผิดพลาดของ nginx จะแสดงดังนี้:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

ให้แก้ไข path ไปยัง socket ใหม่ ทดสอบไฟล์ตั้งค่า และ reload บริการ:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

สำหรับ Apache ที่ใช้ mod_php อาการจะต่างออกไป คือ Apache จะไม่สามารถเริ่มทำงานได้เลย และ sudo apache2ctl -t จะรายงานว่าไม่สามารถโหลด libphp8.3.so ได้เนื่องจากไม่มีไฟล์ดังกล่าวอยู่ โมดูลที่เปิดใช้งานอยู่เป็นเพียง symlink ไปยังแพ็กเกจที่ถูกลบไปแล้ว

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

หากคุณสร้างเซิร์ฟเวอร์จาก a LAMP stack on Ubuntu 24.04 ควรตรวจสอบทั้งสอง path นี้ เนื่องจากคู่มือดังกล่าวใช้ชื่อโมดูลและ socket ที่ระบุเวอร์ชันไว้

การปรับแต่ง php.ini ของคุณจะไม่ถูกย้ายตามไปด้วย ค่า memory_limit, upload_max_filesize และค่าอื่นๆ ที่คุณเคยตั้งไว้จะอยู่ใน /etc/php/8.3/ ซึ่งโครงสร้างไฟล์ใหม่จะเริ่มต้นด้วยค่าเริ่มต้นทั้งหมด ให้ใช้คำสั่ง diff เปรียบเทียบไฟล์ทั้งสองและคัดลอกค่าที่ต้องการด้วยตนเอง การคัดลอกไฟล์เก่าทับไฟล์ใหม่ทั้งหมดจะทำให้ค่าเริ่มต้นของ 8.3 ติดมาในเวอร์ชัน 8.5 จากนั้นให้รัน php -m เพื่อเปรียบเทียบ: หาก extension ที่ติดตั้งไว้ในชื่อ php8.3-redis ต้องการแพ็กเกจ php8.5- และหาก extension นั้นมาจาก PPA ตัวอัปเกรดจะปิดการใช้งาน source นั้นไปแล้ว ทำให้ extension ดังกล่าวหายไป

ใบรับรอง SSL ควรได้รับการตรวจสอบเป็นพิเศษ ให้รัน sudo certbot renew --dry-run หลังการอัปเกรด คำสั่งนี้จะจำลองกระบวนการต่ออายุทั้งหมด รวมถึงการสั่ง reload web server โดยไม่กระทบต่อใบรับรองที่ใช้งานจริง หากมี hook ที่เรียกใช้ชื่อบริการหรือ binary ที่เปลี่ยนไป คำสั่งนี้จะแสดงข้อผิดพลาดให้คุณเห็นทันที แทนที่จะล้มเหลวเงียบๆ ในอีก 60 วันข้างหน้า Certbot with Let's Encrypt on nginx อธิบายรายละเอียดว่า hook เหล่านี้ควรมีลักษณะอย่างไร

SSH: ความล้มเหลวที่ทำให้เซสชันที่คุณใช้งานอยู่สิ้นสุดลง

พรอมต์ sshd_config คือจุดที่ผู้ใช้งานมักจะล็อกตัวเองออกจากระบบ การตอบ Y จะเป็นการติดตั้งไฟล์ของผู้ดูแลแพ็กเกจ ซึ่งจะทิ้งค่า PermitRootLogin, PasswordAuthentication, AllowUsers, Port และบรรทัดอื่นๆ ทั้งหมดที่คุณเพิ่มไว้ หากไฟร์วอลล์ของคุณอนุญาตเฉพาะพอร์ตที่กำหนดเอง แต่ค่าคอนฟิกที่มากับแพ็กเกจตั้งค่าให้ฟังที่พอร์ต 22 การเชื่อมต่อครั้งถัดไปจะถูกปฏิเสธ และเซสชันที่คุณกำลังใช้งานอยู่จะเป็นเซสชันสุดท้ายที่คุณมี

ป้องกันปัญหานี้ก่อนที่คุณจะอัปเกรด /etc/ssh/sshd_config บน 24.04 จะเริ่มต้นด้วย Include /etc/ssh/sshd_config.d/*.conf และ OpenSSH จะยึดค่าแรกที่อ่านได้สำหรับแต่ละการตั้งค่า ดังนั้นไฟล์ drop-in ที่รวมไว้ที่ด้านบนสุดจะมีผลเหนือกว่าค่าใดๆ ที่อยู่ด้านล่าง ให้ย้ายการตั้งค่าของคุณไปไว้ในไฟล์ที่ dpkg ไม่ได้เป็นเจ้าของ:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

เมื่อไม่มีสิ่งใดใน /etc/ssh/sshd_config เป็นของคุณอีกต่อไป พรอมต์นั้นก็ไม่มีความสำคัญอีกต่อไป: ไม่ว่าคุณจะตอบอย่างไร การตั้งค่าของคุณจะยังคงอยู่เพราะมันอยู่ในไฟล์อื่น

พอร์ตที่กำหนดเองต้องการการตรวจสอบเพิ่มเติมอีกหนึ่งจุด เพราะมันอาจไม่ได้อยู่ในที่ที่คุณคิด:

systemctl is-enabled ssh.socket

หากคำสั่งดังกล่าวแสดงผล enabled แสดงว่า systemd เป็นผู้ควบคุมพอร์ตที่เปิดฟังอยู่ และบรรทัด Port ใน sshd_config จะถูกละเว้น Ubuntu ใช้ socket activation สำหรับ sshd มาตั้งแต่เวอร์ชัน 22.10 และนี่คือเหตุผลที่การแก้ไข Port 2222 ดูเหมือนจะไม่มีผลใดๆ ให้ตั้งค่าที่ socket unit แทน โดยใช้ sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

การเว้นว่าง ListenStream= เป็นสิ่งจำเป็น มันจะล้างค่าที่สืบทอดมา หากไม่มีบรรทัดนี้ socket จะเปิดฟังทั้งพอร์ต 22 และ 2222 ให้ปรับใช้การตั้งค่าด้วย sudo systemctl daemon-reload && sudo systemctl restart ssh.socket

หลังจากการอัปเกรด ก่อนที่คุณจะปิดเซสชันที่ใช้งานอยู่:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

จากนั้นให้เปิดเทอร์มินัลที่สองบนเครื่องของคุณเองแล้วล็อกอินใหม่อีกครั้ง การมีเชลล์ที่ใช้งานได้ในเทอร์มินัลที่สองนั้นเป็นหลักฐานเดียวที่เชื่อถือได้ ให้เปิดเซสชันแรกทิ้งไว้จนกว่าคุณจะทำสำเร็จ การเพิ่มความปลอดภัยให้ SSH บน VPS จะอธิบายถึงการตั้งค่าที่ควรเก็บไว้ในไฟล์ drop-in นั้น

หากสายเกินไปแล้ว เว็บคอนโซลของผู้ให้บริการของคุณจะให้ช่องทางล็อกอินที่ไม่ผ่าน SSH เลย ให้ล็อกอินผ่านช่องทางนั้น แก้ไขคอนฟิก รัน sudo sshd -t และรีสตาร์ทเซอร์วิส คอนโซลนั้นคือเหตุผลที่คุณต้องทดสอบการเข้าถึงผ่านคอนโซลก่อนการอัปเกรด ไม่ใช่ทดสอบในระหว่างการอัปเกรด

FAQ

ทำไม do-release-upgrade ถึงแจ้งว่า "No new release found" บน Ubuntu 24.04?

เนื่องจาก /etc/update-manager/release-upgrades มีการตั้งค่า Prompt=lts ไว้บน Ubuntu Server ซึ่งการตั้งค่านี้จะเสนอการอัปเกรดเป็นรุ่น Long Term Support (LTS) ถัดไปก็ต่อเมื่อมีการปล่อย point release รุ่นแรกออกมาแล้วเท่านั้น Ubuntu 26.04 LTS ได้ปล่อยออกมาเมื่อวันที่ 23 เมษายน 2026 และรุ่น 26.04.1 มีกำหนดการในวันที่ 27 สิงหาคม 2026 จนกว่าจะถึงวันนั้น เซิร์ฟเวอร์ 24.04 จะไม่พบการอัปเดตใดๆ ควรคงการตั้งค่านี้ไว้แทนที่จะเปลี่ยนเป็น Prompt=normal ซึ่งจะนำคุณไปสู่รุ่น interim releases แทน

จำเป็นต้องรีบูตเซิร์ฟเวอร์เพื่อให้อัปเกรดเสร็จสมบูรณ์หรือไม่?

จำเป็น การอัปเกรดจะติดตั้ง kernel ใหม่, C library ใหม่ และ init system ใหม่ ซึ่งระบบที่กำลังทำงานอยู่จะยังคงใช้ของเดิมจนกว่าจะมีการรีสตาร์ท do-release-upgrade จะแจ้งเตือนให้รีบูตเมื่อเสร็จสิ้น หากปล่อยให้เครื่องทำงานต่อไปจนถึง "ภายหลัง" จะทำให้เครื่องนั้นทำงานด้วยซอฟต์แวร์ผสมกันระหว่างสองรุ่น หลังจากรีบูตกลับมาแล้ว ให้ตรวจสอบ uname -r เพื่อดู kernel ใหม่ และตรวจสอบ systemctl --failed เพื่อดูว่ามีบริการใดที่ไม่สามารถทำงานต่อได้หรือไม่

ควรเลือกอัปเกรดแบบ in-place หรือสร้างเซิร์ฟเวอร์ 26.04 ใหม่?

หากทำได้ควรสร้างเซิร์ฟเวอร์ใหม่ การใช้ VPS ใหม่ช่วยให้คุณติดตั้ง stack, กู้คืนข้อมูล และทดสอบทุกอย่างได้ในขณะที่เซิร์ฟเวอร์เดิมยังคงให้บริการอยู่ ทำให้การย้อนกลับ (rollback) เป็นเพียงการเปลี่ยนค่า DNS แทนการกู้คืนจาก backup ส่วนการอัปเกรดแบบ in-place เหมาะสำหรับเซิร์ฟเวอร์ที่มีสถานะ (state) ที่ย้ายได้ยาก, กรณีที่ผู้ให้บริการคิดค่าใช้จ่ายต่อเครื่อง หรือเมื่อคุณมี snapshot และสามารถเข้าถึง console ได้จริง การอัปเกรดแบบ in-place เป็นวิธีที่ทำกันทั่วไป แต่เป็นเส้นทางที่ย้อนกลับไม่ได้ในช่วงเวลาที่กระบวนการกำลังทำงาน

จะเกิดอะไรขึ้นหากการเชื่อมต่อ SSH หลุดระหว่างการอัปเกรด?

ใน shell ปกติ กระบวนการจะได้รับสัญญาณ SIGHUP และหยุดทำงานกลางคัน ส่งผลให้ dpkg อยู่ในสถานะกำหนดค่าไม่สมบูรณ์ หากเริ่มกระบวนการภายใน tmux หรือ screen กระบวนการจะยังคงทำงานอยู่ คุณจึงสามารถเชื่อมต่อกลับเข้าไปและรัน tmux attach -t upgrade เพื่อดำเนินการต่อได้ นอกจากนี้ตัวอัปเกรดจะเริ่ม SSH daemon สำรองไว้ที่พอร์ต 1022 เป็นช่องทางเข้าที่สอง แต่ไม่ได้เปิด firewall สำหรับพอร์ตดังกล่าวให้โดยอัตโนมัติ ดังนั้นคุณต้องอนุญาตพอร์ต 1022 ด้วยตนเองก่อนเริ่ม และปิดพอร์ตนี้หลังจากเสร็จสิ้น

เว็บไซต์ PHP ของฉันแสดงข้อผิดพลาด 502 หลังอัปเกรด เกิดอะไรขึ้น?

path ของ PHP FPM socket มีการเปลี่ยนแปลงตามเวอร์ชัน Ubuntu 24.04 ใช้ PHP 8.3 ส่วน 26.04 ใช้ PHP 8.5 ดังนั้น /run/php/php8.3-fpm.sock จึงไม่มีอยู่อีกต่อไปในขณะที่ nginx vhost ของคุณยังคงอ้างอิง path เดิมอยู่ โดย nginx error log จะแสดง connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) ให้คุณอัปเดต fastcgi_pass ให้เป็น socket ของเวอร์ชัน 8.5, รัน sudo nginx -t แล้วจึง reload nginx สำหรับ Apache ที่ใช้ mod_php วิธีแก้ไขที่เทียบเท่ากันคือ sudo a2dismod php8.3 ตามด้วย sudo a2enmod php8.5 และทำการรีสตาร์ทบริการ