Messages posted by: prof

minhquan1712 wrote:

Em cài linux sau winXP. SAu đó, em format lại ổ C và cài lại WinXP trên ổ C, em khởi động lại thì máy nó ko còn GRUB của linux nữa mà nó tự động boot vào winXP luôn. Mong các anh giúp em với, thanks nhiều :?

Hello minhquan1712,

Bạn thử dùng chức năng "tìm kiếm" của diễn đàn và search với từ khoá "grub" xem sao. Trên diễn đàn đã có những thắc mắc và trả lời tương tự cho vấn đề của bạn rồi đấy.

Nên tìm kiếm trước khi đặt câu hỏi nhé. smilie

Thân mến.

hackermientay wrote:

Lệnh này ko ổn. đã thử rồi, vào root, gõ lệnh đó vào, monitor tắt cái cụp --> hết vô, còn cách khác ko vậy )

Hèm, như vậy bạn cần phải chỉnh sửa bằng tay một chút. Trong FC, toàn bộ thông tin cấu hình của X server được lưu trong file /etc/X11/xorg.conf (xem thêm $man xorg.conf). Hiện tại, để khắc phục vấn đề bạn nêu ra, theo tớ bạn nên tiến hành sao lưu file cấu hình này trước khi thay đổi nội dung file nhằm đề phòng bất trắc.

Tiếp theo, bạn tìm phần Screen -> DefaultDepth và thay đổi giá trị cho nó là 16 (thông thường giá trị trường này là 24). Kế tiếp, tìm trong Subsection "Display" dòng Modes để ấn định giá trị "800x600" cho độ phân giải. Trường hợp có nhiều hơn một Subsection "Display", bạn cần lựa chọn Modes của Subsection có giá trị Depth = DefaultDepth.

Lưu ý là hướng dẫn của tôi giúp bạn hiệu chỉnh độ phân giải màn hình trở về 800x600 cốt để hiển thị GUI. Bạn hoàn toàn có thể hiệu chỉnh để có được độ phân giải tốt hơn.

Code:

Section "Screen"
Identifier "Screen0"
Device "Videocard0" # Associates the video card
Monitor "Monitor0" # with this monitor
DefaultDepth 16 # Default is 16-bit colour
SubSection "Display"
Viewport 0 0
Depth 16
Modes "800x600"
EndSubSection
EndSection

Chúc thành công smilie

hackermientay wrote:

Hix, hva lần này off lâu quá, chờ sốt cả ruột
Hi vọng lần này cái diễn đàn của mình sẽ ngày càng hoạt động sôi nổi hơn, bi giờ tới việc quan trọng cho hỏi tí xiu ^ ^
Tớ đang xài Fedora Core 6, update đầy đủ rùi, chỉ tội cái màn hình nó cà tưng, lỡ chỉnh lên 1280x1024 nó vượt quá giới hạn, bi giờ ko vào dc cả GNOME, mỗi lần vào GNOME là màn hình tắt ngúm, cho hỏi ai biết cách nào chỉnh sửa lại cái "screen solution" đó bằng dòng lệnh hông, bi giờ mà cài với lại config toàn bộ chắc chít quá, đang cần gấp, mong giúp giùm :cry:

Hello hackermientay,

Bạn thử lệnh này xem sao: #system-config-display

Chúc thành công smilie

Hello ImNotTeen,

ImNotTeen wrote:

đúng rồi đó , theo mình được biết thì nhân của linux là chung nên chắc là có API của kernel của nó đúng không ?

Như bạn đã biết, linux kernel đã có nhiều thay đổi đáng kể từ phiên bản 2.0, 2.2, 2.4 và cho tới phiên bản gần đây là 2.6. Mỗi lần thay đổi như vậy, tập các hàm API của linux kernel tương ứng ít nhiều cũng bị thay đổi nhằm cải thiện, tối ưu hoá về mặt tốc độ, tăng tính ổn định cũng như nâng cao tính gọn nhẹ cho kernel. Điều đó đồng nghĩa với việc một khi bạn muốn sử dụng các hàm API của kernel, bạn nên tham khảo kỹ các hàm API tương ứng với phiên bản kernel mà bạn có ý định triển khai.

Hiện tại có khá nhiều tài liệu đề cập đến thông tin các hàm API của linux kernel. Một trong số đó, bạn có thể tham khảo tại: hxxp://kernelbook.sourceforge.net/

thứ 2 là về GUI API của linux thì thế nào ? có khác nhau giữa FC, BSD .. không ?

Vào thời điểm này, theo tớ được biết, có khá nhiều GUI Toolkit cho linux. Có thể kể đến wxWindows http://wxwindows.org/), GTK http://www.gtk.org/), Qt http://www.trolltech.com/), FLTK http://www.fltk.org/),.... Trong số này, wxWindows đang được sử dụng khá phổ biến vì khả năng hỗ trợ cross-platform của nó (Win32, Linux, MacOS, OS/2,...). Như vậy, vấn đề ở đây là tuỳ thuộc vào GUI toolkit mà bạn lựa chọn có khả năng hỗ trợ FC và BSD đồng thời hay không.

và cuối cùng là mình đang dùng FC nên muốn tìm hiểu về nó, mình có thể tìm các API của kernel và API cho lập trình GUI cho nó ở đâu ?
thanks.

Tớ đã giới thiệu một số link tương ứng ở trên. Bạn có thể vào đó tìm hiểu kỹ thêm nhé.

Chúc bạn thành công smilie

ImNotTeen wrote:

hi
cái này thực ra không phải mình viết mà là code mẫu trong mấy cái Template của KDevelop. Mới làm quen với nó nên có ví dụ nào thì thử build chạy xem sao , đến cái kia thì bị lỗi nên ko biết làm thế nào.

Hi ImNotTeen,

Rất tiếc là tớ chưa từng gặp lỗi mà bạn mô tả bao giờ. Để viết một ứng dụng GUI đơn giản như helloworld sử dụng KDevelop, bạn thử tham khảo tài liệu này xem sao (thay vì dùng template có sẵn): hxxp://www.dazzle.plus.com/linux/

À cho mình hỏi luôn là trong FC thì có cái nào tương đương như Win32API không ? Nếu có thì tìm thông tin về nó ở đâu ? Thanks bro

Câu hỏi này tớ chưa rõ ý của bạn lắm. Có phải bạn định hỏi về việc tìm thông tin các hàm API của linux kernel?

Hello ImNotTeen,

Theo tớ cảm nhận từ bài viết của bạn thì dường như bạn có ý định dùng source code đã được viết trên môi trường Windows để đem sang KDevelop biên dịch. Điển hình là tớ thấy có hàm WinMain(). Tớ nghĩ bạn nên tìm hiểu về KDevelop & Qtdesigner để viết một GUI App. đơn giản như Helloworld. Việc đem mã nguồn từ Windows (IDE VC++ chẳng hạn) sang Fedora (KDevelop) thường hay phát sinh những lỗi không tương thích về thư viện và cú pháp, khiến cho công việc debug rất mất thời gian.

Chút góp ý. smilie

goldenmice wrote:

Dung roi em bi mac loi do.! The vay gio em co cach nao khac phuc khong cac bac ?

Em cam on nhieu.!

Hi goldenmice,

Nếu bạn muốn cài đặt GRUB/LILO vào phần MBR, bạn có thể làm theo các bước sau:
- Sử dụng CD#1 của bộ Fedora mà bạn có để khởi động hệ thống,
- Tại dấu nhắc boot: bạn nhập lệnh linux rescue và Enter,
- Tiếp theo, bạn gõ lệnh: # chroot /mnt/sysimage,
- Tuỳ thuộc vào việc chọn lựa GRUB hay LILO mà bạn thực hiện tiếp các lệnh sau đây:
+ Đ/v GRUB: # grub-install /dev/hda (/dev/hda cho IDE HDD; /dev/sda cho SCSI HDD)
+ Đ/v LILO: # /sbin/lilo

Ngoài ra, bạn cũng có thể chọn cách active partition (dùng fdisk) chứa Fedora để khởi động vào Fedora. Cách này có ưu điểm là giữ nguyên MBR (không cài đè Linux Boot Loader lên MBR). Tiếp đến, bạn làm theo các bước sau đây để sử dụng Windows Boot Manager trong việc lựa chọn HĐH:
- Dùng lệnh # dd if=/dev/hda3 of=grub.bin bs=512 count=1 (giả sử /dev/hda3 là partition chứa Fedora OS) để ghi 512 bytes đầu tiên của partition chứa Fedora ra file grub.bin,
- Tiếp theo, bạn copy file grub.bin này vào thư mục gốc của phân vùng cài đặt Windows, chẳng hạn ổ đĩa C,
- Trở lại Windows, bạn tìm file BOOT.INI, thêm vào dòng c:\grub.bin="Fedora Linux" sau phần [operating systems].

Chúc bạn thành công. smilie

goldenmice wrote:

Em cai linux text(fecore3) tren partition3 va da co windows tren partition1.Khi reboot lai thi ko thay man hinh lua chon vao win hay vao linux nhu cai dat linux thuong ngay.

Ai co the chi giup em.!

Hello goldenmice,

Trong quá trình cài đặt, bạn lựa chọn cài trình Boot Loader (GRUB/LILO) trên sector đầu tiên (Boot sector) của partition 3 hay trên MBR vậy? Theo tớ biết, việc chọn lựa cài đặt trên sector đầu tiên của partition 3 sẽ khiến bạn ko nhận được màn hình tuỳ chọn HĐH khi khởi động.

huynhfxvn wrote:

em đã cài xong mọi thứ của fedora

em moi dung linux nen chua quen go lenh (đa số)

khi khoi dong em o che do text mode va em muon chuyển sang x windows cho dễ

lam on giup em !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Hello huynhfxvn,

Câu hỏi của bạn có thể hiểu theo 2 cách:
+ Sau khi khởi động vào text mode, bạn muốn chuyển sang GUI mode, thì tại dấu nhắc của hệ thống: bạn gõ lệnh startx
+ Trường hợp bạn muốn vào GUI mode ngay sau khi khởi động xong (không qua CLI mode) thì bạn cần phải tìm dòng: id:3:initdefault trong file /etc/inittab ở lần đăng nhập text mode đầu tiên, và thay bằng id:5:initdefault. Sau đó khởi động lại hệ thống.

Chúc bạn thành công. smilie

Chào các bạn,

Cá nhân tôi đồng tình với ý kiến của bạn Mr.Khoai ở trên. Chúng ta nên tập trung trao đổi, thảo luận và tìm giải pháp cho các vấn đề liên quan đến kỹ thuật hơn là quan tâm đến cấp bậc, chức tước hay một cái gì đó tương tự khi tham gia sân chơi HVA này.

Bản thân tôi cũng chỉ là một member bình thường trong HVA như các bạn mà thôi. Nếu có khác biệt thì hoạ chăng là...tôi có tên trong "tổ bảo vệ": để bên cạnh việc trao đổi, học tập thêm từ các bậc "tiền bối", thì còn phải/được kiêm thêm việc "trông nom", "quét dọn" sân chơi nhằm đảm bảo nó luôn "sạch" & "đẹp". Việc sinh hoạt đều đặn & nghiêm túc tại HVA sẽ giúp các bạn nhanh chóng có thêm việc để làm đấy. Khi đó, không biết là nên vui hay nên buồn đây. smilie

Hi vọng các bạn có những thắc mắc tương tự hiểu được ý mình nói.

Anyway, tôi cũng mong các bạn đọc kỹ lại nội dung bài viết http://www.htmlforum.net/hvaonline/posts/list/3060.html để rõ hơn, đặc biệt là các bạn hackernohat, BuRaTiNoVnO, Vickizw và girlbatcandoi.

To girlbatcandoi: nếu bạn tham gia diễn đàn HVA một thời gian nữa, tớ nghĩ bạn sẽ quay lại bài bạn vừa post để chỉnh sửa hoặc xoá nó đi đấy.

Thân mến.

Hello baby_love_crack,

Bạn có thể tham khảo các tài liệu này cho nhu cầu của mình:
hxxp://www.microsoft.com/technet/prodtechnol/isa/2000/proddocs/isadocs/cmt_h_logreject.mspx?mfr=true (for ISA 2k)
hxxp://www.microsoft.com/technet/prodtechnol/isa/2004/deployment/default.mspx (for ISA 2k4)

baby_love_crack wrote:

- Bro nào đã có kinh nghiệm Config firewall rồi thì cho em một số kinh nghiệm nhé . Hiện tại bây giờ em đang muốn làm một firewall cho mạng của mình (chỉ có 1 server và 2 Client - Học mà)
+ Lọc được các IP mình ko thích cho vào
+ Truy vấn người ở bên ngoài truy cập vào mạng bằng user và pass
+ Lưu lại những log về người truy vập và những việc họ đã làm trong mạng của mình khi mình cho người ta vào
- Có 3 cái gạch đó thôi mà nhức đầu quá . Bro nào đã làm thì post kinh nghiệm lên nhé . Hoặc ai có sách thì cho e link dow với .
Thanks all !!!!!!

Hello baby_love_crack,

Bạn định triển khai firewall loại nào? firewall "cứng" (appliance) hay "mềm" (software)? Nếu lựa chọn một trong số các firewall "cứng" như PIX/SonicWall/Netscreen/Watchguard/... thì điều trước tiên bạn cần đọc kỹ tài liệu trợ giúp và hướng dẫn đi kèm theo mỗi dòng sản phẩm.

Trường hợp bạn có ý định cài đặt một firewall "mềm" thì bạn cũng cần phải nêu rõ bạn muốn triển khai trên nền Windows hay *nix? Sơ đồ hệ thống mạng bạn định thiết kế ra sao?... Có như vậy, mọi người mới có thể giúp bạn được. Câu hỏi càng mô tả chi tiết, bạn sẽ nhanh chóng nhận được câu trả lời thoả đáng.

Thân.

vietwow wrote:

Mình mới thử dơn bản php 5 mới nhất về cài, vẫn lỗi y chang vậy T_T

Copy đoạn cuối bị lỗi lúc make cho mọi người xem :

-I/usr/include -g -O2 -prefer-non-pic -c /root/Desktop/php-5.1.4/sapi/apache/sapi_apache.c -o sapi/apache/sapi_apache.lo
/root/Desktop/php-5.1.4/sapi/apache/sapi_apache.c: In function 'apache_php_module_main':
/root/Desktop/php-5.1.4/sapi/apache/sapi_apache.c:44: error: 'NOT_FOUND' undeclared (first use in this function)
/root/Desktop/php-5.1.4/sapi/apache/sapi_apache.c:44: error: (Each undeclared identifier is reported only once
/root/Desktop/php-5.1.4/sapi/apache/sapi_apache.c:44: error: for each function it appears in.)
make: *** [sapi/apache/sapi_apache.lo] Error 1

Chẳng lẽ là do lỗi của thằng apache ?

Hello vietwow,

Bạn thử thêm các dòng sau vào file include/httpd.h của Apache rồi compile lại xem nhé.
Code:

#define DOCUMENT_FOLLOWS HTTP_OK
#define PARTIAL_CONTENT HTTP_PARTIAL_CONTENT
#define MULTIPLE_CHOICES HTTP_MULTIPLE_CHOICES
#define MOVED HTTP_MOVED_PERMANENTLY
#define REDIRECT HTTP_MOVED_TEMPORARILY
#define USE_LOCAL_COPY HTTP_NOT_MODIFIED
#define BAD_REQUEST HTTP_BAD_REQUEST
#define AUTH_REQUIRED HTTP_UNAUTHORIZED
#define FORBIDDEN HTTP_FORBIDDEN
#define NOT_FOUND HTTP_NOT_FOUND
#define METHOD_NOT_ALLOWED HTTP_METHOD_NOT_ALLOWED
#define NOT_ACCEPTABLE HTTP_NOT_ACCEPTABLE
#define LENGTH_REQUIRED HTTP_LENGTH_REQUIRED
#define PRECONDITION_FAILED HTTP_PRECONDITION_FAILED
#define SERVER_ERROR HTTP_INTERNAL_SERVER_ERROR
#define NOT_IMPLEMENTED HTTP_NOT_IMPLEMENTED
#define BAD_GATEWAY HTTP_BAD_GATEWAY
#define VARIANT_ALSO_VARIES HTTP_VARIANT_ALSO_VARIES

Lưu ý: bạn thêm phần này vào ngay sau phần #define cho httd response code nhé (sau line 485).

Chúc bạn thành công smilie

hack2prison wrote:

Tớ không nghĩ networksolution.com có lỗi nghiêm trọng vậy đâu. Cái này có thể do bất cẩn bị nó chôm pass email rồi forgot password đây. Bởi vì nếu thực sự netsol bị lỗi thì thằng ku háo danh này phải chơi microsoft.com đầu tiên, cũng ở netsol mà

trojon wrote:

