เขียนสคริปต์บน Windows ไปรันบน Linux — สองกับดักที่ทำไฟล์ค้างเซิร์ฟเวอร์
เครื่องที่เปิด path เป็นคนตัดสินว่าจะใช้ syntax แบบไหน — สคริปต์ที่รันบน Linux ต้องพูดภาษา POSIX ล้วน ไม่ใช่ปน backslash ของ Windows เข้าไป ฟังดูเล็กแต่พลาดทีเจอไฟล์ผีใน /tmp จนต้องตามลบ
สรุปใน 1 นาที
- อาการ/ปัญหา
- สคริปต์เขียนบน Windows แล้ว scp ไปรันบน Linux ทิ้งไฟล์ประหลาดใน /tmp และไฟล์ token ค้างบนเซิร์ฟเวอร์
- ใครควรอ่าน
- คนที่เขียน helper script บน Windows เพื่อรันบน Linux
- ทางแก้แบบสั้น
- ใช้ path แบบ POSIX ล้วน ไม่ฝัง path แบบ d:\ และลบไฟล์ token กับ payload ทิ้งหลังใช้เสมอ
พอดีผมทำงานแบบ "เขียนสคริปต์บนเครื่อง Windows แล้ว scp ขึ้นไปรันบนเซิร์ฟเวอร์ Linux" อยู่บ่อยมาก — ตัว generate report บ้าง ตัวดึงข้อมูลบ้าง ทำเป็น Python/PHP/Bash แล้วยิงขึ้นไปรัน เสร็จก็ลบ ดูเหมือนงานง่าย แต่มีสองอย่างที่กัดผมซ้ำ ๆ จนต้องตั้งเป็นกฎประจำตัว เลยเอามาเล่าไว้เผื่อคนทำแนวเดียวกัน
กับดักที่ 1: path แบบ Windows ฝังในสคริปต์ที่รันบน Linux
บน Linux เครื่องหมาย \ เป็นตัวอักษรปกติที่ใช้ตั้งชื่อไฟล์ได้ ไม่ใช่ตัวคั่นโฟลเดอร์เหมือน Windows พอผมเผลอฝัง path แบบ d:\data\out.json ลงในสคริปต์แล้วมันไปรันบน Linux ผลคือมันสร้างไฟล์ชื่อ D:\data\out.json (ทั้งก้อนเป็นชื่อไฟล์เดียว) โผล่มาใน /tmp
ไฟล์ชื่อประหลาดแบบนี้ไปเข้าเงื่อนไข "ชื่อไฟล์น่าสงสัย" ของ file-integrity monitor บนเซิร์ฟเวอร์ แล้วเด้ง alert ขึ้นมา — เสียเวลาไล่ว่าโดนแฮกไหม ทั้งที่เป็นแค่ backslash หลงเข้าไป
กฎที่ผมยึด: เครื่องที่เปิด path เป็นคนกำหนด syntax ของ path สคริปต์ที่จะรันบนเซิร์ฟเวอร์ต้องใช้ path แบบ Linux ล้วน (/tmp/out.json, /home/user/...) เท่านั้น ไม่มี drive letter ไม่มี backslash
กันพลาดด้วย pre-upload check
อย่าพึ่งความจำ ก่อน scp ทุกครั้งให้ grep หา drive-letter path แล้วปฏิเสธถ้าเจอ:
# ก่อน upload — เจอ path แบบ Windows = ไม่ส่ง
if grep -nE '[A-Za-z]:\\|[A-Za-z]:/' deploy.sh; then
echo "REFUSE: พบ Windows path ในสคริปต์ที่จะรันบน Linux"
exit 1
fi
ใส่บรรทัดนี้ไว้หัวสคริปต์ deploy ก็กันได้ตั้งแต่ต้นทาง
กับดักที่ 2: ลืมลบไฟล์ชั่วคราวบนเซิร์ฟเวอร์
งานแบบนี้มักสร้างไฟล์ระหว่างทาง — payload, ไฟล์ .token ที่มีความลับ, ตัว helper script เอง พอทำเสร็จแล้วลืมลบ มันค้างอยู่บนเซิร์ฟเวอร์ ซึ่งแย่สองต่อ: รกและเป็นความเสี่ยงด้านความปลอดภัย (โดยเฉพาะไฟล์ที่มี token/รหัส)
อย่าแยก step ลบไปไว้ทีหลัง เพราะถ้าสคริปต์ตายกลางทาง step ลบจะไม่ทำงาน — รวบ upload -> run -> ลบ ไว้ในคำสั่ง ssh ชุดเดียว แล้วปิดท้ายด้วย ls /tmp ยืนยันว่าสะอาดจริง
scp payload.json runner.sh user@host:/tmp/
ssh user@host 'set -e
cd /tmp
bash runner.sh payload.json > /tmp/run.log 2>&1
rm -f /tmp/payload.json /tmp/runner.sh /tmp/*.token
echo "--- เหลืออะไรใน /tmp บ้าง:"; ls -la /tmp | grep -E "payload|runner|token" || echo clean'
สรุปเป็นกฎประจำตัว
- สคริปต์ที่รันบนเซิร์ฟเวอร์ ใช้ path แบบ Linux ล้วน ห้ามมี drive-letter/backslash
- ก่อน upload grep หา Windows path แล้วปฏิเสธถ้าเจอ
- ไฟล์ token/payload/helper ลบใน ssh chain เดียวกับที่รัน อย่าแยก step
- ปิดท้ายด้วย ls ยืนยันว่าไม่เหลือของค้าง
สองข้อนี้ดูจิ๊บจ๊อยแต่เป็นเรื่องที่ทำให้ผมเสียเวลาไล่ของจริงมาแล้ว โดยเฉพาะไฟล์ผีใน /tmp ที่พาไปสงสัยว่าโดนบุกรุก ทั้งที่เป็นแค่ backslash หลงทาง ใครทำงานข้ามแพลตฟอร์ม Windows→Linux ประจำ ตั้งสองกฎนี้ไว้ตั้งแต่แรกจะสบายกว่ามาตามแก้ทีหลังครับ ตรงไหนผมอธิบายตกหล่นหรือพิมพ์ผิด เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai



ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย