I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine
Yes and that's exactly what's happening, FTFA:
They determined Cricket was intercepting and blocking STARTTLS on port 25
(port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp).
Absolutely correct, with the exception that smtps is long deprecated and only port 587 (submission) should be used for the submission of email.
I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
This is fairly normal. Many ISPs simply block outbound port 25 rather than filtering out STARTTLS. Personally I think that's the better approach for these ISPs (to just block the port alltogether), but either way this article is a bunch of crap written by someone who can't even set his email client to connect to the right port.
Exactly, it would actually make the situation worse. Consider that when you call someone you may ask, "what time is it there"? What you (usually) really want to know is what part of the day / night is it. Making everyone live under GMT would answer the first question but not give you any useful information to what you really want to know and just make it harder to find out.
I wonder if those in the "DST helps to save energy" camp took into account the significant amount of energy used by computers around the world to account for DST in time-zone conversions?
We don't celebrate DST in Tucson, but all my distant suppliers etc. do, so I have to adjust my mental clock to deal with their different offsets.
Try living in New Zealand and having clients in California. Since NZ is in the southern hemisphere our summer is during your winter and vice-versa, so during our summer (and your winter) we are three hours apart* from US/Pacific, but during our winter and your summer we are five hours apart and in-between there is about a month where DST overlaps in both fall and spring and we are four hours apart.
* Actually 21 hours, but it's easier to think of it as us being a day ahead and three hours behind.
Right, chickens have both white and dark meat. The white meat comes from the breasts and the dark meat comes from the thighs, legs and wings. The white meat is known to be healthier, while the dark meat contains more flavour. McDonalds is simply saying that the old nuggets had both white and dark meat while these new ones are only white meat. It's a play to try to say they are healthier now.
Of course the health benefits of this switch when the nugget is battered and then deep fried either way are debatable. It would be more admirable if they switched to white meat, a wholemeal batter and baked them instead of deep frying, but good luck getting them to do that.
... if the service (as I suspect) routes your traffic to a given IP from another IP in the same country, this could backfire as some services are actually better from outside the country, some examples:
mlb.com (and other sports streaming services) which applies blackout restrictions if you're trying to watch games from inside the US or its territories. Watching baseball games from New Zealand, however, has no blackout restrictions.
Purchasing goods from sites that apply sales tax if you're browsing from the same country that the site is based in (more far fetched, they usually apply sales tax according to shipping destination).
In any case why revoke them, just replace them with a new, free cert.
What is the point in replacing a cert if you aren't going to revoke the old one? Replacing the cert doesn't solve anything if the old one is still valid and usable.
I didn't catch that bit of the announcement. It'll be interesting to see what actually happens in that regard, then. At any rate I think it will probably be a minor adaptation to get the sources from git instead of SRPMs and it should make tracking changes in the sources easier. Also it may be possible that the CentOS project itself will continue to release the sources which would be almost identical to the RHEL ones anyways.
No, Oracle rips off RHEL just like CentOS SL and others do, but Oracle doesn't add value to RHEL, instead they compete with RedHat and with less expensive you get a fourth party to the sources (after they have gone through the original project, then Fedora, then RHEL) trying to provide support for something they only cloned off of someone else, whereas RedHat are pretty much 2nd party to the sources and have a lot more knowledge on them, so you get what you pay for in terms of support or with Oracle even less than what you paid for.
Cent tends to lack security updates after RHEL releases,
CentOS has been pretty onto it as of late, 6.5 only took about a week after RedHat released (iirc) and they are very quick on updates, usually the same or next day. Also now that the devs are getting paid (by RedHat) for their time it should be even faster.
Scientific is dependent on government funding but gets security updates in what could be called a timely manner compared to Cent.
There have been times that SL has beaten CentOS and times that CentOS has beaten SL.
If this means Cent gets security updates in a timely manner after RHEL version bumps then it is a good thing.
My understanding form the original CentOS announcement is that CentOS will still have to build their own binaries from the publicly available sources (RedHAT won't allow them to use RHEL binaries) so that part won't change, but as I said above, the devs are now paid for their time which will make a huge difference, plus I imagine that they will have better access to RedHat for issues with rebuilding the sources. RHEL is not self-building and as such has always had difficulties trying to get it to build, especially after a new major release. Often times you can look at the sources and wonder how RedHat managed to get it to build. Now they should have better access to get help with these issues instead of having to figure it out for themselves.
Kind of, I think it's more like RedHat is targeting a certain kind of customer with their business. They want to get the big spending Enterprise customers who are willing to fork out a lot of money for a product with major backing behind it, RHEL is one such product but there are other companies that also sell enterprise Linux distros, not to mention all the other OSes out there that RedHat has to compete with.
They don't loose money on CentOS users because CentOS users generally do not fall into their targeted customer base, but many CentOS users have influence over that targeted customer base and if they are happy with CentOS then when they get the chance to make a recommendation that will be for RHEL. RedHat realizes this and so as a consequence they know that CentOS actually *helps* their business in the long run. I think that by supporting CentOS on a more official basis as they are now doing they can help to solidify that the recommendation really does point to RedHat when it comes around as well as giving something back to the community that has worked to actually help them for all these years. Don't discount the side benefit of being able to excersize a bit of control over CentOS either (although RedHat's track record with other projects that they control is that they usually are fairly benevolent and let the project do what they want within reason).
No, it's perfectly fine for switching between RHEL and CentOS as CentOS is fully binary compatible with RHEL (that is one of the project goals) so if it doesn't work for compatibility reasons then it is a CentOS bug.
SL is not quite as strict on compatibility, but it should still work fine even though it's unsupported.
Oracle Linux even provides a utility to switch from other EL distros to Oracle and all it does is switch the -release package and a couple other key packages over (although I don't recommend Oracle Linux).
What is usually not supported (and not a good idea) is to try to use yum to upgrade from one major release to another, switching from one variant of EL to another on the same version is generally just fine.
There is a major difference between chat, email, etc in ALL CAPS and filling out a form in ALL CAPS. I often times fill out forms in all caps due to the fact that many are scanned and OCR tends to work better with caps than lowercase letters. This is especially true for hand-filled forms. In fact I have filled out forms that *explicitly ask* you to use all caps when filling them in.
Even on older cars the default state of the clutch is engaged. Most cars have a hydrolic clutch which can fail due to a burst hose or failed seal, etc. Other cars have a manual clutch which is basically just a cable that can fail from fatigue (the clutch cable breaks). In either of these cases if the clutch fails it is left *engaged* which means that you cannot release it. The only case of a clutch failing and not leaving the engine engaged is when the clutch plate itself is worn out and then you get what is known as the "clutch slipping" (and eventually not engaging at all).
It's not as bad as it may seem. With disk speeds up to 15,000 rpm and higher areal densities means that data can be pulled off pretty fast. If HDD manufacturers were to implement technologies such as multi-track disk heads then IO speed could increase a lot more and would be limited mainly by seek times. What a lot of companies are doing nowadays is using 2" (laptop) drives in their servers, packing a lot more drives into the space, which means more smaller disks and therefore less to rebuild in the event of a failure as well as a lot more disk heads to increase IO even further (and help a lot with those nasty seek speeds when trying to access data in 200 different files at once). What we're really left with as the limiting factor is the electronics and if all else fails that can be dealt with by multiple parallel channels (first we had PATA, now SATA, anyone for PSATA?).
So yeah, Disk IO is a bit of a problem now but there really is quite a lot that can be done to eliminate that issue.
Linode uses Xen and there's nothing wrong with that. In fact, what virtualization backend is in use is probably not of real concern to most people, and just as many prefer Xen as KVM (I think that Xen is arguably better for VPS-style hosting).
Exactly what driver have you found that will run on RHEL but not on the same version of CentOS? CentOS is fully package and binary compatible with RHEL and they take great pains to make it so so I would be very surprised if there is any RHEL package or driver that won't work with CentOS just as well, or vice-versa for that matter.
There is, it's called TLS (which is the same technology that modern SSL uses, so the same encryption used by https) and is implemented by STARTTLS. It establishes a secure connection between two email servers and sends the email off secure between them and it suffers from the following pitfalls:
1. It only encrypts the data stream between two email servers that support it, or between the email server and client. 2. The email is still decrypted and stored plaintext in the queue of any given email server, and is subject to reading by the admin of any server in the chain. 3. It relies on each email server in the chain supporting TLS (most do, but there are still old ones out there that do not and the ones that do will generally fall back to unencrypted email if need be to communicate with an older server). 4. While it is possible to purchase and verify certificates between two servers no one does because a lot of servers use self-signed or invalid certificates, so verifying them would simply cause a lot of email communications to fail, thus it is susceptible to a man in the middle attack.
The best way to secure your emails has been and still is to use PGP (and before someone says it, that includes GPG), which secures the email end-to-end and so it is not subject to any snooping or attack in between with the exception that the envelope sender, recipient, and email headers still have to be sent in plain text. Of course this requires that both the originator and recipient of the email both have PGP support installed on their email clients and it requires the maintenance of PGP keys be done by the end-user, so it is more complicated than the vast majority of email users are willing to commit to.
Postfix 2.8.x for the MTA (2.8 has the new postscreen feature which is great to help with SPAM control) Dovecot for IMAP POP3 as well as for SASL AUTH Roudcube or Squirrlmail (take your pick) for webmail PostgreSQL or MySQL for database backend Spamassassin to catch what SPAM is missed by postscreen. ClamAV to scan for viruses Amavisd-new to interface psotfix to spamassassin and clamav PostfixAdmin for managing your domains and accounts from the web.
Use virtual domains with postfix "virtual" for the delivery agent, use maildir format for your mailboxes (mailbox path needs to end in "/"). Make sure and use the submission port (587) for your outbound emails, not the SMTP port (25) which should only be for inbound emails. Don't use SMTPS (which works over port 465) unless you have to support a really old email client that doesn't support STARTTLS (which works over the submission and smtp ports). Stitch all the pieces together and if done right you'll have a great email system like all the pros use.
If you need help come into #postfix on freenode IRC network.
Slashdot Mirror
I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine
Yes and that's exactly what's happening, FTFA:
They determined Cricket was intercepting and blocking STARTTLS on port 25
(port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp).
Absolutely correct, with the exception that smtps is long deprecated and only port 587 (submission) should be used for the submission of email.
I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
This is fairly normal. Many ISPs simply block outbound port 25 rather than filtering out STARTTLS. Personally I think that's the better approach for these ISPs (to just block the port alltogether), but either way this article is a bunch of crap written by someone who can't even set his email client to connect to the right port.
Exactly, it would actually make the situation worse. Consider that when you call someone you may ask, "what time is it there"? What you (usually) really want to know is what part of the day / night is it. Making everyone live under GMT would answer the first question but not give you any useful information to what you really want to know and just make it harder to find out.
I wonder if those in the "DST helps to save energy" camp took into account the significant amount of energy used by computers around the world to account for DST in time-zone conversions?
We don't celebrate DST in Tucson, but all my distant suppliers etc. do, so I have to adjust my mental clock to deal with their different offsets.
Try living in New Zealand and having clients in California. Since NZ is in the southern hemisphere our summer is during your winter and vice-versa, so during our summer (and your winter) we are three hours apart* from US/Pacific, but during our winter and your summer we are five hours apart and in-between there is about a month where DST overlaps in both fall and spring and we are four hours apart.
* Actually 21 hours, but it's easier to think of it as us being a day ahead and three hours behind.
Right, chickens have both white and dark meat. The white meat comes from the breasts and the dark meat comes from the thighs, legs and wings. The white meat is known to be healthier, while the dark meat contains more flavour. McDonalds is simply saying that the old nuggets had both white and dark meat while these new ones are only white meat. It's a play to try to say they are healthier now.
Of course the health benefits of this switch when the nugget is battered and then deep fried either way are debatable. It would be more admirable if they switched to white meat, a wholemeal batter and baked them instead of deep frying, but good luck getting them to do that.
... if the service (as I suspect) routes your traffic to a given IP from another IP in the same country, this could backfire as some services are actually better from outside the country, some examples:
mlb.com (and other sports streaming services) which applies blackout restrictions if you're trying to watch games from inside the US or its territories. Watching baseball games from New Zealand, however, has no blackout restrictions.
Purchasing goods from sites that apply sales tax if you're browsing from the same country that the site is based in (more far fetched, they usually apply sales tax according to shipping destination).
In any case why revoke them, just replace them with a new, free cert.
What is the point in replacing a cert if you aren't going to revoke the old one? Replacing the cert doesn't solve anything if the old one is still valid and usable.
I didn't catch that bit of the announcement. It'll be interesting to see what actually happens in that regard, then. At any rate I think it will probably be a minor adaptation to get the sources from git instead of SRPMs and it should make tracking changes in the sources easier. Also it may be possible that the CentOS project itself will continue to release the sources which would be almost identical to the RHEL ones anyways.
Oracle is a less expensive RHEL,
No, Oracle rips off RHEL just like CentOS SL and others do, but Oracle doesn't add value to RHEL, instead they compete with RedHat and with less expensive you get a fourth party to the sources (after they have gone through the original project, then Fedora, then RHEL) trying to provide support for something they only cloned off of someone else, whereas RedHat are pretty much 2nd party to the sources and have a lot more knowledge on them, so you get what you pay for in terms of support or with Oracle even less than what you paid for.
Cent tends to lack security updates after RHEL releases,
CentOS has been pretty onto it as of late, 6.5 only took about a week after RedHat released (iirc) and they are very quick on updates, usually the same or next day. Also now that the devs are getting paid (by RedHat) for their time it should be even faster.
Scientific is dependent on government funding but gets security updates in what could be called a timely manner compared to Cent.
There have been times that SL has beaten CentOS and times that CentOS has beaten SL.
If this means Cent gets security updates in a timely manner after RHEL version bumps then it is a good thing.
My understanding form the original CentOS announcement is that CentOS will still have to build their own binaries from the publicly available sources (RedHAT won't allow them to use RHEL binaries) so that part won't change, but as I said above, the devs are now paid for their time which will make a huge difference, plus I imagine that they will have better access to RedHat for issues with rebuilding the sources. RHEL is not self-building and as such has always had difficulties trying to get it to build, especially after a new major release. Often times you can look at the sources and wonder how RedHat managed to get it to build. Now they should have better access to get help with these issues instead of having to figure it out for themselves.
I honestly don't think that was ever a concern. The CentOS community tends to have a dislike for Oracle almost as much as RedHat does.
Kind of, I think it's more like RedHat is targeting a certain kind of customer with their business. They want to get the big spending Enterprise customers who are willing to fork out a lot of money for a product with major backing behind it, RHEL is one such product but there are other companies that also sell enterprise Linux distros, not to mention all the other OSes out there that RedHat has to compete with.
They don't loose money on CentOS users because CentOS users generally do not fall into their targeted customer base, but many CentOS users have influence over that targeted customer base and if they are happy with CentOS then when they get the chance to make a recommendation that will be for RHEL. RedHat realizes this and so as a consequence they know that CentOS actually *helps* their business in the long run. I think that by supporting CentOS on a more official basis as they are now doing they can help to solidify that the recommendation really does point to RedHat when it comes around as well as giving something back to the community that has worked to actually help them for all these years. Don't discount the side benefit of being able to excersize a bit of control over CentOS either (although RedHat's track record with other projects that they control is that they usually are fairly benevolent and let the project do what they want within reason).
No, it's perfectly fine for switching between RHEL and CentOS as CentOS is fully binary compatible with RHEL (that is one of the project goals) so if it doesn't work for compatibility reasons then it is a CentOS bug.
SL is not quite as strict on compatibility, but it should still work fine even though it's unsupported.
Oracle Linux even provides a utility to switch from other EL distros to Oracle and all it does is switch the -release package and a couple other key packages over (although I don't recommend Oracle Linux).
What is usually not supported (and not a good idea) is to try to use yum to upgrade from one major release to another, switching from one variant of EL to another on the same version is generally just fine.
It's very easy to do. I've done the reverse (RHEL to CentOS) on a few occasions. It is generally as simple as installing a single -release rpm.
There is a major difference between chat, email, etc in ALL CAPS and filling out a form in ALL CAPS. I often times fill out forms in all caps due to the fact that many are scanned and OCR tends to work better with caps than lowercase letters. This is especially true for hand-filled forms. In fact I have filled out forms that *explicitly ask* you to use all caps when filling them in.
hrmmmm, makes you wonder if it was planned that way.
If it was 192.168.0.0/16 that's fine as it is reserved by RFC1918 for private use.
Even on older cars the default state of the clutch is engaged. Most cars have a hydrolic clutch which can fail due to a burst hose or failed seal, etc. Other cars have a manual clutch which is basically just a cable that can fail from fatigue (the clutch cable breaks). In either of these cases if the clutch fails it is left *engaged* which means that you cannot release it. The only case of a clutch failing and not leaving the engine engaged is when the clutch plate itself is worn out and then you get what is known as the "clutch slipping" (and eventually not engaging at all).
That's actually known as a "metric pint", and that's generally what you get when you order a pint in many countries that are on metric.
More and more cellphones today have batteries that cannot be removed by the consumer, though.
Which is why it's very important to monitor your disks using the tools and the SMART data on the disks themselves.
It's not as bad as it may seem. With disk speeds up to 15,000 rpm and higher areal densities means that data can be pulled off pretty fast. If HDD manufacturers were to implement technologies such as multi-track disk heads then IO speed could increase a lot more and would be limited mainly by seek times. What a lot of companies are doing nowadays is using 2" (laptop) drives in their servers, packing a lot more drives into the space, which means more smaller disks and therefore less to rebuild in the event of a failure as well as a lot more disk heads to increase IO even further (and help a lot with those nasty seek speeds when trying to access data in 200 different files at once). What we're really left with as the limiting factor is the electronics and if all else fails that can be dealt with by multiple parallel channels (first we had PATA, now SATA, anyone for PSATA?).
So yeah, Disk IO is a bit of a problem now but there really is quite a lot that can be done to eliminate that issue.
Linode uses Xen and there's nothing wrong with that. In fact, what virtualization backend is in use is probably not of real concern to most people, and just as many prefer Xen as KVM (I think that Xen is arguably better for VPS-style hosting).
Exactly what driver have you found that will run on RHEL but not on the same version of CentOS? CentOS is fully package and binary compatible with RHEL and they take great pains to make it so so I would be very surprised if there is any RHEL package or driver that won't work with CentOS just as well, or vice-versa for that matter.
There is, it's called TLS (which is the same technology that modern SSL uses, so the same encryption used by https) and is implemented by STARTTLS. It establishes a secure connection between two email servers and sends the email off secure between them and it suffers from the following pitfalls:
1. It only encrypts the data stream between two email servers that support it, or between the email server and client.
2. The email is still decrypted and stored plaintext in the queue of any given email server, and is subject to reading by the admin of any server in the chain.
3. It relies on each email server in the chain supporting TLS (most do, but there are still old ones out there that do not and the ones that do will generally fall back to unencrypted email if need be to communicate with an older server).
4. While it is possible to purchase and verify certificates between two servers no one does because a lot of servers use self-signed or invalid certificates, so verifying them would simply cause a lot of email communications to fail, thus it is susceptible to a man in the middle attack.
The best way to secure your emails has been and still is to use PGP (and before someone says it, that includes GPG), which secures the email end-to-end and so it is not subject to any snooping or attack in between with the exception that the envelope sender, recipient, and email headers still have to be sent in plain text. Of course this requires that both the originator and recipient of the email both have PGP support installed on their email clients and it requires the maintenance of PGP keys be done by the end-user, so it is more complicated than the vast majority of email users are willing to commit to.
Postfix 2.8.x for the MTA (2.8 has the new postscreen feature which is great to help with SPAM control)
Dovecot for IMAP POP3 as well as for SASL AUTH
Roudcube or Squirrlmail (take your pick) for webmail
PostgreSQL or MySQL for database backend
Spamassassin to catch what SPAM is missed by postscreen.
ClamAV to scan for viruses
Amavisd-new to interface psotfix to spamassassin and clamav
PostfixAdmin for managing your domains and accounts from the web.
Use virtual domains with postfix "virtual" for the delivery agent, use maildir format for your mailboxes (mailbox path needs to end in "/"). Make sure and use the submission port (587) for your outbound emails, not the SMTP port (25) which should only be for inbound emails. Don't use SMTPS (which works over port 465) unless you have to support a really old email client that doesn't support STARTTLS (which works over the submission and smtp ports). Stitch all the pieces together and if done right you'll have a great email system like all the pros use.
If you need help come into #postfix on freenode IRC network.