Mình cũng nghí đây là một lỗi bấ cẩn ,networksolution.com nếu có bug thì không chỉ có HVA bị mất domain như vậy đâu

Ok, các bạn cứ tiếp tục...nghĩ nhé.

Topic closed!

777 wrote:

Bài toán thứ 4 : Cái này thì mình học hỏi anh em sau vậy, xét về mặt cấu hình cho nó thì tớ thấy 1.x nó cấu hình dễ dàng hơn 2.x còn các mặt khác thì học hỏi anh em sau vậy .

Nói 1 cách tổng quát thì em nhận định 1.x và 2.x mổi cái có điểm mạnh / điểm yếu của nó (về mặt tính năng ) cho nên khi anh chọn 1 trong 2 thì nên chọn version theo mục đích của anh thì sau này dể phát triển theo hướng của anh hơn . (dạo này không theo dõi tin nên không chắc nó có kết họp và mở rổng tính năng hay không , anh tham khảo thêm trong trang chủ của nó nha )

Hẹn gặp anh tại thread : Cấu hình Apache :lol:

Chào cả nhà,

Thấy mọi người thảo luận sôi nổi quá, prof cũng xin được "ké" vài dòng về vấn đề phiên bản của Apache.

Như mọi người đều đã biết, Apache có 2 series: 1.3.x và 2.0.x. 2 dòng Apache này hiện vẫn cùng tồn tại song song nhưng khác nhau cơ bản về kiến trúc và cơ chế làm việc.

Trên các hệ thống Unix, Apache 1.3 đóng vai trò như một Process-based Web server. Theo đó, phiên bản này fork rất nhiều các tiến trình con ngay khi khởi động. Fork ở đây là quá trình tạo ra các tiến trình con giống hệt nhau từ một tiến trình cha. Mỗi tiến trình con đều có khả năng xử lý các yêu cầu một cách độc lập. Điều này làm tăng tính ổn định cho hệ thống. Một sự đổ vỡ của bất kỳ một trong số các tiến trình con nào đó đều không ảnh hưởng đến các tiến trình còn lại. Tuy nhiên, để có sự ổn định này, hệ thống phải "trả giá" về mặt hiệu năng. Đối với hầu hết các hệ thống Unix, việc tạo các tiến trình con và chuyển đổi ngữ cảnh giữa các tiến trình (cung cấp thời gian xử lý của processor cho mỗi tiến trình) đều bị coi là các thao tác gây tốn kém tài nguyên hệ thống. Lý do vì các tiến trình độc lập hoàn toàn với nhau, chúng không thể chia sẻ phần bộ nhớ dữ liệu và mã lệnh cho nhau, điều đó làm tiêu tốn nhiều tài nguyên của hệ thống.

Apache 1.3 cũng là phiên bản đầu tiên có hỗ trợ cho các hệ thống sử dụng HĐH Windows mặc dù phiên bản này chưa đạt được sự ổn định cần thiết so với phiên bản chạy trên nền Unix. Apache 1.3 được thiết kế dưới dạng các module. Người dùng hoàn toàn có thể enable hoặc disable những module mà họ cảm thấy không thực sự cần thiết. Bên cạnh các module có sẵn, hiện nay có một số lượng lớn các 3rd-party modules, người dùng có thể sử dụng chúng vào các mục đích riêng nếu cần.

Apache 2.0 được xem là dòng mới nhất tính tới thời điểm này. Về mặt kiến trúc, chúng có sự cải tiến đáng kể so với Apache 1.3 series. Theo đó, Apache 2.0 có thể tuỳ biến để chạy dưới chế độ process-based server, hoặc hoàn toàn là một thread-based server hoặc thậm chí là sự hỗn hợp giữa 2 chế độ trên. Các thread (tạm dịch: luồng, tuyến) chạy dưới nền các tiến trình và hoạt động đồng bộ với nhau. Không giống như process (tiến trình), thread có thể chia sẻ vùng nhớ dữ liệu (data) và vùng nhớ mã lệnh (code). Do đó, thread chiếm dụng ít tài nguyên hơn so với process và trong hầu hết các trường hợp, một thread-based server hoạt động mềm dẻo hơn so với một process-based server. Tuy nhiên, điểm yếu của nó là tính không ổn định bởi vì khi một thread nào đó bị sự cố, chúng sẽ làm ảnh hưởng tới phần code & data thuộc về các thread khác.

Chi tiết hơn về tính tương thích, hiệu năng và bảo mật của Apache, mọi người có thể tham khảo thêm tại đây:
http://www.tldp.org/HOWTO/Apache-Overview-HOWTO-2.html

Mến.

hyha wrote:

Chào mọi người, mình muốn hỏi về đóng gói sản phẩm trong Linux. Theo mình hiểu sơ sơ thì thường là một chương trình trong Linux nó gồm nhiều file cài đặt, Make file có vai trò như setup.exe trong Windows phải ko? Mình muốn hỏi:
- Quy trình xây dựng một chương trình dạng source như vậy ra sao? (Ý mình muốn nói đến chương trình mà khi cài thường là phải ./configure, make, make install ... đó)
- Nếu muốn đóng gói dạng binary như rpm chẳng hạn thì mình dùng cách nào?

Thanks

Hello hyha,

Để tìm hiểu cách đóng gói một chương trình cung cấp dưới dạng source, bạn có thể tham khảo tài liệu này:
http://www.airs.com/ian/configure/configure_toc.html

Nếu muốn đóng gói phần mềm dưới dạng rpm, bạn tham khảo tại đây:
http://www.tldp.org/HOWTO/RPM-HOWTO/index.html

Thân.

