นโยบายการจัดการความรู้ มหาวิทยาลัยสงขลานครินทร์ 1.ให้ใช้เครื่องมือการจัดการความรู้ผลักดัน คุณภาพคน และกระบวนทำงาน 2.ส่งเสริมการแลกเปลี่ยนประสบการณ์การทำงาน จากหน้างาน 3.ส่งเสริมให้มีเวทีเรียนรู้ร่วมกัน
อ่าน: 1709
ความเห็น: 0

อัพเกรด package บน server หลายๆเครื่องโดยใช้ 2 scripts

Upgrade packages on multiple debian servers in two scripts

จากบันทึกที่แล้ว ซึ่งเป็นเรื่องของการตรวจสอบว่าในกลุ่มของ server ที่ดูแลอยู่มีตัวใหนบ้าง ที่มี package ที่ต้องการ update

หลักการโดยคร่าวๆของการ update package บน server ทีผมเลือกใช้อยู่ก็คือ ถ้าการ update/upgrade package ครั้งนั้นๆ  เป็นการ update เนื่องจากปัญหา security  ก็ควรที่จะ update โดยด่วน

ถ้าเป็นการ upgrade ธรรมดาที่ไม่เกี่ยวข้องกับ security  ถ้าไม่ส่งผลกระทบต่อการใช้งาน ก็ควรที่จะ update ซะเมื่อมีเวลา -- สำหรับกรณีนี้ในความหมายที่ว่า ถึงแม้การสั่ง upgrade package บน server หลายๆเครื่องๆนั้น ผมสามารถที่จะสั่งโดยการพิมพ์คำสั่งเดียวได้ แล้วกระบวนการ upgrade สามารถที่จะเกิดขึ้นพร้อมๆกัน(หรือขนานกันไป) บนเครื่อง server ทุกเครื่อง จนเสร็จสิ้น(ถ้าไม่มีปัญหาใด) โดยที่ผมไม่จำเป็นจะต้องคอยดูจนเสร็จ ผมก็ยังเลือกที่จะใช้วิธีการ สั่ง (ผ่าน script) ให้ update/upgrade ทีละเครื่อง  โดยที่ระหว่างนั้น ผมก็นั่งทำงานอื่นๆไปด้วย (ส่านใหญ่จะเป็นการอ่าน e-mail ซึ่ง logcheck ที่ทำงานอยู่บน server ทุกเครื่องส่งมาให้เป็นระยะๆ) และคอยเหลือบตามาดู terminal ที่ใช้ run upgrade script เรื่อย เพื่อดูว่าการ upgrade เป็นไปได้ดีโดยไม่มีปัญหา

ซึ่งเวลาโดยรวมของการ update/upgrade ของ server ทั้งหมดก็จะขึ้นอยู่กะบ จำนวนเครื่องที่ต้อง update/upgrade และ จำนวน package ที่ต้อง update/upgrade เหล่านั้น ซึ่งเวลาอาจจะอยู่ในช่วงของ  1-2 นาทีในวันปกติธรรมดา ที่มี package 1-2 package อยู่บน 3-4 เครื่อง ซึ่งสัปดาห์นึงอาจจะเกิดขึ้น 2-3 ครั้ง ไปจนถึง จำนวน 100-200 กว่า pakcage บนเกือบทุกเครื่อง ซึ่งเกิดขึ้นตอนที่มีการปรับเปลี่ยน stable distribution หนึ่งไปเป็นอีก distribution หนึ่ง -- ในครั้งที่แล้วเป็นการเปลี่ยน stable distribution จาก sarge เป็น etch และคงจะเกิดขึ้นอีกอีกครั้งในตอนที่เปลี่ยนเป็น lenny ภายในไม่กี่สัปดาห์หน้า -- ลักษณะนี้จะเกิดขึ้นประมาณ 2 ปีครั้ง  ซึ่งจะถือว่าเป็นงานใหญ่ ที่จะต้องแบ่งเวลามาตรวจสอบการ upgrade อย่างใกล้ชิดแต่ละเครื่อง และทำแบบ manual

