Warning: opendir(/vcdata/webroot/manhnd.com/blog.manhnd.com/wp-content/themes/postcard/styles/) [function.opendir]: failed to open dir: Permission denied in /vcdata/webroot/manhnd.com/blog.manhnd.com/wp-content/themes/postcard/includes/theme-options.php on line 39
ManhND | Mạnh Nguyễn - Part 2
Archive by Author
09. Oct, 2010

Những con khỉ không hỏi tại sao

Những con khỉ không hỏi tại sao

Có một câu chuyện xưa lắm, xưa đến nỗi anh không nhớ là ai đã kể cho anh nghe và lúc nào, chỉ nhớ là nó liên quan đến vài con khỉ, một cái chuồng, một trái chuối và một bình chữa lửa.

em xây một cái chuồng rộng cỡ cái phòng ngủ, và lùa năm con khỉ vào một phía. phía còn lại em để một trái chuối. rồi em cầm bình chữa lửa đứng đợi. khỉ thì thích ăn chuối, nên không sớm thì muộn, một trong những con khỉ sẽ bắt đầu chạy về phía trái chuối. khi nó làm như thế, em lấy bình chữa lửa xịt vào những con khỉ còn lại. thay trái chuối mới nếu cần, và lập lại quá trình này.
Bấm xem ảnh ở cửa sổ mới
khỉ rất thông minh, nên chúng sẽ nhanh chóng nhận ra cái luật này: nếu mà có con khỉ nào tiến về phía trái chuối, cả đám còn lại sẽ bị xịt bột chữa lửa. và để tự bảo vệ, cả đàn sẽ bắt đầu tấn công bất kỳ con nào có ý định ăn chuối.

khi hiện tượng này xảy ra, em bắt một con khỉ ra khỏi chuồng, và thay vào đó bằng một con khỉ mới. con khỉ mới sẽ gia nhập đàn, cố gắng kết bạn, và chắc chắn sẽ muốn ăn trái chuối. và những con khỉ còn lại, biết rõ điều gì sẽ xảy ra, sẽ tấn công con khỉ mới để ngăn không cho em xịt chúng. sau vài lần, con khỉ mới sẽ hiểu ra, và bắt đầu tham gia tấn công nếu một con khỉ khác tiến về phía trái chuối. khi hiện tượng này xảy ra, em bắt thêm một con khỉ trong số bốn con khỉ cũ còn lại ra khỏi chuồng, và thay vào đó bằng một con khỉ mới khác.

sau khi lập lại quá trình đó vài lần, sẽ có một thời điểm không có con khỉ nào đang bị nhốt từng bị xịt bột chữa lửa; sự thật là chúng cũng chưa từng thấy cái bình chữa lửa tròn méo ra sao. nhưng mà điều hay ho là, chúng vẫn sẽ tấn công bất kỳ con khỉ nào đi về phía trái chuối!

Bấm xem ảnh ở cửa sổ mới
nếu mà con khỉ biết nói và hiểu được tiếng người, thì khi em hỏi tại sao chúng tấn công, câu trả lời của chúng chắc hẳn sẽ là: àh, thiệt ra tôi cũng không biết tại sao, nhưng đó là cách chúng tôi hành xử ở đây.

thử suy nghĩ một chút về câu trả lời của con khỉ. đã bao giờ chúng ta, con người, cũng có tư duy y như con khỉ hay không? cùng nghĩ thử xem.

đi học. có rất nhiều điều trở thành chân lý đơn giản vì thầy cô hay những người đi trước nói như thế. chúng trở thành chân lý đơn giản vì chúng là “chân lý mà chúng tôi được dạy”. không có ai mảy may nghi ngờ, liệu những chân lý đó có đúng hay không, liệu có áp dụng chúng vào thực tế cuộc sống được hay không.

đi làm. các cty thường có các quy trình. và một khi các quy trình đã trở thành “cách mà chúng tôi làm việc ở đây”, nhất là khi đã trải qua nhiều đời nhân viên, thì sẽ không còn ai nhớ rằng tại sao đó lại là cách mà cty vận hành.

chẳng có ai dừng lại để nghĩ xem đó có còn là cách làm đúng hay không, hay thậm chí đó có phải là cách làm đúng ngay từ thưở ban đầu hay không. quy trình cứ được thực hiện như một quán tính, và bất kỳ người nào đề nghị thay đổi đều sẽ có thể bị tấn công bởi những người còn lại.

có hai loại câu hỏi: làm thế nào và tại sao.

hỏi làm thế nào là hỏi hời hợt, nên câu trả lời cũng sẽ rất hời hợt. hỏi: làm thế nào để không bị tấn công? trả lời: đừng đến gần trái chuối và cứ tấn công những con khỉ đến gần trái chuối. chấm hết.

hỏi tại sao bao giờ cũng sâu sắc hơn hỏi làm thế nào, nên câu trả lời cũng phải sâu sắc. hỏi: tại sao lại tấn công những con khỉ đến gần trái chuối? trả lời: àh câu chuyện nó thế này thế này. hỏi tiếp: nhưng bây giờ đâu còn ai cầm bình xịt đứng canh nữa đâu? trả lời: vậy thì cứ ăn chuối đi!!!

sự thật trong ngày: đa số không hỏi. một số hỏi làm thế nào. một ít, ít lắm, hỏi tại sao, và được ăn chuối ;-) .

05. Oct, 2010

ALTER TABLE post REPAIR PARTITION p23;

ALTER TABLE post REPAIR PARTITION p23;

08. Sep, 2010

Mệt

Tránh

11. Mar, 2010

Domain Keys vs DKIM

Domain Keys vs DKIM

DomainKeys is an authentication and validation technique for email.  This blog article seeks to explain more about the underlying issues of this technology than the technology itself.  However, the technology will also be explained.

