banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: myquartz  XML
Profile for myquartz Messages posted by myquartz [ number of posts not being displayed on this page: 0 ]
 
Cài thử Fedora 18 mới nhất (từ DVD/UEFI đi).
Nó sẽ tự đông xài UEFI boot cho máy của bạn.
Cách cài bằng tay sẽ vất vả hơn, nhưng nếu muốn làm thì search từ khóa là grub uefi install.
PS: UEFI với GPT không chỉ tạo nhiều partition hơn, nó còn làm việc khởi động tiết kiệm thêm 1-3 giây (tùy máy).
Cái UDP port 3389 đó, không hiểu có phải là port game của bạn chạy thì mở ra không.
Thấy gói tin UDP cũng nhỏ, chỉ là 360 bytes so với max là 1500 thì chỉ là 20%, mình đoán đây không phải là tấn công mà có khi chính game của bạn đang có nhiều người chơi.
Và tốc độ mạng 100mb/s = 11mbyte/s ~ 11,000,000/360 ~ 31 ngàn gói UDP/s. Đây là con số khá lớn và mình nghĩ rằng không ai đi flood tốc độ đó, không thể lụt network 100mb được.

Tất nhiên có thể flood UDP làm lụt được 100mb, với điều kiện gửi gói 1500byte (to gấp 5 lần) và đủ năng lực gửi 31000/5 ~ 6000 packet/s là lụt. Nhưng cái này cũng khó (flooder phải huy động ít nhất là 5 kênh FTTH 20mbit/kênh mới đủ nhé).
Nếu lụt mạng thật, xin FPT tăng cổng mạng lên 1Gbit/s xem flooder còn đủ sức tăng 10 lần để lụt được không.

Có thể có nhiều cái khác nữa mà đoạn chụp màn hình trên chưa đủ hiện lên, bạn chạy wireshark, capture trong vòng 1 phút rồi stop. rồi vào menu Statistics => Summary => chụp màn hình gửi => thông tin chung về số gói và tốc độ mạng đang chịu.
Vào cả menu Statistics => Protocol Hierarchy => chụp màn hình gửi. Nó có nhiều thông tin hơn chỉ rõ protocol nào đang bị "lụt".

P/S: Lưu ý rằng dù có firewall cài trên host (ở máy server) chặn đủ kiểu, không có khả năng ngăn chặn lụt traffic inbound (như nhiều bạn vẫn lầm tưởng). Lý do là nó lụt ở dây mạng nối vào cổng mạng server, trước khi tới OS/firewall chặn => FW chả có tác dụng gì nữa.

vikjava wrote:
Hi anh myquartz

- Chi tiết mô hình anh đã triển khai như thế nào vậy anh smilie
Thân. 


Mình không triển khai, chỉ PoC và vẽ cho người khác làm thôi.
Nó cũng đơn giản, nó là (nhiều của) mô hình sau:
client (khai báo proxy tường minh) => internal squid (authen/URL filter/RAM cache only) => HAVP (virus scanning) => external squid (Content filter, disk cache) => Internet.
Trong đó internal, HAVP và external squid có thể cài trên 1 hoặc 2, hoặc 3 server riêng rẽ (tùy thuộc mức độ tải) và có cặp nếu cần dự phòng nóng. Internal squid thì chạy active/standby 1 cặp, đẩy request cho các HAVP (nếu nhiều hơn 1) đều nhau. external squid thì thường là NAT gateway luôn, và mỗi NAT gateway thường có nhiều hơn 1 kênh Internet.

Gọi là nhiều lần của mô hình vì nó áp dụng theo site, tùy kích thước lớn bé và mô hình mạng mà to hay nhỏ, để tối ưu băng thông (chỗ quá nhiều user thì có luôn mô hình, chỗ ít thì kết nối qua WAN).
Hello!
Đọc qua link bạn gửi thì hiểu cái smart switching là gì, thực chất nó cũng là policy routing thôi.

Qua trao đổi riêng và ở đây. Tóm lại nếu mô hình transparent thì:
Ưu điểm:
- Client không phải thay đổi gì, hoạt động trong suốt.
- Các giao thức phi HTTP cũng không bị ảnh hưởng gì bởi squid.

Nhược điểm:
- Không xác thực được.
- SSL không được hỗ trợ.
- Mô hình phức tạp, do hoặc là phải có policy-routing/smart switch, hoặc là squid server phải là gateway (mình có triển khai cái này rất lâu rồi).

