ย้าย DA จาก CentOS 7 ไป Debian 12 ตอนที่ 4 — Cutover จริง กับ 17 ปัญหาหลังสลับเครื่อง

ตอนที่ 1 ถึง 3 ของซีรีส์นี้ผมเล่าตั้งแต่เตรียม VM กับ NAT pre-stage, ถอด RAID มาทำ ZFS mirror, แล้วลง DA กับ CustomBuild ไปแล้ว ใครยังไม่ได้อ่านแนะนำให้ไล่ตามลำดับก่อน เพราะตอนนี้มันต่อยอดจากสถานะที่เครื่องทั้งสองตัวยืนอยู่

ถึงตอนนี้สถานะเครื่องสรุปสั้นๆ คือแบบนี้

• VM เก่า (CentOS 7) ยังให้บริการอยู่บน bridge ตัวนอก ใช้ public IP จริง ลูกค้ายังใช้งานปกติ
• VM ใหม่ (Debian 12) เตรียมพร้อมบน bridge ตัวใน ใช้ private IP 192.168.1.20
• DA กับ CustomBuild ลงครบ smoke test ผ่านหมด

ทีนี้ถึงเวลา cutover จริง คือการสลับให้เครื่องใหม่ขึ้นมาแทนเครื่องเก่า ตอนแรกผมตั้งใจให้ downtime ใกล้ 0 ด้วย NAT pre-stage trick ที่วางไว้ตั้งแต่ตอน 1 แต่ของจริงเจอกำแพง 2 อันที่ทำให้แผนนั้นพังตั้งแต่ยังไม่เริ่ม

กำแพงที่ 1 — DA Legacy license คือ "last DA wins"

DA Legacy license มันมีข้อจำกัดที่ไม่โผล่ตอนเทสต์ในแล็บ คือมันไม่อนุญาตให้รัน DirectAdmin 2 ตัวพร้อมกันบน license เดียว ตัวไหน activate ทีหลัง ตัวก่อนหน้าจะหลุด license ทันที

แผน NAT pre-stage ของผมตั้งอยู่บนสมมุติฐานว่าจะ start DA ตัวใหม่ขึ้นมาคู่ขนานกับตัวเก่าได้ ให้ลูกค้าทยอยย้ายแบบไม่มีรอยต่อ พอเจอข้อจำกัดนี้แผนก็พังทันที เพราะผมจะ start DA ใหม่ระหว่างที่เครื่องเก่ายัง serve ลูกค้าอยู่ไม่ได้เลย ต้อง stop DA เก่าให้เรียบร้อยก่อน แล้วค่อย start ตัวใหม่ ซึ่งแปลว่ามี downtime แน่นอน ไม่ใช่ 0

กำแพงที่ 2 — qcow2 อ่านช้ามาก

storage layer ของเครื่องเก่าคือ qcow2 วางบน mdadm RAID1 ซ้อนกัน 3 ชั้น พอ DA Admin Backup ต้องอ่านไฟล์ของ user 80 กว่าคนออกไปทำ tarball มันใช้เวลาเป็นชั่วโมง สาเหตุคือ random IO บน qcow2 มันเกิด amplification คือ IO หนึ่งครั้งที่ระดับ guest กลายเป็นหลายครั้งที่ระดับ host อ่านไฟล์เล็กๆ จำนวนมากแบบกระจัดกระจายเลยช้ามาก

รอบแรกผมยังใช้ /bin/gzip default ของระบบ ซึ่งมันเป็น single-threaded บนเครื่อง 16 vCPU เลยเสียพลังไปเปล่าๆ 15 core ที่เหลือนั่งว่าง รอบที่ 2 ผมเปลี่ยนมาใส่ pigz wrapper (ตัวนี้จะเล่าละเอียดในปัญหาข้อ 12) แทน /bin/gzip เร็วขึ้น 4 ถึง 6 เท่า แต่ถึงอย่างนั้น เพราะคอขวดหลักอยู่ที่ random IO บน qcow2 ไม่ใช่ที่ CPU มันก็ยังกินเวลาเป็นชั่วโมงอยู่ดี

ของจริง downtime ลูกค้า 1 ชั่วโมง

พอกำแพง 2 อันนี้รวมกัน แผน downtime ใกล้ 0 ก็จบ กลายเป็น downtime จริงประมาณ 1 ชั่วโมง ผมแบ่งช่วงเวลาคร่าวๆ ให้ดูว่าเวลาไปอยู่ตรงไหนบ้าง

• ปิด DA กับ services เก่า (จุดนี้คือเริ่มนับ downtime ลูกค้า) — 5 นาที
• DA Admin Backup เครื่องเก่า (qcow2 IO ช้า บวกกับรอบแรกยังไม่ได้ใช้ pigz) — หลายชั่วโมง
• transfer backup tarball ออกไปยัง FTP destination — 1 นาที
• swap IP กับ MAC ของ VM ใหม่ให้ตรงกับเครื่องเก่า แล้วลบ NAT rules ทิ้ง — 5 นาที
• shutdown VM เก่า แล้ว start VM ใหม่ — 2 นาที (ARP refresh แค่วินาทีเดียว)
• DA fixup config คือ rewrite NAT IP 192.168.1.20 กลับไปเป็น IP จริง — 5 นาที
• start DA ใหม่ แล้ว license claim — 30 วินาที
• Admin Restore wizard อ่านจาก stored backup — 1.5 ชั่วโมง
• copy custom data แล้ว apply 29 DA settings — 15 นาที
• start httpd, exim, dovecot, rspamd — 1 นาที
• smoke test 10 sites แบบสุ่ม — 10 นาที

รวมแล้วลูกค้าเริ่มใช้งานได้จริงประมาณ 1 ชั่วโมง ตรงนี้ขอแยกให้ชัด ส่วนที่ลูกค้า "ใช้เน็ตไม่ได้เลย" คือช่วง downtime จริง ส่วน Admin Restore wizard 1.5 ชม. นั้นบางส่วนทำงานหลังจาก IP ขึ้นแล้ว เว็บหลักๆ กลับมาเร็วกว่านั้น ส่วนที่ restore ช้าคือ data ของแต่ละ user ที่ทยอยกลับมา

คำสั่ง cutover (rewrite NAT IP กลับเป็น public IP)

ตอนสลับ ผมต้องไล่แก้ทุกที่ที่ DA จด private IP เอาไว้ ให้กลายเป็น public IP จริง จุดสำคัญคือ DA ไม่ได้เก็บ IP ไว้ที่เดียว มันกระจายอยู่หลายไฟล์ ทั้ง config หลัก, directory ของ ip, ไฟล์ list, แล้วก็ template ต่างๆ ต้องไล่ครบทุกที่ ไม่งั้นจะมีบางส่วนยัง bind private IP อยู่

# rewrite IP ใน config หลักของ DA
sed -i 's|^ip=192.168.1.20|ip=203.0.113.42|; s|^serverip=192.168.1.20|serverip=203.0.113.42|' \
    /usr/local/directadmin/conf/directadmin.conf

# rename directory ของ ip (DA ตั้งชื่อ dir ตาม IP)
mv /usr/local/directadmin/data/admin/ips/192.168.1.20 \
   /usr/local/directadmin/data/admin/ips/203.0.113.42

# แก้ ip.list
sed -i 's|^192.168.1.20|203.0.113.42|' /usr/local/directadmin/data/admin/ip.list

# ไล่แก้ทุก template ที่มี private IP ฝังอยู่
grep -rln '192.168.1.20' /usr/local/directadmin/data/templates/ | \
    xargs -I{} sed -i 's|192.168.1.20|203.0.113.42|g' {}

# ถึงค่อย start DA — license จะ claim ตอนนี้
systemctl start directadmin

ลำดับสำคัญ ต้อง rewrite ให้ครบก่อน แล้วค่อย systemctl start directadmin ถ้า start ก่อนแก้ DA จะ regenerate config ที่ยัง bind private IP ทำให้ Apache start ไม่ขึ้น

Key trick ที่ work ของจริง — IP กับ MAC reuse

ส่วนที่ทำงานได้สวยที่สุดในแผน คือการให้ VM ใหม่ใช้ public IP เดิม บวกกับ MAC address เดิมของเครื่องเก่า พอ MAC ตรง upstream router แค่ refresh ARP cache วินาทีเดียว packet ก็ flow ต่อทันที

