Messages posted by: giobuon

Replicate với Backup là hai việc khác nhau, phục vụ mục đích khác nhau. Mọi người thường tự tin vào các phương án replicate, nhưng nếu có lỗi logic xảy ra thì sao. Trong trường hợp SVN thì ít có những lỗi logic nghiêm trọng nhưng trong các loại khác thì rất dễ gặp. Và nếu như không có backup thì vô phương cứu chữa.

Tớ thấy hai câu hỏi này đều không rõ ràng như nhau. Hay thuật ngữ chuyên ngành tiếng Việt mình rắm rối quá.
BTW câu 1 có vẻ đúng với những gì tớ được học trong một lần học thật và một lần học lại về Kerberos :">

Cách đấy cũng không phải là hay. Sao bạn không bỏ quyền được gửi từ localhost và cấp cho mỗi người một số account mail nhất định?

Hi,
Mình không có ý định so sánh mức độ an toàn của các loại xác thực trên, mình chỉ muốn nói rằng khái quát hoá thì không có gì khác nhau giữa việc bạn lựa chọn cái gì để trust.

Ps: các điểm yếu mà bạn nêu ra đều tránh được (hơi mất công nhưng cũng tương tự việc bạn nhớ một passphrase rất dài smilie

)

-giobuon

Hi lequi,
Mình xin nói luôn là mình chưa sử dụng nginx trong môi trường production với load cao như của bạn, tuy nhiên mình có một số ý kiến như sau:
1, Các thông tin bạn đưa ra là thiếu: mình không thấy cấu hình ổ cứng (loại, tốc độ), cũng không thấy bạn nói rõ về việc loại file bạn phục vụ như thế nào: lớn hay nhỏ, số lượng ra sao? Không rõ là bạn có đặt db trên cùng server này không?
2, Nếu bạn xác định đầy đủ thông tin nói trên (hoặc càng chi tiết hơn) bạn có thể lên maillist của nginx hỏi. Nếu câu hỏi bạn rõ ràng và đầy đủ bạn có thể được nhiều người quan tâm và trả lời. Chắc chắn là những người dùng như mình và bạn không thể nào hiểu rõ nginx bằng mấy bác dev như Igor rồi.
3, Tune hệ thống: nếu may mắn bạn sẽ nhận được vài lời khuyên hợp lý, chỉnh cái này lên 1 tí, chỉnh cái kia xuống 1 tẹo. Nhưng nên nhớ:
-Chuẩn bị benchmark: bạn cần 1 thứ, "chuẩn" đối với bạn để đo đạc hiệu năng của hệ thống. Chuẩn ở đây nghĩa là nó phải tái hiện được gần như chính xác hoàn cảnh thực tế của bạn.
-Thử từng thứ 1: mỗi lần chỉnh chỉ chỉnh 1 directive. Sau khi điều chỉnh, benchmark, ghi nhận kết quả và thử tiếp theo. Hơi mất thời gian nhưng kết quả sẽ khá chính xác.
4, Tìm kiếm bottle-neck: Khi bạn đã có được một cấu hình tối ưu cho phần mềm mà bạn vẫn thấy hệ thống chỉ đạt tới một mốc nào đó thì bạn nên tìm kiếm để phát hiện điểm gì gây
ra hiệu năng tồi cho hệ thống. Có một nguyên lý gọi là thùng gỗ, không nhớ là mình đã đọc ở đâu nói rằng: Hiệu năng của máy giống như một chiếc thùng gỗ ghép bằng các tấm ván nằm dọc, đựng được mức nước tối đa bằng với độ cao của chiếc ván thấp nhất.
Sử dụng các công cụ monitor hệ thống như sar, htop, vmstat... Bạn có thể phát hiện ra là có quá nhiều cpu time dành cho iowait -> ổ cứng của bạn quá tải -> có cách nào giảm nó xuống không -> giảm đọc ghi, tắt log, tạo ramdisk... Nếu sau quá trình này mà vẫn không có cách nào giải quyết thì ít nhất bạn cũng biết được rằng hệ thống đang bắt bạn xì tiền ra để nâng cấp ổ cứng smilie

Ngồi gõ nhảm một hồi vậy thôi, hi vọng là không làm phiền mọi người vì đã không trả lời trực tiếp được câu hỏi.

