It teaches you how to setup a DigitalOcean (or any other) VPS from scratch to host N amount of Rails applications using Nginx and Passenger. It took me some time to get things working properly and I distilled it into this short article that holds your hand and takes you from A to Z.
Nice. One step I would add is after restarting ssh and before rebooting while still logged in as root is to start a second ssh session, log in as the new user, and verify you can sudo.
Your current instructions are predicated on success. By verifying your new user login and sudo capability before logging out as root (rebooting), you can fix typos or other Bad Things. Not that I would ever make a typo while editing sudoers. ;-)
One thing I would recommend is searching for deals on LowEndBox[1] blog. Most of the popular VPS's are ridiculously overpriced compared to what you can find on LowEndBox. It's a good site to get advice and reviews of various VPS providers, too.
I'm quite familiar with LowEndBox, and I would say my current "Best Value" VPS provider would be Digital Ocean, who I found via HN. I probably can think of at least a dozen with solid reasons to avoid.
FYI Digital Ocean's lowest offering is $5/m.
LowEndBox is great for non-mission critical servers. You aren't going to find many top tier providers on there, mostly smaller companies. I got a dedicated box (quad Xeon, 24GB RAM, 500GB) for $49/m.
Why would anyone need to search LowEndBox, when they can get top tier cloud servers from DigitalOcean(which is linked on the original post)? There is absolutely no reason to use providers from LowEndBox with grandma's SolusVM, when you can spin up a server with DO anytime you want and pay by the hour?
And not to mention, how these providers are ddosing and hacking one another regularly.
You should probably have people use visudo instead of editing /etc/sudoers directly. If you make a typo or similar that prevents sudo from running correctly it will catch it.
Disabling root login without changing to using ssh-keys for authentication doesn't really buy you a whole lot of security; you can still access the box and root with knowing just one password -- the only thing you've avoided are brute force attempts against the root account.
With sudo and only keys based access, the attacker will need to get a copy of the key (barring any new problems with key generation, like the Debian ssl bug) and the password needed for sudo access (or the root password, for su -).
As other's have said, use visudo (possibly with "EDITOR=nano visudo) -- to avoid leaving your sudoers file in a broken state.
An as others mentioned -- make sure you can login and sudo before you log out of the root shell...
Locks to only one editing user and confirms syntax is clean before saving. I'm not aware of nano enforcing correct sudoers syntax. Plus plenty of us don't like nano.
visudo, like vipasswd or crontab -e and other commands, respect the EDITOR environmental variable, so you can edit these files with whatever editor you prefer, while maintaining their protections.
True. Provisioning a new test VM for me usually entails something like this:
ssh in;
visudo;
wtf, this is nano! Boo!;
ctrl-x;
update-alternatives --config editor... :)
Thank you for linking to your article, it was perfect timing as I'm about to throw up a tiny Ruby/Sinatra/PostgreSQL site I've been making for a local need. The quality of my actual code aside, I understand that servers are incredibly complex beasts, especially when it comes to security, and I want to ask (And because of their complexity, I assume it's a small question with a huge, complex answer), how relatively 'safe' would I be following a guide like yours along with other ones that specify some simple, good practices for setting up a server?
By safe, I mean in the context of the server getting hacked. I know people wouldn't bother but I'd rather at least feel a tiny bit safe. I'm going with a VPS (Digital Ocean) too so I can slowly learn all these things.
Hi thanks for your comments, I appreciate you taking the time to read it.
I'm _not_ a devops guy. Following my guide you _will_ get a running production server but I've only distilled things from other blogs I've hunted on the web. I would make sure I hire someone who actually does this for a living before putting production things on something I configured.
So feel safe, but cautiously safe - I'm not a guru.
Not really a terrible idea at all. They are simply conforming to the CGI specification. In realizing the potential security issues associated with doing so, they offer a way to disable that behavior.
I think the sites-available is a debianism, not present on all distros. One nice thing that nginx supports is include directives with wildcards so you can e.g. have /srv/example.com/nginx.conf and /srv/api.example.com/nginx.conf and include them in the main configuration file with include /srv/*/nginx.conf.
Today You Learn that is because the original package maintainer of the NginX package in Debian (and thus later, Ubuntu) simply copied the structure of the Apache package. It's most useless because there is no script to manage the sites available like with apache.
I have been complaining about this for years!
On FreeBSD and all my client's sites (whether they run Linux or what), I always set mine to include sites/*.conf and delete those apache-isms.
It is my experience from years of administration that `ln` and `rm` (or perhaps `mv`) are the only commands necessary to work with the directories without the scripts.
There are "official" nginx packages for Ubuntu and other major Linux distributions which are always up-to-date and use a standard conf.d directory for including configuration files http://nginx.org/en/linux_packages.html
I may be misunderstanding you, but sites-available and the conf files are usually two separate entities. sites-available | sites-enabled is analogous to using a2ensite in Apache without the automagic (you symlink yourself)
On systems that have both, yes, they're separate. But that separation is something the distribution does to help you organize your rules — to nginx, they're all the same AFAIK.
For starter nginx's configuration, the h5bp nginx config [1] is pretty awesome, e.g. sending correct mime types, protecting hidden files, cross domain webfont, expires, gzip, server tunings all included.
I am a little hesitant on restarting nginx. When you do that, it drops the connections that are currently attached. Instead, you may want to do `nginx reload`
Great feedback guys - we'll look this over and probably change it in the article : )
The reason it's as such is because of what @timroman said in his reply, but if this method is no different and scales better no reason not to use it instead.
It's not a problem on a new server of cause, but on a live server it makes a difference, so you might as well learn the "correct" approach initially, so you won't hurt yourself in the future.
Right but if you are modifying and existing server, then this needs to be taken into account. We have several servers who are constantly serving connections and we can't have any of them drop otherwise it will result in a poor user experience.
I just wish the article talked about using reload as well as restart and when to use them.
Hi, author of the article here. I'm actually not familiar with reload, but after reading this comment thread I'm definitely going to read up on it and make sure it's reflected in the article. Any suggestions of knowledge you want to drop is more than welcome!
Me as well. I always use reload but I don't really know how it works. Does it maintain the old and new configs and drops the old after the last connection using it is complete?
When NginX's master process receives the HUP signal[1], NginX will process and test the new configuration. If it is correct, the new configuration will be loaded into new worker processes. The old worker processes will stop receiving connections, but finish their current work. Eventually (within milliseconds usually), all the old processes will be gone and only new processes with new configuration will be working on requests.
[1] On FreeBSD, we just use `killall -HUP nginx` to reload; your distro will probably send HUP to the master process' PID
One of my favorite nginx features I just discovered is that you can use a regex in the server_name and then you can use the capture as a variable later [1] ... this lets you serve domains or subomains from completely different directories without a new conf file or a reload.
I've done something similar in Apache with mod_vhostalias, where you set a VirtualDocumentRoot that specifies the pattern to match against and the dynamic directory path to serve up.
I like just keeping a single "etc/nginx/sites" folder, including "sites/*.ON" in my main nginx.conf and then appending .ON to the sites that are enabled:
In my view, you answered your own question with the second sentence. Sysadmins and linux hackers are no doubt familiar with this stuff anyway and used to reading through sysops-style docs and wikis.
Many other developers, we assumed, would not be as familiar with ops at first, and would prefer more of a basic introduction that walks through the steps and explains things clearly.
You're correct, the audience is really just a matter of semantics. The reason we wrote this post, knowing that this is very basic stuff, is that we found that a lot of the tutorials we'd come across didn't cover the introductory process end-to-end.
You're just as surprised as we are to see it on the frontpage!
Completely off-topic: Is that a custom WP theme? I love the look and feel of this article.
On-topic: Thank you for this. I am going to purchase a DO box this weekend and play around with nginx instead of apache. For some reason when I last tried to use nginx, I could not get location {} to work. Granted it was some time ago.
Does anyone have any resources on nginx as a load balancer?
Actually it's a very simple custom non-wordpress theme I put together in about an hour, the entire thing built on top of http://roots.cx dynamic content : )
Another note, the share button at the bottom (just pushed a minute ago so hard refresh if it's cached) is from this plugin we put together and have been enjoying so far: https://github.com/carrot/share-button
Glad you enjoyed the article! Let us know if you run into any trouble, happy to help or add debugging techniques etc
On the contrary, if you just need a box to tinker with sysops stuff and learn, digital ocean is a fantastic solution. Cheap and I've never had a bad experience or anything unreliable.
I can't speak to using it to store lots of not-backed-up files or running a gigantic production server, but for learning about syops it works great, to get back to the purpose of this article.
That's kind of where I'm at right now. Normally all of my side projects are hosted on PAAS (Appfog is my current choice, but we will see since their acquisition).
I really just want to practice setting up and tearing down configurations. I think DO will be a good choice for this.
Was in that exact same spot a couple months ago and did the same thing. I was eyeing DO for a while and one day folded and paid the (really no brainer) $5. I've learned a ton since then and it has been absolutely worth it for me.
I actually transitioned all my apps off any other PAAS platforms (mostly nodejitsu, timed nicely with their 3x price increase) and am now hosting everything I run off a single $5 digital ocean box, which actually is saving me a bit of money, and deploys are a lot smoother. The company I work at, Carrot, is also hosting all of carrot.is on a $5 DO box, including this article, which has had no issues coping with the 600+ people on site at a time that have come with this HN blitz.
Wow that sounds like it was quite an issue. Where are you thinking about migrating to?
IMO, I can't really trust Linode anymore. MediaTemple is stupid expensive for VPS... Maybe SoftLayer? I've heard mixed reviews.
It's kinda depressing that this article is basically just a copy of one I wrote in 2010 and it's still something that gets attention as interesting stuff. Nginx documentation obviously still has a long way to go.
I was more surprised than depressed about the upvotes for the current article. It really makes me wonder if the technical level of the audience here hasn't declined substantially. The current article is well written but it's aimed at a "Dummies" rather than developer level.
We were not aware of your article at all, and if it's "basically a copy" it was entirely coincidental. I think the way you're looking at is very negative though -- any and all efforts to improve understanding of a great and powerful dev tool I think are a positive thing for the community.
I'd love to see your article too, could you link to it?
It's not your article that's depressing, it's the fact that nginx documentation hasn't come further than this over the years. Obviously there's still a need for even basic nginx information and there's absolutely no blame from me for filling that need. If anything I should blame myself for not marketing my own stuff more. :)
I instantly thought of your article when I saw this one. I also defended NginX's documentation and linked to the actual documentation, which I think most people forget exists over at http://nginx.org/en/docs/.
The official nginx documentation is better but it's still mostly just an API documentation, there's no red thread through it to tell people "read this first, then this and then jump over here".
Since this kind of article still gathers this amount of popularity 3 years later I actually do think it's a problem of the documentation.
I've always wanted to use nginx to build web apps in Lua .. does anyone know/can recommend any great tutorials with this in mind? It'd be nice if I could learn how to use nginx+lua to build a blog, and so on .. I'll use google, but on the off chance someone on HN knows of something already, I'm all ears ..
You might be interested to know that NginX can even embed Lua internally as a scripting language in the configuration[1].
As for your goals of connecting NginX to serve your Lua project, well that's quite simple really. Unlike Apache or Lighttpd, NginX is not an application server. NginX is only a reverse proxying HTTP server that speaks HTTP, FastCGI, and UWSGI. To connect your Lua application to NginX, your Lua application will either need to speak HTTP, FastCGI, or UWSGI. I don't know anything about Lua so I can't really help you figure out which is best, but in terms of setting up with NginX, it mostly just changes which flavor of pass you will use.
This article is just fine for IDE-side development, but I would not recommend for anyone to use the version of nginx in the standard Ubuntu package manager. It traditionally is several version back missing important key features that you might want to take advantage of.
Slightly off-topic, but I'm sad that people still use apt-get. aptitude is pretty much just better[1].
Also, if you're reading this article you probably don't need the slightly better performance/throughput of nginx. Nginx's configuration is just terrible. You can cause segfaults and all sorts of unexpected behavior with the If directive[2]. And who came up with the idea that rewrite[3] should sometimes redirect instead of rewriting?
If the replacement string begins with http:// then the client will be redirected, and any further rewrite directives are terminated.
Apache's configuration might be ugly and unwieldy and the community might be horribly infested, but at least the configuration makes sense. Lighttpd has none of the above problems, though.
I'm extremely biased as I have been using NginX for many years now; however, I've got to completely disagree with you.
NginX's configuration is beautiful, elegant, and concise. It kicks the ever living crap out of configuring Apache or Lighttpd (the two other HTTPd's I have extensive experience with). It seems so strange, because it's different.
NginX's configuration language is declarative. If is imperative and actually using if inside locations in NginX creates an inner location and executes a mini language to process.
14:42 <+merlincorey> !ifisevil
14:42 < ngxbot> please see above
Finally, I have to disagree with OP... NginX has great documentation, written by Igor himself initially (and edited by the community) available here: http://nginx.org/en/docs/
Yes, I linked to IfIsEvil. The fact that you need a page to document the horrible behavior because it's too late to fix it is a sign that something is very wrong with the config syntax.
The fact that you think it is a problem with the configuration syntax is an indication that you didn't read the wiki page, or the important part of my comment.
NginX's configuration is declarative.
The reason the imperative if was given powers beyond its means was because people clamored for the feature.
The reason it's still there is because removing it would break some working configurations that use if.
If you don't have experience with declarative programming and you think in terms of imperative programming, it might seem "horrible behavior", but actually, it's what is to be expected from mixing the two paradigms in the way it is being mixed.
The real wart is under the hood where-in location based if's are converted to sub-locations. This is where many problems related to IfIsEvil stem from.
I'm rather annoyed that you're not reading anything I've said.
No, the problem is not that I haven't read the page. I have. It can cause segfaults. Your configuration can cause segfaults. Your configuration can cause segfaults. Your configuration can cause segfaults.
And yes, I acknowledged that they can't remove it because it's too late, using those exact words. That doesn't mean it's not a problem. It means you should jump ship to something saner, like lighttpd, which also doesn't have the rewrite-sometimes-redirects problem.
MY configuration never causes segfaults, because I understand the declarative nature of the configuration language, and I don't mistakenly attempt to shoehorn imperative constructs into it.
By your logic, software should not be written in C/C++, because it can cause segfaults!
> It means you should jump ship to something saner, like lighttpd,
Ah, you're a lighttpd guy. I'll stick with not having the http server also be an application server, and we'll agree to disagree.
I was using "your" in the third-person, a quirk of the English language that is too late to fix.
Configuration should not be able to cause your software to segfault. Configuration shouldn't be software. And, in case it's not clear, configuration should not be written in C/C++.
Aptitude is awesome and it's in my fingers, but it's slightly different from apt-get... which may turn into a problem if you do stuff with something like puppet, which uses apt-get.
I think I also had to install aptitude on this box (ub 12.04) as it only came with apt-get installed - apt-get is more universal.
Edit: Hrm. 'aptitude' is not the tool of choice for dist-upgrading Debian. I was fresh-installing my debian laptop last year from testing to sid and it was failing to work properly. Hunting down the issue online, it turns out that for dist-upgrades, you just use apt-get. One of those domain-knowledge gotchas :/ Used apt-get, and it went flawlessly.
Guys, don't link to the community wiki, it contains a lot of obsolete or just wrong information. Always use official documentation: http://nginx.org/en/docs/
I like this article because it reaffirms the demand for competent devops who've taken an afternoon to read all of http://wiki.nginx.org/DirectiveIndex.
Very nice article useful for Nginx newbies. While we are on that subject, can anyone please let me know if we can use Nginx for page cache busting purposes.
It is easy to configure Nginx to check if the cached version of the requested URL exists and serve it. But i would like to know if the configuration can be extended bit further to serve the cached file only if is less than a few days old?
Nice introductory article. Maybe it should have included a word about SSL support, especially the fact that you need to build nginx with ssl support, it doesn't come out of the box, so make sure you plan for when you'll need it
This is fantastic, thank you! The way it's written is great because it doesn't treat me like an idiot (I get why books do that, but it can grow tiresome). I wish more tech books were written like this.
While we're picking nits, I thought this might be worth mentioning:
http://tech.pro/tutorial/1335/devops-for-dummies-vps-configu...
It teaches you how to setup a DigitalOcean (or any other) VPS from scratch to host N amount of Rails applications using Nginx and Passenger. It took me some time to get things working properly and I distilled it into this short article that holds your hand and takes you from A to Z.