Topic List
เกิดอาการนี้มาเป็นวันที่ 2 แล้ว เมื่อวานสั่ง reboot แล้วหาย แต่วันนี้ reboot แล้วยังคงมีอาการอยู่
ที่เคยเจออาการนี้ คือ harddisk เต็ม ซึ่งปกติจะตรวจพื้นที่เหลือใน harddisk ก่อน ด้วย df -h ผลออกมาว่ายังมีพื้นที่เหลืออีกเพียบ จนในที่สุดก็พบว่าที่เต็มนั้นไม่ใช่พื้นที่ แต่เป็น inode ลองตรวจดูด้วยคำสั่ง df -i พบว่า / เต็ม 100%
สาเหตุของครั้งนี้คือ inode ที่มีไว้สำหรับเก็บตำแหน่ง folder/file เต็ม เท่าที่อ่านดู ยังไม่สามารถขยายเพิ่มได้ (ต้องทำตอน format harddisk) จึงต้องค้นหาว่า folder ไหนที่มีไฟล์เป็นจำนวนมาก แล้วก็ลบ/ย้ายไปไว้ที่อื่นที่ใช้คนละ inode กัน
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on udev 1275949 357 1275592 1% /dev tmpfs 1278745 553 1278192 1% /run /dev/sda1 1831424 1831424 0 100% / tmpfs 1278745 1 1278744 1% /dev/shm tmpfs 1278745 3 1278742 1% /run/lock tmpfs 1278745 15 1278730 1% /sys/fs/cgroup /dev/sdb1 122093568 8699755 113393813 8% /backup /dev/sda4 119996416 4748787 115247629 4% /home /dev/sda2 122400 337 122063 1% /boot tmpfs 1278745 10 1278735 1% /run/user/1004
คำสั่ง ls เพื่อดูว่าแต่ละ file มี inode หมายเลขอะไร
# ls -lai
คำสั่งสำหรับนับจำนวนไฟล์ในแต่ละ folder
# for i in /*; do echo $i; find $i |wc -l; done
# echo "Detailed Inodes usage for: $(pwd)" ; for d in `find -maxdepth 1 -type d |cut -d/ -f2 |grep -xv . |sort`; do c=$(find $d |wc -l) ; printf "$c - $d " ; done ; printf "Total: $(find $(pwd) | wc -l) "
พบว่า folder usr/local/directadmin/data/tickets มี folder/file จำนวนมาก ซึ่งสะสมมาจาก ticket ที่ระบบอัตโนมัตของ directadmin สร้างขึ้นมา จึงทำการลบไฟล์ทิ้งทั้งหมด
# rm -rm /usr/local/directadmin/data/tickets[code] แล้วย้าย folder tickets ไปไว้ใน /backup (ซึ่งอยู่คนละ harddisk ก็จะไม่มีผลต่อ inode ของ /) [code] # mkdir /backup/usr # mkdir /backup/usr/local # mkdir /backup/usr/local/directadmin # mkdir /backup/usr/local/directadmin/data # mkdir /backup/usr/local/directadmin/data/tickets [code] เปลี่ยน owner/group ให้เป็นของ DirectAdmin [code] # chown diradmin:diradmin /backup/usr/local/directadmin # chown diradmin:diradmin /backup/usr/local/directadmin/data # chown diradmin:diradmin /backup/usr/local/directadmin/data/template # chown diradmin:diradmin /backup/usr/local/directadmin/data/tickets
สร้างลิงก์ tickets ไปที่ใหม่
# cd /usr/local/directadmin/data # mv tickets tickets.old # ln -s /backup/usr/local/directadmin/data/tickets tickets # chown -h diradmin:diradmin tickets
ปล. เขาบอกว่าให้ลบไฟล์ session ทิ้งด้วย
# find . -type f -name sess_\* -delete
ที่มา
ติดตั้งใหม่
แก้ไข Sources List
https://wiki.debian.org/SourcesList
ติดตั้ง DirectAdmin
https://www.directadmin.com/installguide.php
กำหนดค่า DirectAdmin หลังติดตั้งเสร็จ
https://www.directadmin.com/newinstall.html
How to enable LetsEncrypt
https://help.directadmin.com/item.php?id=648
Setting up DA with an SSL certificate
https://help.directadmin.com/item.php?id=15
Installing an SSL certificate for your hostname using LetsEncrypt
https://help.directadmin.com/item.php?id=629
ปล. ยังเขียนไม่เสร็จทีนะครับ
เมื่อวาน (1/12/2018) server ของ wintesla2003 เกิดการ reboot เอง โดยไม่ทราบสาเหตุ
ตรวจ log แล้ว ก็ไม่เจออะไรผิดปกติ
จนถึงตอนนี้ก็ยังไม่ทราบว่าเกิดอะไรขึ้น
Update : เมื่อเช้า ประมาณ 6 โมงเช้า (2/12/2018) ก็มีการ reboot อีก
root$last reboot reboot system boot 3.10.0-327.3.1.e Sun Dec 2 06:08 - 11:28 (05:20) reboot system boot 3.10.0-327.3.1.e Sat Dec 1 13:27 - 11:28 (22:01) reboot system boot 3.10.0-327.3.1.e Sat Dec 1 12:44 - 11:28 (22:44) reboot system boot 3.10.0-327.3.1.e Sat Dec 1 09:52 - 11:28 (1+01:36) reboot system boot 3.10.0-327.3.1.e Tue Nov 7 15:25 - 11:28 (389+20:03) reboot system boot 3.10.0-327.3.1.e Tue Nov 7 14:12 - 14:14 (00:01) reboot system boot 3.10.0-327.3.1.e Tue Nov 7 13:36 - 14:14 (00:37) reboot system boot 3.10.0-327.3.1.e Mon Nov 6 13:00 - 14:14 (1+01:13) reboot system boot 3.10.0-327.3.1.e Mon Nov 6 12:53 - 12:56 (00:02) reboot system boot 3.10.0-327.3.1.e Mon Nov 6 12:48 - 12:52 (00:03) reboot system boot 3.10.0-327.3.1.e Mon Jan 16 11:43 - 12:52 (294+01:09) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:58 - 12:52 (497+18:53) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:55 - 12:52 (497+18:56) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:50 - 17:54 (00:03) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:45 - 17:49 (00:03) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:39 - 17:43 (00:04) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:32 - 17:43 (00:11) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:21 - 17:23 (00:01) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 17:15 - 17:20 (00:04) reboot system boot 3.10.0-327.3.1.e Sun Jun 26 16:43 - 17:20 (00:37) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 15:09 - 16:19 (182+01:09) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 15:07 - 15:08 (00:00) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 15:02 - 15:06 (00:04) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:56 - 15:06 (00:10) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:48 - 15:06 (00:18) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:44 - 15:06 (00:21) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:37 - 14:43 (00:05) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:35 - 14:36 (00:01) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 14:21 - 14:33 (00:12) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 13:42 - 14:33 (00:51) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 13:17 - 13:17 (00:00) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 13:15 - 13:15 (00:00) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 13:10 - 13:15 (00:05) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 12:40 - 13:03 (00:23) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 12:14 - 12:21 (00:06) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 11:38 - 12:21 (00:43) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 09:49 - 12:21 (02:32) reboot system boot 3.10.0-327.3.1.e Sun Dec 27 09:45 - 12:21 (02:36) reboot system boot 3.10.0-327.3.1.e Sat Dec 26 19:44 - 19:51 (00:06) reboot system boot 3.10.0-327.3.1.e Sat Dec 26 19:33 - 19:51 (00:17) reboot system boot 3.10.0-327.el7.x Sat Dec 26 18:56 - 19:21 (00:25)
คำสั่งสำหรับ last - Linux Find Out Last System Reboot Time and Date Command
@2018-11-17 9.00 น. แวะเข้าไป CAT เพื่อเปลี่ยน Harddisk สำหรับ Backup ข้อมูล เนื่องจากเสียมาหลายวันแล้ว แต่รองบประมาณและช่วงวันเสาร์-อาทิตย์ เพราะวันธรรมดามีการใช้งานเยอะ ไม่อยากปิดในช่วงเวลานั้น
เตรียมการโดยการ Format ไปจากบ้าน ตั้ง Label ให้ตรงกับของเดิม เมื่อเปลี่ยนเสร็จ เปิดเครื่องก็เลยมองเห็นทันที ไม่ต้องตั้งค่าอะไร
เสร็จเรียบร้อยในเวลาอันรวดเร็ว
@9.30 น. กลับบ้าน
วันนี้อ่านข่าว ช่องโหว่ใน Apache Struts 2 เปิดทางรันโค้ดจากระยะไกล มีการโจมตีแล้ว แล้วลองมาเช็ค Apache บน production host พบว่ายังเป็น version 2.2 อยู่ ก็เลยลอง upgrade
เริ่มแรกด้วยการตรวจสอบรุ่นของ Apache ก่อน link
On Debian and Mac OS:
apachectl -v
On Red Hat and Amazon's EC2 Linux use:
httpd -v
On other verisons of Linux try:
apache2 -v
You can use two different flags:
-v # gives you the version number -V # gives you the compile settings including version number.
If you want to run the command with the full directory like user3786265 did but don't know where your apache is located, use the whereis command:
whereis httpd
ที่ server ใช้ Directadmin ก็ใช้ DirectAdmin build
cd /usr/local/DirectAdmin/custombuild<br /> ./build set apache_ver 2.4 ./build update ./build clean ./build apache n ./build php n service httpd restart
ผลปรากฏว่า start Apache ไม่ได้ ล่มทั้ง server เนื่องจากใช้ suPHP อยู่ด้วย
รีบหาข้อมูลโดยเร็ว ทำอย่างไรดี โทรศัพท์เริ่มกริ๊งกร๊างเข้ามาแล้ว......
ที่แรก คือ Updating Apache to the latest version
ที่ต่อมา คือ Invalid command 'suPHP_Engine'
ที่สำคัญคือ build suphp และ rewrite_confs
cd /usr/local/directadmin/custombuild ./build update ./build clean ./build php y ./build suphp y ./build rewrite_confs
เหตุที่เกิดปัญหา เนื่องจาก ไม่ได้ build suphp ของ Apache 2.4 ทำให้ start Apache ไม่ได้ และเมื่อ build suphp เสร็จแล้ว จะต้องสร้าง config ใหม่ด้วย build rewrite_confs
รอดตามไปอีกครั้งหนึ่ง ชีวิตนี้มีลุ้นทุกครั้งที่ต้องอัพเกรด server
มีข่าว แอดมินระวัง เริ่มพบการโจมตีช่องโหว่ Bash Shellshock แล้ว มาถึงแล้ว
วันนี้เริ่มมีแจ้งเตือน update มาแล้ว ก็เริ่มดำเนินการกันเลย
ก่อนอื่นลองทดสอบกันดูก่อนว่า bash เรามีช่องโหว่หรือไม่ด้วยคำสั่ง
env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"หากขึ้นข้อความว่า
Bash is vulnerable!
Bash Test
แสดงว่า bash เรามีช่องโหว่นะจ๊ะ
แต่หากขึ้นแค่
Bash Test
ก็แสดงว่าปลอดภัยแล้ว
ส่วนวิธีอัพเดทก็มีหลายวิธีแล้วแต่ค่ายของ Linux ลองตามไปดูต้นฉบับกันจะดีกว่า
รวมหลายค่าย ทำตาม How to Protect your Server Against the Shellshock Bash Vulnerability
Ubuntu : ทำตามวิธีการ
Debian : ทำตามวิธีการ
เจอปัญหา The system load มาประมาณ 1 อาทิตย์แล้ว ยังไม่แน่ใจในสาเหตุ
อาจจะเป็นว่ามีบางเว็บส่งเมล์ เท่าที่ลองเช็คดูพบว่า border9025.com ส่งเมล์ออกเยอะพอสมควร จึงได้ยกเลิกการส่งเมล์ไปก่อน
ด้วยการ ยกเลิการกำหนด MX Record ที่ Use this server to handle my emails. If not, change the MX record and uncheck this option ไปก่อน
แล้วคอยดูสถานการณ์
xxxx.net ถูกโจมตี เริ่มมาตั้งแต่วันที่ 3 ก.พ. 57 แต่ยังไม่รู้ เพิ่งมารู้วันนี้เมื่อ web หยุดทำงานทั้งหมด เช็คดูปรากฏว่า harddisk เต็ม โดยไฟล์ที่ใหญ่ขึ้นคือ log ของโดเมน xxx.net อยู่ใน /var/log/httpd/domains/xxx.net.error.log เบ้อเริ่ม 3xxGB เนื่องจากมีการเข้าถึงไฟล์หนึ่งของ jumla คือ /home/xxxx/domains/xxxx.net/public_html/libraries/joomla/filesystem/folder.php แล้วเกิด warning จึงเกิด error log ที่ใหญ่ขึ้นเรื่อย ๆ จน harddisk เต็ม
ตอนนี้ก็เลย suspen เว็บไว้ก่อน แล้วลบ log file ทิ้งไป
12.30 น. ผมสั่ง remote reboot server พร้อมความกังวลทุกครั้งที่สั่ง reboot ว่าเครื่องจะเปิดขึ้นหรือเปล่า
12.40 น. นิ่ง ping ไม่เห็น เริ่มเหงื่อตก
12.50 น. เริ่มโทรหา NOC โทรเข้าสำนักงาน ไม่ติด โทรหา จนท.ที่ติดต่อกันอยู่ ได้เบอร์ใหม่ของมือถือ จนท. ดูแลห้อง IDC
13.10 น. จนป่านนี้ จนท. ยังไม่ยอมรับสาย โทรหา จนท. ที่ติดต่อกันอยู่อีกที คาดว่า จนท. ไปกินข้าวกระมัง?
14.00 น. ไม่มีวี่แววว่าใครจะรับสาย
14.30 น. ตัดสินใจบึ่งรถไป IDC (เจอ จนท. บอกว่าไปกินข้าว เพิ่งกลับมา)
14.50 น. เสียบจอ ถอดปลั๊ก (หากุญแจหน้าเครื่องไม่เจอ ไม่รู้ไปเก็บไว้ที่ไหน ลืมแว่นตา เพ่งแล้วเพ่งอีกว่าเครื่องเราเครื่องไหนวะ กลัวถอดสายผิดเครื่อง)
14.55 น. boot แล้ว กำลังตรวจสอบ harddisk /dev/sdb1 0.1% ผ่านไปเกือบนาที 0.2% ตายแน่เลย 10 ชั่วโมงก็ไม่รู้จะเสร็จไหม
14.57 น. CTRL+C , CTRL+D ข้ามไปเลย boot..... complete
15.00 น. web site running
15.05 น. กลับบ้าน
แก้คอนฟิกให้ไม่ต้องเข็ค harddisk ขณะเปิดเครื่องดีกว่า ไม่งั้นแย่แน่ ๆ
แก้ค่าในไฟล์ /etc/fstab
/dev/sdb1 /mntpoint ext3 defaults 1 2
แก้ค่าตัวเลขข้างหลังให้เป็น 0 0
/dev/sdb1 /mntpoint ext3 defaults 0 0
ยังไม่กล้า reboot ไว้ค่อยแวะเข้าไปที่ IDC แล้วค่อยลอง reboot นะ
Update : 2014-07-16
15.30 น. Server down อีกแล้ว
15.50 น. โทรเช็คกับ CAT ทราบว่าเขาเปลี่ยน UPS ทำให้เครื่องดับทั้งหมด OK ให้ช่วยกดเปิดสวิทช์ของ wintesla (เครื่องนี้พอไฟดับ จะไม่ start เอง ต้องมากดปุ่ม power)
15.52 น. Server softganz ยังไม่มา noc บอกว่าไฟ harddisk ติดค้างเลย คาดว่าจะเกิดอาการเดิมคือ เครื่องกำลัง check disk อยู่แน่เลย ให้ noc ช่วยเสียบจอ แต่ server เคสสั้น เสียบจอยาก เลยต้องวิ่งเข้าไปเอง
16.10 น. เอาจอเสียบเข้าไป ปรากฏว่าเป็นอย่างนั้นจริง กำลังเช็คได้ 13% อีกนานกว่าจะเสร็จ
16.20 น. ลองสั่งใหม่ ไม่ให้ check disk ตอนเปิดเครื่อง ด้วยคำสั่ง “tune2fs” ซึ่งเป็นคำสั่งสำหรับเปิดจำนวนการ mout (command to turn off mount count based)
sudo tune2fs -c 0 -i 0 /dev/sdDN
โดย “D” คือ represents the disk และ “N” represents the partition number of the file system
16.22 น. ลอง reboot คราวนี้ไม่เช็คแล้ว ลองปิดเครื่อง แล้วกดสวิทช์เปิดใหม่ ก็ไม่เช็คแล้ว หวังว่าคงหายนะ เพราะอีกไม่นานจะโดนปิดเครื่องเพื่อย้าย server ไปไว้อีกห้อง
16.40 น. กลับบ้านแล้ว
ปรับค่าในการทำ System Backup ใหม่ เป็น
- ยกเลิก Configure Full System Backup : Backup MySQL Databases
- เพิ่ม Directories : /backup/daily/home/mysql
- เปลี่ยนเวลา cronjob เป็น 00:01 น. ทุกวัน
Update : สถานการณ์ของ load ดีขึ้น System backup เสร็จภายใน 1 ชั่วโมง rsync fullbackup เริ่มเวลา 03.00 น. เสร็จประมาณ 07.00 น.