Domain Keys

DomainKeys is a PGP-like protocol for validating and authenticating an email.  PGP stands for Pretty Good Privacy.  It is a system where you create a public and private key.  You keep your private key private and give your public key to your friends.  So, you encrypt your data with your private key and your friends can decrypt your message with your public key.  This prevents prying eyes from seeing what’s in the data.

Domain Keys takes this idea one step further.  Instead of encrypting the email, it encrypts the email headers and creates a hash value from that encryption.  The hash value is placed in the header of the email.  When a site receives an email, it locates the public key (located in the DNS server for the user listed in the From: line of the email) and encrypts the email once again to compare the hash value.  If the hash values match after the second encryption test, the email passes validation.

So, what exactly does this do for me?

The validation test proves several things:

  • The domain listed in the From: line is valid
  • The domain listed in the From: line authorized / sent the email
  • The email has remain unchanged since creation
  • The email is not spoofed

So, the recipient can conclude that they can trust that the email is valid and is actually from the person it claims to be from.  It also means the email has not been altered in transit.

Domain Keys and DKIM

There are two methodologies to this this PGP-like technique.  DomainKeys is the branded name created by Yahoo (to which Yahoo has a few patents pending and/or granted surrounding this technology).  Yahoo created this technique to combat spam.  DKIM, on the other hand, stands for DomainKeys Identified Mail. Yes, this is confusing.  It sounds like the same thing, but it isn’t.  DKIM is a similar, but not identical, technique to validate email.   DKIM was created by the internet community (IETF) at large in response to Yahoo’s DomainKeys.  DomainKeys from Yahoo was created based on a Yahoo License agreement.  The Internet community balked at that license and decided to create a separate design that works similarly, but that isn’t under Yahoo’s licensing methodology.

Unfortunately, the DKIM community failed.  Yahoo’s lawyers have stated that parts of the DKIM specification do, in fact, utilize patents that Yahoo holds.  Because of this legal situation surrounding DKIM, what the DKIM creators had hoped to accomplish (by separating it from Yahoo) hasn’t worked.

Fracture

Because Yahoo owns DomainKeys outright based on several patents and it also appears to claim ownership of parts of the implementation of DKIM, neither is safe to use if Yahoo chooses to require licensing fees.  So, it appears that neither DKIM nor DomainKeys is gaining wide acceptance yet as a result. Unfortunately, it is unclear just how many sites are using DKIM or DomainKeys in production to validate emails. There are, however, some ISPs such as Gmail and, of course, Yahoo who are using DomainKeys.  Gmail is also using DKIM.

Because Yahoo is the creator of DomainKeys, they have a vested interest in this validation methdology.  It is still unclear if Yahoo is actually validating emails that have been signed with DKIM.  Yahoo’s outbound servers, however, do appear to use DKIM to sign outbound emails.

What does Domain Keys or DKIM buy you?

Besides email authentication, DomainKeys is a stepping stone to getting access to more Yahoo services.  For example, if you would like your IP address to be whitelisted with Yahoo, you will need to first set up DomainKeys on your domain.  Note that you must set up DomainKeys on the domain that you intend to use in the ‘From’ line of your emails.  If you change the From domain, then you will need to set up DomainKeys for each domain you intend to use.

As far as DKIM goes, it doesn’t appear that there’s much that DKIM buys you yet.  Some places are utilizing it, but many more are not.  Both DomainKeys and DKIM are somewhat cumbersome to implement, so this explains why some sites haven’t begun using it.  Certain DNS hosting services, such as GoDaddy’s Total DNS, do not support the necessary TXT record size to implement DomainKeys or DKIM.  Lack of proper DNS support can prevent setting up these validation technologies.

Overall

These technologies can aid recipients in distinguishing actual valid emails from phishing attempts.  The problem, though, is the licensing aspects, the ease of setting it up and the overall benefit.  As an email marketer, you should determine if the sites you plan to email support DKIM and/or DomainKeys.  Most large ISPs support some form of DKIM/DomainKeys, but it isn’t always the inbound portions that are supported (which matter to the email marketer).  Yahoo specifically supports DomainKeys, but it is as yet unclear if they are supporting DKIM on inbound email.  Gmail supports DomainKeys and DKIM on outbound and inbound email according to references found on the Internet.

Corporations, on the other hand, are probably not supporting either DomainKeys or DKIM just strictly due to licensing issues that could result.  If DKIM is encumbered with Yahoo’s patented techniques, it’s just a matter of time before Yahoo decides to start requiring paid licenses to use the technologies.  With Microsoft looking at buying Yahoo once again, it may not be safe to invest in DKIM or DomainKeys for corporate use.

25. Feb, 2010

ip_conntrack: table full, dropping packet



Last week, I found myself with a server under low load, but it couldn’t make or receive network connections. When I ran dmesg, I found the following line repeating over and over:

ip_conntrack: table full, dropping packet

I’d seen this message before, but I headed over to Red Hat’s site for more details. It turns out that the server was running iptables, but it was under a very heavy load and also handling a high volume of network connections. Generally, the ip_conntrack_max is set to the total MB of RAM installed multiplied by 16. However, this server had 4GB of RAM, but ip_conntrack_max was set to 65536:

# cat /proc/sys/net/ipv4/ip_conntrack_max
65536

I logged into another server with 1GB of RAM (RHES 5, 32-bit) and another with 2GB of RAM (RHES 4, 64-bit), and both had ip_conntrack_max set to 65536. I’m not sure if this is a known Red Hat issue, or if it’s just set to a standard value out of the box.

If you want to check your server’s current tracked connections, just run the following:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

To make this persistent you have to add a line like
‘net.ipv4.ip_conntrack_max=131072′ to /etc/sysctl.conf