วิธีแก้ไขปัญหา /etc/machine-id ซ้ำกันหลังโคลน VPS

/etc/machine-id คืออะไร และเหตุใดการมีค่าซ้ำกันจึงเป็นปัญหา

VPS ที่ถูกโคลนมาจะบูตขึ้นมาพร้อมกับ /etc/machine-id เดียวกันกับเซิร์ฟเวอร์ต้นฉบับ ซึ่งค่านี้ควรจะเป็นค่าเฉพาะสำหรับหนึ่งการติดตั้งเท่านั้น วิธีแก้ไขประกอบด้วย 4 คำสั่ง ได้แก่ ล้างเนื้อหาในไฟล์, ลบไฟล์สำเนาของ D-Bus หากเป็นไฟล์จริง, สร้างค่าใหม่ และรีบูตเครื่อง ขั้นตอนการรีบูตเป็นสิ่งที่คนมักมองข้าม แต่เป็นขั้นตอนที่ทำให้การเปลี่ยนแปลงมีผล

/etc/machine-id เก็บสตริงเลขฐานสิบหกขนาด 32 ตัวอักษรที่เป็นตัวพิมพ์เล็กและปิดท้ายด้วย newline เมื่อถอดรหัสแล้วจะได้ค่าขนาด 16 ไบต์ (128 บิต) หน้าคู่มือของ machine-id(5) ระบุว่าค่านี้เป็นข้อมูลลับและห้ามเปิดเผยบนเครือข่าย เนื่องจากสิ่งที่อ่านค่านี้ได้จะสามารถจดจำเครื่องของคุณได้ในภายหลัง ค่านี้จะถูกเขียนขึ้นเพียงครั้งเดียวเมื่อติดตั้งระบบและไม่มีสิ่งใดเปลี่ยนแปลงมันหลังจากนั้น

มีตัวระบุ 3 ประเภทที่มักสับสนกันในเรื่องนี้ จึงควรแยกออกจากกันให้ชัดเจน Hostname คือป้ายกำกับที่คุณเลือกและเปลี่ยนได้ตลอดเวลา DMI (desktop management interface) product UUID ใน /sys/class/dmi/id/product_uuid มาจาก hypervisor และอ่านได้เฉพาะ root เท่านั้น ส่วน machine ID คือตัวระบุที่สาม ซึ่งระบบปฏิบัติการเป็นผู้สร้างขึ้นและผู้ใช้ทุกคนบนเครื่องสามารถอ่านได้

สิ่งที่อ่านค่า machine ID จริงๆ คืออะไร

DHCP client identifier นี่คือส่วนที่สร้างปัญหามากที่สุด systemd.network(5) ระบุไว้ใน ClientIdentifier= ภายใต้หัวข้อ [DHCPv4] ว่าค่าเริ่มต้นคือ duid ซึ่งจะส่ง client ID ตามมาตรฐาน RFC 4361 ที่สร้างจาก IAID และ DUID (DHCP unique identifier) networkd.conf(5) ระบุประเภท DUID เริ่มต้นไว้เป็น vendor โดยค่า DUID จะถูกสร้างขึ้นโดยใช้ 43793 เป็นรหัสผู้ผลิต (systemd) และใช้เนื้อหาของ machine ID มาทำแฮช DHCPv6 ก็ใช้ DUID รูปแบบเดียวกัน หากมีเครื่องโคลนสองเครื่องที่มี machine ID เดียวกัน ค่าแฮชของ DUID ก็จะเหมือนกัน และหากทั้งสองเครื่องยังคงใช้ชื่ออินเทอร์เฟซเดิม ทั้งคู่ก็จะส่ง client identifier ที่มีข้อมูลไบต์เหมือนกันทุกประการ ส่งผลให้ DHCP server มองเห็นเป็นไคลเอนต์เพียงรายเดียวแทนที่จะเป็นสองราย และเสนอ IP lease เดียวกันให้กับทั้งสองเครื่อง อาการที่พบคือ IP address จะสลับไปมาระหว่างเซิร์ฟเวอร์ทั้งสองเครื่อง หรือเซิร์ฟเวอร์เครื่องหนึ่งจะสูญเสีย IP address ทันทีที่อีกเครื่องทำการต่ออายุ lease

