https://vpsexperience.wordpress.com/

An odd experience, I would say.

3.13 Subscribers may not use the Services in a manner that would violate the lawful privacy rights of any person, ... or embarrass, which shall be determined in DigitalOcean’s sole and absolute discretion.

So... if someone gets embarrassed by what you put up, DO just decides to take it down.

https://www.digitalocean.com/legal/terms/

There are occasional weird situations like this that come up and I would love to handle every support request directly but unfortunately that's not possible.

We've had to scale the support team to support over 100,000 customers and we didn't get the right customer support director on board till about 2 months ago.

We are constantly looking to improve our service in all areas and Zach is on top of it to ensure that all of our customer support staff get more training in how to better respond to customers.

However, the promise that I make is that if any situation ever arises in any way shape or form with DigitalOcean please contact me directly - moisey --- a-t --- digital0cean - and I will be on top of it as soon as possible.

I hope that helps in response to this issue.

Thanks, Moisey

At any rate, I have no way of knowing about this issue. It's just curious that DO would put embarrassment as a ToS violation. All sorts of stuff embarrasses all sorts of people. Might as well just put up "DO reserves the right to terminate your services, at any time, without reason."

In regards to embarrassment it's about the intention of the statement which is to not use the service for a malicious nature. But we're more than happy to open up a dialogue about this and see if there are any amendments to the terms that are a good idea.

We'll push on getting more of our public content into github so that customers can provide feedback and provide rewrites of the terms that they feel capture the sentiment but perhaps clarify those terms better.

these people do not give a shit about the streisand effect. they are going after their money.

We try not to interpret the law as that is not our specialty of course, we are simply saying that we would like that customers use the service for a non-malicious purpose. But we're more than happy to open up a dialogue about this and make amendments if necessary.

Thanks!

I'm sure they will get that eventually. Maybe after they learn to scrub customer storage in every case (not just enough to sweep the issue under the rug) so that droplets aren't immediately compromised on termination.

In case that wasn't clear to you, DO puts their drive wear ahead of your data. There are still multiple endpoints in the API that will leak your data to other customers. They fix some cases of it every now and then, then revert without telling anyone once they see the impact on their SMART metrics. When sneak called them out they wrote an entirely fabricated blog post. That incident resulted in a published CVE in libcloud earlier this year but of course nobody gives a shit, throw more VC at them!

It sure seems like the author went into the chatroom looking for a story, and got the THINNEST of all possible stories ("Random Google Developer Has Opinions") and, in an effort to turn it into real news, colored it in the most negative way possible. It is profoundly terrible journalism, and the motives behind it are so ugly. This is not something that we should endorse on Hacker News.

The only story of relevance here is that Digital Ocean has a line in its TOS about not allowing "harassment or embarrassment", and they will enforce it if you do indeed harass a guy.

I think you are missing the real relevance here; that DO will use their own discretion to determine if your content is worthy of dissemination. You're right, it was terrible journalism, and a thin story. So what of it? Why should DO concern themselves with the content that isn't breaking any laws? What, precisely, is "embarrassment"? It was a no-name blogger posting a non-story.

>This is not something that we should endorse on Hacker News.

The fact that you say this explains a lot about why you have your opinion on DO and how things should work, and why I have mine. If this story is getting upvoted, it's getting upvoted. There is no "we", unless you're trying to curate opinion and create an echo chamber.

Say, for example, that there's an article about a "scientific study", claiming some strong conclusion (e.g. "pig hair cures diabetes.") The article goes on to say that the study has one data-point and no control-group (which is to say, basically, that it's an anecdote.)

To still even consider the study's conclusion as possibly true is to privilege the hypothesis. You didn't have any facts before. You don't have any facts after. And yet, your default has switched from "assume pig hair has no special properties whatsoever" to "assume pig hair maybe has something with a vaguely-medicinal use in it." You've updated on zero information.

