Messages posted by "tuanksor"

Xin giúp đỡ vấn đề về high load avg

tuanksor — GMT

cảm ơn myquartz đã giải thích rõ ràng cho mình hiểu vấn đề, như myquartz nói việc phân rõ ràng mount point nào cho dạng truy cập nào thì mình thấy nó thích hợp nếu ứng dụng web là của mình, mình điều chỉnh thế nào cũng đc. Nhưng do hiện tại nó là mô hình shared host, việc điều chỉnh cho từng host tương ứng chắc là k khả thi, :). nó đúng như là cái nồi lẩu thật :D Không biết là có ứng dụng nào có thể cache lại php file lên trên web server để nó có thể đọc từ local cho lần thứ 2 thay vì phải truy xuất vào nfs k nhỉ mình có dùng cachefs nhưng thấy nó cache tùm lum hết, mà hiệu năng cũng k cải thiện đc mấy xin cảm ơn mọi ng đã xem và tư vấn giúp mình

Xin giúp đỡ vấn đề về high load avg

tuanksor — GMT

myquartz wrote:

tuanksor wrote:

- Source code đặt tại NFS (mount nfs v3)

tuanksor wrote:

2. Mình có test qua performance giữa apache, php, local storage(1) vs apache, php, nfs storage(2) thì thấy performance (1) > (2), sử dụng strace php-cgi để count syscall khi chạy trên nfs thì thấy các syscall access, open có % lớn hơn khi chạy local storage (ở local storage thì syscall munmap lớn). Sử dụng cachefs & nhưng cũng không ăn thua. Nên có nghĩ đến việc đổi mô hình, nhưng mắc phải vấn đề sync, dữ liệu hosting rất nhiều. với lại đang là mô hình production, thay đổi thì chắc rất cực. Mình tập trung vấn đề load avg tại web server do chỉ có 1 con server ấy bị, các con khác còn lại chạy bình thường
Có vẻ như 2 phần bôi đậm kia, kết hợp thông tin NFS v3 là vấn đề của bạn. Ứng dụng của bạn khi chạy local storage nó sử dụng IO kiểu mmap/munmap, một kiểu IO có tốc độ cao và trễ thấp. Khi mount với NFS v3, thì mmap không được hỗ trợ, phải fail-back về kiểu open/read bình thường (nên syscall 2 cái này nhiều hơn). Có vài thảo luận về vấn đề NFS liên quan đến mmap này. Kể cả khi dùng open/read thì cũng có vấn đề. Do NFS là 1 share file system nên yếu tố concurrency được đảm bảo, chính nó gây nhiều overhead xử lý các IO, nhất là trong trường hợp read+write IO. Đó chính là nguyên nhân dẫn tới IO wait cao hơn local storage. Bạn không nói rõ ngoài source code ra thì còn content nào khác (ví dụ images, css...) phải lấy ra từ disk không, ứng dụng chỉ source code/content read only hay cả read/write. Vì thế, giải pháp là 1. bạn phải từ bỏ NFS, phải dùng local storage + sync. 2. bạn phải tuning/sửa lại ứng dụng PHP hoặc cách dùng module, sao cho phân rõ kiểu IO với từng module (read hay read/write) để dùng NFS cache được, (kiểm tra lại ứng dụng mount NFS dạng read-only và tùy chọn nolock, bật cache nữa). 3. Ứng dụng phải sửa hoặc NFS mount option phải chỉnh lại để truy cập IO tối ưu cho open/read, tránh locking hoặc cache-sync giữa các node mount lên NFS server. Ref: Google 1 lúc thì ra khá nhiều thông tin liên quan đến NFS mmap. Ví dụ có 1 thảo luận: http://stackoverflow.com/questions/10367577/mmap-file-shared-via-nfs

Cảm ơn myquartz đã tư vấn, Về source code và tất cả content đều đặt tại 1 folder trên nfs mount, read lẫn write 1. Vì hiện nó đang vận hành, mô hình xuyên xuốt từ phía khách hàng đến cả phần quản lý, nên việc thay đổi như vậy mình thấy rất khó mặc dù là muốn thế 2,3. Đây là option mount nfs hiện tại đang sử dụng: Code:

rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.x,mountvers=3,mountport=43882,mountproto=udp,local_lock=none,addr=10.0.0.x 0 0

trước có dùng option fsc và chạy cachefs nhưng mình bỏ do mình test đi test lại thấy vẫn như nhau k có tác dụng gì lắm.