journald ไฟล์บันทึกของ journal จัดเก็บอยู่ใน /var/log/journal/<machine-id>/ โดยชื่อไดเรกทอรีจะตั้งตาม ID นั้นโดยตรง หากคุณส่งไฟล์ journal จากเครื่องโคลนสองเครื่องไปยังตัวรวบรวมข้อมูล (collector) เดียวกัน ข้อมูลจะถูกเขียนลงในไดเรกทอรีเดียวกันและถูกอ่านเสมือนว่าเป็นโฮสต์เดียว

D-Bus /var/lib/dbus/machine-id คือจุดเริ่มต้นของรูปแบบไฟล์นี้ บน Debian และ Ubuntu ไฟล์นี้จะเป็น symlink ไปยัง /etc/machine-id ในบางระบบ ไฟล์นี้จะเป็นไฟล์จริงที่แยกออกมาต่างหากและเก็บสำเนาของตัวเองไว้ ซึ่งสำเนานี้เองที่เป็นกับดักในขั้นตอนการดำเนินการด้านล่าง

เอเจนต์ระดับโฮสต์ (Per-host agents) เอเจนต์สำหรับตรวจสอบระบบ (monitoring agents), การตรวจสอบสิทธิ์การใช้งาน (licence checks), เครื่องมือทำรายการทรัพย์สิน (inventory tools) และไคลเอนต์สำรองข้อมูล มักใช้ machine ID เป็นตัวระบุโฮสต์เริ่มต้นเนื่องจากมีความเสถียรและไม่ต้องตั้งค่าเพิ่มเติม การที่เซิร์ฟเวอร์สองเครื่องรายงานตัวตนเดียวกันหมายถึงข้อมูลเมตริกจะถูกรวมเข้าด้วยกัน หรือสิทธิ์การใช้งานซอฟต์แวร์หนึ่งชุดจะถูกนับรวมทั้งสองเครื่อง ให้ตรวจสอบว่าเอเจนต์ของคุณใช้วิธีใดในการระบุ host ID แทนที่จะอนุมานว่าเอเจนต์ใช้ hostname เพียงอย่างเดียว

วิธีตรวจสอบว่าคุณมีค่าซ้ำหรือไม่

ให้รันคำสั่งนี้บนเซิร์ฟเวอร์ทั้งสองเครื่องแล้วเปรียบเทียบผลลัพธ์ที่ได้

cat /etc/machine-id
ls -l /var/lib/dbus/machine-id
sudo cat /sys/class/dmi/id/product_uuid

หากเครื่องที่ใช้งานอยู่สองเครื่องมี machine ID เหมือนกัน แสดงว่าเครื่องหนึ่งถูกโคลนมาจากอีกเครื่องหนึ่ง คุณสามารถใช้ hostnamectl เพื่อแสดงค่าเดียวกันในบรรทัด Machine ID: ได้หากต้องการใช้คำสั่งเดียว

ผลลัพธ์จาก ls -l จะเป็นตัวกำหนดขั้นตอนถัดไป หากเป็น symlink จะมีลักษณะดังนี้:

lrwxrwxrwx 1 root root 15 Aug 21 09:12 /var/lib/dbus/machine-id -> /etc/machine-id

หากบรรทัดเริ่มต้นด้วย -rw-r--r-- แสดงว่าเป็นไฟล์จริงที่เก็บสำเนาของ ID เก่าไว้ คุณต้องลบไฟล์นี้ทิ้ง เนื่องจาก systemd-machine-id-setup จะอ่านค่าจากไฟล์นี้ก่อนดำเนินการอื่นใด

