Khả năng bảo trì được của Kernel Linux P2.

5. KẾT QUẢ

 

Báo cáo kết quả của các tác giả khá chi tiết và phức tạp nên tôi không trình bày ra đây (chủ yếu chỉ là công thức, cách tính giá trị, làm tròn, vẽ biểu đồ … ). Sau đây là một số kết quả hiển thị trên biểu đồ.

 

Các common coupling thống kê được biểu diễn bằng đường đứt nét còn các đường dự báo couling được biểu diễn bằng đường liền nét. Các tên ví dụ Sys.c, printk.c là tên các file được khảo sát.

 

 

 

 

 

5.1 Lines of Code

 

Đường biểu diễn của lines of code (LOC) trên biểu đồ gần như là một đường thẳng tuyến tính với version numer.

 

5.2 Common Coupling

 

Một điều thể hiện rõ trên biểu đồ là đường biểu diễn common coupling của các module tăng theo dạng hàm mũ theo version number.

 

6. KẾT LUẬN

 

Sau khi làm những công việc khá “cày cuốc” như trên, họ rút ra hai kết luận chủ yếu sau đây:

 

Đầu tiên là phát hiện ra phụ thuộc tuyến tính giữa LOC và version number với độ chính xác đến 99.99%; 95.1% trong sự phụ thuộc đó có thể giải thích bởi ba tác động: version number, module và sự tương tác giữa chúng. Nói cách khác, số LOC trong mỗi kernel module tăng tuyến tính với version number, và không cần giải thích gì thêm nữa; đó là một đặc tính thừa kế của các successive version của Linux. Kết quả này cũng không gây ngạc nhiên, vì suy cho cùng các phiên bản kế tiếp của Linux cung cấp nhiều chức năng hơn nên code nhiều hơn cũng là hợp lý.

 

Thứ hai là phát hiện sự tăng theo dạng mũ giữa số common coupling với version number. Kết quả này cũng chính xác đến 99.99%. Trong trường hợp này, 94.6% có thể được giải thích bởi ba tác động: version number, module, và tương tác giữa chúng. Có nghĩa là, đường biểu diễn dạng mũ đó lại là đặc tính thừa kế của successive versions của Linux.

 

Trong phần 2, ta đã thấy được sự liên quan giữa common coupling và fault-proneness. Do đó, kết hợp với 2 kết quả các tác giả trên vừa thu được ta thấy một điều đáng lo ngại: Mặc dù số LOC trong kernel chỉ tăng tuyến tính, số thể hiện của common coupling giữa mỗi kernel module và tất cả các module khác của Linux lại tăng theo dạng mũ. Giả sử mỗi dòng lệnh được thêm vào một kernel module là một lời gọi đến một module khác, thì số thể hiện common coupling mới xuất hiện cũng chỉ được phép tăng theo dạng tuyến tính. Nhưng vì đặc tính clandestine common coupling đã được đề cập ở trên, common coupling tăng theo dạng mũ!

 

Common coupling đã xuất hiện trong Linux ngay từ những ngày đầu, và chẳng có gì phải nghi ngờ là nếu không được xây dựng lại với số common coupling tối thiểu thì trong tương lai nó sẽ tăng không hề chậm lại. Để có thể xây dựng lại một sản phẩm khổng lồ như vậy có nghĩa là việc phát triển Linux sẽ phải đình trệ trong nhiều tháng cho đến khi hòan tất việc “thay máu”. Mặt khác, nếu không tiến hành việc xây dựng lại thì vào 1 ngày nào đó, sự phụ thuộc giữa các module được common coupling tạo ra sẽ làm cho Linux rất khó để thay đổi một phần mà không tạo ra lỗi regression (tạm dịch là hồi quy) nằm đâu đó trong sản phẩm mà nhìn bên ngòai thì có vẻ chẳng liên quan gì đến. Kết quả là nếu đợi đến lúc đó mới xây dựng lại thì thậm chí công việc phải làm còn lớn hơn nhiều!

 

Nói chung, những thí nghiệm và kết luận trên có chiều hướng nghiêng về ủng hộ cho ý kiến của Ken Thompson. Tuy nhiên, không như những ý kiến “vô thưởng vô phạt” mà đại đa số người dùng đưa ra để bài xích Linux, các tác giả đã chỉ ra là những vấn đề về lâu dài của Linux có thể được ngăn chặn ngay từ bây giờ bằng cách tổ chức lại theo hướng giảm common coupling đến tối thiểu, và phải có một chế độ theo dõi cẩn thận để bảo đảm không xuất hiện thêm thể hiện nào của common coupling sau khi thực hiện việc tái tổ chức.

 

Đây cũng là một vấn đề chung cần được quan tâm trước khi quá muộn của tất cả các phần mềm mã nguồn mở.

 

 

Sun,Aug,14,2005

Đông Thao

 

 

Tài liệu tham khảo

 

Maintainability of the Linux Kernel — Stephen R. Schach, Bo Jin, David R. Wright, Gillian Z. Heller, A. Jefferson Offutt

Khả năng bảo trì được của Kernel Linux P1.

1.Giới thiệu

 

Đã có rất nhiều bài báo, bài viết chỉ ra rất nhiều điểm ưu việt của Linux, một hệ thống mã nguồn mở. Nhưng cũng có một số lượng tương đương như thế những lời chỉ trích, vạch ra những yếu kém của Linux. Tôi chỉ nêu ra ý kiến của Ken Thompson (một trong số những tác giả của UNIX) đã viết trên tạp chí IEEE Computer số tháng 5 năm 1999:

 

“… Tôi không nghĩ là Linux về lâu dài sẽ thành công. Tôi đã đọc mã nguồn và thấy là có những đoạn viết tốt và có những đoạn thì không tốt. Một nhóm người ngẫu nhiên đã đóng góp cho mã nguồn này, và chất lượng thì cũng khác nhau thấy rõ. Với kinh nghiệm của tôi và một số bạn bè tôi thì Linux hoàn toàn không đáng tin cậy. Microsoft thật sự là không thể tin cậy được, nhưng Linux còn tệ hơn. Trong một môi trường không phải là máy cá nhân, vấn đề chẳng có gì to tát. Nhưng nếu bạn muốn dùng Linux làm firewall, gateway, hệ thống nhúng, … thì vẫn còn nhiều thứ phải làm lắm…”