Nếu mô hình khai báo tường minh proxy, thì ưu điểm là nhược điểm của mô hình transparent và ngược lại. Tuy việc khai báo proxy trong trình duyệt (và tất cả những gì chạy HTTP) phải làm bằng tay, nhưng nó lại có một số kỹ thuật như auto-proxy (wpad http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) giúp giảm bớt công việc này.

Còn quan ngại về việc squid có ổn định hay không. Thật ra transparent thì squid die => HTTP vẫn chết, phải thay đổi bằng tay bỏ wwwect/bỏ routing thì mới chạy tiếp được.
Mình thiên hướng theo mô hình khai báo tường minh, nhưng squid thò 1 chân xuống mạng (không phải gateway) và Internet gateway độc lập phục vụ các giao thức không qua squid khác. Việc này đôi khi là bắt buộc vì mình phải xác thực được client nào truy cập Internet và kiểm soát họ cả những giao thức khác như Yahoo Chat, GTalk, Skype... mà mô hình transparent không làm được.

Squid die thì chỉ lo die phần cứng. Như thế thì làm 2 server, active/standby. Thậm chí có nhiều server hơn vừa cân bằng tải, vừa quét virus HTTP Response (sử dụng với HAVP), vừa content-based scanning, hay DLP gì đó.
quanta ah, nếu state và xử lý state của kết nối với iptable thì là module state (-m state) chứ nhỉ?
Còn cái conntrack kia nó không cần quan tâm state (của connection) lắm mà là nó kiểm tra port đó có rơi vào 1 protocol helper nào đó không => để helper lục lọi soi vào data gửi => có thêm cư xử. Ví dụ FTP thì phải mở thêm cổng FTP Data sau lệnh gửi/nhận (nếu là ACTIVE mode thì còn phải NAT nữa).
Một công ty khởi nghiệp tại TP.HCM (Quận 10), chuyên làm ứng dụng và giải pháp phục vụ bài toán viễn thông, cần tuyển:
A- 03 vị trí Web Java Developer, yêu cầu:
  • Thành thạo ngôn ngữ Java, biết cách lập trình servlet, JSP, HTML/XML và JS.
  • Biết ngôn ngữ SQL (CSDL Oracle), sử dụng JDBC và truy vấn CSDL.
  • Ưu tiên đã có kinh nghiệm với dự án ứng dụng báo cáo, data warehouse.


B- 01 vị trí Oracle DB Developer, yêu cầu:
  • Thành thạo ngôn ngữ SQL, PL/SQL với Oracle RDBMS (hoặc chứng minh là đã quen một RDBMS khác với quy mô lớn, chuyển loại được)
  • Biết lập trình Java hoặc .Net hoặc một ngôn ngữ kết nối với Oracle.
  • Ưu tiên đã có kinh nghiệm với dự án ứng dụng báo cáo, data warehouse, dữ liệu lớn.


C- Quyền lợi:
  • Lương 6M-12M VND/tháng, tùy theo kinh nghiệm và khả năng.
  • Thưởng khi kết thúc dự án.
  • Được học hỏi và có cơ hội va chạm, cọ xát với dự án data warehouse cỡ lớn ở VN (100GB-1TB, đối mặt với bảng trăm triệu row trở lên).


