Linux (OS, shell script, etc) – Page 31

Recovering Files From ecryptfs Encrypted Home

April 10, 2013 23:16

ผมเจอปัญหาว่ามีเครื่องเสีย ผมต้องเข้าไปช่วยกู้ข้อมูลในดิสก์ที่เสีย แต่ก็พบว่า home directory ได้ทำ encrypt ไว้ในตอนติดตั้ง ubuntu 10.04 desktop ผมจึงค้นหาดูพบหลายบทความ แต่มาลงตัวที่บทความนี้ http://www.kaijanmaki.net/2009/10/26/recovering-files-from-ecryptfs-encrypted-home/ เป็นจุดเริ่มต้นให้ลองทำตามดู ผมทำ Virtual Machine เป็น guest ใน Oracle VM VirtualBox โดยติดตั้ง ubuntu 10.04 desktop (จะลองกับ 12.04 หรืออื่นๆก็คงได้) แล้วลองสร้างไฟล์ test.txt, test2.txt จากนั้น shutdown เครื่อง guest แล้วบูตอีกทีด้วยไฟล์ ubuntu-10.04.4-desktop-i386.iso แล้วเลือก Try ubuntu เมื่อเข้าถึงหน้ากราฟิกแล้ว คลิกเมนู places, เลือก disk ที่ต้องการ จากนั้นเปิด terminal เพื่อออกไปทำงานในโหมด command line ใช้คำสั่ง df ดูจะเห็นว่าดิสก์ถูก mount เป็นชื่อ ดังนี้ /dev/sda1 /media/c460e698-ae7a-478e-a9fa-7ea4beb4f7c6 ให้เข้าทำงานเป็น root ubuntu@ubuntu:~$ sudo su ลองตรวจสอบดูว่ามีอะไรอยู่ข้างในบ้างด้วยคำสั่งข้างล่างนี้ root@ubuntu:~# ls -l /media/c460e698-ae7a-478e-a9fa-7ea4beb4f7c6/home/mama/ total 0 lrwxrwxrwx 1 1000 1000 56 2013-04-10 08:52 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop lrwxrwxrwx 1 1000 1000 52 2013-04-10 08:52 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt ตรวจสอบดูว่าไฟล์ต่างๆ น่าจะซ่อนอยู่ที่ไหนก็พบว่าอยู่ที่นี่ root@ubuntu:~# ls -l /media/c460e698-ae7a-478e-a9fa-7ea4beb4f7c6/home/.ecryptfs/mama/.Private/ total 276 -rw-r–r– 1 1000 1000 12288 2013-04-10 09:10 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC1PAe3rM36mt8nRtyRWtxlE– drwxr-xr-x 4 1000 1000 4096 2013-04-10 09:06 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC2Yj-dqfvpHuYFJe32oPmP— drwx—— 4 1000 1000 4096 2013-04-10 09:05 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC3kM22hNF7litgpIAwtmwtU– drwx—— 2 1000 1000 4096 2013-04-10 09:11 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC7W8YJQSLe20t0XJHf6xjB— -rw-r–r– 1 1000 1000 12288 2013-04-10 08:52 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC9cPIgv52y7AFWY.H1WCtTE– -rw——- 1 1000 1000 12288 2013-04-10 09:05 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC9dcmZbWv.pjpzikXKTE2xU– lrwxrwxrwx 1 1000 1000 104 2013-04-10 08:52 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmC9u1V-uJOrNxm7ZdoXYvX5E– -> ECRYPTFS_FNEK_ENCRYPTED.FXaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCGOuByR46pE4zxC1IyPOC1XMuz8uG9d.Y91Nys0NXy1o- drwx—— 2 1000 1000 4096 2013-04-10 09:06 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCBinhrU4ijNIOXaDLIUmz6— drwxr-xr-x 6 1000 1000 4096 2013-04-10 09:08 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCbQymH7oV5njbGxrao6qK.E– drwx—— 2 1000 1000 4096 2013-04-10 09:11 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCcib.jfkdAKRfPUX3SRC3PE– drwx—— 2 1000 1000 4096 2013-04-10 09:05 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCd8fDbrGkyQn76SLx7OFbWk– drwxr-xr-x 2 1000 1000 4096 2013-04-10 09:05 ECRYPTFS_FNEK_ENCRYPTED.FWaiRtz3Ag4mTURWaW1nT.6mYpw-PkyvsXmCf9KXChgI4vRxtQINyM5f2U–

แนวทางการ Backup บน Ubuntu Server (กรณีระบบ PSU EMail)

