A place for friends...

Cái blog đóng bụi

2012-02-10T17:01:00.000+11:00

Hôm nay chợt nhớ đến cái blog ngày xa xưa. Thử "login", chà... vẫn đăng nhập được. Chỉ có điều, google bắt mình phải đổi account bởi vì account ngày xa xưa cũng chẳng còn nữa.

Thôi... phủi bụi và bắt đầu viết lại. Biết đâu ngày nào đó vẫn còn hữu dụng.

Craftsman 4 - A Test of Patience

2008-04-02T11:08:00.001+11:00

Robert C. Martin
12 tháng 7, 2002

Nhật ký thân yêu,

Tối qua tôi ngồi tựa cửa sổ hàng giờ, nhìn các vì sao mờ dần trong bầu trời đêm. Tôi thấy việc làm của tôi và Jerry hôm qua có nhiều xung đột. Tôi học hỏi rất nhiều trong khi làm việc với Jerry với vấn đề tạo số nguyên tố, nhưng tôi không tin tôi gây ấn tượng gì với gã. Và, thật tình mà nói, tôi cũng không nể gã cho lắm. Thật ra, gã tốn khá nhiều thời gian mài dũa các mảnh mã cho dù những mảnh mã này làm việc ngon lành.

Hôm nay với một bài tập mới, Jerry đến gặp tôi. Gã yêu cầu tôi viết một chương trình tính thừa số nguyên tố của số nguyên. Gã cho biết gã làm việc với tôi ngay từ đầu nên hai chúng tôi ngồi xuống và bắt đầu lập trình.

Tôi tin chắc tôi biết cách làm. Hôm qua chúng tôi đã viết chương trình tạo số nguyên tố. Dò tìm các thừa số nguyên tố chỉ là vấn đề đi xuyên qua danh sách các số nguyên tố và xét thử có thừa số nào từ các số nguyên đã định. Thế nên tôi vớ lấy bàn đánh và bắt đầu viết mã. Khoảng nữa giờ sau khi viết và kiểm tra, tôi làm được như sau:

import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

public class PrimeFactorizer {
Public static void main(String[] args) {
int[] factors = findFactors(Integer.parseInt(args[0]));
for (int i = 0; i <>
}

Public static int[] findFactors(int multiple) {
List factors = new LinkedList();
int[] primes = PrimeGenerator.generatePrimes((int) Math.sqrt(multiple));
for (int i = 0; i <>
for (; multiple % primes[i] == 0; multiple /= primes[i])
factors.add(new Integer(primes[i]));
return createFactorArray(factors);
}

private static int[] createFactorArray(List factors) {
int factorArray[] = new int[factors.size()];
int j = 0;
for (Iterator fi = factors.iterator(); fi.hasNext();) {
Integer factor = (Integer) fi.next();
factorArray[j++] = factor.intValue();
}
return factorArray;
}
}

Tôi kiểm tra chương trình bằng cách chạy nó với nhiều thông số khác nhau. Mọi thứ dường như ổn thoả. Chạy chương trình với giá trị thông số 100 cho tôi kết quả 2, 2, 5 và 5. Chạy nó với 32767 cho tôi 7, 31 và 151. Chạy với 32768 cho tôi mười lăm số hai.

Jerry ngồi nhìn tôi. Gã chẳng nói nửa lời. Ðiều này làm tôi hơi hoảng nhưng tôi tiếp tục nắn bóp và thử nghiệm mã nguồn cho đến lúc tôi hài lòng. Sau đó, tôi bắt đầu viết phần "unit tests".

Jerry hỏi: "Mày làm gì vậy?"

"Chương trình chạy nên tôi đang viết các unit tests." Tôi đáp lại.

"Nếu chương trình đã chạy việc gì mày cần unit tests?" Gã hỏi tiếp.

Tôi không nghĩ đến điểm này. Tôi chỉ biết theo thông lệ cần phải viết unit tests. Tôi liều lĩnh đoán mò: "Ðể mà các lập trình viên khác biết được là chương trình đó chạy?"

Jerry nhìn tôi khoảng 30 giây rồi gã lắc đầu và nói: "Thời buổi này họ dạy dỗ tụi mày cái gì ở trường vậy?"

Tôi đớ lưỡi không trả lời được nhưng gã ngăn tôi lại bằng một cái nhìn.

"OK", gã nói, "xoá hết những thứ mày đã làm đi. Tao chỉ cho mày cách tụi tao làm ở đây."

Tôi quả không chuẩn bị cho tình thế như vậy. Gã muốn tôi xoá những gì tôi đã tạo ra trong ba mươi phút qua. Tôi chỉ ngồi yên, không tưởng tượng nổi.

Cuối cùng Jerry nói: "Xoá đi."

Tôi trả lời: "Nhưng chương trình đó chạy mà."

"Thì sao?" Jerry đáp lại.

Tôi bắt đầu nổi cáu. Tôi nói cứng: "Chương trình này chẳng có gì sai hết!"

"Thực vậy hở?" gã lầm bầm và vớ lấy bàn đánh, xoá hết mã nguồn của tôi.

Tôi điếng người. Không phải, tôi điên tiết lên. Gã mới vừa chồm qua và xoá hết đồ của tôi. Trong phút chốc ấy tôi chẳng còn thiết gì đến ưu thế được làm một tay học việc cho ông C nữa. Học việc mà phải đụng đến những kẻ tàn bạo như Jerry thì còn hay ho gì nữa? Với ý nghĩ như thế và những ý nghĩ còn kém phần tưởng thưởng khác diễn nhanh qua trong đầu trong khi tôi nhìn gã chằm chặp.

"À, tao thấy mày nổi đoá rồi đó." Jerry nói một cách điềm tĩnh.

Tôi lắp bắp nhưng chẳng thốt được gì cho minh bạch.

"Này." Jerry nói, rõ ràng đang cố làm dịu tôi xuống. "Ðừng có đeo cứng vào mã nguồn của mà quá như vậy. Chỉ có ba mươi phút làm việc mà thôi chẳng phải là cái gì ghê gớm đâu. Mày phải chuẩn bị tinh thần vứt bỏ thêm cả đống mã nguồn nữa nếu mày muốn trở thành một thứ lập trình viên gì đó. Vứt bỏ được hàng đống mã nguồn thường là điều tốt nhất mà mày nên làm.

Tôi buộc miệng: "Nhưng làm như thế thì quả là phí!"

Gã hỏi lại: "Bộ mày nghĩ giá trị của chương trình nằm trong mã nguồn sao? Không phải vậy. Giá trị của một chương trình nằm trong cái đầu của mày đó."

Gã nhìn tôi chừng một giây rồi tiếp tục. "Có bao giờ mày lỡ tay xoá cái gì đó mày đang làm chưa? cái gì đó mất của mày vài ngày làm việc đó?"

"Có một lần, ở trường". Tôi nói "Cái disk bị hỏng và hồ sơ lưu trữ cũ đến hai ngày."

Gã cau mày gật đầu biểu lộ sự thông hiểu rồi hỏi: "Mày mất bao lâu để tái tạo lại những cái đã bị mất?"

"Tôi nắm khá rõ những cái bị mất nên chỉ mất có nửa ngày để tái tạo."

"Ra thế mày chẳng thật sự mất khối lượng hai ngày làm việc."

Tôi chẳng màng gì đến cái logic của gã. Tôi không bắt bẻ được nhưng tôi không khoái cái logic đó. Chỉ đơn giản là tôi cảm thấy bị mất một khối lượng hai ngày làm việc!

Gã hỏi tiếp: "Mày có nhận thấy phần mã làm lại tốt hơn hay tệ hơn phần mã mày bị mất không?"

"Ồ, tốt hơn nhiều." Tôi nói, ngay lập tức hối tiếc là đã phát biểu như thế. "Lần thứ nhì tôi có thể dùng một cấu trúc tốt hơn nhiều."

Gã cười. "Thế thì cố thêm 25 phần trăm, mày đưa ra được một giải pháp tốt hơn."

Logic của gã làm tôi bực mình. Tôi lắc đầu và gần như thét lên: "Có phải ông giả định là chúng ta luôn luôn vứt bỏ mã nguồn sau khi làm xong?"

Trả lời cho sự ngạc nhiên của tôi, gã gật đầu và nói: "Gần như là như vậy. Tao giả định chuyện vứt bỏ mã nguồn là một việc giá trị và hữu dụng. Tao giả định mày không nên xem đó là chuyện hoang phí. Tao giả định mày không nên ôm khư khư cái mã nguồn của mày."

Craftsman 3 - Clarity and Collaboration

2008-04-02T11:01:00.002+11:00

Lần trước, Jerry, một cựu học việc yêu cầu tay học việc Alphonse viết một chương trình tạo số nguyên tố dùng phương pháp lượt Eratosthenes (sieve of Eratosthenes). Jerry duyệt và giúp Alphonse tách lược (refactor) mã nguồn đó. Anh ta không được hài lòng với kết quả của Alphonse. Lần trước Alphonse thực hiện xong phần refactoring và nghĩ chắc Jerry sẽ chấp thuận...

Jerry chỉ thoáng gật đầu. Liệu gã có thật sự khoái những điều tôi đã làm không?

Sau đó Jerry đi xuyên qua trọn bộ chương trình, đọc lại từ đầu đến cuối như thể gã đang đọc bài chứng minh hình học. Gã bảo tôi đây là một bước hết sức quan trọng. "Ðến bước này, tụi mình đã thực hiện refactoring các mảnh mã. Bây giờ tụi mình xem thử trọn bộ chương trình có thể nối liền nhau như một dạng tổng thể".

Tôi hỏi: "Jerry, bộ ông cũng làm như thế với chính mã nguồn của ông sao?"

Jerry quắc mắt lên và nói: "Ở đây tụi tao làm việc với nhau theo nhóm nên không có cái mã nào là của riêng tao hết. Bộ mày cho là cái mã này của riêng mày hở?"

Tôi trả lời hết sức nhỏ nhẻ: "hết nghĩ như vậy rồi, ông ảnh hưởng rất lớn đến mã nguồn này."

Gã trả lời: "Cả hai thằng mình đều ảnh hưởng đến nó, và đây là cách ông C ưa chuộng. Ông ấy không khoái bất cứ một ai làm chủ mã nguồn hết đâu. Trả lời riêng cho câu hỏi của mày: Ðúng vậy, ở đây tụi tao thực nghiệm cái "rơ" refactoring và dọn rác và đây là phương pháp của ông C."

Trong khi đọc qua mã nguồn, Jerry thấy gã không khoái cái tên initializeArrayOfIntegers.

Gã nói: "Cái được khởi tạo ở đây thực ra không phải là một dãy số nguyên, mà là một dãy booleans. Nhưng initializeArrayOfBooleans không hẳn là cách cải tiến. Ðiều chúng ta thực sự muốn làm ở method này là liệt kê ra một danh sách các số nguyên phù hợp và để chúng lên một cái sàng, rồi sau đó lọc và loại ra các số không phải số nguyên tố (ie loại ra những bội số)". (Do đó, danh sách lúc đầu sẽ không bị gạch chéo, những số bị loại sẽ sẽ bị gạch chéo (crossed out )).

Tôi trả lời: "Tất nhiên!" Thế là tôi vớ lấy bàn đánh và sửa tên của method đó thành uncrossIntegersUpTo. Tôi cũng thấy không khoái cái tên isCrossed lại dùng cho một dãy booleans, nên tôi đổi nó thành crossedOut. Các cái test vẫn chạy. Tôi bắt đầu thấy thích mấy cái trò này nhưng Jerry vẫn không hề tỏ vẻ đồng tình.

Sau đó Jerry quay lại, hỏi tôi có phải tôi đã mơ màng theo khói thuốc khi viết cái mớ maxPrimeFactor. (Xem mã dẫn 6). Thoạt đầu tôi hết sức ngỡ ngàng nhưng khi xem lại đoạn mã và các phụ chú tôi nhận thấy gã có lý. Eo ôi, tôi thấy mình thật là ngu! Căn bậc 2 (Square root )* của chiều dài một dãy số không hẳn là nguyên số. Method đó không tính thừa số nguyên tố cực đại (max prime factor) **. Phần chú giải sai bét nên, hết sức ngượng ngùng tôi viết lại phần phụ chú để giải thích rõ hơn cái căn bậc 2 này dùng để làm gì và đổi tên những biến , hàm cho thích hợp. Các test vẫn chạy.

Mã dẫn 6:

TestGeneratePrimes.java (Partial)
    private static int calcMaxPrimeFactor() {

       // We cross out all multiples of p, where p is prime.
       // Thus, all crossed out multiples have p and q for factors.
       // If p > sqrt of the size of the array, then q will never
       // be greater than 1. Thus p is the largest prime factor
       // in the array, and is also the iteration limit.

       double maxPrimeFactor = Math.sqrt(isCrossed.length) + 1;
       return (int) maxPrimeFactor;
    }

"dùng +1 ở đây làm quái gì vậy?" Jerry tru tréo lên.

Tôi nuốt cái ực, xem lại đoạn mã và cuối cùng tôi phát biểu: "Tôi ngại là khi chỉ lấy phần nguyên của căn bậc 2, thì phần thập phân của căn bậc 2 đó bị mất đi, do đó vòng lặp có thể bị thiếu."

Gã bèn hỏi: "Cho nên mày xả rác trong đoạn mã với phần gia tăng "+1" bởi vì mày bị hoảng? Như thế thì ngốc quá, dẹp ngay cái trò gia tăng "+1" đó đi và thử test lại."

Tôi làm như thế và trọn bộ các test đều chạy. Tôi suy nghĩ lại phần này một lúc vì nó làm tôi run quá. Thế nhưng tôi quyết định có thể giới hạn lặp lại thực sự chính là số "thừa số nguyên tố cực đại" và "thừa số nguyên tố" đó <= căn bậc 2 chiều dài của dãy số.

"Phần thay đổi vừa rồi làm tôi khá bối rối". Tôi nói với Jerry. "Tôi hiểu nguồn gốc đằng sau cái căn bậc 2, nhưng tôi cảm thấy không yên, biết đâu có trường hợp "biên" nào đó mình chưa thấy hết."

Gã lầm bầm "OK, vậy thì viết một cái test khác để kiểm tra chuyện đó đi."

"Tôi nghĩ tôi có thể kiểm tra xem trong các danh sách số nguyên từ 2 đến 500 không có trường hợp ở trên".

"OK, nếu nó làm cho mày cảm thấy dễ chịu hơn, thì thử đi." Gã nói. Rõ ràng là gã bắt đầu trở nên mất kiên nhẫn.

Thế là tôi viết cái testExhaustive function như trong mã dẫn 8. Phần test mới này chạy đúng và nỗi lo sợ của tôi lắng xuống.

Jerry dịu xuống một chút. Gã nói: "Biết được lý do tại sao một cái gì đó chạy được luôn luôn là một điều tốt; và lại càng tốt hơn khi mà kiểm chứng được mày đúng bằng cái test."

Sau đó Jerry dò qua trọn bộ mã nguồn và các cái tests một lần nữa (xem mã dẫn 7 và 8). Gã ngã người ra và suy nghĩ chừng một phút rồi nói: "OK, tao nghĩ là tụi mình làm xong. Mã nguồn này xem ra đủ rõ ràng (clean) rồi đó. Tao sẽ đưa cho ông C xem."

Thế rồi gã nhìn tôi, lạnh lùng nói: "Phải nhớ, từ nay về sau khi mày viết một phần nào đó, nên tìm sự giúp đỡ và nhớ giữ cho mã nguồn rõ ràng (clean). Nếu mày nhúng tay vào những thứ dưới tiêu chuẩn này, mày không "thọ" ở đây đâu."

Gã rảo bước.

Mã dẫn 7:

PrimeGenerator.java (final)
  /**
  * This class generates prime numbers up to a user specified
  * maximum. The algorithm used is the Sieve of Eratosthenes.
  * Given an array of integers starting at 2: Find the first
  * uncrossed integer, and cross out all its multiples. Repeat
  * until there are no more multiples in the array.
  */

public class PrimeGenerator {
   private static boolean[] crossedOut;
   private static int[] result;

   public static int[] generatePrimes(int maxValue) {
     if (maxValue < 2)
       return new int[0];
     else {
       uncrossIntegersUpTo(maxValue);
       crossOutMultiples();
       putUncrossedIntegersIntoResult();
       return result;
     }
   }

   private static void uncrossIntegersUpTo(int maxValue) {
     crossedOut = new boolean[maxValue + 1];
     for (int i = 2; i < crossedOut.length; i++)
       crossedOut[i] = false;
   }

   private static void crossOutMultiples() {
     int limit = determineIterationLimit();
     for (int i = 2; i <= limit; i++)
       if (notCrossed(i))
         crossOutMultiplesOf(i);
   }

   private static int determineIterationLimit() {
     // Every multiple in the array has a prime factor that is
     // less than or equal to the sqrt of the array size, so we
     // don't have to cross out multiples of numbers larger than
     // that root.
     double iterationLimit = Math.sqrt(crossedOut.length);
     return (int) iterationLimit;
   }

   private static void crossOutMultiplesOf(int i) {
     for (int multiple = 2*i; multiple < crossedOut.length;
       multiple += i)
       crossedOut[multiple] = true;
   }

   private static boolean notCrossed(int i) {
     return crossedOut[i] == false;
   }
   private static void putUncrossedIntegersIntoResult() {
     result = new int[numberOfUncrossedIntegers()];
     for (int j = 0, i = 2; i < crossedOut.length; i++)
       if (notCrossed(i))
         result[j++] = i;
   }

   private static int numberOfUncrossedIntegers() {
     int count = 0;
     for (int i = 2; i < crossedOut.length; i++)
       if (notCrossed(i))
         count++;

     return count;
   }
}

Mã dẫn 8:

TestGeneratePrimes.java (final)
import junit.framework.*;

public class TestGeneratePrimes extends TestCase {
   public static void main(String args[]) {
     junit.swingui.TestRunner.main(
       new String[] {"TestGeneratePrimes"});
   }
   public TestGeneratePrimes(String name) {
     super(name);
   }

   public void testPrimes() {
     int[] nullArray = PrimeGenerator.generatePrimes(0);
     assertEquals(nullArray.length, 0);

     int[] minArray = PrimeGenerator.generatePrimes(2);
     assertEquals(minArray.length, 1);
     assertEquals(minArray[0], 2);

     int[] threeArray = PrimeGenerator.generatePrimes(3);
     assertEquals(threeArray.length, 2);
     assertEquals(threeArray[0], 2);
     assertEquals(threeArray[1], 3);
     int[] centArray = PrimeGenerator.generatePrimes(100);
     assertEquals(centArray.length, 25);
     assertEquals(centArray[24], 97);
   }

   public void testExhaustive() {
     for (int i = 2; i<500; i++)
       verifyPrimeList(PrimeGenerator.generatePrimes(i));
   }

   private void verifyPrimeList(int[] list) {
     for (int i=0; i < list.length; i++)
       verifyPrime(list[i]);
   }

   private void verifyPrime(int n) {
     for (int factor=2; factor < n; factor++)
       assert(n%factor != 0);
   }
}

Quả là tai hoạ! Tôi cứ ngỡ là giải pháp nguyên thủy của tôi là thượng thặng. Chút gì đó tôi vẫn còn cảm thấy như vậy. Tôi cố phô trương tài năng của tôi nhưng tôi đoán là ông C đánh giá cao sự cộng tác và tính minh bạch hơn tài năng cá nhân.

Tôi phải thú nhận rằng chương trình này dễ xem hơn lúc khởi đầu. Nó lại làm việc ngon hơn một tí nữa. Tôi khá hài lòng với kết quả và, mặc dù Jerry có thái độ cộc cằn, làm việc với gã tôi cũng thấy vui. Tôi học hỏi được rất nhiều.

Dẫu vậy, tôi thấy hơi chùn bước với chính hiệu suất của tôi. Tôi không dám nghĩ là mấy tay ở đây sẽ khoái tôi cho lắm. Tôi cũng không dám chắc đến bao bao giờ họ đánh giá tôi đủ "ngon". Sự thể sẽ khó khăn hơn tôi nghĩ nhiều lắm.

* Square root hay căn số là cách gọi trước đây cho căn bậc 2, một cách gọi được dùng sau này ở VN (chú thích này dành cho những ai thắc mắc với 1 số thuật ngữ toán học xưa và nay ;))

** max prime factor hay thừa số nguyên tố cực đại (hoặc phân tố cực đại nguyên số) cũng là những thuật ngữ toán (quen dùng) trước đây. cực đại có thể dịch là tối đa nếu muốn (chú thích này một lần nữa dành cho những ai thắc mắc với 1 số thuật ngữ toán học xưa và nay ;))

Craftsman 2 - Crash Diet

2007-07-30T10:57:00.001+10:00

Trong phần trước * Jerry, một tay cựu học việc, yêu cầu Alphonse, một tay học việc, viết một chương trình tạo các số nguyên tố dùng phương pháp lượt Eratosthenes (sieve of Eratosthenes). Jerry, nhận thấy Alphonse đã cài đặt toàn bộ thuật toán vào một function "khổng lồ" nên đã yêu cầu Alphonse tách nó ra theo ba khái niệm: khởi động, thực hiện (loại bỏ các số không nguyên tố) và cho ra giá trị output (đưa ra danh sách các số nguyên tố);... nhưng Alphonse không biết phải bắt đầu từ đâu...

Gã nhìn tôi một lúc, rõ ràng đang đợi tôi làm gì đó. Nhưng rốt cuộc gã thở dài, lắc đầu, rồi nói: "Ðể mở rộng ba khái niệm rõ hơn, tao muốn mày tách chúng ra thành ba methods riêng biệt. Ðồng thời vứt hết những cái phụ chú không cần thiết và đặt một cái tên khá hơn cho cái class. Mày làm xong những thứ đó rồi, nhớ bảo đảm là mấy cái test vẫn còn chạy được."

Các bạn có thể thấy những điểm tôi đã làm trong mã dẫn 3. Tôi đã đánh dấu những thay đổi bằng chữ đậm, y hệt như Martin Fowler trình bày trong cuốn Refactoring của ông ta. Tôi đổi tên của cái class thành dạng danh từ, vứt hết những phụ chú về chuyện Eratosthenes và tạo ra ba methods từ ba khái niệm trong generatePrimes function.

Tách ra ba functions buộc tôi phải chuyển một số biến local trong cái function "khổng lồ" trước đây, thành static fields của class. Jerry nói cách này làm rõ những biến hàm nào là local và những biến hàm nào có ảnh hưởng rộng lớn hơn.

Mã dẫn 3:

PrimeGenerator.java, version 2

/**
* This class generates prime numbers up to a user-specified
* maximum. The algorithm used is the Sieve of Eratosthenes.
* Given an array of integers starting at 2: Find the first
* uncrossed integer, and cross out all its multiples. Repeat
* until the first uncrossed integer exceeds the square root of
* the maximum value.
*/
import java.util.*;