Một điều quan trọng trong phát biểu của Thompson là “Tôi đã đọc mã nguồn”. Ý nghĩ của điều đó là, điểm khác biệt then chốt giữa Linux và Windows là Linux là phần mềm mã – nguồn – mở – bất cứ ai cũng có thể nghiên cứu mã nguồn và cho ý kiến về chất lượng của nó.

 

Tôi sẽ không đề cập đến những đặc điểm, ưu nhược của phần mềm mã nguồn mở, nếu muốn các bạn có thể tham khảo ở các bài viết khác. Với những hiểu biết cơ bản về mã nguồn mở, các bạn có thể hiểu được là phát biểu của Thompson “…có những đoạn viết tốt và có những đoạn thì không tốt…” và “… chất lượng khác nhau thấy rõ … “ không phải là không có cơ sở.

 

Tạm để qua một bên tầm vóc của Ken Thompson trong cộng đồng công nghệ phần mềm, xét theo một khía cạnh khách quan thì ý kiến của ông về chất lượng của Linux cũng mơ hồ như ý kiến của rất nhiều người dùng ủng hộ Microsoft và Windows bài xích Linux (các bạn cũng đã thấy khá nhiều trên forum này). Bởi vì, xét cho cùng, hình như Thompson không hề dùng một chuẩn mực nào (ví dụ như số lỗi dò ra được) để đo lường chất lượng mã nguồn. Hơn nữa, ông cũng không nói rõ là khi phát biểu như vậy ông đã nghiên cứu thấu đáo Linux chưa, hay chỉ là “vơ đũa cả nắm” từ một mẫu code.

 

Để chỉ ra những điểm yếu của Linux, ta cần những ý kiến cụ thể hơn, xác đáng hơn, khách quan hơn. Bài viết “Maintainability of the Linux Kernel” của các tác giả Stephen R. Schach, Bo Jin, David R. Wright, Gillian Z. Heller, A. Jefferson Offutt

 

đã thử nghiệm trên 365 phiên bản của Linux. Với mỗi phiên bản, họ đếm số thực thể (instance) của các móc nối toàn cục (common coupling) giữa 17 module trong mỗi kernel và tất cả những module khác trong các phiên bản đó. Họ đã phát hiện ra là số thể hiện của common coupling tăng theo hàm mũ (exponentially) với số của phiên bản. Kết quả này đúng đến 99,99%. Mặt khác, số dòng code trong các module của mỗi kernel chỉ tăng tuyến tính (linearly) với số của phiên bản. Qua đó, họ đã kết luận là, trừ phi Linux được tổ chức lại với số lượng common coupling nhỏ nhất, thì những quan hệ phụ thuộc ràng buộc bởi common coupling đến một ngày nào đó sẽ làm cho Linux trở nên cực kỳ khó để bảo trì (maintain) mà không gây ra lỗi.

 

Nhận thấy đây là một bài báo có ích cho người nghiên cứu mã nguồn Linux nói riêng và nghiên cứu mã nguồn mở nói chung nên tôi lược dịch và trình bày lại với một số ý kiến của mình, hy vọng giúp được gì đó cho những người quan tâm, đặc biệt là những thành viên của nhóm Operatin System trong dự án High Performance Computing của trường mình. Nếu có thể, khi chỉnh sửa mã nguồn ta sẽ làm cho Linux hòan chỉnh hơn. Have fun with FOSS!

 

2. Sự phụ thuộc giữa các module trong một software

 

2.1Coupling:

 

- Một coupling (tạm dịch là “móc nối”) giữa hai unit của một sản phẩm phần mềm là mức độ tương tác giữa các unit đó, do đó, cũng có thể nói là mức độ phụ thuộc giữa các unit.

 

- Page-Jones đưa ra ba lý do chính cho thấy việc giảm số thể hiện của coupling giữa các module là cần thiết:

 

+ Số quan hệ giữa các module càng ít thì càng giảm xác suất khi lỗi của một module xảy ra sẽ ảnh hưởng lên module khác.

 

+ Số quan hệ giữa các module càng ít thì càng giảm xác suất các thay đổi trong một module gây ra vấn đề, việc này sẽ nâng cao khả năng tái sử dụng.

 

+ Số quan hệ giữa các module càng ít thì càng giảm thời gian của lập trình viên trong việc đọc hiểu chi tiết của các module khác. (Việc này ai đã từng đọc code của Linux cũng biết vất vả như thế nào!)

 

Mặc dù tất cả các loại coupling đôi khi rất hữu ích cho thiết kế, nhưng một số lại thường dẫn đến lỗi cho phần mềm. Do đó một số loại coupling nên được giới hạn sử dụng.

 

Ví dụ:

 

Trong bảng phân loại 11 mức coupling của Offutt, mức thấp nhất là call coupling, dùng giữa module P và Q nếu P gọi Q hay Q gọi P, nhưng không có truyền tham số, tham khảo biến toàn cục, hay các tham khảo toàn cục đến các phần nằm bên ngòai giữa P và Q.

 

Trong bài viết này ta quan tâm đến common coupling, tương ứng với mức 10, global coupling. Nó được dùng khi module P và Q cùng chia sẻ một tham khảo đến một biến toàn cục.

 

2.2Vai trò của coupling:

 

Nếu một phần mềm không có coupling nào thì sản phẩm đó sẽ bao gồm một module khổng lồ, vì vậy một lượng coupling rõ ràng là cần thiết. Có nghĩa là, coupling là một hệ quả tất yếu của việc lập trình theo module.

 

Tuy nhiên, khi giữa 2 module có coupling, sẽ có một mức độ phụ thuộc giữa 2 module đó. Mức độ phụ thuộc đó có thể là cao (“strong coupling”) hay thấp (“weak coupling”). Một phần mềm được thiết kế tốt sẽ cân nhắc việc sử dụng weak coupling và tránh càng xa càng tốt strong coupling.

 

Ví dụ: call coupling là một weak coupling, common coupling là một strong coupling.

 

2.3Coupling và maintainability

 

Qua các phần trên các bạn đã thấy được mối liên quan giữa coupling với sự dễ xảy ra lỗi (fault-proneness), nhưng chưa thấy rõ ràng mối liên quan giữa coupling với khả năng bảo trì (maintainability). Mặt khác, chúng ta cũng chưa có một định nghĩa chính xác cho maintainability, do đó cũng chưa có tiêu chuẩn gì được công nhận rộng rãi cho maintainability. Tuy nhiên, ta có thể nói rằng, khi một modult là fault-prone thì nó sẽ phải trải qua nhiều lần bảo trì lặp đi lặp lại, và những thay đổi thường xuyên đó hầu như làm “lờn” đi khả năng bảo trì của nó. Hơn nữa, những thay đổi thường xuyên như vậy sẽ không chỉ giới hạn trong bản thân module bị fault – prone; việc phải thay đổi nhiều hơn một module chỉ để sửa một lỗi không phải là hiếm. Do đó, đặc tính fault-proneness của một module có thể gây bất lợi cho maintainability của một số modules khác.

 