Trưa 27/04/2005
Cả sáng nay lại bao nhiêu là công việc dồn dập. Tôi đang ở giai đoạn cao điểm của một số công trình ở công ty nên chẳng lấy được bao nhiêu thời gian để tiếp tục với mớ luật còn lại cho HVA forum. Mãi đến trưa, tôi lại tiếp tục vừa ăn trưa, vừa log vào server HVA để làm nốt phần dang dở.

Sau mười phút, tôi hoàn tất phần còn lại mà tôi bỏ dở tối qua. Kiểm tra lại một lần cuối tôi tháo bỏ phần ứng dụng trong .htaccess mà JAL đặt vào tối hôm qua để bắt người dùng phải đăng nhập. Sau khi restart lại apache, tôi phóng ngay một "tail" trên console để theo dõi log của web server, tôi thích thú khi thấy 100% các cú GET và POST kỳ quặc kia bị khựng lại và được "wwwect" về lại trang index.html nếu chúng không thoả mãn các điều kiện áp đặt. Tôi thở phào nhẹ nhõm khi thấy mớ luật tuy chưa được "debug" một cách trọn vẹn nhưng làm việc khá tốt. Tôi biết chắc đâu đó vẫn còn những điểm phải điểm xuyết; nhưng trước mắt, tình hình có vẻ sáng sủa hơn rất nhiều. Server load giữ ở mức y hệt như khi "ép" các request xuyên qua cổng 443.

Vài phút trôi qua, nỗi lo ngại mà tôi đoán trước từ từ lộ rõ. Bạn còn nhớ tôi nhận định thế này: "Trong khi thao tác các bước cần thiết để tạo thêm lớp "vỏ" này, tôi đã ngầm e ngại một "triệu chứng phụ" sẽ xảy ra. Triệu chứng này không thể làm cho máy chủ HVA treo vì cạn kiệt tài nguyên nhưng lại có thể không cho người dùng truy cập vào diễn đàn HVA." Tôi nhận thấy vận tốc truy cập đến HVA càng lúc càng chậm mặc dù server load vẫn rất thấp, vẫn giữ ở mức không quá 2.0. Tôi đoán ra được chuyện gì nhưng muốn kiểm chứng. Một lệnh sau đã xác thực thắc mắc của tôi:
Code:

# ps -ef | grep httpd | wc -l
1386

Con số trên cho thấy điều gì? Nó cho thấy rằng apache cực kỳ bận rộn. Hiện apache đã tạo ra đến 1386 processes (vì HVA dùng prefork model cho apache để chạy với php). Cũng may là tôi đã "lo xa" khi biên dịch lại apache, giá trị "MaxClients" đã được sửa thành 4096, tức là gấp 16 lần con số mặc định (và được apache "hard coded" trong mã nguồn). MaxClients vẫn còn dư để phục vụ cho requests nhưng các request lại chậm vì sao? Tôi đoán rằng apache phải tạo ra các child process liên tục nhằm đáp ứng tình trạng đang bị DoS căng thẳng này. Có ba yếu tố chính trong cấu hình của apache khiến cho con số "MaxClients" này gia tăng nhanh chóng:
- MinSpareServer là 2
- MaxRequestPerChild là 500
- KeepAliveTimeOut là 15

Cứ mỗi khi một ChildProcess đã phục vụ xong 500 request, nó tự động bị hủy và một ChildProcess khác được tạo ra (để tránh tình trạng bị memory leak). Khi một ChildProcess mới được tạo ra, thêm 2 ChildProcess dự phòng khác cũng được hình thành vì nếu không có sẵn, lúc ấy apache phải tạo nó để phục vụ. Trong khi ChildProcess được tạo, apache không tiếp nhận request. Rõ ràng con số 500 cho MaxRequestPerChild không thích hợp vì trong tình trạng bị DoS thế này, chẳng mấy chốc sẽ đụng tới giới hạn này và công tác tạo ChildProcess mới lại xảy ra. Sở dĩ con số này rất lớn là vì tôi ấn định MinSpareServer nhưng không ấn định MaxSpareServer vì tôi thấy rằng để cho apache tự động điều tác việc này tốt hơn, apache biết rõ nó cần có bao nhiêu ChildProcess dự phòng tuỳ tình hình. Có lẽ trong tình trạng nhận request dồn dập này, apache đã tạo ra tối đa vài chục "spare" nên con số 1386 không có gì đáng ngạc nhiên. Con số KeepAliveTimeOut có giá trị là 15 giây quả là thoải mái và nó tạo hiệu xuất cho hoàn cảnh bình thường (không bị DoS) nhưng trong hoàn cảnh hiện tại, nó kéo dài thời gian socket ở tình trạng TIME_WAIT vì cần bảo đảm dữ liệu từ mỗi đầu truy cập đã hoàn toàn chấm dứt.

Đối với một webserver bình thường, không bị DoS, giá trị ấn định trên khá thích hợp vì nó bảo đảm không bị memory leak, nó luôn luôn có ít nhất là 2 ChildProcess dự phòng để liên tục nhận request. Tuy nhiên, rõ ràng nó không còn ứng hiệu trong tình trạng DoS "hợp lệ" này. Tôi không muốn các ChildProcess được tạo ra quá nhanh và quá nhiều, bởi thế, con số MaxRequestPerChild được chỉnh thành 20000.

Tôi restart lại apache và tiếp tục theo dõi tình hình. Quả có cải thiện nhưng vẫn chưa thật sự nâng cao tốc độ truy cập đến mức bình thường. Tôi chạy liển hai lệnh để xem tình hình các sockets thế nào:
Code:

# netstat -nat | grep WAIT | wc -l
13079