-giobuon

antiadmin wrote:

Vấn đề em gặp phải ở đây là bất kỳ Client nào tạo request kết nối đến SSH server đều được Server đẩy cho public key của mình. Như vậy Client nào cũng có thể kết nối được đến Server miễn là chỉ cần user/password.

Vậy làm cách nào để Server kiểm tra Client đó có "trust" thật ko?. Để có user/pass cũng không kết nối được.

Chào bạn,
Theo mình để làm rõ vấn đề này đầu tiên chúng ta nên xác định chúng ta cần gì ở đây. Chúng ta cần làm sao để server xác định được người dùng đăng nhập đến là người dùng hợp lệ có quyền truy nhập vào hệ thống (hay theo bạn nói là "trust thật"). Server có thể đưa ra nhiều cách để xác định: user/password, key-based... Tại sao user và pass không thể dùng để trust được mà cặp pub/pri key lại có thể trust được? Nói đơn giản thì thế này: server trust client chính bằng cặp user/pass, client có thể đưa ra cặp user/pass chứng tỏ client đó trust được (chúng ta - server quy định điều đó cơ mà). Client có user/pass thì trên server cũng phải lưu giữ cặp giá trị này (hoặc tương đương) để từ đó xác định người dùng có quyền ko, tương tự với cặp pub/pri key, như bạn nói server cũng phải lưu public key của client phải ko nào. Nếu bạn nghĩ: "Ồ, user và pass nguy hiểm lắm, nhỡ lộ thì sao, làm sao mà trust được?", vậy private key thì sao, cũng dễ dàng bị chẩm mất lắm chứ smilie

. Về mặt logic, không có sự khác nhau nào giữa 2 thứ mà bạn kể trên trong việc trust cả.

Mình nghĩ topic này khá hay, tuy nhiên theo mình nên chuyển 1 tuần thành 1 tháng hoặc hơn. Có quá nhiều thứ để nói đến dù chỉ với 1 dịch vụ.

-giobuon

Đâu cần phải vậy. Bạn có thể đặt sub interface và sử dụng IP Private (giữa Real Server và LVS Director). Bạn vận chỉ cần 1 IP public và 1 card mạng trên tất cả các máy.
Theo mình bạn nên setup trên hệ thống máy ảo như VMWare chẳng hạn. Sẽ chủ động hơn trong việc thay đổi cấu hình, test...

Cái text copy qua nó xô lệch lung tung cả xem tạm ảnh này nhé

Có lẽ bạn đang vướng mắc một số điểm sau:
-Bạn đang setup với mô hình one network LVS/NAT. Nếu bạn setup với mô hình này bạn cần phải config thêm một số thứ trên real server (bỏ route tới client, tắt icmp wwwect - google để biết thêm chi tiết). Nếu bạn thực sự chưa hiểu rõ cách thức hoạt động của mô hình này mình khuyên bạn nên cài với mô hình 2 network riêng biệt:

________
| |
| client |
|________|
CIP=192.168.1.254
|
|
|
__________
| | VIP=192.168.1.110 (eth0)
| director |
|__________| DIP=10.1.1.9 (eth1)
|
|
----------------------------------------
| | |
| | |
RIP1=10.1.1.2 RIP2=10.1.1.3 RIP3=10.1.1.4 (all eth0)
_____________ _____________ _____________
| | | | | |
| realserver | | realserver | | realserver |
|_____________| |_____________| |_____________|

Mô hình này tương đối rõ ràng hơn. Gói tin đi từ client đến LVS director sau đó được thay đổi địa chỉ đích và đi đến real server. Real trả lại gói tin, gói tin này đi qua LVS director (do trên real đặt default gateway là DIP của LVS director ). Gói tin được LVS director thay đổi địa chỉ nguồn thành VIP rồi gửi lại cho client. Client hoàn toàn không biết gì và nó chỉ giao tiếp với 1 IP duy nhất là VIP.
Nếu đứng trên director và tcpdump cả 2 card mạng bạn sẽ thấy quá trình gói tin giao tiếp trong hệ thống.
Bạn đọc thêm về TCP và NAT thì sẽ dễ hơn trong việc hiểu vấn đề và cách debug.

-giobuon