Hay nói cách khác, dễ hiểu là strong coupling có thể gây hại cho maintainability.

 

Tại sao trong bài viết này chỉ đề cập đến common coupling? Có ba lí do:

 

- Thứ nhất, trong các case study về maintainability của multiversion real-time software cho thấy, các strong coupling xuất hiện trong giai đoạn maintenance đại đa số là common coupling.

 

- Thứ hai, có những tranh cãi đáng chú ý về việc chính xác là cái gì cấu thành weak hay strong coupling, và nên thống nhất theo bản phân loại coupling nào. Tuy nhiên, tất cả các bảng phân loại đều có một dạng coupling tương ứng với một common coupling kinh điển (ví dụ trong bảng ta đã nói ở trên là global coupling), và hầu như tất cả đều thống nhất là common coupling có thể gây phiền phức.

 

- Thứ ba, common coupling có một thuộc tính hiểm họa là số thể hiện của common coupling giữa module M và các module khác có thể thay đổi một cách mạnh mẽ, ngay cả khi bản thân module M không hề thay đổi; cái này được gọi là clandestine common coupling. Ví du, nếu module M và N đều tham khảo đến một biến toàn cục gv, sau đó có một thể hiện của common coupling giữa M và các module khác. Nhưng nếu có 10 module khác được viết ra, tất cả đều tham khảo đến biến gv, thì số thể hiện của common coupling giữa M và các module khác sẽ tăng lên 11, mặc dù bản thân M không thay đổi gì cả.

 

3. SUCCESSIVE VERSIONS (Các phiên bản liên tiếp)

 

- Một số sản phẩm phần mềm (đặc biệt là FOSS) có quá trình phát triển song song, nghĩa là, một phiên bản chuẩn của phần mềm sẽ được mở rộng theo nhiều hướng cùng một lúc. Đôi khi, một hay nhiều nhánh trong số đó hợp nhất với nhau, trong khi các nhánh khác dừng lại.

 

- Nhắc lại cho các bạn chưa biết trong trường hợp của Linux, có hai bộ phiên bản của Linux kernel. Kernel có số version mà chữ số thứ 2 (minor number) là số chẵn (ví dụ, 2 trong 1.2.9) là phiên bản ổn định (stable). Kernel có minor number là số lẻ (vd 2.1.132) là phiên bản đang phát triển (developmental). Khi một developmental version đã đến độ “chín muồi”, nó sẽ trở thành một stable version với minor number tăng lên 1 (vd: 2.1.132 trở thành 2.2.0). Việc thay đổi minor number xảy ra khá thường xuyên, nhưng thay đổi major number (chữ số đầu tiên) trong lịch sử Linux chỉ có một lần đó là từ 1.x sang 2.x, major number chỉ tăng lên khi có một thay đổi cực lớn, tác động đến toàn bộ kernel.

 

Trong bài viết này, ta thống nhất là successive versions của version X là những version có version number và có time stamp (thời điểm công bố) liên tục nhau (theo chiều tăng dần). Ví dụ: trong Linux, version 2.0.30 đến 2.0.39 không phải là successive version vì có time stamp trễ hơn của 2.1.0. Và trong bài viết này sẽ chỉ làm việc với các successive version.

 

4. HỌ ĐÃ LÀM ĐIỀU ĐÓ NHƯ THẾ NÀO?

 

Như đã nói ở trên, module P và Q có common coupling nếu P và Q chia sẻ các tham chiếu đến cùng một biến toàn cục. Ta sẽ xem qua cách người ta (Stephen R. Schach, Bo Jin, David R. Wright … – tác giả bài báo tôi đề cập ở trên) đếm các common coupling thế nào.

 

Họ download tất cả các module của mỗi version trong 365 version của Linux. Với mỗi module trong số 17 module tạo nên kernel, họ phân loại bằng tay các biến toàn cục. Sau đó họ xác định mỗi biến toàn cục trong một module kernel được tham khảo bởi bao nhiêu module khác (mấy bước này mà không có tools như lxr thì cũng hơi bị phê!). Do chỉ tính module nên 1 module có nhiều tham chiếu đến 1 biến cục bộ cũng tính là 1, họ cũng loại những tham chiếu toàn cục đến các hằng số. Sau đó họ xác định xem mã nguồn đó có được thay đổi so với version trước không. Nếu có, họ ghi chú lại số dòng code trong version mới đó và ngày phát hành.

 

 

 

Ví dụ, version 2.1.104 của kernel module Panic.c được phát hành ngày 21 tháng 5 năm 1998, có 79 dòng code, và có 914 thể hiện của common coupling giữa module Panic.c và tất cả các modules khác trong version 2.1.104 của Linux. Số thể hiện của common coupling tăng đều lên 946 trong version 2.1.109, mặc dù code của Panic.c không hề thay đổi gì cả, một ví dụ của clandestine common coupling.

 

(còn tiếp)

 

Đông Thao

 

 

Compile Kernel in A Nutshell P2.

IV.Bắt tay vào việc
1.Cấu hình kernel
Đây là bước quan trọng nhất, quyết định thành bại của việc compile một kernel. Do đó tôi viết kỹ và dài nhất. Hãy hiểu rõ là bạn đang làm gì (không hiểu cũng cứ chọn đại, từ từ sẽ hiểu ). Mỗi một module thành phần có 3 tùy chọn khi compile: Không compile (N), compile trực tiếp vào kernel (Y), compile như một module rời (M). Có những module không thể compile như một module rời được vì nó phải được load ngay khi kernel được boot.

-Compile trực tiếp vào kernel nghĩa là các module ấy có dùng hay không vẫn được load lên khi kernel khởi động và sẽ chiếm một phần bộ nhớ. Ưu điểm là về mặt bảo mật, không bị “fake” khi load module rời lên, và lợi về mặt performance khi không phải load module lên để chạy.
-Compile như module rời nghĩa là chỉ khi nào cần dùng thì các module này mới được load lên. Do đó lợi hơn về mặt tốn memory và tài nguyên. Một ưu điểm nữa là nếu chỉnh sửa gì module đó thì không cần phải compile lại toàn bộ kernel.

