I thought they were quite open about the Xen exploit and how they managed it. Did I miss something about it?

What about the xen exploit?

http://blog.linode.com/2012/06/13/xen-s ... dled-them/

People need to understand the current Xen pre-disclosure procedure means we can't tell anyone what it is until after the advisories have been made public. Which is what we did. Discussions are underway regarding said procedures:

http://lists.xen.org/archives/html/xen- ... 01072.html

-Chris

This. It is remarkably difficult to provide enough information to let the public know something is up (and provide guidance on how to fix it) without pointing to the exact path of exploitation. I'd say Linode came as close to the line as they could... see the lists.xen.org link above, particularly list item #7, which probably sounds familiar.

Also, I'd like to note that Linode admitted the Bitcoin problem occurred and that they were fixing the relevant issues, which is atypical in this market. I'm in the midst of a self-imposed embargo period for this sort of thing involving another major provider; they silently fixed the issues on new deployments but left existing servers hanging in the breeze. I am not discounting anyone's opinion with regards how transparent Linode could/should have been, but it's hard to put things in perspective when everyone else is completely opaque. Hopefully things will improve across the entire industry.

_________________

/* TODO: need to add signature to posts */

That's fair I suppose. The time line for what happened between reporting and disclosure is kind of a joke without names associated to the actors involved though. What's linodes position on how that was handled by xen-sec? Specifically what's the feeling relating to the length of time the issue was kept embargoed?

My original comments about requests for transparency re: the bitcoin hack still stand however, and would still put my "improve on this" credits toward better transparency in general.

1. Multi-factor auth for the Linode Manager.

Simple user name/password authentication just isn't adequate when we're talking about a portal that gives complete control to a customer's entire virtual infrastructure. Any provider can be hacked. When it happens, it should be more difficult for the hacker to gain access than simply having to crack passwords. Amazon Web Services has a very nice and easy-to-use setup via Google Authenticator. Please take a look at it.

2. NodeBalancer Private IPs or IPv6 to Back-end Nodes

I need to load-balance database reads over the private no-fee network.

3. Named Snapshots

A simple thing that would make my life easier.

4. Clone API

Oh wait, you added that! Almost 11 months to the day since I first requested it, but better late than never!

And thanks for asking. It's nice to know you are listening.

_________________
Got Escher? | @artagesw

Anyone mentioned lish over ipv6?

Now that I've had some real-world experience with NodeBalancers, specific improvements I would love to see:

1) Private IPs or IPv6 to Back-end Nodes

Already mentioned this one - for load-balancing private intra-cluster traffic, such as database reads.

2) HTTP Keepalive Support in HTTP Mode

This one is really important from a performance standpoint, especially for static assets.

3) SSL Termination

Would be great if I could manage the certs in one place and offload SSL processing to the balancer.

4) Alerts

Ability to configure alerts (email, SMS, etc.) when a backend node's health check fails/succeeds and it is pulled from/added to the rotation.

_________________
Got Escher? | @artagesw

Ext4 by default -- there is no ext4 documentation whatsoever

Additional IP addresses before deploying a Linode and receiving this error: "Additional IPv4 addresses require technical justification. Please open a Support Ticket describing your requirement."

Easier web panel management for setting up multiple websites, especially DNS

Ext4 would be good, you can gain some benefits of ext4 by mounting an ext3 partition as ext4, it's backwards compatible. If you convert from ext3 to ext4 completely things won't work anymore (i.e. linode backups, pv_grub, resizing partitions)

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Floating IP addresses would be awesome. Associate IP (IPv4 that is) addresses with the account rather than the node. As far as I understand it IPv6 addresses already work this way if you request a pool of addresses.

Aren't they are assigned geographically else how would GeoIP work?

for one, they're assigned to a datacenter.
for two, that's not really how GeoIP and IP address assignment works...

_________________
うるさいうるさいうるさい！

Sorry. I should have stated that I meant floating IP addresses for each data centre rather than floating IP addresses across all data centres.

Are there really any notable benefits from ext4 in a Linode environment? Increased size limits seem unnecessary, plus it seems to me that most of the performance or I/O handling changes are obviated (either unnecessary or not guaranteed by the hardware) by things such as the virtualization layer and/or the use of BBU-backed raid arrays as the local storage. And in fact in some cases might get in the way more than help.

-- David