ดยปกติแล้ว Vista จะใช้พื้นที่ประมาณ 15% ของ HDD สำหรับทำ System Restore
ใน XP จะมี option ที่สามารถลดขนาดได้ แต่วิสต้ามันไม่ติดมาให้ด้วย
ดังนั้นเราต้องใช้ command สำหรับ Reduce หรือลดขนาดเอง =_____________="
ก่อนอื่นเลยให้เราเปิด command prompt ขึ้นมาด้วยการไปที่ RUN แล้วพิมว่า cmd แล้ว Enter
จากนั้นพิมว่า vssadmin list shadowstorage เพื่อดูขนาดของ System Restore ปัจจุบัน
vssadmin list shadowstorage
ต่อไปเป็นวิธีการ edit ให้มันเล็กลง
vssadmin resize shadowstorage /on=[drive]: /for=[drive]: /maxsize=[size]
ตัวอย่างผมจะลดขนาด System Restore ที่ไดร์ C: ให้เหลือ 2GB
vssadmin resize shadowstorage /on=C: /for=C: /maxsize=2GB
แล้วมาตรวจสอบขนาดอีกทีครับ
vssadmin list shadowstorage
เอาไปทดสอบกันดู :p
วันอังคารที่ 7 กุมภาพันธ์ พ.ศ. 2555
วันพุธที่ 25 มกราคม พ.ศ. 2555
How to get notified when an e-mail has been read/delivered?
Content: DSN, RFCs, How? , MUAs, Receipt Notification
This text tries to explain what standards and other means are available to get a notification when your e-mail has been delivered, received, or read.
First, let's define the terminology:
delivery
means that the e-mail has been delivered by an MTA to a recipient's mailbox;
receipt
means that a user has received the e-mail.
As you can immediately see, there are several problems involved with these definitions. What is the recipient's mailbox? Is it just the spool file on her mailhost? What if she gets her e-mail forwarded by a fax or pager or something similar?
What does it mean that the user has received the e-mail? That is has actually been read? Just the subject of the e-mail? That some program has sorted the e-mail?
As you can see, these are complicated questions, and they can be formally defined only in a fixed framework, as it has been done in X.400. There are two documents available about this topic from the Canonical Internet vs X.400 Debate: Delivery Report Notifications and Receipt Notifications (which are quite old).
In this document, I'll concentrate on what the Internet, i.e, (E)SMTP, has to offer for these topics. If you have any corrections or additions please let me know.
Delivery Status Notification
Delivery Status Notification (DSN) is a function of the MTA. There are two different kinds: positive and negative delivery status notifications. Negative delivery status notifications have been available for a long time: Sorry, your message could not be delivered to:... and hopefully some meaningful explanation. Depending on some implementation stuff, you probably get your complete message back.
Positive delivery status notifications have not been available as a standard. sendmail prior to version 8.7 (and other MTAs) supported Return-Receipt-To: (I patched my sendmail 8.7, since one of my friends asked for it). There are several problems with this, but it has been useful for me in many situation. You just have to know, that
the recipient's MTA does support Return-Receipt-To:;
you should use it only with one recipient (or a very few), but not with a mailing list;
it doesn't mean that much if you don't get a notification.
The first problem is addressed by DSN in the following way: if it delivers an e-mail to an MTA which doesn't support DSNs it will tell the sender so (using a MIME message as defined in RFC 1892 ):
----- The following addresses have delivery notifications -----
RECIPIENT (relayed to non-DSN-aware mailer)
----- Transcript of session follows -----
RECIPIENT relayed; expect no further notifications
The second problem is addressed by DSN too: you have to specify for each recipient, whether you want a DSN for her. This has also been addressed by D.J. Bernstein: he proposes a header Notice-Requested-Upon-Delivery-To: orig.recipient@host.dom.ain in his proposal for an RFC. This is implemented in qmail.
The third problem isn't solved. Since the DSN is sent with a null sender ( <> ), it will be dumped if it can't be delivered.
Delivery Status Notification: The RFCs
The relevant RFC for DSN is RFC 1891 K. Moore: SMTP Service Extension for Delivery Status Notifications (31 pages).
RFC 1892 G. Vaudreuil: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (4 pages)
defines the framework for notification messages. This framework ist used for the message format of DSNs:
RFC 1894 K. Moore: An Extensible Message Format for Delivery Status Notifications (39 pages).
Delivery Status Notification: How does it work?
sendmail 8.7 has no hook to request a DSN from the commandline, it can be only done in an ESMTP dialogue. This is quite reasonable, since options (as introduced in sendmail 8.8), are barely flexible enough to allow for something like this (slightly modified from the RFC):
R: 220 Pure-Heart.ORG SMTP server here
S: EHLO Pure-Heart.ORG
R: 250-Pure-Heart.ORG
R: 250-DSN
R: 250 SIZE
S: MAIL FROM: RET=HDRS ENVID=QQ314159
R: 250 sender ok
S: RCPT TO: NOTIFY=SUCCESS,DELAY ORCPT=rfc822;Bob@Big-Bucks.COM
R: 250 recipient ok
S: RCPT TO: NOTIFY=FAILURE ORCPT=rfc822;Carol@Ivory.EDU
R: 250 recipient ok
S: RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Dana@Ivory.EDU
R: 250 recipient ok
S: RCPT TO: NOTIFY=NEVER
R: 250 recipient ok
Let's look at some of the additional keywords: In the MAIL command you can specify what to return (RET=). This only applies to an e-mail that couldn't be delivered. For each RCPT you specify what kind of DSN you want (NOTIFY=):
SUCCESS when the e-mail has successfully been delivered.
FAILURE when the e-mail couldn't be delivered.
DELAY when the e-mail delivery has been delayed.
NEVER you want no DSN at all.
The first three parameters may be combined, the last one must occur only on its own.
In sendmail 8.8.x (x > 4), you can trigger a DSN with the Return-Receipt-To: header, if you re-compile sendmail and set a switch.
Other MTA which support DSNs are ISOCOR's N-PLEX and TeamWARE Office.
Delivery Status Notification: Which MUA supports it?
ELM 2.4ME supports from PL27 on DSN, if you have sendmail 8.8 or higher. You can select several options from a menu. Mutt is another MUA with DSN support. It looks similar to elm, but is a complete new start, without all the legacy code elm has. Ratatosk is still in beta, but it has support for DSN.
Exmh 2.0 supports DSN too (but only with a patch).
Pine supports DSN since about version 4.0 according to Vladimír Solnický. Older (outdated?) versions may need a patch for Pine to enable DSN (but it's limited: there is an option in the config screen for delivery SUCCESS notifications). It is from Chris Taylor.
Netscape is another MUA which supports DSN (thanks to Diane Davidowicz for pointing this out).
Novell GroupWise (as of v7.0 it runs on Linux) supports DSN too (according to David Bank).
I don't know many MUAs, so please tell me, when you know other MUAs (for Unix of course), which support DSN.
Receipt Notification
This is a function of the MUA. Take a look at the Charter of the IETF group working on this topic.
Extensible Message Format for Message Disposition Notification is the current RFC (2298).
This is a rather controversial topic, since it touches privacy issues. So the best is to ask the recipient that she sends you an acknowledge :-).
Receipt Notification: Which MUA supports it?
Chris Koenigsberg told me that Exmh 2.0 supports MDN. Ron Arts wrote me that Netscape 4.5 which supports MDN too.
I don't know any other MUA that supports receipt notification. But I assume there are many available in proprietary system. However, these don't count here. Please tell me, when you know a MUA (for Unix of course) which supports receipt notification.
Some more things about DSN
Robert Sargent added the following information about DSN in sendmail 8.8:
In the sendmail.cf file you must have these options set:
# deliver MIME-encapsulated error messages?
O SendMimeErrors=True
# privacy flags must NOT be set for "goaway" or "noreceipts". The
# tightest the Privacy can be set to is:
O PrivacyOptions=authwarnings,noexpn,novrfy,needmailhelo,restrictmailq,restrictqrun
And of course you must be in an ESMTP session (i.e., DSN doesn't work over plain old SMTP sessions). The starting MUA must have requested DSN (or Return-Receipt-To: (RRT) and if so, sendmail must support the option to convert RRT to DSN. Then after doing all of the above, DSN still won't work all the time and when it does, you'll be amazed at how much detail it can provide an outsider about your internal (thought to be trusted) network topology, operating systems, local delivery situations, aliases, mailing lists, etc., etc..
This text tries to explain what standards and other means are available to get a notification when your e-mail has been delivered, received, or read.
First, let's define the terminology:
delivery
means that the e-mail has been delivered by an MTA to a recipient's mailbox;
receipt
means that a user has received the e-mail.
As you can immediately see, there are several problems involved with these definitions. What is the recipient's mailbox? Is it just the spool file on her mailhost? What if she gets her e-mail forwarded by a fax or pager or something similar?
What does it mean that the user has received the e-mail? That is has actually been read? Just the subject of the e-mail? That some program has sorted the e-mail?
As you can see, these are complicated questions, and they can be formally defined only in a fixed framework, as it has been done in X.400. There are two documents available about this topic from the Canonical Internet vs X.400 Debate: Delivery Report Notifications and Receipt Notifications (which are quite old).
In this document, I'll concentrate on what the Internet, i.e, (E)SMTP, has to offer for these topics. If you have any corrections or additions please let me know.
Delivery Status Notification
Delivery Status Notification (DSN) is a function of the MTA. There are two different kinds: positive and negative delivery status notifications. Negative delivery status notifications have been available for a long time: Sorry, your message could not be delivered to:... and hopefully some meaningful explanation. Depending on some implementation stuff, you probably get your complete message back.
Positive delivery status notifications have not been available as a standard. sendmail prior to version 8.7 (and other MTAs) supported Return-Receipt-To: (I patched my sendmail 8.7, since one of my friends asked for it). There are several problems with this, but it has been useful for me in many situation. You just have to know, that
the recipient's MTA does support Return-Receipt-To:;
you should use it only with one recipient (or a very few), but not with a mailing list;
it doesn't mean that much if you don't get a notification.
The first problem is addressed by DSN in the following way: if it delivers an e-mail to an MTA which doesn't support DSNs it will tell the sender so (using a MIME message as defined in RFC 1892 ):
----- The following addresses have delivery notifications -----
RECIPIENT (relayed to non-DSN-aware mailer)
----- Transcript of session follows -----
RECIPIENT relayed; expect no further notifications
The second problem is addressed by DSN too: you have to specify for each recipient, whether you want a DSN for her. This has also been addressed by D.J. Bernstein: he proposes a header Notice-Requested-Upon-Delivery-To: orig.recipient@host.dom.ain in his proposal for an RFC. This is implemented in qmail.
The third problem isn't solved. Since the DSN is sent with a null sender ( <> ), it will be dumped if it can't be delivered.
Delivery Status Notification: The RFCs
The relevant RFC for DSN is RFC 1891 K. Moore: SMTP Service Extension for Delivery Status Notifications (31 pages).
RFC 1892 G. Vaudreuil: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (4 pages)
defines the framework for notification messages. This framework ist used for the message format of DSNs:
RFC 1894 K. Moore: An Extensible Message Format for Delivery Status Notifications (39 pages).
Delivery Status Notification: How does it work?
sendmail 8.7 has no hook to request a DSN from the commandline, it can be only done in an ESMTP dialogue. This is quite reasonable, since options (as introduced in sendmail 8.8), are barely flexible enough to allow for something like this (slightly modified from the RFC):
R: 220 Pure-Heart.ORG SMTP server here
S: EHLO Pure-Heart.ORG
R: 250-Pure-Heart.ORG
R: 250-DSN
R: 250 SIZE
S: MAIL FROM:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
Let's look at some of the additional keywords: In the MAIL command you can specify what to return (RET=). This only applies to an e-mail that couldn't be delivered. For each RCPT you specify what kind of DSN you want (NOTIFY=):
SUCCESS when the e-mail has successfully been delivered.
FAILURE when the e-mail couldn't be delivered.
DELAY when the e-mail delivery has been delayed.
NEVER you want no DSN at all.
The first three parameters may be combined, the last one must occur only on its own.
In sendmail 8.8.x (x > 4), you can trigger a DSN with the Return-Receipt-To: header, if you re-compile sendmail and set a switch.
Other MTA which support DSNs are ISOCOR's N-PLEX and TeamWARE Office.
Delivery Status Notification: Which MUA supports it?
ELM 2.4ME supports from PL27 on DSN, if you have sendmail 8.8 or higher. You can select several options from a menu. Mutt is another MUA with DSN support. It looks similar to elm, but is a complete new start, without all the legacy code elm has. Ratatosk is still in beta, but it has support for DSN.
Exmh 2.0 supports DSN too (but only with a patch).
Pine supports DSN since about version 4.0 according to Vladimír Solnický. Older (outdated?) versions may need a patch for Pine to enable DSN (but it's limited: there is an option in the config screen for delivery SUCCESS notifications). It is from Chris Taylor.
Netscape is another MUA which supports DSN (thanks to Diane Davidowicz for pointing this out).
Novell GroupWise (as of v7.0 it runs on Linux) supports DSN too (according to David Bank).
I don't know many MUAs, so please tell me, when you know other MUAs (for Unix of course), which support DSN.
Receipt Notification
This is a function of the MUA. Take a look at the Charter of the IETF group working on this topic.
Extensible Message Format for Message Disposition Notification is the current RFC (2298).
This is a rather controversial topic, since it touches privacy issues. So the best is to ask the recipient that she sends you an acknowledge :-).
Receipt Notification: Which MUA supports it?
Chris Koenigsberg told me that Exmh 2.0 supports MDN. Ron Arts wrote me that Netscape 4.5 which supports MDN too.
I don't know any other MUA that supports receipt notification. But I assume there are many available in proprietary system. However, these don't count here. Please tell me, when you know a MUA (for Unix of course) which supports receipt notification.
Some more things about DSN
Robert Sargent added the following information about DSN in sendmail 8.8:
In the sendmail.cf file you must have these options set:
# deliver MIME-encapsulated error messages?
O SendMimeErrors=True
# privacy flags must NOT be set for "goaway" or "noreceipts". The
# tightest the Privacy can be set to is:
O PrivacyOptions=authwarnings,noexpn,novrfy,needmailhelo,restrictmailq,restrictqrun
And of course you must be in an ESMTP session (i.e., DSN doesn't work over plain old SMTP sessions). The starting MUA must have requested DSN (or Return-Receipt-To: (RRT) and if so, sendmail must support the option to convert RRT to DSN. Then after doing all of the above, DSN still won't work all the time and when it does, you'll be amazed at how much detail it can provide an outsider about your internal (thought to be trusted) network topology, operating systems, local delivery situations, aliases, mailing lists, etc., etc..
Delivery Status Notification: How does it work?
sendmail 8.7 has no hook to request a DSN from the commandline, it can be only done in an ESMTP dialogue. This is quite reasonable, since options (as introduced in sendmail 8.8), are barely flexible enough to allow for something like this (slightly modified from the RFC):
R: 220 Pure-Heart.ORG SMTP server here
S: EHLO Pure-Heart.ORG
R: 250-Pure-Heart.ORG
R: 250-DSN
R: 250 SIZE
S: MAIL FROM: RET=HDRS ENVID=QQ314159
R: 250 sender ok
S: RCPT TO: NOTIFY=SUCCESS,DELAY ORCPT=rfc822;Bob@Big-Bucks.COM
R: 250 recipient ok
S: RCPT TO: NOTIFY=FAILURE ORCPT=rfc822;Carol@Ivory.EDU
R: 250 recipient ok
S: RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Dana@Ivory.EDU
R: 250 recipient ok
S: RCPT TO: NOTIFY=NEVER
R: 250 recipient ok
Let's look at some of the additional keywords: In the MAIL command you can specify what to return (RET=). This only applies to an e-mail that couldn't be delivered. For each RCPT you specify what kind of DSN you want (NOTIFY=):
SUCCESS when the e-mail has successfully been delivered.
FAILURE when the e-mail couldn't be delivered.
DELAY when the e-mail delivery has been delayed.
NEVER you want no DSN at all.
R: 220 Pure-Heart.ORG SMTP server here
S: EHLO Pure-Heart.ORG
R: 250-Pure-Heart.ORG
R: 250-DSN
R: 250 SIZE
S: MAIL FROM:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
S: RCPT TO:
R: 250
Let's look at some of the additional keywords: In the MAIL command you can specify what to return (RET=). This only applies to an e-mail that couldn't be delivered. For each RCPT you specify what kind of DSN you want (NOTIFY=):
SUCCESS when the e-mail has successfully been delivered.
FAILURE when the e-mail couldn't be delivered.
DELAY when the e-mail delivery has been delayed.
NEVER you want no DSN at all.
Notify when Read
15:24:07.797 5 SMTP-037978() started
15:24:07.797 5 SMTP-037978(softdebut.com) processing
15:24:07.799 5 SMTP-037978(softdebut.com) 2 relay(s) found:ast2.softdebut.com ast1.softdebut.com
15:24:07.799 4 SMTP-037978(softdebut.com) connecting [61.47.43.197]:0 -> [61.47.43.194]:25
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 220 ast1.softdebut.com ESMTP qmail 5.4.2 is glad to see you!
15:24:07.800 4 SMTP-037978(softdebut.com) connected to ast1.softdebut.com [61.47.43.194]:25, ESMTP
15:24:07.800 5 SMTP-037978(softdebut.com) out: EHLO debutmail.com\r\n
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ast1.softdebut.com we trust you debutmail.com
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-DSN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-SIZE 41943040
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ETRN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-TURN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ATRN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-NO-SOLICITING
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-8BITMIME
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-HELP
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-PIPELINING
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250 EHLO
15:24:07.800 4 SMTP-037978(softdebut.com) Connected. DSN SIZE SOLICIT
15:24:07.800 4 SMTP-037978(softdebut.com) [15138592] sending
15:24:07.800 5 SMTP-037978(softdebut.com) out: MAIL FROM: SIZE=591\r\n
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250 chanamat.o@debutmail.com sender accepted
15:24:07.801 5 SMTP-037978(softdebut.com) out: RCPT TO: NOTIFY=FAILURE,DELAY\r\n
15:24:07.801 5 SMTP-037978(softdebut.com) inp: 250 chanamat.o@softdebut.com accepting mail from a client address
15:24:07.801 5 SMTP-037978(softdebut.com) out: DATA\r\n
15:24:07.801 5 SMTP-037978(softdebut.com) inp: 354 Enter mail, end with "." on a line by itself
15:24:07.801 5 SMTP-037978(softdebut.com) out: Received: from [58.9.225.207] (account chanamat.o@debutmail.com)\r\n by debutmail.com (CommuniGate Pro WEBUSER 5.3.15)\r\n with HTTP id 15138592 for chanamat.o@softdebut.com; Wed, 25 Jan 2012 15:24:07 +0700\r\nFrom:\r\nSubject: 2\r\nTo: chanamat.o@softdebut.com\r\nX-Mailer: CommuniGate Pro WebUser v5.3.15\r\nDate: Wed, 25 Jan 2012 15:24:07 +0700\r\nMessage-ID: \r\nMIME-Version: 1.0\r\nDisposit
15:24:07.805 5 SMTP-037978(softdebut.com) inp: 250 13168410 message accepted for delivery
15:24:07.805 2 SMTP-037978(softdebut.com) [15138592] sent to [61.47.43.194]:25, got:250 13168410 message accepted for delivery
15:24:07.805 5 SMTP-037978(softdebut.com) out: QUIT\r\n
15:24:07.805 5 SMTP-037978(softdebut.com) inp: 221 ast1.softdebut.com qmail SMTP closing connection
15:24:07.805 4 SMTP-037978(softdebut.com) closing connection
15:24:07.805 4 SMTP-037978(softdebut.com) releasing stream
15:24:07.797 5 SMTP-037978(softdebut.com) processing
15:24:07.799 5 SMTP-037978(softdebut.com) 2 relay(s) found:ast2.softdebut.com ast1.softdebut.com
15:24:07.799 4 SMTP-037978(softdebut.com) connecting [61.47.43.197]:0 -> [61.47.43.194]:25
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 220 ast1.softdebut.com ESMTP qmail 5.4.2 is glad to see you!
15:24:07.800 4 SMTP-037978(softdebut.com) connected to ast1.softdebut.com [61.47.43.194]:25, ESMTP
15:24:07.800 5 SMTP-037978(softdebut.com) out: EHLO debutmail.com\r\n
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ast1.softdebut.com we trust you debutmail.com
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-DSN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-SIZE 41943040
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ETRN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-TURN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-ATRN
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-NO-SOLICITING
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-8BITMIME
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-HELP
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250-PIPELINING
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250 EHLO
15:24:07.800 4 SMTP-037978(softdebut.com) Connected. DSN SIZE SOLICIT
15:24:07.800 4 SMTP-037978(softdebut.com) [15138592] sending
15:24:07.800 5 SMTP-037978(softdebut.com) out: MAIL FROM:
15:24:07.800 5 SMTP-037978(softdebut.com) inp: 250 chanamat.o@debutmail.com sender accepted
15:24:07.801 5 SMTP-037978(softdebut.com) out: RCPT TO:
15:24:07.801 5 SMTP-037978(softdebut.com) inp: 250 chanamat.o@softdebut.com accepting mail from a client address
15:24:07.801 5 SMTP-037978(softdebut.com) out: DATA\r\n
15:24:07.801 5 SMTP-037978(softdebut.com) inp: 354 Enter mail, end with "." on a line by itself
15:24:07.801 5 SMTP-037978(softdebut.com) out: Received: from [58.9.225.207] (account chanamat.o@debutmail.com)\r\n by debutmail.com (CommuniGate Pro WEBUSER 5.3.15)\r\n with HTTP id 15138592 for chanamat.o@softdebut.com; Wed, 25 Jan 2012 15:24:07 +0700\r\nFrom:
15:24:07.805 5 SMTP-037978(softdebut.com) inp: 250 13168410 message accepted for delivery
15:24:07.805 2 SMTP-037978(softdebut.com) [15138592] sent to [61.47.43.194]:25, got:250 13168410 message accepted for delivery
15:24:07.805 5 SMTP-037978(softdebut.com) out: QUIT\r\n
15:24:07.805 5 SMTP-037978(softdebut.com) inp: 221 ast1.softdebut.com qmail SMTP closing connection
15:24:07.805 4 SMTP-037978(softdebut.com) closing connection
15:24:07.805 4 SMTP-037978(softdebut.com) releasing stream
Notify when Delivered
15:16:19.871 5 SMTP-037767() started
15:16:19.871 5 SMTP-037767(softdebut.com) processing
15:16:20.160 5 SMTP-037767(softdebut.com) 2 relay(s) found:ast2.softdebut.com ast1.softdebut.com
15:16:20.160 4 SMTP-037767(softdebut.com) connecting [61.47.43.197]:65535 -> [61.47.43.194]:25
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 220 ast1.softdebut.com ESMTP qmail 5.4.2 is glad to see you!
15:16:20.161 4 SMTP-037767(softdebut.com) connected to ast1.softdebut.com [61.47.43.194]:25, ESMTP
15:16:20.161 5 SMTP-037767(softdebut.com) out: EHLO debutmail.com\r\n
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ast1.softdebut.com we trust you debutmail.com
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-DSN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-SIZE 41943040
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ETRN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-TURN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ATRN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-NO-SOLICITING
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-8BITMIME
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-HELP
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-PIPELINING
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 EHLO
15:16:20.161 4 SMTP-037767(softdebut.com) Connected. DSN SIZE SOLICIT
15:16:20.161 4 SMTP-037767(softdebut.com) [15138018] sending
15:16:20.161 5 SMTP-037767(softdebut.com) out: MAIL FROM: SIZE=536\r\n
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 chanamat.o@debutmail.com sender accepted
15:16:20.161 5 SMTP-037767(softdebut.com) out: RCPT TO: NOTIFY=FAILURE,SUCCESS,DELAY\r\n
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 chanamat.o@softdebut.com accepting mail from a client address
15:16:20.161 5 SMTP-037767(softdebut.com) out: DATA\r\n
15:16:20.162 5 SMTP-037767(softdebut.com) inp: 354 Enter mail, end with "." on a line by itself
15:16:20.162 5 SMTP-037767(softdebut.com) out: Received: from [58.9.225.207] (account chanamat.o@debutmail.com)\r\n by debutmail.com (CommuniGate Pro WEBUSER 5.3.15)\r\n with HTTP id 15138018 for chanamat.o@softdebut.com; Wed, 25 Jan 2012 15:16:05 +0700\r\nFrom:\r\nSubject: test1\r\nTo: chanamat.o@softdebut.com\r\nX-Mailer: CommuniGate Pro WebUser v5.3.15\r\nDate: Wed, 25 Jan 2012 15:16:05 +0700\r\nMessage-ID: \r\nMIME-Version: 1.0\r\nCont
15:16:20.177 5 SMTP-037767(softdebut.com) inp: 250 13167950 message accepted for delivery
15:16:20.177 2 SMTP-037767(softdebut.com) [15138018] sent to [61.47.43.194]:25, got:250 13167950 message accepted for delivery
15:16:20.177 5 SMTP-037767(softdebut.com) out: QUIT\r\n
15:16:20.178 5 SMTP-037767(softdebut.com) inp: 221 ast1.softdebut.com qmail SMTP closing connection
15:16:20.178 4 SMTP-037767(softdebut.com) closing connection
15:16:20.178 4 SMTP-037767(softdebut.com) releasing stream
15:16:19.871 5 SMTP-037767(softdebut.com) processing
15:16:20.160 5 SMTP-037767(softdebut.com) 2 relay(s) found:ast2.softdebut.com ast1.softdebut.com
15:16:20.160 4 SMTP-037767(softdebut.com) connecting [61.47.43.197]:65535 -> [61.47.43.194]:25
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 220 ast1.softdebut.com ESMTP qmail 5.4.2 is glad to see you!
15:16:20.161 4 SMTP-037767(softdebut.com) connected to ast1.softdebut.com [61.47.43.194]:25, ESMTP
15:16:20.161 5 SMTP-037767(softdebut.com) out: EHLO debutmail.com\r\n
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ast1.softdebut.com we trust you debutmail.com
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-DSN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-SIZE 41943040
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ETRN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-TURN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-ATRN
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-NO-SOLICITING
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-8BITMIME
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-HELP
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250-PIPELINING
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 EHLO
15:16:20.161 4 SMTP-037767(softdebut.com) Connected. DSN SIZE SOLICIT
15:16:20.161 4 SMTP-037767(softdebut.com) [15138018] sending
15:16:20.161 5 SMTP-037767(softdebut.com) out: MAIL FROM:
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 chanamat.o@debutmail.com sender accepted
15:16:20.161 5 SMTP-037767(softdebut.com) out: RCPT TO:
15:16:20.161 5 SMTP-037767(softdebut.com) inp: 250 chanamat.o@softdebut.com accepting mail from a client address
15:16:20.161 5 SMTP-037767(softdebut.com) out: DATA\r\n
15:16:20.162 5 SMTP-037767(softdebut.com) inp: 354 Enter mail, end with "." on a line by itself
15:16:20.162 5 SMTP-037767(softdebut.com) out: Received: from [58.9.225.207] (account chanamat.o@debutmail.com)\r\n by debutmail.com (CommuniGate Pro WEBUSER 5.3.15)\r\n with HTTP id 15138018 for chanamat.o@softdebut.com; Wed, 25 Jan 2012 15:16:05 +0700\r\nFrom:
15:16:20.177 5 SMTP-037767(softdebut.com) inp: 250 13167950 message accepted for delivery
15:16:20.177 2 SMTP-037767(softdebut.com) [15138018] sent to [61.47.43.194]:25, got:250 13167950 message accepted for delivery
15:16:20.177 5 SMTP-037767(softdebut.com) out: QUIT\r\n
15:16:20.178 5 SMTP-037767(softdebut.com) inp: 221 ast1.softdebut.com qmail SMTP closing connection
15:16:20.178 4 SMTP-037767(softdebut.com) closing connection
15:16:20.178 4 SMTP-037767(softdebut.com) releasing stream
วันพุธที่ 27 เมษายน พ.ศ. 2554
MSC (Microsoft System Console)
| Certificates | certmgr.msc |
| Indexing Service | ciadv.msc |
| Computer Management | compmgmt.msc |
| Device Manager | devmgmt.msc |
| Disk Defragmenter | dfrg.msc |
| Disk Management | diskmgmt.msc |
| Event Viewer | eventvwr.msc |
| Shared Folders | fsmgmt.msc |
| Group Policy | gpedit.msc |
| Local Users and Groups | lusrmgr.msc |
| Removable Storage | ntmsmgr.msc |
| Removable Storage Operator Requests | ntmsoprq.msc |
| Performance | perfmon.msc |
| Resultant Set of Policy | rsop.msc |
| Local Security Settings | secpol.msc |
| Services | services.msc |
| Windows Management Infrastructure (WMI) | wmimgmt.msc |
| Component Services | comexp.msc |
วันจันทร์ที่ 11 เมษายน พ.ศ. 2554
Unicast Mode
NLB สามารถทำใช้งานได้ใน uncast หรือ multicast โหมดโดยการกำหนด MAC Address ให้กับมัน ปกติเร้าเตอร์จะทำการส่งเพคเกจออกโดยใช้ MAC ของ VIPและ MAC
ของ VIP จะเหมือนกันทั้งหมด เพราะ ทุกแพคเกจที่ส่งออกไปปลายทางของ VIP จำเป็นที่จะต้องเป็น
สมาชิกของกลุ่ม NLB
โดยค่าปกติแล้ว NLB จะถูกตั้งค่าเป็น unicast modeโดยในโหมดนี้ทุก NLB จะถูกแทนที่ด้วย
MAC ในแต่และ LAN Adapter เป็นค่า NLB MAC Address เมื่อ NLB adapter
มี MAC ค่าเดียวกันแล้วทุกแพคเกจที่ถูกส่งเข้ามาหาจะถูกส่งไปหาทุกสมาชิกใน NLB อย่างไรก็ดีจะมีปัญหา
เมื่อมีการ config สมาชิก NLB ใน Switch ตัวเดียวกันเพราะมีการใช้งาน MAC ค่าเดียวกันใน
port อื่นๆ
NLB แก้ปัญหานี้โดยทำการ masking Cluster MAC (ทำการซ่อน MAC เอาไว้) ปกติแล้ว switch จะทำมีกระบวนการเรียนรู้ MAC Address โดยมองตรวจสอบจาก Ethernet Frame Header. NLB จะทำการ สร้าง MAC Address หลอกขึ้นมาและกำหนดให้แต่ละ NLB Adapter โดยที่ MAC Address หลอกที่ถูกสร้างขึ้นจะมีส่วนที่แตกต่างกันตามแต่ละ Host ID
ตัวอย่างเช่น host ID number 1 has the bogus MAC address 02-01-ac-10-00-01, host ID number 2 has the bogus MAC address 02-02-ac-10-00-01, host ID number 3 has the bogus MAC address 02-03-ac-10-00-01, and so on
ทำให้เราสามารถที่เชื่อมต่อไปที่ Switch โดยใช้ MAC Address หลอก ที่สร้างขึ้นมาได้ทำให้แก้ปัญหาการชนกันของ MAC ADDRESS ใน switch ได้และเมื่อมีการส่ง Packet จาก Router ไปที่ MAC Address Clusster แล้ว Switch ไม่พบ MAC Address ดังกล่าวมันจะทำการส่งเพจเกจไปทุก port ของ switch
ซึ่งเร้าเตอร์ไม่ได้ค้นหา Server ปลายทางแบบ Switch โดยเมื่อเร้าเตอร์ทำการส่ง ARP request เพื่อตรวจสอบ NLB MAC Address ของ VIP ออกไป ARP header จะได้รับ NLB MAC Address (Cluster MAC Address) ไม่ใช่ MAC หลอกทำให้ในการคุยกับเร้าเตอร์ Server จะมี VIPกับ Cluste MAC ส่งไปหาเร้าเตอร์ผ่าน
ARP request (Switch จะไม่รู้เพราะตรวจสอบจาก Ethernet Frame Header) และเมื่อเร้าเตอร์ต้องการจะคุย
กับ Server จะทำการส่ง Packet กลับมาให้ Switch ซึ่งภายในEthernet Frame Header จะเป็น Cluster MAC Address ทำให้ Switch ไม่รู้จักจึงทำการส่งข้อมูลไปทุก Port เป็นแบบนี้ไปเรื่อยๆ
http://www.isaserver.org/tutorials/basicnlbpart1.html
http://www.isaserver.org/articles/basicnlbpart2.html
ของ VIP จะเหมือนกันทั้งหมด เพราะ ทุกแพคเกจที่ส่งออกไปปลายทางของ VIP จำเป็นที่จะต้องเป็น
สมาชิกของกลุ่ม NLB
โดยค่าปกติแล้ว NLB จะถูกตั้งค่าเป็น unicast modeโดยในโหมดนี้ทุก NLB จะถูกแทนที่ด้วย
MAC ในแต่และ LAN Adapter เป็นค่า NLB MAC Address เมื่อ NLB adapter
มี MAC ค่าเดียวกันแล้วทุกแพคเกจที่ถูกส่งเข้ามาหาจะถูกส่งไปหาทุกสมาชิกใน NLB อย่างไรก็ดีจะมีปัญหา
เมื่อมีการ config สมาชิก NLB ใน Switch ตัวเดียวกันเพราะมีการใช้งาน MAC ค่าเดียวกันใน
port อื่นๆ
NLB แก้ปัญหานี้โดยทำการ masking Cluster MAC (ทำการซ่อน MAC เอาไว้) ปกติแล้ว switch จะทำมีกระบวนการเรียนรู้ MAC Address โดยมองตรวจสอบจาก Ethernet Frame Header. NLB จะทำการ สร้าง MAC Address หลอกขึ้นมาและกำหนดให้แต่ละ NLB Adapter โดยที่ MAC Address หลอกที่ถูกสร้างขึ้นจะมีส่วนที่แตกต่างกันตามแต่ละ Host ID
ตัวอย่างเช่น host ID number 1 has the bogus MAC address 02-01-ac-10-00-01, host ID number 2 has the bogus MAC address 02-02-ac-10-00-01, host ID number 3 has the bogus MAC address 02-03-ac-10-00-01, and so on
ทำให้เราสามารถที่เชื่อมต่อไปที่ Switch โดยใช้ MAC Address หลอก ที่สร้างขึ้นมาได้ทำให้แก้ปัญหาการชนกันของ MAC ADDRESS ใน switch ได้และเมื่อมีการส่ง Packet จาก Router ไปที่ MAC Address Clusster แล้ว Switch ไม่พบ MAC Address ดังกล่าวมันจะทำการส่งเพจเกจไปทุก port ของ switch
ซึ่งเร้าเตอร์ไม่ได้ค้นหา Server ปลายทางแบบ Switch โดยเมื่อเร้าเตอร์ทำการส่ง ARP request เพื่อตรวจสอบ NLB MAC Address ของ VIP ออกไป ARP header จะได้รับ NLB MAC Address (Cluster MAC Address) ไม่ใช่ MAC หลอกทำให้ในการคุยกับเร้าเตอร์ Server จะมี VIPกับ Cluste MAC ส่งไปหาเร้าเตอร์ผ่าน
ARP request (Switch จะไม่รู้เพราะตรวจสอบจาก Ethernet Frame Header) และเมื่อเร้าเตอร์ต้องการจะคุย
กับ Server จะทำการส่ง Packet กลับมาให้ Switch ซึ่งภายในEthernet Frame Header จะเป็น Cluster MAC Address ทำให้ Switch ไม่รู้จักจึงทำการส่งข้อมูลไปทุก Port เป็นแบบนี้ไปเรื่อยๆ
http://www.isaserver.org/tutorials/basicnlbpart1.html
http://www.isaserver.org/articles/basicnlbpart2.html
สมัครสมาชิก:
บทความ (Atom)