Sớm hay muộn thì mỗi người quản trị cũng thấy rằng anh ta muốn một điều là có thể chạy các chương trình ứng dụng bằng nhiều hệ điều hành trên đồng thời một máy và sau đó cố gắng để tìm ra một giải pháp để làm được điều đó.
Có thể bạn thích sử dụng Microsoft Exchange nhưng bạn vẫn muốn có được các công cụ e-mail mã nguồn mở giống như SpamAssassin hay fetchmail. Hoặc có thể bạn đang sử dụng các ứng dụng Unix cho các dịch vụ mạng, nhưng bạn lại thực sự muốn chạy chúng dưới Windows để bạn có thể tích hợp chúng thành toàn bộ mô hình bảo mật mạng của bạn. Trong bất kỳ trường hợp nào bạn cũng mong muốn có thể chạy các chương trình tốt từ các hệ điều hành.
Trong trường hợp của tôi, tôi đã thực hiện giải pháp này khi đang nâng cấp một ứng dụng cũ và tôi đã mắc một lỗi trong việc mua một bo mạch chủ mới của Intel mà vẫn không thích hợp với sự hỗ trợ của driver Linux. Nếu tôi sử dụng hệ thống này thì nó có thể chạy được Windows, nhưng hầu hết các phần mềm của tôi trên hệ thống này chỉ được thiết kế cho Unix.
Giải pháp thông thường với tình trạng này là bắt buộc bản thân bạn phải chọn một platform bằng cả các danh sách chi tiết mang nặng tinh lợi và hại cho mỗi hệ điều hành và cả việc sử dụng các kỹ thuật tiến bộ đã được xác nhận và sau đó phát triển với các công cụ giúp ích có sẵn. Nhưng lý do bạn gặp tình trạng này là bởi vì bạn muốn sử dụng các ứng dụng từ các platform để phát triển hầu hết các ứng dụng luân phiên nghĩa là sử dụng cái nào tốt hơn, là tối ưu.
Một cái nữa ở đây có thể làm được đó là có thể chạy nhiều hệ thống song song hay sử dụng kỹ thuật ảo để chạy nhiều platform trên hệ thống đơn. Có một thuận lợi khi sử dụng phương pháp này là sẽ đem lại giá thành thấp đỡ tốn chi phí cho cả hai loại hệ điều hành. Mặc dù vậy cũng có những vấn đề phát sinh do người dùng sử dụng các phương pháp khác nhau trong các lĩnh vực khác nhau.
Nhưng có một lựa chọn khác mà không phải bất kỳ ai cũng biết đó là để chạy các ứng dụng Unix của bạn dưới Windows bằng việc sử dụng Posix, dịch vụ của Microsoft cho Unix. Theo mô hình này, hệ điều hành hoạt động thực là Windows trong khi hệ thống cung cấp Posix-compliant cho hệ điều hành. Các ứng dụng Unix cho rằng chúng đang sử dụng Unix thông thường, nhưng thực ra chúng đang sử dụng tài nguyên Windows.
Hình vẽ này sẽ giải thích rõ ràng hơn. Nó sẽ rất dài nhưng chỉ cần một đoạn ngắn trên màn hình cũng giúp bạn hiểu nó nghĩa như thế nào.
Có thể bạn thích sử dụng Microsoft Exchange nhưng bạn vẫn muốn có được các công cụ e-mail mã nguồn mở giống như SpamAssassin hay fetchmail. Hoặc có thể bạn đang sử dụng các ứng dụng Unix cho các dịch vụ mạng, nhưng bạn lại thực sự muốn chạy chúng dưới Windows để bạn có thể tích hợp chúng thành toàn bộ mô hình bảo mật mạng của bạn. Trong bất kỳ trường hợp nào bạn cũng mong muốn có thể chạy các chương trình tốt từ các hệ điều hành. Trong trường hợp của tôi, tôi đã thực hiện giải pháp này khi đang nâng cấp một ứng dụng cũ và tôi đã mắc một lỗi trong việc mua một bo mạch chủ mới của Intel mà vẫn không thích hợp với sự hỗ trợ của driver Linux. Nếu tôi sử dụng hệ thống này thì nó có thể chạy được Windows, nhưng hầu hết các phần mềm của tôi trên hệ thống này chỉ được thiết kế cho Unix.
Giải pháp thông thường với tình trạng này là bắt buộc bản thân bạn phải chọn một platform bằng cả các danh sách chi tiết mang nặng tinh lợi và hại cho mỗi hệ điều hành và cả việc sử dụng các kỹ thuật tiến bộ đã được xác nhận và sau đó phát triển với các công cụ giúp ích có sẵn. Nhưng lý do bạn gặp tình trạng này là bởi vì bạn muốn sử dụng các ứng dụng từ các platform để phát triển hầu hết các ứng dụng luân phiên nghĩa là sử dụng cái nào tốt hơn, là tối ưu.
Một cái nữa ở đây có thể làm được đó là có thể chạy nhiều hệ thống song song hay sử dụng kỹ thuật ảo để chạy nhiều platform trên hệ thống đơn. Có một thuận lợi khi sử dụng phương pháp này là sẽ đem lại giá thành thấp đỡ tốn chi phí cho cả hai loại hệ điều hành. Mặc dù vậy cũng có những vấn đề phát sinh do người dùng sử dụng các phương pháp khác nhau trong các lĩnh vực khác nhau.
Nhưng có một lựa chọn khác mà không phải bất kỳ ai cũng biết đó là để chạy các ứng dụng Unix của bạn dưới Windows bằng việc sử dụng Posix, dịch vụ của Microsoft cho Unix. Theo mô hình này, hệ điều hành hoạt động thực là Windows trong khi hệ thống cung cấp Posix-compliant cho hệ điều hành. Các ứng dụng Unix cho rằng chúng đang sử dụng Unix thông thường, nhưng thực ra chúng đang sử dụng tài nguyên Windows.
Hình vẽ này sẽ giải thích rõ ràng hơn. Nó sẽ rất dài nhưng chỉ cần một đoạn ngắn trên màn hình cũng giúp bạn hiểu nó nghĩa như thế nào.
Trong ví dụ này, một người dùng Windows đã vào được Windows XP thông qua cấu trúc bash cục bộ bằng việc sử dụng Posix trong SFU. Môi trường nhìn trông khá giống với hệ thống Unix nhưng thực tế là Windows XP.
Posix cho Windows đã có trong một thời gian ngắn. Kỹ thuật này được gọi là Interix và được phát triển bởi công ty Softway Solutions đã sử dụng cùng với Windows NT. Microsoft có được công ty này vào mùa thu năm 1999 và sau đó kết hợp Interix với vài NFS khác và kỹ thuật NIS vào gói bán lẻ được gọi là các dịch vụ cho Unix 2.0 (cũng được biết đến như SFU). Bây giờ nó đã phát triển thành SFU v3.0 và SFU v3.5có thể download miễn phí (bạn có thể download tại đây).
Microsoft đang chuyển tiếp lại sản phẩm này bằng việc tích hợp nó vào Windows. Với thành phần Posix được đặt tên lại là Subsystem cho Unix Applications (SUA). Sự chuyển tiếp này bắt đầu với Windows Server R2 nhưng nó cũng là chiến lược đang hướng đến cho Vista. Việc ghi nhãn hiệu mới cũng biểu thị rằng SUA là bản viết lại của Posix – bao gồm sự hỗ trợ 64-bit platform, các giao diện Open Database Connectivity (ODBC), và sự tích hợp hơn với Microsoft Visual Studio. Nhưng với các ứng dụng user-space thì nó vẫn là Interix.
Về cơ bản, Posix ánh xạ các tài nguyên Windows vào môi trường Unix bằng việc cung cấp một sự lựa chọn “cá nhân” trong Windows thông qua một thiết lập các APIs và các tuyên bố giống Unix. Ví dụ, các account người dùng không được lưu trong file /etc/passwd truyền thống mà thay vì đó được truy cập thông qua các thư viện gọi giống như getpwnam và getpwuid. Sau đó Posix ánh xạ đến hệ thống xác nhận Windows thông qua SAM database API đã có.
Mô hình này cho phép sự xác nhận Windows lưu công việc liền mạch, không quan tâm đến lưu bản thân nó là một dữ liệu nhóm và người dùng cục bộ, một NT domain đã có, hay một Active Directory domain. Mặt xấu của vấn đề này là dữ liệu tài khoản người dùng bị giới hạn để có thể lưu những gì trong SAM database. Thành phần NIC server của SFU cung cấp cho Posix là có thể mở rộng cho Active Directory, nhưng những thuộc tính này lại không được sử dụng bởi vì Posix chỉ có thể làm việc được với SAM database API.
Tương tự như vậy, hệ thống file Posix khá đơn giản cho các file hệ thống của Windows, nó có thể chỉ sử dụng những gì mà Windows có thể cung cấp. Đường dẫn của các hệ thống file Unix được ánh xạ đến C:\SFU một cách mặc định mặc dù các thành phần khác của hệ thống file Windows có thể được truy cập thông qua biệt hiệu thiết bị. (ví dụ, đường dẫn của ổ C có thể được truy cập thông qua /dev/fs/C ).
Khi không có các định vị được gắn để thi hành thì chỉ có cách truy cập vào các hệ thống file từ xa bằng Posix là thiết lập một kết nối trong Windows. Ví dụ, nếu bạn cần sử dụng một chia sẻ SMB từ xa cho một thư mục gốc của người dùng thì bạn cần bảo đảm rằng tài nguyên phải được ánh xạ đến kí tự ổ đĩa bởi Windows trong suốt quá trình login cả bằng các thiết lập profile của người dùng và cả bằng việc sử dụng một kịch bản login. (Điều này bạn có thể xem trên hình đã cho ở trên. Nó thể hiện thư mục gốc của người dùng ánh xạ đến Z: hoặc /dev/fs/Z trong Posix). Đây cũng có thể là các yếu điểm khác của sự tích hợp trong một vài trường hợp bởi vì thuộc tính thư mục gốc của người dùng cũng được sử dụng cho thư mục gốc Posix của người dùng. Bạn mắc kẹt với UNC và các đường dẫn kĩ tự ổ đĩa cho thư mục gốc SFU trong khi các hệ thống từ xa có thể sử dụng các điểm và các đường dẫn NFS.
Posix cho Windows đã có trong một thời gian ngắn. Kỹ thuật này được gọi là Interix và được phát triển bởi công ty Softway Solutions đã sử dụng cùng với Windows NT. Microsoft có được công ty này vào mùa thu năm 1999 và sau đó kết hợp Interix với vài NFS khác và kỹ thuật NIS vào gói bán lẻ được gọi là các dịch vụ cho Unix 2.0 (cũng được biết đến như SFU). Bây giờ nó đã phát triển thành SFU v3.0 và SFU v3.5có thể download miễn phí (bạn có thể download tại đây).
Microsoft đang chuyển tiếp lại sản phẩm này bằng việc tích hợp nó vào Windows. Với thành phần Posix được đặt tên lại là Subsystem cho Unix Applications (SUA). Sự chuyển tiếp này bắt đầu với Windows Server R2 nhưng nó cũng là chiến lược đang hướng đến cho Vista. Việc ghi nhãn hiệu mới cũng biểu thị rằng SUA là bản viết lại của Posix – bao gồm sự hỗ trợ 64-bit platform, các giao diện Open Database Connectivity (ODBC), và sự tích hợp hơn với Microsoft Visual Studio. Nhưng với các ứng dụng user-space thì nó vẫn là Interix.
Về cơ bản, Posix ánh xạ các tài nguyên Windows vào môi trường Unix bằng việc cung cấp một sự lựa chọn “cá nhân” trong Windows thông qua một thiết lập các APIs và các tuyên bố giống Unix. Ví dụ, các account người dùng không được lưu trong file /etc/passwd truyền thống mà thay vì đó được truy cập thông qua các thư viện gọi giống như getpwnam và getpwuid. Sau đó Posix ánh xạ đến hệ thống xác nhận Windows thông qua SAM database API đã có.
Mô hình này cho phép sự xác nhận Windows lưu công việc liền mạch, không quan tâm đến lưu bản thân nó là một dữ liệu nhóm và người dùng cục bộ, một NT domain đã có, hay một Active Directory domain. Mặt xấu của vấn đề này là dữ liệu tài khoản người dùng bị giới hạn để có thể lưu những gì trong SAM database. Thành phần NIC server của SFU cung cấp cho Posix là có thể mở rộng cho Active Directory, nhưng những thuộc tính này lại không được sử dụng bởi vì Posix chỉ có thể làm việc được với SAM database API.
Tương tự như vậy, hệ thống file Posix khá đơn giản cho các file hệ thống của Windows, nó có thể chỉ sử dụng những gì mà Windows có thể cung cấp. Đường dẫn của các hệ thống file Unix được ánh xạ đến C:\SFU một cách mặc định mặc dù các thành phần khác của hệ thống file Windows có thể được truy cập thông qua biệt hiệu thiết bị. (ví dụ, đường dẫn của ổ C có thể được truy cập thông qua /dev/fs/C ).
Khi không có các định vị được gắn để thi hành thì chỉ có cách truy cập vào các hệ thống file từ xa bằng Posix là thiết lập một kết nối trong Windows. Ví dụ, nếu bạn cần sử dụng một chia sẻ SMB từ xa cho một thư mục gốc của người dùng thì bạn cần bảo đảm rằng tài nguyên phải được ánh xạ đến kí tự ổ đĩa bởi Windows trong suốt quá trình login cả bằng các thiết lập profile của người dùng và cả bằng việc sử dụng một kịch bản login. (Điều này bạn có thể xem trên hình đã cho ở trên. Nó thể hiện thư mục gốc của người dùng ánh xạ đến Z: hoặc /dev/fs/Z trong Posix). Đây cũng có thể là các yếu điểm khác của sự tích hợp trong một vài trường hợp bởi vì thuộc tính thư mục gốc của người dùng cũng được sử dụng cho thư mục gốc Posix của người dùng. Bạn mắc kẹt với UNC và các đường dẫn kĩ tự ổ đĩa cho thư mục gốc SFU trong khi các hệ thống từ xa có thể sử dụng các điểm và các đường dẫn NFS.
Windows và Posix cũng chia sẻ một môi trường lệnh chung, vì vậy bạn có thể gọi Windows từ bên trong Unix shell đơn giản bằng việc gọi thi hành giống như bạn sẽ từ bất kỳ một dấu nhắc lệnh nào. Đổi lại cũng như vậy như là việc sử dụng “1s” để gọi thư mục kiểu Unix bằng cách liệt kê từ bên trong trình lệnh CMD. Nhưng nếu bạn cần toàn bộ Posix (bao gồm việc ánh xạ các file và tương tự như vậy) thì bạn cần phải sử dụng lệnh POSIX.EXE như load đầu vào cho lệnh kiểu Unix để tạo một môi trường đầy đủ.
Một vùng không kết nối ở đây là trong các dịch vụ nền: Posix bao gồm các kịch bản khởi động bản thân nó /etc/init.d và lịch trình cron hoàn toàn độc lập với dịch vụ Windows và lịch trình nhiệm vụ. Sự thử nghiệm thể hiện rằng là hoàn toàn có thể khởi chạy một vài dịch vụ Unix như các dịch vụ Windows giả mạo bằng việc sử dụng tiện tích "instsrv" từ Windows Resource Kit và "psxrun" (POSIX.EXE với tháo bỏ các chức năng I/O kết cuối) mặc dù đây là cách hack thô thiển nhất. Sẽ rất tốt nếu Microsoft có thể tìm được một wApart từ các thành phần cơ bản. SFU cũng bao gồm các điểm của các tiện ích Unix cũ cũng như các công cụ mới cần thiết cho biên dịch những lệnh mới bằng các công cụ GNU giống như gee và gmake. Màn hình dưới đây thể hiện nội dung của thư mục /bin trong cài đặt mặc định và một vài update.
Một vùng không kết nối ở đây là trong các dịch vụ nền: Posix bao gồm các kịch bản khởi động bản thân nó /etc/init.d và lịch trình cron hoàn toàn độc lập với dịch vụ Windows và lịch trình nhiệm vụ. Sự thử nghiệm thể hiện rằng là hoàn toàn có thể khởi chạy một vài dịch vụ Unix như các dịch vụ Windows giả mạo bằng việc sử dụng tiện tích "instsrv" từ Windows Resource Kit và "psxrun" (POSIX.EXE với tháo bỏ các chức năng I/O kết cuối) mặc dù đây là cách hack thô thiển nhất. Sẽ rất tốt nếu Microsoft có thể tìm được một wApart từ các thành phần cơ bản. SFU cũng bao gồm các điểm của các tiện ích Unix cũ cũng như các công cụ mới cần thiết cho biên dịch những lệnh mới bằng các công cụ GNU giống như gee và gmake. Màn hình dưới đây thể hiện nội dung của thư mục /bin trong cài đặt mặc định và một vài update.
Phụ thuộc vào bạn sử dụng SFU hay SUA mà các công cụ sẽ thực hiện gói cài đặt trực tiếp (SFU) hay sẽ dowload từ kho của Microsoft như một phần của quá trình cài đặt.
Interop Systems, một công ty được thành lập bởi các nhân viên gốc của Softway Systems cũng duy trì các port của một vài ứng dụng mã nguồn mở. Một vài gói có thể update đơn giản các tiện ích của SFU và SUA.c Nhưng Interop Systems lại duy trì các port khác với các ứng dụng chính giống như OpenSSH và Apache… Interop Systems tính một lần lệ phí là 20$ cho việc truycập đến các kho lưu trữ của nó.
Bạn cũng có thể thử tại các ứng dụng port bằng việc sử dụng các công cụ phát triển (hay các phiên bản update từ Interop Systems). Theo kinh nghiệm của chúng tôi, điều này có thể làm cho một vài thứ trở lên dễ dàng trong khi các ứng dụng khác là rất khó khắn với nó. Nói chung, nếu tarball nguồn sử dụng kịch bản GNU configure hỗ trợ Interix như một platform và ứng dụng không muốn làm việc trực tiếp với các tài nguyên Unix rõ ràng như /etc/passwd thì bạn có một cơ hội tốt để biên dịch thành công ứng dụng mặc dù nó vẫn không chạy. Nếu ứng dụng được viết đến các platform đích rõ ràng và nó không hỗ trợ cho Interix như một target thì bạn có thể không có được nó trừ khi bạn tốn nhiều ông sức để hack code.
Như ví dụ mẫu ở trên, chúng tôi có thể có được phiên bản mới nhất của Berkeley DB để biên dịch và chạy không có vấn đề gì. Chúng tôi cũng có thể có được SpamAssassin và các modul hỗ trợ khác để biên dịch và chạy (bao gồm Net::LDAP, mặc dù chúng tôi phải nâng cấp Perl từ Interop Systems). Vài modul của Perl khác sẽ không dịch hay sẽ không qua giai đoạn "make test". Khi chúng tôi không có được các thư viện CMU SASL để biên dịch, trong khi đó UW IMAPD và Cyrus IMAP lại được viết cho các platform cụ thể mà không hỗ trợ cho Interix. Vì vậy chúng tôi không thể biên dịch được với chúng.
Ở đây chúng tôi có hai ứng dụng Unix quan trọng mà chúng tôi thực sự cần cho hệ thống này là OpenSSH và Squid, và chúng tôi đã dễ dàng sử dụng các dịch vụ Windows cho các thứ ứng dụng khác. Trong vài trường hợp, giống như quản lý máy in chúng tôi đã sai lệch đôi chút với các ứng dụng Windows. Khi OpenSSH và Squid là có sẵn từ Interop Systems thì nó thực sự là dễ dàng. Ngắn gọn hơn là chúng tôi có thể chạy các ứng dụng mã nguồn mở tốt dưới Windows như chúng vẫn từng chạy trên Unix, và đây là một lợi ích từ việc tích hợp chặt chẽ với môi trường Windows.
Interop Systems, một công ty được thành lập bởi các nhân viên gốc của Softway Systems cũng duy trì các port của một vài ứng dụng mã nguồn mở. Một vài gói có thể update đơn giản các tiện ích của SFU và SUA.c Nhưng Interop Systems lại duy trì các port khác với các ứng dụng chính giống như OpenSSH và Apache… Interop Systems tính một lần lệ phí là 20$ cho việc truycập đến các kho lưu trữ của nó.
Bạn cũng có thể thử tại các ứng dụng port bằng việc sử dụng các công cụ phát triển (hay các phiên bản update từ Interop Systems). Theo kinh nghiệm của chúng tôi, điều này có thể làm cho một vài thứ trở lên dễ dàng trong khi các ứng dụng khác là rất khó khắn với nó. Nói chung, nếu tarball nguồn sử dụng kịch bản GNU configure hỗ trợ Interix như một platform và ứng dụng không muốn làm việc trực tiếp với các tài nguyên Unix rõ ràng như /etc/passwd thì bạn có một cơ hội tốt để biên dịch thành công ứng dụng mặc dù nó vẫn không chạy. Nếu ứng dụng được viết đến các platform đích rõ ràng và nó không hỗ trợ cho Interix như một target thì bạn có thể không có được nó trừ khi bạn tốn nhiều ông sức để hack code.
Như ví dụ mẫu ở trên, chúng tôi có thể có được phiên bản mới nhất của Berkeley DB để biên dịch và chạy không có vấn đề gì. Chúng tôi cũng có thể có được SpamAssassin và các modul hỗ trợ khác để biên dịch và chạy (bao gồm Net::LDAP, mặc dù chúng tôi phải nâng cấp Perl từ Interop Systems). Vài modul của Perl khác sẽ không dịch hay sẽ không qua giai đoạn "make test". Khi chúng tôi không có được các thư viện CMU SASL để biên dịch, trong khi đó UW IMAPD và Cyrus IMAP lại được viết cho các platform cụ thể mà không hỗ trợ cho Interix. Vì vậy chúng tôi không thể biên dịch được với chúng.
Ở đây chúng tôi có hai ứng dụng Unix quan trọng mà chúng tôi thực sự cần cho hệ thống này là OpenSSH và Squid, và chúng tôi đã dễ dàng sử dụng các dịch vụ Windows cho các thứ ứng dụng khác. Trong vài trường hợp, giống như quản lý máy in chúng tôi đã sai lệch đôi chút với các ứng dụng Windows. Khi OpenSSH và Squid là có sẵn từ Interop Systems thì nó thực sự là dễ dàng. Ngắn gọn hơn là chúng tôi có thể chạy các ứng dụng mã nguồn mở tốt dưới Windows như chúng vẫn từng chạy trên Unix, và đây là một lợi ích từ việc tích hợp chặt chẽ với môi trường Windows.
0 nhận xét:
Đăng nhận xét