Just as much as publicizing such a "study", it's irresponsible to put such journalism--sophistry, really--in front of other people, where it could possibly infect their defaults. Not everyone catches these things. Most people only read the first paragraph or two of things, and come away with impressions. These impressions, especially in the case of really bad journalism, can be directly opposed to the impressions they should have taken.

If we are a community here, then we should want to help one-another avoid bad journalism, and more importantly, avoid becoming swayed by whatever the bad journalism purports to report. We don't all need to think the same thing--but supporting a story just on the basis that other people support it, leads to pig hair being "signal-boosted" into notoriety.

Or are they exercising editorial discretion?

All I was talking about is the meta-issue you brought up, of what HN as a community should or shouldn't "give air-time."

Even if you take the stance that his ability to speak freely should be defended (which I agree with) I suspect his behaviour here indicates there could be more to the story. Plus he sounds like the kind of customer I wouldn't want to have.

Businesses should be free to choose who they serve (subject to some restrictions around bias against classes of people).

[1] https://news.ycombinator.com/item?id=7016735

(Full disclosure: My only relationship with Digital Ocean is having been offered a free month of hosting with them once. Never used it.)

Can you explain what you mean here? The blog owner appeared to be offended by the Googler's stance that he was taking in a public chatroom about Google policies so he blogged about it. How is that a creepy obsession?

But if true, I'm moving everything away to a more professional hosting provider. You don't just shut down a hosting account because of a single anonymous complaint. That's just a silly thing to waste your time with.

I also have a vegitable garden which we can most of our food from or preserve in other ways. :)

If I want a chicken that tastes just as good as the ones I raise I have to shell out $20+ for a 6lb whole chicken.. Crazy.. I get it for about $1/lb.

I have a massive vegetable garden but not enough to survive off completely as we're in a London suburb so we concentrate on growing the expensive stuff (and potatoes because once we planted them they just keep coming up every year).

Can't do chickens here - too many foxes.

"I wonder if anyone has ever tried to run a startup out of a cave..."

I guess it could happen, but wow.. its like trying to get Beyonce derp face or whatever meme removed from the internet

* Can't add backups to an already provisioned node

* Undocumented "droplet limits" e.g. one day you'll click "Add Droplet" and it will say "You've reached your droplet limit, please contact support". They'll generally raise it after some basic security verification but it's a nasty shock since you don't find out about it until you need to provision a new Droplet, especially if you're in a hurry.

https://cloud.digitalocean.com/settings

The second is if a customer signs up using Paypal we restrict some of the larger sizes, this is done to minimize the amount of fraud we have to deal with.

Unfortunately we deal with a high amount of abusive and fraudulent signups so we've had to instate a lot of automated filters and other updates to the user experience. It really sucks, but without it we'd have a lot more fraud which would really just make the entire experience worse overall.

In either case opening up a ticket will get either issue resolved.

Sorry for the inconvenience but if anyone is good at fraud detection and wants to help us to continue to automate it and make it smarter, we are hiring =]

Thanks, Moisey

I suggest this because I've been using Digital Ocean for quite a while (several different accounts for different projects/ clients) and have never needed to look at that page.

The need for limits and additional verification makes complete sense, but it would be useful for it to be highlighted in advance (e.g. in an intro email or banner) so you can deal with it in advance of it becoming a problem.

Then I can sleep/configure the rest of the system.

Been meaning to package this all up in an ansible playbook but I can't be bothered :(

I'd be using FreeBSD if they offered it. Much like OpenBSD it's a lot more pleasant for sysadmins!

PSA: If you just update the kernel using system tools within the instance, it'll still boot the old one. (At least it did few months ago.)

The grub (or other bootloader) and kernels that are installed inside the instance's disk image are silently ignored and the vm uses a kernel stored outside of your instance's image. You can select which kernel image you want to boot in the control panel. The problem is that the kernels available in there are updated very, very rarely. For popular distributions like Ubuntu they can lag several months, for others it can get up to, say, _two years_ [1].

