DigitalOcean credit expiration policy changed

Yesterday I received a strange email from DigitalOcean: Honestly, I don’t think it’s a good idea at all. Basically they want to change the expiration policy of ALL new and issued credits. You will have a month to use all your remaining credits, or it will be expired. It would be much better if they only add expiration for newly issued credits. As in, older credits will be kept intact. By the way, after a small complain, DigitalOcean gave me $20 credits. That was much better than I could hope for.

Update on DigitalOcean’s connectivity issue with 4.2.2.2

This is the followup post of the following report: Seems that DigitalOcean haven’t fixed anything yet. 8 days since my last post. This page https://status.digitalocean.com/ show no information regarding this issue. Other people also reported similar behavior. Come on, do something DigitalOcean! Here is the latest benchmarks from my server to 3 different DNS provider: 4.2.2.2 (Level3), 8.8.8.8 (Google) and 208.67.222.222 (OpenDNS). I issued 10 dig queries for google.com, each of them 10 seconds apart. 6/10 queries sent to 4.2.2.2 are timed out. None of them happen for 8.8.8.8 and 208.67.222.222 tuananh@codepie:~$ for i in {1..10}; do dig google.com @4.2.2.2 | grep ‘connection timed out’; sleep 10; done; ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached tuananh@codepie:~$ for i in {1..10}; do dig google.com @8.8.8.8 | grep ‘connection timed out’; sleep 10; done; tuananh@codepie:~$ for i in {1..10}; do dig google.com @208.67.222.222 | grep ‘connection timed out’; sleep 10; done;

DigitalOcean droplets (at least for NYC2 region) are having trouble connecting to 4.2.2.2

I noticed a noticeable degrade in network performance in my droplets. It took forever to open a connection. It happened from last week I guess. Restart server does not help. I though it’s just temporary. However today I noticed that, DigitalOcean by default assign 2 DNS servers for every droplet in NYC2 region: nameserver 4.2.2.2 nameserver 8.8.8.8 Here is the result for ping from my droplet to both servers: tuananh@codepie:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=46 time=13.8 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=46 time=13.8 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=46 time=13.8 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=6 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=7 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=8 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=9 ttl=46 time=13.7 ms 64 bytes from 8.8.8.8: icmp_req=10 ttl=46 time=13.7 ms ^C — 8.8.8.8 ping statistics — 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 13.705/13.774/13.883/0.147 ms tuananh@codepie:~$ ping 4.2.2.2 PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. ^C — 4.2.2.2 ping statistics — 167 packets transmitted, 0 received, 100% packet loss, time 167318ms Performing dig returns similar problem: tuananh@codepie:~$ dig google.com @4.2.2.2 ; < > DiG 9.8.1-P1 < > google.com @4.2.2.2 ;; global options: +cmd ;; connection timed out; no servers could be reached As you can see, somehow my droplet won’t be able to connect to 4.2.2.2. A simple switch to 8.8.8.8 as main DNS resolver and thing’s back to normal.

My perfect setup (hint: CloudFlare, DigitalOcean, StartSSL, nginx, apache and private servers)

My situation is a little bit complicated: I have a powerful server completely under firewall (no inbound connection from outside) I want to run several websites (mostly blogs) I want to support SSL At the beginning, DigitalOcean is the best choice. I will have my own server, host unlimited websites, have full control and DigitalOcean is blazingly fast. I selected the smallest plan with 20G SSD and 512MB RAM. It would be more than enough for my blogs. I installed my own LAMP stack, get my own SSL certificate from StartSSL (you should get your own, too. It’s free!) Everything is fine until after several week. My server crashed every few hours. There are lots of requests coming for wp-comment-post.php, xmlrpc.php and wp-login.php. Unfortunately I can’t disabled them. Apache’s mod_security and mod_qos couldn’t help much. I have to write a temporary cron script to restart apache2 daemon whenever server load bigger than 20. Doesn’t improved much. My server still crash. There come nginx. Not work. Then CloudFlare. The same Until I decided to use my dedicated server to handle requests. Then it works!, not perfectly but we will be there later. In short, my configuration is like this: INTERNET < -> CLOUDFLARE < -> NGINX (DIGITALOCEAN) < -> APACHE (MY DEDICATED SERVER) There are several technical challenges that need to be solved: How can I forward requests to my dedicated server (completely under firewall) How can my end point (apache on my dedicated server) recognize IP from visitors correctly (since there are several layers in between? The solution for my first challenge is actually very simple: SSH Tunnel. There is one catch: Each website in my dedicated server will have to use its own port. And here is why: Assume I have 2 websites, example.com and codepie.org. I assigned port