Liên hệ: myquartz at gmail. Không giới hạn thời gian ứng tuyển (khi nào tuyển đủ tôi sẽ close topic này).
Ứng tuyển: gửi CV qua email, nếu hấp dẫn, tôi sẽ gọi điện và hẹn phỏng vấn.
exim là MTA, server của bạn gửi nhận mail nhiều lắm mới bị chậm thế.
Bạn xem cụ thể làm sao exim lại phải làm việc nhiều thế? cỡ 4CPU cho một mail server sẽ đủ sức xử lý đến cả chục GB/giờ. Không rõ bạn nhiều cỡ nào?
Bạn đã gửi thư giấy bao giờ chưa?
Bạn thử gửi thư, đề phong bì From: tên mình + địa chỉ của mình, và để To: Tên mình + địa chỉ của mình. mang ra bỏ vào hòm thư bưu điện.
Bưu điện họ gửi họ chỉ quan tâm đến To:, From là gì chả quan trọng, họ vẫn chuyển thư tới đúng To. To (là bạn) nhận được, ngạc nhiên thấy phong bì đề From là tên bạn gửi cho bạn (dĩ nhiên là nếu bạn không phải là người đề thư trên thì sẽ thế).
Email cũng thế. From đó chỉ là cái tên trên bì thư, nói chung là đặt thế nào cũng được. Có một vài kỹ thuật nhỏ cho phép đề From lung tun như thế mà "bưu điện gmail" chả có ý kiến gì.
Time trên máy Linux guest luôn luôn khó giữ đúng. bởi vì Linux nó đếm time theo số vòng tick CPU. Tùy thuộc tải và resource mà host cho guest => sai time.
Cách giải quyết:
Tùy thuộc Virtual Machine Host là loại gì mà có cách xử lý.
Có khả năng là bạn đang chạy với VMWare (trong đó CentOS của bạn là Guest), thì cài vmware-guest-tool là xong (nó sẽ đồng bộ time với host, ko còn sai nữa). xem thêm http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
Nếu dùng KVM, thì chả cần làm gì, họ nhà RedHat nó hỗ trợ sẵn luôn (chắc ko phải?). Xem them: http://www.linuxtopia.org/online_books/rhel6/rhel_6_virtualization/rhel_6_virtualization_chap-Virtualization-KVM_guest_timing_management.html
VirtualBox, hay Citrix Xen cũng thế. Host gì thì guest phải theo để cái time stamp counter trong linux nó hiểu và chạy đúng.
Máy Linux chạy trong ruột nó là 1 máy ảo Windows. Yêu cầu thế là xong.
Biết mỗi về policy based-routing thôi. Cái thứ 2 ko biết là gì :-D.

Với 1000 user, với công ty không phải là Internet Working (ví dụ 1000 user không như là tòa soạn điện tử hay game online) thì giải pháp số 3 dự sức chạy được.
Nếu 1 box làm gateway cảm thấy không đủ, thì làm 2, 3 cái. Routing cũng ko cần policy-based mà routing bình thường theo destination. Ví dụ 1000 người dùng 2 kênh cáp quang, 1 của FPT, 1 của VNPT. Thoi quen người dùng hay vào ngoisao.net và vnexpress.net, thì làm 2 gate, gate1 nối với kênh FPT và định tuyến mọi đích đến là FPT sẽ định tuyến đến gate1, còn lại default gate2.
Mình đã từng có kinh nghiệm với 1000 user, chỉ 1 squid server kiêm gateway + 4 kênh cáp quang tổng lên đến 80Mbit/s, chạy OK chả làm sao.
Xong.
mở dịch vụ SSH và dùng WinSCP (hoặc SCP).
Dùng lệnh yum localinstall <tên file rpm> sẽ giúp xử lý các gói depency.
Dùng Xen Citrix thì đơn giản, nhưng license của nó cũng mất tiền. bản free mỗi năm phải đăng ký một lần chán lắm.
Giờ nên dùng KVM (của RedHat/Centos 6.4) => xem https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/index.html

Mình cảm nhận KVM chạy nhanh hơn Xen và được support sẵn bởi RedHat/CentOS 6. (bản 6 không còn support Xen cho Host nữa, chỉ support cho Guest).