Bạn thấy gói tin đến RealServer thì gói tin đó là gói gì (HTTP request?). Địa chỉ nguồn và đích của gói tin đó là bao nhiêu?
Bạn có thấy gói tin đi Real Server ra ko? Địa chỉ nguồn đích của gói tin đó như thế nào?

http://www.redhat.com/advice/tips/meminfo.html

K4i wrote:

Code:

[user@xxxxsrv ~]$ uname -ra
Linux db09srv.ho.fpt.vn 2.6.9-67.0.22.ELlargesmp #1 SMP Fri Jul 11 10:59:18 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Hình như bạn K4i này là người quen smilie

Theo mình giờ phải thu nhỏ phạm vi nghi ngờ vào. Xem những ứng dụng chuyên biệt nào đang chạy (ví dụ như server này chỉ chạy db oracle thôi chẳng hạn), tìm xem có bug nào của ứng dụng này đẻ ra cái lỗi đó không?
Nếu vẫn không được thì phải mò:
-Log output của top và lsof ra file 1s 1 lần. Nhớ đặt rotate log không lại teo. Đành phải trâu bò tí vậy chứ biết sao smilie

1. chkconfig iptables off là không chạy script iptables trong init.d. Script này chỉ có tác dụng đọc từ file /etc/sysconfig/iptables và áp dụng các rule này chứ không có tác dụng stop start process iptables.
2. Đây là tất cả các bước thông thường mà mình làm khi đổi hostname:
- Thay đổi file /etc/sysconfig/network
- Thay đổi file /etc/hosts
- Gõ lệnh hostname
Đối với một hệ thống Redhat (centos) là đảm bảo chuẩn đã qua kiểm định smilie

), nếu mà không được thì tớ cũng chịu smilie

Theo mình trong thử nghiệm của các bạn có nhiều vấn đề không rõ ràng:
- Cấu hình máy các bạn đang sử dụng là như thế nào (RAM thế nào, ổ cứng loại gì, có bao nhiêu diskcache, có chạy RAID không, RAID bạn có cache và battery không, bạn có warn cache hệ thống trước khi chạy không?)
- Bạn thử nghiệm với mẫu dữ liệu như thế nào, to hay nhỏ, nhiều hay ít truy cập cùng lúc? Liệu với dữ liệu lớn hơn hoặc nhiều hơn tốc độ đọc từ đĩa của bạn có đảm bảo như vậy không?

Theo mình lý do mà người ta dùng cache RAM là vì:
RAM ngày càng rẻ so với HDD (rẻ hơn SSD và chênh lệch không nhiều với RAID 10 SAS) và nó nhanh hơn. Thông thường cache là cache read, trong một số trường hợp đặc thù mới dùng write cache vì vậy không lo lắng đến vấn đề toàn vẹn dữ liệu, do đó nhược điểm của RAM coi như bỏ qua được.
Một vấn đề nữa quan trọng hơn cả là disk IO, theo mình đây mới chính là điều kiện dẫn đến việc người ta sử dụng cache trên RAM. Nếu bạn có tiếp xúc nhiều với các hệ thống lớn (đặc biệt chạy db) thì có lẽ bạn sẽ thường xuyên gặp vấn đề về disk IO bound. Ổ cứng thông thường rất rẻ nhưng ổ cứng có IO/s cao thì rất rất đắt. Nếu bạn load toàn bộ DB vào RAM bạn có thể giảm đi phần lớn số lượng read vào disk.

-giobuon

1. Đừng bao giờ test plugin của nagios với user root. Nhiều khi nó chả có vấn đề gì, nhưng nhiều lúc khiến mình mất cả ngày debug (Trust me, I learned it the hard way smilie

). Theo mình trong trường hợp của bạn có thể khi bạn chạy script với quyền root đã tạo ra các file tạm trong thư mục tmp với quyền root, sau đó khi bạn chạy với quyền nagios thì không thể đọc ghi các file này nữa.
2. Trong phần lớn trường hợp các plugin của nagios đều có source code. Bạn có thể edit và print ra các thông tin debug một các dễ dàng (ví dụ như các giá trị file đọc vào, giá trị có được từ query SNMP...)
3. Giữ mọi thứ đơn giản và theo chuẩn. Từ việc đặt tên, dùng biến, command... Việc này sẽ có ích rất lớn nếu bạn làm với số lượng lớn.

