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 :))
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.
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.
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.
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.
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.
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.
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...
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.
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 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 ;)
30 comments
[ 3.4 ms ] story [ 94.3 ms ] threadSomething 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?
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.
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...
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.
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.
Also, just learned what 'LEMP' was (like LAMP, but [e]nginx instead of Apache)
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.
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 :)
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.
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.
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.