April 10, 2013 06:40

เนื่องจากจะจัดทำระบบ Backup and Recovery ระบบ Mail ซึ่งทำงานอยู่บน Ubuntu จึงทำการรบรวมข้อมูล และหาแนวทางที่เหมาะสม ก่อนจะตัดสินใจเลือก แผนการ Backup ที่เหมาะสม ก็ควรพิจารณาเรื่องต่อไปนี้ด้วย [1] 1. WHY: จุดประสงค์การ Backup/Restore, ถ้าข้อมูลสูญหายจริงๆจะเกิดความเสียหายขนาดไหน ? 2. WHAT: สิ่งที่จะทำการ Backup, ทั้ง Hard Drive? หรือเป็นข้อมูลบางส่วน? 3. WHEN: เวลาที่ดีที่สุดที่จะ Backup, บ่อยขนาดไหน, จะทำการ Full/Incremental Backup เมื่อใดบ้าง ? 4. WHERE: เก็บ Backup ไว้ที่ใด, ในเครื่องนั้นๆ, เก็บไว้ภายนอก หรือใช้บริการ Cloud Storage 5. MEDIUM: สื่อที่ใช้จัดเก็บ, USB Stick, External HDD, Tape หรือ Backup Server ประเภทของการ Backup [1] 1. Full: สำรองทุกสิ่งอย่าง 2. Incremental: สำรองเฉพาะสิ่งที่เพิ่มขึ้นมา นับจากการสำรองครั้งล่าสุด 3. Differential: เหมือนกับ Incremental แต่เก็บเฉพาะไฟล์ที่ยังไม่ปรับค่า Archive bit (ในกรณี Windows Filesystem) วิธีการ Backup : จากการสำรวจ พบว่าบน Ubuntu มีเครื่องมือ และวิธีการให้ใช้มากมาย เช่น SimpleBackupSuite, grsync, pybackpack หรือที่ติดมาพร้อมกับ Ubuntu Desktop อย่าง Déjà Dup [1] แต่เครื่องมือเหล่านี้เหมาะสำหรับการใช้งานแบบ Desktop Computer มากกว่า แต่ในระบบ Mail Server ซึ่งมีปริมาณข้อมูลจำนวนมาก และเป็นของผู้ใช้จำนวนมาก (ในระบบมีผู้ใช้รวม 6000 คน) จึงควรต้องมีการทำงานที่ยืดหยุ่นกว่า และสามารถปรับแต่งตามต้องการได้ จึงพิจารณาใช้ tar เพื่อทำการ Full [2] และ Incremental Backup [3] แล้วจึงใช้ rsync ส่งไฟล์ไปเก็บไว้ที่ Backup Server ต่อไป ในกรณี PSU Email มีลักษณะดังนี้ 1. เก็บ email แต่ละฉบับเป็นแบบไฟล์ ไฟล์ขนาดเล็กๆ 2. ไม่มีการเขียนทับไฟล์เดิม (เว้นแต่ Index ของ Mailbox ซึ่งไม่จำเป็นนัก เพราะ ต้อง rebuild ใหม่เมื่อทำการ restore) 3. เมื่อมี email ใหม่เข้ามา จะทำการสร้างไฟล์ใหม่ โดยแต่ละไฟล์จะเป็นตัวเลข เพิ่มขึ้นเรื่อยๆ ไม่ซ้ำเดิมแน่นอน 4. เมื่อผู้ใช้สามารถ สร้าง และ rename ชื่อ directory ได้ พิจารณาคำถามข้างต้น แล้วให้ตำตอบ WHY: เพื่อสำรอง email ไว้ให้ ในกรณีฉุกเฉินที่ผู้ใช้ลบ email ไปโดยไม่ตั้งใจ WHAT: email อยู่บน disk แยกออกไป, ทำการสำรองเฉพาะไฟล์ใน directory จัดเก็บ ซึ่งใช้เนื้อที่รวม 600 GB ซึ่งเป็นของผู้ใช้ในระบบ 6,000 คน, ข้อมูลมีลักษณะเป็นไฟล์ขนาดเล็กจำนวนมาก และมีการเพิ่มและลดจำนวน แต่ไม่มีการแก้ไขไฟล์, มีการเพิ่ม/ลบ/เปลี่ยนชื่อ directory WHEN: จากสถิติการใช้งาน พบว่า ผู้ใช้ใช้งานน้อยที่สุดหลังเวลา 03:00 ของทุกวัน

