ก๊วนซอฟท์แวร์ </softganz> SoftGang (Gang Software)

เกิดอาการนี้มาเป็นวันที่ 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

ที่มา

• Solution For Running Out of Inodes
• How can I increase the number of inodes in an ext4 filesystem?
• Mysql error 28 no space left on the device

ติดตั้งใหม่

แก้ไข 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 น.