bạn phải tuning/sửa lại ứng dụng PHP hoặc cách dùng module, sao cho phân rõ kiểu IO với từng module (read hay read/write) để dùng NFS cache được

mình k rõ ý này lắm, myquartz có thể tư vấn thêm ở cái đoạn này ko :D ?

Xin giúp đỡ vấn đề về high load avg

tuanksor — GMT

Ikut3 wrote:

Hello Tuan (sorry vì mình reply trễ) Nếu theo các thông số bạn đưa ra trên Webserver này, thì tuyệt nhiên mình không thấy có gì bất thường. Thậm chí là còn nhanh nữa là đằng khác. Đoán già đoán non thôi thì bạn thử gather lại với các thông tin tương tự trên các server khác để so sánh xem có sự chênh lệch ở điểm nào không ? Mình nghĩ nên chạy cho các server ở thời điểm có lượng người truy cập. Mình chỉ hơi confuse ở 2 điểm này, nếu bạn tiếp tục được cùng mình thì tốt 1. Bạn có hệ thống monitoring nào để lấy các thông tin của các server không ? Mình nghĩ sử dụng graph trong các trường hợp này sẽ thấy được nhiều mối tương quan hơn là chỉ dựa vào các thông số 2. Bạn có đảm bảo rằng Server chậm đang cài giống 100% cấu hình cả mềm lẫn cứng đối với các server khác ? Kinh nghiệm của mình trong những case mà tất cả mọi thứ đều có sự logic như thế này là "so sánh & so sánh". Có thể 1 vài thông số tunning của application dựa vào phần cứng đã bị sai lệch đi khi chạy trên những hardware profile khác nhau ? Mình có dùng thử 1 công cụ mới được giới thiệu ở Hacker News là http://www.sysdig.org/. Mình thấy có sự khác biệt rất nhiều so với việc tự gather từ những thông số rời rạc như disk - ram - cpu thông qua các câu lệnh thường dùng. Với sysdig mình nắm được rõ mọi hành vi của bất kì request nào thông suốt từ application đến kernel, tiêu tốn bao nhiêu phần trăm tài nguyên hệ thống. Biết đâu sự bình thường trong những tình huống bất thường diễn ra từ đó. Thân

Hi Ikut3, thanks đã reply 1. Hệ thống sử dụng nagios & nagios grapth để thu thập các thông tin của server. Nhưng khi dựng server lên và chạy đã xảy ra sự cố như trên, k thể để chạy lâu dài mà mình phải ngắt ra khỏi hệ thống. 2. Mình không đảm bảo 100% là phần cứng giống nhau nhưng tương đương nhau về lượng (CPU, mem, Disk, ....), 100% về config giống nhau. Hiện tại đã thay thế 1 con server khác, cũng với những config như vậy nhưng lại chạy bình thường, k vấn đề gì xảy ra. Nên nghĩ chắc vấn đề là ở phần cứng nhưng k biết troubleshoot như thế nào cho chính xác mà thôi :) Thanks Ikut3 về cái tool sysdig (biết thêm 1 món :D)

Xin giúp đỡ vấn đề về high load avg

tuanksor — GMT

Trước tiên mình xin cảm ơn Ikut3 đã tư vấn cho mình, các vấn đề bạn đặt ra mình xin trả lời: 1. Kết nối giữa NFS storage & Web server: 1000Mbps, bw dùng iperf để đo (Đo lúc web server chưa có http traffic): Code:

# iperf -c 10.0.x.y -P 1 -i 1
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   111 MBytes   932 Mbits/sec
[  3]  1.0- 2.0 sec  87.9 MBytes   737 Mbits/sec
[  3]  2.0- 3.0 sec   110 MBytes   925 Mbits/sec
[  3]  3.0- 4.0 sec   110 MBytes   926 Mbits/sec
[  3]  4.0- 5.0 sec   111 MBytes   929 Mbits/sec
[  3]  5.0- 6.0 sec   109 MBytes   916 Mbits/sec
[  3]  6.0- 7.0 sec   110 MBytes   923 Mbits/sec
[  3]  7.0- 8.0 sec   111 MBytes   930 Mbits/sec
[  3]  8.0- 9.0 sec   111 MBytes   930 Mbits/sec
[  3]  9.0-10.0 sec   108 MBytes   909 Mbits/sec
[  3]  0.0-10.0 sec  1.05 GBytes   906 Mbits/sec