InnoDB Storage Engine Data Recovery สำหรับ MySQL database

March 31, 2013 01:44

ปัญหาของการลืม password ของ root ของ MySQL ไม่ได้เป็นปัญหาเดียวที่ผมเจอ ในเรื่องของการใช้งาน MySQL Database Server ถึงแม้จะไม่บ่อยนัก แต่ก็บ่อยมากพอที่จะทำให้ ใน 2-3 ครั้งให้หลัง ผม “จำ” วิธีการแก้ปัญหาได้ โดยไม่ต้องพึ่งพา google อีกต่อไป ถ้าจะว่าไป ถ้าปัญหานี้ เกิดขึ้น “บ่อย” กว่าเดิมอีกซักหน่อย ผมก็คง “จำ” root password ได้ (เพราะต้องใช้บ่อยขึ้น) และส่งผลในทางกลับ ทำให้ ไม่ลืม root password และทำให้ปัญหานี้ไม่ใช่ปัญหาอีกต่อไป — ฟังดูย้อนแย้ง ชวนขยักขย่อน หรือเปล่าครับ 🙂 แต่ไม่ว่าอย่างไร … การลืม password ในระดับสร้างความหงุดหงิดรำคาญใจแค่นั้นเอง ความรู้สึกอย่างมากก็คือ “ลืมอีกแล้ว ต้องรีเซ็ทพาสเวิร์ดอีกรอบ งี่เง่าจริงๆ!” แต่มีปัญหาอีกอย่างที่ … ไม่ได้เกิดขึ้นบ่อย … นานๆเกิดที แต่พอเกิดขึ้นมาแล้ว ทำให้ระดับความเครียดของ sysadmin พุ่งขึ้นสูงอย่างฉับพลัน ปัญหาแบบที่ว่า เกิดขึ้น ในลักษณะนี้ ครับ นี่คือข้อความทีี่มีอยู่ในไฟล์ “/var/log/mysql/error.log” InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer… InnoDB: Doing recovery: scanned up to log sequence number 7 3581528990 InnoDB: Error: page 4 log sequence number 7 3581552218 InnoDB: is in the future! Current system log sequence number 7 3581528990. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: for more information. ก่อนที่จะมาถึงที่จุดนี้ อาการของตัว mysql server ก็คือว่า load ของ mysqld ตัว daemon ทำงานอยู่แกว่งอยู่ในช่วง 90-100% อยู่ตลอดเวลา หลังจาก boot เครื่องขึ้นมา และถึงแม้จะไม่มีการใช้งาน mysql server จาก process อื่นๆเลย (ผมทดสอบโดยการ shutdown ตัว web server ซึ่งเป็น client เพียงตัวเดียวที่ใช้งาน mysql server อยู่) ก็ไม่ได้ทำให้ load ของตัว mysqld ลดลง หลังจากลองตรวจสอบจาก system log ของระบบ

Solved Firefox browser with adobe flash player outdated

March 30, 2013 14:56

ผมรัน Firefox browser แล้วพบว่ามันจะแจ้งว่า Adobe Flash Player Plugin ไม่ปลอดภัยเนื่องจาก Outdated จึงคลิกเข้าไปในหน้า Addons แล้ว ดาวน์โหลดจากเว็บ http://get.adobe.com/flashplayer/ ได้ไฟล์ install_flash_player_11_linux.x86_64.tar.gz จากนั้นแตกไฟล์ออกมาอย่างง่ายๆ เพราะใช้ GUI อยู่ ได้ไฟล์มาดังนี้ libflashplayer.so และไดเรกทอรี usr แล้วเปิดอ่าน readme.txt สั่งว่าให้อัปเดตแบบ manual ก็ต้องทำตาม ทั้งๆที่อยากทำแบบคลิกๆๆๆ จะสะดวกสำหรับผู้ใช้มากกว่า ตอนนี้ผมอยู่ที่หน้าต่าง terminal ของ linux mint ทำตามดังนี้ sudo cp libflashplayer.so /opt/mint-flashplugin-11/ sudo cp -r usr/* /usr รัน firefox ใหม่ ตอนนี้ใช้งานได้แล้ว หมายเหตุ เครื่องที่ใช้งานคือ ผมใช้คำสั่ง cat /etc/lsb-release ได้ดังนี้ DISTRIB_ID=LinuxMint DISTRIB_RELEASE=13 DISTRIB_CODENAME=maya DISTRIB_DESCRIPTION=”Linux Mint 13 Maya” ผมใช้คำสั่ง uname -a ได้ดังนี้ Linux HP-ProBook-6450b 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux จบครับ

Script สำหรับการ reset mysql root’s password

March 30, 2013 02:59

สำหรับ admin ของ Linux Server โดยทั่วไปแล้ว มักจะหลีกไม่พ้นที่จะต้อง ติดตั้ง database server สักครั้งนึง เพราะว่า สำหรับ application โดยส่วนใหญ่แล้ว โดยเฉพาะ web application ในปัจจุบัน มักจะต้องการใช้ database server เป็น backend สำหรับการเก็บข้อมูล และบน Linux ส่วนใหญ่ก็จะหนีไม่พ้นการใช้งาน MySQL เป็น Server … เพราะเป็นตัวที่มีคนใช้กันมากที่สุด และรองรับโดยหลายๆ framework ของ Web App ทั้งหลาย แน่นอน ตอนที่ติดตั้งครั้งแรก ตัวซอฟต์แวร์ที่ใช้ในการติดตั้ง ก็ถาม root password ของ MySQL สำหรับการ กำหนดสิทธิในการใช้งาน สำหรับคนที่ใช้งาน database server มานานระดับหนึ่ง ก็จะรู้ว่า password ที่จะใช้สำหรับ root ของ MySQL นั้น ไม่จำเป็นจะต้องเป็นตัวเดียวกับ root password ของระบบ … และ ไม่ควรที่จะเป็นตัวเดียวกัน … สำหรับคนที่ไม่รู้ในเรื่องนี้ ก็มักจะต้อง “เรียนรู้” ด้วยความยากลำบากในทีหลัง … ผมรู้สิน่า ผม “จ่าย” ค่าเล่าเรียนเรื่องนี้ด้วยราคาที่ “แพง” พอสมควรเชียวล่ะ หลังจากที่รู้แล้วว่า มัน “จะต้อง” ไม่ใช่ password เดียวกันกับ password ที่สำคัญของระบบ ปัญหาที่จะตามมาก็คือว่า เราก็อาจจะตั้ง password ของ root ของ MySQL แบบง่ายๆ เช่น “1234”, “abcd” อะไรทำนองนี้ เพราะว่า ในแง่ของการให้บริการ MySQL server ก็มักจะให้บริการกับ “client” ท่อยู่บนเครื่องเดียวกัน ไม่ได้ให้บริการผ่าน network ไปให้เครื่องอื่นๆ หรือ ถ้าจำเป้นจะต้องให้บริการ ก้ให้บริการกับ server ที่อยู่ใน cluster เดียวกัน จะมีเฉพาะ admin ด้วยกันที่จะรู้ว่ามี mysql ให้บริการอยู่บนเครื่องนี้ แน่นอน ความคิดเช่นนี้ ก็มักจะนำบทเรียน “ราคาแพง” บทที่สอง เกี่ยวกับ root password ของ mysql มาให้ อีกเหมือนกัน และมันมักจะพ่วงมากับ “phpmyadmin” ที่จะทำให้ ตัว mysql server ซึ่งเคยเข้าใจว่า “ไม่สามารถเข้าถึงจาก server อื่นๆได้” กลับเข้าถึงได้ง่ายๆ ผ่าน “web” และเมื่อเจอกับ bot ที่โจมตีแบบอัตโนมัติ หายนะ … ก็มาเยือนได้ง่ายๆ เหมือนกัน นั่นก็จะเป็นบทเรียนราคาแพงอีกบทนึงเช่นกัน ข้อสรุปของผม หลังจากได้บทเรียนอย่างนั้นมาก็คือ password ของ root ไม่ว่าจะเป็นของระบบเอง หรือ จะเป็นของ database “จะต้อง” เป็นคนละตัวกัน _และ_ จะต้องมีระดับของความปลอดภัยสูงใกล้ๆกัน ได้ password ที่ secure มา … ก็ดี … แต่ปัญหาของ password ที่ secure ก็คือ จำยาก … สำหรับ root’s password ของระบบ ที่ยังมีการใช้งานค่อนข้างบ่อย ก็จะมีโอกาสที่จะลืมได้น้อยกว่า … วิธีการที่จะทำให้ ไม่ลืม และยังมี password ที่ secure ก็มีแน่ๆ แต่นั่นไม่ใช่สิ่งที่ผมอยากจะพูดถึงในบันทึกนี้ (อันที่จริงก็เขียนเอาไว้ที่อื่นแล้วด้วย) ที่จะมาแก้ปัญหาในบันทึกนี้ ก็คือ