แต่สำหรับการ upgrade แบบทั่วไปจะใช้เวลาในช่วง 5-15 นาทีซึ่งจะทำในช่วงที่แน่ใจว่า ไม่มีงานอื่นมาคั่นกลางคัน

โดยทั่วไปจะไม่มีปัญหาอะไร อาจจะมีคำถามที่ต้องการการยืนยันว่า ให้ใช้ configuration ไฟล์เดิมที่มีอยู่แล้ว หรือมี ข้อความบอกว่าควรที่จะ reboot เครื่องใหม่ เพราะ kernel package ใหม่ที่ upgrade ไปเป็นเวอร์ชันเดียวกับที่กำลังใช้งานอยู่ เพราะฉะนั้นถ้ามีการ load kernel module เพิ่มเข้าไปในภายหลัง อาจจะมีปัญหา

แต่หลายปีที่แล้ว ผมเคย upgrade ตัว dhcp server แล้ว config file เดิมที่ setup เอาไว้ถูกเขียนทับโดยไฟล์จาก package ซึ่งมี address ไม่ถูกต้อง ครั้งนั้นเป็นการ upgrade แบบอัตโนมัติ ทำให้กว่าจะทราบว่ามีปัญหาก็เวลาผ่านไปหลาย ชม. ในระหว่างนั้นเครื่องคอมพิวเตอร์ทีใช้ dhcp กำหนด address ก็ไม่สามารถใช้งานได้

กลับมาดูวิธีการที่ผมใช้ในการ update package บน server กันต่อ 

เนื่องจากข้อมูลที่จะใช้สำหรับบอกว่ามี server เครื่องใหนบ้างที่ต้องการการ update package จะถูกส่งมาผ่านทาง e-mail และ e-mail นี้จะเก็บอยู่บน mailserver/fileserver ของภาควิชาฯ ในขณะเครื่องคอมพิวเตอร์ที่ผมใช้ทำงานเป็นหลักจะเป็น desktop เพราะฉะนั้น script ที่ใช้ในการ update package บน server จะแบ่งเป็น 2 ส่วน ส่วนแรกอยู่บนเครื่อง mail server เพื่อลดภาระในการส่งข้อมูลผ่าน network

script ตัวแรกชื่อว่า getupdateinneed

#!/bin/sh

MBOX="/home/cj/mail/mbox"
DATE=$(date +%Y%m%d)
YESTERDAY=$(date --date=yesterday +%Y%m%d)

grep "^Subject: " $MBOX            |\
grep pkgupdate                            |\
egrep "$DATE|$YESTERDAY"     |\
grep -v '(0,0,0,0)'                          |\
cut -f3 -d' '                                    |\
sort -u                                           |\
cut -f1 -d'.'                                    |\
while read name; do echo -n "$name "; done; echo
 

MBOX จะเป็นตัวแปร shell ที่ระบุชื่อไฟล์เก็บ mail ซึ่งผ่านจากการ filter  โดยใช้ procmail แล้ว และเก็บอยู่ที่นั่น ถ้าเป็น mail โดยทั่วไปที่เก็บแบบ mailbox จะอยู่ใน /var/spool/mail หรือ /var/mail เพราะฉะนั้นตัว MBOX สำหรับผู้ใช้โดยทั่วไปก็อาจจะเป็น

MBOX=/var/mail/$USER

 ใน script ข้างต้น ผมตรวจสอบวันที่ส่ง mail มาทั้งวันปัจจุบัน DATE=$(date +%Y%m%d) และ เมื่อวาน YESTERDAY=$(date -d yesterday +%Y%m%d) เพราะ server ที่ดูแลอยู่มีบางตัวที่ กำหนดเวลาของการตรวจสอบ update package ต่างจากเครื่องอื่นๆ เพราะฉะนั้นจะต้องตรวจสอบทั้ง 2 วันแทนที่จะเป็น 'วันนี้' เพียงวันเดียว

สิ่งที่จะได้จาก script ตัวนี้ก็คือ list ของรายชื่อ server ที่ต้องการการ update package ส่วน server ตัวใหนที่ไม่จำเป็น ต้อง update ก็จะถูกตัดทิ้งไป