ผลพลอยได้คือลูกค้าไม่ต้องทำอะไรเลย ไม่ต้องเปลี่ยน DNS, ไม่ต้องแก้ config FileZilla, ไม่ต้องแก้ Outlook อะไรทั้งสิ้น ทุกอย่างชี้ IP เดิม mail server เดิม FTP เดิม ลูกค้าไม่รู้ด้วยซ้ำว่าเครื่องเปลี่ยนไปแล้ว ตรงนี้คือส่วนที่ตามแผน "swap 30 วินาที" จริงๆ แต่ปัญหาคือมันเกิดขึ้น หลัง backup ที่กินเวลาหลายชั่วโมงไปแล้ว เลยไม่ได้ช่วยลด downtime ตามที่หวัง

ทำไมไม่ใช้ DA's ipswap.sh

ใช้ได้ครับ แต่มันไม่จำเป็นในเคสนี้ ipswap.sh จะไป rewrite domain.conf ของทุก user ซึ่งเพิ่ม rollback complexity ถ้ามีอะไรพลาดต้องไล่ย้อนเยอะ ส่วนตัวผม IP กับ MAC reuse ที่ระดับ network มันง่ายกว่ามาก แตะไฟล์น้อยกว่า rollback ก็แค่ย้าย IP/MAC กลับ ไม่ต้องไปยุ่งกับ config ของ user

ทำไมไม่ pre-add IP แบบ metadata-only

ผมเคยลองแล้ว คือพยายามเพิ่ม public IP เข้าไปใน DA แบบ metadata อย่างเดียว โดยที่ยังไม่ยก IP ขึ้น NIC จริง ผลคือ Apache fail ทันที

AH00072: make_sock: could not bind to address 203.0.113.42:80

เหตุผลคือ DA generate config ออกมาเป็น <VirtualHost 203.0.113.42:80> บวกกับ Listen 203.0.113.42:80 แบบระบุ IP ตรงๆ ไม่ใช่ wildcard เพราะฉะนั้น IP ตัวนั้นต้องอยู่บน NIC จริงๆ ตอน Apache start ไม่ใช่แค่มีใน metadata ของ DA ถ้า IP ไม่ได้ผูกกับ interface จริง bind ไม่ได้ Apache ก็ไม่ขึ้น นี่คือเหตุผลว่าทำไม IP+MAC reuse ถึงต้องเกิด หลัง backup ไม่ใช่ก่อน

Lesson learned — ถ้าทำใหม่จะทำยังไง

cutover รอบนี้สอนผม 3 เรื่องหลัก ที่ถ้าได้ทำ migration ครั้งหน้าจะทำต่างออกไป

• ย้าย storage เป็น ZFS ก่อน cutover ZFS มี native snapshot แล้วก็ zfs send/zfs receive ที่ส่ง state ของ VM เก่าไปเครื่องใหม่ได้ในไม่กี่นาที เทียบกับ DA backup ที่กินหลายชั่วโมงมันคนละโลกกัน ตรงนี้ผมยังไม่ได้ลองจริง migration ครั้งหน้าตั้งใจจะ test ดู
• ใช้ pigz wrapper ตั้งแต่แรก แทน /bin/gzip default ที่เป็น single-threaded ลด backup time ลง 4 ถึง 6 เท่า เรื่องนี้รู้ตั้งแต่ตอนกลางๆ งานแต่ควรเซ็ตไว้ตั้งแต่เริ่ม
• อัพ DA license เป็น Modern (subscription) มันไม่มีข้อจำกัด "last DA wins" รัน 2 DA พร้อมกันได้ ซึ่งจะทำให้ NAT pre-stage trick work เต็มศักยภาพจริงๆ ใครงบถึงตรงนี้คุ้ม เพราะมันคือสิ่งที่ทำให้ downtime ใกล้ 0 ได้จริง

17 ปัญหาที่เจอหลัง cutover

หลังจาก downtime ก้อนใหญ่จบ ลูกค้าเริ่มใช้งานได้ ตอนนั้นผมคิดว่าน่าจะ smooth แล้ว ปรากฏว่าโดน 17 ปัญหาเข้ามารัวๆ บางตัวยังบังตัวอื่นด้วย คือแก้ตัวหนึ่งจบ อีกตัวถึงโผล่ ต้องไล่แก้ตามลำดับ ผมจะไล่ให้ฟังคร่าวๆ ก่อน ส่วนเรื่อง security fixes ลึกๆ จะเก็บไปเล่าเต็มๆ ตอนที่ 5

