Linode introduces StackScripts - Custom recipes for your Linode | Hacker News Reader

Linode introduces StackScripts - Custom recipes for your Linode

blog.linode.com

100 pointsJshWright30 comments

I would love it if they had this at Slicehost. It seems so stupid to have to configure a basic web server from scratch again when it's been done millions of times before me. Set up a great standard setup and then let me tune from there.

From what I've seen, the scripts looks like shell script, so they can be used elsewhere, or am I missing something?

The only thing that you would have to do is include the "helper" file and it should work if you copied it. It looks like linode is doing some extra preprocessing but I do not do much bash scripting.

I built SliceApp.com to solve this problem.

Spent the past couple week reworking it. It will work with Slicehost, Linode, Rackspace Cloud...anything running Ubuntu accessible via SSH.

Actively working on it and open to suggestions on what would make it better.

Very nice! In terms of suggestions:

  a) info on versions would be nice
  b) more options (ftp, mail, sphinx, lucene, etc)
  c) maybe a short questionnaire about usage to optimize config
  d) I'd like to see more about security and who you are before I hand over username/pw

PS - You should post this as a "Tell HN" here if you haven't already...

Also, it would be nice if you supported more than Ubuntu.

I'd say that support is coming, but everything currently available on the menu are things that I actually use for dev work.

If I find myself in a situation where I suddenly need to support CentOS, Debian, whatever, then the first thing I'll do is add it to sliceapp :)

Very nice job. I'll be using it soon. I second the idea of submitting it as a "Tell HN."

I don't think the security is a huge deal because, since it's setting up a new server, you really should just change the password afterward. But it probably wouldn't be bad to reassure people (or say "don't worry about security! just use a throwaway password for us and then change it"). It doesn't matter if security shouldn't be a concern if prospective customers see it as a concern.

It doesn't matter to a lot of the people that use it. I don't store their passwords and I pipe everything going on in the server to the user's web browser. User's are invited to snoop TTY's.

But yes I agree totally. It's meant to work with cloud servers so if you grow weary or distrustful of the box, tear it down and start over. One thing I've been playing with is API integration. Not that its any more secure, but I think fewer people would confuse an "API key" input field as a "Login here" form (which some have).

Security aside, I'm slowly attempting to monetize this and to be quite honest I'm more interested in people giving me their money than their passwords. I can't pay rent with passwords.

Pretty cool feature, but it seems like they're working at the wrong layer of abstraction.

It seems like that's really best left up to Capistrano, Puppet, etc. Stuff you run from your shell where you run the "setup the server with ip/hostname of x", and it does it.

But they want you to raise the barrier of exit for their customers and want to differentiate themselves, so it makes sense. Plus a lot of the stacks say they're tuned for Linode's exact resources. That might be more selling point than actual special setup, but there is potential for them to tweak it for better performance on their exact machines.

I'm not sure I see the lock in... Other than being a little distro specific, I don't see any reason the scripts would run on any linux platform.

The "tweaking" in most cases just seems to be modifying the default configs for Apache and MySQL to something a lot more sane for a limited memory environment.

This is nice. As a level 1 bofh I love this and will consider Linode as my next VPS (though I'm uberhappy at slicehost!).

Also, just learned what 'LEMP' was (like LAMP, but [e]nginx instead of Apache)

I helped beta this and it works great. Since it just just a typical script you can write the script in whatever language the distro has an interpreter for. Bash, Ruby, Python, whatever. If the distro doesn't have the interpreter you want, you could always write a StackScript to install it ;)

This is neat. Similar to EC2 AMIs, right?

Something I've these -- who is responsible for security updates? I assume it's the deployer, which can often be someone who may not have much experience as an sysadmin. What's the best way to keep a system secure? Cron + Apt-get update?

I wouldn't suggest cron'ing apt-get update, it may break something while you're not there. Better to do a manual update once a month or so and do a quick test afterwards. Ideally you'd do this on a identical non-production QA machine, but if you're only a one box sorta guy then you can likely get away with no issues.

Of course, security issues these days are more often the result of misconfiguration but if you're doing something simple like a single box with a localhost only MySQL, Apache/Nginx and Rails/Python/PHP or the like then it's pretty straight forward. Don't really even need a firewall.

What I would suggest is locking down SSH to not allow root login and to require key authentication and deny password auth. So much automated SSH password guessing bot spam out there.

Thanks for the info. Are exploits rare enough these days that updating once a month good enough for a well-configured machine? (If so, that's great -- I was worried about taking a vacation :))

Depends on your risk profile, but in general if you update once a month you're probably ahead of 95% of the servers out there.

I don't agree - I try to do security patches every few days, and major upgrades when I have time to test them. The hard part is keeping tabs on what servers need them. I have 7 or 8 vm's and when they're not involved in a project they're easy to forget about.

Setting up UFW on ubuntu is so simple that I really don't see why not use a firewall.

Oddly enough, from the command line, I don't get the point of UFW, straight iptables is much easier for me. I mean, if you understand the concepts of iptables, UFW is just an alternate but by no means easier way of manimpulating iptables.

Agreed. UFW is just simple to copy/paste commands from tutorials on how to set up your own server.

Brute forcing:

http://news.ycombinator.com/item?id=1025520

I think a new admin needs to read up on locking down ports in iptables, Bastille, snort, filesystem fingerprinting and some checklists:

http://www.mnxsolutions.com/blog/apache/securing-your-server...

http://blog.dhananjaynene.com/2009/10/configuring-a-secure-u...

I always run ssh on a really high port, which does a decent enough job of keeping the password guessing bots.

I have a cron job set up to mail me if there are packages to upgrade. Avoids potential breakage with automated updates while still letting me act reasonably fast.

Looks like a simpler Puppet or Chef, very cool. Anyone want to comment on the differences ?

This looks like an organized collection of bash scripts with standard libraries for basic configuration processes, much like the fundamentals of Puppet and Chef.

This is great for simple initial setup (I'm sure a lot of us already have some short bash scripts to similar effect). However, Chef is great for maintaining multiple similar servers and keeping things standardized across machines with minimal effort. Chef also gives you some handy tools like automatic deployment and ERB templates.

I'm using Chef with 7 servers on Slicehost right now, and it's easy as pie once the recipes are set up and your server is deployed.

I would be up for building some StackScripts myself but I hate to have to buy a complete plan to do it. I really wish Linode would offer a more fine grained billing.

It's pro-rated to the day - so if you add a Linode for the month but remove it after one day, you've ended up being credited back all but $0.67, in the case of a Linode 360.

I agree. I'd infinitely love Linode if they offered hourly billing of servers.

This is very cool ... hope to see some Rails stackscripts soon ... that would save me a few hours here and there

Reply on news.ycombinator.com