Nếu dùng KVM, cấu hình máy trên, chưa nói CPU vì chưa biết VPS chạy gì tốn CPU không, nhưng với 16GB RAM thì có thể thiếu với 60VPS (16000/60 = 266M/VPS => hơi ít, tối thiểu nên là 512M). Cũng tùy thuộc VPS chạy Guest OS nào, nếu chạy tất centos luôn, phần quản lý RAM thằng RedHat có kỹ thuật gọi là same-page merging, sẽ giúp tiết kiệm thêm một ít RAM cho việc khác (ví dụ IO cache). Kinh nghiệm mình thấy 16GB có thể gánh được khoảng 25-30 VPS chạy CentOS/RedHat với mỗi VPS 512MB (còn phải tính thêm phụ phí cho Host nữa). Nếu tăng gấp 2 lần RAM cho VPS thì số lượng VPS giảm đi nửa.
Ngoài ra, nếu VPS chạy tốn CPU, thì quad core chạy 30VPS sẽ hơi ... thiếu. 2 lần số đó sẽ cải thiện hơn (mỗi VPS sẽ được 1 VCPU).
Mấy dịch vụ anti-theft hay CompuTrace chưa có ở VN, mà nếu có chắc cũng không có hiệu quả lắm.
Mã hóa toàn bộ ổ cứng là đủ rồi. Tuy có làm giảm tốc độ máy đi một chút nhưng cũng ổn (máy mạnh mạnh dòng core i thì hầu như không cảm thấy gì). Cách khác là chỉ mã hóa phân vùng chứa dữ liệu nhạy cảm và thư mục home nhưng sẽ thêm thao tác.
TrueCrypt là ứng cử viên ngon bổ rẻ cho Windows.
Mà nếu cấp trùng thì sẽ bị báo là IP Conflict thôi.
3 DHCP vào 1 LAN vẫn chạy, nhưng có thể có những tình huống quái lạ, ví dụ cấp trùng địa chỉ, hoặc các DHCP server sẽ la lối trong log vì có cái khác ở trong mạng... Nếu làm kỹ thì sẽ không có chuyện gì cả.
Giao thức IPX/SPX (mạng Novell Netware cũ) dùng luôn địa chỉ MAC để liên hệ, nó không cần đến địa chỉ IP mà coi địa chỉ MAC là địa chỉ của host luôn. Nó cũng có khả năng hoạt động liên mạng thông qua bộ định tuyến. Ngoài IPX, còn DECNet, NetBEUI cũng vậy.
Tuy nhiên giờ các giao thức ấy đã hiếm sử dụng lắm, bởi TCP/IP với cách đánh địa chỉ logic tách rời với địa chỉ vật lý (là MAC), khiến cho hệ thống mạng rất linh hoạt, đa nền tảng truyền dẫn, đặc biệt việc định tuyến liên mạng rất dễ dàng và tin cậy, chịu lỗi (IP là giao thức khởi thủy cho ARPA Net, giao thức dành cho quốc phòng, với khả năng thay đổi định tuyến liên mạng khi một vài link lỗi).
Nhiều ưu điểm nên nhiều hỗ trợ => trở thành de-factor.
Nếu bạn không thích gán IP Address, vẫn có thể dùng trong mạng LAN thêm giao thức khác như IPX (ngày xưa các game trong LAN chỉ hỗ trợ cái này, không có khỏi chơi) hay NetBEUI (cái này chia sẻ file/máy in rất nhanh và ổn định). IP chỉ cần thiết khi bạn lên Internet hay dùng các dịch vụ dựa trên nó (mà giờ rất nhiều, ví dụ web thì cần IP, không có web liệu có ... sống được không?).

Feb 20 15:18:49 PPPoE-serv pppd[2071]: rc_ip_hostname: couldn't look up host by addr: %lX
Feb 20 15:18:49 PPPoE-serv pppd[2071]: rc_send_server: no reply from RADIUS server unknown:1812
 


Chú ý đoạn này. Nhất là port cho Radius server. ACS thường chạy port 1645, trong khi yêu cầu gửi tới server là port 1812

Ngoài ra nên define các IP sử dụng (10.10.10.x) trong file /etc/hosts để nó tránh lookup mất thời gian.
Tớ thì ủng hộ ý tưởng điên rồ.
Không có những người hoang tưởng thì sẽ không có cách mạng khoa học công nghệ.
không có các ý tưởng điên rồ của Steve Jobs hay cặp SL gúc thì thế giới hiện tại không có mấy thứ hay ho để xài rồi.
Tuy nhiên hãy nghĩ tới cái mới, làm cái mới toe chưa ai làm, đừng reinventing the wheel là được rồi.
Topic này tôi cũng muốn theo xem chủ topic tìm ra nguyên nhân là sao. Chưa bao giờ gặp hiện tượng này cả, chỉ có khi bắt đầu ssh thì bị chậm hoặc là báo lỗi ngay lập tức thôi.
Nếu có thể chủ topic bật debug thông tin putty (cái SSH được tốt ấy), rồi so sánh với openssh debug xem có gì khác nhau trong quá trình bắt tay không, biết đâu có manh mối gì đó.
Trên server, thử làm cái này coi:
- mở file /etc/ssh/sshd_config
- tìm các dòng bắt đầu bằng
GSSAPI*, comment hết.
Thêm hoặc sửa dòng sau:
GSSAPIAuthentication no
- tìm dòng sau và sửa thành:
UseDNS no
- Restart sshd, rồi ssh thử xem còn bị không.
Con số 1 triệu cũng khá to nhưng thực tế có nhiều hệ thống đạt mức hơn thế này nhiều rồi.
Cái mấu chốt thiết kế hệ thống này chính là: chia để trị, hay là scale-out. làm sao để 1 máy ví dụ gánh được 10K kết nối, và số lượng tăng lên tỉ lệ thuận với số máy. bài toán giải sẽ là 1 triệu = 100 máyx10K kết nối.
Nếu protocol hiệu quả hơn, ko phải TCP mà UDP hoặc 1 kiểu sáng tạo khác nào đó, thì 1 server có khả năng nhận được nhiều hơn, 50K, 100K => số server ít hơn => tiết kiệm hơn.
Tốc độ kết nối thiết bị vật lý thì không thể tăng quá cái giá trị đó. Khi cổng thiết bị bị nhồi quá nhiều dữ liệu hơn khả năng truyền vật lý, do đó thiết bị kết nối (ví dụ switch nối máy có interface 1gb) nó sẽ drop (bỏ) gói tin quá tốc độ đó. Nghĩa là 0.5gb sẽ bị bỏ đi, interface chỉ nhận đúng 1gb còn lại.
repo = viêt tắt của repositories = kho chứa.
Yum repo là kho chứa các gói phần mềm theo kiểu của yum đặt trên một server ngoài Internet, cho phép dùng lệnh yum để cập nhật, cài đặt hay tìm kiếm. Nó từa tựa như Apple Store (trên iPhone iPad) hay Google Play Store (Android), nơi tác giả của distro đưa lên rất nhiều các gói phần mềm đã được dịch sẵn và làm sẵn, thử trước rồi, khi cần chỉ tìm kiếm cài đặt hay update không phải build compile từ nguồn hay xử lý các vấn đề tương thích gì phức tạp.