Các công cụ để cấu hình kernel
-make config: Đơn giản nhất, nhẹ nhất, ít đòi hỏi nhất vì nó ở dạng … console đen ngòm! Nó đưa ra một loạt các câu hỏi bất tận cho bạn lựa chọn Y, N hay M. Với chương trình này, phím sa là gà chết vì một khi đã Enter thì vô phương quay lại lựa chọn vừa rồi. Nếu lỡ phát hiện ra sai sót thì cho dù bạn đang ở câu hỏi cuối cùng cũng phải trở lại từ đầu. lời khuyên: không nên dùng.

-make xconfig: Phương tiện ưa thích và dễ dùng cho những ai dùng X Windows (giao diện đồ hoạ). Giao diện trực quan, có thể sử dụng chuột rất tiện lợi. lời khuyên: Nếu bạn thích dùng giao diện trực quan thì đây là lựa chọn số 1. Ngoài ra kernel 2.6 còn có make gconfig tương tự.

-make menuconfig: Đưa ra các menu GUI trên nền console. Khá tiện lợi, bảo đảm chạy vào là biết dùng ngay lần đầu tiên. Tốt hơn config và đơn giản hơn xconfig. Khi có module nào không hiểu thì chỉ cần chọn module đó và gõ dấu ? hay chọn nút Help là thông tin sẽ hiện ra. Đây là công cụ tôi ưa thích vì ít khi dùng X Windows.

Kernel 2.6 còn đưa ra 4 lựa chọn nữa cho bước này:
-make defconfig: tạo một cấu hình mới với chế độ default cho mọi chọn lựa.
-make allmodconfig: tạo cấu hình mới với chế độ chọn các module khi có thể được.
-make allyesconfig: tạo cấu hình mới với chế độ chấp nhận YES (Y) cho mọi chọn lựa.
-make allnoconfig.

Một tùy chọn nữa khi cấu hình là make oldconfig. Cách này sẽ dùng lại file config cũ mà không cho bạn lựa chọn sửa đổi nào. lời khuyên: dùng lựa chọn này nếu bạn đã có một file cấu hình hoàn chỉnh và không muốn thay đổi gì nữa.

Hic, “lắm thầy nhiều ma”, càng đọc càng thấy hoang mang quá. Đừng lo, sau khi đã trang bị một số kiến thức cần thiết ở trên, giờ ta bắt tay vào config thật sự. Đây là những gì tôi đã làm. Giả sử mình bắt đầu config lại một kernel mới, không dùng file cũ. Nhắc lại là ta sẽ dùng thư mục cài đặt: /home/abel/build. Nếu bạn đã dùng thư mục này để compile một kernel trước đó và không muốn dùng lại file cấu hình cũ đó nữa thì CD (change directory) vào thư mục source và bắt đầu bằng lệnh sau:

#make O=/home/abel/build mrproper

Lệnh này sẽ xóa toàn bộ những file đã xuất hiện khi cấu hình kernel cũ. Khi dùng lệnh này rồi thì không dùng make oldconfig được nữa. Nếu bạn không tạo thư mục cài đặt mà để mặc định thì phía sau make không có tùy chọn O=…, nghĩa là chỉ còn: #make mrproper. Điều này đúng cho tất cả các lệnh bắt đầu bằng make từ đây trở xuống.

Tiếp theo:

#make O=/home/abel/build menuconfig

Nếu bạn không bắt đầu bằng mrproper thì menuconfig sẽ load file config cũ lên. Ngược lại thì menuconfig sẽ load lên một cấu hình mặc định. Bạn có thể thay menuconfig bằng các phương tiện cấu hình đã giới thiệu ở trên.

Bây giờ bắt đầu vào các menu và tìm hiểu xem bạn có những gì trong tay. Tùy vào phần cứng từng máy và sở thích từng người mà có lựa chọn thích hợp. Đừng quên bấm ? để xem hướng dẫn trước khi ra quyết định. Hai mục chọn quan trọng trong các menu là File Systems và Device Drivers. Hãy cẩn thận với hai mục này. Nếu không chắc nên chọn cái nào bỏ cái nào thì tốt nhất là để mặc định như vậy và chọn Exit để thoát ra.

Important Note: Nếu bạn dùng distro nền là Redhat Enterprise WS 3 thì phải vào mục File System và sửa lại phần Extend 3rd Support là phần build in trong kernel luôn chứ không phải là một Module như default (di chuyển vệt sáng đến dòng đó và nhấp space bar đến khi nào kí hiệu trong <> chuyển thành dấu *). Nếu quên sửa mục này thì sẽ bị kernel panic vì insmod không load được module ext3.ko! Nguyên nhân chung chung có thể là do REWS dùng kernel 2.4 còn FC dùng kernel 2.6.

Khi thoát ra đừng quên chọn YES khi được hỏi có lưu cấu hình vào file .config không. Cuối cùng file cấu hình .config sẽ được tạo ra trong thư mục /home/abel/build ta đã xác định trước (sao không vi nó ra xem thử một chút nhỉ?). Vậy là xong bước gian khổ nhất rồi. Từ đây về sau tất cả những gì bạn cần làm là gõ và chờ.

2.Tạo kernel image và biên dịch module
Bước này chỉ cần một lệnh (với kernel 2.6)

#make O=/home/abel/build

Sau đó pha một ly cà phê nhâm nhi hoặc tranh thủ đi giặt đồ! Sau thời gian tàn chừng … bó nhang thì quay lại coi sao nhé. Nói vậy thôi chứ bên cạnh năng lực phần cứng còn tùy vào số module bạn chọn nhiều hay ít mà bước này sẽ lâu hay rất lâu .
Tất cả các bước trên đều có thể thực hiện bằng quyền user bình thường nhưng hai bước sau các bạn phải thực hiện ở quyền root.
3.Cài đặt module

#make O=/home/abel/build modules_install

4.Đưa kernel mới vào hoạt động

#make O=/home/abel/build install

Nếu mọi việc suôn sẻ thì bạn đã hoàn tất cái gọi là compile một kernel rồi đấy. mọi việc rất đơn giản. giờ chỉ còn reboot lại máy và xem chuyện gì xảy ra .
Các bạn thử về làm theo các hướng dẫn ở trên để thấy thật ra kernel cũng chẳng có gì ghê gớm và thử trả lời câu hỏi sau:

Cấu hình nào là tối thiểu để một kernel có thể boot lên được? Nghĩa là bỏ đi tất cả những module có thể để cuối cùng còn lại những module thiết yếu sao cho giờ nếu ta bỏ bất cứ module nào thì khi compile xong cũng không thể boot vào kernel mới được.
tôi cũng đang dùng phương pháp thử sai để tìm ra giải đáp cho câu hỏi trên. Nếu có trục trặc gì thì các bạn cứ gửi lên đây để cùng tìm hiểu.
Hứa hẹn một bài viết “Compile Kernel in advanced” ta sẽ bàn chi tiết hơn về các bước quá trình compile này nhé. Còn nhiều điều thú vị ta chưa để cập tới.

Tài liệu tham khảo:
[1]Internal Document of Operating System Group – HPC Project, DIT of HCMUT
[2]#more /home/abel/linux2.6.11/Readme

Compile Kernel in A Nutshell P1.

I.Lí do để compile kernel
Khái niệm compile kernel chỉ xuất hiện với các hệ điều hành tự do, mã nguồn mở. Còn với các mã nguồn đóng thì kernel là cái chi chúng ta còn không biết thì làm sao mà compile. Có thể nói (không chính xác hoàn toàn) việc compile kernel với người dùng Linux cũng khá là quen thuộc như là thao tác reinstall khi dùng Window$! Các lí do chính để người dùng đi đến quyết định compile kernel:

1.Tái biên dịch để sửa lỗi kernel.
2.Nâng cao hiệu suất bằng cách bỏ bớt những module không cần thiết.
3.Loại bỏ những driver không cần thiết hoặc thêm vào driver mới.
4.Thêm vào, thử nghiệm một chức năng mới hoặc một module mới mình vừa tạo ra.

Cuối cùng, compile kernel là “độc quyền” của hệ điều hành mã mở thì sao ta lại từ chối quyền lợi này khi đã dùng Linux? Chưa compile được kernel thì chưa phải là dân Linux “sành điệu” . Các bước được trình bày sau đây là đơn giản và hiệu quả nhất, đơn giản với cả những người mới bước vào thế giới Linux.

II.Nắm thông tin phần cứng
Đây là những thông tin quan trọng cho phần cấu hình kernel. Ví dụ bạn phải biết các thông tin về loại CPU, loại ổ cứng, các card PCI cắm vào máy …
Ngoài hóa đơn báo giá lúc mua máy, bạn có thể dùng các lệnh sau để biết được thông tin về phần cứng trên máy:

#/sbin/lspci – liệt kê chi tiết các card PCI
#cat /proc/cpuinfo – xem chi tiết về CPU. Xem tài liệu về hệ thống file proc để biết thêm.
#dmesg (đọc hiểu được các kết quả xuất ra cũng không thoải mái lắm!)

III.Chuẩn bị đồ nghề
0.Một hệ điều hành Linux ngon lành
Cái này thì không thể thiếu. Các distro mà tôi đã thử nghiệm cho bài viết này là Red Hat Enterprise Workstation 3 (có license đàng hoàng nha ) và Fedora Core 3, 4.

1.Thiết bị cứu hộ
Bước này đưa ra cho đúng thủ tục “an toàn lao động” thôi chứ trong mấy chục lần compile tôi chưa hề thấy lần nào phải dùng đến đĩa cứu hộ do lỗi lúc compile (lỡ bị gì là chôn lun, khỏi cứu J/K). Nguyên nhân là do dù bạn có cấu hình bậy bạ đến bao nhiêu khi config kernel thì nó cũng chỉ ảnh hưởng đến cái kernel bạn mới tạo chứ không ảnh hưởng đến kernel nền. Một nguyên tắc an toàn khi compile kernel đó là không nên bỏ kernel cũ đi mà vẫn để nguyên đó cho đến khi kernel mới đã chạy ổn định để có thể boot vào lại được khi bất trắc. Nếu nhớ quy tắc này thì không có gì là quá muộn! Ta chỉ phải dùng đĩa cứu hộ khi bạn táy máy chỉnh sửa file cấu hình của GRUB hay LILO bậy bạ làm cho không boot vào được thôi.
Nói đến đĩa cứu hộ ai cũng nghĩ ngay đến đĩa mềm khởi động và rất nhiều cách để tạo đĩa mềm này (vd: mkbootdisk) nhưng tôi thì đã từ lâu quên cái đĩa mềm vào dĩ vãng nên đĩa cứu hộ lúc này là cái đĩa #1 của bộ đĩa cài đặt (Fedora Core, Red Hat…), khỏi cần phức tạp chi cho mệt.
Đút cái đĩa #1 vào và gõ “linux rescue” khi hiện lên màn hình boot. Sau một vài thao tác Enter là bạn đã vào được cái shell quen thuộc. Bây giờ gõ thêm lệnh “chroot /mnt/sysimage” là bạn đã ở trong hệ thống file cũ của mình rồi đó. Lúc này thì tìm và lôi file config của GRUB hay LILO ra sửa lại là xong.

2.Mã nguồn Kernel
Tải về từ chính hãng www.kernel.org
Bình thường thì nên chọn phiên bản ổn định (stable) với chữ số đằng sau dấu chấm thứ nhất là số chẵn (vd 2.4, 2.6…). Gói source thường ở dạng nén bz2.
Trong bài viết này Abel dùng kernel 2.6.11 làm demo -> file linux2.6.11.tar.bz2

3.Thư mục mã nguồn và thư mục cài đặt
File source kernel mà chúng ta có là một file nén do đó để sử dụng được các bạn phải giải nén gói đó bằng lệnh bzip2 –d sau đó bung gói tar ra bằng lệnh tar xvf. Cụ thể:

#bzip2 –d linux2.6.11.tar.bz2
#tar xvf linux2.6.11.tar

Sau khi hoàn thành hai lệnh trên ta sẽ được một thư mục là linux 2.6.11. Đây chính là thư mục chứa source code kernel. Ta sẽ tạo thêm một thư mục nữa để chứa các file output khi biên dịch. thường thì Abel hay để hai thư mục này ở trong /home/<username>/. Giả sử ta có thư mục chứa source: /home/abel/linux 2.6.11 và thư mục cài đặt: /home/abel/build.
Note: Nếu không dùng một thư mục cài đặt khác thì mặc định các file sau khi cài đặt sẽ nằm chung với thư mục source và ta sẽ rất khó quản lí và khảo sát.

Đông Thao

Take owner ship