public class PrimeGenerator {
private static int s;
private static boolean[] f;
private static int[] primes;

public static int[] generatePrimes(int maxValue) {
if (maxValue < 2)
return new int[0];
else {
initializeSieve(maxValue);
sieve();
loadPrimes();
return primes; // return the primes

}
}

private static void loadPrimes() {{{/b}
int i,j;

// how many primes are there?
int count = 0;
for (i = 0; i < s; i++) {
if (f[i])
count++; // bump count.
}

primes = new int[count];

// move the primes into the result
for (i = 0, j = 0; i < s; i++) {
if (f[i]) // if prime
primes[j++] = i;
}
}

private static void sieve() {{{/b}
int i,j;
for (i = 2; i < Math.sqrt(s) + 1; i++) {
// if i is uncrossed, cross out its multiples.
if (f[i]) {
for (j = 2 * i; j < s; j += i)
f[j] = false; // multiple is not prime
}
}
}

private static void initializeSieve(int maxValue) {{{/b}
// declarations
s = maxValue + 1; // size of array
f = new boolean[s];

// initialize array to true.
for (int i = 0; i < s; i++)
f[i] = true;

// get rid of known non-primes
f[0] = f[1] = false;
}
}

Jerry bảo tôi mã này hơi lộn xộn, nên gã giành lấy bàn đánh và chỉ tôi cách dọn dẹp. . Mã dẫn 4 minh hoạ những gì gã đã làm. Thoạt tiên gã vứt đi cái biến hàm s trong initializeSieve và thay thế nó bằng f.length. Sau đó gã đổi tên của ba functions (theo kiểu) gã cho là có ấn tượng hơn. Cuối cùng gã sắp xếp lại cái "bộ lòng" initializeArrayOfIntegers (từ initializeSieve) để cho dễ đọc hơn một chút. Các cái test vẫn chạy nhưng thường.

Mã dẫn 4:
PrimeGenerator.java, version 3 (partial)

public class PrimeGenerator {
private static boolean[] f;
private static int[] result;

public static int[] generatePrimes(int maxValue) {
if ((maxValue < 2)
return new int[0];
else {
initializeArrayOfIntegers(maxValue);
crossOutMultiples();
putUncrossedIntegersIntoResult();
return result;
}
}

private static void
initializeArrayOfIntegers(int maxValue) {
f = new boolean[an[maxValue + 1];
f[0] = f[1] = false; //neither primes nor multiples.
for (int i = 2; i < f.length; i++)
f[i] = true;
}

Tôi phải công nhận mã này rõ hơn một chút. Trước giờ tôi nghĩ tạo functions có tên sinh động là phí thời giờ , nhưng những chỉnh đổi của gã quả thật làm cho mã nguồn dễ đọc hơn.

Tiếp theo Jerry trỏ vào crossOutMultiples, nói là gã nghĩ cụm if(f[i] == true) có thể làm cho dễ đọc hơn nữa. Tôi nghĩ đến điểm này chừng một phút. Ý định của các cụm này dùng để kiểm tra xem i không bị loại trừ; thế là tôi đổi tên của f thành unCrossed.

Jerry nói mã này coi được hơn nhưng vẫn chưa vừa ý vì nó dẫn đến khả năng phủ định đôi (double negative) như unCrossed[i] = false. Bởi thế gã đổi tên của dãy số thành dãy isCrossed. Các cái test vẫn chạy được.

Jerry bỏ qua phần khởi động : gán cho isCrossed[0] và isCrossed[1] giá trị true . Gã nói, chúng ta có thể giả sử không chỗ nào của thuật toán dùng dãy isCrossed với với chỉ số nhỏ hơn 2 . Các cái test vẫn chạy được.

Jerry tách phần lặp bên trong (inner loop) của crossOutMultiples function và gọi nó là crossOutMultipleOf. Gã bảo rằng các cụm tương tự như if (isCrossed[i] == false) dễ nhầm lẫn nên gã tạo ra function có tên notCrossed và thay cụm if thành if (notCrossed(i)). Kết tiếp gã chạy thử mấy cái test lại.

Sau đó Jerry hỏi tôi ý nghĩa của phần số căn đó là gì. Tôi tốn một ít thời giờ viết phụ chú giải thích tại sao cần phải lặp lại cho đến phần số căn của chiều dài dãy số. Tôi cố tranh đua với Jerry bằng cách tách phần tính toán thành một function, nơi tôi có thể đưa vào phần phụ giải. Trong khi viết ghi chú tôi nhận ra rằng căn số là thừa số nguyên tố cực đại của một số bất kỳ trong một dãy số. Bởi thế để ứng phó, tôi chọn cách gọi đó (maxValue) cho các biến, hàm. Cuối cùng tôi bảo đảm các tests vẫn chạy được. Kết quả của các thay đổi trong mã dẫn 5.

Mã dẫn 5:

PrimeGenerator.java version 4 (partial)
public class PrimeGenerator {
private static boolean[] isCrossed;
private static int[] result;

public static int[] generatePrimes(int maxValue) {
if (maxValue < 2)
return new int[0];
else {
initializeArrayOfIntegers(maxValue);
crossOutMultiples();
putUncrossedIntegersIntoResult();
return result; }
}

private static void
initializeArrayOfIntegers(int maxValue) {
isCrossed = new boolean[maxValue + 1];
for (int i = 2; i < isCrossed.length; i++)
isCrossed[i] = false;
}

private static void crossOutMultiples() {
int maxPrimeFactor = calcMaxPrimeFactor();
for (int i = 2; i <= maxPrimeFactor; i++)
if (notCrossed(i))
crossOutMultiplesOf(i);
}

private static int calcMaxPrimeFactor() {
// We cross out all multiples of primes. Thus, all crossed
// out multiples have p and q for factors. If p > sqrt of the
// size of the array, then q will never be greater than 1.
// Thus p is the largest prime factor in the array, and is
// also the iteration limit.
double maxPrimeFactor = Math.sqrt(isCrossed.length) + 1;
return (int) maxPrimeFactor;
}

private static void crossOutMultiplesOf(int i) {
for (int multiple = 2*i; multiple < isCrossed.length;
multiple += i)
isCrossed[multiple] = true;
}

private static boolean notCrossed(int i) {
return isCrossed[i] == false;
}

Tôi bắt đầu nắm bắt được vấn đề nên liền xét lại method xét lại method putUncrossedIntegersIntoResult. Tôi thấy rằng method này có hai phần. Phần thứ nhất đếm các số nguyên không bị loại trong dãy số, và tạo nên dãy kết quả (bằng chiều dài của dãy số). Phần thứ nhì dời các số nguyên không bị loại vào dãy kết quả này. Bởi thế, như bạn thấy trong mã dẫn 6, tôi tách phần thứ nhất ra để hình thành function cho chính nó và dọp dẹp lặt vặt đôi chút. Các tests vẫn chạy được. Jerry chỉ thoáng gật đầu. Gã có thật sự khoái những điều tôi đã thực hiện không?

Mã dẫn 6:

PrimeGenerator.java, version 5 (partial).
private static void putUncrossedIntegersIntoResult() {
result = new int[numberOfUncrossedIntegers()];
for (int j = 0, i = 2; i < isCrossed.length; i++)
if (notCrossed(i))
result[j++] = i;
}

private static int numberOfUncrossedIntegers() {
int count = 0;
for (int i = 2; i < isCrossed.length; i++)
if (notCrossed(i))
count++;
return count;
}

* Trong nguyên bản là "In the last month's column..." nhưng ở đây tạm dịch thoáng ra là "trong phần trước" cho phù hợp với tinh thần các bài craftsman được post lên (không theo tháng mà theo... tùy hứng của người dịch)

Craftsman 1 - Opening Disaster

2007-07-18T08:47:00.000+10:00

The crafsman One.
Robert C. Martin
13 Tháng 2, 2002

Bài viết này lược trích từ chương Principles, Patterns and Practices trong cuốn Agile Software Development của Robert C. Martin, nhà xuất bản Prentice Hall, 2002.

Nhật ký thân mến,
13 tháng 2, 2002.

Hôm nay đúng là một ngày xui xẻo - Tôi làm hỏng cả chuyện. Tôi rất muốn gây ấn tượng với các ngài "cựu học việc" ở đây nhưng rút cuộc chỉ làm rối tung cả lên.

Ðó là ngày đầu tiên tôi được một chân học việc với ông C. Tôi quả là may mắn có được chân học việc này. Ông C là một tay trùm lớp lang trong vấn đề phát triển phần mềm. Ðấu để giành được chân việc này đúng là nẩy lửa. Các tay học việc của ông C thường trở nên các tay "cựu học việc" sáng giá. Ðiều này có nghĩa được làm việc với ông C có giá trị rõ ràng.

Tôi cứ ngỡ là hôm nay tôi sẽ được gặp ông ta nhưng thay vì đó tôi bị một gã "cựu học việc" níu tôi qua một bên. Gã bảo ông C luôn luôn dẫn các tay học việc đi xuyên qua phần định hướng trong những ngày đầu. Gã nói ông C nhất quyết cho rằng phần thực tập định hướng là thiết thực với các tay học việc và nó dẫn đến mức chất lượng mã nguồn mà ông ta ta dự tưởng.

Tôi náo nức kinh khủng. Ðây là một cơ hội cho họ thấy tôi là một tay lập trình "ngon" cỡ nào. Thế là tôi bảo Jerry tôi không chờ được nữa. Gã đáp lại sự náo nức của tôi bằng cách bảo tôi thử viết một chương trình đơn giản cho gã. Gã muốn tôi dùng "Sieve of Eratosthenes" để tính các số nguyên tố. Gã còn bảo tôi phải chuẩn bị xong chương trình bao gồm trọn bộ các "unit tests" sẵn sàng để "chấm" sau buổi ăn trưa.

Thật là khoái! Tôi có gần 4 tiếng đồng hồ để "xào nấu" một chương trình giống như Sieve. Tôi quyết tâm thực hiện công tác này một cách hết sức có ấn tượng. Mã dẫn 1 đưa ra những gì tôi đã viết. Tôi nắm chắc là chương trình của tôi được chú thích cẩn thận và trình bày gọn gàng.

Mã dẫn 1:

/**
* This class generates prime numbers up to a user-specified maximum.
* The algorithm used is the Sieve of Eratosthenes.
* <p>
* Eratosthenes of Cyrene, b. c. 276 BC, Cyrene, Libya; d. c. 194 BC, Alexandria. He was
* the first man to calculate the circumference of the Earth, and was also
* known for working on calendars with leap years and running the library at
* Alexandria.</p>
*
* The algorithm is quite simple: Given an array of integers starting at 2,
* cross out all multiples of 2. Find the next uncrossed integer, and cross
* out all of its multiples. Repeat until you have passed the square root of
* the maximum value.
*
* @authorAlphonse, @version 13 Feb 2002 atp
*/
import java.util.*;

public class GeneratePrimes {
/**
* @param maxValue is the generation limit.
*/
public static int[] generatePrimes(int maxValue) {
if (maxValue >= 2) { // the only valid case
// declarations
int s = maxValue + 1; // size of array
boolean[] f = new boolean[s];
int i;

// initialize array to true.
for (i = 0; i < s; i++)
f[i] = true;

// get rid of known non-primes.
f[0] = f[1] = false;

// sieve
int j;
for (i = 2; i < Math.sqrt(s) + 1; i++) {
if (f[i]) { // if i is uncrossed, cross its multiples.
for (j = 2 * i; j < s; j += i)
f[j] = false; // multiple is not prime
}
}

// how many primes are there?
int count = 0;
for (i = 0; i < s; i++) {
if (f[i])
count++; // bump count.
}
int[] primes = new int[count];

// move the primes into the result.
for (i = 0, j = 0; i < s; i++) {
if (f[i]) // if prime
primes[j++] = i;
}

return primes; // return the primes.
} else // maxValue < 2
return new int[0]; // return null array if bad input.
}
}

Sau đó tôi viết một cái "unit test" cho GeneratePrimes. Xem ở mã dẫn 2. Ðoạn mã này dùng JUnit framework như Jerry đã chỉ dẫn. Nó dùng tính chất hướng thống kê; kiểm tra xem cái "generator" có thể tạo ra các số nguyên tố tới 0, 2, 3 và 100. Trong trường hợp thứ nhất hẳn không có số nguyên tố nào cả. Trong trường hợp thứ nhì hẳn phải có một số nguyên tố và nó phải là số 2. Trường hợp thứ ba phải có hai số nguyên tố và chúng phải là số 2 và 3. Trường hợp cuối phải là 25 số nguyên tố và số cuối phải là 97. Nếu các bước kiểm tra đều đúng, tôi giả định là cái "generator" làm việc đúng. Tôi e rằng khó có thể tin cậy tuyệt đối cách ở trên, nhưng tôi không nghĩ ra được một trường hợp nào một "function" có thể bị hỏng mà các bước kiểm tra đều đúng.

Mã dẫn 2:

import junit.framework.*;
import java.util.*;

public class TestGeneratePrimes extends TestCase {
public static void main(String args[]) {
Junit.swingui.TestRunner.main(
new String[] {"TestGeneratePrimes"});
}
public TestGeneratePrimes(String name) {
super(name);
}

public void testPrimes() {
int[] nullArray = GeneratePrimes.generatePrimes(0);
assertEquals(nullArray.length, 0);

int[] minArray = GeneratePrimes.generatePrimes(2);
assertEquals(minArray.length, 1);
assertEquals(minArray[0], 2);

int[] threeArray = GeneratePrimes.generatePrimes(3);
assertEquals(threeArray.length, 2);
assertEquals(threeArray[0], 2);
assertEquals(threeArray[1], 3);

int[] centArray = GeneratePrimes.generatePrimes(100);
assertEquals(centArray.length, 25);
assertEquals(centArray[24], 97);
}
}

Tôi mất khoảng một giờ đồng hồ để làm những bước trên chạy được. Jerry không muốn gặp tôi cho đến sau buổi ăn trưa, bởi thế, tôi dành trọn bộ thời gian còn lại đọc cuốn Design Patterns mà Jerry đưa cho tôi.

Sau buổi ăn trưa, tôi ghé văn phòng của Jerry và cho gã biết tôi đã thực hiện xong chương trình. Gã nhìn tôi và với một nụ cười khó tả, hắn nói: "Ðược lắm, hãy xem thử nó thế nào."

Gã dẫn tôi và phòng thí nghiệm và cho tôi ngồi trước một máy. Gã ngồi bên cạnh tôi và yêu cầu tôi đưa chương trình của tôi vào máy này. Thế là tôi chuyển mã nguồn từ máy laptop của tôi lên.

Jerry xem xét hai mã nguồn chừng năm phút rồi gã lắc đầu và bảo: "Mày không thể đưa những cái này cho ông C xem được! Nếu tao để ổng xem mấy cái này, ổng sẽ đuổi cổ cả tao lẫn mày. Ông ấy không phải là người kiên nhẫn đâu."

Tôi đánh thót một phát nhưng cố giữ bình tĩnh và hỏi gã: "Chớ nó sai chỗ nào?"

Jerry thở dài và nói: "Tụi mình nên đi xuyên qua mã nguồn này với nhau." "Tao sẽ chỉ cho mày từng điểm một cách ông C muốn thực hiện nó như thế nào."

"Quá rõ ràng", gã tiếp tục, "cái main function muốn làm ra ba cái functions riêng biệt. Cái thứ nhất khởi tạo tất cả các biến hàm và thiết lập cái "sieve". Cái thứ nhì thực sự thi hành cái "sieve" và cái thứ ba tải kết quả của "sieve" vào một dãy số nguyên tố."

Tôi nhận ra được ý gã muốn nói gì. Có ba khái niệm chôn trong cái function đó. Tuy vậy, tôi không biết gã muốn tôi phải làm gì với nó.

Gã nhìn tôi một lúc, rõ ràng đang đợi tôi phản ứng sao đó. Nhưng rốt cuộc gã thở dài, lắc đầu và....

Qmail as a Mail Gateway - Phần cuối

2007-07-17T08:28:00.000+10:00

5. Ðiều chỉnh sau khi cài đặt

Trước đây, khi Internet còn giới hạn (chỉ phổ biến giữa các trường đại học và các nhóm nghiên cứu và rất ít người dùng bình thường), mail là một phương tiện tuyệt vời để liên lạc và trao đổi. Tính thương mại hoá hầu như chưa có cho đến khi loạt “SPAM” đầu tiên xuất hiện đã biến Internet mail trở nên một vấn đề gần như nan giải đối với các loạt mail “vô chủ” chuyên để quảng cáo.

Có hai trường hợp thường xảy ra trong vấn nạn “SPAM” đó là:
- Bị biến thành phương tiện để “SPAM” những nạn nhân khác nếu mail server không được điều chỉnh và kiểm soát đúng mức (bị relay).

- Bị “SPAM” (bom thư).

5.1 Chiến thuật relaying điện thư (để không biến mail server của mình trở thành phương tiện để “SPAM”
5.1.1 Tại sao cần relay?
Như đã đề cập đến trong phần 3.5 (Bộ quản trị SMTP Access Control), có những trường hợp bạn cần cho phép mail gateway của mình relay mail vì lý do nào đó (chuyển nhận mail dùng cho công ty bạn hoặc mail server của bạn dùng để relay mail cho nhiều domain khác nhau như một mail server của ISP). Nói một cách ngắn gọn, khả năng “mail relaying”của một mail server A là khả năng tiếp nhận mail từ host X và chuyển gởi mail này đến host Y hoặc những host nào đó trong chế độ định sẵn mà mail server phải đảm nhiệm.

5.1.2 Chuyện gì xảy ra nếu không relay?
Nếu mail gateway của bạn chỉ dành phục vụ cho một domain riêng của bạn thì vấn đề relay không còn cần thiết nữa và quyết định hoàn toàn không relay là cách an toàn nhất để ngăn ngừa trường hợp mail gateway của bạn bị biến thành một phương tiện để SPAM.

5.1.3 Cho phép relaying theo lựa chọn
Trong phần 3.5 đã đi sâu vào chi tiết sắp xếp cho phép relay một cách chọn lọc, một trong những variables cần phải chú tâm đến là: allow,RELAYCLIENT. Nên xem xét một cách kỹ lưỡng các giá trị “RELAYCLIENT” để nắm chắc bạn đã không cho phép một “client” nào đó được phép relay vì sơ ý.

5.1.4 Thử nghiệm relaying bằng tcprulescheck
Trong nhóm “ucspi-tcp” có một chương trình gọi là tcprulescheck cho phép bạn kiểm tra các “luật” relay trước khi ứng dụng Qmail như một mail relay server thực sự. tcprulescheck dùng 2 variables của môi trường để kiểm tra các “luật” relay, đó là: TCPREMOTEIP và TCPREMOTEHOST. Bạn có thể thay đổi các variables này cho quy trình kiểm tra.

Sau đây là một ví dụ đơn giản quy trình kiểm tra các “luật” relay bằng tcprulescheck. Giả sử chúng ta dùng ví dụ qmail-rules.txt từ phần 3.5.

127.:allow,RELAYCLIENT=””
192.168.1.:allow,RELAYCLIENT=””
10.10.10.50:allow,RELAYCLIENT=””
spamboy@spamhouse.com:deny
badhost.net:deny
.:deny

Chúng ta thử “cat” qmail-rules.txt và “pipe” nó xuyên qua chương trình tcprules để tạo ra hash của các rules thuộc “qmail-rules.txt” (nên nhớ smtpd daemon dùng hash của qmail-rules.txt, đó là hồ sơ tcp.smtp.cdb, nó không bao giờ dùng nguyên bản cleartext qmail-rules.txt):
# cat /etc/smtprules/qmail-rules.txt | tcprules /etc/tcp.smtp.cdb

Hash của các rules được chứa trong hồ sơ tcp.smtp.cdb và chúng ta sẽ dùng hồ sơ này để kiểm tra các “luật” relay.

a. Lệnh $ tcprulescheck /etc/tcp.smtp.cdb sẽ cho kết quả:
rule:
deny connection
Trường hợp ở trên tcprulescheck dùng giá trị mặc định (default) của “qmail-rules.txt” đó là .:deny. Bất cứ truy cập nào vào mail relay server của bạn, đầu tiên nó sẽ dùng giá trị mặc định để “deny” trước và sau đó dựa trên IP hoặc hostname của nơi gởi mail mà định đoạt “số phận” của mail này.

b. Thử lệnh trên một lần nữa trước khi chỉnh variable TCPREMOTEIP là 10.10.10.50 như đã cho phép trong “qmail-rules.txt” ở trên:
$ TCPREMOTEIP=10.10.10.50 ; export TCPREMOTEIP
$ tcprulescheck /etc/tcp.smtp.cdb sẽ cho kết quả:
rule: 10.10.10.50:
set environment variable RELAYCLIENT=
allow connection

Ở trên cho thấy qmail chấp nhận TCPREMOTEIP là 10.10.10.50 là vì IP này đã thuộc trong danh sách qmail-rules.txt và được thiết lập ở chế độ allow,RELAYCLIENT nên tcprulescheck trả lời: allow connection.

c. Thử lệnh trên với TCPREMOTEIP mang giá trị khác, giả sử như badhost.net có IP là 172.173.174.175 (được thiết lập ở chế độ deny trong qmail-rules.txt)
$ TCPREMOTEIP=172.173.174.175 ; export TCPREMOTEIP
$ tcprulescheck /etc/tcp.smtp.cdb sẽ cho kết quả:
rule: badhost.net:
deny connection

Ở trên cho thấy Qmail từ chối không nhận mail muốn được chuyển nhận đến server 172.173.174.175 (IP của badhost.com trong ví dụ này) vì địa chỉ này được ấn định là deny.

Cứ như vậy, bạn đi xuyên qua mỗi “rule” trong qmail-rules.txt để kiểm tra chức năng relay của các rules.

5.1.5 Thử nghiệm relaying bằng “telnet”
Phương pháp dùng “telnet” để truy cập vào một mail server ở port 25 (SMTP port) có lẽ là một phương pháp cổ điển và phổ biến nhất để kiểm tra tính năng “relay” của nó. Ðây cũng là một trong những phương pháp các tay chuyên tìm kiếm “open relay” để có thể SPAM, tất nhiên không bằng cách “telnet” từng mail server mà bằng cách “tự động hoá” qua một dạng scripting nào đó để có thể đi xuyên qua hàng loạt mail server trong một khoảng thời gian ngắn.

Ở đây tôi sẽ đưa ra hai ví dụ đơn giản để kiểm tra tính năng “relay” của mail server của bạn. Ðòi hỏi đơn giản chỉ cần có chương trình “telnet” trong máy. Tính năng “relay” dựa trên hồ sơ “rcpthosts” (trong phần 4.2.7) có các giá trị như sau:
mail.mydomain.com
exchange1.mydomain.com
exchange2.mydomain.com
mydomain.net
mail.myfriend.com

Khởi động telnet trên một command prompt (Windows hoặc *nix tùy chọn). Giả sử mail gateway server của tôi có địa chỉ là 192.168.1.200 với hostname là mail.mydomain.com chẳng hạn, tôi sẽ làm các bước như sau:

1 telnet 192.168.1.200 25
2 220 My company mail server - Welcome ESMTP
3 HELO
4 250 My company mail server – Welcome
5 MAIL FROM: <spamboy@spamhouse.com>
6 250 ok
7 RCPT TO: <reciepient@someonecompany.com>
8 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

Dòng 1: Dùng telnet với các thông số là IP 192.168.1.200 và SMTP port 25.

Dòng 2: Nếu mail server của tôi đang hoạt động bình thường, tôi sẽ nhận được lời chào (bạn còn nhớ hồ sơ “smtpgreeting” trong phần 4.2.8? đây chính là lời chào lấy từ hồ sơ “smtpgreeting” này).

Dòng 3: Tôi thử lệnh HELO, một lệnh căn bản của SMTP.

Dòng 4: Mail server của tôi sẽ trả lời với thông điệp lấy từ “smtpgreeting”.

Dòng 5: Tôi “mạo danh” là spamboy@spamhouse.com qua lệnh MAIL FROM:

Dòng 6: Mail server trả lời 250 ok bởi vì tôi chưa cho mail server của tôi biết là người nhận sẽ là ai và người nhận thuộc domain nào.

Dòng 7: Tôi dùng lệnh RCPT TO: và cho mail server biết người nhận là reciepient thuộc domain someonecompany.com; một domain không hề có trong rcpthosts.

Dòng 8: Qmail sẽ từ chối ngay lập tức.

Hãy thử kiểm tra relaying bằng telnet dùng các giá trị người nhận thuộc domain có trong hồ sơ “rcpthosts”. Quy trình này tương tự như sau:

1 telnet 192.168.1.200 25
2 220 My company mail server - Welcome ESMTP
3 HELO
4 250 My company mail server – Welcome
5 MAIL FROM: <spamboy@spamhouse.com>
6 250 ok
7 RCPT TO: <someone@mydomain.net>
8 250 ok
9 DATA
10 354 go ahead
11 From: spamboy@spamhouse.com
12 To: someone@mydomain.net
13 Subject: a relay test
14 This is only a test for open relay
15 .
16 250 ok 1041050865 qp 12150
17 QUIT
18 221 My company mail server – Welcome
19
20 Connection to host lost.

Dòng 1 đến dòng 6: tương tự như ví dụ ở trên

Dòng 7: Lệnh RCPT TO: gởi đến người nhận thuộc domain mydomain.net, domain này có trong danh sách rcpthosts

Dòng 8: Mail server tiếp nhận và trả lời với SMTP code 250. Sở dĩ mail server tiếp nhận trong trường hợp này là vì domain mydomain.net hiện diện trong rcpthosts

Dòng 9: Lệnh DATA để báo với mail server dự định gởi thông điệp

Dòng 10: Mail server tiếp nhận và trả lời với SMTP code 354

Dòng 11 đến dòng 13: Các “message header” From, To và Subject thông thường để mail client có thể hiển thị những thông tin này

Dòng 14: Nội dung của thông điệp. Nội dung này có thể trải ra thành nhiều dòng nếu cần

Dòng 15: Dấu chấm (.) để kết thúc thông điệp

Dòng 16: Mail server trả lời kết thúc một “xuất” gởi thông điệp

Dòng 17: Lệnh QUIT dùng để dừng truy cập đến mail server bằng telnet

Dòng 18: Mail server trả lời với SMTP code 221, ngưng truy cập vào mail server thành công

Dòng 19 và dòng 20: Dòng trống trên console và thông điệp telnet báo không còn truy cập đến mail server nữa.

Ở trên bạn thấy người gởi “spamboy@spamhouse.com” vẫn có thể gởi mail đến “someone@mydomain.net” vì domain mydomain.net hiện diện trong hồ sơ “rpcthost”. Nếu trong hồ sơ “qmail-rules.txt” có dữ kiện dùng để “deny” người gởi này, chắc chắn mail ở trên không thể đi vào mail server của bạn được. Ví dụ trên một phần nào minh hoạ quan hệ giữa “qmail-rules.txt” và “rcpthosts” trên phương diện chống relay và chống spam.

Qua hai phần thử nghiệm 5.1.4 và 5.1.5 chúng ta có thể rút tỉa được một số điểm quan trọng như sau:

- Hồ sơ “qmail-rules.txt” dùng để xác định các host được phép relay và được phép dùng mail gateway để chuyển mail. Nó còn có trách nhiệm giúp Qmail quyết định mail đến và đi từ các host nào sẽ có số phận ra sao. Ðịnh nghĩa ÐẾN và ÐI ở đây có nghĩa là mail đi từ bên ngoài domain của bạn hoặc bên ngoài những domain bạn cho phép relay. Ngoài hồ sơ “badmailfrom” (xem lại trong phần 4.2.6), “qmail-rules.txt” là nơi để xác định những domains, hosts và các e-mail bạn không muốn tiếp nhận (qua phương thức :deny).

- Hồ sơ “rpcthost” dùng để xác định các domain nào được Qmail relay server giao chuyển mail. Ðiều này có nghĩa, Qmail dựa trên những dữ liệu của “rpcthosts” để tiếp nhận mail từ một nơi nào đó đến một mail server nào mà nó đã chịu trách nhiệm relay.

5.2 Chiến thuật chống bom thư với Qmail
Các bước 5.14 và 5.1.5 ở trên dùng để kiểm tra lại những lỗ hổng “relay” trên bình diện mail gateway được dùng để relay (hoặc mail gateway được làm phương tiện để spam các hòm thư). Hồ sơ “qmail-rules.txt” có thể dùng để quy định những e-mail, domains hoặc một chuỗi địa chỉ bạn không muốn nhận mail. Ðây là có thể là một cách chống bom thư nhưng thiếu tính “tự động hoá” vì bạn phải thường xuyên theo dõi, cập nhật các dữ kiện trong hồ sơ này.

Ðể nâng cao khả năng chống bom mail với tính “tự động hoá”, trong phần này chúng ta bàn về vấn đề dùng các RBL (realtime black list) database phối hợp với “qmail-rules.txt” để chống bom thư một cách hữu hiệu hơn.

Trong phần 3.4.2 trước đây, chúng ta nói đến chương trình “tcpserver” được sử dụng trong script “run” cho qmail-smtpd. Hãy xem lại đoạn script chạy “tcpserver” của phần 3.4.2:

#!/bin/sh
# concurincoming is not standard qmail control file
# it is created manually to specify the allowed concurrent incoming messages
#
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurincoming`
if [ -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" ]; then
echo QMAILDUID, NOFILESGID, or MAXSMTPD is not set in
echo /var/qmail/supervise/qmail-smtpd/run
echo “Have you set qmaild UID & qmaild GID yet?”
exit 1
fi
exec /usr/local/bin/softlimit -m 6291456 \
/usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /var/qmail/bin/qmail-smtpd 2>&1

Ở trên tcpserver chỉ dùng “tcp.smtp.cdb”, hồ sơ này được “hash” từ “qmail-rules.txt” để chống relay và bom thư theo dạng đơn giản. Cũng với cơ chế này, chúng ta có thể dùng “rblsmtpd” cùng với “tcpserver” để báo cho qmail server biết nó có trách nhiệm phải kiểm tra các mail đi xuyên qua mail gateway có thuộc dạng “SPAM” trước khi được chấp nhận. Phương thức kiểm tra bằng cách đối chiếu dữ kiện ở một trong những RBL servers. Có một số RBL database miễn phí trên internet. Có hai RBL cá nhân tôi dùng là: ordb.org và osirusoft.com (bạn có thể đọc thêm một số tin tức về RBL từ hai site này).

Cách dùng rblsmtpd trong script run của “qmail-smtpd” đơn giản như sau:

exec /usr/local/bin/softlimit -m 6291456 \
/usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -r relays.ordb.org -r relays.osirusoft.com /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1

Chương trình rblsmtpd ở trên dùng hai tham số “relays.ordb.org” và “relays.osirusoft.com” chính là hai RBL database mà qmail phải đối chiếu mỗi khi nhận mail vào. Nếu Qmail nhận được dữ kiện từ một trong hai RBL database trên cho biết mail nào đó thuộc dạng “SPAM”, nó sẽ không tiếp nhận. Bạn có thể thêm các tham số cho rblsmtpd tùy thích.

Có lẽ bạn sẽ tự hỏi: vậy cứ mỗi lần mail đi vào đều phải được kiểm tra từ RBL thì chắc phải chậm lắm? Ðây là câu hỏi đã được đặt ra nhiều lần. Cá nhân tôi không thấy mức độ hoạt động của Qmail giảm sút khi đi qua giai đoạn kiểm tra này vì thật sự đây chỉ là một quy trình đối chiếu đơn giản. Nói cho cùng, dẫu có chậm hơn một tí vẫn còn nhanh hơn thời gian bạn phải ngồi xoá những bom thư bằng tay.

Một điểm cần lưu ý khi dùng các RBL database là nên theo dõi sự hiện diện của các RBL này. Lý do, các RBL này thường hoạt động theo tính thiện nguyện trên căn bản không lợi nhuận hoặc rất ít lợi nhuận nên tính trường tồn của chúng có phần bấp bênh. Nếu một trong những RBL bạn đang dùng không còn tồn tại thì nên cập nhật run script của “qmai-smtpd” nếu muốn duy trì nhiệm vụ kiểm tra SPAM của rblsmtpd. Tất nhiên bạn cũng có thể dùng RBL thương mại (phải trả tiền để dùng RBL database). Ðể cho tiện theo dõi, đây là danh sách cách RBL dabase cho chính Dan Bernstein, người viết Qmail và các phần mềm ứng dụng cho Qmail: http://cr.yp.to/ucspi-tcp/rblsmtpd.html

Hy vọng bạn sẽ hình thành một mail relay server bằng Qmail một cách hữu hiệu và tiện ích.

(hnd - 13/1/2003)

Qmail as a Mail Gateway - Phần 4

2007-07-09T10:33:00.000+10:00

4. Hồ sơ điều chỉnh của Qmail trong “qmail-control”
Có 28 hồ sơ thuộc thư mục “qmail-control”để đối ứng với tất cả mọi hoạt động của Qmail (và các phân bộ của Qmail). Ðối với trường hợp ứng dụng Qmail như một mail relay server, bạn không cần dùng trọn bộ 28 hồ sơ này. Ở đây, tôi sẽ dẫn ra trọn bộ 28 hồ sơ và phân nhóm chúng để dễ hiểu hơn.

4.1 Danh mục các hồ sơ trong “qmail-control”

Hồ sơ control Thuộc vào chương trình

badmailfrom qmail-smtpd
databytes
localiphosts
morercphosts
rcpthosts
smtpgreeting
timeoutsmtpd

defaultdomain qmail-inject
defaultroot
idhost
plusdomain

bouncefrom qmail-send
bouncehost
concurrencylocal (concurincoming)
concurrencyremote
doublebouncehost
doublebounceto
envnoathost
locals
me
percenthack
queuelifetime
virtualdomains

qmqpservers qmail-qmqpc

helohost qmail-remote
smtproutes
timeoutconnect
timeoutremote

4.2 Danh mục các hồ sơ trong “qmail-control” cần thiết cho Qmail relay server:
Ngoại trừ bạn dùng Qmail để thiết lập một mail server hạng nặng và muốn xử dụng tối đa chức năng của mỗi chương trình trong Qmail suite, bạn sẽ hiếm khi phải xử dụng tới trọn bộ 28 hồ sơ ở trên. Với trường hợp Qmail là một relay server, bạn không cần quá một chục hồ sơ trong nhóm các hồ sơ thuộc “qmail-control”. Sau đây là danh sách các hồ sơ tôi dùng cho “qmail-control” và nội dụng của từng hồ sơ để giúp bạn hình dung dễ dàng hơn chức năng của từng hồ sơ:

4.2.1 Hồ sơ “me” thuộc qmail-send:
- Hồ sơ “me” là khởi điểm cho mọi hoạt động của Qmail, thiếu nó Qmail sẽ không chạy. Hồ sơ này được tạo ra từ bước 2.4.4 khi bạn chạy lệnh ./config để thiết lập hostname cho mail server của bạn. Hồ sơ này chỉ có một dòng chỉ định cho domain entry của mail relay server.

- Nội dung của hồ sơ này có dạng: mail.mydomain.com, trong đó: mail là hostname của mail relay server, mydomain.com là fully qualified domain name bạn có.

4.2.2 Hồ sơ “locals” thuộc qmail-send:
- Hồ sơ này dùng để chỉ định các địa chỉ e-mail được xem là “local” đối với mail relay server. Nếu không có entry nào trong “locals” thì qmail-send cho rằng chỉ có mỗi host trong “me” thuộc local. Trường hợp dùng Qmail như một mail relay server không cần “locals” nữa, nếu có, hồ sơ “locals” này có một dòng chỉ định y hệt như “me” vậy thôi.

4.2.3 Hồ sơ “concurincoming”(hay còn gọi là concurrencylocal) thuộc qmail-send:
- Hồ sơ này ấn định số lượng mail được chuyển giao cùng một lúc. Default có giá trị là 10, với giá trị này, Qmail đủ sức chuyển giao mail cho một server cỡ nhỏ đến cỡ trung. Nên tránh dùng giá trị quá nhỏ để đề phòng trường hợp bị “denial attack”. Tôi dùng giá trị là 20 cho một văn phòng cỡ 100 nhân viên (khoảng 140 e-mails tổng cộng, bao gồm các e-mail chung cho từng nhóm nhân viên).

4.2.4 Hồ sơ “defaultdomain” thuộc qmail-inject:
- Hồ sơ này dùng như một dạng bản mẫu, nếu vì một lý do gì đó mail client không dùng trọn bộ tên người dùng + tên domain như một e-mail thông thường ví dụ: me@mycom.com mà chỉ có tên người dùng là me thì “defaultdomain” được qmail dùng để “gắn” thêm cái đuôi tên domain trước khi nó gởi mail ra ngoài. Nếu qmail không tìm thấy “defaultdomain” nó sẽ tự động dùng entry trong hồ sơ “me” ở trên. Hồ sơ này không quá cần thiết, sự hiện diện của nó thường để loại trừ trường hợp mail client không gởi “sender” đúng và dùng để giao chuyển giữa các mail account trong cùng mail relay server.

- Hồ sơ này chỉ đơn giản có 1 entry là domain name của bạn, ví dụ: mycompany.com

4.2.5 Hồ sơ “queuelifetime” thuộc hồ sơ qmail-send:
- Hồ sơ này dùng để chỉ định thời gian (tính theo đơn vị giây) mail được giữ trong mail queue (vì lý do gì đó không chuyển gởi được) trước khi bị xoá. Khi mail đợi trong queue đến hạn cuối của “queuelifetime”, qmail sẽ chuyển gởi mail đó lần cuối trước khi thực sự xoá nó khỏi mail queue (nếu mail này vẫn không thể chuyển giao được).

- Giá trị default của hồ sơ “queuelifetime” là 604800 giây (tương đương với 1 tuần lễ). Giá trị này tùy thuộc vào môi trường của bạn mà thiết lập cho thích hợp. Ví dụ, mail relay server của bạn chỉ phục vụ cho một số ít người và thuộc mạng “chậm” thì nên thiết kết giá trị của “queuelifetime” cao hơn một tí để mail có cơ hội được chuyển giao trong trường hợp mạng bi nghẽn (thật ra queuelifetime cho 1 tuần là rất lâu). Tôi chọn giá trị 172800 (khoảng 48 giờ) vì mail relay server trong trường hợp tôi thiết kế phục vụ cho khá nhiều người và đường dẫn khá tốt.

4.2.6 Hồ sơ “badmailfrom” thuộc qmail-smtpd:
- Hồ sơ này là một trong những hồ sơ tiện dụng của qmail, nó dùng để chứa các e-mail bạn không cho phép qmail server nhận vào (nó thuộc qmail-smtpd nên thuộc phần “nhận”). Dù phương pháp chống “bom thư” hay spam này không được linh động cho lắm nhưng nó là một trong những chức năng chứng tỏ sự quan tâm của ông Bernstein khi viết Qmail trong vấn đề chống spam.

- Hồ sơ này chứa các e-mail hoặc trọn bộ domain bạn không muốn nhận bất cứ tin tức gì, mỗi e-mail phải nằm trên một dòng. Ví dụ:
spamboy@spamhouse.com (không nhận mail từ 1 địa chỉ này)
@spamhouse.com (không nhận mail từ trọn bộ domain này).

- Các phương pháp phòng chống “bom thư” linh động hơn sẽ được đi sâu hơn trong những phần tới.

4.2.7 Hồ sơ “rpcthosts” thuộc qmail-smtpd:
- Hồ sơ rcpthosts là một hồ sơ hết sức quan trọng đối với qmail-smtpd, nhất là cho một mail relay server. Hồ sơ này cung cấp dữ kiện cho qmail-smtpd, daemon này thay mặt các hosts và domains nào muốn nhận chuyển mail. Ví dụ bạn có 2 mail server trong LAN nội bộ có tên là domain1.com và domain2.com, hồ sơ rcpthosts phải có dữ kiện của 2 mail server này, nếu không, mail từ bên ngoài vào 2 server này sẽ bị qmail-smtpd từ chối chuyển nhận vào bên trong. Nên nhớ phải có ít nhất là một dữ kiện cho chính mail relay server không thì sẽ không có mail nào được vào (ngay cả cho chính mail relay server).

- Hồ sơ rcpthosts chứa các dữ kiện theo mặc định mỗi dòng một host/domain. Hồ sơ này có cấu trúc tương tự như sau:
mail.mydomain.com (mail là hostname của mail relay server và domain.com là fully qualified domain name. Ðây chính là dữ kiện thiết yếu và đầu tiên cho mail relay server).

exchange1.mydomain.com (exchange1 là hostname của MS exchange thuộc LAN nội bộ. Tất nhiên DNS của bạn (hoặc của ISP cung cấp cho bạn) phải có entry cho host exchange1 này và mail relay server phải biết được địa chỉ (bên trong) của host exchange1).

exchange2.mydomain.com (tương tự như exchange1 và nhiều mail server bên trong theo cấu trúc này nếu cần).

mydomain.net (giả sử bạn có thêm một domain name khác với đuôi .net và một trong những mail server thuộc LAN nội bộ đã thiết lập để nhận mail cho domain.net này, entry domain.net trong rcpthosts cần thiết để mail relay server biết domain.net được phép nhận mail từ bên ngoài thông qua mail relay server).

mail.myfriend.com (giả sử một người bạn có domain name là myfriend.com và anh ta bị trục trặc với mail server. Bạn có thể “tạm thời” giúp anh ta bằng cách cho phép mail relay server của bạn nhận các mail thuộc myfriend.com vào host mail để anh ta có thể dial in host mail này mà lấy mail (chẳng hạn). Kỹ thuật này còn có cái tên là “chuyển nhận có lựa chọn” (selective relay policy).

- Sự hiện diện của hồ sơ rpcthosts là một trong những đặc thù của qmail trong vấn đề phòng chống open-relay. Chỉ có những host/domain hiện diện trong rpcthosts được phép nhận mail từ mai relay server của bạn. Ðiều này có nghĩa, một người ở hostA (mang IP address xx.xx.xx.xx) có ý định dùng mail relay server của bạn để chuyển tới một mail server nào đó (có IP address zz.zz.zz.zz) ngoài giới hạn quy định của rpcthosts tuyệt đối không thể được. Phần “Thử nghiệm sau khi cài đặt” trong phần 6 sẽ đi xuyên qua một số bước kiểm tra cụ thể.

4.2.8 Hồ sơ “smtpgreeting” thuộc qmail-smtpd:
- Hồ sơ này trên mặt chức năng gần như không cần thiết nhưng trên mặt tâm lý nó mang ít nhiều tính chuyên nghiệp (professionalism) sự sắp xếp và hiện diện của một mail relay server trên Internet. Hồ sơ smtpgreeting không chứa gì ngoài một giòng thông điệp “chào mừng” những ai đến mail relay server này (bao gồm sự trao đổi giữa các mail relay servers và ngay cả các tay chuyên dùng telnet hoặc các loại dụng cụ thăm dò mail server lỗ hổng open-relay).

- Hồ sơ này tùy thuộc vào tinh thần của bạn mà hình thành một lời “chào mừng” đúng mức. Tôi đã từng thấy một số mail relay server có lời “chào mừng” khá thách thức chẳng hạn như: “Kiddies, this server is not your playground. Stay away or stick around for a challenge” (Tạm dịch: Mấy ông nhóc con, server này không phải là chỗ chơi của các ông. Tránh xa hay nhào vô mà thử thách). Dù cơ chế làm việc của qmail mang nặng tính bảo mật không có nghĩa là nó hoàn hảo và không cách gì phá được. Một thông điệp mang tính hoà nhã và nghiêm túc thường có tác dụng tốt đẹp hơn nhiều (bạn sẽ phải hối hận nếu lỡ buông lời thách thức trong thế giới bảo mật).

- Tôi giả định nên dùng một thông điệp ngắn gọn và rõ ràng như sau: “Welcome to company ABC mail server and have a nice time”. Xét cho cùng, bạn không muốn tạo nên phiền toái mà làm gì. Nếu một tay chuyên tìm open-relay thất vọng khi “đụng” phải mail server của bạn đã là một thành tựu; một thông điệp nhẹ nhàng sẽ giúp cho anh ta quyết định “để yên server” của bạn. Nên nhớ rằng, dù mail relay server của bạn không open-relay, những kẻ muốn phá vẫn có thể “flood” server của bạn được, tổn thất ở chỗ người dùng trong nội mạng không có cơ hội gởi và nhận mail trong khi mail relay server bị “flood”.

4.2.9 Hồ sơ “smtproutes” thuộc qmail-remote:
- Ðối với một mail server bình thường (qmail được thiết kế để trực tiếp nhận / gởi e-mail từ clients bên trong nội mạng và các mail server ngoại mạng), hồ sơ smtproutes không cần thiết. Tuy nhiên, để một qmail relay server làm việc, hồ sơ này không thể thiếu được. Hồ sơ này tương tự hồ sơ rcpthosts ở trên chỉ có thêm giá trị địa chỉ IP đi sau mỗi host (mail server trong nội mạng). Các IP của mail server trong nội mạng giúp mail relay server xác định được mail sẽ được chuyển về đâu và mỗi mail server nội mạng chịu trách nhiệm phân phát cho các clients theo đúng quy định. Ðây chính là cốt yếu khác biệt giữa một mail server bình thường và một mail relay server.

- Hồ sơ smtproutes có cấu trúc như sau: hostname.domain.com:[IP_ADDRESS]. Giả sử hai exchange mail servers trong nội mạng có tên là exchange1 (IP: 192.168.1.100) và exchange2 (IP: 192.168.1.200), dữ kiện được quy định trong smtproutes sẽ như sau:
exchange1.mydomain.com:[192.168.1.100]
exchange2.mydomain.com:[192.168.1.200]
mail.myfriend.com:[192.168.1.100] (dùng exchange1 để “nhận dùm” mail cho người bạn, tất nhiên exchange1 đã được thiết kế để tiếp nhận mail cho domain myfriend.com).

4.3 Mail server trong nội mạng (MS Exchange)
- Tôi chọn MS Exchange như một mail server nội mạng không phải vì khả năng chuyên biệt của MS Exchange mà vì tính phổ biến của nó trong môi trường văn phòng thường xử dụng MS Back Office. Cách điều chỉnh cho các loại mail server khác có những điểm tương tự như MS Exchange về phương diện mail đi ra / vào (thay vì đi vào trực tiếp từ mail server của ISP bạn dùng, MS Exchange hoặc mail server nào đó có thể đi vào từ Qmail mail relay server).

- Trong phần điều chỉnh Connections của MS Exchange, bạn chọn “Internetmail Service Properties”. Trong phần điều chỉnh này có một “tab” gọi là “Connection”, trong đó bạn có thể điều chỉnh hai dữ kiện để MS Exchange biết phải chuyển nhận mail từ Qmail mail relay server ở đâu:
Transfer mode chọn: “Inbound and Outbound”
Message delivery chọn: “Forward all messages to host” và IP của host chính là IP của mail relay server.

- Nếu Exchange server của bạn chịu trách nhiệm quản lý mail cho nhiều domain, bạn phải điều chỉnh “Reroute incoming SMTP mail” cho thích ứng trong “tab” Routing của “Internet Mai Properties. Những thiết lập này mang tính cụ thể cho từng loại mail server. Bạn nên tham khảo thêm tài liệu của mỗi loại mail server để đi sâu vào các chi tiết.
- Nguyên tắc làm việc trước và sau khi có mail relay server là:
* Các mail server thuộc nội mạng (hoặc DMZ) không còn truy cập trực tiếp đến mail server của ISP mà truy cập vào Qmail relay server.
* Cơ chế mail relay hoàn toàn do qmail server nắm giữ.
* Qmail relay server có thể được nằm trong DMZ hoặc nội mạng hoặc đằng sau một router miễn sao router + firewall có thể “foward” các thông tin từ bên ngoài vào mail relay server. Quyết định đặt để qmail relay server tùy thuộc vào cấu trúc của từng network.

(còn tiếp)

Qmail as a Mail Gateway - Phần 3

2007-06-28T11:20:00.000+10:00

3.4.2 Thư mục “qmail-smtpd” trong supervise
- Tương tự như trên, bạn tạo ra hồ sơ có tên là run trong thư mục /var/qmail/supervise/qmail-smtpd. Hồ sơ run này có trách nhiệm gọi một số phân bộ quan trọng của qmail để thi hành các chức năng trực thuộc smtp. Hồ sơ “run” này có chi tiết như sau:
#!/bin/sh
# concurincoming is not standard qmail control file
# it is created manually to specify the allowed concurrent incoming messages
#
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurincoming`
if [ -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" ]; then
echo QMAILDUID, NOFILESGID, or MAXSMTPD is not set in
echo /var/qmail/supervise/qmail-smtpd/run
echo “Have you set qmaild UID & qmaild GID yet?”
exit 1
fi
exec /usr/local/bin/softlimit -m 6291456 \
/usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /var/qmail/bin/qmail-smtpd 2>&1

Hồ sơ này sẽ có thêm một vài thông số quan trọng cho vấn đề chống “SPAM” sẽ được đi sâu hơn trong phần 5.4 sau này. Ở đây, bạn chỉ cần nắm bắt một vài chi tiết quan trọng đó là:
- softlimit -m $MEMSIZE trong đó, $MEMSIZE là số lượng memory thích hợp cho các phân bộ của qmail để xử lý khối lượng mail cao nhất trong khoảng thời gian bận rộn nhất.

- tcpserver và các thông số -p -x trong đó, -p chỉ định cho tình trạng “hoảng” (paranoid) dùng để kiểm tra IP của host gởi mail đến xem domain, MX record và IP của nó có giá trị hay không (tránh tình trạng SPAM theo phương thức đơn giản). -x chỉ định cho tcpserver dùng database (trong phần 3.4 sau đây) để kiểm tra chế độ nhận hoặc từ chối mail từ người gởi dựa trên database này.

- concurincoming variable trong hồ sơ “run” dùng để chỉ định số lượng mail được “đi vào” mail gateway mỗi lần. Bạn có thể cho nó một con số thích đáng tùy theo nhu cầu. Tuy nhiên, không nên cho concurincoming có giá trị quá cao để phòng ngừa khả năng bị DOS. Tôi chọn giá trị là 20 cho concurincoming, giá trị này đủ sức xử lý vài trăm đến vài ngàn mail mỗi giờ (tùy theo dung tích của mail đi xuyên qua mail gateway).
# echo 20 > /var/qmail/control/concurincoming
# chmod 644 /var/qmail/control/concurincoming

- Ðừng quên đổi hồ sơ “run” này thành “executable”:
# chmod 755 /var/qmail/supervise/qmail-smtpd/run

- Bước kế tiếp là tạo ra hồ sơ “run” trong thư mục /var/qmail/supervise/qmail-smtpd/log. Hồ sơ này gọi multilog thi hành nhiệm vụ logging cho các lưu thông thuộc phần hành smtp, multilog chuyển các log thuộc smtp vào thư mục /var/log/qmail/smtpd; nó có chi tiết như sau:
#!/bin/sh
# set user id and group id for qmail smtp daemon
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s5000000000 /var/log/qmail/smtpd

- Ðừng quên đổi hồ sơ “run” này thành “executable”:
# chmod 755 /var/qmail/supervise/qmail-smtpd/log/run

- Cuối cùng là tạo thư mục log cho qmail-smtpd:
# mkdir -p /var/log/qmail/smtpd

- Và đổi chủ quyền của thư mục này cho qmaill (bạn còn nhớ phần tạo tài khoản nhân dụng và nhóm nhân dụng ở phần 2.4.3?):
# chown qmaill /var/log/qmail /var/log/qmail/smtpd

3.5 Bộ quản trị “SMTP Access Control”
Trong qmailctl có một function chuyên chịu trách nhiệm cho phần SMTP access control. Bạn xem lại qmailctl sẽ thấy có dòng như sau thuộc function cdb:
cat /etc/smtprules/qmail-rules.txt | tcprules /etc/tcp.smtp.cdb

Lệnh trên có hai phần: copy qmail-rules.txt và pipe nó sang tcprules để biến nó thành hash database. Database này chứa các thông tin để kiểm tra chế độ nhận hoặc từ chối mail từ người gởi như đã đề cập trong phần 3.4.2 ở trên.

Bạn có thể tạo một hồ sơ có tên là qmail-rules.txt trong thư mục /etc/smtprules và có chi tiết như sau:
- Tạo thư mục /etc/smtprules trước:
# mkdir – p /etc/smtprules

- Ðưa chi tiết vào hồ sơ qmail-rules.txt:
# echo '127.:allow,RELAYCLIENT=””' >> /etc/smtprules/qmail-rules.txt
Lệnh trên đưa vào policy cho phép các host thuộc loopback được phép relay, nếu không Qmail không làm việc được.

# echo '192.168.1.:allow,RELAYCLIENT=””' >> /etc/smtprules/qmail-rules.txt
Lệnh trên đưa vào policy cho phép trọn bộ các client thuộc subnet 192.168.1.0/24 được quyền gởi mail đến Qmail gateway

# echo '10.10.10.50:allow,RELAYCLIENT=””' >> /etc/smtprules/qmail-rules.txt
Lệnh trên đưa vào policy cho phép một IP address (có thể là MS Exchange Server bên trong một subnet của LAN) được quyền relay.

# echo 'spamboy@spamhouse.com:deny' >> /etc/smtprules/qmail-rules.txt
Lệnh trên đưa vào policy từ chối mail từ người gởi có tên spamboy từ domain spamhouse.com. Cách này là cách đơn giản đề phóng chống bomb mail. Trên thực tế ứng dụng có nhiều phương pháp hữu hiệu hơn (sẽ bàn sâu hơn trong phần 5.4 sau này).

# echo 'badhost.net:deny' >> /etc/smtprules/qmail-rules.txt
Lệnh trên đưa vào policy từ chối mail của trọn bộ domain badhost.com. Bạn có thể dùng phương cách :allow hoặc :deny một cách linh động cho thích hợp với nhu cầu riêng. Và cuối cùng của hồ sơ qmail-rules.txt này, bạn luôn luôn cần một dòng như sau:
.:deny (# echo '.:deny' >> /etc/smtprules/qmail-rules.txt) với tác dụng từ chối tất cả các trường hợp còn lại.

Hồ sơ qmail-rules.txt đến đây tương tự như sau:

127.:allow,RELAYCLIENT=””
192.168.1.:allow,RELAYCLIENT=””
10.10.10.50:allow,RELAYCLIENT=””
spamboy@spamhouse.com:deny
badhost.net:deny
.:deny

Sau khi đã hoàn tất hồ sơ qmail-rules.txt như ý (đúng syntax như trên cho :allow, :deny) bạn có thể dùng function cdb của qmailctl:
# qmailctl cdb

Hoặc kiểu “dài dòng”:
# cat /etc/smtprules/qmail-rules.txt | tcprules /etc/tcp.smtp.cdb

Cũng nên đi vào chi tiết của tcprules syntax để giúp bạn tạo thêm các rules theo ý muốn và tránh những sai sót có thể xảy ra. Syntax của tcprules rất đơn giản như sau:
address:action,variable

Trong đó,
address có thể là một internet address (192.168.1.1), một chuỗi subnet (192.168.1.), một e-mail address (spamboy@spamhouse.com), một domain host (badhost.net) hoặc nếu không chỉ định một address nào thì bất cứ address cũng ứng dụng. Các variables của address có thể tóm gọn như sau:
$TCPREMOTEINFO@$TCPREMOTEIP (spamboy@192.168.1.1)
$TCPREMOTEINFO@$TCPREMOTEHOST (spamboy@spamhouse.com)
$TCPREMOTEIP (192.168.1.1)
$TCPREMOTEHOST (box.spamhouse.com)
Một phần của $TCPREMOTEIP (192.168.1)
Một phần của $TCPREMOTEHOST (spamhouse.com)
Không để address (bất cứ address nào cũng ứng dụng)

action là một trong hai trường hợp allow dành để cho phép address đã định hoặc deny dành để từ chối address đã định.

variable đi sau action được tách ra bởi dấu phẩy (,) (comma separated) thông thường là variable RELAYCLIENT với giá trị là một empty string (RELAYCLIENT=””)

3.6 Tạo ảo dụng “alias” cho Qmail
“alias” đóng vai trò quan trọng trong vấn đề quản lý mail server, điều này có nghĩa mỗi “alias” là một “ảo nhân” chịu trách nhiệm cho một số trường hợp điển hình của các hoạt động trên một mail server. Sau đây là 3 “alias” cần thiết nhất :
- postmaster (theo đúng RFC 2821) chỉ cho Administrator của mail server
- mailer-daemon một loại người dùng bán tiêu chuẩn để nhận các mail bị dội (bounce)
- root dùng để chuyển các loại mail mang tính chủ quyền đến system administrator

Giả sử bạn muốn mailbox của chính mình lo luôn cả 3 alias ở trên, bạn cần ra các lệnh sau:
# echo myname > /var/qmail/alias/.qmail-root
# echo myname > /var/qmail/alias/.qmai-postmaster
# ln -s /var/qmail/alias/.postmaster /var/qmail/alias/.qmail-mailer-daemon
# chmod 644 /var/qmail/alias/.qmail-root /var/qmail/alias/.qmail-postmaster

Nên nhớ các alias trên đều là hồ sơ “dấu” (hidden files) nên chúng đều có dấu chấm (.) đằng trước tên của alias. Các alias này có thể dùng để chuyển mail đến các user trên Unix (hoặc Linux), tôi không đi sâu vào vấn đề này vì chủ đề của bài viết là dùng Qmail như một mail gateway để forward mail vào một MTA bên trong LAN (như MS Exchange chẳng hạn).
Ðến đây Qmail có thể hoạt động được. Tuy nhiên, có một số vấn đề còn phải thử nghiệm và điều chỉnh để hoàn thiện các configuration của Qmail và daemontools. Ðây là các bước quan trọng và sẽ được đi sâu trong phần kế tiếp.

(còn tiếp)

Qmail as a Mail Gateway - Phần 2

2007-06-26T08:10:00.000+10:00

3. Thiết lập ứng dụng Qmail
3.1 Hồ sơ rc và “defaultdelivery”
Hồ sơ “rc” là boot script của qmail ấn định phương thức chuyển giao mail tùy theo cách sắp xếp và chọn lựa của từng hệ thống. Trong thư mục /var/qmail/boot có sẵn một số script cho từng trường hợp.

Nếu bạn không dùng daemontools mà dùng splogger của qmail để gởi log xuyên qua syslog (tiêu chuẩn Unix) và binmail để chuyển giao thông điệp theo phương thức /var/spool/mail/$USER thì “rc” script tương tự như sau:

Ví dụ thứ nhất:

#!/bin/sh
# Dùng splogger để chuyển log xuyên qua syslog
# Dùng binmail để chuyển giao thông điệp đến /var/spool/mail/$USER theo default
# Dùng V7 binmail interface: /bin/mail -f

exec env – PATH=”/var/qmail/bin:$PATH” \
qmail-start \
`|preline -f /bin/mail -f "${SENDER:-MAILER-DAEMON}" -d "$USER"` \
splogger mail

Trong đó,
- Phương thức chuyển giao mail đến /var/spool/mail/$USER chính là phương thức chuyển giao mail theo truyền thống Unix.Nếu bạn muốn hiểu rõ hơn, nên tham khảo thêm phương thức chuyển giao mail của Unix.
- Các dấu back-slash (\) chỉ cho sự nối tiếp trong câu lệnh (\ là return character)
- Phần lệnh h preline -f /bin/mail -f của người gởi là MAILER-DAEMON đến $USER nằm trong dấu backquote (`) chớ không phải là singlequote ('). Nên phân biệt rõ các dấu quote này khi đánh lệnh trên trong script “rc” (backquote dùng để ứng thế một cụm lệnh, singlequote chỉ là một singlequote). Nếu bạn muốn hiểu rõ hơn về khả năng “command subtitution” trên Unix, nên đọc thêm phần này.

Dĩ nhiên bạn có thể tạo nên một “rc” như trên và dùng splogger. Tuy nhiên, nếu đã install daemontools, tại sao không tận dụng chức năng của nó? Hồ sơ “rc” của tôi như sau:

Ví dụ thứ nhì:

#!/bin/sh
# Dùng multilog của daemontools để gởi log đến /var/log/qmail
# Dùng /var/qmail/control/defaultdelivery làm hồ sơ configuration
# Dùng ./Mailbox làm phương thức chuyển giao thông điệp

exec env – PATH=”/var/qmail/bin:$PATH” \
qmail-start “`cat /var/qmail/control/defaultdelivery`”

- So với hồ sơ “rc” ở trên dùng splogger và hồ sơ “rc” dùng daemontools này thì hồ sơ “rc” này giản tiện hơn nhiều.
- Lệnh exec env xác định môi trường qmail và qmail-start chỉ đơn giản khởi động theo thông số đã định sẵn trong defaultdelivery.
- defaultdelivery không phải là một hồ sơ tiêu chuẩn của qmail. Nó đơn giản chỉ là một phương tiện gởi thông số cho qmail-start.

Sau khi đã tạo ra hồ sơ “rc” trong thư mục /var/qmail, có hai việc cần làm là:
- Thay “mod” của hồ sơ này thành “executable: # chmod 755 /var/qmail/rc để script rc này có thể “khởi động” được khi cần.
- Tạo ra thư mục /var/log/qmail để daemontools gởi log của qmail vào vị trí này: # mkdir /var/log/qmail (nếu bạn không muốn dùng daemontools mà chỉ dùng rc như phần ví dụ thứ nhất thì không cần tạo ra thư mục này vì splogger sẽ dùng syslog).

Ðến đây có lẽ bạn sẽ hỏi: defaultdelivery ở đâu ra và trong hồ sơ này chứa những gì? Như đã đề cập ở trên, defaultdelivery chỉ đơn giản là một phương tiện gởi thông số cho qmail-start; nó giúp qmail-start xác định phương thức chuyển gởi mail (nếu không muốn dùng .qmail). Có 3 phương thức chuyển gởi mail thông thường trên Unix như sau:

Format Vị trí defaultdelivery Lợi điểm
maildir $HOME ./Maildir/ Ðáng tin cậy nhưng ít MUA hỗ trợ
mbox $HOME ./Mailbox Phổ biến và được các MUA hỗ trợ
username /var/spool/mail xem thêm INSTALL.vsm Mail tiêu chuẩn Unix.

Dựa vào bảng phân tích trên, bạn có thể chọn phương thức thích hợp cho mình. Trong thư mục mã nguồn có kèm các hồ sơ INSTALL.mbox, INSTALL.maildir và INSTALL.vsm giải thích rất chi tiết các ưu khuyết điểm của từng phương thức nếu bạn muốn tìm hiểu sâu hơn. Cá nhân tôi chọn ./Mailbox vì muốn tạo tiện dụng cho các MUA (Mail User Agent).

Vậy, để tạo ra defaultdelivery, bạn chỉ cần chọn một phương thức và dùng lệnh echo để đính phương thức đã chọn, giả sử như:
# echo ./Mailbox > /var/qmail/control/defaultdelivery

Trong đó,
- ./Mailbox là phương thức.
- hồ sơ defaultdelivery được nằm trong thư mục /var/qmail/control, nơi trọn bộ các configuration thuộc qmail được lưu trữ.
- lệnh echo đính dòng ./Mailbox (>) vào hồ sơ defaultdelivery.

3.2 Hồ sơ khởi động “qmailctl” của hệ điều hành
Ðến đây, bạn đã có thể khởi động qmail bằng cách chạy script “rc” đã tạo ở trên. Tuy nhiên, để qmail được ứng dụng như một mail gateway có khả năng tự khởi động và tự tắt theo đúng quy chế thì “rc” không có khả năng này. Hơn nữa, các chức năng tiện dụng của phần daemontools không được ứng dụng đầy đủ nếu chỉ dùng script “rc” ở trên. Hồ sơ “rc” sẽ được dùng như một phân bộ trong cơ chế chuyển gởi thông điệp (qua smtp), các phần kế tiếp sẽ đi sâu hơn.

Vì lý do trên, hồ sơ khởi động qmailctl được hình thành để quản lý các phân bộ của qmail và daemontools đúng hệ thống. Trước khi đi sâu vào nội dung của hồ sơ qmailctl, bạn cần biết qua một số binaries và các chức năng của chúng trong phần mềm hỗ trợ “daemontools” để dễ hình dung cơ chế làm việc của hồ sơ qmailctl.

Sau khi compile và build daemontools thành công, phần mềm này có 14 binaries được lưu trữ trong /usr/local/bin, bạn chỉ cần biết đến một số binaries và chức năng của chúng như sau:

Tên binary Chức năng
supervise: Dùng để khởi động và theo dõi một process. Có khả năng tái khởi động process đó nếu nó bị “chết”
svok: Dùng để kiểm tra xem supervise đang thao tác hay không
svc: Dùng để điều khiển một process được khởi động bởi supervise, binary này cho phép Admin ngưng và tái khởi động một process nào đó.
svstat: Dùng để báo cáo tình hình của một process được khởi động bởi supervise
svscan: Dùng để khởi động vào theo dõi một nhóm process được supervise tạo ra

Theo đây là một bản mẫu của hồ sơ qmailctl, bạn có thể dùng nó cho hệ thống của mình nếu không muốn tự tạo một “qmailctl” riêng:
#!/bin/sh
# Người dùng RedHat có thể giản tiện chu trình sắp xếp
# “runlevel” với lệnh “chkconfig”
# chkconfig: - 80 30
# description: qmail as MTA

# Phần kế tiếp dùng để chỉnh user environment
PATH=/var/qmail/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin
export PATH

# Xác định variables cho qmail daemon ID và user group ID
QMAILDUID=`id -u qmaild`
NOFILESGID-`id -g qmaild`

# Bắt đầu tạo ra các trường hợp hoạt dụng cho supervise
case “$1” in
start)
echo -n “Starting qmail: svscan”
cd /var/qmail/supervise
env – PATH=”$PATH” svscan &
echo $! > /var/run/svscan.pid
echo “.”
;;
stop)
echo -n “Stopping qmail: svscan
kill `cat /var/run/svscan.pid`
echo -n “ qmail down”
svc -dx /var/qmail/supervise/*
echo -n “ logging down too”
svc -dx /var/qmail/supervise/*/log
echo “.”
;;
stat)
cd /var/qmail/supervise
svstat * */log
;;
doqueue)
echo “Sending ALRM signal to qmail-send”
svc -a /var/qmail/supervise/qmail-send
;;
queue)
qmail-qstat
qmail-qread
reload)
echo “Sending HUP signal to qmail-send”
svc -h /var/qmail/supervise/qmail-send
;;
pause)
echo “Pausing qmail-send”
svc -p /var/qmail/supervise/qmail-send
echo “Pausing qmail-smtpd”
svc -p /var/qmail/supervise/qmail-smtpd
;;
cont)
echo “Continuing qmail-send”
svc -c /var/qmail/supervise/qmail-send
echo “Continuing qmail-smtpd”
svc -c /var/qmail/supervise/qmail-smtpd”
;;
restart)
echo “Restarting qmail:”
echo “* Stopping qmail-smtpd”
svc -d /var/qmail/supervise/qmail-smtpd
echo “* Sending qmail-send SIGTERM and restarting”
svc -t /var/qmail/supervise/qmail-send
echo “* Restarting qmail-smtpd”
svc -u /var/qmail/supervise/qmail-smtpd
;;
cdb)
echo “Do not forget to modify /etc/smtprules/qmail-rules.txt or it will use the old cdb”
cat /etc/smtprules/qmail-rules.txt | tcprules /etc/tcp.smtp.cdb /tmp/tcp.smtp.tmp
chmod 644 /etc/tcp.smtp*
echo “/etc/tcp.smtp.cdb is reloaded”
;;
help)
cat <<HELP
stop -- stops mail service (smtp connections refused, nothing goes out)
start -- starts mail service (smtp connection accepted, mail can go out)
pause -- temporarily stops mail service (connections accepted, nothing leaves)
cont -- continues paused mail service
stat -- displays status of mail service
cdb -- rebuild the tcpserver cdb file for smtp
restart -- stops and restarts smtp, sends qmail-send a TERM & restarts it
doqueue -- sends qmail-send ALRM, scheduling queued messages for delivery
reload -- sends qmail-send HUP, rereading locals and virtualdomains
queue -- shows status of queue
HELP
;;
*)
echo “Usage: $0 {start|stop|restart|doqueue|reload|stat|pause|cont|cdb|queue|help}”
exit 1
;;
esac
exit 0

Ðến đây có lẽ bạn sẽ thấy là binary svc được dùng rất nhiều trong hồ sơ qmailctl và sẽ thắc mắc các thông số -a, -h, -t, -u.... của binary này có những chức năng nào?

Như đã đề cập ở trên về một số binaries của daemontools và các chức năng của chúng; svc dùng để điều khiển một process được khởi động bởi supervise, binary này cho phép Admin ngưng và tái khởi động một process nào đó. Việc ứng dụng chức năng “tái khởi động một process nào đó” của svc hết sức quan trọng vì nó bảo đảm sự hoạt động liên tục của qmail và các phân bộ của qmail (nếu không mail sẽ bị bounce và không chuyển gởi được khi một trong những phân bộ của qmail bị ngưng).

Sau đây là bảng tóm gọn các thông số của svc (cho trường hợp bạn cần đào sâu), bạn có thể dùng bảng thông số của svc và đối chiếu với phần script trong hồ sơ qmailctl để hiểu rõ hơn các functions của nó:

Thông số Chức năng

-a Alarm – Dùng để gởi tín hiệu ALRM đến service
-c Continue – Dùng để gởi tín hiệu CONT đến service
-d Down – Dùng để gởi tín hiệu TERM và CONT đến service (nếu service này đang chạy) và không cho phép supervise tái khởi động service này.
-h Hangup – Dùng để gởi tín hiệu HUP đến service
-i Interrupt – Dùng để gởi tín hiệu INT đến service
-k Kill – Dùng để gởi tín hiệu KILL đến service
-o Once – Dùng để khởi động service nếu service này chưa khởi động, nếu service này ngừng sau đó, once ngăn chặn supervise tái khởi động nó.
-p Pause – Dùng để gởi tín hiệu STOP đến service
-t Terminate – Dùng để gởi tín hiệu TERM đến service
-u Up – Nếu service đang ngưng, thông số này khởi động service
-x Exit – Ðình chỉ supervise ngay sau khi service down.

Có hai cách sắp xếp cho hồ sơ “qmailctl” ở trên tự động chạy khi Linux (Unix) system đi xuyên qua “run level”. Linux và các Unix System V xử dụng init.d thư mục để chứa các shell scripts cho các run level, thông thường thư mục init.d có cấu trúc như:
/etc/init.d hoặc,
/etc/rc.d/init.d tùy theo cách sắp xếp và ứng dụng của mỗi Linux distro và Unix System V.
a. Cách “lười” (trên RedHat và một số distro có ứng dụng chkconfig):
- Tạo hồ sơ qmailctl như trên trong /var/qmail/bin (cho tiện)
- Làm cho qmailctl “chạy được” và tạo “soft link” từ hồ sơ qmailctl này vào /etc/rc.d/init.d (hoặc /etc/init.d tùy theo) và /usr/bin
# chmod 755 /var/qmail/bin/qmailctl
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/init.d/qmail
# ln -s /var/qmail/bin/qmailctl /usr/bin

- Chuyển vào thư mục /etc/rc.d/init.d
# cd /etc/rc.d/init.d

- Chạy lệnh chkconfig để đưa các “soft links” vào đúng các “run level”
# chkconfig –add qmail

Nên nhớ phải có phần #chkconfig: - 80 30 và # description: ở phần đầu của qmailctl không thì lệnh chkconfig sẽ không chạy được. 80 và 30 là enable level và disable level của qmail (xem thêm các tài liệu về runlevel trên Sys V)

b. Cách “cổ điển” (trên tất cả các distro và System V):
Cách “cổ điển” để tạo ra runlevel cho System V sau đây rất căn bản và thông thường.
Sau khi tạo hồ sơ qmailctl trong /var/qmail/bin và làm nó “chạy được” với chmod như trên phần “lười”, bạn tạo ra các soft link từ qmailctl đến tới từng runlevel như sau:

# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc0.d/K30qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc1.d/K30qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc2.d/S80qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc3.d/S80qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc4.d/S80qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc5.d/S80qmail
# ln -s /var/qmail/bin/qmailctl /etc/rc.d/rc6.d/K30qmail

Ở trên cho thấy các symbolic links từ /var/qmail/bin/qmailctl đến mỗi runlevel (của các rcX.d) với chỉ định: qmail ngưng hoạt động ở rc0.d, rc1.d và rc6.d và hoạt động ở rc2.d, rc3.d, rc4.d và rc5.d (ký hiệu K dùng cho Stop và ký hiệu S dùng cho Start trong runlevel). Ở đây tôi chọn S80 và K30 dựa trên runlevel (by default) của Sendmail, bạn có thể chọn chỉ số khác thích hợp cho yêu cầu riêng. Tuy nhiên, nên sắp xếp runlevel theo đúng trình tự và ưu tiên của mỗi daemon không thì sẽ tạo ra sự cố cho các daemon của system.

3.3 Stop Sendmail và link Sendmail
Có lẽ bạn sẽ tự hỏi tại sao lại có Sendmail ở đây và tại sao phải Stop Sendmail rồi link Sendmail? Câu trả lời như sau: Sendmail gần như là một MTA default cho các Linux Distro cũng như đa số các Unix flavor cho nên cơ hội Sendmail daemon đang chạy và chiếm cứ port 25 trên máy của bạn rất cao. Ðiều này dẫn đến nhiều trục trặc tai quái khi qmail bắt đầu khởi động (cho dù bạn vẫn có thể chỉnh định cho Sendmail và Qmail cùng chạy trên một host nếu sắp xếp cẩn thận). Bước Stop Sendmail và Link Sendmail theo tôi, là một bước hết sức quan trọng và cần thiết. Tất nhiên, nếu bạn không hề có Sendmail trên máy thì bước này không cần phải đi xuyên qua.

3.3.1 Stop Sendmail:
- Thông thường, Stop Sendmail cách đơn giản nhất là dùng runlevel script trong /etc/rc.d/init.d/sendmail để Stop:
# /etc/rc.d/init.d/sendmail stop

- Cách “dã chiến” là kill process ID nào của Sendmail nếu Sendmail đang chạy (hoặc system của bạn không dùng runlevel hoặc Sendmail được khởi động kiểu “dã chiến”...). Dùng lệnh ps để in ra các process nào của Sendmail:
# ps -ef | grep sendmail

- Sau khi ps cho bạn danh sách các process thuộc Sendmail, bạn chỉ đơn giản “kill”:
# kill PID-of-Sendmail

- Cho an toàn, bạn nên tháo bỏ trọn bộ Sendmail nếu đã quyết định không dùng nó nữa hoặc ít nhất là tháo bỏ các symbolic link cho runlevel của Sendmail trong /etc/rc.d/rcX.d. Ðể tháo bỏ các runlevel theo phương pháp tiện dụng chkconfig (trên RedHat và các distro có ứng dụng chkconfig này):
# chkconfig –del sendmail

- Ðể tháo bỏ các symbolic links cho runlevel của Sendmail theo kiểu “dã chiến”:
# mv /etc/rc.d/init.d/sendmail /etc/rc.d/init.d/sendmail.old
# rm -f /etc/rc.d/rc0.d/K30sendmail
# rm -f /etc/rc.d/rc1.d/K30sendmail
# rm -f /etc/rc.d/rc2.d/S80sendmail
# rm -f /etc/rc.d/rc3.d/S80sendmail
# rm -f /etc/rc.d/rc4.d/S80sendmail
# rm -f /etc/rc.d/rc5.d/S80sendmail
# rm -f /etc/rc.d/rc6.d/K30sendmail

- Ðể tháo bỏ luôn cả binaries của Sendmail, trên RedHat hoặc distro nào dùng RPM bằng cách:
# rpm -e –nodeps sendmail

- Hoặc đi vào từng thư mục /usr/sbin hoặc /usr/local/sbin (hoặc /usr/lib, /usr/local/lib) để manually rename từng binary thuộc về Sendmail (nếu Sendmail được cài vào máy theo phương thức “compile and build” tổng quát.

3.3.2 Link Sendmail
Ðã muốn xoá luôn Sendmail vậy sao còn link Sendmail là sao? Có rất nhiều chương trình trên Linux và Unix “gọi” Sendmail để chuyển gởi thông điệp theo “default”. Nếu Sendmail binary bị hoàn toàn tháo gỡ thì không chóng thì chầy bạn sẽ lâm vào nhiều trục trặc bí ẩn :). Cách loại trừ những trục trặc “bí ẩn” có thể xảy ra là dùng phương thức Link Sendmail. Link Sendmail ở đây là link một copy có tên là Sendmail từ binary của Qmail thay vì dùng nguyên bản binary của Sendmail.

- Ðổi tên của nguyên bản binary Sendmail:
# mv /usr/sbin/sendmail /usr/sbin/sendmail.old
# mv /usr/lib/sendmail /usr/lib/sendmail.old

- Link bản Sendmail của Qmail vào các thư mục /usr/sbin và /usr/lib:
# ln -s /var/qmail/bin/sendmail /usr/lib
# ln -s /var/qmail/bin/sendmail /usr/sbin

3.4 Thư mục “supervise” và các ứng động trong thư mục này
Ðến đây, bạn cần tạo các thư mục và một số hồ sơ “supervise” cho qmailctl làm việc (bạn xem lại qmailctl có rất nhiều phần svc dùng /var/qmail/supervise/qmail-send hoặc /var/qmail/supervise/qmail-smtpd). Các bước kế tiếp rất đơn giản, tuy nhiên bạn nên cẩn thận với các chi tiết không thì sẽ gặp những trục trặc sau này.
Ðầu tiên, bạn tạo ra 2 thư mục:
# mkdir -p /var/qmail/supervise/qmail-send/log
# mkdir -p /var/qmail/supervise/qmail-smtpd/log

Trong đó, thông số -p (parents) dùng để tạo các thư mục từ trên xuống dưới (từ supervise đến qmail-send và log tương tự cho qmail-smtpd và log). Ðiều này có nghĩa trước khi mkdir tạo ra thư mục log bên trong thư mục qmail-send, nó kiểm tra xem thư mục qmail-send có sẵn hay không và tạo ra thư mục này nếu cần. Tương tự nó kiểm tra xem thư mục supervise có sẵn hay không.... (Dùng # mkdir –help để xem thêm chi tiết)

3.4.1 Thư mục “qmail-send” trong supervise
Sau khi tạo ra các thư mục /var/qmail/supervise/qmail-send/log như trên, bạn phải đi qua các bước như sau:
- Tạo một hồ sơ gọi là run trong /var/qmail/supervise/qmail-send (hồ sơ run nằm trong thư mục qmail-send – chú ý vị trí của các hồ sơ trong các thư mục). Hồ sơ run này có chi tiết như sau:
#!/bin/sh
exec /var/qmail/rc

Bạn còn nhớ hồ sơ “rc” ở phần 3.1 không? Ðây chính là nơi “rc” được gọi và thi hành nhiệm vụ trong trọn bộ cơ chế hoạt động của qmail và daemontools. Sau khi tạo ra hồ sơ run này, bạn phải đổi “mod” của nó thành “executable”:
# chmod 755 /var/qmail/supervise/qmail-send/run

- Tạo một hồ sơ khác cũng có tên là run nhưng nằm trong thư mục log của thư mục qmail-send). Hồ sơ run này có trách nhiệm gọi multilog thi hành nhiệm vụ logging của những gì qmail-send gởi đi; nó có chi tiết như sau:
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s5000000000 /var/log/qmail

- Ðừng quan tâm lắm đến các thông số của shell script “run” lúc này. Các chi tiết sẽ đưọc đào sâu thêm trong những phần sau. Nếu bạn quan sát kỹ sẽ thấy mọi bước ăn khớp với nhau từ giai đoạn tạo ra thư mục cho log và thư mục này đến đây được dùng như một thông số trong shell script “run” ở trên. Sau khi tạo ra hồ sơ run này, bạn phải đổi “mod” của nó thành “executable”:
# chmod 755 /var/qmail/supervise/qmail-send/log/run

(Còn tiếp)

Qmail as a Mail Gateway - Phần 1

2007-06-25T12:09:00.000+10:00

1. Giới thiệu về Qmail
1.1 Tài liệu dành cho ai?
Tài liệu này dành cho những ai muốn dùng Qmail như một MTA cho hệ thống mail. Ðiều cần thiết là người đọc phải có kiến thức căn bản sử dụng một hệ thống *nix (cách sử dụng các lệnh và cách truy cập / tạo vào các thư mục). Người viết tài liệu không chịu trách nhiệm cho bất cứ hư hại đến máy của người dùng cũng như sự phiền não, bực dọc, mất ngủ .... đến người dùng tài liệu này :)

Tài liệu này đào sâu ở mức độ có hạn. Mọi ứng dụng tùy thuộc vào nhu cầu và khả năng thiết lập của người dùng. Qmail không phải là một MTA phức tạp. Tuy nhiên nó mang một số khái niệm điều hành độc lập giữa các thành phần để tạo nên một MTA làm việc hoàn chỉnh, do đó, người đọc nên nghiên cứu kỹ trước khi bắt tay vào việc thiết kế một hệ MTA dùng Qmail.

Tài liệu này ứng dụng mô hình qmail làm mail gateway để nhận mail từ Internet và chuyển mail đến một hoặc nhiều mail servers bên trong mạng riêng. Người viết không ứng dụng mô hình qmail như là một mail server phục vụ tất cả các mail protocol khác như IMAP, POP3... vì lý do bảo mật. Có hai điểm tối quan trọng của mô hình mail gateway là:

- Ổn định và hiệu năng: qmail có khả năng chuyển nhận hàng triệu thông điệp một ngày (dựa vào tài liệu trên web site của qmail.org). Tuy nhiên, nếu biến nó thành một mail server phục vụ tất cả các mail protocol thì bị giới hạn trong vấn đề kiểm dịch (authentication). Nếu mail server thuộc một mạng dùng hoàn toàn Unix thì giới hạn này có thể khắc phục dễ dàng. Không may trên thực tế hiện nay, không còn nhiều mạng “thuần” Unix hoặc “thuần” một hệ điều hành nào khác. Bởi vậy, qmail hoạt động như một mail gateway chỉ có trách nhiệm chuyển mail đến các mail servers khác (trong giới hạn cho phép domain) mà không phải lo vấn đề authentication, do đó, ngoài tính bảo mật, tính hiệu năng được nâng cao đáng kể.

-Tính bảo mật: Như đã nêu ra ở trên những khó khăn trong cơ chế quản lý kiểm dịch của một (hoặc nhiều) mạng có đa hệ điều hành không những giảm sút tính hiệu năng mà còn ảnh hưởng lớn đến tính bảo mật. Lý do, quản lý một trung tâm tài nguyên nhân dụng (central user database) dễ dàng và ổn định hơn nhiều user database. Hơn thế, cơ chế Internet <--> Mail Gateway <--> Firewall <--> Internal Mail Servers <--> Users chặc chẽ và an toàn hơn. Ðó là chưa kể ứng dụng kiểm soát / ngăn chặn viruses, trojans và cách loại scripts mang tính phá hoại trên một Unix Mail Gateway trước khi thông điệp được chuyển vào một Mail Server bên trong (Microsoft Exchange hoặc IBM Lotus chẳng hạn). Các ứng dụng cho POP3 hoặc IMAP được thiết lập một cách độc lập trên internal mail servers và người dùng có thể truy cập qua một cơ chế firewalling nào đó.

1.2 Sơ lược về Qmail
Qmail được viết bởi Tiến sĩ toán của trường đại học Illinois, Chicago, tiến sĩ Dan Bernstein. Qmail ra đời vào tháng Giêng năm 1996 với một phiên bản Beta 0.70 và sau đó phiên bản Gamma 0.90 được cập nhật vào tháng 8 năm 1996. Phiên bản ổn định 1.0 được ra mắt vào tháng 2 năm 1997. Phiên bản được lưu hành hiện nay là 1.03 được phát hành vào tháng 6 năm 1997.

1.3 Tại sao dùng Qmail?
Có rất nhiều MTA trên môi trường *nix hiện nay và mỗi khi nhắc đến MTA chúng ta phải nhắc đến Sendmail. Tuy nhiên, Dan Bernstein viết Qmail vì ông ta thấy rằng Sendmail thừa hưởng nhiều lỗi bảo mật từ các phiên bản trước đây và phần mềm này rất cồng kềnh, cho dù những năm gần đây, nhóm Sendmail không ngừng điều chỉnh và cải tiến phần mềm này để giảm thiểu những yếu điểm. Khi viết Qmail, ngoài ưu tiên cho vấn đề bảo mật, Dan Bernstein chú trọng rất nhiều đến khả năng hoạt động và tính dễ dùng của nó. Qmail mang tính truyền thống của các hoạt trình Unix: mỗi tiểu ứng trình có khả năng đảm đương trọn vẹn một chức năng chuyên biệt và các tiểu ứng trình này có thể chuyền (pipe) sang các tiểu ứng trình khác để đáp ứng các quy trình phức tạp. Bởi thể, Qmail bao gồm nhiều binaries tạo thành một dây chuyền hoạt động. Ðây là một điển hình nặng tính bảo mật và tính hiệu năng trong cơ chế điều hành của một MTA.

2. Cài đặt Qmail
2.1 Cài từ “gói” (RPM) hay từ tar ball?
Qmail thuộc dạng mở-nguồn nên bạn có thể tải mã nguồn của Qmail về để compile và thiết kế nó cho thích hợp với hệ điều hành của mình. Có một số RPM cho RedHat trên Internet (dùng http://rpmfind.net để tìm). Tuy nhiên, có ít nhiều hạn chế khi dùng RPM và không phải các “gói” này luôn luôn có sẵn cho các hệ điều hành.

RPM thường buộc người dùng cài đặt binaries vào một nơi trong những thư mục và đôi khi sự ép buộc này không tiện cho cách tổ chức thư mục đã có sẵn của bạn. RPM không giải quyết được các trường hợp bị thiếu hoặc sai “thư viện lệ thuộc” (dependencies). Bởi thế, phương cách compile và build từ mã nguồn xem ra là một phương cách khả thi nhất. Hơn nữa, nó sẽ tạo cơ hội cho bạn hiểu rõ hơn cơ chế làm việc của Qmail sau quá trình cài đặt. Tài liệu này sẽ chỉ chuyên chú vào quy trình compile và build từ mã nguồn.

2.2 Yêu cầu để cài đặt Qmail
Ðể có thể cài đặt Qmail thành công, sau đây là các yêu cầu tối yếu:

- Một C compiler, các thư mục header và các thư viện cho hệ thống lập trình. Nếu bạn dùng trong một phiên bản Linux, compiler của bạn hẳn là gcc.

- Có đủ nơi chứa cho quá trình build và các binaries và các tài liệu sau khi Qmail được build. Ổ chứa tuyệt đối cần thiết cho Qmail lưu trữ và xử lý mail trong các điểm “xếp hàng” (mail queues).

- Domain name của bạn. Qmail chỉ làm việc (đúng) khi bạn có một domain hợp pháp (fully qualified domain name FQDN). Liên hệ với dịch vụ Internet của bạn cho vấn đề này nếu bạn không rõ.

- Qmail được thiết kế như một MTA hạng nặng. Ðiều này có nghĩa máy chạy Qmail phải có băng thông ổn định và rộng đủ để tải và nhận mail. Nếu bạn có dự định thiết lập một MTA xuyên qua modem, có lẽ serialmail là một phần mềm thích hợp hơn (http://cr.yp.to/software/serialmail-0.75.tar.gz).

2.3 Những điều cần chuẩn bị
Qmail không phải là một phần mềm MTA phức tạp. Tuy nhiên, cách an toàn nhất nên thử cài đặt trên một máy tách biệt từ hệ thống mail đang làm việc của bạn và thâu thập kinh nghiệm trước khi cài đặt trên máy chính thức.

Thực ra quá trình compile và build qmail sẽ không ảnh hưởng gì đến hệ thống mail đang làm việc của bạn. Tuy nhiên, bước kiểm nghiệm Qmail sẽ làm gián đoạn hệ thống mail đang có. Ðề nghị trên đơn giản là một cách nhắc nhở mang tính an toàn.
Nếu bạn có dụng ý chuyển đổi (migrate) từ một MTA khác sang Qmail, cũng như bao nhiêu quy trình chuyển đổi khác, giai đoạn hình thành một chiến thuật chuyển đổi (từng bước một) là một điều hết sức cần thiết và giai đoạn “thử” Qmail sẽ giúp bạn hình thành chiến thuật này chính xác hơn và hữu hiệu hơn.

2.4 Tải mã nguồn từ đâu
- Mã nguồn Qmail có thể được tải về từ: ftp://cr.yp.to/software/qmail-1.03.tar.gz hoặc theo đường dẫn của site http://cr.yp.to/software.html (site chính thức của mã nguồn Qmail).
- Ngoài mã nguồn của Qmail ở trên, bạn cần thêm ít nhất hai phần mềm phụ nhưng tuyệt đối cần thiết cho Qmail (chi tiết hoạt động của các phần mềm phụ này sẽ được trình bày trong quy trình thiết lập Qmail). Hai phần mềm phụ nói trên là: ftp://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz (cho uscpi-tcp) và ftp://cr.yp.to/daemontools/daemontools-0.76.tar.gz (cho daemontols).

2.4 Từng bước cài đặt
2.4.1 Xả nén mã nguồn
Các bước cài đặt cần chủ quyền root nên trước khi xả nén vào tạo các hồ sơ thư mục, bạn nên chuyển chủ quyền sang super user. Theo quy định chung của System V, các nguồn và binaries do người dùng thêm vào system nên cho vào /usr/local/src, cho nên chúng ta cứ theo vậy mà làm.
- chuyển thành super user:
myshell$ su
(đánh mật mã của root)

- đổi umask thành 022 cho bảo đảm
# umask 022

- tạo thư mục /usr/local/src (nếu nó chưa có sẵn)
# mkdir -p /usr/local/src

- dời các source của qmail vào trong /usr/local/src
# mv qmail-1.03.tar.gz ucspi-tcp-0.88.tar.gz daemontools-0.76.tar.gz /usr/local/src

- vào thư mục /usr/local/src để xả nén cái gói qmail, uscpi-tcp và daemontools
# cd /usr/local/src
# gunzip *
# tar -xpvf qmail-1.03.tar
# tar -xpvf ucspi-tcp-0.88.tar
# tar -xpvf daemontools-0.76.tar

2.4.2 Tạo hồ sơ thư mục
Ðến đây bạn đã có một nhóm thư mục như sau:
/usr/local/src/qmail-1.03, /usr/loca/src/ucspi-tcp-0.88 và /usr/local/src/admin/daemontools-0.76.

- Bước kế tiếp tạo thư mục chủ cho Qmail, đây là nơi trọn bộ binary và configuration cho qmail được cất giữ và điều hành.
# mkdir /var/qmail

- Tạo thư mục bin trong thư mục chủ của qmail, nơi chứa các binaries
# mkdir /var/qmail/bin

- Tạo thư mục control trong thư mục chủ của qmail, nơi chứa các hồ sơ chỉnh liệu
# mkdir /var/qmail/control

- Tạo thư mục alias trong thư mục chủ của qmail, nơi chứa các hồ sơ ảo
# mkdir /var/qmail/alias

- Tạo thư mục man trong thư mục chủ của qmail, nơi chứa các tài liệu cho qmail
# mkdir /var/qmail/man

2.4.3 Tạo tài khoản nhân dụng và nhóm nhân dụng
Vấn đề tạo tài khoản nhân dụng và nhóm nhân dụng hết sức quan trọng cho qmail trong vấn đề hoạt động vào bảo mật. Tài khoản nhân dụng cho phép qmail hoạt động trong giới hạn trách nhiệm của nó. Ðiều này có nghĩa, trường hợp qmail bị “hack”, tài khoản nhân dụng của qmail không thể dùng (hoặc rất khó) để xâm nhập hệ thống sâu hơn.

Có một số phương thức khác nhau để tạo tài khoản nhân dụng và nhóm nhân dụng. Nhiều người xử dụng qmail đã tạo ra một số scripts để thực hiện bước này một cách nhanh chóng và dễ dàng. Tuy nhiên ở đây chúng ta nên đi xuyên qua các bước này một cách cụ thể để có thể hiểu sâu hơn vấn đề tài khoản nhân dụng và bảo mật trong quá trình tạo tài khoản nhân dụng.

- Tạo nhóm nhân dụng nofiles
# groupadd nofiles

- Tạo tài khoản nhân dụng cho nhóm nofiles này
# useradd alias -g nofiles -d /var/qmail/alias -s /bin/true
# useradd qmaild -g nofiles -d /var/qmail -s /bin/true
# useradd qmaill -g nofiles -d /var/qmail -s /bin/true
# useradd qmailp -g nofiles -d /var/qmail -s /bin/true

Như các bạn thấy, chuỗi lệnh ở trên là lệnh căn bản tạo tài khoản nhân dụng cho các user alias, qmaild, qmaill và qmailp có cùng một nhóm nhân dụng là nofiles. Ðặc biệt các lệnh trên không cho những user này một shell nào cả (-s /bin/true – lệnh true thực sự không làm gì cả) vì lý do các user này là các “nhân viên” hoạt động của qmail và chúng không hề cần shell. Một điểm cần nhớ trong quá trình tạo tài khoản nhân dụng: khi “người dùng” không cần một shell để thi hành trách nhiệm thì không nên cho họ một shell. Trường hợp một tài khoản nhân dụng bị hack, tin tặc khó có thể đi sâu hơn nếu tài khoản nhân dụng đó không được phép xử dụng bất cứ một shell nào.

- Tương tự, tạo nhóm nhân dụng qmail như sau:
# groupadd qmail

- Tạo tài khoản nhân dụng cho nhóm nhân dụng qmail này:
# useradd qmailq -g qmail -d /var/qmail -s /bin/true
# useradd qmailr -g qmail -d /var/qmail -s /bin/true
# useradd qmails -g qmail -d /var/qmail -s /bin/true

Một lần nữa, các “người dùng” qmailq, qmailr và qmails thuộc nhóm qmail này không cần shell. Lý do phải tạo các người dùng như trên sẽ được giải thích trong những bước sau.

Bước kế tiếp rất quan trọng. Bước này kiểm nghiệm chủ quyền và nhóm nhân dụng của các “người dùng” vừa tạo ra ở trên.

- Dùng vihoặc bất cứ text editor nào vào /etc/group và viết xuống mã hiệu (GID hay group ID) của nhóm nhân dụng nofiles và qmail.

- Ví dụ group nofiles có mã hiệu là 2004 và group qmail là 2005. Bạn dùng vi vào /etc/passwd và kiểm lại xem các entry cho alias, qmaild, qmaill, qmailp, qmailq, qmailr và qmails có đúng nhóm nhân dụng và shell của họ là /bin/true hay không. Những entry này tương tự như:
alias:*:1005:2004::/var/qmail/alias:/bin/true
qmaild:*:1006:2004::/var/qmail:/bin/true
qmaill:*:1007:2004::/var/qmail:/bin/true
qmailp:*:1008:2004::/var/qmail:/bin/true
qmailq:*:1009:2005::/var/qmail:/bin/true
qmailr:*:1010:2005::/var/qmail:/bin/true
qmails:*:1011:2005::/var/qmail:/bin/true

Trong các entry ở trên mỗi user có riêng một mã hiệu và thuộc vào nhóm nhân dụng khác nhau.

2.4.4 Build binaries từ mã nguồn
Ðến đây bạn đã sẵn sàng thực hiện bước compile và build qmail. Các bước build qmail như sau:
- cd vào thư mục chứa mã nguồn của qmail
# cd /usr/local/src/qmail-1.03

- Ðánh lệnh make buộc compiler biên dịch mã nguồn của qmail dựa trên chỉnh định của hồ sơ Makefile
# make

- Ðánh các lệnh make setup check. Ðây là 2 lệnh gom lại thành một.. Lệnh thứ nhất make setup chuyển các binaries đã được build ở trên vào đúng nơi của nó. Lệnh thứ nhì make check là lệnh dùng để kiểm tra lại thực tính của các hồ sơ và binaries được build.
# make setup check

- Bước kế tiếp là bước hiệu chỉnh DNS cho qmail. Nếu DNS server (fully qualified) của bạn đã sẵn sàng, bạn chỉ cần chạy lệnh:
# ./config

Lệnh này kiểm tra DNS server của bạn, nếu không có gì trở ngại nó đặt domain name của bạn vào /var/qmail/control/defaultdomain và /var/qmail/control/plusdomain (plusdomain dành cho một binary của qmail “qmail-inject” để thêm vào entry của plusdomain khi cần. Xem thêm ở phần 4: Hồ sơ điều chỉnh của Qmail trong “qmail-control”). Lệnh này cũng thêm vào các entry cần thiết cho /var/qmail/control/locals và /var/qmail/control/rcphosts.

Vì một lý do trục trặc nào đó thuộc DNS làm cho lệnh ./config ở trên không thể lấy được DNS entry để điều chỉnh các hồ sơ trên, bạn phải dùng lệnh ./config-fast để cài các entry cần thiết vào /var/qmail/control/

- Ðánh lệnh ./config-fast với thông số là domain name của bạn
# ./config-fast mydomain.com

mydomain.com phải là một domain name hoàn toàn hợp pháp và đã đăng ký với Internic (xem ở bước 2.2: Yêu cầu để cài đặt qmail ở trên). Lệnh ./config-fast của bước này sẽ cài các entry cần thiết với domain name bạn đã cho (như thông số ở trên); chắc chắn bạn sẽ không bị trở ngại gì trong bước này. Tuy nhiên, những bước sau này bạn sẽ gặp trở ngại nếu như bạn không cung cấp một domain name hợp pháp. Bước này chỉ buộc ./config-fast cài vào entry bạn cung cấp mà không bảo đảm (không kiểm nghiệm) là domain name đó giá trị hay không.

2.4.5 Cài ucspi-tcp
ucspi-tcp là phần mềm Dr. Dan Bernstein viết với mục đích thay thế cho inet daemon của Unix. Inet daemon được dùng rộng rãi trên các ứng trình Unix và gần đây, xinet ra đời để nâng cao tính năng của inet. Theo Dr Bernstein, phần mềm ucspi-tcp (dùng Unix Client-Server Program Interface cũng của ông) gọn nhẹ, hiệu quả và an toàn hơn inet rất nhiều. Bản thân người viết tài liệu này đã thử cả hai ứng dụng trên xinetd và uscpi-tcp và thấy rõ ưu điểm của ucspi-tcp trên bình diện hiệu năng. Ucspi-tcp được tạo ra với quan tâm bảo mật nên cách xử lý socket giữa client và server rất hiệu quả. Thực tế cho thấy ucspi-tcp ứng hoạt khít khao với qmail.

- Ðể compile và build uscpi-tcp, bạn cd vào thư mục uscpi-tcp
# cd /usr/local/src/ucspi-tcp-0.88

- Ðánh lệnh make buộc compiler biên dịch mã nguồn của ucspi-tcp dựa trên chỉnh định của hồ sơ Makefile
# make

- Ðánh các lệnh make setup check. Ðây là 2 lệnh gom lại thành một.. Lệnh thứ nhất make setup chuyển các binaries đã được build ở trên vào đúng nơi của nó. Lệnh thứ nhì make check là lệnh dùng để kiểm tra lại thực tính của các hồ sơ và binaries được build.
# make setup check

Nếu quy trình này không bị trở ngại gì, bạn đã compile và build xong ucspi-tcp.

2.4.6 Cài daemontols
Daemontools là một phần mềm giúp bạn rất nhiều trong quy trình quản lý và điều hành qmail server. Bạn có thể dùng qmail mà không cần đến daemontools. Tuy nhiên, khi đã dùng qmail nhiều hơn, bạn sẽ khám phá daemontools là một thứ đồ nghề không thể thiếu được.

Ðể compile và build daemontools, chỉ đơn giản cd vào thư mục của daemontools-0.76
# cd /usr/local/src/admin/daemontools-0.76

- Thư mục này có hai thư mục con, bạn không cần vào các thư mục con mà chỉ cần đánh lệnh
# package/install

(Còn tiếp)

Biên dịch Linux kernel - phần 4 (phần cuối)

2007-06-20T20:03:00.000+10:00

9. Cài kernel
Phần này giới thiệu hai cách cài kernel vừa biên dịch và chỉnh định boot loader.

9.1 Cài qua "make install"
Ít người dùng đến chức năng "make install" này vì một số bản phân phối không có các tiện ích cần thiết để thực hiện trọn vẹn bước này. "make install" tiện lợi và an toàn hơn cài bằng tay vì nó thao tác các bước cần thiết để thiết lập kernel mới trên hệ thống. Các bước này bao gồm quy trình lưu trữ kernel cũ (trong thư mục /boot), copy kernel image mới, copy System.map mới, điều chỉnh boot loader configuration (lilo.conf hoặc grub.conf) và cập nhật boot loader.

Bước "make install" dựa trên hồ sơ Makefile và install.sh, một shell script thuộc thư mục ./arch/$ARCH/boot. Shell script install.sh "gọi" một số shell script khác như /sbin/installkernel và /sbin/new-kernel-pkg, ngoài ra các shell scripts này còn dựa vào một binary có tên là "grubby" để tạo thông tin trong grub.conf nếu bạn dùng GRUB. Các shell scripts "installkernel" và "new-kernel-install" thuộc gói mkinitrd của RedHat, các bản phân phối khác có những ứng dụng tương tự. Nếu bản phân phối bạn dùng không có gói tương tự, bạn phải cài kernel bằng tay (phần 9.2) hoặc tạo các script tương tự để thực hiện bước này. Trong khuôn khổ giới hạn của bài viết, tôi không đi sâu vào vấn đề tạo các script tiện ích.

Để cài Linux kernel mới, bạn chỉ đơn giản chạy lệnh # make install ở chế độ super user từ trong thư mục chứa mã nguồn của Linux kernel. Sau khi hoàn tất bước "make install" bạn nên kiểm tra lại cấu hình của boot loader trên máy và chạy các lệnh tương ứng (nếu cần) để chỉnh định boot loader cho chính xác.

9.1.1 Đối với GRUB
Ví dụ bạn có hai phiên bản kernel trên máy 2.4.20 (phiên bản đang chạy) và 2.4.26 (phiên bản vừa được biên dịch), sau khi chạy "make install", grub.conf có chi tiết tương tự như sau:

{b}default=1{/b}
timeout=20
splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title Linux (2.4.26)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.26 ro root=/dev/hda1
    initrd=/boot/initrd-2.4.26.img

title Linux (2.4.20)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20 ro root=/dev/hda1
    initrd=/boot/initrd-2.4.20.img

- chi tiết cần chú ý là biến default. Trong ví dụ trên, bạn có hai kernel trong cấu hình GRUB cho các phiên bản 2.4.26 và 2.4.20. Nếu bạn muốn boot kernel 2.4.26 theo mặc định thì giá trị của default phải là 0 (grub đếm thứ tự các kernel từ giá trị 0, không phải từ giá trị 1). Khi chạy "make install", các tiện ích của "install" tự động đưa vào các chi tiết thuộc kernel mới vào cấu hình GRUB. Tuy nhiên, giá trị default vẫn giữ ở giá trị chỉ định cho kernel hiện đang hoạt động trên máy. Bạn cần chỉnh giá trị này để buộc boot loader tải lên phiên bản kernel mới. Một chi tiết hết sức quan trọng bạn cần chú ý là giá trị root (hdX,Y). Nếu GRUB đã được cài trong lúc cài đặt hệ thống từ CD và đã hoạt động hoàn chỉnh, bạn không nên thay đổi giá trị này. Giá trị này chỉ cần thay đổi nếu bạn thêm đĩa cứng và thay đổi các partitions trên máy.

- sau khi chỉnh định và lưu trữ grub.conf thích hợp, bạn chỉ cần tái khởi động máy. Nếu bạn dùng GRUB làm boot loader thì công tác tái biên dịch nhân Linux hoàn thành ở đây.

- giải pháp phòng bị trường hợp không thể boot vào kernel mới rất đơn giản nếu dùng GRUB làm boot loader. Bạn chỉ cần thêm một dòng fallback 1 vào cấu hình grub.conf là đủ. Chỉnh định này cho GRUB boot loader biết nếu dùng "default=0" để boot kernel mới nhất (2.4.26 trong ví dụ này) nhưng không thành công vì lý do nào đó thì thử boot lại với kernel cũ hơn (2.4.20). Xem thêm ở phần 10 nếu không thể boot được vào Linux vì boot loader bị hỏng.

9.1.2 Đối với LILO
Ví dụ bạn có hai phiên bản kernel trên máy 2.4.20 (phiên bản đang chạy) và 2.4.26 (phiên bản vừa được biên dịch), sau khi chạy "make install", lilo.conf có chi tiết tương tự như sau:

prompt
timeout=50
{b}default=linux{/b}
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message

image=/boot/vmlinuz-2.4.20
initrd=/boot/initrd-2.4.20.img
root=/dev/hda1
label=linux-2.4.20
read-only
        
image=/boot/vmlinuz
initrd=/boot/initrd-2.4.26.img
root=/dev/hda1
{b}label=linux{/b}
read-only

- chi tiết cần chú ý là biến default. Trong ví dụ trên, bạn có hai kernel trong cấu hình LILO cho các phiên bản 2.4.26 và 2.4.20. Nếu bạn muốn boot kernel 2.4.26 thì giá trị của default phải là giá trị label thuộc kernel nào bạn muốn dùng. Trong trường hợp này, label có giá trị là linux chỉ định cho kernel 2.4.26. Khi chạy "make install", các tiện ích của "install" đưa vào các chi tiết của kernel mới vào cấu hình LILO. Ở đây vmlinuz là symbolic link của hồ sơ vmlinuz-2.4.26. Bạn nên kiểm tra lại giá trị default để bảo đảm boot loader sẽ tải kernel vừa biên dịch khi boot.

- sau khi chỉnh định và lưu trữ lilo.conf theo ý muốn, bạn phải chạy lệnh:
# /sbin/lilo và chú ý trường hợp hệ thống báo lỗi trong bước cài lilo làm boot loader. Nếu có, điều chỉnh cho chính xác và thực hiện lại lệnh trên. Với ví dụ trên, bạn sẽ được báo kết quả trên console tương tự như:
Added linux*
Added linux-2.4.20
Giá trị nào đi kèm với dấu hoa thị (*) chỉ định cho kernel được boot theo mặc định.

- với LILO, giải pháp đơn giản nhất phòng bị trường hợp không thể boot vào kernel mới mang tính tạm thời. Trước khi tái khởi động máy dùng lệnh như sau:
# /sbin/lilo -R linux
rồi chạy
# reboot

Nên nhớ lệnh trên được đưa ra như một ví dụ cho kernel 2.4.20 và 2.4.26 với cấu hình boot loader như trên, bạn phải điều chỉnh đúng phiên bản kernel bạn đang biên dịch.

Lệnh thứ nhất cho LILO biết lần kế tiếp máy tái khởi động thì thử dùng kernel 2.4.26. Nếu không thành công cũng không chỉnh định cho kernel 2.4.26 làm kernel boot theo mặc định và lần boot kế tiếp sẽ dùng kernel 2.4.20 (kernel này chắc chắn phải làm việc được vì nó đã dùng để biên dịch kernel 2.4.26).

Lệnh thứ nhì chỉ đơn giản ra lệnh cho máy tái khởi động.

Nếu dùng lệnh "/sbin/lilo -R linux-x.xx.xx" và boot vào kernel mới thành công thì sau khi boot vào, bạn cần chỉnh định cho kernel x.xx.xx làm mặc định rồi mới chạy "/sbin/lilo -v" như đã nói ở trên (trong phần biến "default" của lilo.conf).

9.2 Cài qua các bước bằng tay
Các bước cài "bằng tay" tương tự như các bước "make install" ở trên nhưng được thao tác "bằng tay". Thật ra quy trình này rất đơn giản, điều bạn cần lưu ý là phải thực hiện chính xác để tránh những trở ngại trong bước này và trong giai đoạn boot vào kernel mới.

9.2.1 Tạo initrd
Trường hợp bạn biên dịch các drivers quan trọng ở dạng modules có liên hệ đến quy trình boot của Linux (như SCSI driver, RAID driver, các loại filesystem mà root filesystem dùng như ext3, jbd...) thì chắc chắn bạn phải cần đến initrd (INITial Ram Disk). Mục đích chính của initrd là phương tiện tải sẵn các driver cần thiết cho kernel trong quá trình boot. Nếu không muốn dùng initrd, bạn phải biên dịch các driver trực tiếp vào kernel (hay còn gọi là static compile). Nên chú ý một số bản phân phối Linux không dùng initrd, họ khuyến khích biên dịch các driver liên hệ đến quy trình boot trực tiếp vào kernel. Muốn tham khảo thêm chi tiết về RAM disk cho trường hợp này, xem <KERNEL_SRC>/Documentation/ramdisk.txt.

Quy trình tạo initrd rất đơn giản, chỉ cần chạy lệnh:
# /sbin/mkinitrd /boot/initrd-<KERNEL_VERSION>.img <KERNEL_VERSION>, trong đó:

- Tham số thứ nhất /boot/initrd-<KERNEL_VERSION>.img chỉ định cho hồ sơ và thư mục chứa hồ sơ initrd. Thông thường initrd của kernel được chứa trong thư mục /boot cùng với các thông tin và hồ sơ khác cần thiết cho quy trình boot.

- Tham số <KERNEL_VERSION> thứ nhì chính là kernel nào bạn muốn tạo initrd cho nó. Tất nhiên thư mục chứa các modules cho kernel version này phải hiện hữu ở /lib/modules/, nếu không bạn sẽ được system báo lỗi.

Tùy bản phân phối, mkinitrd đòi hỏi thêm các thông số cụ thể để chỉ đường dẫn đến kernel. Nếu gặp trở ngại trong bước tạo mkinitrd bạn nên tham khảo tài liệu cụ thể cho bản phân phối mình đang dùng hoặc tối thiểu là xem man mkinitrd và tài liệu <KERNEL_SRC>/Documentation/initrd.txt để xem thêm các thông tin cần thiết.

Một điểm đáng chú ý là từ kernel 2.5.x (development kernel) trở đi, initramfs được phát triển với mục đích hỗ trợ và sẽ đi đến chỗ thay thế initrd (init ram disk). Ưu điểm nổi bật của initramfs là nó có thể chứa các bộ lưu trữ ở dạng cpio "newc" hoặc "crc" (được nén hoặc không được nén). initramfs cho đến nay chưa phổ biến và ứng dụng rộng rãi trên các bản phân phối Linux. Tuy nhiên, hướng phát triển và ứng dụng initramfs có vẻ đầy hứa hẹn.

9.2.2 Copy kernel và System.map
Sau khi hoàn thành bước "make modules_install" (phần 8.2), lúc này bạn đã có trọn bộ các bộ phận cần thiết cho kernel mới bao gồm kernel image và các modules thuộc kernel này.

- copy bzImage từ <KERNEL_SRC>/arch/i386/boot/ đến thư mục /boot, ví dụ:
# cp /usr/src/linux-2.4.26/arch/i386/boot/bzImage /boot/bzImage-2.4.26

install script của RedHat và một số phân phối khác bao gồm bước copy bzImage thành vmlinuz, bạn có thể thực hiện (hay không tùy ý, bước này tương tự như bước ở trên) như sau:
# cp /usr/src/linux-2.4.26/arch/i386/boot/bzImage /boot/vmlinuz-2.4.26

kế tiếp là xoá symbolic link cũ (nếu có) của vmlinuz trong thư mục /boot:
# rm -f /boot/vmlinuz

và sau đó tạo symbolic link mới cho vmlinuz-2.4.26 thành:
# ln -s /boot/vmlinuz-2.4.26 /boot/vmlinuz

Tất nhiên bạn phải điều chỉnh lại cấu hình boot loader để thích ứng với cách gọi "bzImage" hoặc "vmlinuz" này cho giá trị image (trong lilo.conf) hoặc giá trị kernel (trong grub.conf). Cách dùng và cách gọi bzImage và vmlinuz tạo khá nhiều bối rối cho người dùng Linux khi tiếp cận quy trình biên dịch kernel. Một số bản phân phối Linux dùng bzImage, một số khác lại dùng vmlinuz. Dù gì đi chăng nữa, đây cũng chỉ là cách dùng và cách gọi; bạn nên dùng theo cách bản phân phối Linux nào có trên máy.

- phần còn lại là bước copy hồ sơ System.map:
# cp /usr/src/linux-2.4.26/System.map-2.4.26 /boot/System.map-2.4.26

kế tiếp là xoá symbolic link cũ của System.map trong thư mục /boot:
# rm -f /boot/System.map

và sau đó, tạo symbolic link mới cho System.map:
# ln -s /boot/System.map-2.4.26 /boot/System.map

9.2.3. Chỉnh bootloader config

9.2.3.1 Nếu bootloader là GRUB
Ví dụ bạn có hai phiên bản kernel trên máy 2.4.20 (phiên bản đang chạy) và 2.4.26 (phiên bản vừa được biên dịch) thì grub.conf tương tự như sau:

default=0
timeout=20
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title Linux (2.4.20)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20 ro root=/dev/hda1
    initrd=/boot/initrd-2.4.20.img

Chỉnh thành:

default=0
timeout=20
splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title Linux (2.4.26)
    root (hd0,0)
    kernel /boot/vmlinuz ro root=/dev/hda1
    initrd=/boot/initrd-2.4.26.img

title Linux (2.4.20)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20 ro root=/dev/hda1
    initrd=/boot/initrd-2.4.20.img

Sau khi đã lưu trữ (save) cấu hình của /etc/grub.conf ở trên (/etc/grub.conf là symbolic link đến /boot/grub/menu.1st) và tái khởi động máy để bắt đầu dùng kernel vừa được biên dịch. Nếu bạn dùng GRUB làm boot loader thì công tác tái biên dịch nhân Linux hoàn thành ở đây. Nên lưu ý trong ví dụ này, tôi dùng vmlinuz thay vì dùng bzImage, bạn nên chọn lựa theo ý và điều chỉnh cho phù hợp trong grub.conf.

Đối với giải pháp phòng bị trường hợp không thể dùng GRUB để boot vào kernel mới, xem chi tiết ở phần 9.1.1 ở trên.

9.2.3.2 Nếu bootloader là LILO
Ví dụ bạn có hai phiên bản kernel trên máy 2.4.20 (phiên bản đang chạy) và 2.4.26 (phiên bản vừa được biên dịch) thì lilo.conf tương tự như sau:

prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message

image=/boot/vmlinuz
initrd=/boot/initrd-2.4.20.img
root=/dev/hda1
label=linux
read-only

Chỉnh /etc/lilo.conf để cài kernel mới (2.4.26 cho ví dụ ở đây), bạn có /etc/lilo.conf như sau:

prompt
timeout=50
{b}default=linux{/b}
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message

image=/boot/vmlinuz-2.4.20
initrd=/boot/initrd-2.4.20.img
root=/dev/hda1
{b}label=linux-2.4.20{/b}
read-only
        
image=/boot/vmlinuz
initrd=/boot/initrd-2.4.26.img
root=/dev/hda1
{b}label=linux{/b}
read-only

Sau khi đã lưu trữ (save) cấu hình của /etc/lilo.conf ở trên, chạy lệnh:
# /sbin/lilo để đăng ký kernel mới cho LILO boot loader.

Đối với giải pháp phòng bị trường hợp không thể dùng LILO để boot vào kernel mới, xem chi tiết ở phần 9.1.2 ở trên.

10. Tái khởi động máy và chỉnh lý nếu gặp trục trặc
Tới đây, bạn cần tái khởi động máy để boot vào kernel mới. Nếu không có gì trở ngại, máy sẽ boot vào Linux bình thường. Bạn có thể kiểm lại xem kernel mình đang chạy có đúng phiên bản vừa được biên dịch hay không bằng cách chạy:
$ uname -r

hoặc,
$ cat /proc/version

Nếu kết quả báo phiên bản kernel cũ thì có nghĩa boot loader (LILO hoặc GRUB) đã không boot kernel vừa được biên dịch. Bạn nên kiểm tra lại boot configuration (lilo.conf hoặc grub.conf) cho đúng theo chi tiết đã nêu ở trên.

10.1 Bị treo khi bootloader đang boot vào linux
Trở ngại trong giai đoạn boot loader chuẩn bị boot vào Linux thông thường do cấu hình boot loader ấn định không đúng và boot loader được cài lên không đúng boot partition hoặc MBR bị hỏng (hiếm thấy trong quá trình tái biên dịch và cài kernel mới nếu thực hiện đúng quy cách). Trong trường hợp này, bạn phải:
- dùng đến đĩa mềm "cấp cứu" được tạo ở phần 6.1 để boot vào Linux

- Đến giai đoạn này bạn hẳn phải biết vị trí của root partition (/) trên đĩa cứng để mount partition của đĩa cứng:
# mount /dev/hdXy /mount/point/somewhere, trong đó X là ví trí đĩa cứng trên máy, y là vị trị root partition trên đĩa cứng này.

- đổi root (chroot) trở thành root partition của đĩa cứng:
# chroot /mount/point/somewhere, trong đó /mount/point/somewhere là nơi đĩa cứng của bạn được mount.

- kiểm tra lại cấu hình của boot loader và cài lại boot loader cho máy (xem phần 9.1.1 hoặc 9.1.2 tùy theo boot loader bạn dùng là GRUB hay LILO). Điểm cần chú ý ở đây cho GRUB boot loader là bạn phải chạy lệnh:
# /sbin/grub-install /dev/hdX, trong đó /dev/hdX là disk nào chứa MBR cho hệ thống (thường là đĩa đầu tiên trên máy - Primary Master). Lệnh trên sẽ tái thiết lập boot record và loại bỏ các trường hợp MBR bị hỏng. Tương tự cho LILO, bạn phải chạy lệnh:
# /sbin/lilo.

10.2 Bị treo trong quá trình kernel được load
Nếu bạn vướng vào các trở ngại trong giai đoạn kernel đang được tải lên thông thường là do các drivers tối cần thiết để mount filesystems trên máy bị thiếu. Giả sử bạn dùng ext3 cho root partition (/) chứa kernel. Để có thể mount root partition này, ext3 module phải được biên dịch và initrd phải tải module này lên. Tương tự ứng dụng cho các trường hợp dùng filesystem khác và cũng thiếu module.

Trong trường hợp này, bạn cần ghi xuống phần lỗi được báo trong khi boot vào kernel mới để xác định lỗi này thuộc phần nào của cấu hình biên dịch nhân Linux và từ đó điều chỉnh lại và tái biên dịch lại cho thích ứng. Nói một cách tổng quát, bạn phải:
- tái khởi động lại máy và boot vào phiên bản cũ của kernel (hoặc boot loader sẽ boot vào phiên bản cũ của kernel nếu bạn dùng biện pháp trù bị đã được đề cập ở phần 9.1.1 và 9.1.2 ở trên)
- chọn lựa và chỉnh định cấu hình biên dịch nhân Linux lại (xem phần 7.2.2 để tránh lặp lại bước lựa chọn cấu hình một cách không cần thiết).
- thực hiện lại các bước đã nêu ra trong phần 8 và 9 ở trên

11. Vá và biên dịch kernel
Mã nguồn của Linux kernel thường được "vá" rồi tái biên dịch nhiều hơn là được biên dịch từ trọn bộ mã nguồn tải về từ kernel.org nếu bạn đã quen thuộc với quy trình tái biên dịch hoặc bạn có nhu cầu phải cập nhập kernel của máy thường xuyên. Tại sao lại cần "vá"? Mã nguồn của Linux kernel cần được vá vì các lý do thường gặp như sau:
- mã nguồn của Linux kernel được cập nhật. Bạn đã có sẵn mã nguồn của Linux kernel (cũ hơn) trên máy. Muốn nâng cấp phiên bản của Linux kernel, bạn chỉ cần tải các "miếng vá" về để vá (thay vì phải tải trọn bộ mã nguồn của Linux kernel cho phiên bản mới).
- một số "drivers" được cập nhật. Để xử dụng các driver mới này (và các drivers này cần được biên dịch để nối với các thư viện hiện hành trên máy), bạn chỉ cần tải các "miếng vá" của những drivers này để vá Linux kernel và tái biên dịch chúng.

11.1 Các điểm quan trọng trước khi vá
Tương tự như phần 6.2, 6.3 và 6.4 ở trên, quy trình tải các miếng vá (patch) cho Linux kernel y hệt như tải trọn bộ gói mã nguồn của Linux kernel. Điểm khác biệt là bạn phải tải các hồ sơ khởi đầu bằng patch và chọn cho đúng các patch cần thiết cho kernel cần được patch.

Điểm tối yếu cần ghi nhớ là khi vá mã nguồn của Linux kernel, bạn phải vá đúng thứ tự và đầy đủ các miếng vá cho đến đúng phiên bản cần có. Ví dụ, bạn đang có phiên bản kernel là 2.4.20 trên máy và bạn muốn tái biên dịch phiên bản kernel của máy trở thành 2.4.26. Thay vì tải trọn bộ mã nguồn của kernel 2.4.26 và biên dịch lại (như đã trình bày trong suốt bài viết này), bạn có thể tải các bản vá 2.4.21, 2.4.22, 2.4.23, 2.4.24, 2.4.25 và 2.4.26 về máy. Tổng cộng dung lượng các bản vá này chỉ là một phần rất nhỏ so với trọn bộ gói mã nguồn 2.4.26. Tất nhiên bạn đã có mã nguồn của kernel 2.4.20 trên máy không thì không thể vá được.

11.2 Tải, xả và vá
Các miếng vá thường được nén ở hai dạng: .gz hoặc .bz2 như gói mã nguồn. Bạn có thể tùy chọn và có thể tải các miếng vá này về bất cứ nơi nào trên máy. Sau khi tải chúng về, bạn có thể thực hiện quy trình tương tự như sau:

giả định các bản vá được nén ở dạng .bz2, nơi chứa mã nguồn của Linux kernel ở /usr/src và thực tính của các patch này đã được kiểm tra. Trong ví dụ này, giả định phiên bản đang dùng trên máy là 2.4.20 và phiên bản cần được vá sẽ là 2.4.26

a)
# chuyển vào thư mục /usr/src
$ cd /usr/src

b)
# xả nén các patch ở dạng .bz2 vào thư mục /usr/src. Lặp lại cho đến khi xả hết các patch cần được vá
$ tar xfvj /path/to/patch/patch-x.xx.xx ./

c)
# dọn dẹp sạch sẽ mã nguồn kernel hiện có trên máy, giả định phiên bản mã nguồn hiện có là 2.4.20
cd ./kernel-2.4.20
make mrproper

d)
# lưu một bản mã nguồn kernel 2.4.20 trong thư mục /usr/src phòng bị cho sự cố trong quá trình vá (nếu bạn không lưu một bản mã nguồn nguyên thủy của kernel 2.4.20 trên máy, hoặc bản mã nguồn 2.4.20 này cũng đã được vá trước đây)
tar cvf ../linux-2.4.20.tar ./

e)
# vá các miếng vá theo đúng thứ tự và theo dõi bất cứ lỗi nào được báo
$ patch -p1 < ../patch-2.4.21
$ patch -p1 < ../patch-2.4.22
$ patch -p1 < ../patch-2.4.23
$ patch -p1 < ../patch-2.4.24
$ patch -p1 < ../patch-2.4.25
$ patch -p1 < ../patch-2.4.26

hoặc thực hiện kiểu "lười" như sau:

# tạo một biến PATCH tạm thời chứa tên các patch cần patch theo đúng thứ tự, tách rời bằng phím trống (space)
$ export PATCH="patch-2.4.21 patch-2.4.22 patch-2.4.23 patch-2.4.24 patch-2.4.25 patch-2.4.26"

# chạy vòng lặp
$ for item in $PATCH; do patch -p1 < ../$item; done

Nếu trong khi vá không có gì trở ngại, bạn sẽ thấy các thông tin tương tự:

patching file xxx
patching file yyy
....

cho đến khi kết thúc.

Nếu trong khi vá bị báo lỗi, bạn phải ngưng bước vá (ctrl-C) và kiểm tra xem bạn có dùng đúng bản vá và thực hiện các bản vá đúng thứ tự phiên bản hay không. Không nên tiếp tục với bước vá khi gặp lỗi vì chắc chắn bạn sẽ gặp trở ngại trong giai đoạn biên dịch sau này. Để tránh các trở ngại về sau, nếu bị báo lỗi trong khi vá, cách tốt nhất bạn nên xoá trọn bộ thư mục chứa mã nguồn của Linux kernel (đang được vá và bị lỗi) và xả gói mã nguồn nguyên thủy hoặc gói bạn vừa lưu trữ ở trên rồi thử lại.

f)
# xoá thư mục chứa mã nguồn vừa vá và bị trục trặc, thư mục linux-2.4.20 được dùng như một ví dụ ở đây
$ cd /usr/src
$ rm -rf ./linux-2.4.20

g)
# xả gói mã nguồn được lưu trữ ở trên
$ tar xvf linux-2.4.20
$ cd ./linux-2.4.20

và sau đó lặp lại bước vá (bước e) theo đúng thứ tự các miếng và.

Sau khi vá thành công, bạn nên thực hiện hai bước kế tiếp như sau trước khi bắt tay vào việc chuẩn bị cấu hình biên dịch nhân Linux và biên dịch mã nguồn:

h)
# đổi tên thư mục chứa mã nguồn cho đúng phiên bản đã được vá (giúp bạn nhận diện phiên bản của mã nguồn đang có trên máy đã được vá tới phiên bản nào)
$ cd /usr/src
$ mv ./linux-2.4.20 ./linux-2.4.26

i)
# chỉnh giá trị "VERSION" trong Makefile chính của mã nguồn Linux. Thư mục chứa mã nguồn lúc này đã được đổi tên thành linux-2.4.26
$ vi ./linux-2.4.26/Makefile

Vài dòng đầu của hồ sơ Makefile này chứa các thông tin tương tự như sau (nếu mã nguồn của phiên bản 2.4.20 được xả từ gói mã nguồn nguyên thủy):

VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 20
EXTRAVERSION =

Bạn cần đổi giá trị SUBLEVEL thành 26 và lưu hồ sơ Makefile này (cho ví dụ này, hoặc bất cứ phiên bản nào bạn đã vá tới - xem thêm chi tiết về quy định phiên bản Linux kernel ở phần 3). Giá trị phiên bản 2.6.26 lấy từ hồ sơ Makefile sẽ được dùng trong quá trình biên dịch và cài đặt kernel về sau. Nếu bạn không điều chỉnh giá trị "VERSION" ở bước này, bước cài kernel về sau sẽ viết chồng lên kernel 2.4.20 đang có trên máy. Nói về mặt kỹ thuật việc viết chồng lên không có gì trở ngại. Tuy nhiên, nếu bạn gặp trục trặc sau khi đã biên dịch kernel nhưng không boot vào được thì sự thể sẽ rất phức tạp vì bạn không còn bản kernel chạy được trên máy.

Tới đây bạn đã thực hiện thành công bước vá mã nguồn Linux kernel và các bước phòng bị cần thiết. Bạn có thể tiếp tục với công việc tái biên dịch Linux kernel như đã nói trên.

<hết>

Biên dịch Linux kernel - phần 3

2007-06-20T15:19:00.000+10:00

7.2 Điều chỉnh cấu hình biên dịch nhân Linux
Vậy, để điều chỉnh các chọn lựa cho một cấu hình biên dịch nhân Linux, có một số cách thực hiện chuyện này.

7.2.1 Các "config" tools
Như đã đề cập ở phần 6.5, mặc định cấu hình biên dịch nhân nằm ở ./arch/i386/defconfig. Khi khởi động một "config" tool nó sẽ tự động đọc và dùng nội dung của config mặc định này trước khi bạn chỉnh sửa theo ý.

Để chỉnh cấu hình biên dịch nhân Linux, chuyển vào thư mục chứa mã nguồn của kernel (đã xả nén):
$ cd /usr/src/linux-2.4.26 (ví dụ này dùng kernel 2.4.26 - xem lại phần xả nén ở phần 6.4)
và việc đầu tiên rất nên làm đó là chạy lệnh:
$ make mrproper
Không kể bạn dùng bản phân phối Linux nào và phiên bản Linux kernel nào, bạn nên chạy lệnh này trước khi thực hiện quy trình tái biên dịch kernel. Target "mrproper" này dùng để xoá hết tất cả những gì còn "vất vưởng" trong các cây chứa mã nguồn của Linux kernel để nắm chắc mã nguồn trước khi được biên dịch phải ở tình trạng "sạch sẽ".

Có ba phương tiện "config" phổ biến có thể dùng để chỉnh cấu hình biên dịch nhân Linux. Sau khi chuyển vào thư mục /usr/src/linux-2.4.26, bạn có thể chọn một trong ba cách:
- make config
- make menuconfig
- make xconfig

Trong đó,
- make config là phương tiện đơn giản nhất và không đòi hỏi thêm bất cứ thư viện nào khác để chạy công cụ này. make config sẽ tạo ra một loạt câu hỏi (ở dạng prompt) và sau khi nhận được câu trả lời của bạn (Y, N, M như đã nói ở trên sau khi bạn nhấn phím Enter, xác nhận câu trả lời của mình), nó sẽ hình thành một cấu hình biên dịch nhân Linux. Nhược điểm của loại config này ở chỗ, nếu bạn lỡ trả lời sai (chọn Y, N hoặc M và gõ phím Enter), bạn không thể quay ngược lại để điều chỉnh mà phải bắt đầu lại từ đầu. Phương tiện "make config" này chỉ tiện lợi cho những ai rất kinh nghiệm và nắm rõ mình cần gì trong cấu hình biên dịch nhân, nó cũng tiện lợi cho quy trình chỉnh cấu hình biên dịch nhân từ xa (xuyên qua console và không dùng được X11 forward vì lý do gì đó). Sau khi hoàn tất các câu hỏi, công cụ này sẽ lưu trữ một cấu hình biên dịch nhân (được lưu ở dạng .config trong thư mục chứa mã nguồn của Linux) và sẵn sàng cho bước tạo dependency cho kernel build. Nếu hồ sơ .config đã tồn tại từ lần biên dịch trước, nó sẽ bị viết chồng lên ở giai đoạn này.
<insert hình>

- make menuconfig nâng cấp lên một mức cao hơn so với make config. Công cụ này cần thư viện và binaries "ncurses" để tạo GUI đơn giản. Với công cụ này, bạn có thể tái điều chỉnh các chi tiết tuỳ thích mà không phải bắt đầu lại từ đầu (nếu lỡ chọn sai) như dùng make config. Trên GUI đơn giản này, bạn có thể di chuyển, thay đổi các chọn lựa bằng cách dời chuyển phím mũi tên (lên xuống), chọn Y bằng phím Y, chọn N bằng phím N và chọn M bằng phím M. Với công cụ này, bạn cũng có thể tải một cấu hình biên dịch nhân có sẵn (đã làm từ trước và đã biên dịch thành công chẳng hạn) mà chẳng phải đi xuyên qua mọi chọn lựa để hình thành một cấu hình biên dịch nhân mới. Một đặc tính của công cụ này là nó chứa "help context sensitive" (phần giúp đỡ hoặc thông tin cho từng mục trong quá trình điều chỉnh configuration). Nếu bạn không nắm rõ giá trị hoặc tác dụng của module nào đó, bộ phận "help" này chắc chắn sẽ hữu ích. Sau khi đã hoàn thành các chọn lựa, bạn có thể lưu trữ một bản configuration trên máy để lần sau dùng lại và "exit" đồ nghề này. Ở giai đoạn này, một bản configuration được lưu lại (ở dạng .config trong thư mục chứa mã nguồn của Linux) và sẵn sàng cho bước tạo dependency cho kernel build. Tương tự như "make config", nếu hồ sơ .config đã tồn tại từ lần biên dịch trước, nó sẽ bị viết chồng lên.
<insert hình>

- make xconfig có lẽ là phương tiện được dùng rộng rãi nhất, nhất là cho những hệ thống chạy X Window. make xconfig cần trọn bộ thư viện Qt và X Window để tạo GUI. Các chọn lựa và cách di chuyển trong GUI này để điều chỉnh hoàn toàn giống như trường hợp dùng menuconfig và thêm một khả năng nữa là có thể dùng mouse để chọn. Nếu bạn cần tái biên dịch kernel và có thể dùng X Window thì nên dùng công cụ xconfig này vì nó dễ dùng nhất.

Trên Linux kernel 2.6.x series có thêm make gconfig. Tương tự như make xconfig, "gconfig" cũng tạo GUI config tool nhưng GUI này dựa trên thư viện Gtk.

7.2.2 Một số điểm cần chú ý trong giai đoạn hình thành cấu hình biên dịch nhân
- Dùng cấu hình biên dịch nhân có sẵn và điều chỉnh cho thích hợp với nhu cầu của mình. Nếu bạn dùng bản phân phối của RedHat, cấu hình biên dịch nhân có trong thư mục /boot ở dạng config-<KERNEL_VERSION> (hồ sơ cấu hình này từ các kernel do RedHat cung cấp). Để dùng cấu hình biên dịch nhân này, bạn có thể dùng make menuconfig hoặc make xconfig để tải configuration này lên và điều chỉnh theo ý muốn. Thật ra không có bất cứ tài liệu nào có thể giải thích cặn kẽ từng chọn lựa cho mỗi cấu hình máy cả. Ở mức độ tái biên dịch một kernel, bạn cần hiểu cấu hình máy và những chọn lựa trong một configuration đến mức độ có thể quyết định chọn lựa những gì cho thích hợp. Bản phân phối Debian cũng lưu trữ các cấu hình biên dịch nhân trong thư mục /boot tương tự như bản phân phối RedHat. Các bản phân phối khác có một số tương đồng và dị biệt, bạn nên tham khảo thêm các hướng dẫn cụ thể cho bản phân phối mình đang dùng.

- Lưu trữ cấu hình biên dịch nhân cho lần biên dịch kế tiếp. Nếu vì lý do gì đó khiến giai đoạn biên dịch kernel bị hỏng, bạn cần xem xét đoạn báo lỗi sau cùng khi công cụ biên dịch (compiler) thoát ra với "tình trạng không thành công" (exit status is not 0). Thông thường compiler thoát ra nửa chừng vì cách chọn lựa cấu hình biên dịch nhân có những điểm không thích hợp và thoả mãn (liên hệ nhau). Những lỗi được báo trên console giúp bạn xác định trục trặc nằm trong khu vực nào của cấu hình biên dịch nhân. Bạn chỉ cần tải hồ sơ biên dịch đã được lưu trữ lần cuối cùng lên và vào thẳng khu vực bị sự cố để xem xét và điều chỉnh, thay vì phải thiết lập từ dầu để tránh va vào những lỗi khác. Mỗi khi điều chỉnh và thay đổi cấu hình biên dịch nhân, bạn lại tiếp tục lưu lại một bản và đặt tên cho nó một cách hợp lý (ví dụ kernel-2.4.26-1 cho configuration thứ nhất, kernel-2.4.26-2 cho configuration thứ nhì.....).

- Nếu bạn dùng một "vanilla" kernel, mã nguồn kernel được tải về từ kernel.org hoặc mirror site của nó (bài viết này tập trung chủ yếu vào "vanilla" kernel), sau khi hoàn thành bước make config hoặc make menuconfig hoặc make xconfig, cấu hình biên dịch nhân đã được bạn điều chỉnh và chọn lựa sẽ đưọc lưu trữ ở dạng dấu (hidden) ở ./.config (các hồ sơ và thư mục bắt đầu bằng dấu chấm . được xếp loại là hidden files, chỉ có ls -la mới thấy chúng). Lần kế tiếp, sau khi chạy một trong số lệnh trên và tiếp nhận các thay đổi thì cấu hình biên dịch nhân lại tự động viết chồng lên ./.config. Cho nên, bạn có thể lưu trữ hồ sơ ./.config thành một hồ sơ có tên khác trước khi điều chỉnh và chọn lựa lần kế tiếp.

- Ngoài make config, make menuconfig, make xconfig hoặc make gconfig (cho kernel 2.6.x series), bạn còn có thể dùng một lệnh khác cho cả kernel series 2.4.x và 2.6.x là: make oldconfig. make oldconfig là một trường hợp đặc biệt dùng để đọc và dùng các chọn lựa đã có sẵn trong ./.config mà không cho bạn cơ hội đi xuyên qua để điều chỉnh và chọn lựa. Trường hợp này rất tiện lợi nếu bạn đã điều chỉnh và chọn lựa thành công một cấu hình biên dịch nhân cho mình.

Kernel 2.6.x series còn có bốn target cho bước này:
make defconfig: tạo một cấu hình biên dịch nhân mới với chế độ mặc định cho mọi chọn lựa
make allmodconfig: tạo một cấu hình biên dịch nhân mới với chế độ chọn lựa các modules khi có thể được
make allyesconfig: tạo một cấu hình biên dịch nhân mới với chế độ tiếp nhận yes (Y) cho mọi chọn lựa
make allnoconfig: tạo một cấu hình biên dịch nhân mới với chế độ tiêp nhận no (N) cho mọi chọn lựa. Chế độ này sẽ tạo ra một kernel rất nhỏ và đơn giản.

Hiếm khi bạn điều chỉnh một cấu hình biên dịch nhân Linux lần đầu mà không hề bị lỗi trong khi biên dịch. Cách lưu trữ từng configuration cho mỗi lần hiệu chỉnh là cách tốt nhất để bảo đảm "lỗi" lần trước sẽ không tái diễn. Nếu bạn chỉ đơn giản dùng cấu hình biên dịch nhân có sẵn (như RedHat Linux chứa trong /boot) và không điều chỉnh gì cả thì ngoài mục đích vá lỗi, lối dùng này chẳng có tác dụng gì về mặt nâng cao hiệu năng của máy.

8. Các bước xây dựng
8.1 Bước tạo dependency, dọn dẹp và tạo kernel image
Bước này có thể chạy ba lệnh:
make dep
make clean
make bzImage

hoặc gom chung lại thành một nhóm:
make dep clean bzImage

Nếu bạn chạy dep, clean và bzImage riêng biệt thì phải trông chừng khi nào lệnh thứ nhất hoàn tất để tiếp tục chạy lệnh thứ nhì và tiếp theo. Nếu bạn chạy ba lệnh một lượt thì lệnh thứ nhì tự dộng nối tiếp lệnh thứ nhất và lệnh thứ ba nối tiếp lệnh thứ nhì. Bạn không cần phải chờ đợi.

- bước "dep" là bước tạo dependencies và các includes cần thiết cho kernel. Bước này có thể mất nhiều phút, tùy vào CPU của từng máy. Đối với kernel series 2.6.x, bước này không cần thiết nữa.

- sau khi xong bước "dep", bước "clean" dùng để dọn dẹp tất cả những "objects" vụn vặt, không còn cần thiết vì dependencies đã hoàn tất ở trên.

- bước kế tiếp "bzImage" là bước tạo kernel image. Đây là bước hết sức quan trọng trong ba bước này. Nếu có sự cố gì xảy ra thì phải quay lại điều chỉnh cấu hình biên dịch nhân và đi xuyên qua các bước "make dep", "make clean" trở lại (cần phải chạy một số lệnh dọn dẹp trước khi make dep clean bzImage trở lại, vấn đề này sẽ được đề cập trong phần 10). Trên máy chạy Athlon Thunderbird 1.4Ghz, tôi mất chừng 10 phút để hoàn thành bước này. Trên một máy Pentium 233MMX cũ, tôi mất hơn 40 phút mới hoàn thành bước tạo kernel image.

Nếu ba bước trên hoàn toàn thành công, bạn có thể tìm thấy "kernel image" nằm trong thư mục ./arch/$ARCH/boot, trong đó $ARCH là dòng phần cứng của kernel bạn muốn biên dịch. Nếu máy bạn thuộc dạng i386, bạn sẽ tìm thấy kernel image trong ./arch/i386/boot. Kernel image này đã được tạo ra nhưng chưa được cài và ở bước này, nó chỉ lưu trong thư mục trên cho các bước về sau.

Thật ra có thể tạo nhiều dạng "kernel image". Dạng kernel image được tạo từ "make bzImage" là dạng phổ biến nhất hiện nay vì nó nén kernel image tốt nhất và thích hợp với hầu hết các loại computer. Bạn cũng có thể dùng:
make zImage, make zDisk hoặc make zLilo để tạo kernel image nếu kernel dự kiến rất nhỏ và không cần kỹ thuật nén cao độ như "bz". Dùng các dạng này cũng thích hợp trong trường hợp máy của bạn quá cũ và có thể có sự cố với "bzImage". Chỉ cần nắm một cách khái quát như sau:
- Phần bz hoặc z đi trước các image ở trên chỉ định cho loại nén nào được dùng với kernel image.
- Phần Image hoặc Disk hoặc Lilo chỉ định cho "loại" kernel image.
- Kernel image này được xả nén "on-the-fly" trong quá trình boot vào Linux sau này.

Xuyên qua ba bước ở trên, bạn sẽ thấy vô số thông điệp chạy trên console (ở kernel 2.6.x thông điệp chạy trên console ít hơn rất nhiều). Bất cứ lỗi nào (error) được báo trong bước này đều phải điều chỉnh cấu hình biên dịch nhân và trở lại bước "make dep". Cho đến giai đoạn này, lý do gây ra lỗi thường là:
- đồ nghề dùng để biên dịch không đúng phiên bản (xem phần 4.1 và 4.2 cho kernel series này bạn đang biên dịch)
- điều chỉnh sai hoặc thiếu một số chọn lựa nào đó trong cấu hình biên dịch nhân. Xem lỗi báo trước khi compiler thoát ra để xác định lỗi này thuộc phần nào trong cấu hình biên dịch nhân mà chỉnh lại cho thích hợp, nên dùng phương pháp tải và lưu trữ cấu hình biên dịch nhân đã đề cập trong phần 7.2.2 ở trên
- cấu hình máy quá thấp (memory / diskspace) không đủ để thực hiện ba bước ở trên. Nếu gặp sự cố này, nên nâng cấp máy hoặc dùng một máy khác để build kernel cho máy này.

Linux kernel 2.6.x series đơn giản hoá chỉ với một target "make all". Target này bao gồm luôn phần "make modules" trong bước 8.2 kế tiếp.

8.2 Bước tạo modules và cài modules
Bước này có thể chạy hai lệnh:
make modules
make modules_install

hoặc gom chung lại thành một dòng:
make modules modules_install

Điểm khác biệt giữa cách chạy hai lệnh riêng biệt hoặc chạy chung một dòng lệnh ở đây nằm ở chỗ:
- bạn có thể chỉ muốn biên dịch modules cho kernel mà không muốn cài (install) trên máy ngay sau khi các modules được biên dịch xong,
- hoặc bạn chỉ muốn biên dịch modules trên máy này rồi sẽ mang qua máy khác để cài.

Thông thường "make modules modules_install" đi chung vì ít người build modules trên một máy rồi mang đi cài trên một máy khác. Nếu chạy hai lệnh này một lượt, bạn phải chạy ở chế độ "super user" không thì modules không install được vì chỉ có root (super user) mới có thể "install" các modules vừa được biên dịch. Nếu bạn tách rời hai lệnh trên thì các lệnh tách rời như sau:
make modules # chạy bằng user account bình thường
su # chuyển sang chế độ "super user"
[enter password]
make modules_install # cài modules vừa biên dịch xong.

Bước "make modules" là bước biên dịch và tạo ra các modules (mà bạn đã chọn ở dạng M trong quá trình chỉnh lý cấu hình biên dịch nhân). Các modules đã được biên dịch sẽ được lưu trữ trong các thư mục thích ứng với từng nhóm "drivers" trong cây mã nguồn (kernel source tree). Giai đoạn này là giai đoạn biên dịch lâu nhất trong trọn bộ quá trình compiler thực sự biên dịch mã nguồn của kernel. Trên một máy chạy Athlon Thunderbird 1.4Ghz, bước này mất chừng 25 phút. Trong khi đó cùng số lượng modules cần biên dịch chạy trên máy Pentium 233MMX mất chừng trên 4 giờ đồng hồ.

Bước "make modules_install" sẽ "cài" các modules vừa được biên dịch vào thư mục /lib/modules/<kernel_version>. Nếu liệt kê thư mục này (ls), bạn sẽ thấy ít nhất một thư mục chứa modules cho kernel đang chạy trên máy hoặc nhiều thư mục cho nhiều phiên bản kernel trước đây (có từ quy trình cập nhật kernel bằng rpm hoặc quy trình nào đó tuỳ theo bản phân phối, hoặc từ quy trình biên dịch kernel tương tự như bài viết này). Khi boot Linux bằng một phiên bản kernel nào đó có trên máy, các modules thuộc kernel này (trong thư mục thích ứng với kernel version) sẽ được ứng tải.

Đối với kernel 2.4.x series, bạn có thể tham khảo chi tiết thông tin về modules, cách biên dịch modules tổng quát và cách xử dụng modules (thuộc user space) trong hồ sơ ./Documentation/modules.txt thuộc mã nguồn kernel bạn dự định biên dịch.

Đối với kernel 2.6.x series, bạn có thể tham khảo chi tiết thông tin về modules, cách biên dịch modules tổng quát và cách xử dụng modules (thuộc user space) trong ba hồ sơ ./Documentation/kbuild/modules.txt, ./Documentation/networking/net-modules.txt và ./Documentation/sound/oss/README.modules thuộc mã nguồn kernel bạn dự định biên dịch. Riêng với kernel 2.6.x series, bước "make modules" có thể thực hiện từ "make all" và bước "make modules_install" chỉ thực hiện riêng (ở chế độ super user) để cài các modules đã được biên dịch.

8.3 Tách rời mã nguồn và hồ sơ output trên kernel 2.6.x series
Nếu bạn đang dùng kernel 2.4.x series thì không cần tham khảo thông tin của mục 8.3. Những thông tin trong mục này chỉ giới thiệu thêm một số tiện ích hữu dụng cho quy trình chuẩn bị và biên dịch kernel 2.6.x.

8.3.1 "make help", một tiện ích mới trên kernel 2.6.x series
Ngoài những điểm khác biệt trong các make target đã được đề cập ở phần 8.1 và 8.2, trên kernel 2.6.x series, bạn có thể xử dụng một tiện ích khá hay mà kernel 2.4.x không có đó là phần "help" trước khi "make" mã nguồn của Linux kernel. Tất nhiên bạn phải chạy lệnh này sau khi vào trong thư mục chứa mã nguồn Linux kernel:
$ cd /usr/src/linux-2.6.6 (dùng kernel 2.6.6 trong trường hợp này)
$ make help sẽ cho thông tin trợ giúp như sau:

bash-2.05b$ make help
Cleaning targets:
 clean           - remove most generated files but keep the config
 mrproper     - remove all generated files + config + various backup files

Configuration targets:
 oldconfig       - Update current config utilising a line-oriented program
 menuconfig   - Update current config utilising a menu based program
 xconfig         - Update current config utilising a QT based front-end
 gconfig         - Update current config utilising a GTK based front-end
 defconfig       - New config with default answer to all options
 allmodconfig    - New config selecting modules when possible
 allyesconfig    - New config where all options are accepted with yes
 allnoconfig     - New minimal config

Other generic targets:
 all                   - Build all targets marked with [*]
* vmlinux          - Build the bare kernel
* modules         - Build all modules
 modules_install - Install all modules
 dir/                 - Build all files in dir and below
 dir/file.[ois]     - Build specified target only
 rpm                - Build a kernel as an RPM package
 tags/TAGS       - Generate tags file for editors
 cscope            - Generate cscope index

Documentation targets:
 Linux kernel internal documentation in different formats:
 sgmldocs (SGML), psdocs (Postscript), pdfdocs (PDF)
 htmldocs (HTML), mandocs (man pages, use installmandocs to install)

Architecture specific targets (i386):
* bzImage       - Compressed kernel image (arch/i386/boot/bzImage)
 install       - Install kernel using
                  (your) ~/bin/installkernel or
                  (distribution) /sbin/installkernel or
                  install to $(INSTALL_PATH) and run lilo
 bzdisk       - Create a boot floppy in /dev/fd0
 fdimage      - Create a boot floppy image

 make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build
 make O=dir [targets] Locate all output files in "dir", including .config
 make C=1   [targets] Check all c source with checker tool

Execute "make" or "make all" to build all targets marked with [*]
For further info see the ./README file
bash-2.05b$

Thông tin trên cho thấy "Makefile" chính của kernel 2.6.x series bao gồm các mục tiêu (target) biên dịch khi chạy make help. Với thông tin này, bạn có thể chọn các target make theo ý muốn mà không phải kiểm tra trong "Makefile" như với kernel 2.4.x series (kernel 2.4.x series không có "make help" như kernel 2.6.x series và kernel 2.4.x series không có nhiều make targets như kernel 2.6.x series). Điểm đặt biệt cần quan tâm là ba chọn lựa cuối trong thông tin "make help" cung cấp:
make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build
make O=dir [targets] Locate all output files in "dir", including .config
make C=1 [targets] Check all c source with checker tool

Một trong những chọn lựa quan trọng ở đây là nó cho phép bạn lưu trữ trọn bộ các hồ sơ output trong quá trình biên dịch vào một thư mục riêng biệt thay vì chứa chung với mã nguồn của kernel.

8.3.2 Tách rời mã nguồn và output files
Kernel 2.6.x series cho phép bạn tách rời mã nguồn của kernel và các hồ sơ output được tạo trong quá trình compile, các hồ sơ dấu (hidden) như .config, .depend.... trong các bước đề cập ở phần 7 và 8 cũng sẽ được lưu trữ ở thư mục nào bạn muốn dùng cho output files. Với phương tiện này, mã nguồn và các hồ sơ output sẽ không xen kẽ chung. Điểm quan trọng cần nhớ là khi đã dùng chọn lựa này thì phải dùng cho các bước "make" khác trong suốt quá trình biên dịch. Ví dụ, bạn có thể khởi đầu bằng:
make O=/path/to/output xconfig

thì các bước kế tiếp sẽ là:
make O=/path/to/output all (target "all" bao gồm "dep, clean, bzImage, modules"), và
make O=/path/to/output modules_install (chạy lệnh này bằng super user để cài modules của kernel).

<còn tiếp>

Biên dịch Linux kernel - phần 2

2007-06-19T20:50:00.000+10:00

6.3 Kiểm tra thực tính của mã nguồn
Điều quan trọng khi tải mã nguồn của kernel, nên tải gpg .sign cho phiên bản tương ứng. Mục đích là để kiểm tra thực tính của mã nguồn được tải về. Khi mã nguồn của Linux kernel được công bố, chúng được dồn lại thành một gói .tar và sau đó được nén bằng GNUzip hoặc bzip2, cả hai loại này sau khi được nén đều được tạo "chữ ký" .sign.

Kiểm tra thực tính của mã nguồn được tải về bằng phương pháp kiểm tra "chữ ký" của từng gói mã nguồn là một thói quen cần thiết. Lý do: các mã nguồn mở nói chung được công bố và phổ biến rộng rãi, ai cũng có thể chỉnh sửa (một cách không chính thức và không được nhóm phát triển chính thức cho phép) rồi đưa lên một server nào đó trên Internet. Người dùng tải về, biên dịch và cài trên máy mà không kiểm tra thực tính của chúng (và mã nguồn này có những thay đổi mờ ám) thì hậu quả khó mà lường.

Quy trình kiểm tra "chữ ký" chỉ đơn giản gói gọn trong một dòng lệnh:
$ gpg --verify linux-2.4.26.tar.bz2.sign linux-2.4.26.tar.bz2, trong đó
linux-2.4.26.tar.bz2.sign là "chữ ký" của gói linux-2.4.26.tar.bz2 được tải về từ server chứa mã nguồn Linux kernel
linux-2.4.26.tar.bz2 là gói mã nguồn Linux kernel được nén bằng bzip2

Trước khi có thể kiểm tra thành công bằng lệnh trên, bạn phải có gpg đã cài trong máy, tải và nhập public key của server chứa mã nguồn Linux kernel mà bạn tải về. Chi tiết hướng dẫn cho quy trình này ở:
http://www.kernel.org/signature.html

Quy trình tải mã nguồn Linux kernel và kiểm tra thực tính của mã nguồn này có thể tóm tắt bằng một ví dụ như sau:

# chuyển vào thư mục chứa mã nguồn của máy ở /usr/src là nơi thông thường. Đối với kernel 2.6.x series, bạn có thể dùng thư mục khác tùy ý:
cd /usr/src

# dùng wget để lấy một phiên bản mã nguồn từ server về ở dạng .bz2
wget http://www.kernel.org/p...2.4/linux-2.4.26.tar.bz2

# dùng wget để lấy .sign của phiên bản mã nguồn vừa được tải về
wget http://www.kernel.org/p...inux-2.4.26.tar.bz2.sign

# Dùng gpg với option verify để kiểm thực tính của mã nguồn vừa tải về
gpg --verify linux-2.4.26.tar.bz2.sign linux-2.4.26.tar.bz2

Ngoài phương pháp dùng signature cho vấn đề kiểm chứng thực tính của mã nguồn (không chỉ mã nguồn của Linux kernel) , bạn cũng thấy rất nhiều nơi trên Internet dùng "MD5sum" cho mục đích này (cho đến nay, mã nguồn Linux kernel dùng signature để kiểm chứng, không dùng MD5sum). Quy trình kiểm tra "MD5sum" chỉ đơn giản là một quy trình tạo một "MD5sum" từ mã nguồn được tải về trên máy và so sánh kết quả "MD5sum" này với hồ sơ "MD5sum" được tải về kèm với mã nguồn. Nếu "MD5sum" bạn tạo ra trên máy của mình với cùng gói mã nguồn mà không trùng hợp với "MD5sum" nguyên thuỷ tải về từ server thì thực tính của phần mã nguồn này không đáng tin cậy. Cách tốt nhất là chỉ nên tải mã nguồn ở những địa chỉ phố biến và đáng tin cậy. Cẩn thận hơn nữa (really paranoid), thì so sánh MD5sum với một số server chứa mã nguồn khác nhau.

- Kiểm tra thực tính của mã nguồn bằng MD5 checksum khá đơn giản. Tiện ích md5sum có sẵn hần như trên mọi bản phân phối. Lệnh tạo MD5 checksum đơn giản là lệnh:
# md5sum <file_cần_kiểm_tra>

sẽ tạo ra 1 chuỗi chữ và số tương tự như: 2fe2a5fabcc3a33722b4ffe05714bec3 *<file_cần_kiểm_tra>. Nếu chuỗi này trùng với chuỗi được cung cấp chính thức với mã nguồn thì mã nguồn này có thực tính và đáng tin cậy.

6.4 Xả nén mã nguồn
Tùy vào gói mã nguồn được tải về thuộc dạng nén .gz hay .bz2 mà dùng tiện ích thích hợp để xả nén. Như đã tóm tắt trong phần 6.3 ở trên, gói mã nguồn được chứa trong /usr/src (wget được chạy sau khi cd vào /usr/src), cho nên bạn phải ở trong thư mục này trước khi thao tác các bước kế tiếp (không thì các bước kế tiếp phải thêm và đường dẫn đến nơi chứa gói mã nguồn). Đối với kernel 2.6.x series, mã nguồn của Linux kernel có thể được xả, chứa và biên dịch từ bất cứ nơi đâu mà bạn có quyền chứa trên hệ thống. Tuy nhiên, để giữ cho hệ thống sạch và thống nhất, bạn nên giữ mã nguồn ở /usr/src.

- nếu gói mã nguồn có dạng .gz thì dùng:
$ gunzip linux-2.x.xx.tar.gz (x.xx là bất cứ phiên bản nào bạn tải về).
$ tar xf linux-2.x.xx.tar (lệnh này dùng option x để extract (xả) và f để chỉ định hồ sơ nào cần được xả, ở đây hồ sơ cần được xả là linux-2.x.22.tar).

Hai lệnh trên cũng có thể gọp chung lại như sau:
$ tar xfz linux-2.x.xx.tar.gz (lệnh này dùng thêm option z để ngầm xả nén .gz file "on-the-fly" trước khi xả gói tar).

Hoặc có thể tạo cùng kết quả bằng cách khác nữa:
$ gzip -dc linux-2.x.xx.tar.gz | tar xvf - (cụm lệnh này dùng chương trình gzip để xả nén (option -d) ra stdout (option -c) và "tee" nó qua chương trình tar để xả gói tar ra "on-the-fly". Cả cách này và cách ở trên đều tiện dụng cho những ai eo hẹp dung lượng trên đĩa).

- nếu gói mã nguồn có dạng .bz2 thì dùng:
$ bunzip2 linux-2.x.xx.tar.bz2
$ tar xf linux-2.x.xx.tar

Hai lệnh trên cũng có thể gọp chung lại như sau:
$ tar xfj linux-2.x.xx.tar.bz2 (lệnh này dùng thêm option j để ngầm xả nén .bz2 file "on-the-fly" trước khi xả gói tar).

Hoặc có thể tạo cùng kết quả bằng cách khác nữa:
$ bzip2 -dc linux-2.x.xx.tar.bz2 | tar xvf - (cụm lệnh này dùng chương trình bzip2 để xả nén (option -d) ra stdout (option -c) và "tee" nó qua chương trình tar để xả gói tar ra "on-the-fly". Cả cách này và cách ở trên đều tiện dụng cho những ai eo hẹp dung lượng trên đĩa).

Cả ba trường hợp đều cho kết quả là một thư mục có tên là linux-2.x.xx bên trong thư mục /usr/src/

Trong phần này, chúng ta chỉ đề cập đến trường hợp tải trọn bộ mã nguồn của Linux kernel về để biên dịch. Trường hợp đã có mã nguồn cũ hơn của Linux kernel trên máy và chỉ cần tải patch và "vá" thì có quy trình khác. Vấn đề này sẽ đề cập sau.

6.5 Dùng "config" nào thì thích hợp?

Cấu hình biên dịch nhân Linux đơn giản là một "text file" chứa các biến với giá trị Y (Yes), N (No) hoặc M (Module). Các giá trị này được xử dụng trong quá trình biên dịch; chúng dùng để xác định những gì không được biên dịch, những gì được biên dịch và nếu được biên dịch thì sẽ theo dạng nào.

Tùy vào cách sắp xếp của mỗi Linux bản phân phối, cấu hình biên dịch nhân Linux nằm nhiều nơi khác nhau. Hồ sơ cấu hình theo mặc định của "vanilla" kernel nằm ở ./arch/i386/defconfig (nếu dùng dòng phần cứng IA32 nói chung), các hồ sơ cấu hình khác cho những dòng phần cứng khác nằm ở ./arch/$ARCH/defconfig; trong đó $ARCH là dòng phần cứng của máy. Nếu dùng cấu hình mặc định, không chỉnh sửa thì kernel sẽ được tái biên dịch trọn bộ theo giá trị mặc định và chắc hẳn, kernel này sẽ không thích hợp cho bạn (ngay cả nếu nó được biên dịch thành công). Điều này đi ngược lại mục đích cần tái biên dịch Linux kernel ngay từ đầu. Bạn có thể dùng hồ sơ cấu hình này để khởi đầu và chỉnh sửa giá trị cho thích hợp. Đây là một bước rất khó khăn cho những ai chưa từng đi qua giai đoạn này và không có sẵn một cấu hình biên dịch nhân hoàn chỉnh cho máy.

Cấu hình cho kernel hiện hữu trên máy cũng có thể nằm trong thư mục /boot ở dạng config-2.x.xx nếu bạn dùng kernel do RedHat (hoặc dựa RedHat) và một số bản phân phối khác cung cấp. Bạn có thể an toàn dùng cấu hình này và chỉnh sửa, loại bỏ các chi tiết (driver module) không cần dùng. Nếu hệ thống đã được biên dịch kernel trước đây, bạn có thể tìm thấy cấu hình biên dịch nhân Linux có tên là .config, được lưu trong thư mục <KERNEL_SRC> (nơi trước đây mã nguồn của kernel được xả nén và biên dịch).

7. Chỉnh cấu hình biên dịch nhân Linux

7.1 Thành phần của cấu hình biên dịch nhân Linux
Thành phần trong cấu hình biên dịch nhân Linux cho kernel 2.4.x và 2.6.x có một số tương đồng và dị biệt. Tuy nhiên, quy trình chọn Y, N hoặc M cho các modules vẫn như nhau. Bước chọn lựa và chỉnh liệu cấu hình biên dịch nhân Linux là một bước mất nhiều thời gian nhất, nó cũng là một bước gây nhiều trở ngại nhất nếu chỉnh sửa không hợp lý hoặc thiếu sót.

7.1.1 Thành phần cấu hình biên dịch nhân Linux thuộc kernel 2.4.x series

Code Maturity Level Options
Chọn lựa của mục này cho phép dùng các modules / drivers còn ở trạng thái "alpha" (thử nghiệm). Nếu hệ thống làm việc là một máy production, cần tính ổn định cao thì nên tắt bỏ chọn lựa của phần này. Làm như thế sẽ tắt bỏ rất nhiều modules / drivers thuộc dạng "alpha" trong những phần bên dưới. Nếu muốn thử dùng một số modules / drivers ở dạng alpha thì nên cho phép phần này (Y) và cẩn thận khi lựa chọn các modules được biên dịch sau này. Việc chọn lựa các "alpha" drivers ở chế độ mặc định của các kernel trong nhiều bản phân bố Linux là một trong những nguyên nhân chính tạo nên tình trạng bất ổn định trên một số hệ thống Linux. Nếu chọn lựa các driver này một cách cẩn thận, cơ hội va phải tình trạng bất ổn định sẽ giảm thiểu rõ rệt.

Loadable Module Support
Đây là chức năng nòng cốt của Linux kernel (loadable module). Như đã đề cập ở phần tổng quan (phần 1), loadable modules tiện dụng và linh động, cho nên bạn gần như sẽ chọn Y trong trường hợp này. Trong trường hợp bạn cần dùng kernel modules được viết thêm bên ngoài kernel tree chính thức (3rd party modules), bạn phải chọn "enable set version information on all modules symbols" trong mục này. Nếu bạn cần biên dịch trọn bộ các drivers thẳng vào kernel và không dùng modules (vì lý do bảo mật chẳng hạn), bạn có thể chọn N ở đây. Bạn cũng phải chọn "Y" cho trọn bộ các drivers trong cấu hình biên dịch nhân để thích hợp với chọn lựa "N" cho phần Loadable Module Support này.

Processor Type and Features
Phần này có lẽ là phần tối quan trọng trong cấu hình biên dịch nhân Linux. Đây là nơi để chọn đúng CPU đang dùng trên máy. Ngoài ra còn rất nhiều chọn lựa khác nhau cho vấn đền system scheduling, SMP (symetrical multi-processing) nếu máy có nhiều CPU, hỗ trợ số lượng lớn memory có trong máy.... Nếu bạn chon CPU là i386 thì có lẽ sẽ không có sự cố vì i386 là architecture chung nhất (cả Intel và AMD CPU đều chạy với chọn lựa i386). Tuy nhiên, chọn lựa này sẽ không đạt hiệu năng tối đa và thích hợp cho từng loại CPU cụ thể. Nên chọn đúng CPU để bảo đảm hiệu năng của máy và nhất là để tránh trường hợp không thể boot vào Linux sau khi cài kernel mới (vì loại CPU chỉnh định cho kernel không đúng với CPU có trên máy hay nói một cách kỹ thuật, instructions giữa kernel và máy không tương đồng).

General Setup
Mục này cho phép chọn lựa các ứng dụng hỗ trợ cho những thiết bị (cards) trên máy như ISA, PCI, PCMCIA và các chức năng thuộc về vấn đề quản trị năng lượng nâng cấp (Advanced Power Management).

Memory Technology Devices
Phần này cho phép lựa chọn những ứng dụng thiết bị liên hệ đến memory. Nếu bạn dùng các thiết bị như digital camera hoặc các loại compact flash thì bạn nên chỉnh lý phần này cho thích hợp.

Block Devices
Đây là một phần rất quan trọng trong cấu hình biên dịch nhân Linux. Nó bao gồm các chọn lựa cho những thiết bị thông thường và cần thiết như đĩa cứng, đĩa mềm, băng lưu trữ cũng như các thiết bị điều tác (controllers) cho parallel ports và RAID. Hầu như các chọn lựa trong mục này đều cần thiết; đặc biệt là chức năng hỗ trợ initrd cần thiết để tải sẵn các drivers cần thiết ở dạng module trong quá trình boot máy.

Multi-Device support (RAID and LVM)
Phần này chuyên chú đến các chức năng cần thiết cho hệ thống ở cấp độ server. Các chọn lựa ở đây hỗ trợ những thiết bị như RAID và LVM. Nếu máy của bạn hiện đang dùng RAID và LVM thì không thể bỏ qua phần này trong quá trình xác lập cấu hình biên dịch nhân Linux. Chọn lựa trong phần này đòi hỏi phải hiểu rõ nhu cầu dùng những công nghệ thuộc dạng này trên máy. Nếu máy không dùng đến những công nghệ này, bạn có thể an toàn tắt bỏ chúng (dùng N). Nên nhớ, nếu tắt bỏ RAID trong phần này thì phải tắt bỏ chọn lựa RAID trong phần "block devices" ở trên để tránh gặp phải lỗi biên dịch sau này.

ATA/IDE/MFM/RLL support
Phần này bao gồm các chọn lựa và hỗ trợ cho IDE và ATAPI dùng trên các pc-compatible (và trên nhiều architecture khác hiện có trên thị trường). Hầu hết các hệ thống cần các chức năng hỗ trợ trong phần này.

Cryptography Support (CryptoAPI)
Đây là một phần khá mới và lý thú trong mã nguồn của Linux kernel 2.4.x (chỉ được giới thiệu và công bố trong các phiên bản sau này của 2.4.x). Phần này có những lựa chọn thuộc về vấn đề "mã hoá" cho filesystems. Bạn có thể biên dịch các chọn lựa trong mục này và xử dụng (hoặc không) trên máy tùy ý.

Networking Options
Đây là một phần cực kỳ quan trọng trong cấu hình biên dịch nhân Linux nếu bạn muốn máy của mình gắn liền với mạng. Nó bao gồm các chọn lựa cho cả IPv4 và IPv6 networking. Đây cũng là một phần hết sức phức tạp, cho nên, để có thể hiểu rõ và chọn lựa đúng cho hiệu năng tối đa của máy về mặt networking, bạn nên tham khảo rộng rãi các tài liệu về Linux networking, ít nhất là nên đọc các tài liệu kèm theo trong mã nguồn Linux kernel ở <KERNL_SRC>/Documentation/networking/ (thường là /usr/src/linux-2.x.xx/Documentation/networking/).

SCSI Support
Phần chọn lựa cho SCSI ít được những người dùng PC bình thường quan tâm đến vì không mấy ai dùng SCSI cho máy con. Tuy nhiên nếu bạn dùng SCSI card (hoặc SCSI built-in trên motherboard) hoặc dùng CDR/W qua IDE nhưng chạy ở dạng SCSI emulation thì phải điều chỉnh các chọn lựa trong mục này. Điều quan trọng cần nhớ, nếu không dùng tiện dụng initrd, khi chọn lựa SCSI cho một filesystem chạy trên SCSI disk bạn phải biên dịch trực tiếp các chọn lựa cho SCSI vào kernel thay vì dùng dưới dạng module. Nếu không, kernel sẽ treo trong giai đoạn Linux kernel boot vì module hỗ trợ SCSI chưa được load trong giai đoạn này.

Character Devices
Trong mục này có khá nhiều lựa chọn tập trung vào các thiết bị như serial và parellel, mouse, joysticks (để chơi games). Tắt hoặc mở các lựa chọn trong mục này thường ít tạo ảnh hưởng nghiêm trọng.

File Systems
Mục này chứa trọn bộ các chọn lựa liên quan đến file system và các loại file system được hỗ trợ trên Linux (bao gồm các file system thường được hỏi đến như FAT, FAT32, NTFS, ISO cho CD-ROM....). Các file system phụ trợ như NTFS, FAT... có thể được biên dịch như một module cho kernel. Không nên biên dịch các modules cho file system dùng để "mount" trong giai đoạn boot như ext3, jbd mà nên biên dịch thẳng vào kernel (Lý do tương tự như đã đề cập trong phần "SCSI Support" ở trên). Cách này sẽ làm kích thước kernel lớn hơn nhưng sẽ an toàn và đơn giản hơn. Chức năng hỗ trợ initrd có thể dùng để tải các modules cần thiết trong quá trình Linux kernel boot nhưng phải nhớ bật chức năng này lên trong phần block devices. Đây là vấn đề tùy chọn của từng cá nhân.

7.1.2 Thành phần Linux kernel configuration thuộc kernel 2.6.x series

Code Maturity Level Options
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

General Setup
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

Loadable Module Support
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

Processor Type and Features
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

Power Management Options
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

Executable File Formats
Đây là một mục riêng biệt trong cấu hình biên dịch nhân của series 2.6.x. Nếu bạn quan tâm đến "a.out", "elf" và "misc", nên nghiên cứu kỹ phần này qua các tài liệu kèm theo với mã nguồn kernel, đặt biệt cho các tiện dụng của "misc" (<KERNEL_SRC>/Documentation/mono.txt, <KERNEL_SRC>/Documentation/binfmt_misc.txt, <KERNEL_SRC>/Documentation/filesystem/proc.txt)

Device Drivers
Đây là một mục mới trong phần cấu hình biên dịch nhân của series 2.6.x. Thật ra device drivers nằm rải rác khắp nơi trong kernel build configuration của series 2.4.x. Ở series 2.6.x, mọi vấn đề liên quan đến "device drivers" được gom lại trong cùng một nhóm. Các chọn lựa thuộc về các thiết bị như graphic card, sound card, USB, SCSI và vấn đề hiệu chỉnh chúng đều tập trung ở đây.

File Systems
Phần này tương tự như đã đề cập ở trên cho kernel 2.4.x series

Security Options
Phần này dành riêng cho các vấn đề về bảo mật của kernel. Cho đến nay vẫn còn đang phát triển, tuy nhiên, đây là phần đầy hứa hẹn cho một Linux kernel mang tính bảo mật cao.

<còn tiếp>

Biên dịch Linux kernel - phần 1

2007-05-16T15:04:00.000+10:00

Biên dịch Linux kernel - phần 1
Hướng dẫn chi tiết các bước trong quá trình tái biên dịch Linux kernel cho kernel 2.4.x và 2.6.x.
Tổng lược về Linux kernel và những yếu tố cần chuẩn bị.

Compile Linux Kernel

1. Tổng quan về Linux kernel trên phương diện tái biên dịch

1.1 Linux kernel và vấn đề tái biên dịch:
Linux kernel là một "modern kernel", nặng tính modular. Từ kernel phiên bản 2.6.x trở đi, có rất nhiều chức năng và mở rộng được đưa vào kernel. Với tinh thần "compile kernel", một yếu tố chính yếu và quan trọng nhất cần ghi nhận đó là tính phân bộ (modularity) của Linux kernel.

Đối với người dùng bình thường, tính modularity này cho phép chọn lựa cách biên dịch các drivers kernel theo dạng modules hay theo dạng biên dịch trực tiếp vào kernel. Thông thường, kernel build configuration cho phép ba chọn lựa: Y, M và N cho mỗi "driver" trong kernel configuration. Có những "driver" không thể compile như một module vì nó phải được load and link trực tiếp ngay khi kernel khởi động. Cũng có những "driver" cho phép chọn như một module và được load trong khi và sau khi kernel được boot. Điểm chính yếu cần nắm bắt trong giới hạn chủ đề "compile Linux kernel" là hiểu rõ tại sao phải chọn M (cho module), Y (cho compile trực tiếp) và N (không dùng) các drivers này.

- Biên dịch trực tiếp vào kernel có nghĩa là các "drivers" này dù có được dùng hay không vẫn được load lên khi kernel khởi tác và tất nhiên nó sẽ chiếm một phần memory. Lợi điểm chính của chọn lựa này là một khi "drivers" đã được compile vào kernel thì không còn phải quan ngại đến tính trung thực của kernel và các driver nữa. Các hệ thống làm việc đòi hỏi tính bảo mật cao không dùng modules mà compile thẳng vào kernel để tránh trường hợp các modules không tin cậy "bị" cài vào kernel lúc nào đó trong quá trình hoạt động của máy. Lợi điểm kế tiếp của chọn lựa này là tính hiệu xuất (rất nhỏ), khi cần driver thì đã có sẵn và không cần ứng tải nữa.

- Biên dịch như các modules cho kernel có nghĩa là chỉ khi nào cần dùng các "drivers" này mới được ứng tải. Lợi điểm của chọn lựa này nổi bật ở khía cạnh xử dụng memory và tài nguyên trên máy. Với lựa chọn này, bạn có thể tạo nên một kernel cực nhỏ và dễ dàng di chuyển cho nhiều mục đích khác nhau. Lợi điểm kế tiếp là khả năng tái biên dịch chỉ một hoặc một số modules nào đó (cần cập nhật chẳng hạn). Tất nhiên để thực hiện chuyện này thì phải thoả mãn tất cả những đòi hỏi về dependency cho system.

1.2 Tóm tắt các bước biên dịch (dành cho những kẻ thiếu kiên nhẫn ;))
Biên dịch Linux kernel rất đơn giản nếu như đã hiểu rõ các quy trình và các bước thực hiện. Sau đây là các lệnh cần thiết, giả định bạn đã có trọn bộ các công cụ để biên dịch và các công cụ này đúng phiên bản:
1. $ cd /usr/src # chuyển vào thư mục /usr/src, nơi thông thường chứa mã nguồn để biên dịch kernel

2. $ wget http://www.kernel.org/pub/linux/kern...>.tar.bz2 ( là phiên bản kernel cần biên dịch, ví dụ ở đây tải mã nguồn được nén ở dạng bz2)

3. $ gpg --verify .tar.bz2.sign .tar.bz2 (xác thực chữ ký và thực tính của mã nguồn)

4. $ bzip2 -dc .tar.bz2 | tar xvf - (xả nén gói chứa mã nguồn)

5. $ make xconfig (dùng GUI để điều chỉnh các chọn lựa cho kernel build configuration và lưu trữ configuration)

6. $ make dep clean bzImage (tập họp lệnh để tạo dependencies và includes, tiếp theo là dọn dẹp các objects không cần thiết và kernel image ở dạng nén)

7. $ make modules (biên dịch các modules đã được chọn lựa)

8. $ su (chuyển sang chế độ super user cho lệnh tiếp theo)

9. # make modules_install (cài các modules vào /lib/modules/, chỉ có super user mới có thể thực hiện lệnh này)

10. # make install (cài kernel vào máy, bước này bao gồm quy trình cài các hồ sơ cần thiết vào thư mục /boot)

Bước thứ 10 có thể thay thế bằng một loạt thao tác bằng tay (chi tiết ở phần 9.2) nếu như Linux distribution không có sẵn một số công cụ thuộc gói mkinitrd chỉ có trong RedHat distribution và các distribution dựa trên RedHat.

Lưu ý: đối với kernel 2.6.x series, bạn có thể dùng các bước như trên. Tuy nhiên bước "make dep" không cần thiết nữa. Bài viết này bao gồm kernel 2.4.x và 2.6.x series nên có một số chi tiết không cần thiết cho kernel 2.6.x. Tuy vậy, những chi tiết này sẽ không ảnh hưởng đến sự thành công của quy trình biên dịch kernel.

2. Tại sao cần compile lại Linux kernel?
Đối với người dùng đã quen với những hệ điều hành "đóng" thì khái niệm tái biên dịch kernel là một khái niệm hết sức lạ lẫm. Điều này cũng dễ hiểu vì kernel của các hệ điều hành "đóng" hiển nhiên là "đóng" và người dùng bình thường không thể có cơ hội tiếp cận với mã nguồn của kernel cho thao tác quy trình tái biên dịch. Trong khi đó, mã nguồn của Linux kernel hoàn toàn "mở" và đây là phương tiện cũng như động lực tiên quyết cho vấn đề tái biên dịch kernel. Câu hỏi được đặt ra là tại sao lại cần phải tái biên dịch Linux kernel?

Câu trả lời ngắn: không cần nếu như không cần và cần nếu như cần :)

Câu trả lời dài: có vô số lý do khiến cho người dùng cần phải tái biên dịch Linux kernel. Sau đây là một số trường hợp thường gặp nhất:
a. tái biên dịch kernel để chữa lỗi của kernel. Nếu các lỗi này thuộc về lõi của kernel thì phải vá nguồn của kernel và tái biên dịch nó để sửa chữa các lỗi được công bố.

b. tái biên dịch kernel để nâng cao hiệu năng của kernel. Theo mặc định, các Linux distribution thường kèm một phiên bản kernel biên dịch với hầu hết những thành phần có sẵn để có thể đáp ứng rộng rãi cấu hình hardware (có thể hiện diện trên các máy). Đây là điểm lợi tổng quát lúc khởi điểm. Tuy nhiên, sau khi đã cài thành công và nắm chắc máy có những thiết bị gì (sound card, graphic card, network cards, SCSI card..... ) và biết rõ cần những thành phần nào cho cấu hình của máy thì không có lý do gì phải bao gồm trọn bộ các thứ không cần thiết và không dùng. Đối với kernel 2.4.x, mức độ nâng cao hiệu năng không rõ rệt (ngoại trừ dùng phương pháp test load để đo). Tuy nhiên, từ kernel 2.6.x trở đi, tính hiệu năng qua việc tái biên dịch và điều chỉnh "driver" modules cho kernel tạo hiệu xuất rõ rệt, nhất là trong việc điều chỉnh "thời biểu" (scheduling) của các công tác mà system phải đảm nhiệm.

c. tái biên dịch để loại bỏ những "drivers" không được dùng và có thể gây "hiểu lầm" cho kernel, tạo ra trường hợp máy có những triệu chứng hoạt động thiếu ổn định và hay gây lỗi.

d. tái biên dịch kernel để thử nghiệm một chức năng hoặc một module mình vừa tạo ra. Trường hợp này không nhiều như các trường hợp trên nhưng cũng nằm trong các lý do phổ biến.

3. Cấu trúc và quy định phiên bản của Linux kernel
Phiên bản của Linux có quy định rất đơn giản và dễ nhớ. Vấn đề này cần nắm rõ trước khi chọn một phiên bản nào đó của Linux kernel để vá và biên dịch.

Phiên bản của Linux bao gồm ba nhóm số tách ra bởi các dấu chấm. Ví dụ: 2.4.26

Số thứ nhất: 2 là phiên bản
Số thứ nhì: 4 là chỉ định cho tình trạng phiên bản. Nếu số này là số chẵn, nó chỉ định cho phiên bản ổn định (stable), có thể dùng cho môi trường production. Nếu số này là số lẻ, nó chỉ định cho phiên bản không ổn định, nó thường dùng trong môi trường đang phát triển (development). Các kernel thuộc dạng này thường có nhiều bugs và không ổn định. Nếu dùng các phiên bản này để tìm bugs và thông báo cho nhóm phát triển Linux kernel thì đây là điều rất tốt. Không nên dùng phiên bản development cho môi trường production.
Số thứ ba: 26 là chỉ định cho số hiệu phát hành của một phiên bản Linux kernel. Một phiên bản ổn định của một Linux kernel có thể có nhiều số hiệu phát hành khác nhau.

Đây là các quy định chung cho dạng Linux kernel "vanilla" có nghĩa là ứng dụng cho các phiên bản kernel từ http://www.kernel.org, các phiên bản kernel được điều chỉnh bởi mỗi distribution có những điểm dị biệt. Có nhiều Linux distribution xử dụng số hiệu con (extra-version) cho phiên bản kernel họ đã điều chỉnh. Ví dụ RedHat có những cập nhật phụ cho các kernel như: 2.4.20-8 chẳng hạn. Điều cần nắm ở đây là chỉ nên xử dụng phiên bản ổn định (stable) của Linux kernel (số chẵn ở giữa) cho môi trường production và dùng phiên bản thử nghiệm (development) của Linux kernel (số lẻ) cho môi trường thử nghiệm và phát triển.

4. Đòi hỏi tối thiểu trong việc tái biên dịch Linux kernel
Trước khi bắt tay vào việc tái biên dịch Linux kernel, điều cần thiết là phải có đủ chỗ chứa trên disk. Ít nhất là phải đủ chỗ chứa cho mã nguồn (trước và sau khi xả nén), chỗ chứa để cài kernel và các modules mới sau khi biên dịch.

Đòi hỏi quan trọng khác là phải có một bộ công cụ cần thiết và đúng phiên bản, không thể biên dịch được kernel nếu không thoả mãn yêu cầu này. Phiên bản cho bộ công cụ với mỗi series kernel khác nhau. Nên nhớ, nhóm phát triển kernel yêu cầu bạn phải có đúng phiên bản của các công cụ để đảm bảo việc biên dịch kernel thành công.

4.1 Đòi hỏi cho Linux kernel 2.4.x
Đồ nghề Phiên bản tối thiểu Cách xác định phiên bản có trên máy
Gnu C 2.91.66 # gcc --version
Gnu make 3.77 # make --version
binutils 2.9.1.0.25 # ld -v
util-linux 2.10o # fdformat --version
modutils 2.4.2 # insmod -V
e2fsprogs 1.19 # tune2fs
reiserfsprogs 3.x.0b # reiserfsck 2>&1|grep reiserfsprogs
pcmcia-cs 3.1.21 # cardmgr -V
PPP 2.4.0 # pppd --version
isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version

Tham khảo thêm chi tiết các công cụ này và địa chỉ để tải các công cụ cho đúng (ít nhất phải cùng phiên bản đã cung cấp ở trên hoặc mới hơn) trong hồ sơ ./Documentation/changes của mã nguồn kernel bạn đang dự tính biên dịch.

4.2 Đòi hỏi cho Linux kernel 2.6.x
Đồ nghề Phiên bản tối thiểu Cách xác định phiên bản có trên máy
Gnu C 2.95.3 # gcc --version
Gnu make 3.78 # make --version
binutils 2.12 # ld -v
util-linux 2.10o # fdformat --version
module-init-tools 0.9.10 # depmod -V
e2fsprogs 1.29 # tune2fs
jfsutils 1.1.3 # fsck.jfs -V
reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
xfsprogs 2.1.0 # xfs_db -V
pcmcia-cs 3.1.21 # cardmgr -V
quota-tools 3.09 # quota -V
PPP 2.4.0 # pppd --version
isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
nfs-utils 1.0.5 # showmount --version
procps 3.1.13 # ps --version
oprofile 0.5.3 # oprofiled --version

Tham khảo thêm chi tiết các công cụ này và địa chỉ để tải các công cụ cho đúng (ít nhất phải cùng phiên bản đã cung cấp ở trên hoặc mới hơn) trong hồ sơ ./Documentation/changes của mã nguồn kernel bạn đang dự tính biên dịch.

Nếu phiên bản của các công cụ trên máy cũ hơn các phiên bản đưa ra ở trên, bạn cần phải tải phiên bản mới (đã biên dịch) từ website của distribution nào bạn đang dùng. Bạn cũng có thể chọn cách tải mã nguồn của từng công cụ về biên dịch lại. Cách này mất thời gian hơn rất nhiều và chỉ thích hợp cho những ai đã quen thuộc với vấn đề biên dịch mã nguồn trên Linux. Lợi điểm của cách này là bạn tạo cho mình một bộ công cụ rất "sạch" vì đã biên dịch theo ý, thích hợp với môi trường của máy (và vừa đủ).

Đối với IA64 architecture, bạn cần GCC 64bit compliant compiler, nên tham khảo chi tiết ở:
http://gcc.gnu.org/install/specific.html (nếu bạn may mắn có một con IA64 để thử :)

5. Xác định cấu hình (hardware) của máy
Phần lớn người dùng bình thường ít khi quan tâm đến cấu hình của máy ngoại trừ có nhu cầu cụ thể. Ngay cả những ai dùng Linux đã lâu và không cần phải tái biên dịch kernel, cũng ít khi quan tâm đến cấu hình hardware của máy. Dù có biết nhiều hay ít về cấu hình hardware của máy mình dùng, bạn vẫn phải thu thập thông tin chính xác của cấu hình trước khi bắt tay vào việc điều chỉnh kernel build configuration.

Giả định mọi chỉnh lý đã ổn định và làm việc tốt đẹp (do installer tự detect trong khi cài Linux hay do bạn phải điều chỉnh lại), bạn cần tái biên dịch Linux kernel và cần thâu thập thông tin về cấu hình của máy, hai lệnh sau cung cấp các chi tiết hardware có trên máy:
# /sbin/lspci để liệt kê trọn bộ những PCI "card" đang gắn vào máy. Lệnh này liệt kê trọn bộ các "card" đang trực tiếp làm việc trên máy, hardware version và model của chúng.

# cat /proc/cpuinfo để xem chi tiết CPU của máy là loại gì. Nếu Linux distribution bạn dùng không dùng /proc filesystem thì bạn có thể dùng lệnh # dmesg để thu thập thông tin về hardware trên máy của mình. Ngoài ra, lệnh lsmod cũng ít nhiều giúp bạn xác định các modules đang được dùng trên máy và tên của các modules này.

Những thông tin thâu thập được ở đây hết sức quan trọng trong giai đoạn điều chỉnh kernel build configuration. Nó giúp bạn xác định các chọn lựa đúng cho cấu hình máy, tránh đi những trở ngại có thể rất mất thời gian sau này.

6. Các bước chuẩn bị

6.1 Tạo một bootable floppy disk dùng kernel đang chạy
Đây là một bước cần thiết đề phòng sự cố gì đó khiến bạn không thể boot vào Linux system sau khi cài kernel mới. Trường hợp này hiếm khi xảy ra trong quá trình biên dịch kernel và cài kernel mới nếu bạn thực hiện và điều chỉnh đúng. Những sự cố với bootloader (LILO hoặc GRUB) ít thấy xảy ra vì bootloader đã được thiết lập hoàn chỉnh trước khi cập nhật kernel. Phần lớn giai đoạn tái điều chỉnh config của LILO hoặc GRUB không chính xác tạo trở ngại. Vấn đề này sẽ được đề cập sau. Trước mắt chúng ta cần tạo một "bootable floppy disk".

Có rất nhiều cách để tạo một bootable floppy lấy từ kernel hiện đang chạy trên máy. Thay vì trình bày nhiều cách khác nhau cho việc tạo bootable floppy disk, ở đây tôi chỉ đề cập đến phương thức đơn giản nhất. Cách dễ nhất có lẽ là cách dùng mkbootdisk. Đây là một binary được cài mặc định trên các RedHat distribution và hầu hết các distribution dựa RedHat. Nếu binary này không hiện diện trên máy, bạn có thể tải mã nguồn về và biên dịch cho distribution mình đang dùng. Chạy lệnh:
# mkbootdisk --device /dev/fd0 `uname -r`, trong đó
`uname -r` là lệnh ngầm để lấy phiên bản kernel hiện dùng trên máy. Nếu không muốn phiên bản này, bạn có thể gõ vào phiên bản nào đó theo ý (tất nhiên là phiên bản kernel này phải hiện hữu trên system).

/dev/fd0 là "device" chỉ cho đĩa mềm thứ nhất trên máy (tương tự như drive A: trên DOS). Bạn phải chọn đúng "device" thì mới có dữ liệu viết vào đĩa mềm mình muốn tạo.

Quy trình này chỉ mất khoảng vài phút. Sau khi tạo bootable floppy disk ở trên, bạn nên dùng nó để thử boot vào Linux trước khi thực hiện các bước kế tiếp. Nên nhớ phải chỉnh BIOS để cho phép máy boot từ A:

Ở trang:
http://www.yolinux.com/TUTORIALS/Lin...Disk.html
có các hướng dẫn tạo disk cấp cứu rất hay. Bạn nên tham khảo thêm nếu trên máy mình dùng không có sẵn mkbootdisk.

6.2 Tải mã nguồn
Mã nguồn của Linux kernel cả stable lẫn development có rất nhiều nơi trên Internet. Nên vào trang trung tâm của Linux kernel ở http://www.kernel.org và tham khảo danh sách "mirrors" để tìm nơi "gần" chỗ mình cư ngụ nhất để tải về. Nơi "gần" không nhất thiết là "gần" theo phương diện địa lý mà nên chọn "gần" nhất dựa trên "ping time". Chịu khó lấy vài địa chỉ trên mirror và ping những địa chỉ này để chọn lấy nơi có ping time ngắn nhất mà download. Bằng cách sẽ giúp bạn đỡ mất thời gian và tiện cho vấn đề chia xẻ băng thông.

Có nhiều cách tải mã nguồn. Bạn có thể dùng browser để tải qua http hoặc dùng một ftp client nào đó để tải qua ftp. Bạn cũng có thể dùng wget để download. Có lẽ đây là cách tiện nhất và nhanh nhất nếu biết rõ địa chỉ và đường dẫn đến gói mình muốn download. Ví dụ:
$ wget http://www.kernel.org/pub/linux/kern...6.tar.bz2 (trong trường hợp này, gói cụ thể cần tải là linux-2.4.26.tar.bz2).

Mã nguồn ổn định của Linux kernel được nén ở hai dạng khác nhau: dạng có đuôi là .gz (dùng GNUzip để nén) và dạng có đuôi .bz2 (dùng bzip2 để nén). Thông thường cả hai tiện ích nén / xả nén trên đều có sẵn trong các Linux distribution thông dụng. Nếu không có sẵn trên máy thì tìm trong trong CD của distribution (tham khảo thêm tài liệu của distribution mình dùng cho cách cài thêm software trên máy) hoặc tải về từ:
- http://www.gzip.org/ cho GNUzip
- http://sources.redhat.com/bzip2/ cho bzip2

Nhìn lại từ năm 2000...

2007-04-19T12:40:00.000+10:00

Đầu năm 2000, tôi về thăm VN. Đó là lần đầu tiên tôi có dịp tiếp xúc với các anh em trong ngành CNTT ở VN.

Năm đó, khi quay lại Úc, tôi bắt đầu tìm hiểu kỹ hơn về tình hình CNTT tại VN bằng cách đọc tin tức và tham gia một số diễn đàn thảo luận tin học.

Diễn đàn đầu tiên tôi vào đó là diễn đàn... gì đó của VDC (tôi quên bẵng cái tên). Tôi sinh hoạt ở đây đúng một tuần và không ghé lại nữa bởi vì tôi nhiều lần bị sự cố với việc đăng nhập. Mặc dù đã gởi e-mail đến nhóm hỗ trợ, họ không bao giờ trả lời. Hơn nữa, lần đầu tiên sinh hoạt ở một diễn đàn tiếng Việt (và điều hợp rất kém), tôi thấy hết sức lạ lẫm bởi vì tôi không hề nhận được một lần "cám ơn" từ thành viên trên diễn đàn này mặc dù tôi tẩn mẩn trả lời một số bài viết hết sức chi tiết và kỹ lưỡng. Đành vậy, cái duyên với VDC forum thật ngắn ngủi.

Sau đó một thời gian ngắn, tôi tìm ra một diễn đàn tiếng Việt có tên là diendantinhoc.org (xuyên qua search engine). Rút kinh nghiệm lần trước, lần này tôi lượn lờ bên ngoài, quan sát cách sinh hoạt và tổ chức của diễn đàn khá lâu trước khi tôi đăng ký tài khoản chính thức để tham gia. Đây là diễn đàn tôi sinh hoạt lâu nhất. Cho đến nay tôi vẫn còn sinh hoạt ở diễn đàn này và trông lo khoản "cơ sở hạ tầng" của nó. Trong suốt mấy năm sinh hoạt với diendantinhoc.org, sau đổi tên domain chính thức thành vninformatics.com (tôi có may mắn chọn cái domain này và anh em nhất trí với nó), tôi viết và dịch khá nhiều tài liệu.

Khoảng 2003, ngoài vninformatics.com, tôi tham gia sinh hoạt với một diễn đàn khác có tên là vnsecurity.net. Đây là một diễn đàn không lớn như vninformatics.com nhưng anh em ở đây chuyên về bảo mật và bởi thế, diễn đàn này khá đặc biệt. Không may, diễn đàn vnsecurity.net bất thình lình đóng cửa (vì lý do nào đó, cho đến nay tôi cũng chẳng rõ).

Giữa năm 2004, tôi bắt đầu tham gia diễn đàn HVAOnline với tư cách thăm dò. Tôi biết HVAOnline từ những năm 2001, 2002 nhưng không tham gia vì tính lộn xộn của nó vào những năm ấy. Mãi đến đầu tháng mười năm 2004, tôi mới chính thức góp sức vào việc "chống" DDoS mà HVA hứng chịu một thời gian dài. Tôi được biết đến bằng 2 cái nick name: hnd (ở diễn đàn vninformatics.com) và conmale (ở diễn đàn hvaonline.net).

Cho đến nay, tôi vẫn thường xuyên sinh hoạt ở hai diễn đàn: vninformatics.com (diendantinhoc.org) và hvaonline.net.

Tôi dự định sẽ thâu thập lại trọn bộ những bài viết, bài dịch mà tôi đã thực hiện trong hơn 6 năm qua để đưa lên blog này (cho mục đích lưu trữ - vì tôi tin rằng google khó mà chết ;)).

Chuyện gì xảy ra sau đó?

2007-02-12T10:48:00.000+11:00

Tôi nhận khá nhiều e-mail, PM, offline messages.... "hỏi thăm" chuyện gì xảy ra sau đó, sau cái ngày lão sếp sồng sộc bước vào phòng làm việc của bọn tôi và phán rằng: "sao tụi mày không tìm cách giới hạn chỉ cho phép các chi nhánh sử dụng dịch vụ ftp". Chuyện là thế này....

Bọn tôi lân la các IRC channels và hỏi han về cách thức làm sao giới hạn một hoặc nhiều IP truy cập đến một dịch vụ do mình làm chủ. Thời ấy IRC toàn là dân cyber-junky hay là nerd thứ thiệt lai vãng cho nên một câu hỏi được đặt ra là có cả đống câu trả lời, bàn tán, đề nghị... nếu như câu hỏi ấy chứng tỏ mức quan tâm đúng mức và thể hiện tính nghiêm túc của nó (chả bù ngày nay diễn đàn nào cũng helppp meeee... kíu kíu.... và chẳng buồn giải thích rõ vấn đề). Phần lớn các hồi đáp là "ấn định user account được phép login".

Một ngày đẹp trời không lâu sau đó, có một gã trên IRC loan báo Wietse Zweitze Venema (được biết đến nhiều với cái tên Wietse Venema) đã ra mắt một giải pháp gọi là "tcp wrapper" nhưng ít người biết đến và gã tuyên bố rằng với giải pháp này, hệ thống *nix của bạn sẽ vững như... đồng. Paper nguyên thuỷ về tcp wrapper mà Venama đã viết còn lưu ở đây và nhiêu nơi khác trên mạng. Hiện nay trường Đại học Indiana vẫn còn bảo trì "tcp wrapper" ở đây.

Bọn tôi mừng như bắt được vàng và hối hả tìm mã nguồn, tải về và biên dịch để dùng thử. Thời ấy chẳng có chuyện gì là dễ dàng. Tải nguồn về, bọn tôi khám phá ra phải cần C compiler để biên dịch nhưng C compiler chẳng có sẵn và muốn có thì phải trả thêm $ (vì không được cung cấp miễn phí). Chẳng bù ngày nay compiler tràn ngập trên mạng. Bọn tôi phải thuyết phục lão xếp chi $ để mua thêm bộ compiler. Nếu tôi nhớ không sai thì hồi ấy công ty phải mở hầu bao ra và chi mấy ngàn đô Úc -1- cho bộ C compiler trên Solaris. Gần một tháng sau bọn tôi mới nhận được CD từ bên Mẽo gởi sang.

Hăm hở cài bộ compiler lên test server, bọn tôi thử biên dịch... Ôi thôi, lỗi tè le. Nào là thiếu thư viện, rồi lại thư viện không tương thích, khai báo chỗ này sai, khai báo chỗ kia thiếu. Bọn tôi, một lũ admin tay ngang, chẳng biết bao nhiêu về C, chẳng biết link thư viện là cái quái quỷ gì. Thế là lại lò dò vào IRC hỏi. Dân cư trên IRC cực tốt, họ giúp cho đủ thứ, chỉ vẽ đủ điều. Thế nhưng, bọn tôi phải ra tiệm sách kiếm mấy cuốn sách về C để mà "bồi bổ".

Loay hoay cả tháng trời, bọn tôi biên dịch thành công, cài đặt thành công. Chỉ vỏn vẹn có mấy dòng config cho inetd, tạo và thêm giá trị cho hai cái hosts.deny và hosts.allow. Thế là bọn tôi lại... phè cánh nhạn.

Cuối tuần lễ đầu, cả bọn in ra một đống log (trong syslog) để báo cáo với lão xếp "thành quả lớn lao". Lão gật gù và nói "Được lắm. Chả bỏ mấy ngàn bạc để mua cái compiler quỷ quái gì đó". Thế rồi, lão lại nói tiếp: "bọn bây có bảo đảm 100% là không còn bị sự cố nữa không?". Mấy thằng tôi tắc tị, mặt xanh dờn, nhìn nhau và... ú ớ vì chẳng biết nên trả lời lão thế nào. Tôi đánh bạo trả lời lão: "để bọn tôi xem xét lại rồi sẽ báo cáo chi tiết cho ông sau.". Lão ầm ừ rồi kêu bọn tôi tan hàng. Có lẽ do dáng điệu tiu nghỉu của bọn tôi thảm não quá, lão nói với theo: "Bọn bây cần gì cứ cho tao biết. Ráng sao cho yên là được, không thì chẳng những mông của tụi mày bị dập mà mông của tao cũng lãnh đủ" -2-

Bọn tôi về phòng và lại log vào IRC, channel của sự sống sót (theo cách gọi của bọn tôi thời ấy "survival channel").

Chú thích:
-1-: những năm đầu thập niên 90, đồng đô Úc chỉ thua đô Mẽo vài xu, giá trị của hai đồng đô ngang ngửa nhau.

-2-: tôi còn nhớ nguyên văn là "not only your asses get kicked but mine too".

Từ đâu tôi quan tâm đến bảo mật?

2006-12-05T12:01:00.000+11:00

Có lần (đúng ra là nhiều lần) tôi "bị" hỏi rằng: "anh đã đến với bảo mật như thế nào?". Tôi cười xoà và trả lời tôi đã "đến với nó" như thế này:

Đó là năm 1992, khi tôi còn làm việc với một công ty chuyên sản xuất và phát hành CD, sách, tạp chí... Công ty ấy đứng ở vị trí "top three" trong ngành này ở Úc vào những năm đó.

Khi mà thời Internet còn là thứ xa vời và những ai may mắn có được một chiếc modem 9600 bauds để gọi vào một BBS, chúng tôi "bị" bổ nhiệm thiết kế một hệ thống chuyển gởi hồ sơ giữa các chi nhánh bởi vì công ty này có văn phòng khắp nơi từ Tân Tây Lan sang Úc, trải dài sang Thái Lan, Ấn Độ (và một khoảng thời gian có mặt ở Hồng Kông).

Mọi chuyện diễn ra khá suông sẻ sau 5 tuần sắp đặt, điều chỉnh, bay (bằng máy bay) đến các chi nhánh để cài server (Solaris), kết nối, điều chỉnh hệ thống. Telstra lúc ấy là công ty viễn thông duy nhất ở Úc cung cấp ISDN và chúng tôi thật "phê" khi được vọc đường dây 64K lần đầu tiên (128K dual-line cho các văn phòng lớn). Dữ liệu được chuyển tải bằng ftp giữa các văn phòng và được điều tác bằng một chương trình home-grown (tự viết) bằng Perl (hèm... yucky).

Sau sáu tháng hoạt động đều đặn, không chút sự cố, tai nạn bắt đầu xảy ra. Một ngày "đẹp trời", ông sếp hầm hầm bước vào data room của chúng tôi và vứt xuống bàn một tờ thanh toán với số tiền kinh khủng. Tôi còn nhớ mang máng hình như là hai mươi mấy ngàn đô la. Lão sếp "gầm rú" giận dữ: "tại sao trước giờ tháng nào cũng dưới năm ngàn một tháng, tháng này gần ba chục ngàn tiền đường dây? Tụi bây liệu mà điều tra và fix ngay lập tức".

Bọn tôi tiu nghỉu thoát ra khỏi IRC channel (hèm... thời đó quả là hoàng kim, ngồi server room máy điều hoà không khí, dùng dual-channel ISDN để IRC, chừng nào có chuyện thì mới làm việc ;)) và gọi điện cho đám Telstra để bắt đầu điều tra sự thể. Sau vài giờ liên lạc, bọn tôi được biết rằng dung lượng đi xuyên qua đường dây ISDN tăng gấp năm lần bình thường. Hối hả trace ngược lại số lượng job đã queue và transfered, cộng trừ nhân chia... bọn tôi thấy rằng số lượng dữ liệu có gia tăng nhưng không thể nào đến mức 5 lần tháng trước.

Bọn tôi quyết định yêu cầu đám Telstra cung cấp bản tường trình chi tiết số lượng băng thông được sử dụng theo từng tháng. Từ bản tường trình, điều rõ ràng là số lượng băng thông gia tăng theo cấp số, đặc biệt từ nửa tháng trước cho đến tháng cuối cùng. Không dám nghĩ rằng Telstra tính hoá đơn sai vì họ có đầy đủ bằng chứng mức sử dụng, bọn tôi lại quay ngược về đống logs, trace số lượng jobs ra vào và đi đến kết luận: it nhất 70% dung lượng băng thông được dùng cho việc gì đó bí ẩn.

Thời ấy, chẳng đứa nào trong bọn tôi có chút ý niệm gì về bảo mật. Chẳng bao giờ nghĩ đến src_ip, dst_ip, chẳng bao giờ nghĩ rằng dịch vụ ftp đã có ấn định username / password mà có thể suy suyển. Thế nhưng, sau nhiều giờ sục tìm, bọn tôi nhận ra rằng có hàng trăm IP addresses truy cập ftp server của chúng tôi. Các IP này đi từ US và Europe là chính (lúc ấy chưa có ISDN ở Ấn và Thái). Tìm sâu hơn, chúng tôi phát hiện ra một thư mục chứa đủ thứ đồ "hàng xén" do ai đó upload tự lúc nào. Thư mục này có dung lượng mấy chục Mb (thời ấy, mấy chục Mb rất lớn và băng thông được tính theo K). Kiểm tra lại user account và password, mọi thứ đều ổn.... lạ nhỉ?

Bọn tôi hết phương cách bèn gởi sự thể đến SUN nhờ họ hỗ trợ. Sau hơn tuần lễ gọi điện liên tục, thảo luận trực tiếp với CA (Sun based ở California), chúng tôi nhận được một CD có bản vá cho OS và dịch vụ FTP. Tất nhiên là thư mục chứa hàng xén kia bị xoá và hoá đơn lão sếp nhận trở lại bình thường. Đám Telstra đồng ý cắt hoá đơn ấy còn 1/2 vì không phải hoàn toàn lỗi của bọn tôi (khoảng 10 ngàn thời đó, thời giá bây giờ có lẽ khoảng 100 ngàn đô).

Sau này, tôi tự tìm hiểu (vì thắc mắc và vì hỏi đám SUN lý do, họ không thèm giải thích) thì mới biết rằng dịch vụ FTP ở phiên bản ấy có lỗi cho phép by-pass authentication trên cổng 21 và đi thẳng vào data port ở cổng 20. "Ai đó" có thể upload file thẳng qua cổng 20 dễ dàng :). Thông tin về cái thư mục "hàng xén" kia trên FTP server của bọn tôi được phán tán và lan truyền trên IRC, BBS thời đó và thiên hạ tha hồ vào download. Âu đó cũng là duyên số cho tôi nảy ra thói tò mò bảo mật.

Một ngày đẹp trời không lâu sau đó, lão sếp lại xuất hiện và chỉ hỏi một câu gọn lỏn: "bọn bây sao không tìm cách hạn chế chỉ cho các chi nhánh của công ty truy cập cái FTP server?" rồi biến mất. Đó là cơ duyên tiếp theo để tôi tìm hiểu về một cơ chế có khả năng cản lọc (firewall) và tis là firewall đầu tiên tôi đụng đến (từ một đĩa mềm và 1 tập photocopy do một lão bên Mỹ gởi sang vào năm 1994) nhưng đây là chuyện khác.

Một kiểu nhìn về dữ liệu...

2006-11-16T13:14:00.000+11:00

Tôi là a. Lũ bạn tôi, đứa thì tên 1, đứa tên 10, đứa tên 3.5407059681495977512423785953907e+48, lại có đứa tên Nguyễn Văn Tèo, đứa thì mang tên t\u00ed, thậm chí có đứa mang tên là 74 E8 6F.

Cùng nhau, chúng tôi rong ruổi qua những chặng đường mà người tạo ra chúng tôi muốn như thế.

Chúng tôi, một đám dữ liệu vô tri giác, đi và về những khi bị gọi tên, hoà lẫn vào những lối đi, cưỡi lên các nhịp đập của tín hiệu, bị phân tán rã rời, bị ghép lại từ các mảnh, bị nhào trộn, nắn bóp, lọc chắt để rồi được sắp hàng trước đôi mắt của ai đó.

Đôi khi chúng tôi hiền hoà và ích lợi.
Lắm lúc chúng tôi tàn nhẫn và vô ích.

Chúng tôi là nguyên nhân của thành công và thất bại. Chúng tôi chỉ là một đám dữ liệu vô tri vô giác.

Opening.....

2006-11-10T21:11:00.000+11:00

Once upon a time.... there was a place, nested deep deep in the Internet. It called "a place for friends..." and the story started.