Ôi chao! Chưa từng thấy trên máy chủ HVA bao giờ. Lý do tại sao nhiều TIME_WAIT và FIN_WAIT đến thế? Thế này, khi "x-flash" còn nhận diện được, phần lớn chúng đã bị "triệt" một cách im ắng từ IP layer. Số còn lại có đụng phải mod_security cũng không nhiều đến nỗi phải dồn đống như thế. Hơn nữa trận tấn công này hình như nặng nề và dồn dập hơn trước.

Tôi thử thêm một cách khá nhanh và.... "dơ" để "bắt" những gói SYN đi đến cổng dịch vụ HTTP -62-:
Code:

/usr/sbin/tcpdump tcp[13] == 2 and port 80 > numsyn

Tôi cho lệnh này chạy chừng một phút rồi ngừng. Mở hồ sơ "numsyn" này ra bằng vi, tôi nhanh chóng xác định trong 60 giây qua có bao nhiêu cú SYN đi vào. Lúc này HVA nhận chừng trên 2000 cú SYN một giây vì hồ sơ "numsyn" ở trên cho tôi biết có gần 130 ngàn dòng được lưu trong 1 phút vừa qua. Điều tôi có thể xác thực 100% là máy chủ HVA bị vướng trong tình trạng nhận quá nhiều requests và tạo quá nhiều sockets nhưng không thể giải toả chúng kịp thời và nhịp nhàng. Nếu apache dùng giá trị mặc định cho MaxClients là 256 thì có lẽ lúc này chẳng có ai có thể vào diễn đàn. Vậy, điều cần phải giải quyết hiển nhiên là giải toả mớ sockets đang dồn đống kia. Không may là giờ ăn trưa của tôi đã hết từ lâu. Tôi không thể tiếp tục ngồi táy máy với HVA server vì hàng đống công việc đang chờ đợi tôi. Tôi lẩm bẩm "thôi để chiều nay hoặc tối nay xem sao" và logoff HVA server.

Chiều 27/04/2005
Tôi vừa xong một cuộc họp ở công ty. Có chỉ thị tạm ngưng công trình vì cần phải điều chỉnh lại một số yêu cầu từ đám kinh tế. Điều này có nghĩa là tôi có thêm ít thời gian chiều nay để tiếp tục táy máy với máy chủ HVA. Sau khi thu xếp xong giấy tờ và cập nhật thông tin, dữ kiện cho công trình, tôi tiếp tục bắt tay vào việc khắc phục tình trạng socket dồn ứ trên máy chủ HVA.

Log vào HVA server, tôi thấy tình hình y hệt trưa hôm nay, có nghĩa là các cú "x-flash" vẫn đổ dồn vào bốn vị trí:

- GET /
- POST /
- GET /forum/
- POST /forum/index.php

và số lượng TIME_WAIT + FIN_WAIT vẫn dồn đống. Tất nhiên là thế vì chưa hề có thay đổi xác đáng nào để khắc phục tình trạng này. Tôi mở cấu hình của apache ra xem lại và ngạc nhiên khi thấy giá trị KeepAliveTimeOut vẫn còn là 15 giây. Có lẽ lúc trưa tôi đãng trí và chưa điều chỉnh nó. Tôi sửa ngay giá trị này thành 5 giây. Stop apache, đợi cho mọi socket trên máy chủ hoàn toàn chấm dứt (không còn TIME_WAIT và FIN_WAIT nào nữa), rồi mới start apache.

Cứ mỗi phút tôi "đo" số lượng "WAIT" socket một lần và sau năm phút, số lượng "WAIT" socket nằm ở vị trí trên dưới 3000 và giữ lại ở mức độ này:
Code:

# netstat -nat | grep WAIT | wc -l
3350

Theo tôi, bấy nhiêu đã là một cải thiện lớn lao. 5 giây để duy trì socket ở tình trạng "WAIT" bảo đảm thông tin ở hai đầu truy cập (giữa client và apache server trên máy chủ HVA) hoàn toàn kết thúc để tránh tình trạng mất dữ liệu theo tôi là quá đủ. Lý do tôi dùng giá trị này vì tôi chưa hề thấy thời gian chuyển gởi thông tin giữa máy chủ HVA và trình duyệt nào đó quá 3 giây (dựa trên thông tin tôi sniff và thử nghiệm). Thay đổi này đã cắt bỏ một số lượng rất lớn các "WAIT" socket làm đình trệ máy chủ. Tuy nhiên, tôi vẫn chưa hoàn toàn hài lòng vì con số trên dưới 3000 kia có thể gia tăng dễ dàng nếu số lượng x-flash gia tăng.

Tôi quyết định làm một thử nghiệm nhỏ bằng cách chạy 2 sniffers một lượt (dùng tcpdump trong trường hợp này), một cái chạy trên máy chủ HVA, một cái chạy trên chính proxy server tôi dùng để truy cập HVA (bạn còn nhớ tôi dùng ssh tunnel để truy cập từ sở về nhà và dùng proxy server ở nhà mà tôi đề cập trong một bài ký sự nào đó trước đây?). Thêm một console nối vào HVA server để theo dõi giá trị trên /proc/net/ip_conntrack -63-. Cả 2 sniffer này đều sniff cổng 80 và sniff host IP chính là IP của proxy server tôi dùng. Khi mọi việc đã chuẩn bị xong, tôi dùng Firefox để duyệt HVA một cách bình thường (như một người dùng bình thường), có nghĩa là bao gồm bước logon, và duyệt xuyên dăm ba topic.... Sau vài phút, tôi ngừng cả 2 sniffer và thu thập cả hai hồ sơ được sniff trên 2 vị trí.