iostat tại NFS server (đang có io từ 3 web server): Code:

# zpool iostat -v
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write

rpool       23.1G   905G      0     12  5.25K   115K
  c2t0d0s0  23.1G   905G      0     12  5.25K   115K

zpool1      1003G  1.74T    288    119  2.29M  1.25M
  c2t1d0     334G   594G     96     18   781K   240K
  c2t2d0     334G   594G     96     18   782K   240K
  c2t3d0     334G   594G     96     18   780K   240K
logs            
  c2t75d0   13.9M   111G      0     64      0   556K

- NFS đang chạy trên bundle ZFS (OS: Unix - Openindiana), chạy raid 1, sử dụng Zil SSD cho logs pool 2. Mình có test qua performance giữa apache, php, local storage(1) vs apache, php, nfs storage(2) thì thấy performance (1) > (2), sử dụng strace php-cgi để count syscall khi chạy trên nfs thì thấy các syscall access, open có % lớn hơn khi chạy local storage (ở local storage thì syscall munmap lớn). Sử dụng cachefs & nhưng cũng không ăn thua. Nên có nghĩ đến việc đổi mô hình, nhưng mắc phải vấn đề sync, dữ liệu hosting rất nhiều. với lại đang là mô hình production, thay đổi thì chắc rất cực. Mình tập trung vấn đề load avg tại web server do chỉ có 1 con server ấy bị, các con khác còn lại chạy bình thường

Xin giúp đỡ vấn đề về high load avg

tuanksor — GMT

Hi mọi người, hiện tại e đang gặp khó khăn về vấn đề troubleshoot high load avg, mong mọi người giúp em. Mô hình phát thảo của e như sau: LVS -> Webserver(Apache) -> NFS storage Web server: - Ram 32G, CPU 2.40GHz, 8 core, HDD raid 1 (nhưng đang chạy 1 ổ do 1 ổ hỏng đã rút ra) - OS: Centos 6.5, Apache chạy mod worker, suexec, php handler: php-cgi - Đã rebuild kernel giảm time_wait còn 15s - Source code đặt tại NFS (mount nfs v3) load avg sau 2 phút cho http traffic đi vào server này: Code:

load average: 44.91, 25.12, 10.04

Code:

top - 09:47:36 up 3 days, 11:21,  2 users,  load average: 44.91, 25.12, 10.04
Tasks: 261 total,   1 running, 259 sleeping,   0 stopped,   0 zombie
Cpu(s): 14.9%us,  4.8%sy,  0.0%ni, 14.5%id, 65.1%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:  32869904k total,  2728816k used, 30141088k free,    11176k buffers
Swap: 16777208k total,        0k used, 16777208k free,   951004k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
18985 17674     20   0  396m  51m  25m D 14.6  0.2   0:00.81 php-cgi
19296 19037     20   0  448m  89m  11m D 13.0  0.3   0:00.39 php-cgi
19259 10944     20   0  389m  38m  19m D  6.0  0.1   0:00.18 php-cgi
19112 18034     20   0  398m  56m  27m D  5.0  0.2   0:00.64 php-cgi
19244 10944     20   0  395m  50m  25m D  4.7  0.2   0:00.25 php-cgi
19245 10944     20   0  395m  51m  26m D  4.7  0.2   0:00.25 php-cgi
19252 10944     20   0  391m  43m  22m D  4.7  0.1   0:00.21 php-cgi
19256 19389     20   0  382m  27m  14m D  4.3  0.1   0:00.13 php-cgi
19246 12969     20   0  387m  34m  17m D  4.0  0.1   0:00.27 php-cgi
19239 13264     20   0  394m  49m  24m D  3.7  0.2   0:00.24 php-cgi
19241 12969     20   0  387m  34m  17m D  3.7  0.1   0:00.27 php-cgi
19291 18253     20   0  378m  19m  10m D  3.3  0.1   0:00.10 php-cgi
19255 17569     20   0  380m  22m  12m D  3.0  0.1   0:00.09 php-cgi
19290 15184     20   0  378m  19m  10m D  3.0  0.1   0:00.09 php-cgi
19211 10944     20   0  401m  62m  31m D  2.7  0.2   0:00.33 php-cgi
19258 17691     20   0  378m  19m  10m D  2.7  0.1   0:00.08 php-cgi
19292 10544     20   0  379m  19m  10m D  2.7  0.1   0:00.08 php-cgi
19294 18371     20   0  378m  18m  10m D  2.7  0.1   0:00.08 php-cgi
19295 18371     20   0  378m  18m  10m D  2.7  0.1   0:00.08 php-cgi
19311 15905     20   0  379m  20m  11m D  2.7  0.1   0:00.08 php-cgi
19224 19047     20   0  382m  27m  14m D  2.3  0.1   0:00.20 php-cgi
19310 18371     20   0  378m  18m  10m D  2.3  0.1   0:00.07 php-cgi
19313 16031     20   0  378m  18m  10m D  2.3  0.1   0:00.07 php-cgi
19215 15905     20   0  398m  56m  28m D  2.0  0.2   0:00.31 php-cgi
19216 15905     20   0  398m  56m  28m D  2.0  0.2   0:00.30 php-cgi
19217 15530     20   0  386m  34m  17m D  2.0  0.1   0:00.18 php-cgi

