ec2-manage-snapshots http://bit.ly/9MO76l

php ec2-delete-old-snapshots.php -v vol-3ff83856 -o 0

Will try to bulk delete for vol-3ff83856 older than 2010/01/30 06:55:35

Fatal error: Class ‘XsltProcessor’ not found in
/usr/share/php/Amazon/EC2/Client.php on line 2584

As for requirement #4 (making sure the cloud e-mail server is not RBL listed), the proper solution is for the cloud provider to offer dedicated e-mail cloud servers that do not allow customer code on them, and to manage those cloud servers the way good business ISPs handle their mail servers. This is similar to how many cloud providers (such as the pioneer Akamai) offers dedicated cloud web servers for scalable high bandwidth non-programmatic content such as downloads.

It is the policy of rackspace that unauthenticated email sent from this IP address should be sent out only via the designated outbound mail server allocated to rackspace customers. To find the hostname of the correct mail server to use, customers should consult the original signup documentation or contact rackspace Technical Support.”

I have made several requests on providing information on their outbound mail server. All I need is a single email address originating from my server notifying me and my users. I am frustrated. What is the point of a cloud server hosting? What are we supposed to host on a cloud server? only wikis or 90’s era website? If these functionality are absent from cloud then I do not thing that the cloud business model will succeed.

I would like to offer some additional details from the GoGrid standpoint. For starters, we have always had the policy that people request that port 25 be opened and is closed from the getgo. While this extra step is, I agree, a bit of a hassle, the unblocking usually doesn’t take long to do. Because it is extremely easy to set up (and tear down) servers, many “spam shops” have looked at the Cloud as a great way to set up on-the-fly spamming environments. By requiring this extra step, we have dramatically reduced the number of abuses within the GoGrid environment, thus making it “cleaner” for other users of the service. Users simply have to open a Support Case requesting that port 25 be unblocked and the change is done quickly.

However, our prevention methods don’t stop there. One of the issues with other providers (AWS, for example) is that frequently the IP address that you are allocated is often from a pool of public IP resources. What that means is that you “could” run into the case where an IP address you are given was used in the past by a spammer, and thus, since you now “lease” that IP, your service could be listed in an RBL. It is possible to get off those lists, but it does take a bit of legwork. So, part of the way that GoGrid helps you avoid that type of situation is that fact that you are given a block of 16 static, contiguous IP addresses from the beginning. You only need to fill out an “IP Justification Form” should you want more beyond the initial 16. More information on that is here. This, too has helped us reduce the number of occurrences of IP addresses being blacklisted. When you get your initial block, those 16 IP addresses are essentially reserved for you to use and “protect.”

Lastly, as you mention at the end of your post is to move to “physical hosting.” This too, can be accomplished easily with GoGrid using a Hybrid Hosting solution where you have your web/app servers in the Cloud, with GoGrid, and your back-end infrastructure (e.g., DBs or in this case perhaps your sendmail server) hosted on physical hardware with ServePath, all privately connected via a dedicated, physical LAN connection. Just another option I thought I would throw out there.

True, a spammer could have gone through the process of creating an account, requesting that port 25 be unblocked, used the service maliciously, then cancelled the account (or had it shut down). Then there is a slim possibility that a new user could be assigned the same block, but the odds of that happening are pretty low.

AWS recently implemented a similar procedure for SMTP limiting on new accounts. Read the thread here for more information. All cloud providers should recognize that this is an issue and take steps to prevent email abuse.

Regardless, I think your points that you detail in your post are good to have written out. We (at GoGrid) will always work with our customers to help prevent abuse and blacklisting as best as we can.

Thank you,
Michael Sheehan
Technology Evangelist for GoGrid

As a final (possibly stupid question). Master-master doesn’t help you scale beyond the capabilities of a single server, but only provides a fallback if the primary server fails, correct?

Master-slave at least increases the read performance by every slave you add, but the write performance it still limited to the slowest machine on the cluster, as all writes need to propagate to each of the slaves too, right?

Please excuse my stupidity, I’m new to MySQL scaling, even though I’ve been tasked to handle it… lol