Có bao giờ các bạn gặp trường hợp này chưa: Bạn muốn cài lại Windows, nhưng không muốn bị mất các dữ liệu dính tới user cũ của mình ở ổ C (giả sử đây là ổ system) như My Document, Bookmark, Desktop…. nên bạn quyết định cài lại Windows với tùy chọn là không format ổ C mà chỉ cài đè lên.
Sau khi cài đặt xong, bạn vào Windows, vào thư mục C:\Documents and Settings\ thì vẫn thấy tên user cũ nằm đó. Mừng húm, bạn nhảy vào thư mục của user cũ để chép dữ liệu ra thì … ôi thôi, Access Denied! Ngay cả với quyền admin bạn cũng không thể vào được thư mục đó!

Lí do: Account user bình thường thì không phải là chủ cái profile đó nên không vào được là chuyện đương nhiên, nhưng admin cũng không vào được là sao? Vì thư mục đó đã được phân quyền với các UID cũ của bản Win trước, do đó admin mới với UID mới cũng trở thành vô dụng.

Giải pháp: Take ownership hay còn gọi là đoạt quyền. Chuột phải vô thư mục profile đó, chọn Tab Security, nhấn vào nút Advanced, Tab Owner, bạn thấy cái tên Admin nằm ở cái ô dưới, cùng với cái user đầu tiên của hệ thống (có quyền tương đương admin). OK, check vào Replace owner on subcontainers and objects. Click Apply, OK.

P/S: Việc này phải thực hiện với quyền admin.
TIPS: Cách này có thể giúp bạn “cướp” tài sản của bất kì user nào nằm trên hệ thống do bạn làm admin . Becareful, evil!

-ĐT

Linux và một chiếc máy tính cho mẹ già

Một bài viết đã rất lâu trên báo tuổi trẻ: Linux và một chiếc máy tính cho mẹ già. Sau đây là ý kiến của tôi (cũng đã viết khá lâu rồi), sau khi đọc bài báo này. Cũng xin nói trước là tôi là một người ủng hộ mù quáng cho FOSS .

Những vấn đề anh chairuou đề cập với FOSS ở trên, vẫn có thể thực hiện được với một người sử dụng Windows thành thạo, thậm chí không cần cài đặt thêm cái gì cả. Chẳng hạn:

-Vấn đề double click được giải quyết bằng: mở My Computer, Chọn menu Tool>Folder Options> Tab General> Cái Option cuối cùng chọn Single-click to open an item (point to select)

-Vấn đề session:
+ Tạo một user mới cho mẹ, không có quyền Administrator. Việc này có hai cái lợi: thứ nhất, tránh tối đa việc mẹ dùng account Administrator (các chương trình muốn chạy bằng quyền Admin có thể nhấp chuột phải, chọn Run As). Thứ hai, dễ dàng phân quyền và quản lí hơn.
+ Thiết lập mọi thứ cho profile của user này như hình nền desktop, sắp xếp shortcut…
+ Vào thư mục Document and Settings của ổ đĩa hệ thống, vào thư mục của user mới tạo, đổi tên file NTUSER.DAT thành NTUSER.MAN. Kể từ đây, cho dù mẹ có thay đổi gì trên desktop đi nữa, sau khi log on vào lần sau mọi thứ vẫn quay về như thiết lập ban đầu!

-Vấn đề thư mục cá nhân:
My Document hoàn toàn có thể thay đổi đường dẫn đến một thư mục bất kì trên hệ thống. Về công dụng, My Document hoàn toàn tương ứng với /home/username trên Linux.

-Giúp đỡ từ xa:
Với giao diện đồ họa Windows, Remote Assistant là một công cụ trợ giúp rất hiệu quả!
Ngoài ra, tương ứng với việc sử dụng sshd trên Linux, ta có thể dùng Remote Desktop trên Windows hay dùng phần mềm hỗ trợ từ 3rd party như VNC…

Hệ thống command trên Windows cũng được hỗ trợ rất nhiều những tiện ích mà trên giao diện đồ họa không có. Nhưng dĩ nhiên home user ít khi nào quan tâm.

Ngoài ra, nếu mắt mẹ yếu, tai mẹ không được tốt, tay mẹ run, ta có thể thiết lập trong Accessibility để giúp mẹ.

Lời kết
Về vấn đề tiện dụng, mọi HDH đều hướng đến chỉ tiêu này cho người dùng, nhất là với thằng Window$ lấy home user làm cần câu cơm chính! Chỉ có là mình chưa biết khai thác hết mà thôi. Do đó theo ý kiến của Abel, nói Linux tiện dụng hơn Windows đối với home user (hay ngược lại) là khập khiễng. Ta dùng FOSS với tiêu chí đầu tiên không phải là làm tăng tính tiện dụng cho home user, mà đó là điều bắt buộc phải có để FOSS có thể tồn tại!

Dù sao đi nữa, ý tưởng thiết kế một hệ thống Linux tuyệt vời cho mẹ già như trên của anh chairuou thật đáng để học hỏi (và xúc động nữa ). Sau này mua máy cho mẹ, tôi cũng sẽ học hỏi như thế !

-ĐT

Lỗi XServer khi dùng SuSE

Mấy bữa nay tự nhiên con SuSE 10 mới cài của tôi lăn đùng ra không chịu start giao diện lên nữa. Sau khi bỏ ra một ngày trouble shoot (bao gồm luôn cả việc cài lại!) cuối cùng tôi cũng tìm được cách cho nó start được cái giao diện quái quỉ lên (hic, SuSE mà không start GUI lên được thì vứt cho rồi, xài làm gì nữa!).
Tình hình chung là thế này: Sau khi install xong, bạn login vào SuSE với chế độ giao diện đồ họa (init 5) một cách bình thường. Nhưng sau khoảng 3, 4 lần log out, log in – hoặc restart máy (có khi chỉ cần 1 lần mà thôi!), bạn không thể nào login được vô cái GUI được nữa. Mỗi lần start lên, nó cứ dừng lại ở màn hình đồ họa lúc login, rồi đứng đó luôn cho dù bạn có nhập đúng username/password cả trăm lần đi nữa! (ban đầu ai không biết cứ nghĩ là mình quên password)

Dĩ nhiên, sau khi chắc chắn là mình không quên password, bạn sẽ nghĩ đến việc login bằng Console. Nhấp vào cái nút System màu đỏ ở phía dưới, bạn sẽ thấy cái menu Console Login. Sau khi login bằng console, bạn thử startx lên thì sẽ nhận được các error messages sau:

Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing from list!