io wait lên rất cao dẫn đến các process chờ lâu nên sinh ra rất nhiều process php-cgi kết quả e test read/write lên HDD khi không chạy apache; Code:

# hdparm -I /dev/sda | grep speed
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)

Code:

# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   15424 MB in  2.00 seconds = 7724.50 MB/sec
 Timing buffered disk reads: 402 MB in  3.01 seconds = 133.72 MB/sec

Code:

# dd if=/dev/zero of=/tmp/test.bin bs=8k count=256k
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 1.84109 s, 1.2 GB/s

Code:

# dd of=/dev/null if=/tmp/test.bin bs=8k count=256k
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 0.485696 s, 4.4 GB/s

Mong mọi người giúp đỡ e vấn đề này để có thể detect đc do đâu, e xin cảm ơn. PS: Với cấu hình tương tự ở một server khác hoạt động rất bình thường nên nghi ngờ vấn đề từ hardware ^^

Lỗi 502 Bad Gateway nginx

tuanksor — GMT

Lỗi 502 thường do frontend (nginx as proxy) nhận đc invalid respone từ backend (apache) (có thể apache ko chạy, hay bị drop bởi iptables). Bạn kiểm tra truy cập từ nginx -> apache xem thế nào Code:

#curl -IL http://172.20.20.238:8080

Lỗi 502 Bad Gateway nginx

tuanksor — GMT

Bạn kiểm tra lại xem apache có đang hoạt động bình thường không (truy cập trực tiếp ko qua proxy), kiểm tra iptables tại server apache đã accept port 8080 chưa.

Show UIDs & GIDs cả sub folder

tuanksor — GMT

Code:

ls -nR > export.txt

Show UIDs & GIDs cả sub folder

tuanksor — GMT

Bạn thử dùng Code:

#find  -type d | xargs ls -nd > export.txt

thử có phải cái bạn cần ko

tìm process id đang mở udp port

tuanksor — GMT

Hiện tại mình đã tìm được file gây ra bottle neck. Khi xảy ra sự cố, mình tail access log của uid này, và tìm ra được file bot php Bên trong file đơn giản chỉ là 1 vòng lặp vô tận while(1) nội dung bên trong while dùng các func fsockopen() , fwrite() và fclose() để mở socket gửi data ra ngoài data là chuỗi ký tự XXXXX (khớp với payload khi mình capture đc bằng tcpdump) Cảm ơn quanta rất nhiều

tìm process id đang mở udp port

tuanksor — GMT

mình cảm ơn quanta rất nhiều Sau một buổi nín thở nằm chờ, đã xác định được uid gây ra hiện tượng trên Khi xảy ra hiện tượng bottle neck tại firewall, xác định được des ip, mình vào webserver bật iptables lên tạo 1 rule mới: Code:

# iptables -t filter -I OUTPUT -d 112.78.1.194 -j LOG --log-prefix="tracking: "

nhằm để xác định thời gian tiếp tục tạo rule audit: Code:

#auditctl -d exit,always -F arch=b64 -S socket -k SOCKET -F a0=2 -F a1=2

để im trong ~1 phút sau đó bỏ 2 rule trên, đổ log audit vào 1 file mới Code:

#ausearch -sc socket | grep 'a0=2' | grep 'a1=2' > audit.track.log

hiện tượng xảy ra lúc ~10:54 (theo log kernel), mình lọc khoảng thời gian này Code:

#grep "^10:5[4-6]" audit.track.log > audit.track1.log

nhưng lượng log vẫn còn quá lớn Code:

# grep "^10:5[4-6]" audit.track1.log | wc -l
55921

nên mình lọc ra xem uid nào mở socket nhiều nhất trong khoảng thời gian 10:54 -10:56 Code:

#grep "^10:5[4-6]" audit.track1.log | awk '{print $15,$16,$24,$25,$26}' | sort -k1 | uniq -c | sort -rn | head
55084 uid=1xxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
     85 uid=xxxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
     34 uid=xxxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
.....

lúc này coi như khoanh vùng được là do tên nào cd đến homedir của uid này: có source web chạy joomla vẫn chưa thể xác định được file nào mình thử xem log của những web này, thấy có nhiều request lạ như thế này 80.242.139.195 - - [10/Jan/2014:10:53:53 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:55:15 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:56:36 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:57:58 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:59:19 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:00:41 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:02:02 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:03:23 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xxx trong homedir/tmp, mình tìm ra đc 2 file (file đính kém) trong đó có 1 con webshell :( nhưng không biết có phải file b.php gây ra hiện tượng bottle neck hay ko (còn chính xác file nằm trong homedir của uid trên, vì trong lúc xảy ra hiện tượng, mình đổi tên cái homedir đi thì ngắt ngay hiện tượng bottle neck ) hiện mình định dùng audit track (chờ xảy ra hiện tượng ở lần tiếp theo) toàn bộ file trong homdir của user này, auditctl -w /homedir-uid/ -p rx mong sẽ xảy ra hiện tượng trên sớm. (cho mình hỏi có cách nào tối ưu hơn không :) ) http://www.mediafire.com/download/dls41n3bdk7uh76/file.zip

tìm process id đang mở udp port

tuanksor — GMT

mình cảm ơn quanta, mặc dù chưa gặp lại cái hiện tượng trên để mình thực hiện tracking bằng audit, mình có thử nghiệm với rule quanta hướng dẫn, sau khi add rule khoảng 15s, dùng ausearch: # ausearch -sc socket kết quả quá lớn, và toàn bộ các process hầu như là suexec và php-cgi (vì webserver chạy rất nhiều website) Code:

# ausearch -sc socket | wc -l
63468

Code:

#ausearch -sc socket
time->Thu Jan  2 20:47:33 2014
type=SYSCALL msg=audit(1388670453.581:284435): arch=c000003e syscall=41 success=yes exit=3 a0=1 a1=80801 a2=0 a3=ffffffffff
ffffff items=0 ppid=30299 pid=3651 auid=520 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 tty=(none) ses=388
55 comm="suexec" exe="/usr/sbin/suexec" key="SOCKET"

time->Thu Jan  2 20:47:33 2014
type=SYSCALL msg=audit(1388670453.584:284436): arch=c000003e syscall=41 success=yes exit=4 a0=2 a1=2 a2=0 a3=7fff17818960 i
tems=0 ppid=3305 pid=3649 auid=520 uid=15382 gid=200000 euid=15382 suid=15382 fsuid=15382 egid=200000 sgid=200000 fsgid=200
000 tty=(none) ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi" key="SOCKET"

Nếu xảy ra hiện tượng như ở câu hỏi, khi mình track được dữ liệu với số lượng như trên, không biết phải soi thế nào mới ra đúng cái process hay uid,pid,... mình cần tìm không :(

tìm process id đang mở udp port

tuanksor — GMT

Cảm ơn myquartz, mà với lệnh netstat bạn đưa ra thì chỉ xem được process nào đang LISTEN thôi, mình cần tìm ra process đã thiết lập kết nối ra bên ngoài. Thêm thông tin là tại webserver, net.ipv4.ip_forward = 0, nên mình chắc rằng không có kết nối nào đi qua nó được, chỉ có vào ra thôi

tìm process id đang mở udp port

tuanksor — GMT

Các bạn cho mình hỏi làm sao để tìm được 1 process id nào đang mở 1 udp port. Mình sử dụng netstat nhưng tại column process_id/process_name hiển thị là - Code:

#  netstat -np --protocol=inet | grep 101.99.6.87
udp        0      0 10.0.0.xxx:44431            101.99.6.87:53              ESTABLISHED -

mình sử dụng lsof, nhưng không ra kết quả gì Code:

#port=`netstat -np --protocol=inet | grep 101.99.6.87 |awk '{print $4}' | cut -d: -f2` && lsof -i :$port

(hơi ngoài lề với câu hỏi nhưng cho mình tiện hỏi luôn) Sở dĩ mình cần tìm process và file đang sử dụng để xác định nguyên nhân của việc mạng bị bottle neck. Sơ đồ mạng đơn giản như sau: Wan<---> eth0-LVS(nat)-eth1 <---> Webserver, cổng eth0 100Mb, eth1 1000Mb Tại LVS, mình chạy # iftop -i eth0 Kết quả show ra top là ip 101.99.6.87 <-> 123.162.233.1 (ip wan lvs) với TX > 90Mb, RX: < 1Mb # iftop -i eth1 Kết quả show ra top là ip 101.99.6.87 <-> 10.0.0.xxx (ip webserver) với TX > 900Mb, RX: < 1Mb Mình sử dụng tcpdump tại LVS : #tcpdump -n -vv host 101.99.6.87 -i eth1 -w 101.99.6.87.pcap Dùng wireshark xem gói tin thấy có 2 dạng gói tin, trong đó có 1 gói là malform packet dns(mình ko rõ cái dạng gói tin này là gì, tra google 1 tí thì mình đoán có lẽ server mình bị dính con bot gì rồi, DNS malformed packet flood, http://www.iss.net/security_center/reference/vuln/DNS_Malformed_Flood.htm :( ) file chứa gói tin mình export 2 gói ra file txt: https://www.mediafire.com/?le1d0m6w2zj3h2a Mình đã dùng iptables Drop ip này: #iptables -t filter -I FORWARD 1 -d 101.99.6.87 -j DROP Lúc này traffic out từ ip 123.162.233.1 -> 101.99.6.87 ở eth0 ko còn nữa, nhưng traffic out ở eth1 vẫn còn, nhưng RX = 0, TX > 900Mb À còn ip 101.99.6.87 ko phải lúc nào cũng là ip đó, có lúc nó lại ra ip khác với trường hợp tương tự Rất mong mọi người có thể xem qua và giúp mình, chân thành cảm ơn :)

Giúp đỡ mod_clamav proftpd

tuanksor — GMT

Hiện tại mình recompile proftpd với module mod_clamav version 0.11rc Quá trình biên dịch hoàn toàn bình thường và đã đưa được module clamav vào proftpd Code:

[root@cntt proftpd-1.3.2]# proftpd -vv
ProFTPD Version: 1.3.2 (stable)
  Scoreboard Version: 01040002
  Built: Mon Jun 17 14:34:36 ICT 2013

Loaded modules:
  mod_cap/1.0
  mod_vroot/0.8.5
  mod_clamav.c
  mod_ident/1.0
  mod_facts/0.1
  mod_delay/0.6
  mod_site.c
  mod_log.c
  mod_ls.c
  mod_auth.c
  mod_auth_file/0.8.3
  mod_auth_unix.c
  mod_xfer.c
  mod_core.c

sau đó mình config file proftpd.config với các tham số: Code:

...

  AllowOverwrite                yes

   ClamAV on
   ClamServer 127.0.0.1
   ClamPort 3310


...

clamd đã chạy: Code:

[root@cntt proftpd-1.3.2]# netstat -nlp | grep clamd
tcp        0      0 127.0.0.1:3310              0.0.0.0:*                   LISTEN      3638/clamd

Sau đó mình chạy proftpd ở chế độ debug level 10, dùng trình ftp client đăng nhập, upload 1 file virus lên server Kết quả là clamav đã remove file này. Đến đây mọi thứ OK Code:

...
localhost (113.10.2.149[113.10.2.149]) - Going to virus scan absolute filename = '/home/proftpd/eicar.com' with relative filename = '/eicar.com'.
localhost (113.10.2.149[113.10.2.149]) - Clamd did not respond to fgets (2): No such file or directory
localhost (113.10.2.149[113.10.2.149]) - mod_clamav/0.11rc: Connecting to remote Clamd host '127.0.0.1' on port 3310
localhost (113.10.2.149[113.10.2.149]) - ROOT PRIVS at mod_clamav.c:227
localhost (113.10.2.149[113.10.2.149]) - ROOT PRIVS: ID switching disabled
localhost (113.10.2.149[113.10.2.149]) - PRIVS_RELINQUISH: ID switching disabled
localhost (113.10.2.149[113.10.2.149]) - Successfully reconnected to Clamd.
localhost (113.10.2.149[113.10.2.149]) - mod_clamav/0.11rc: Virus 'Eicar-Test-Signature' found in '/home/proftpd/eicar.com'
...

Sau đó e config mod_vroot (đã biên dịch cùng với mod_clamav) cho proftpd: Code:

...
  
    VRootEngine on

    VRootOptions allowSymlinks
  
DefaultRoot ~
...

Tiếp theo chạy proftpd ở chế độ debug level 10, dùng ftp client upload file virus cũ lên, proftpd có gọi clamd scan, nhưng sai path của file, nên clamd báo no such file or dir...nên ko diệt đươc Code:

...
localhost (113.10.2.149[113.160.226.149]) - mod_clamav/0.11rc: Connecting to remote Clamd host '127.0.0.1' on port 3310
localhost (113.10.2.149[113.10.2.149]) - ROOT PRIVS at mod_clamav.c:227
localhost (113.10.2.149[113.10.2.149]) - ROOT PRIVS: ID switching disabled
localhost (113.10.2.149[113.10.2.149]) - PRIVS_RELINQUISH: ID switching disabled
localhost (113.10.2.149[113.10.2.149]) - Successfully reconnected to Clamd.
localhost (113.10.2.149[113.10.2.149]) - mod_clamav/0.11rc: Clamd Error: /eicar.com: lstat() failed: No such file or directory. ERROR

...

Mình có coi qua trang này https://forums.proftpd.org/smf/index.php?topic=3768.0 Nhưng cũng chẳng biết debug cái mod_clamav như thế nào Mong mọi người giúp đỡ, đê có thể dùng mod_clamav và mod_vroot cho proftpd Xin cảm ơn

Xây dựng hệ thống HA Load Balancer Mysql Cluster

tuanksor — GMT

Còn phần nữa làm nốt đi ngtrongtri

Xin giúp đỡ lỗi barnyard2: Unable to open waldo file

tuanksor — GMT

Hi anh quanta, đã fix lỗi này Do ko tồn tại file /etc/barnyard2/barnyard2.waldo nên bị báo lỗi (nghĩ là nó tự sinh khi chạy) Thanks anh!!

Xin giúp đỡ lỗi barnyard2: Unable to open waldo file

tuanksor — GMT

Mình cài đặt Snort+Barnyard2+base với các thông số: snort-2.9.4-1: - /etc/snort/snort.conf: .... output unified2: filename snort.log, limit 128, mpls_event_types, vlan_event_types .... - /etc/sysconfig/snort: INTERFACE=eth0 CONF=/etc/snort/snort.conf USER=snort GROUP=snort PASS_FIRST=0 LOGDIR=/var/log/snort ALERTMODE=fast DUMP_APP=1 BINARY_LOG=1 NO_PACKET_LOG=0 PRINT_INTERFACE=0 SYSLOG=/var/log/messages SECS=5 barnyard2-1.9 - /etc/barnyard2/barnyard2.conf ..... config hostname: localhost config interface: eth0 config waldo_file: /etc/barnyard2/barnyard2.waldo input unified2 output alert_fast: stdout output database: log, mysql, user=root password=123456 dbname=snortdb host=localhost Snort đã chạy bình thường và đã alert vào file /var/log/snort/alert Mình chạy barnyard : barnyard2 -c /etc/barnyard2/barnyard2.conf -d /var/log/snort -f snort.log -w /etc/barnyard2/barnyard2.waldo Kết quả : .....v.v WARNING: Unable to open waldo file '/etc/barnyard2/barnyard2.waldo' (No such file or directory) Opened spool file '/var/log/snort/snort.log.1358752156' Closing spool file '/var/log/snort/snort.log.1358752156'. Read 0 records Opened spool file '/var/log/snort/snort.log.1358754263' Waiting for new data và barnyard2 cũng ko ghi gì vào db cả. nên Base cũng ko hiển thị Mong mọi người giúp đỡ

giúp đỡ biên dịch mod_suexec với INCLUDELIMITS

tuanksor — GMT

Hiện tại mình có đọc được http://docs.1h.com/Suexec#Limits Nhưng không biết cách nào để biên dịch httpd có mod_suexec với INCLUDELIMITS. Mình tìm trong file configure mã nguồn của httpd không thấy tuỳ chọn này. Mong mọi người giúp đỡ Xin cảm ơn nhiều!

xin hỏi về giới hạn resource cho mỗi virtual host apache

tuanksor — GMT

Thanks LNH đã giúp đỡ!

xin hỏi về giới hạn resource cho mỗi virtual host apache

tuanksor — GMT

Thanks LNH! Như vậy nếu chạy suexec thì việc còn lại chỉ là giới hạn cho từng user chạy php-cgi. việc giới hạn cho từng user LNH có thể nói rõ hơn đc không ạ, vì cái này mình chưa biết phải làm như thế nào?

xin hỏi về giới hạn resource cho mỗi virtual host apache

tuanksor — GMT

Thanks anh quanta và emdinoiay. Google search e có tìm ra được cái này http://httpd.apache.org/docs/current/en/mod/core.html#rlimitcpu Mọi người có thể xem qua và góp ý giúp e về cái nay đc ko ạ. Vì trình tiếng anh cũng yếu.^^

Cho mình hỏi về https trên Juniper

tuanksor — GMT

ngtrongtri đổi port management của router từ 443->4343 (port gì tuỳ thích) , rồi forwarding port 443 -> IP của máy server web https. Lưu ý là đổi port management trước khi forward port. Chứ ko là phải vào Router bằng cổng console đấy. Cấu hình trong console bạn có thể tham khảo tại http://www.fir3net.com/Juniper-SRX-Series-Gateway/juniper-srx-destination-nat-port-forwarding.html

xin hỏi về giới hạn resource cho mỗi virtual host apache

tuanksor — GMT

quanta wrote:

Đố bạn biết: Apache dựa vào cái gì trong HTTP header để chuyển một request đến đúng virtual host cần đến?

Hi anh Quanta, theo e biết thì Apache dựa vào host field (chứa domain name và port nếu khác port default) của http header để chỉ nó đến document root của virtual host.

xin hỏi về giới hạn resource cho mỗi virtual host apache

tuanksor — GMT

Cho mình hỏi là có cách nào để mình có thể chỉ định cho mỗi virtual host trong apache chỉ được phép sử dụng bao nhiêu mem, cpu không ạ. Xin cảm ơn nhiều

Xin giúp đỡ cài đặt Kloxo

tuanksor — GMT

Thansk anonymous_itop, emdinoiay nhiều. Cuối cùng cài lại centos 5 thì cài đặt được.

Xin giúp đỡ cài đặt Kloxo

tuanksor — GMT

Hiện tại mình đang cài đặt Kloxo cho Centos 6.3 32bit Mình có download script cài đặt Kloxo. Nhưng khi chạy ./kloxo-installer.sh --type=master --db-rootpassword=123 @123 thì bị lỗi Warning: RPMDB altered outside of yum. ** Found 2 pre-existing rpmdb problem(s), 'yum check' output follows: cronie-1.4.4-7.el6.i686 has missing requires of /usr/sbin/sendmail redhat-lsb-4.0-3.el6.centos.i686 has missing requires of /usr/sbin/sendmail Sau đó mình cài đặt sendmail bằng yum : yum install sendmail* và chạy lại nhưng vẫn bị lỗi trên. Nhìn lên thì thấy Removing packages sendmail sendmail-cf sendmail-doc sendmail-devel exim vsftpd postfix vpopmail qmail lxphp lxzend pure-ftpd imap... trong quá trình thực thi script. Cho mình hỏi khắc phục cách nào để cài đặt được Kloxo ạ. Vì ở trên vì remove sendmail, mà ở dưới thì requires sendmail. Mình xin cảm ơn!!

Xây dựng hệ thống HA Load Balancer Mysql Cluster

tuanksor — GMT

Bạn ngtrongtri có thời gian thì viết tiếp bài 2 nhé, để mọi người đọc nửa chừng rồi trốn thế.

Các anh cho em hỏi về car wlan trong backtrack5

tuanksor — GMT

Nếu cài máy ảo thì không máy ảo ko nhận card wireless đâu, bạn dùng usb wireless thì được.

Xin giải pháp cho hệ thống Wirte-Read Database Mysql server.

tuanksor — GMT

quanta wrote:

Thú thật là mình chưa dùng MySQL Cluster trong môi trường thật bao giờ. Bạn dùng rồi có thấy vấn đề gì không?

Thế anh dùng trên môi trưởng ảo hoá hả anh, công nhận việc ảo hoá hệ thống tiện thật