Mang chúng về laptop, tôi bắt tay vào phân tích (dùng Ethereal). Điều tôi cần phân tích ở đây không phải là vận tốc truy cập mà tôi muốn tìm hiểu giữa server và client mất bao lâu để triệt tiêu socket sau khi cuộc truy cập hoàn tất. Tôi cần 2 hồ sơ từ hai phía để đối chiếu và nắm chắc là chúng hoàn toàn ăn khớp. Điều quan trọng tôi thấy được từ các mảnh packets được sniff ở trên là: từ lúc HVA server gởi gói tin có mang FIN bit (để báo cho trình duyệt của tôi là dữ liệu sau gói tin này là hết, không còn gì để cung cấp nữa) cho đến khi trình duyệt tôi dùng tiếp nhận dấu hiệu FIN này bằng cách trả lời FIN-ACK chỉ mất chưa tới 1 giây. Sau đó, socket trên HVA server đi vào tình trạng "TIME_WAIT" và duy trì tình trạng này khá lâu trước khi đi vào tình trạng CLOSED. Đây chính là nguồn gốc của hàng đống "WAIT" socket nằm trên HVA server.

Để kiểm nghiệm, tôi thử duyệt HVA bằng FireFox một lần nữa và theo dõi thông tin cụ thể IP của proxy server tôi dùng trên /proc/net/ip_conntrack lẫn thông tin trên netstat lấy được trên HVA server. Quả thật, trọn bộ giai đoạn thiết lập connection cho đến khi connection kết thúc ứng hiệu với giá trị KeepAliveTimeOut trên apache. Tuy nhiên, "connection tracking table" của netfilter "giữ riệt" socket này ở dạng "TIME_WAIT" đến những 120 giây trước khi hủy bỏ nó. Thật ra sự áp đặt này của "conntrack table" của netfilter chẳng có gì sai quấy cả. Dụng đích của nó là chờ để bảo đảm connection phía client (trình duyệt) hoàn toàn chấm dứt để tránh tình trạng "treo". Không may, ở tình trạng bị DoS dồn dập, cơ chế bảo đảm các "state" của một tcp connection lại tạo đình trệ và ảnh hưởng không tốt đến máy chủ.

Tôi vào /proc/sys/net/ipv4/netfilter/ và điều chỉnh trọn bộ giá trị ở đây. Cắt giảm thời gian "đợi" từ 1/2 đến 2/3 thời gian quy định theo mặc định. Nên nhớ, các giá trị này được ứng hiệu "on the fly" (ngay lập tức mà không cần stop / start gì cả). Một phút sau, số lượng "TIME_WAIT" trở thành:
Code:

# netstat -nat | grep WAIT | wc -l
983

Thêm 2/3 các "WAIT" sockets được giảm thiểu! Ngay lúc này, duyệt diễn đàn HVA nhanh hơn rõ. Tôi không dám mong đạt được ở mức bình thường vì thật sự HVA đang bị DoS dồn dập; có lẽ không nên ngớ ngẩn mà mong đợi kết quả không tưởng như thế. Vậy, việc điều chỉnh các giá trị trên hồ sơ cấu hình của apache và kernel dính dáng gì đến trang index.html được áp đặt kia? "tôi chẳng thấy sự tương quan rõ rệt chỗ nào cả!", bạn có thể hỏi câu này. Thật sự chúng liên quan trực tiếp và chặt chẽ với nhau. Ứng dụng "lọc" mọi request không thoả mãn quy định sẽ "bị" quay về lại index.html đột nhiên gia tăng công việc ở tầng application cũng như gia tăng số lượng sockets. Thay vì các gói tin vi phạm được nhận diện và triệt tiêu ở ngay tầng IP (và bởi thế không có tình trạng các "WAIT" socket nằm vất vưởng), các gói tin "vi phạm" được cản lọc trên tầng application vì chúng chẳng có đặc điểm "vi phạm" nào cả. Những chỉnh lý trên cấu hình apache và trên kernel ở đây đều phục vụ cho một mục đích duy nhất: giải phóng các sockets càng nhanh càng tốt để có thể tiếp tục phục vụ.

Tôi log vào YIM và gởi cho JAL một thông điệp: "bồ duyệt thử HVA xem sao?". Một phút sau, JAL hồi báo: "Ngon lắm rồi đó lão, chạy vù vù!". Tôi đáp: "vậy thì tớ dzọt đây!" và tôi logoff.

Tối 27/04/2005:
Tối nay, khi duyệt diễn đàn HVA, tôi va vào một trở ngại khác. Tôi vào HVA được nhưng gặp tình trạng khựng lại trên trình duyệt và thỉnh thoảng tôi phải nhấn nút "Stop" rồi thử bấm trên đường dẫn tôi muốn duyệt thì trang web mới load. Tôi không tin đây là trục trặc trên trình duyệt của tôi mà có lẽ là một vấn đề "bí ẩn" nào đó trên máy chủ HVA.

Log vào máy chủ HVA xuyên qua SSH (một cách dễ dàng), tôi nhận thấy ngay là server load rất thấp, số lượng ChildProcess của apache đang chạy cũng ở mức chấp nhận được (dù đang bị DoS), số lượng "WAIT" sockets nằm ở mức trên dưới 1000. Đo thử số lượng SYN mà máy chủ HVA nhận (và tạo) trong một giây, tôi thấy con số này gia tăng lên khoảng gần 4000 SYN / 1 giây. Kiểm tra thử số lượng ESTABLISHED socket là bao nhiêu, tôi thấy nó liên tục nằm ở mức 127 - 128. Một ý nghĩ loé nhanh trong đầu, tôi kiểm tra ngay một giá trị cực kỳ quan trọng:
Code:

# cat /proc/sys/net/core/somaxconn
128

và rồi:
Code:

# netstat -nat | grep SYN
128

Điều này chứng tỏ gì đây nhỉ? Máy chủ HVA đã dùng tối đa số lượng socket tiếp nhận SYN cho phép. Lạ nhỉ? HVA firewall có phần cản lọc SYN FLOOD cơ mà? smilie

