ระบบ filesystem ก่อนจะมี Logical Volume Manager (LVM)

ตามที่ได้เขียนไว้ครั้งที่แล้ว ว่าเราจะเกริ่นเรื่อง  Logical Volume Manager (LVM)  กัน แต่พอลองเรียบเรียงแล้ว เพื่อให้เนี้อหาในแต่ละตอนไม่ยาวมาก เลยจะขอตัดเป็นตอนสั้นๆ ก็แล้วกันนะครับ โดยตอนนี้ จะเล่าถึงประวัติศาสตร์ ระบบการใช้งาน disk และ Linux partition ในยุคแรกๆ ก่อนจะมี LVM

บน Linux (และ Unix)  การนำเนื้อที่ของ disk มาใช้งาน เราจะต้องจอง disk เป็นส่วนๆ (partition) แล้ว นำมา format สร้างเป็น filesystem หลังจากนั้นก็นำไป เชื่อมต่อ (mount) กับ directory  โดยการ mount เราต้องกำหนด mount point ด้วยครับ ว่า disk partition นั้น จะ mount ที่จุดไหน

โดยปกติ จะมี disk partition แรก mount  ที่ "/" directory หรือที่เราเรียกว่า root directory ครับ ใน directory นี้ และ directory ย่อยๆ ลงไป ถ้ามีการสร้างไฟล์ ก็จะกินเนื้อที่ของ disk partition นี้

แต่ถ้าเรามี disk อีก partition ที่สอง เพิ่มเข้ามา และ mount อยู่ที่ /usr การสร้างไฟล์ หรือ sub directory ย่อย ภายใต้ /usr จะใช้เนื้อที่ของ partition ที่สองครับ ไม่เกี่ยวข้องกับ partition แรก

disk แต่ละ partition ที่เรานำมา mount เข้ากับ directory tree  ถ้าเราจะดูว่าในเครื่องเรา มี filesystem  อะไรอยู่บ้าง mount อยู่ที่ไหน ก็ใช้คำสั่ง df ดูได้ครับ

การเพิ่มขยาย disk ของ Unix และ Linux ยุคแรกๆ ก็จะใช้วิธีการ mount disk เพิ่มแบบนี้หละครับ

การจอง partition เพื่อจะนำมาสร้างเป็น filesystem แบบนี้ มีข้อจำกัดคือ

1) เนื้อที่ในแต่ละ partition ต้องเป็นเนื้อที่ที่อยู่ติดต่อกัน 
2) ต้องอยู่บน harddisk ลูกเดียวกันเท่านั้น

การขยายเนื้อที่ใน filesystem  จะลำบากมาก ถ้าไม่มีเนื้อที่ติดกันกับ filesystem เดิมเหลืออยู่ ปกติก็คือ

1) ต้องจองเนื้อที่ใน partition ใหม่ ที่ใหญ่กว่าเดิม
2) copy ข้อมูลไป ยัง partition ใหม่
3) unmount filesystem เดิม
4) mount filesystem ใหม่ที่ mount point เดิม

วุ่นวายดีไหมครับ นี่แบบย่อๆ นะที่จริงซับซ้อนกว่านี้อีกนะ

ซึ่งการ unmount filesystem ได้นั้น จะต้องไม่มี process ไหนใช้งาน file หรือ directory บน filesystem นั้น ทำให้ การขยายบาง filesytem ที่ระบบใช้งานตลอด เช่น /usr หรือ /var ทำได้ค่อนข้างยาก ครับ

ถ้าทำได้ ก็จะมีปัญหาอีกอย่างคือ เนื้อที่ filesystem ของเดิมที่เลิกใช้แล้ว จะมีอยู่กระจัดกระจาย ไม่ติดต่อกัน บางที่เนื้อที่ว่างทั้ง disk เหลือพอ แต่อยู่กระจัดกระจาย จะเอามา recycle เพื่อสร้างเป็น filesytem ใหม่ ก็ทำได้แค่ filesystem ขนาดเล็กกว่า partition ที่มีอยู่ หรือเท่าเดิมเท่านั้นครับ

เกริ่นนำ zimbra backup

เรื่องที่กวนใจคนใช้ Zimbra Open Source version อย่างหนึ่งก็คือ ไม่มีระบบ backup มาให้