Sau khi thử đủ thứ, cuối cùng tui phát hiện ra là vấn đề không phải do font (lúc đầu nghĩ thế) mà là do thằng .xinitrc không biết phải load thằng quản lí giao diện nào lên (!). Chỉ cần thêm vào file .xinitrc dòng

exec kde

nếu bạn dùng KDE thì mọi chuyện sẽ ổn thỏa. Giờ thì có thể login vào giao diện, surf web, viết blog bình thường.

P/S: đây là một lỗi cực kì phổ biến và cực kì chuối trong SuSE từ đời 9. (trước đó có bị không thì tui không rõ) tới bi giờ. Vậy mà không hiểu sao Novell chưa fix nó đi.

Password cho GRUB/LILO, why not?

1. Trên Linux, việc reset password cho account root có thể thực hiện một cách dễ dàng bằng chế độ boot single-user
1.1 Trên GRUB:
Khi màn hình chọn kernel để boot xuất hiện, nhấn “e” để vào chế độ edit các tham số khởi động.
Chọn dòng chứa tham số kernel. Ví dụ:

kernel /boot/vmlinuz-2.6.11 ro root=LABEL=/

Nhấn “e” để vào cửa sổ soạn thảo.
Di chuyển đến cuối dòng, thêm chữ “single” vào. Press Enter để lưu thay đổi. Gõ “b” để boot với chế độ single-user.
Bạn sẽ có được cái shell của root mà không bị hỏi password gì cả. Lúc này chỉ bằng lệnh “passwd” bạn đã có thể dễ dàng đổi password root rồi đó! Xong gõ “exit” để hệ thống tiếp tục boot bình thường.

2.2 Trên LILO:
Nếu bạn dùng LILO ở chế độ graphic thì khi màn hình LILO hiện lên nhấn “Ctrl-x” để thoát giao diện đồ họa và vào dấu nhắc “boot:”. Gõ vào
linux single
Sau đó bạn sẽ được vào account root mà không cần password gì cả! Thực hiện đổi pass như trên.

2. Vậy thì bất cứ ai ngồi trên Linux box của bạn cũng có thể chiếm quyền root? Yeah. Giải pháp: Đặt password cho boot loader GRUB/LILO.
2.1 Protecting GRUB
Không cho edit GRUB config để vào single mode.
•Tạo password grub được hash với md5Gõ /sbin/grub-md5-cryptGõ password Grub vào
Ta được một giá trị hash
•Edit GRUB config file: /boot/grub/grub.conf: Phía dưới dòng timeout thêm vào: password –md5 <giá trị hash>
Bonus: Bắt phải nhập password GRUB mới được khởi động HDH:
•Gõ vào phía dưới dòng title: lock
•Gõ password –md5 <giá trị hash> vào

2.2 Protecting LILO
Phải nhập pass để boot:
•Edit file /etc/lilo.conf: trước image, thêm vào password=<passwordLILO>
•Chạy /sbin/lilo –v –v để update lilo
Bảo vệ cụ thể cho image nào: trước image=/boot/vmlinuz-<version> dòng password=<password>

Cho phép usre khởi động nhưng không cho thêm tham số để vào single-usermà không có password: thêm dòng restricted vào phía dưới password.

Hãy đặt thêm password cho GRUB/LILO để tránh bị mất quyền điều khiển hệ thống khi sơ ý.

-ĐT

Sử dụng Linux trên máy ảo VMWare

Máy ảo VMWare là một công cụ tuyệt vời để chạy nhiều hệ điều hành cùng một lúc. Nó đặc biệt hữu dụng cho những người muốn làm quen với Linux nhưng chưa muốn từ bỏ Windows. Lúc đó, một (hay nhiều) bản Linux chạy với VMWare trên Windows là sự lựa chọn tốt nhất. Đến khi bạn đã quen với Linux thì có thể bỏ hẳn Windows, trong trường hợp cần phải làm việc với môi trường Windows lại thì bạn có thể cài Windows với VMWare chạy trên Linux!

Bài viết này tôi muốn chia sẻ một số kinh nghiệm lúc dùng Linux với VMWare chạy trên Windows, hy vọng giúp được các bạn mới làm quen với chú chim cánh cụt.

1.VMWare
Download VMWare bản free . Tôi hay xài bản VMWare Server.

Cách cài đặt VMWare trên Windows và tạo máy ảo rất đơn giản. Sau khi tạo máy ảo xong, start nó lên và nhấn F2 vào CMOS cấu hình cho nó boot bằng CD, đút đĩa cài đặt Linux vào và cài đặt bình thường như là một con PC thật.

2.Dùng ssh điều khiển Linux trên Windows
Một bất tiện khi dùng VMWare chạy Linux trên Windows là do hệ điều hành guest (cài trên máy ảo) là Linux nên ta không cài các VMWareTools được, do đó để di chuyển giữa cửa sổ máy ảo và máy thật ta phải nhấn Ctl-Alt để giải phóng con chuột ra khỏi máy ảo. Sẽ rất khó chịu khi bạn vừa tham khảo tài liệu vừa test thử trên máy ảo. Một cách để khắc phục là ta không thao tác trực tiếp trên VMWare mà sẽ dùng remote login, ví dụ dùng ssh để log vào máy ảo. Chương trình ssh client ta dùng sẽ là Putty (miễn phí), lúc đó ta có thể chuyển qua lại giữa các cửa sổ một cách dễ dàng như bất kỳ ứng dụng nào trên Windows.

Để sử dụng được cách này, trước hết ta phải cấu hình để Linux trên máy ảo thấy được Windows trên máy thật. Ta có thể dùng card mạng trên máy ảo ở chế độ Bridging để truy cập vào mạng LAN bên ngoài (và có thể ra Internet) được. Lúc cài đặt HDH nó sẽ yêu cầu bạn config card mạng. Một số lưu ý khi config:
1. IP của máy ảo cùng subnet với máy thật
2. Defautl gateway giống như của máy thật (IP router hay modem ADSL của bạn)
3. DNS Server có thể phân giải tên ra Internet.

Ngoài ra có thể config lúc đã log vào HDH bằng lệnh ifconfig hoặc dùng tool netconfig trên Redhat. Xem thêm tài liệu Networking Howto .

Sau khi cấu hình xong, ping thử hai máy đã thấy reply ok thì bạn start service sshd trên máy Linux lên. Trước hết kiểm tra xem có ssh server trên máy bạn chưa bằng cách tìm file sshd:

$sudo find / -name sshd

Nếu có rồi thì kiểm tra xem sshd đã có chạy chưa:

$pgrep sshd