//Không đọc kĩ, quanta bài trước trả lời cùng ý mình rồi. Thực ra cách đo traffic bằng SNMP hiện nay mà hầu hết các chương trình monitor hay plugin của nagios dùng là lấy kết quả 1 lần đầu, lưu ra file, chạy tiếp lần 2, lấy chênh lệch rồi chia cho interval giữa hai lần chạy.

-giobuon

Bạn có thẻ dump một ít gói ở con proxy ko. Dùng tcpdump dump qua format của Wireshark.
Nếu không cài GUI thì dùng mấy text-based browser cũng được mà.
Nếu mà có log của squid thì càng tốt smilie

Mình mới dùng con Draytek này được mấy hôm. Cũng có một số kết luận sau:
-Phải upgrade lên firmware mới nhất. Thiết bị sẽ hoạt động trơn tru hơn và có thêm một số tính năng mới giúp ích cho việc quản trị. Bản firmware cũ thường bị lỗi khi mất một WAN là cả mạng die hoặc bình thường cũng rất chập chờn, cộng với việc rất khó khăn trong việc thực hiện NAT.
-Để ý đến session và các bảng cản lọc. Draytek rất dễ bị overload ở CPU, đảm bảo là mạng của bạn không quá nhiều các session NAT, giảm tối thiểu các rule cản lọc, ghi log, refresh...

Chắc chắn các thiết bị đều được cài đặt để chạy SNMP. Đảm bảo đều sử dụng community string public hoặc nếu dùng private thì phải cài đặt chính xác string.

Cảm ơn tất cả mọi người, có lẽ mình sẽ theo cách của Bi vậy. Hôm nay mò trên doc của sun cũng ối thứ hay ho. Không nên vội vàng quá. Từ từ rồi khoai sẽ nhừ smilie

Chào mọi người.
Mình đang muốn bắt đầu tìm hiểu về Unix. Mình muốn tìm một cuốn sách đảm bảo một số yêu cầu như:
Rõ ràng chi tiết về cấu trúc HDH.
Chỉ rõ về các khái niệm trong Unix.
Nếu có thể thì chứa kiến thức về kiến trúc máy tính thì càng quý.

Mình muốn học một cách bài bản và có nền tảng chắc, chứ không như cái Linux mình tự vọc thành ra lộn xộn và nhiều chỗ hời hợt quá. Mình đã có kiến thức căn bản về HDH, kiến trúc máy tính, Linux và lập trình C. Hy vọng bạn nào có kinh nghiệm có thể giúp mình.

Mình cảm ơn.

-giobuon

Loại này khó kiếm lắm. Hồi trước mình tìm cả ngày mà không được. Tốt nhất ra quán đã mua rồi xin lại đi

Nói thế nào nhỉ. Xét một cách tổng quan và trừu tượng nhất NAS và DAS không có gì khác nhau cả smilie

. Người ta thậm chí còn liệt kê:

wikipedia wrote:

Direct Attached Storage refers to a range of storage devices that have a single connection to a computer or device. These include:

* Portable USB storage devices
* CD-ROM drives
* ATA, SATA, SCSI, SAS hard drives
* Tape drives and autoloaders
* J.B.O.D. (Just a Bunch of Disks)
* RAID enclosures
* Server Storage Expansion

Về mặt tổng thể bạn vẫn dùng một máy nối đến thành phần lưu trữ rồi share nó qua mạng do đó NAS và DAS không khác gì nhau.
Vậy thì nên dùng NAS hay DAS theo cách của bạn hiện nay? Có thể thấy là NAS có nhiều lợi thế hơn: NAS nhẹ hơn, đơn giản hơn -> một máy chạy NAS sẽ dễ dàng thiết lập hơn, ổn định hơn và đỡ tốn điện hơn smilie

. Bạn chỉ mất khoảng 15' để cài đặt thiết lập hoàn chỉnh một máy chạy FreeNAS. Hơn nữa NAS hiện nay đã có thể sử dụng chuẩn iSCSI (tiếc là chưa cho truy xuất đồng thời vào 1 target), nếu bạn kết hợp bond 2 hay nhiều card mạng thì bạn sẽ có một máy chủ lưu trữ file với tốc độ cao. Tớ biết một cty ở HN biên tập video cho VTV trên các file RAW đặt trên một máy chủ FreeNAS, nói chung là rất "nuột".
Nếu có ý định tìm hiểu nó bạn nên cài đặt thử, rất đơn giản.