Since digitalocean "doesn't support custom kernels" it appears that the only way to use something up to date (and stay secure) is to write a script that loads a custom kernel using kexec. :S

edit: The fact that they use kvm (and that kexec works) which means real visualization but can't boot user's kernels is just very, very weird. The only technical reason i can think of is that they can't manage to make it work with their control panel. If that's the reason, then it's very worrying. (The "right" way is easier to code and it's the solution that you'd think of first and it makes custom kernels a non-problem, but they picked one that both has obvious problems and is harder to setup, i can't think of a reason why.)

[1]: https://www.digitalocean.com/community/questions/how-can-i-b...

At this time we only support xen paravirtualization(PV) though, which almost, but not quite, all major distributions have. Notably we can't run 64-bit freebsd right now because they only have HVM support. I'd like to change that but it needs more testing first. Here is a partial list of distributions supporting xen: http://wiki.xen.org/wiki/DomU_Support_for_Xen Really any linux distribution with a modern kernel can be made to support it though as support has been in mainline for a long time now.

As is industry standard, I'm upgrading existing customers (e.g. they stay on the same price plan, but they get more resources) before I offer those new price plans to the general public. I have maybe... 1/3rd of my customers upgraded to the plan I promised several years back (that has more disk and less ram than the plan I am upgrading to now.)

A big part of the problem is that I made a huge business mistake a year ago that cost me most of the money I would have used for upgrades. But, I've got a few options on the table, one of which is just consulting for a while;

if I go with used hardware, I'm within $50K of having enough hardware to upgrade everyone to "competitive, but not great" pricing. - that's maybe 3 months of full-time contracting work. Completely reasonable. Of course, used hardware is a lot like 'technical debt' - pay me now or pay me later, but it might make sense, just to get the monkey off my back. (That, and dealing with hardware problems is part of my core skillset; I can probably eek more reliability out of used garbage than most companies can.)

I'm talking 2-3x that for new hardware, which is a lot less realistic without some sort of loan or lease, something I should look into, but eh. I am thinking that used hardware until I'm competitive, then start buying new hardware once I start getting new customers on board might be the best way to go. The company is vastly easier to run when it's slowly growing rather than slowly shrinking.

1. their original "inject kernel into OS and boot from it that way" architecture was designed that way on purpose, so that users could downgrade kernels out-of-band as a way to rescue a bad upgrade;

2. but now they've got thousands of droplets configured that way, so switching architectures to something sensible will require either A. forcibly installing grub on, and restarting, every one of their nodes (not something people expect out of a VPS provider), or B. coming up with some sort of glue that can manage both the nodes expecting an injected kernel, and nodes that want to boot on their own, and providing a way to transition your nodes from one to the other.

Basically, it's a mess. A bit like the problems Heroku had with its Alpine stack.

Writing this playbook paid off already for the second installation of the box.

Restart ssh after editing sshd_conf.

If you're squeemish, run dropbear on another port so you can log into your machine in case you made a boo-boo configuring openssh.

Also, more resources for security settings:

https://benchmarks.cisecurity.org/downloads/multiform/index....

Shameless plug: a small side project I did with my team at nodeSWAT [1]: CMify [2] - a web service to easily generate your ansible playbooks. Somewhat naive so far, if there is interest we'll extend it.

[1] http://nodeswat.com [2] https://cmify.com

Give us your address so we can send you money.

Small thing but at least then it doesn't shout "Hey I'm a *nix box with remote login enabled"

https://www.google.com/search?q=fail2ban+dos+bug

A better approach is something like pam_abl which is a pam module that will accomplish mostly the same thing but only for login attempts and without the crappy plain text log parsing.

I've always been installing denyhosts but I have not compared the two.

Don't forget https://github.com/kickstarter/rack-attack as well though.

To be fair I'd just use FreeBSD which has a little better kernel architecture with respect to security.