ที่จริง เราสามารถ backup zimbra ได้หลายแบบ แบบที่ง่ายๆ (ถึกๆ) ก็คือ backup ทั้ง /opt/zimbra (หรือ path ที่เราลง zimbra) ทั้งก้อนเลย เวลาเราจะ restore ก็  restore กลับมาทับทั้งหมด ก็สดวกดี

ข้อดีของวิธีนี้ก็คือ เราได้ตัว zimbra ในส่วนของ binary และรวมไปถึง data ทุกอย่างทั้ง mysql data, openldap data เนื้อเมล์ใน /opt/zimbra/store และ index ใน /opt/zimbra/index  เรียกว่าครบทุกอย่างเลย

แต่อย่างไรก็ตาม การ backup /opt/zimbra มีข้อควรระวังก็คือในระหว่างการ backup ต้องมีการ stop zimbra เสียก่อน ตามคำแนะนำของ zimbra open source ครับ (ส่วนเรื่องทำไมต้อง backup ระหว่างที่ zimbra หยุดทำงาน ผมจะเขียนถึงที่หลังละกัน) ปัญหาก็คือ ถ้า data ของ zimbra มีจำนวนมาก เวลาในการ backup จะใช้เวลานาน ซึ่งหมายถึง zimbra จะต้องหยุดทำงานเป็นเวลานานไปด้วย ซึ่งไม่ค่อยดีเท่าไหร่ ใช่ไหมครับ

จุดนี้ไม่ใช่ปัญหาใหญ่ เราสามารถดัดแปลงสิ่งที่ Linux มีมาให้อยู่แล้ว ใช้ในการ backup zimbra ได้ครับ โดยใช้ สิ่งที่เรียกว่า snapshot ของ Logical Volume Manager (LVM) ครับ โดยวิธีนี้  เราต้องสร้าง filesystem /opt/zimbra  ให้อยู่บน partition ที่เป็น Logical Volume(LV) แทนที่จะเป็น partition ที่สร้างจากการแบ่งเนื้อที่บน hardisk ตรงๆ  ซึ่งผมเคยแนะนำใน Zimbra Tips & Technique ตอนต้นๆ แล้วนะครับ แต่ผมขอสรุปอีกที สำหรับหลายๆท่านที่เพิ่งกด like  Thai Zimbra fan page ครับ

เหตุผลที่เราต้องทำแบบนี้ ก็เพราะ เราสามารถที่จะสร้าง copy ที่เสมือนถูก "หยุดเวลา" ไว้ ของ filesystem ที่ถูกสร้างอยู่บน LV ได้ เราเรียกสิ่งนี้หรือการทำแบบนี้ว่า snapshot โดยตัว filesystem ที่เป็นต้นแบบจะสามารถถูกใช้งานต่อ (มีการเปลี่ยนแปลงแก้ไขข้อมูล) ส่วน snapshot จะยังคงมีข้อมูลค้าง ณ.เวลาที่เราสร้าง snapshot นั้นไว้

พอเห็นภาพแล้วใช่ไหมครับ พอเราสามารถ สร้าง copy ที่ถูก "หยุดเวลา" ของ /opt/zimbra ได้ เราจะเสียเวลาในการ stop zimbra อยู่แค่ช่วงที่เราสร้าง snapshot filesystem ของ /opt/zimbra (ซึ่งกินเวลาแป็บเดียว) หลังจากนั้น เราสามารถ start zimbra ขึ้นมาทำงานต่อได้ ส่วนการ backup เราก็ทำในขณะที่ zimbra ทำงานอยู่ได้ โดย backup ข้อมูลจาก snapshot แทน

ตัว snapshot filesystem เอง ก็เสมือนเป็น filesystem ปกติธรรมดา ครับ ต้องมีการ mount ไปยัง directory ในระบบ จึงจะสามารถถูกใช้งานได้ เพียงแต่เราจะอ่านข้อมูลได้อย่างเดียว เปลียนแปลงแก้ไขข้อมูลไม่ได้

ปกติตัว snapshot จะไม่กินเนื้อที่ disk มาก ยกเว้นในกรณีที่ตัว disk ต้นแบบมีข้อมูลเปลี่ยนแปลงไปหลังจากที่มีการทำ snapshot ซึ่งตรงนี้ จะทำให้ snapshot กินเนื้อที่บน disk ครับ ดังนั้น ยิ่งปล่อยให้ snapshot filesystem อยู่ในระบบนาน ก็จะยิ่งกินเนื่อที่ disk ไปเรื่อยๆ แต่พอเราลบ snapshot LV ทิ้ง เนื้อที่ที่ใช้ไป ก็จะถูกคืนกลับสู่ LVM ครับ