ผมแบ่งเป็น 3 ระดับ — critical คือ web stack ดับทั้งระบบ, medium คือบาง subset ใช้ไม่ได้, minor คือ debugging notes กับ improvement ที่ควรรู้ไว้

critical — web stack ดับทั้งระบบ

1. OpenSSL SECLEVEL=2 บล็อก nginx กับ Apache Debian 12 ใช้ OpenSSL 3 ที่ default SECLEVEL=2 ซึ่งปฏิเสธ SHA1 กับ MD5 ใน CA chain cert legacy ของลูกค้าบางคนยังมี SHA1 intermediate อยู่ พอแม้แต่ใบเดียวเสีย web stack ทั้งระบบไม่ start เลย ไม่ใช่แค่ site นั้น site เดียว ผมแก้ที่ /etc/ssl/openssl.cnf โดยใส่ CipherString = DEFAULT@SECLEVEL=0 ชั่วคราว

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
CipherString = DEFAULT@SECLEVEL=0
Options = UnsafeLegacyServerConnect

แล้ว systemctl restart nginx httpd ให้ web กลับมาก่อน จากนั้นค่อยๆ reissue cert ของลูกค้าผ่าน Let's Encrypt ทีละราย พอครบ 60 ถึง 90 วันที่ cert ใหม่หมุนครบแล้วค่อย raise กลับไป SECLEVEL=2 รายละเอียดส่วน hardening เก็บไว้ตอน 5

2. nginx duplicate listen แบบ TAB-indented ตัวนี้เป็น bug ของ DA 1.7+ ตอน ./build rewrite_confs มันใส่บรรทัด listen ที่ขึ้นต้นด้วย TAB เข้าไปซ้ำกับบรรทัดที่มีอยู่แล้ว (ซึ่ง indent ด้วย space) พอ nginx -t มันฟ้อง duplicate ทันที web ไม่ขึ้น แก้ถาวรคือเขียน post-hook ใน CustomBuild ที่ /usr/local/directadmin/custombuild/custom/post.rewrite_confs.sh ให้ sed strip บรรทัด listen ที่ขึ้นต้นด้วย TAB ออกหลัง rebuild ทุกครั้ง จะได้ไม่ต้องมานั่งแก้มือทุกรอบที่ rebuild

3. Subdomain ใช้ PHP version เก่าเกินไป HTTP 500 DA เก็บ PHP version ของ subdomain ไว้ใน URL-encoded format เช่น %31 คือ slot 1, %33 คือ slot 3 ปัญหาคือตอน restore slot mapping ไม่ตรงกับเครื่องเก่า เช่นเครื่องเก่า slot 3 คือ PHP 7.4 แต่เครื่องใหม่ slot 3 ดันเป็น PHP 5.6 พอ composer autoload ที่เขียน ?? null-coalescing เอาไว้ มันใช้ได้บน 7.4 แต่ 5.6 parse ไม่ได้ เว็บเด้ง 500 ทันที แก้ผ่าน DA panel ไปที่ User Level แล้ว Domain Setup คลิก subdomain เลือก PHP Version Selector แล้ว save ระวังตรงนี้ ถ้าไปกด Modify Domain มันจะแก้แค่ domain หลักไม่แตะ subdomain

4. Reseller package หาย user backup tarballs มี user.conf มาด้วยก็จริง แต่ไม่มี .pkg template file ติดมา ถ้า admin backup ไม่สมบูรณ์ package จะหายเฉยๆ user ที่ผูกกับ package นั้นจะเสีย config ตามมา แก้โดย recreate ไฟล์ .pkg ขึ้นมาใหม่จาก user.conf ของ user ที่ใช้ package นั้นอยู่ ถอด setting ออกมาประกอบเป็น template กลับ

medium — บาง subset ใช้ไม่ได้

5. private_html / public_html symlink direction กลับ ของ DA รุ่นก่อน 1.6 มันแยก HTTPS content ไว้ใน private_html ส่วนรุ่นหลัง 1.6 รวมไว้ใน public_html แล้วทำ symlink เชื่อม พอ restore ข้าม version กัน symlink direction มันกลับด้าน ผลคือ HTTPS แสดง content ผิด แก้ทีละ user คือ ls -la ดูทิศ symlink แล้วจัดใหม่ให้ถูก

6. DA FTP backup ฟ้อง "FTP information invalid" error ตัวนี้หลอกมาก มันขึ้นข้อความ generic แต่จริงๆ มีปัญหา 3 layer ซ้อนกัน — (a) /home/tmp หายหลัง restore ซึ่ง DA ใช้ที่นี่ stage ไฟล์ก่อนส่ง (b) proftpd บนเครื่อง destination ไม่ได้ chroot (c) CSF บนเครื่อง source ตัด outbound port 21 ทิ้ง ต้องแก้ครบทั้ง 3 ชั้น error ถึงหาย ถ้าแก้แค่ชั้นเดียวมันก็ยังขึ้นข้อความเดิมอยู่ดีเลยไล่ยาก

7. DA scheduled backup เงียบ ไม่ fire ตัว DA install บน Debian มันไม่ใส่ per-minute dataskq cron line ให้ แล้ว daemon mode ก็ไม่ scan backup_crons.list เอง ผลคือ scheduled backup ตั้งไว้แต่ไม่เคยทำงาน เงียบสนิทไม่มี error แก้โดยใส่ cron ที่ /etc/cron.d/directadmin_cron ให้รัน dataskq ทุกนาที

* * * * * root /usr/local/directadmin/dataskq d800

8. FTPS handshake fail เพราะ TLS cert directive proftpd-basic ที่ ship มากับ Debian config มันใช้ directive TLSECCertificateFile ชี้ไปที่ cert ของ DA ที่ /etc/exim.cert ซึ่งจริงๆ เป็น RSA cert ไม่ใช่ ECC พอ directive ไม่ตรงชนิด cert มันก็ handshake fail แบบเงียบๆ ไม่มี error ชัดๆ แก้โดย sed เปลี่ยน TLSECCertificateFile เป็น TLSRSACertificateFile ในไฟล์ tls.conf

9. CSF MODSEC_LOG path ผิด DA กับ nginx-modsec ship CSF config มาด้วย MODSEC_LOG = "/var/log/apache/modsec_audit.log" แต่ ModSec3 ของ nginx จริงๆ มัน log ไปที่ /var/log/nginx/error_log ผลคือ scanner ที่ ModSec ตรวจเจอไม่โดน ban ตามที่ตั้งไว้ เพราะ CSF อ่าน log ผิดไฟล์ มันก็ไม่เห็น event ที่ควรจะ trigger การ ban แก้ path ให้ตรงกับที่ ModSec3 เขียนจริง

10. CSF BLOCK_REPORT ไม่ fire สำหรับ csf -d direct DA's BFM (Brute Force Monitor) เรียก csf -d ตรงๆ ซึ่ง bypass LFD ไปเลย ผลคือ BLOCK_REPORT hook ที่ตั้งไว้ไม่ fire ปัญหานี้เด่นชัดเมื่อลูกค้า office IP rotate แบบ PPPoE คือ IP เปลี่ยนไปเรื่อย static csf.allow เลยใช้ไม่ได้ พอโดน ban ก็ไม่มี report แจ้ง แก้ 2 ชั้น — ทำ BLOCK_REPORT hook กับ periodic sweep cron รายละเอียดเต็มเก็บไว้ตอน 5

minor — debugging notes กับ improvements

11. CSF TCP_OUT block relay port mail relay บางเจ้าใช้ port ที่ไม่ standard เช่น 2525 หรือ 24 พอ CSF default block outbound port พวกนี้ mail relay ก็ไม่ออก แก้โดยเพิ่ม port ที่ relay ใช้เข้าไปใน TCP_OUT กับ TCP6_OUT

12. pigz wrapper ทำให้ DA backup เร็วขึ้น 4-6 เท่า ตัวนี้แหละที่ช่วย save downtime ของผมในรอบหลัง เดิม DA Admin Backup เรียก /bin/gzip ซึ่ง single-threaded บนเครื่อง 16 vCPU เสียพลังเปล่า แก้ด้วยการ apt install pigz แล้ว mv /bin/gzip /bin/gzip.bin จากนั้นวาง wrapper script แทนที่ /bin/gzip ให้เรียก pigz ที่กิน core ครบ