https://mail-archive.com/[email protected]/msg127100.html

  > There is a lot of functionality built into these
  > utilities, iptables being the most popular nowadays, but
  > they require a decent effort on behalf of the user to
  > learn and understand them.

I'd rather use pf on BSD though.

You should still understand iptables but you do not need to config everything manually.

Simple is being able to simply say "allow all outgoing traffic and incoming traffic should only be allowed for HTTP(S) and SSH" and being able to figure out how to do it by just invoking "ufw --help".

Maybe someday I'll learn about iptables, I'm sure it's going to be worth it, but for now ufw does the job for me.

> Maybe someday I'll learn about iptables

Hmm...

    iptables -A INPUT -p tcp --dport 22 -j ALLOW
    iptables -A INPUT -p tcp --dport 80 -j ALLOW
    iptables -A INPUT -p tcp --dport 443 -j ALLOW
    iptables -A INPUT -p icmp -j ALLOW
    iptables -A INPUT -i eth0 -j DROP

Indeed, it is. Even if you want to cargo cult that without understanding it, you might get bitten because running those commands again will not do what you expect, since they're not idempotent.

You will now reply telling me how to deal with this situation, for example if I want to now listen on a different port, or how I get FTP (or some other protocol that needs "-m state" to work. The need to do this proves that using iptables is more complicated that your example.

    sudo ufw allow proto tcp from any to any port 22
    sudo ufw enable

  sudo ufw limit ssh
  sudo ufw enable

    sudo ufw allow from your.ip.addr to tcp port 22

I ran into that in connection with MIPSpace. Large swathes of DO IPs are blacklisted by MIPSpace, which impacts my deliverability for a small double opt-in hobby list.

- Digital Ocean says they can't get MIPSpace to remove IPs.

- MIPSpace will only deal with me if I can get DO to add rwhois/SWIP for my IP

- Digital Ocean doesn't offer that feature (of course).

So I'm somewhat stuck there. Not as though things are going to be any better elsewhere on another cloud service, I suppose, though I never had these issues at AWS. But moving back would triple the cost of running an equivalent mail server.

Hopefully some of the funding here can be used by DO to actually clean up their IPs and manage the issues with the less reasonable blacklists like MIPSpace - who doesn't send abuse notices, and seems pretty capricious, from what I'm reading. Since DO are in the business of renting IP addresses, it would be good if those IP addresses were not usually on some blacklist somewhere.

So while DO is saying no, I'm wondering if it's because they don't offer the space required to SWIP the ranges. In addition to not offering the size, it would incur additional administrative overhead.

Can't blame them.

Edit: definitely possible http://lowendtalk.com/discussion/12406/which-providers-provi...

So you shouldn't call MIPSpace stupid, thanks.

I've seen numerous complaints indicating that Digital Ocean abides no such policies.

http://digitalocean.uservoice.com/forums/136585-digitalocean...

Anyone have any citations for case law where virtualized hosting falls under 512(c), and doesn't qualify for safe harbor under 512(a)?

512(a) would apply to, say, an ISP that stood between a system hosting allegedly infringing content and those accessing it, not to the owner of the physical system hosting that content who allowed a third party to control a VM on the physical system on which the content was hosted.

http://www.law.cornell.edu/uscode/text/17/512

Knowing first hand that other providers handle the exact same scenario with ample amounts of equitability informs my decision that there's a better way to go about it.

Effectively, it's the kind of policy that would allow me to jokingly refer competitors to becoming DO customers.

No, it doesn't.

The DMCA provides both a safe harbor for hosts against infringement liability (the take down notice procedure) and a safe harbor for hosts against any liability they might have for taking down content (the counter-notice procedure), but neither of these procedures are strictly mandatory, they just provide a liability shield for certain liabilities that the host may have had without them.

But most hosts have taken pains to assure that they have no liability in the latter case through terms of service, so there is little reason for them to be concerned with the counter-notice procedure.

If a host does not follow the entire OCILLA playbook in every case, unconditionally, across the board, the host no longer qualifies for any safe harbor whatsoever. Then it's open season on copyright violations. Think $400,000 per song style open season.

The real liability threat remains third parties, not customers, and disregarding the prescribed counter procedure is handing them the keys to the bank. If you see a host playing fast and loose with the rules, for example your content not being restored in 10 to 14 days after counter notice with no further action, it's time to go after their registered agent.

The 512(c) safe harbor rules are clearly written in a transaction-specific manner rather than the way you describe, and every case I've seen on them has focussed on whether they were followed as relevant to the transaction and not addressed whether the host followed them "unconditionally, across the board". So, I think your conclusion is wrong.

Under what grounds? Taking down your content isn't violating your copyright. If they lose their safe harbor status, some future copyright holder could sue them, but I don't see how you could.

Getting ahead takes capital and i'm sure they're aware of what makes them inferior, you can't raise $37m without a good story on how you're going to use it to get ahead and win.

I have great hope for http://bigv.io but they're not quite there yet.

Having worked for some big hosts myself, i know how hard it can be to make changes once you have people using your platform. I suspect DO are in a similar situation and are looking to make a big leap forward with new growth leveraging their existing brand. I have no real evidence of this, but it feels like a sensible course of action.

No one likes giving up equity and taking money unless there is a damn good reason for it.

Normally in these situations, much as they do with DO already with disparate DC capabilities, you deploy infrastructure side-by-side and slowly port it over from one system to another. Developing the capabilities isn't really a big problem even if you build it versus buy as the total developer / administrator / server ratios on these sorts of companies are pretty favourable to massive automation.

I suspect they really do just want the money. Either than or they've short-sold themselves as a bargain host and now have trouble generating revenue and will lose too many customers if they crank prices so they're riding the investor's crack pipes via hype.

The latter is all too common unfortunately. One of the UK's "leading" hosts I did some consultancy for in the mid 00's actually relaunched with just under 50 CentOS servers with shared hosting/cPanel stuff on them but priced too low. They got customers but not enough to pay for the cage. Spent a couple of months moving their shit into a single 42U and consolidating their billing and provisioning system. They're still around now and can pay the bills. I did it for cash - I wouldn't want the equity myself.

Ramnode absolutely sucks. I can pull maybe 100k/sec off them if I'm lucky from UK in their US and NL data centres which is abysmal. Cancelled my account the day after opened it.

- The site doesn't look good on my Retina MacBook Pro, mainly due to the extensive use of low resolution images for things like gradients and text (I don't understand that at all).