Thân.

Có lẽ bạn nên chuyển tên chủ đề thành DAS vs NAS thì chính xác hơn. NAS cũng sử dụng giao thức NFS.
Mà có lẽ nên có định nghĩa chính xác hơn về DAS. DAS thường gồm 2 thiết bị: server và storage bay. Hai cái này hiện nay thường sử dụng interface eSATA để kết nối. Đơn giản ta có thể coi storage bay là một cái ổ cứng cắm ngoài, chỉ có khác một điều là nó thường có thể hỗ trợ RAID trực tiếp trên đó.
NAS thì về nguyên tắc chỉ gồm một server. Server này cung cấp dịch vụ chia sẻ file thông qua một số giao thức thông dụng như NFS, SMB hay thậm chí cả iSCSI. Về cơ bản nó chả khác gì bạn share file một cách bình thường của máy bạn cả. Tuy nhiên các hệ thống OS chạy NAS thường để ở mức minimum đủ để phục vụ cho mục đích lưu trữ và chia sẻ mà thôi vì thế nó tối ưu hơn các OS thông dụng khác.
Bạn có thể tìm hiểu thêm về 2 hệ thống NAS thông dụng hiện nay là Openfiler và FreeNAS

Failed to connect là do nó không bind vào IP 192.168.1.35 chứ sao. Khi đó thì nó sẽ không listen trên interface đó. Nên khi thêm -b 0.0.0.0 nghĩa là nó bind trên tất cả các interface, khi đó thì lại vào được.
Một trường hợp có thể dẫn tới tình huống như thế này nữa là do cơ chế tường lửa trên máy hoặc của chính dịch vụ này.

http://www.ipcop.org/

Nếu xét về độ "thường" ý, nếu như nó có file script rồi thì "thường" nó cũng copy vào init.d luôn cho bạn chứ chẳng để bạn phiền lòng thế đâu smilie

Thực ra cũng chả có gì lạ lùng lắm. Lấy ví dụ đơn giản trên windows nhé, cho gần gũi smilie

Giả sử đang code một cái application trên C# chẳng hạn, từ source muốn có file exe thì phải compile đúng không nào. Khi đó thì nào là trình biên dịch, nào là .NET Framework SDK. Thế nhưng sau khi biên dịch xong ta chỉ việc vác cái exe đó qua máy khác kèm với .NET Framework bình thường là chạy được rồi. Trên linux cũng vậy binary và source tuy cùng của một phần mềm nhưng là hai thứ cách nhau khá xa đấy smilie

Theo mình nghĩ là như vậy. Cũng chưa có thời gian nghiên cứu kĩ về nó. Thường thì gói source là system independent ở một mức nào đó, khi bạn compile môi trường nào thì nó sẽ chạy trên môi trường đó (đương nhiên là nếu nó hỗ trợ). Còn với binary thì khác, đó là các gói đã biên dịch sẵn và thường chỉ chạy trên một môi trường xác định.
Về gói .deb bạn có thể tham khảo thêm ở đây:
http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/index.html

giobuon wrote:

Bạn thử tưởng tượng gói deb đó như một file nén chứa các file binary đã đc biên dịch sẵn, còn với source bạn phải compile, khi đó sẽ cần các thứ để compile nó ví dụ như gcc, make...

Với gói gnome-doc-utils thì cụ thể nó như thế này

The GNOME Doc Utils package is a collection of documentation utilities for the GNOME project. Notably, it contains utilities for building documentation and all auxiliary files in your source tree, and it contains the DocBook XSLT stylesheets that were once distributed with Yelp. Starting with GNOME 2.8, Yelp requires GNOME Doc Utils for the XSLT. Starting with GNOME 2.12, many of the core GNOME packages require GNOME Doc Utils.

Bạn thử tưởng tượng gói deb đó như một file nén chứa các file binary đã đc biên dịch sẵn, còn với source bạn phải compile, khi đó sẽ cần các thứ để compile nó ví dụ như gcc, make...