apt install -y pigz
mv /bin/gzip /bin/gzip.bin
cat > /bin/gzip <<'EOF'
#!/bin/sh
exec /usr/bin/pigz "$@"
EOF
chmod +x /bin/gzip

ผลคือ backup ก้อน 150 GB จากเดิม 45 นาที เหลือ 10 ถึง 12 นาที วิธีนี้ตรงคือ DA ไม่รู้ตัวด้วยซ้ำ มันเรียก /bin/gzip เหมือนเดิม แต่ของจริงคือ pigz ทำงานแทน

13. Debian sudoers binary paths ต่างจาก CentOS อันนี้ระวัง บน Debian ตัว exim อยู่ที่ /usr/sbin/exim ไม่ใช่ /usr/bin/exim แบบ CentOS ผลคือ sudoers entry ที่ก๊อปมาจาก CentOS มัน path ไม่ตรง พอ path ไม่ match กฎ sudoers ก็ fall through เงียบๆ ไปขอ password แทน ซึ่งทำให้ script ที่เคยรันอัตโนมัติได้บน CentOS มันค้างรอ password บน Debian ต้องไล่แก้ path ใน sudoers ให้ตรงกับ Debian

14. DA PHP conf override pattern ตัวนี้ผมครอบไปแล้วในตอน 3 คือใช้ pattern 99-custom-*.ini ใครยังไม่เห็นกลับไปอ่านตอน 3 ได้

15. Sudoers wildcard path traversal vulnerability อันนี้ระดับ CVE เลยครับ จะเล่าเต็มๆ ตอน 5 ใครใช้ wildcard * ใน sudoers entry อยู่ บอกไว้ก่อนว่าต้องดู

16. csfpost.sh path precedence แบบ silent regression CSF มันเช็ค 2 path คือ /usr/local/csf/bin/csfpost.sh กับ /etc/csf/csfpost.sh แต่มันรันแค่อันเดียว /usr/local ชนะ ตัวที่อยู่ใน /etc/csf ตายเงียบๆ ไม่มี warning ใครวางกฎไว้ใน /etc/csf แล้วคิดว่าทำงานอยู่ จริงๆ มันไม่รัน แก้ด้วย drop-in pattern จะเล่าตอน 5

17. DA domain alias pattern อันนี้เป็น lesson learned ไม่ใช่ bug domains.list คือ primary ส่วน alias อยู่ใน .pointers ตัว Apache log file จะตั้งชื่อตาม primary เสมอ แต่ WordPress siteurl อาจชี้ไป alias พอจะ grep หา traffic หรือไล่ log ของ site ที่ลูกค้าเข้าผ่าน alias อาจหาผิดไฟล์ ระวังตรงนี้ตอน debug

ปิดท้าย

cutover รอบนี้สอนชัดอย่างหนึ่ง คือแผนที่สวยในแล็บไม่ได้แปลว่ามันจะรอดในของจริง กำแพง license กับ qcow2 IO เป็นสองตัวที่ไม่โผล่ตอน smoke test แต่โผล่ตอน cutover พอดี ส่วน 17 ปัญหาหลังย้ายส่วนใหญ่มาจากความต่างระหว่าง CentOS กับ Debian บวกกับ slot mapping ที่ไม่ตรงตอน restore ซึ่งถ้ารู้ pattern ไว้ก่อนก็ไล่แก้ได้ไม่ยาก

ตอนสุดท้าย ตอนที่ 5 จะมาเล่า security fixes ลึกๆ กับ hardening ซึ่งเป็นตอนเด็ดของซีรีส์ มี sudoers wildcard CVE ที่หลายคนยังไม่รู้ ใครยังใช้ wildcard * ใน sudoers entry อยู่ ตอนนั้นต้องดูให้ดี

ใครจะย้ายด้วย storage หรือ license แบบไหนก็ตามสะดวก หลักการมันเหมือนกันหมด ไว้นึกอะไรออกเพิ่มจะมาแก้ทีหลังครับ