|
|
bontobaru wrote:
Em cũng dùng firfox mà anh
chằng hạn như em vào trang này
/hvaonline/posts/list/42798.html
trang này thì có ít dòng dài nên dễ nhìn hơn 1 tí nhưng vẫn bị dòng dài vượt quá trang
có những bài các dòng liền nhau mà lại rất dài chữ lại nhỏ em không nhớ là bài nào khi em nhấn ctrl +
4 đến 4 lần thì chữ còn nhỏ ma các dòng liền nhau nên khó đọc em nhấn 2 3 lần nữa thì mới xuất hiện
chữ to nhưng dòng rất dài phải cuộn gần như gấp 2 lần so với trước khi nhân crtl +
Tôi vào trang đó và ctlr + 4 lần cũng không bị cuộn gì hết.
Chắc chắn không thể chỉnh font cho diễn đàn to gấp 4 lần được vì làm như vậy là tiếp tục bị than phiền. Khổ thật.
|
|
|
Hmm... chuyện kích thước font cứ lâu lâu lại có người than phiền. Lúc trước thì có người than là font to như con gà mái (lúc đó là 12pt) nên được chuyển thành 11pt. Bây giờ thì có người lại than là font nhỏ quá. Thiệt không biết phải làm sao cho mọi người vừa lòng đây nữa
|
|
|
Nhìn không thấy có gì sai. Chỉ có 1 điểm từ tài liệu của tomcat:
Make sure your web.xml has the <distributable/> element
|
|
|
bontobaru wrote:
Em thấy bài viết trong diễn đàn của mình có cỡ chữ nhỏ,rất khó đọc
nếu em nhấn ctrl + thì cở chữ có tăng lên nhưng lại có 1 số bài viết trong 1 dòng quá dài
người đọc phải di chuyển tranh trượt sang bên phải mới đọc hết được dòng đó,em thấy sẽ bất tiện
nếu bài đó rất hay và người đọc muốn đọc liên tục lại phải kéo sang phải khiến ham muốn đọc bài giảm xuống
hi vọng ban quản trị có thể chỉnh sửa để nếu có người đọc nhấn ctrl + thì bài viết sẽ chỉ xuất hiện
theo khuôn khổ từ trên xuống dưới,người đọc sẽ cảm thấy thoải mái hơn với việc chỉ cần nhấn mũi tên xuống
hay chỉ cần kéo rê chuột giữa
em chỉ xin có ý kiến như vậy thôi ạ
Bồ dùng trình duyệt nào?
Tôi dùng FF và nhấn Ctrl + thì nó chỉ phóng to chữ mà không tạo thanh trượt sang bên phải.
|
|
|
StarGhost wrote:
conmale wrote:
Chuyển sang IPv6 thì 90% những kẻ hở của giao thức trong IPv4 sẽ bị loại bỏ và bởi thế, DDoS cũng bị loại bỏ 1 phần lớn.
Khi chuyển sang IPv6, mỗi thiết bị được gán cho 1 IP riêng và nếu IP ấy dùng để DDoS thì nó sẽ bị ban vĩnh viễn. Khỏi DDoS .
Anh có thể cho một số ví dụ về kẽ hở của IPv4 mà sau khi được khắc phục bởi IPv6 thì DDoS sẽ bị hạn chế?
Một trong những tính năng quan trọng của IPv6 là IPSec hoàn toàn được hỗ trợ (natively). Vì tính năng này, những dạng DDoS sử dụng reflection không thể thực hiện được vì các packets refection không có giá trị. Những dạng DDoS sử dụng spoof addresses như với IPv4 sẽ không thực hiện được với IPv6. Các dạng DDoS sử dụng biện pháp spoofing và reflection chiếm tỉ lệ rất lớn ở IPv4.
Không may, với IPv6, dạng flood bằng TCP, UDP và ICMP vẫn không thể triệt tiêu vì cơ chế "bắt tay" vẫn không thay đổi. Tuy nhiên, vì IPv6 có thừa IP để assign cho mỗi device một static IP riêng biệt cho nên nếu sử dụng biện pháp ban IP vi phạm thì chỉ ảnh hưởng có 1 người thay vì ban 1 IPv4 IP như hiện nay có thể ban hàng chục, hàng trăm hay hàng ngàn người (vì sử dụng proxy, nat....).
StarGhost wrote:
Còn câu sau của anh thì em không đồng ý, có 3 lí do:
- một IP được sử dụng để DDoS không phải là do chủ nhân IP đó muốn, mà là do thiết bị sử dụng IP đó đã trở thành zombie. Nếu IP đó bị ban, thì lại nảy sinh một vấn đề DoS mới, mà anh tưởng tượng giả sử một botnet khoảng 100000 máy bị dùng làm DDoS, mà nếu ban IP của 100000 máy đó thì không phải là DoS trên diện rộng sao.
- nếu IP spoofing vẫn còn tồn tại, làm sao tìm ra chính xác 100000 máy trong botnet để ban IP
- kể cả tìm ra được, ai sẽ thực hiện việc ban IP? ISP chăng? Tier 3, tier 2, hay tier 1 chăng? Họ được lợi gì trong việc đó?
- Nếu chủ nhân không muốn tham gia DDoS và là nạn nhân thì trước tiên chỉ có mỗi "nạn nhân" ấy bị block thay vì hàng loạt người bị block như tình trạng hiện nay. Cái này giúp giảm thiểu "từ chối dịch vụ" do chính biện pháp ban. Nếu 100000 static IPv6 IP bị ban thì chỉ 100000 IP đó bị ban thay vì 100000 x 10 hoặc x 100 bị ban như IPv4 hiện nay thì vẫn tốt hơn.
- IP Spoofing không tồn tại với IPv6 được.
- Người bị DDoS (chủ máy, chủ hệ thống) ban chớ chẳng có ISP nào ban cả. Người bị DDoS có trọn quyền cho phép hoặc ban bất cứ nguồn IP nào vi phạm. Nếu "nạn nhân" bị ban vì chính máy mình là zombie thì người bị ban phải có trách nhiệm tự xoá zombie, tự phục hồi để không bị ban.
Hãy xét ở góc độ "adaptive firewall" có khả năng tiếp tục ban một IP cho đến khi nào IP đó không còn tấn công với tính chất là một zombie. Như HVA hiện tại chẳng hạn, nếu một IP nào đó liên tục và dồn dập gởi quá giới hạn số requests trong vòng một khoảng thời gian (ngắn) thì nó bị ban. Quy chế ban có nhiều cấp độ khác nhau.
Ví dụ, nếu IP gởi cùng 5 requests đến /hvaonline/forums/list.html mà có User-Agent y hệt nhau trong vòng 10 giây thì drop request thứ 6 nhưng không block IP đó. Nếu tình trạng này tiếp tục thì tiếp tục drop requests. Nếu sau một khoảng thời gian hoặc sau một số lượng đếm nhất định nào đó thì ra lệnh cho firewall block IP này. Tuy nhiên, việc block IP sẽ không phải là block vĩnh viễn mà cứ sau bao nhiêu giây hoặc bao nhiêu phút kiểm tra và thấy IP ấy vẫn tiếp tục "dội bom" thì tiếp tục block nhưng nếu nó quay về tầng số truy cập như một người bình thường thì không block nó nữa. Nếu cũng cùng 1 IP nhưng có nhiều User-Agents khác nhau thì nới rộng giới hạn drop và block ra vì xem đó là 1 IP (proxy hoặc nat) có nhiều người dùng nhưng đến một lúc nào đó vẫn phải block vì nó đi quá giới hạn cho phép.
Bởi vậy, với IPv6 và với hoàn toàn static IP thì block một IP (theo cơ chế đã giải thích ở trên) vẫn tốt hơn là block 1 IPv4 IP.
|
|
|
OK, vừa xem xong jetty.xml của em.
Proxy của em thì chỉnh để nhận đến 51200 connections với 20 worker processes nhưng trong jetty thì chỉ có 2 Acceptors thì quá sức không cân bằng. Proxy cần phải điều chỉnh đề tương quan với backend jetty không thì 1 đầu thì rộng, 1 đầu thì quá hẹp và sẽ dẫn đến 502 dài dài.
Ngoài việc điều chỉnh Acceptors, em cần phải thêm 1 attribute acceptQueueSize:
<Set name="acceptQueueSize">512</Set>
Giá trị 512 này cần được điều chỉnh để tương quan với giá trị mà nginx accepts bên ngoài.
Em cần điều chỉnh trên kernel để tương quan với acceptQueueSize nữa:
/sbin/sysctl -w net.core.somaxconn=512
|
|
|
Sao chỉ thấy config của nginx, còn config của jetty đâu?
Config của nginx nhìn chung ok, chỉ có 2 điểm:
1. Server của em có bao nhiêu core mà set đến 20 worker processes?
2. Sao không set proxy_read_timeout ? Directive này ấn định nginx (như một proxy) phải đợi jetty trả lời trong bao lâu trước khi quyết định hồi báo (với trình duyệt) status 502.
Ngoài ra, có phải nginx và jetty chạy trên cùng server? Nếu đúng vậy thì nên chỉnh:
proxy_pass http://my_domain_vn;
thành:
proxy_pass http://localhost:<port>;
Nếu http://my_domain_vn (jetty) là một server khác thì coi chừng bị firewall có giới hạn connections giữa nginx và jetty hoặc jetty config để điều chỉnh số acceptors cho thích hợp. Tham khảo thêm ở đây:
http://wiki.eclipse.org/Jetty/Howto/Configure_Connectors
Điều chỉnh jetty connectors đều cần thiết cho cả trường hợp nginx và jetty cùng chạy trên 1 host hoặc chạy trên 2 hosts khác nhau.
|
|
|
lam_nhi wrote:
Dear All,
Hệ thống của mình gồm có: Nginx làm proxy và Jetty chạy SSO được setup trên cùng 1 server. Gần đây, nó thường sảy ra lỗi, khi dùng browser vào web: https://mydomain.vn thì lỗi: 502 Bad Gateway , Mình nghĩ lỗi này là do jetty có vấn đề, vì khi restart lại jetty thì hệ thống lại bình thường. Hiện tại, mình chỉ biết khắc phục bằng cách viết script auto restart jetty khi log có lỗi mà không biết cách khắc phục triệt để lỗi đó như thế nào vì không biết nguyên nhân do đâu. Vậy nên, mong anh em giúp đỡ
Đây là log của nó:
2012/07/02 11:05:32 [error] 11914#0: *53 connect() failed (111: Connection refused) while connecting to upstream, client: 113.160.158.93, server: mydomain.vn, request: "GET /login HTTP/1.1", upstream: "http://127.0.0.1:8080/login", host: "mydomain.vn"
2012/07/02 11:05:32 [error] 11914#0: *53 connect() failed (111: Connection refused) while connecting to upstream, client: 113.160.158.93, server: mydomain.vn, request: "GET /login HTTP/1.1", upstream: "http://127.0.0.1:8080/login", host: "mydomain.vn"
2012/07/02 11:05:38 [error] 11914#0: *53 connect() failed (111: Connection refused) while connecting to upstream, client: 113.161.76.50, server: mydomain.vn, request: "GET /login HTTP/1.1", upstream: "http://127.0.0.1:8080/login", host: "mydomain.vn"
Mình xin cảm ơn!
Bồ chỉ có nginx đứng trước jetty mà thôi? Giữa nginx và jetty có gì không?
Bồ thảy cái config của nginx và jetty lên coi?
|
|
|
xlove wrote:
conmale wrote:
xlove wrote:
conmale wrote:
Dùng mysql command để login mysql (bằng root account của mysql) rồi chạy:
show global variables like '%timeout%';
rồi post kết quả lên coi thử?
Đây là kết quả ạ
thảy mấy cái này vô my.cnf và restart lại mysql service:
connect_timeout=120
wait_timeout = 1800
Trong my.cnf của em ko có.
connect_timeout=120
wait_timeout = 1800
em đã thêm vào và restart lại mysql service. Em Restore theo bác Conmale nhưng kết quả vẫn lỗi như những lần trước
Thêm
max_allowed_packet=32M
vô trong my.cnf rồi restart lại mysql rồi thử lại.
|
|
|
8BiBi8 wrote:
Mình đọc rất nhiều topic ở HVA, mình học được nhiều thứ, từ kỹ thuật đến các kỹ năng nói chuyện, cách trả lời comment từ tất cả mọi người và nhất là các anh admin, BQT HVA. Nhưng qua loạt bài của bạn Doremon, mình thấy cần phải có chút góp ý nhỏ, đó là các bạn dùng từ quá nặng nề để nói chuyện với nhau, theo bản chất con người, dù cho các bạn nói đúng nhưng cách các bạn nói không hợp lý thì người nghe cũng tất yếu sẽ không thèm nghe. Như bạn tmd dùng những lời lẽ chỉ trích rất nặng, còn bạn comale thì cứ lặp đi lặp lại mấy từ "chụp mũ" rồi "ngụy biện" (có thể với bạn là bình thường, nhưng những người khác như mình chẳng hạn rất khó chịu, huốn chi là bạn Doremon). Ví dụ: các bạn có thể nói "cách của bạn Doremon cũng rất hay nhưng mình thấy còn nhiều chỗ chưa hợp lý (theo kinh nghiệm thực tiễn của mình) là abc, xyz, ..." thì topic đã có kết quả khác. Mình rất ngưỡng mộ kiến thức (cả kỹ thuật lẫn cách sống cách nghĩ) của anh comale, nhưng cũng rất thất vọng trước cách cư xử của anh conmale (người có quyền lực tối cao nhất diễn dàn) trong topic này, lại để kết cục chủ để là "học Tiếng Anh" trở thành nơi đấu khẩu về kiến thức, thậm chí là chà đạp nặng nề sự "chia sẻ không vụ lợi" của người khác, kết quả chỉ là sự bất bình và tâm trạng không vui cho người khác, mình thấy không đáng chút nào cả, chắc bạn comale cũng không muốn đúng không?
"Lời nói không mất tiền mua, lựa lời mà nói cho vừa lòng nhau.".
Các bạn có thể đọc bài viết phỏng vấn thiền sư Nhất Hạnh, người bị lưu đày 39 năm vì kêu gọi hòa bình ở VN:
http://langmai.org/cong-tam-quan/Thich-Nhat-Hanh/oprah-dam-dao-voi-thien-su-nhat-hanh
Mình xin trích một đoạn từ bài viết trên:
TS Nhất Hạnh: Lắng nghe sâu là lắng nghe như thế nào mà làm vơi được khổ đau của người khác. Ta có thể gọi đó là cách lắng nghe bằng tâm từ bi. Ta lắng nghe chỉ với một mục đích duy nhất : giúp cho ngươi kia trút hết nỗi lòng. Dù rằng có khi người kia đã nói những điều dẫy đầy những cái thấy rất sai lạc, đầy cay đắng, nhưng ta vẫn có thể tiếp tục ngồi lắng nghe với tâm từ bi. Bời vì ta biết rõ là lắng nghe như thế sẽ cho người kia một dịp may là bớt khổ. Nếu bạn muốn tìm cách sửa cái thấy sai lạc của người kia, ta phải chờ một dịp khác. Nhưng bây giờ đang ngồi nghe, bạn không nên cướp lời người đó, cũng không nên lý luận gì hết. Nếu bạn cướp lời thì người kia sẽ cụt hứng, sẽ mất dịp may được trút bầu tâm sự. Bạn chỉ cần lắng nghe với tấm lòng thật từ bi và điều đó sẽ giúp cho người kia bớt khổ nhiều lắm. Chỉ cần ngồi lắng nghe được chừng một giờ như thế thì ta có thể giúp chuyển hoá và chữa lành khá nhiều.
Cô Oprah: Tôi thích cách lắng nghe sâu này lắm bởi vì khi người bạn tới với ta và muốn ta lắng nghe nỗi khổ của người ấy, ta hay bị kéo đi bởi ý muốn góp ý khuyên can này nọ. Nhưng nếu ta để cho người kia trút được hết nỗi lòng. Rồi một thời gian khác ta mới trở lại khuyên nhủ và góp ý thì người kia có dịp chữa lành sâu sắc hơn. Có phải thầy muốn nói như vậy không ?
TS Nhất Hạnh: Thưa đúng. Lắng nghe sâu giúp ta nhận diện những cái thấy sai lầm của người kia về chính họ và cả những cái thấy phiến diện của họ về ta. Người kia có cái thấy sai lầm về chính anh hay chị ta và về chúng ta. Và chúng ta thì cũng có tri giác sai lầm về chính ta và về người đó. Đó là căn nguyên của bạo động, bất hòa và chiến tranh. Các người khủng bố, họ có cái thấy sai lệch. Họ tin là nhóm người kia (chống khủng bố) đang muốn tiêu diệt tôn giáo họ, tiêu diệt nền văn minh của họ. Vì thế họ phải tiêu diệt ta trước, trước khi ta tiêu diệt họ. Rồi những người chống khủng bố cũng nghĩ và hành xử y chang như nhóm kia : tụi nó muốn tiêu diệt ta thì ta phải tiêu diệt họ trước. Cả hai bên đều bị kích động bởi sự sợ hãi, căm thù và tri giác sai lầm. Và tri giác sai lầm, cái thấy sai không thể chữa trị bằng đạn bom. Cái thấy sai chỉ có thể chữa trị bằng lắng nghe sâu, nghe với tâm từ bi và lời nói ái ngữ, để gỡ từ từ những cái thấy sai lệch đó mà thôi
Tại sao khổ đau quan trọng thế và làm sao để chữa lành nó?
Cô Oprah: Cách duy nhất để chấm dứt chiến tranh là sự truyền thông của các bên.
TS Nhất Hạnh: Vâng, chúng ta phải có khả năng nói rằng: “Này các bạn, này các bạn thân mến, tôi biết quý vị đang khổ, tôi không hiểu hết được những khó khăn và khổ đau của quý vị. Chúng tôi không có ý đồ làm khổ quý vị. Ngược lại chúng tôi không hề muốn làm cho quý vị khổ thêm nữa. Nhưng chúng tôi không biết làm cách nào và chúng tôi e sẽ làm thêm những điều sai trái để khiến cho quý vị khổ thêm nếu quý vị không giúp chúng tôi hiểu thêm quý vị. Vì thế xin quý vị cho chúng biết những khó khăn của quý vị, chúng tôi rất mong được học thêm, được hiểu thêm”. Chúng ta phải tập nói lời ái ngữ. Và nếu thật sự chúng ta nói những lời ấy bằng tấm lòng chân thật của ta thi họ sẽ mở lòng ra. Rồi thì ta thực tập lắng nghe với tâm từ bi và nhờ thế ta sẽ học thêm được biết bao điều về cái thấy (chưa đúng đắn) của ta và cái thấy (chưa đúng đắn) của họ. Chỉ có những dịp như thế ta mới lấy ra từ từ những cái thấy sai lầm. Đó là cách hay nhất, cách duy nhất để làm vơi đi nạn khủng bố.
p/s: mình cũng là dân IT cùi, nên không đóng góp gì kỹ thuật được, reg nick mới cũng chỉ để góp ý mong chúng ta hòa đồng, vui vẻ vì một cộng đồng VN giàu đẹp.
Cảm ơn bạn 8BiBi8. Quả thật tôi đã nóng nảy và thiếu kiềm chế. Tôi sẽ suy ngẫm về việc này và rút kinh nghiệm.
|
|
|
xlove wrote:
conmale wrote:
Dùng mysql command để login mysql (bằng root account của mysql) rồi chạy:
show global variables like '%timeout%';
rồi post kết quả lên coi thử?
Đây là kết quả ạ
thảy mấy cái này vô my.cnf và restart lại mysql service:
connect_timeout=120
wait_timeout = 1800
|
|
|
Dùng mysql command để login mysql (bằng root account của mysql) rồi chạy:
show global variables like '%timeout%';
rồi post kết quả lên coi thử?
|
|
|
goldarrow wrote:
Theo tôi thì DDoS cũng có 1 giá trị nào đó của nó. Nếu không có DDoS thì chúng ta không biết hết (có thể là chưa hết) những điểm yếu hiện đang có trong TCP hay HTTP hiện tại.
Không cần DDoS nhưng hiểu ngọn ngành các giao thức thì vẫn biết hết được những điệm yếu đang có trong TCP/IP.
|
|
|
Các công ty bảo mật cho biết những nhà hoạt động chính trị có quan tâm đến những vấn đề ở Trung Quốc hiện đang bị một loại sâu "cửa sau" gần như chắc chắn có nguồn ở quốc gia này (Trung Quốc), nhắm đến một lần nữa.
Dựa trên cơ chế MaControl (hoặc MacControl) APT, mục tiêu cửa sau lần này là những nhà hoạt động Tân Cương (Uighur) sử dụng Windows và hết sức lý thú là cho cả Apple Macs chạy trên nền Intel và PowerPC cũ.
Như những lần tấn công trước có từ nguồn Trung Quốc, không có gì khác thường với cơ chế tấn công bằng phương thức gởi một tập nén zip đến hộp thư trong đó có chứa một bức ảnh và một ứng dụng.
Khởi động ứng dụng này khiến máy bị nhiễm sẽ bị mở cửa cho việc đánh cắp thông tin và điều khiển tầm xa; hay nói một cách khác, đây là biên độ tiêu chuẩn của dạng mã độc APT.
Ngoài thực tế vấn đề chính trị Tân Cương (một sắc tộc thiểu 'khó trị' ở vùng tây-bắc Trung Quốc) là điểm quan tâm của nhiều tổ chức ở Trung Quốc, hệ thống máy chủ điều khiến và ra lệnh được đăng ký bên trong quốc gia (Trung Quốc) nhưng có điều cần ghi nhận; những ai đã viết hoặc dùng lại mã nguồn đã thêm những phần debug bằng tiếng Anh đầy những lỗi chính tả y hệt những người không nói tiếng Anh như tiếng mẹ đẻ).
"Với Macs đang phát triển và được các mục tiêu nổi cộm ưa chuộng, chúng tôi dự phỏng số tấn công MacOS X APT cũng sẽ gia tăng," Costin Raiu, nhà nghiên cứu từ Kaspersky Lab nhận định trước khi nói thêm rằng chính Đạt Lai Lạt Ma - một mục tiêu quan trọng của nhóm chủ nghĩa dân tộc Trung Quốc - gần đây cũng sử dụng máy Mac.
Công ty AlienVault đã tường trình một phiên bản khác sử dụng hệ thống nổi tiếng Gh0st RAT để tấn công người dùng PC. Vào tháng Ba vừa rồi, dạng tấn công đến những người ủng hộ Tây Tạng mang một số tính chất có thể so sánh được với dạng tấn công mới này. Đến tháng Năm, ngay cả trang web của tổ chức ân xá quốc tế ở Anh Quốc cũng bị dùng để phát tán Gh0st RAT.
Nguồn: http://www.macworld.com/article/1167542/trojan_targets_chinese_activists_using_macs.html
|
|
|
Làm éc min mà quờ quạng kiểu này thì chết. Chỉ có 1 dòng command mà không đọc cho kỹ mà đi gõ trật lên, trật xuống thì éc min cái nỗi gì trời? Tài liệu mysql cũng chẳng buồn đọc. Đúng là mệt mỏi.
Đây:
Backup DB:
1. Tắt forum, ngưng apache.
2. Chạy command:
mysqldump -u vannghi -p -h localhost -P 3306 kenhthugian_db > /var/www/html/vnquick/thugian_data.sql
3. Download /var/www/html/vnquick/thugian_data.sql về host nào cần restore.
Restore DB:
1. start mysql service lên.
2. Chạy command:
mysql -u vannghi -p -h localhost -P 3306 kenhthugian_db < /path/to/the/file/thugian_data.sql
Chú ý từng command cả chữ IN lẫn chữ thường và dấu > hoặc < cho CHÍNH XÁC.
"step by step" cỡ đó mà còn không làm được nên bỏ nghề đi vì khổ lắm.
|
|
|
Chuyển sang IPv6 thì 90% những kẻ hở của giao thức trong IPv4 sẽ bị loại bỏ và bởi thế, DDoS cũng bị loại bỏ 1 phần lớn.
Khi chuyển sang IPv6, mỗi thiết bị được gán cho 1 IP riêng và nếu IP ấy dùng để DDoS thì nó sẽ bị ban vĩnh viễn. Khỏi DDoS .
|
|
|
Nếu giao cho ai đó quyền sờ mó cái máy, quyền tắt mở điện, quyền mở thùng máy ra thì sớm muộn gì cũng xong.
Muốn không bị reset password thì chỉnh BIOS không cho boot từ cái gì khác ngoài HD chính, khoá thùng máy, chỉnh grub password, khoá "single user mode" bằng cách thảy dòng "~:S:wait:/sbin/sulogin" vô trong /etc/inittab
Tóm lại, nếu đã cho physical access đến server thì không chỉ dùng kỹ thuật để cản mà còn cần phải dùng quy định để cản.
|
|
|
robokk wrote:
"dựa vào những gì mà Doremon giới thiệu thì em có thể tự học tại VN hay Lào hay bất kỳ môi trường nào cũng đều ok, chứ em ko cần phải bay qua "Úc" sinh sống và học tập. "
dựa vào đó mà Doremon, người "luyện" tiếng Anh 7 năm vẫn còn mắc phải những lỗi phát âm cực kỳ căn bản. Dựa vào đó mà hàng đống người học tiếng Anh ở VN có học bao nhiêu năm vẫn dính phải những lỗi phát âm cực kỳ căn bản.
Tất nhiên, nếu đây là thứ bố cho là tốt nhất thì đó là chọn lựa của bồ.
Bồ không cần phải vòng vèo thêm. Tôi chỉ cần hỏi bồ "Phương pháp là gì", tôi chỉ cần một câu định nghĩa của bồ nhưng bồ nói không ra thì thôi vậy. Phí thời gian vậy là đủ rồi.
|
|
|
Đọc kỹ lại bài số #3: /hvaonline/posts/list/42771.html#265986
nếu bồ tiếp tục kiểu chỉ 1 đằng, làm 1 nẻo thì chẳng bao giờ đi tới đâu hết.
|
|
|
warmoger wrote:
Nguồn tin ở đâu ra vậy Mod?
Nguồn tin từ HVA và từ các anh em reverse engineering của HVA.
|
|
|
lntc500 wrote:
conmale wrote:
huy_chuoi wrote:
Em xin đi thẳng vào vấn đề luôn. Hiện tại em muốn đi theo hướng bảo mật website, nhưng em có một thắc mắc là để bảo mật website thì cần những kiến thức gì? Có cần hiểu biết chuyên sâu về lập trình web hay không?
Thân.
Bảo mật cái gì thì thông thạo cái đó.
anh conmale có thể nói cụ thể hơn một chút được không ạ? chứ nếu chỉ nói hiểu biết về website thì những người mới như bọn em sẽ vẫn chưa biết nên nghiên cứu những vấn đề nào cả?
- Cái gì tạo ra web site? (apache, IIS, php, asp, aspx, jsp...)
- Cái tạo ra web chạy trên nền gì? (Windows, Linux, Solaris, AIX...)
- Cái nền ấy có cấu hình phần cứng và những kết nối với mạng như thế nào? (băng thông ít, băng thông nhiều, ADSL, Optic Fibre, VPS, dedicated server, clouds..)
Mỗi cái ở trong ngoặc có cấu hình, có thông số và có những đòi hỏi tối ưu khác nhau.
"Cụ thể hơn một chút" có nghĩa là đọc tài liệu hướng dẫn của từng cái trong ngoặc ở trên để tạo ra:
Chạy được ---> chạy bền ----> chạy tối ưu ---> chạy bảo mật
|
|
|
Ha ha, chỉ có một câu hỏi cần định nghĩa "phương pháp là gì" mà sao ngại ngùng không trả lời lại quote tùm lum tá lả lên như vậy?
Tớ chỉ cần một câu định nghĩa "phương pháp là gì" từ chính bồ thôi. Đừng quote tá lả và nhét cái emotion vô một cách vô nghĩa như một trò troll vậy.
Nếu hứng thú, bồ chứng minh giùm cho câu này: "người ta lại có cả tá hướng dẫn, tài liệu cách thức học tại nước sở tại". Bồ lục hết các tài liệu mà Doremon đưa ra, có tài liệu nào đã có cả hướng dẫn , tài liệu cách thức học tai nước VN xem?
Đừng nói liều nhá.
|
|
|
Gg9x wrote:
Mấy hôm nay thấy cái host ngốn BW ghê quá , chuyển sang VPS xài thì khổ nỗi là không thể nào chạy được code
- CentOS 5.8
VPS đã được cài : Apache2 , mySQL , PHP 5.3
Nhưng khi up code xtremedia lên thì hiện trang trắng tinh
Mong các bác giúp đỡ
Demo : http://id.p1vn.com/
Cực kỳ mơ hồ.
Những trường hợp như thế này cần logs, cần cấu hình và tất cả những gì liên quan đến "trang trắng tinh". Bồ post lên mấy cái apache2, mysql, php 5.3 để làm chi vậy?
|
|
|
xlove wrote:
Câu lệnh restore và backup thì em biết rồi. Em đã xoá log. tối ưu data. Chỉ còn hơn 1Gb Em đã backup ra 1 bản để restore lại. Em restore lại thì cứ đến đoạn table post được 1 tý là MySQL server has gone away. Em đã thử restore 1 table post thì vẫn bị. Table post có hơn 700 nghìn bản ghi. Vấn đề là table post này nhiều bản ghi quá hoặc server ko tải nổi.
Em chưa hiểu các bác giải thích giúp
Bồ post lên chính xác command bồ dùng để restore xem?
Lần trước, command để dump bồ chạy sai cho nên chẳng có gì bảo đảm command restore đúng hết.
|
|
|
robokk wrote:
conmale wrote:
robokk wrote:
conmale wrote:
robokk wrote:
robokk wrote:
nhưng thực tế của Bác ở Úc ko thể áp dụng cho bọn em ở VN được
Ba điểm đơn giản tôi đưa ra mà "thực tế không thể áp dụng cho bọn em ở VN được" thì cả đống sách, cả đống phương pháp lấy cái gì mà áp dụng được?
Hoá ra chính bồ lại đồng ý với tôi rằng những phương pháp của mấy ông giáo sư dạy tiếng Anh đều không thể áp dụng được ở VN, phải không nào?
Thiết nghĩ Bác là người biết rõ sự khác biệt giữa "phát biểu" và "phương pháp", cái nào có thể áp dụng làm theo, cái nào không thể áp dụng làm theo, nên em mạn phép ko xoay qua phân tích cụ thể cái này nữa
Hoá ra bồ không có khả năng phân biệt được sự nhận xét, đánh giá và tổng hợp những sự việc đã xảy ra trong thực tế nhằm để tránh là cái gì. Muốn "phát biểu" thì phải có nhận xét, đánh giá và tổng hợp còn không thì cũng chỉ là chém gió.
Có lẽ theo trí tuê của bồ thì những câu giảng dạy trong sách là những câu không phải là phát biểu. Ha ha.
Và "phương pháp" đi chăng nữa thì cũng không áp dụng được bởi vì ngay chính chủ nhân topic mà còn không tránh nổi những lỗi hết sức đơn giản và căn bản như tớ đã nêu ra. Chỉ 3 điểm để tránh trong cách phát âm như thế mà "không làm theo" được thì tớ quả là phí thời gian với một người như bồ. Nhưng không sao, trả lời với bồ không quan trọng bằng để cho những người khác cùng đọc.
Thôi bồ há, đừng cù nhầy nữa. Chán lắm.
nản toàn tập!!! Bác vẫn ko thoát khỏi cái vỏ bọc "Conmale". xin phép Doremon cho mình chém gió thêm 1 lần nữa!
hết vấn đề thực tế h Bác lại xoay qua vấn đề áp dụng. em đã nói 1 câu chung chung để Bác hiểu và chấm dứt tranh luận, thế mà Bác lại dùng mấy cái lý luận hàm hồ kia để nói em thế này thế khác! cái sai tiếp theo của Bác là Bác lại đi đánh đồng việc áp dụng phát biểu của Bác như phương pháp của ông giáo sư Mỹ! từ đó Bác nói phát biểu của Bác ko áp dụng dc thì phương pháp kia cũng thế! thưa Bác để chứng minh phát biểu của Bác ko hợp lý thì chỉ cần 1 phát biểu khác chứng minh ko hợp lý là ok. còn muốn chứng minh phương pháp ko hợp lý thì phải dựa vào thực tiễn chứng minh, hoặc dựa vào phương pháp khác tốt hơn phủ định nó! chứ dựa vào 1 phát biểu của Bác và 1 lỗi đơn giản (Bác nói) của Doremon để nói nó ko hợp lý thì rất liều vì chủ quan! cái kinh nghiệm của Bác được đúc kết trong 1 môi trường cụ thể là Úc (bản xứ) rèn luyện hay ứng dụng nó cũng tại úc, Bác đem nó áp dụng ở VN tất nhiên là gặp rất nhiều bất cập! Bác lại chỉ phát biểu mà ko đưa ra cách thức áp dụng. còn phương pháp kia lại dc dày công nghiên cứu đúc kết từ những khó khăn của người học tiếng anh phi bản xứ (như môi trường VN) người ta lại có cả tá hướng dẫn, tài liệu cách thức học tại nước sở tại. ví dụ như topic này của Doremon thế mà Bác lại bảo ko áp dụng dc!
nói dai nói dài vs Bác cũng thế: nếu lý lẽ của Bác chặt chẽ, kinh nghiệm của Bác đủ nhiều, thì Bác hãy nâng tầm phát biểu của Bác lên thành phương pháp, rồi dùng lý lẽ lập luận để chứng minh nó hợp lý, tiếp theo đưa ra giải pháp hướng dẫn cụ thể người ở VN làm theo kinh nghiệm của Bác từng bước từng giai đoạn 1.... Bác mà làm dc thế thì chẳng cần phải nói nhiều, lúc đấy tự nhiên ai cũng hiểu phương pháp của ông giáo sư Mỹ bị phủ định và kinh nghiệm của Bác bên đó trở thành thực tế bên này! em cũng hết ý kiến ý cò, còn ko làm dc thì đừng dùng 1 phát biểu mà bác bỏ 1 phương pháp, đừng dùng lý lẽ hàm hồ để phán linh tinh!
hy vọng cmt tiếp theo (nếu có) Bác lý luận chân chính làm dc điều em nói để em đõ phải chém gió nữa, Bác mà cứ phán bừa để đả kích em thi em lại phải chém để đả kích lại, lặp lại như thế mãi em cũng chán tận cổ rồi!
Ha ha ha. Thế thì mấy ông giáo sư soan sách kia chỉ có "phương pháp" mà thôi chớ các ông ấy chẳng có nhận xét, đánh giá, tổng hợp để phát biểu cái gì cả. Phải không nào?
Vậy theo bạn, "phương pháp" là gì? Bạn nói đi rồi mình tám tiếp. Tớ đang rảnh đây.
|
|
|
Server "ở nhà" là IP động và không có reverse DNS thì hầu hết các SMTP của hotmail, gmail và yahoo sẽ từ chối nhận.
Giải pháp: quên đi hoặc thuê server có static IP và có reverse DNS hẳn hòi.
|
|
|
monday1010 wrote:
Hi
Hôm nay có đọc được về hiện tượng leap second xảy ra vào cuối ngày 30/6, mình hiểu nôm na là giây nhuận do trái đất quay chậm lại
Tìm hiểu trên wiki : http://en.wikipedia.org/wiki/Leap_second
Thấy thông tin nó ảnh hưởng tới các server chạy Linux :
"A number of organizations reported computer problems following the June 30, 2012, leap second. Among the sites which reported problems were reddit (Apache Cassandra), Mozilla (Hadoop), Qantas Airlines, and various sites running Linux"
Chưa rõ lắm nó ảnh hưởng thế nào mà "down" cả server được, mọi người có thông tin gì về vấn đề này xin chia sẻ.
Trên hệ thống tớ quản lý có hơn 500 VM instances chạy RHEL 6 và gần như 100% bị treo vào khoảng 10:00am ngày 1/7/2012 giờ Brisbane, Australia (sáng Chủ Nhật vừa rồi). Đây cũng chính là 00:00 giờ UTC giao điểm giữa ngày 30/6/2012 và 1/7/2012 tại múi giờ UTC.
Hiện tượng "treo" là CPU lên cực kỳ cao (có server lên > 100), có server hoàn toàn tê liệt. Khi check system log thì thấy dòng:
Code:
BUG: spinlock lockup on CPU#1, ntpd/3128
Đây là lỗi ở tầng kernel chưa được vá để xử lý lúc chuyển tiếp từ 23:59:00 đến 00:00:00 ngày hôm sau (cho nên gọi là "leap second". Nguyên do là daemon ntpd gọi hàm adjtimex để kernel điều chỉnh time bằng cách thêm 1 "leap second" vào system clock. Việc này tạo ra deadlock khiến kernel bị panic và bận rộn xử lý panic trong khi những tasks khác dồn ứ cho nên CPU tăng cao và dẫn đến tê liệt.
Để fix cái này chỉ cần disable ntpd rồi restart lại server. Đợi vài giờ rồi start ntpd lên lại.
|
|
|
Nản thât.
Tài liệu hướng dẫn của mysql cả đống không chịu đọc. Đã cho cái command đã chạy chỉ có 1 dòng vỏn vẹn mà cũng không chịu đọc cho kỹ.
Bó chiếu rồi.
|
|
|
xlove wrote:
conmale wrote:
xlove wrote:
conmale wrote:
xlove wrote:
Hi các bạn
Hiện nay mình có 1 data vbb 4 Có dung lượng 7Gb. Chạy server CentOs 5. Mình đã dùng Mysqldumper để restore sang data mới cùng mysql của server đó. Nhưng chạy được 5% thì báo lỗi MySQL server has gone away.
Cho hỏi. Thông báo lỗi kia là gì? Có cách nào backup data lớn như vậy không? Thường những data lớn thì sẽ backup và restore bằng gì?
mysqldump -u <user> -p -h <host> -P <port> <database> > whatever.sql
Quên mấy cái php/perl script để backup như Mysqldumper, mysqladmin.... đối với các DB lớn vì hầu như là failed.
PS: đừng dùng chữ IN để đặt tiêu đề hoặc để gõ nội dung câu hỏi.
Đã backup theo cách của bác. Nhưng vẫn vị báo MySQL server has gone away Mong bác chỉ giúp
Tạm thời ngưng forum, tắt apache rồi mới chạy sqldump.
Đã làm theo cách của bác. Tắt apache nhưng vẫn bị lỗi như này
Bồ post lên chính xác command bồ chạy xem?
|
|
|
Xem cái này:
http://www.wireshark.org/docs/dfref/
và dành thời gian để thử nghiệm từng cái một.
|
|
|
|
|
|
|