บางระบบอาจมีการสร้าง filesystem  ที่ /opt/zimbra อยู่ มาจาก disk ที่อยู่บน NAS หรือ SAN ซึ่งพวกนี้ส่วนใหญ่ก็สามารถทำ snapshot ได้นะครับ ไม่ต้องใช้ความสามารถของ LVM  เลย

ครั้งต่อไป ผมจะพูดถึงทฤษฏีเบื้องต้นของ Logical Volume Manager เพื่อปูพื้นฐาน ก่อนจะพูดถึงเรื่องการทำ snapshot ในตอนต่อๆไป ครับ

Advance Import/Export Account (Tips and Technique #13)

Advance Import/Export Account (Tips and Technique #13)

ครั้งที่แล้ว ผมได้พุดถึงการ import/export ข้อมูลของ account ไปบ้างแล้วว่า ว่า user ของ zimbra สามารถ backup หรือ export ข้อมูลมาเก็บไว้ได้ จาก Preference -> import/export ครั้งนี้เรามา...ดูกันต่อครับ

ถ้าเลือก export และ เลือก Type เป็น account จะเห็นว่า มี check box ที่ชื่อ Advanced Settings ถ้าเราติ๊กถูกที่ช่องนี้ zimbra จะแสดงตัวเลือกเพิ่มเติมในการ export ครับ

 

เราสามารถเลือก

1. ชนิดของ data type ได้ ว่าจะเป็น Mail ,Addressbook, Calendar Task หรือ Briefcase
2. ช่วงเวลาของ ข้อมูลที่จะถูก export
3. สามารถใช้ filter เพื่อเลือกข้อมูลได้
4.เลือกว่าจะ export เฉพาะข้อมูล หรือเอา Metadata จะเลือกอันนี้ เฉพาะในกรณีที่จะ import ข้อมูลนี้เข้า zimbra เท่านั้นนะครับ

จะเห็นว่าการใช้ export advance setting นี้ทำให้เรา สามารถเลือกข้อมูลที่จะ export ไว้ได้ตรงตามที่เราต้องการมากขึ้นครับ

Zimbra Tip and Technique #10 : Failed Login Policy

อาทิตย์ก่อน ผมได้พูดถึงเรื่องการ hack email account ซึ่ง zimbra สามารถป้องกัน หรือ ทำให้โอกาสเกิดขึ้นได้น้อยลงมาก โดยการกำหนด password policy
อีกสิ่งหนึ่งที่ทำได้ คือการกำหนด Failed login policy ซึ่งเป็นการกำหนดพฤติกรรมให้กับ zimbra ว่า ถ้า user คนหนึ่งมีการ login ผิด ว่าระบบจะใช้อะไรตัดสิน และจะทำอย่างไรกับ account ที่ login ผิด

ซึ่งมีค่าที่เซตได้ดังนี้

Enable failed login lockout : เป็นการ enable feature ว่า ถ้ามีการ login ผิดตามรายละเอียดที่ set ไว้ ระบบจะทำการ lock user ไม่ให้ login ได้

Number of consecutive failed login allowed : เป็นค่าจำนวนครั้งที่อนุญาติให้ user มีการ login ผิด ติดต่อกัน

Time window in which failed login must occure to lock the account : เป็นการระบุว่า การ login ผิดติดต่อกัน ตามค่าที่กำหนด ต้องเกิดขึ้นภายในระยะเวลาเท่าไหร่ ระบบถึงจะ lock account นั้นๆ

Time to lockout the account : เวลาที่ระบบจะ lock user ไม่ให้ login ถ้ามีการ login ผิดติดต่อกัน ตาม จำนวนครั้ง และภายในเวลาที่กำหนด


วิธีนี้สามารถแก้ปัญหาที่ hacker รู้ account และพยายาม เดา password ได้ในระดังหนึ่ง คือเดาได้แค่เท่ากับจำนวนครั้งที่เรากำหนดไว้ หลังจากนั้น ถึงแม้เดาถูก แต่ account ถูก lock ก็ login ไม่ได้

และในขณะเดียวกัน จะทำให้ zimbra admin ทราบได้ว่ามีคนพยายามจะ hack account โดยสังเกตุได้จากมี user หลายๆ คน ถูก lock account เนี่องจาก failed login ด้วยครับ