ค่า product UUID ก็มีความสำคัญเช่นกัน systemd-machine-id-setup(1) จะใช้ KVM UUID ก่อนที่จะเปลี่ยนไปใช้วิธีสุ่มค่า ดังนั้นหากผู้ให้บริการของคุณกำหนด SMBIOS (system management BIOS) UUID เดียวกันให้กับเครื่องโคลนทั้งสองเครื่อง การสร้าง ID ใหม่ก็จะยังคงให้ค่า machine ID เดิมซ้ำกัน หากเครื่องทั้งสองเครื่องมี product UUID ที่แตกต่างกัน คุณก็ไม่มีเรื่องต้องกังวลในส่วนนี้

การสร้าง machine ID ใหม่บน VPS ที่โคลนมา

ลำดับขั้นตอนมีความสำคัญ systemd-machine-id-setup(1) ระบุว่าหากระบบมี D-Bus machine ID ที่ถูกต้องอยู่แล้ว ID นั้นจะถูกคัดลอกไปใช้เพื่อเริ่มต้นค่า /etc/machine-id หากปล่อยไฟล์ /var/lib/dbus/machine-id ที่มีค่าจริงทิ้งไว้ คุณจะได้ค่าเดิมกลับมาซึ่งเป็นค่าที่คุณต้องการลบออก

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id       # only if ls -l showed a real file
sudo systemd-machine-id-setup
sudo ln -sf /etc/machine-id /var/lib/dbus/machine-id
cat /etc/machine-id

จำเป็นต้องล้างข้อมูลในไฟล์ก่อน เพราะเครื่องมือนี้จะทำงานก็ต่อเมื่อไฟล์หายไปหรือว่างเปล่าเท่านั้น และจะไม่ทำอะไรกับไฟล์ที่มี ID ที่ถูกต้องอยู่แล้ว systemd-machine-id-setup จะรายงานสิ่งที่ทำลงไปผ่าน standard error สำหรับ VPS แบบ KVM โดยปกติคุณจะเห็นข้อความดังนี้:

Initializing machine ID from KVM UUID.

Initializing machine ID from random generator. คือข้อความที่จะปรากฏเมื่อไม่มี hypervisor UUID ให้ใช้งาน ผลลัพธ์ทั้งสองแบบถือว่าใช้ได้ ตราบใดที่ cat /etc/machine-id แสดงค่าที่แตกต่างจากเซิร์ฟเวอร์เครื่องอื่น

การใช้ symlink ช่วยให้ D-Bus และ systemd ใช้ค่าเดียวกัน หากคุณต้องการแยกเป็นไฟล์จริงต่างหาก ให้รันคำสั่ง sudo dbus-uuidgen --ensure แทน ซึ่งจะสร้างไฟล์พร้อม UUID ใหม่ในกรณีที่ไฟล์ยังไม่มีอยู่ หากไม่ได้ติดตั้ง dbus ไว้ จะไม่มีไดเรกทอรี /var/lib/dbus อยู่เลย และ ln จะล้มเหลวด้วยข้อความ No such file or directory ซึ่งในกรณีนี้คุณสามารถข้ามทั้งสองบรรทัดนั้นไปได้เลย

จากนั้นให้รีบูตเครื่อง

sudo reboot

เหตุผลที่การรีบูตไม่ใช่ทางเลือก

ทุกกระบวนการที่อ่านค่าเก่าไปแล้วจะยังคงใช้งานค่านั้นอยู่ sd_id128_get_machine() จะแคช ID ไว้ภายในกระบวนการที่เรียกใช้ ดังนั้น daemon ที่กำลังทำงานอยู่จึงไม่มีทางทราบได้เลยว่าไฟล์มีการเปลี่ยนแปลง journald ได้เปิด /var/log/journal/<old-id>/system.journal ค้างไว้และยังคงเขียนข้อมูลต่อท้ายไฟล์เดิมอย่างต่อเนื่อง systemd-networkd ได้กำหนดค่า DUID ของตนเองตั้งแต่เริ่มทำงานและยังคงส่ง client identifier ตัวเดิมในการต่ออายุทุกครั้ง ซึ่งมักเป็นสาเหตุของความล้มเหลวที่คุณพยายามแก้ไข D-Bus ก็อ่าน ID ของตนเองตั้งแต่ตอนเริ่มทำงานเช่นกัน คุณสามารถรีสตาร์ทบริการทีละรายการได้ แต่คุณจะพลาดบางรายการไป และ PID 1 ก็ยังคงถือค่าเก่าไว้อยู่เช่นกัน

หลังจากรีบูตแล้ว ให้ตรวจสอบทั้งสองส่วน:

cat /etc/machine-id
ls /var/log/journal/

/var/log/journal/ จะมีไดเรกทอรีที่สองซึ่งตั้งชื่อตาม ID ใหม่ปรากฏขึ้น และรายการบันทึกใหม่จะถูกเก็บไว้ที่นั่น journalctl แบบปกติจะอ่านเฉพาะไดเรกทอรีของเครื่องปัจจุบันเท่านั้น ดังนั้นประวัติก่อนการโคลนจะหายไปจากมุมมองเริ่มต้น ข้อมูลดังกล่าวยังคงอยู่บนดิสก์: journalctl --merge จะอ่านทุกไดเรกทอรีของ journal รวมถึงไดเรกทอรีเก่าด้วย ให้ลบไดเรกทอรีเก่าทิ้งเมื่อคุณมั่นใจแล้วว่าไม่จำเป็นต้องใช้ log เหล่านั้นอีกต่อไป

นี่คือเหตุผลที่คุณไม่สามารถทดลองทำตามขั้นตอนนี้ใน container ได้ เนื่องจาก container ใช้ kernel ร่วมกับโฮสต์และไม่ได้บูต PID 1 ของตนเอง ซึ่งการรีบูตคือหัวใจสำคัญของกระบวนการนี้ ให้ทดสอบด้วยวิธีเดียวกับที่เกิดขึ้นในสภาพแวดล้อมจริง: โคลน VM, รันคำสั่ง, รีบูต จากนั้นเปรียบเทียบ ID กับเครื่องต้นทาง

ตัดข้อมูลให้ว่างก่อนทำ snapshot ไม่ใช่ทำหลังจาก clone

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

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo shutdown -h now

ให้ล้างข้อมูลในไฟล์ให้ว่างเปล่า ห้ามลบไฟล์ทิ้ง machine-id(5) แนะนำให้ใช้ไฟล์ว่างสำหรับ image ที่นำไปใช้กับเครื่องหลายเครื่อง เพราะการมีไฟล์ว่างวางไว้ในตำแหน่งเดิมจะช่วยให้สามารถ bind-mount ไฟล์ชั่วคราวทับไฟล์จริงได้ในกรณีที่ใช้งาน image แบบ read-only บน /etc ที่เป็น read-only นั้น ID ที่ถูกสร้างขึ้นตอนบูตจะอยู่ในไฟล์ชั่วคราว และ systemd-machine-id-setup --commit จะเขียนข้อมูลลงไปเมื่อ filesystem เปลี่ยนสถานะเป็น writable

ผลข้างเคียงประการหนึ่งที่ต้องวางแผนรับมือคือ การที่ machine ID ไม่ถูกระบุค่าไว้จะทำให้การบูตครั้งถัดไปถูกมองว่าเป็น first boot ดังนั้น unit ที่มี ConditionFirstBoot=yes จะทำงานในการบูตครั้งนั้นและถูกข้ามไปในการบูตครั้งต่อๆ ไปทั้งหมด ให้ตรวจสอบว่า image ของคุณจะรันคำสั่งใดบ้างด้วย grep -rl ConditionFirstBoot /usr/lib/systemd/system/ ก่อนที่คุณจะสร้าง template

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