- Only pricing is in GBP, it'd be nice to have something else as a reference (a little "roughly $16 USD" in brackets would be nice)

- Straight up asks for my full address and phone number, without stating a reason why they're necessary or how they're used

- Takes me to a payment page and asks for my credit card number on a plain looking page served with a Class 1 SSL certificate (no organization validation) and again, with no indication how it'll be used

I was actually looking to give it a try after filling the address fields and phone number with "Nopenopenope" but lost it at the (subjectively) dodgy looking payment page.

A redesign and some explanations on signup pages would do you a lot of good I think :)

Got a $20 credit for my trouble (good PR!), and then promptly moved on to a provider that actually supports my needs.

1. Dependency on ColdFusion. Seriously that product is dead, poorly maintained and powers the entire front end. That's scary. Even more scary than PHP written by outsources from Elbonia. They got hacked due to this.

2. Billing system is take then refund credit rather than billing afterwards.

3. From my location their latency and throughput sucked even in their EU DC despite being only 11 miles from my house.

This is a huge issue for us and we've wasted time with this.

It's not possible to shrink upsized instances like you can on Linode. On DO you can't even restore a snapshot or backup to a smaller instance size - you must rebuild from scratch.

I guess the right way to handle this is a configuration management tool, but this is a real pain since there is only local storage.

Yes, this is vital, but it's still not going to help you maintain existing data. A config management tool isn't going to fill out your logs, for example.