Topic List
/var/log/apache2/error.log
[Sun Jul 07 14:36:12.269017 2024] [mpm_prefork:error] [pid 3153653:tid 3153653] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
/var/log/php7.4-fpm.log
- [07-Jul-2024 00:00:01] NOTICE: error log file re-opened
- [07-Jul-2024 13:15:25] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
nano /etc/php/7.4/fpm/pool.d/www.conf
change pm.max_children = 5 to pm.max_children = 20
nano /etc/apache2/mods-enabled/mpm_prefork.conf
<IfModule mpm_prefork_module>
#StartServers 10
MinSpareServers 10
MaxSpareServers 20
#MaxRequestWorkers 150
#MaxConnectionsPerChild 0
ServerLimit 250
StartServers 10
#MinSpareThreads 75
#MaxSpareThreads 250<br />
#ThreadLimit 64
#ThreadsPerChild 32
MaxRequestWorkers 250
MaxConnectionsPerChild 10000
</IfModule>
yum update iproute yum update ss
เกิดอาการนี้มาเป็นวันที่ 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 ทิ้งไป