. Đúng là như vậy nhưng phần cản lọc này trở nên khá hạn chế khi HVA server "bị" trên 500 IP cùng "rải" ít nhất 1 đến 5 cái SYN cho mỗi giây. Nếu các IP này "rải" với tầng số như vậy thì hẳn HVA firewall cho vào vì chúng không mang dấu hiệu SYN FLOOD ở đâu cả. Cứ cho rằng có 500 IP chỉ gởi 2 request cho mỗi giây vào HVA server, và nếu phía client trả lời nhanh chóng sau khi HVA server trả lời SYN-ACK thì cũng mất 1/5 giây thì:

1000 SYN * 0.2 giây = 200 syn cho mỗi giây

Lúc nào listen() -64- cũng bị quá giới hạn:
200 - 128 = 72 SYN (đứng chờ)

thì tất nhiên khi người dùng duyệt HVA phải bị chậm hoặc khựng lại. Một khi xuất truy cập đã hình thành thì thông tin được chuyển tải rất nhanh bởi vì xuất truy cập này đã ở tình trạng "ESTABLISHED" trên tcp.
Vậy somaxconn dính dự gì đến listen()? Hẳn nhiên rồi, và còn dính trực tiếp nữa là đằng khác. somaxconn chính là int thứ ba của hàm listen() (đã chú thích ở -64-). Hiện tại, giá trị somaxconn trên HVA server rất thấp và chắc chắn không đủ để phục vụ các request (kể cả hợp lệ lẫn "bất hợp lệ"). Cứ 128 SYN gởi vào thì có lẽ hơn 99% là các cú "x-flash" tham lam kia chiếm lấy, những request hợp lệ của người dùng bình thường hẳn phải đi vào hàng đợi để tuần tự được truy cập --> chậm. Nếu đợi lâu --> timeout, trình duyệt sẽ được báo lỗi là "host is not contactible" hay đại loại như vậy.

Giải pháp? tất nhiên là phải gia tăng giá trị somaxconn. Không những thế, giá trị "syn_backlog" cũng phải được gia tăng (đến mức độ thích hợp mà lượng memory trên hệ thống cho phép) với mục đích:
- gia tăng cơ hội (tỉ số) người dùng hợp lệ được phép truy cập.
- gia tăng thời gian cho phép các request "bị" đưa vào hàng đợi "backlog" có điều kiện đợi mà không bị timeout (và nhận error).

Bạn có thể hỏi: "tại sao trước giờ HVA bị DDoS sao không bị trường hợp này mà mãi đến bây giờ mới phát hiện?". Câu trả lời thế này: chuyện này đã xảy ra trước đây nhưng lại tái diễn vì hai lý do:
1. các giá trị ứng dụng và được điều chỉnh trên kernel thực hiện trên máy chủ cũ (cấu hình kém hơn) trước đây đã không được mang qua máy chủ mới một cách trọn vẹn.

2. khi mang qua, một số giá trị quan trọng đã không ứng dụng toàn thời trong /etc/sysctl.conf mà chỉ ứng dụng ở dạng:
# cat <n> > /proc/sys/net/ipv4/whatever_param
loại thay đổi "ad-hoc" này sẽ bị xoá mất và giá trị mặc định sẽ được dùng sau khi server được reboot.

Phải nói rằng, đây là một chểnh mảng của tôi. Chểnh mảng ở chỗ, tôi nghĩ rằng nó đã được ứng dụng và không buồn xem lại và đợi đến khi lâm vào tình trạng khó khăn rồi mới đi xuyên qua các bước thử nghiệm để tìm lý do.

Sau khi ấn định lại giá trị somaxconn gấp ba lần giá trị trước đây và xem xét kỹ lưỡng các giá trị khác trên kernel. Tôi tạm ngưng apache và khởi động lại nó sau vài giây. Bạn đã đoán ra: truy cập HVA nhanh hơn và dễ dàng hơn cho dù vẫn còn đang bị DoS.

Giá phải trả cho chuyện này là "lão JAL phải mua thêm RAM" smilie

(j/k JAL, RAM trên server còn dư dùng, nhưng nếu được thì nên chuẩn bị thêm một server nữa nếu DDoS biến thái ).

Chú thích:
-62- tcpdump cho phép "bắt" những gói tin ở dạng cụ thể dựa trên bit nào được set trên tcp flags. Nếu sử dụng nó đúng mức, tcpdump là một công cụ đa năng và không thể thiếu trong việc bắt và phân tích các gói tin. Xem thêm chi tiết các chọn lựa cho tcpdump bằng man page của nó: $ man tcpdump.

-63- /proc/net/ip_conntrack giá trị biểu thị tình trạng (state) của các connection đang được netfilter theo dõi trên hệ thống. Muốn biết thêm chi tiết, xin tham khảo các tài liệu liên hệ trên website http://www.iptables.org

-64- listen() queue. Để tiếp nhận một connection, socket phải được tạo ra và phải ở tình trạng sẵn sàng tiếp nhận truy cập và hàm listen() được dùng để áp đặt giới hạn bao nhiêu truy cập dịch vụ có thể cung cấp. Hàm listen() còn có thêm một tham số khác trực tiếp giới hạn số lượng "backlog connection", có nghĩa là nó quy định con số bao nhiêu connection được đứng trong hàng đợi để chờ lượt mình truy cập. listen() có hai tham số:
int listen(int s, int backlog);, trong đó s là integer ấn định giới hạn bao nhiêu connection được cho phép và backlog là integer ấn định giới hạn "hàng đợi" chứa bao nhiêu request chờ được tiếp nhận.
Xem thêm man socket, man listen và các tài liệu cụ thể cho socket programming trên Linux để nắm thêm chi tiết.