Nếu chưa có thì bạn cài gói openssh server vào. Có thể download bằng trình duyệt hoặc dùng wget:

$wget ftp://ftp.openbsd.org/pub/OpenBSD/Op…h-4.3p2.tar.gz

TIPS: Redhat đã có sẵn sshd. Start sshd trong Redhat:

$sudo /sbin/service sshd start

Cài đặt xong, start service sshd lên (xem man sshd để biết thêm chi tiết).
Dùng tool Putty trên Windows để connect vào máy ảo Linux. Download Putty.

Như vậy là bạn chỉ cần start Linux trên VMWare lên, start service ssh (có thể đưa sshd vào boot scripts để nó tự động start) và dùng Putty ssh vào để làm việc. Hết sức thuận tiện.

3.Dùng pure-ftp chia sẻ file giữa máy ảo và máy thật
Để chia sẻ file giữa máy ảo Linux với máy thật Windows, cách đơn giản nhất là dùng ftp. Trên máy Linux ta sẽ cài FTP server và trên Windows ta sẽ dùng FTP client connect vào. Có nhiều sản phẩm FTP server và client, Abel hay dùng nhất là server pure-ftpd và client là Total Commander (do dùng cái này làm file manager luôn nên xài rất chi là tiện).
Download pure-ftpd mới nhất về máy sau đó cài đặt và start pure-ftpd lên.
Nếu tìm không ra Total Commander các bạn có thể dùng bất kì chương trình ftp client nào.
Dùng Total Commander thiết lập một FTP Connection mới đến máy ảo Linux, cung cấp account user thích hợp và bắt đầu chia sẻ file. Hết sức đơn giản.

Đông Thao

Một số cách chạy dịch vụ tự động trong Nux

Các server luôn có nhu cầu khởi động các dịch vụ mình đảm nhiệm lúc boot máy, do đó khi cài một dịch vụ mới lên, bạn phải biết cách làm cho nó tự động chạy. Sau đây là một số cách mà tôi đã làm.

1. Trên các hệ điều hành Debian like (Ubuntu, SuSE…): Dùng công cụ update-rc.d
Ví dụ sau khi cài xong bind (gói DNS Server), tôi muốn cho trình named (file exe của bind) phải tự động chạy khi máy khởi động. Vị trí của file named là: /usr/bin/named.

1.1 Đầu tiên tôi viết một đoạn shell script nho nhỏ với ba nhiệm vụ chính sau đây:
-Kiểm tra xem file /usr/bin/named có thể thực thi được hay không
-Kiểm tra file cấu hình /etc/named có tồn tại hay không
-Nếu hai điều kiện trên thỏa thì xuất ra dòng “Starting named” và chạy file /usr/bin/named

Cụ thể nó thế này:
#!/bin/sh
#file khoi dong named luc boot may
if test −x /usr/bin/named −a −f /etc/named.conf
then
echo "Starting named"
/usr/bin/named
Fi


(Với những dịch vụ khác cách viết file script là hoàn toàn tương tự)
1.2 Lưu nó lại với cái tên gì đó, ví dụ bootnamed, rồi nhét nó vô thư mục /etc/init.d
1.3 “Biến” nó thành file exe: chmod 755 /etc/init.d/bootnamed
1.4 Dùng lệnh
update-rc.d bootnamed defaults

Để cập nhật bootnamed vào các thư mục rc.d, các thư mục mà khi boot hệ thống sẽ vào kiểm tra để lôi dịch vụ ra chạy. Tham số defaults cho biết bootnamed sẽ được boot tự động ở init-mode default của hệ thống (ví dụ trong file inittab bạn để init default là 3 thì cứ vào 3 là nó chạy named!)
1.5 Reboot lại máy để kiểm tra

2. Trên các hệ điều hành Redhat like (Redhat, CentOS, Fedora…): Dùng công cụ chkconfig
Đây là một công cụ quản lí service at boottime rất mạnh của Redhat. Ví dụ để xem các service nào được auto run ở level 3, ta dùng lệnh:

[root@centos init.d]# chkconfig --list | grep 3:on
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
...

Để enable một service ở level được định trước:


[root@centos init.d]# chkconfig wine on
[root@centos init.d]# chkconfig --list wine
wine 0:off 1:off 2:on 3:on 4:off 5:off 6:off

Disable nó ở tất cả các level:


root@centos init.d]# chkconfig wine off
[root@centos init.d]# chkconfig --list wine
wine 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Đặc điểm của chkconfig là ta không cần tạo script như với update-rc.d, mà chkconfig sẽ đọc một số dòng đầu của file thực thi của dịch vụ (hay còn gọi là file rc) để xác định file thực thi đó sẽ chạy ở các level nào và độ ưu tiên như thế nào. Ví dụ với dịch vụ sshd ta xem thử file thực thi nó có cái gì

[root@centos init.d]# head -8 sshd
#!/bin/bash
#
# Init file for OpenSSH server daemon
#
# chkconfig: 2345 55 25
# description: OpenSSH server daemon
#

Ý nghĩa các tham số:


# chkconfig: 2345 55 25


| | |
| | độ ưu tiên của kill scripts
| |
| độ ưu tiên của start scripts
|
các level mà service được start (2, 3, 4, 5)

Giờ ta sẽ đưa named vào các dịch vụ được boot khi khởi động máy
2.1 Kiểm tra named đã được autorun ở level nào chưa:

[root@centos init.d]# chkconfig --list named
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
2.2 Sửa file rc của named lại để cho nó auto run ở level 3. Ban đầu do không autorun ở level nào hết nên 8 dòng đầu của named rc file có dạng:

[root@cent init.d]# head -8 named
#!/bin/bash
#
# named This shell script takes care of starting and stopping
# named (BIND DNS server).
#
# chkconfig: _ 55 45
# description: named (BIND) is a Domain Name Server (DNS)
# that is used to resolve host names to IP addresses.

Ta sửa dòng chkconfig thành:

#chkconfig: 3 55 45
2.3 Add named vào trình quản lí chkconfig

[root@centos init.d]# chkconfig named --add
2.4 Enable nó lên

[root@centos init.d]# chkconfig named on
2.5 Kiểm tra lại

[root@centos rc2.d]# chkconfig named --list
sshd 0:off 1:off 2:off 3:on 4:off 5:off 6:off

Thế là xong!

Kết: Hãy chắc chắn là bạn hoàn toàn kiểm soát được những dịch vụ nào đang autorun trên hệ thống của bạn.

-ĐT