Shell file bị sai hoặc bi xóa.
Vào single mode rồi gõ lệnh này xem:

usermod --shell /bin/bash root
Thấy mọi người có vẻ nặng lời vì lỗi này. Tớ cho đây là việc lười biếng của lập trình viên thôi.

Cho mình hỏi trong lập trình, thì có cách nào đơn giản để một ứng dụng back-end chạy dưới quyền "root" (được set SUID), ví dụ mục đích update, cài đặt một phần mềm mới, thay đổi tham số hệ thống... mà ứng dụng front-end (chạy dưới quyền user) có thể invoke nó mà không cần nhập mật khẩu root?
Kiểu như sudo ấy, sudo mà không config trước sudoers thì đừng hòng thực hiện được lệnh khi không có mật khẩu root.
cái dòng log này:

Code:
[Mon Oct 01 16:45:15 2012] [error] server reached MaxClients setting, consider raising the MaxClients setting


Chính là dấu hiệu có thể làm cho server chết. vì có quá nhiều client kết nối => quá tải => hết tài nguyên (nhất là RAM) => treo (tức là chậm ko chạy được cái gì khác cả)?
Xóa rule thì không được nhưng rule trong iptables có điều thời gian đấy. Có thể chặn từ thời gian tới thời gian trong ngày hoặc từ ngày/giờ đến ngày/giờ nào đó cụ thể thì rule hết tác dụng (vẫn còn trong bảng nhưng hết tác dụng)
Không phải vô lý đâu. Không có lửa làm sao có khói. Họ phải có lý do là tại sao chặn, nhất là bạn kinh doanh vàng và CK to tiền thế mà lại đặt server nước ngoài thế thì càng có lý do nghi ngờ nó không hợp pháp.
Hiện nay có hoạt động dò tìm mật khẩu email rất nhiều. Ở công ty tớ ngày nào cũng ghi nhận vài trăm hoạt động như thế.

Công ty Hosting của bên bạn khá cẩn thận, theo cái log mà bạn gửi thì có vẻ như nhập sai mật khẩu (xác thực SMTP) quá 5 lần trong 300 giây là bị khóa tài khoản hoặc khóa IP. Nguồn dò là IP ở China.
Vì lý do khóa tài khoản hoặc tương tự sau khi sai 5 lần, nó làm cho chủ nhân của TK ko vào được nữa cho dù nhập đúng mật khẩu. Bạn không nói rõ là bên bạn không gửi được mail nữa vì lý do gì nên tớ đoán thế. Hoặc chính công ty bạn có người/có phần mềm mã độc chuyên dò mật khẩu nhằm luôn vào mail công ty => bị chặn luôn IP.
Theo tớ bạn nên có ý kiến với bên Hosting, hỏi họ lý do bị khóa và đề nghị họ cho lời khuyên. Có thể cung cấp thêm nhiều thông tin hơn nữa (về chương trình email client, khi không dùng được báo lỗi sao...) thì có thể có lời khuyên hay hơn.
 
Go to Page:  First Page Page 2 4 5 6 Page 7 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|