Messages posted by: tuanksor

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, smilie

. nó đúng như là cái nồi lẩu thật smilie

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

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 smilie

?

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 smilie

Thanks Ikut3 về cái tool sysdig (biết thêm 1 món smilie

)

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

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 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

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.

Code:

ls -nR > export.txt

Bạn thử dùng
Code:

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

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

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

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 smilie

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 smilie

)

http://www.mediafire.com/download/dls41n3bdk7uh76/file.zip

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 smilie

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

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 smilie

) 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 smilie

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:

...
<Global>
AllowOverwrite yes
<IfModule mod_clamav.c>
ClamAV on
ClamServer 127.0.0.1
ClamPort 3310
</IfModule>
</Global>
...

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:

...
<IfModule mod_vroot.c>
VRootEngine on
VRootOptions allowSymlinks
</IfModule>
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

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

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!!

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 đỡ

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!

Thanks LNH đã giúp đỡ!

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?

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.^^

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

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.

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

Thansk anonymous_itop, emdinoiay nhiều.

Cuối cùng cài lại centos 5 thì cài đặt được.

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!!

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ế.

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.

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