ใน script สำหรับการตรวจสอบในบันทึกก่อนหน้านี้ ผมเลือกที่จะให้ทุกเครื่อง ส่ง mail มาถึงแม้ว่าจะไม่มี package ที่ต้องการการ upgrade ก็เพื่อเป็นการตรวจสอบเพิ่มขึ้นอีกทางหนึ่ง (นอกเหนือจากการตรวจสอบอื่นๆที่มีอยู่แล้ว เช่น nagios)  ว่า server เครื่องนั้นๆยังทำงานเป็นปกติอยู่ ซึ่งสามารถตรวจสอบดูได้คร่าวๆจาก e-mail  ที่ส่งมาว่า มาครบจากทุกๆเครื่องหรือเปล่า

เพราะฉะนั้นใน script getupdateinneed ก็จะตัด serverที่ไม่จำเป็นทิ้งออกไป เหลือเฉพาะ list ของ server ที่ต้องการการ upgrad

ซึ่งจะส่งให้กับ script ตัวที่ 2 ชื่อว่า server-package-upgrade ซึ่งอยู่บนตัว desktop

 #!/bin/bash

MAILSVR="fivedots"
SVRLIST=$(ssh $MAILSVR bin/getupdateinneed)
LIST1=""
LIST2=""
for name in $SVRLIST; do
    case $name in
    th|us|uk|dwm)
        LIST2="$LIST2 $name"
    ;;
    *)
        LIST1="$LIST1 $name"
    ;;    
    esac
done

echo "LIST1 : $LIST1"
echo "LIST2 : $LIST2"

echo "Start upgrading LIST1 : $LIST1"
[ "$LIST1" ] && \
for svr in ${LIST1}; do
    echo "===== Update $svr ====="
    ssh -t $svr sudo apt-get -y upgrade
done

echo "Start upgrading LIST2 : $LIST2"
[ "$LIST2" ] && \
echo "LIST2 : $LIST2"
for svr in ${LIST2}; do
    echo "===== Update $svr ====="
    ssh -t $svr sudo apt-get -y upgrade
done


Script ตัวนี้จะไปเรียก script getupdateinneed บนตัว mailserver ซึ่งจะได้ list ของ server ที่ต้องการการ update package ออกมา

ในที่นี้ผมเอามาแยกเป็น 2 กลุ่ม คือ กลุ่ม server ภายในภาควิชาฯ คือทั้งหมด ยกเว้น th,us,uk และ dwm และ กลุ่มภายนอก คือทั้ง 4 ตัวที่ยกเว้นไปนี้  และจะเริ่มจากการ upgrade ตัว server ในกลุ่มแรกก่อน เพราะตัดปัญหาในกรณีระบบเครือข่ายมีปัญหา

บน server ทั้งหมด ผมได้ setup sudo และ secure public key เอาไว้แล้วทำให้การ secure shell เข้าไป run คำสั่ง sudo ทำได้โดยไม่ต้องใส่ password

วิธีการจัดการเรือง secure shell public key  ผมได้เขียนไว้แล้วในบันทึก etherwake ethersleep  และส่วนเรื่องของคำสั่ง sudo ก็อยู่ในบันทึก remote shutdown เครื่องโดยไม่ต้องใช้ root account (ซึ่งตอบไม่ตรงคำถาม แต่ก็คงมีเนื้อหาอยู่บ้าง)

ส่วนบันทึกนี้ คงพอแค่นี้ก่อนครับ 

Sections: Miscellaneous
License: สงวนสิทธิ์ทุกประการ Copyright
created: 29 December 2008 13:05 Modified: 21 June 2009 14:39 [ Report Abuse ]
ดอกไม้
People Who Like This
 
Facebook
Twitter
Google

Other Posts By This Blogger

ความเห็น

ไม่มีความเห็น

ร่วมแสดงความเห็นในหน้านี้

ชื่อ:
อีเมล:
IP แอดเดรส: 18.210.24.208
ข้อความ:  
เรียกเครื่องมือจัดการข้อความ
   
ยกเลิก หรือ