เหตุใด cloud image จึงจัดการเรื่องนี้ได้ถูกต้องในขณะที่ snapshot ของคุณทำไม่ได้

Cloud image ของระบบปฏิบัติการถูกสร้างมาเพื่อการโคลน ดังนั้นจึงถูกจัดส่งมาโดยที่ machine ID ยังไม่ได้ถูกกำหนดค่าไว้ และจะถูกเติมให้สมบูรณ์ในการบูตครั้งแรก cloud-init มีขั้นตอนที่ระบุไว้ชัดเจนสำหรับเรื่องนี้โดยเฉพาะ cloud-init clean --machine-id จะตั้งค่า /etc/machine-id ให้เป็นสตริงตัวอักษร uninitialized บนระบบที่ใช้ systemd และคู่มืออ้างอิง CLI ของ cloud-init ก็ระบุว่านี่เป็นแนวทางปฏิบัติที่ดีที่สุดเมื่อทำการโคลน golden image เพื่อให้การบูตครั้งถัดไปของ image นั้นสร้าง machine ID ที่ไม่ซ้ำกันขึ้นมาใหม่

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

สิ่งที่การโคลนคัดลอกมาด้วย

• SSH host keys: /etc/ssh/ssh_host_* จะถูกคัดลอกมาด้วย ทำให้เซิร์ฟเวอร์ทั้งสองเครื่องแสดง fingerprint เดียวกันแก่ไคลเอนต์ ให้ลบไฟล์เหล่านั้นออกแล้วรัน sudo ssh-keygen -A หรือ sudo dpkg-reconfigure openssh-server บน Debian และ Ubuntu หลังจากนั้นไคลเอนต์ของคุณจะแจ้งเตือนเรื่อง host key ที่เปลี่ยนแปลง ซึ่งถือเป็นพฤติกรรมที่ถูกต้อง
• Hostname: ตั้งค่าใหม่ด้วย sudo hostnamectl set-hostname app02 จากนั้นตรวจสอบว่า /etc/hosts ยังคง resolve ชื่อใหม่ได้ถูกต้อง
• การตั้งค่าเครือข่ายแบบ static: การโคลนเครื่องที่มี static IP จะทำให้เกิดความขัดแย้งกับเครื่องต้นฉบับทันทีที่เปิดใช้งาน โปรดอ่าน /etc/netplan/ ก่อนที่จะนำเครื่องที่โคลนมาเชื่อมต่อกับเครือข่าย
• เวลาของระบบ: snapshot ที่ถูกกู้คืนจะเริ่มทำงานด้วยเวลา ณ ขณะที่บันทึก snapshot นั้นไว้ การกระโดดของเวลาอย่างมากบน VPS ที่กู้คืน จะทำให้การตรวจสอบ TLS certificate ล้มเหลวและลำดับของ log ผิดเพี้ยนจนกว่าระบบซิงค์เวลาจะทำงานตามปกติ

ให้ดำเนินการตาม รายการตรวจสอบสิบนาทีแรกสำหรับ VPS ใหม่ บนเครื่องที่โคลนมาด้วยเช่นกัน เนื่องจากเครื่องที่โคลนมาจะได้รับบัญชีผู้ใช้, SSH keys, กฎ firewall และงานที่ตั้งเวลาไว้ (scheduled jobs) ของเครื่องต้นฉบับมาทั้งหมด ซึ่งสิ่งเหล่านี้อาจไม่เหมาะสมกับงานใหม่ที่เครื่องโคลนต้องทำ

FAQ

ฉันจำเป็นต้องรีบูตเครื่องหลังจากแก้ไข /etc/machine-id หรือไม่?

จำเป็น กระบวนการต่างๆ จะอ่านค่า machine ID เพียงครั้งเดียวและเก็บไว้ในแคช ดังนั้นค่าใหม่จะไม่มีผลกับสิ่งที่กำลังทำงานอยู่ journald จะยังคงเขียนข้อมูลลงในไดเรกทอรี journal ที่ตั้งชื่อตาม ID เดิม และ DHCP client จะยังคงส่ง client identifier ที่ได้มาจากค่าเดิม ซึ่งมักเป็นสาเหตุที่คุณต้องเปลี่ยนค่าดังกล่าว การรีสตาร์ทบริการรายตัวอาจแก้ไขปัญหาได้บางส่วน แต่ PID 1 ก็ยังคงถือค่าเดิมอยู่ ให้รีบูตเครื่อง จากนั้นตรวจสอบด้วย cat /etc/machine-id และเปรียบเทียบกับเซิร์ฟเวอร์เครื่องอื่น

/etc/machine-id เหมือนกับ hardware UUID หรือไม่?

ไม่เหมือนกัน DMI product UUID ใน /sys/class/dmi/id/product_uuid มาจาก hypervisor และอ่านได้เฉพาะ root เท่านั้น ส่วน machine ID ถูกสร้างขึ้นโดยระบบปฏิบัติการและอยู่ในไฟล์ธรรมดาที่ผู้ใช้ทุกคนสามารถอ่านได้ ทั้งสองค่าเชื่อมโยงกันในทิศทางเดียวคือ บน KVM guest นั้น systemd-machine-id-setup จะใช้ hypervisor UUID เป็นค่าตั้งต้นสำหรับสร้าง machine ID ใหม่ในกรณีที่ไม่มี D-Bus ID ให้คัดลอก หากโคลนสองเครื่องมี product UUID เดียวกัน ทั้งสองเครื่องจะสร้าง machine ID เดียวกันออกมา ดังนั้นควรตรวจสอบไฟล์ดังกล่าวด้วยก่อนที่จะเชื่อถือผลลัพธ์

ฉันควรลบ /etc/machine-id หรือปล่อยให้ว่างไว้?

ควรปล่อยให้ว่างไว้เมื่อคุณกำลังเตรียม image ระบบ machine-id(5) ต้องการไฟล์ที่ว่างเปล่ามากกว่า เพราะ systemd สามารถทำ bind-mount ไฟล์ชั่วคราวทับลงไปได้เมื่อ image ทำงานในสภาวะที่ /etc เป็นแบบอ่านอย่างเดียว การลบไฟล์สามารถทำได้บนระบบที่เขียนข้อมูลได้และสคริปต์โคลนบางตัวก็ใช้วิธีนั้น แต่การปล่อยไฟล์ให้ว่างไว้เป็นค่าเริ่มต้นที่ปลอดภัยกว่า cloud-init จะเขียนคำว่า uninitialized ลงในไฟล์เพื่อจุดประสงค์เดียวกันนี้

ทำไมเซิร์ฟเวอร์ที่โคลนมาสองเครื่องถึงได้รับ DHCP address เดียวกัน?

เพราะทั้งสองเครื่องส่ง client identifier เดียวกัน systemd-networkd ใช้ค่าเริ่มต้นเป็น ClientIdentifier=duid สำหรับ DHCPv4 และ DUID เริ่มต้นถูกสร้างขึ้นจากแฮชของ /etc/machine-id ดังนั้น machine ID ที่เหมือนกันจะทำให้ได้ identifier ที่เหมือนกันบนเครื่องโคลนที่ใช้ชื่ออินเทอร์เฟซเดียวกันด้วย DHCP server จะจับคู่จาก identifier นั้น โดยมองว่าคำขอทั้งสองมาจากไคลเอนต์เดียวกันและแจก lease ให้เพียงหนึ่งรายการ ให้กำหนด machine ID ใหม่ให้กับแต่ละเครื่องแล้วรีบูตทั้งคู่ หากเซิร์ฟเวอร์ยังคงเสนอที่อยู่เดิม ให้ล้าง lease ที่ค้างอยู่ในตัว DHCP server เอง