4 ms·

Some random selections from my notes on building Linode web servers: - Set up reverse DNS in the Linode manager: select the Linode, click on "Remote Access", c

Some random selections from my notes on building Linode web servers: - Set up reverse DNS in the Linode manager: select the Linode, click on "Remote Access", click on "Reverse DNS" (under "Public IPs") - Linodes don't offer very much disk space; use localepurge to keep the filesystem on a diet: # apt-get install localepurge - After installing and setting up MySQL, don't forget: # mysql_secure_installation - After installing Apache, change the following in httpd.conf: ServerToken -> Prod, ServerSignature -> Off, KeepAlive -> Off - After installing PHP, edit php.ini to make it shut up: expose_php -> Off There's a bunch of other fiddly stuff to do, and a seemingly endless combination of packages and strategies depending on what you're trying to accomplish. For instance, I currently run a stack with Postfix for MTA, awstats+jawstats for beautiful server-side site statistics, mod_deflate, mem_cache, fcgid/suexec to make it harder to break the server if a site is compromised, PureFTPd for really easy managed-by-MySQL FTP access, and a pile of other little minor tweaks and knobs turned. MOST IMPORTANTLY: Backups, backups, backups. If you don't already have your own in-house backup service for your server (and I bet you don't!), then please take advantage of Linode's backup services: http://www.linode.com/backups/ http://www.linode.com/backups/

nigma 14y ago
Why would you turn off KeepAlive instead of setting it to a small value?
- thaumaturgy 14y ago
  Honestly, I haven't done serious high-traffic testing to see if there's a magic number for KeepAlive. However, I've had enough traffic to the server on a couple of occasions that Apache would've fallen over if KeepAlive were on at all, since you can't specify KeepAliveTimeout in increments of less than 1 second. There are also quite a few Apache-tuning articles on the web that feature "turn off KeepAlive!" in big bold letters, not to mention previous discussion on HN: http://news.ycombinator.com/item?id=2588783 http://news.ycombinator.com/item?id=2588783, http://news.ycombinator.com/item?id=1980278 http://news.ycombinator.com/item?id=1980278, http://news.ycombinator.com/item?id=1875848 http://news.ycombinator.com/item?id=1875848, http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memory-constrained-vps/ http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memo... ...
sounds 14y ago
Two other suggestions would be: 1. Test how your VPS comes back after a reboot. When you make big changes and at least every 6 months due to all the upgrading that ubuntu does by default it can break the bootup process and you won't know until that emergency unscheduled reboot at 3AM. 2. As long as you're customizing the firewall you should block pings entirely. * Really, since the distributions are very compatible I would urge you to consider a distro that has selinux enabled by default. Fedora Core is a great place to start. It also has better tools to manage security and gives you good resume skills.
- darklajid 14y ago
  Why would you block icmp ping? I never understood that practice, especially not for standalone machines (in contrast to company networks, on the router). So, why really?
  - __alexs 14y ago
    I commonly see advice to block all ICMP traffic which is even crazier. I think perhaps the general suspicion of ICMP might be related to things like this http://en.wikipedia.org/wiki/Ping_of_death http://en.wikipedia.org/wiki/Ping_of_death which are now mostly irrelevant. Some sort of naive attempt to stop attackers mapping your network too perhaps? It's not exactly a high tech (or effective) means of intrusion detection though.
    - deleted 14y ago
      [deleted]
- thorduri 14y ago
  >> 2. As long as you're customizing the firewall you should block pings entirely. Why? I've never seen a threat model where filtering icmp doesn't end up being more trouble then it's worth. Then there is even the maintenance headache when basic but powerful tools like ping and traceroute are rendered useless. It's the same BS as with fail2ban, thankfully the OP wasn't spreading the gonorrhea of port knocking/single packet auth. Lock down your sshd like everything else: Disable root, disable tunneled cleartext passwords, enforce proper key usage, use AllowGroups/AllowUsers. EDIT: The BS with fail2ban is moving the ssh port around. I understand this being a problem, but surely iptables has something similar to OpenBSD pf's: block in quick from <brutes> pass in log on $if_ext proto tcp from any to ($if_ext:0) port ssh keep state \ (max-src-conn 3, max-src-conn-rate 4/32, overload <brutes> flush global)
epic9x 14y ago
Blindly turning off KeepAlive isn't a recipe for awesomeness. KeepAlive is a trade for memory/cpu time; on if you want to speed up in exchange for memory, off if you want to conserve memory and pay the cost of initializing new conections. If you're doing anything like loading a web page with more than a few images, KeepAlive will likely improve connection time as http requests things serially, and you'll have a speed up by re-using the same connection. Protip: run apache's mpm-worker with keepalive on and save memory and speed up your site.
- thaumaturgy 14y ago
  It just so happens that I have the very best test site possible for this argument: one of my alpha customers has a website built by Not-A-Professional with an incredible 156 requests and 2.39MB of data for the landing page. It is exactly the opposite of an optimized website. So I tested the page load with KeepAlive on and KeepAlive off. I `/etc/init.d/apache2 graceful`'d before each test, and I cleared Chrome's cache before each test. I have nothing else running on my system right now and our pipe is nice and clear. I have a 92ms ping from the office to my web server. KeepAlive On: 5.31s KeepAlive Off: 6.87s 1.5 seconds is an appreciable difference. It works out to roughly 10ms per request, unless it's so late that the math part of my brain has quit for the night. If Yahoo.com were loaded from my web server, having KeepAlive on would delay total page load by about 750ms -- a noticeable difference. (However, given that it takes over 4 seconds to reach page load on yahoo.com for 70+ requests, their page might actually load faster if it were hosted on my server...) Now here's the kicker: that same customer site has been featured on a popular radio show, twice, driving over 6 million hits over 24 hours, with peak traffic at 40Mb/s, thousands of simultaneous connections, and 100+ requests per second, sustained for several hours. The site's loading time during that period was utterly unaffected. Seriously, never even a blip. (I stayed up during the whole period just to personally watch it.) I wasn't about to experiment with turning on KeepAlive during all that fun, but I'm reasonably confident that having KeepAlive turned on would have crushed that server, given that my customer's site was receiving substantially more traffic than even Pinboard did immediately after the Delicious announcement (http://blog.pinboard.in/2011/03/anatomy_of_a_crushing/ http://blog.pinboard.in/2011/03/anatomy_of_a_crushing/) -- traffic that Pinboard's founder notes will usually kill an unprepared site (or server). And keep in mind, this was all on a memory-constrained tiny little vm. So here's my final statement on KeepAlive, which I will link back to from now on: if, as a server admin, you're turning KeepAlive on to speed up your site, then you are optimizing your server and your site in exactly the wrong way.
floomp 14y ago
> - After installing Apache, change the following in httpd.conf: ServerToken -> Prod, ServerSignature -> Off, KeepAlive -> Off > > - After installing PHP, edit php.ini to make it shut up: expose_php -> Off What is the purpose of this? Security by obscurity? Or being really frugal about header length?
- thaumaturgy 14y ago
  Yep, security by obscurity. AKA, the exact same reason that people move ssh to other ports. If it turns out that there is some kind of exploit floating around for a specific version of Apache or PHP, and if jackasses are looking for vulnerable servers by first looking at the server headers instead of just randomly targeting servers, then I want mine to be totally useless to them so that they (hopefully) just move on to some other poor schmuck's server. Security-by-obscurity is only a problem when you depend on it, or when you are using it to cover up some kind of serious stupidity, like totally untested crypto. There's nothing wrong with using it to frustrate and annoy adversaries.
pilif 14y ago
Regarding keep-alive: yes, it will lead to memory issues when it's on and you use mod_php and the prefork MPM (which you really have to with mod_php). But this is just one configuration. You can easily fix it by either of: - use php-fpm and switch to any other MPM in apache - keep using mod_php but put an nginx or other reverse proxy before apache. It will do the keep-alive and you can configure apache to still close it's connections. - use nginx and php-fpm directly All will mitigate the memory issue while still allowing you to offer keep-alive
- thaumaturgy 14y ago
  I think prefork/mod_php is still the default setup, and it's a really good one to get away from right away if you plan on handling any serious traffic. Using nginx/php-fpm is great, so long as you don't need support for Apache-style .htaccess files. Since I'm adminning a shared hosting environment, I can't give up support for .htaccess files; if you intend to only host your own site, and your site doesn't need that, then by all means please use nginx & php-fpm, you'll save yourself a lot of headaches. Setting up an nginx proxy seems like kind of a cheat in a discussion about tuning Apache -- "how to tune Apache: 1. don't tune Apache, set up nginx proxies instead..." -- but suffice it to say that setting up proxying nginx servers is on my to-do list. I have not yet though had a traffic-related site outage (see also http://news.ycombinator.com/item?id=4619906 http://news.ycombinator.com/item?id=4619906), so it's not as high on my list as things like "recurring payments system". :-)

nigma 14y ago

Why would you turn off KeepAlive instead of setting it to a small value?

thaumaturgy 14y ago
Honestly, I haven't done serious high-traffic testing to see if there's a magic number for KeepAlive. However, I've had enough traffic to the server on a couple of occasions that Apache would've fallen over if KeepAlive were on at all, since you can't specify KeepAliveTimeout in increments of less than 1 second. There are also quite a few Apache-tuning articles on the web that feature "turn off KeepAlive!" in big bold letters, not to mention previous discussion on HN: http://news.ycombinator.com/item?id=2588783 http://news.ycombinator.com/item?id=2588783, http://news.ycombinator.com/item?id=1980278 http://news.ycombinator.com/item?id=1980278, http://news.ycombinator.com/item?id=1875848 http://news.ycombinator.com/item?id=1875848, http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memory-constrained-vps/ http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memo... ...

sounds 14y ago

Two other suggestions would be: 1. Test how your VPS comes back after a reboot. When you make big changes and at least every 6 months due to all the upgrading that ubuntu does by default it can break the bootup process and you won't know until that emergency unscheduled reboot at 3AM. 2. As long as you're customizing the firewall you should block pings entirely. * Really, since the distributions are very compatible I would urge you to consider a distro that has selinux enabled by default. Fedora Core is a great place to start. It also has better tools to manage security and gives you good resume skills.

darklajid 14y ago
Why would you block icmp ping? I never understood that practice, especially not for standalone machines (in contrast to company networks, on the router). So, why really?
- __alexs 14y ago
  I commonly see advice to block all ICMP traffic which is even crazier. I think perhaps the general suspicion of ICMP might be related to things like this http://en.wikipedia.org/wiki/Ping_of_death http://en.wikipedia.org/wiki/Ping_of_death which are now mostly irrelevant. Some sort of naive attempt to stop attackers mapping your network too perhaps? It's not exactly a high tech (or effective) means of intrusion detection though.
  - deleted 14y ago
    [deleted]
thorduri 14y ago
>> 2. As long as you're customizing the firewall you should block pings entirely. Why? I've never seen a threat model where filtering icmp doesn't end up being more trouble then it's worth. Then there is even the maintenance headache when basic but powerful tools like ping and traceroute are rendered useless. It's the same BS as with fail2ban, thankfully the OP wasn't spreading the gonorrhea of port knocking/single packet auth. Lock down your sshd like everything else: Disable root, disable tunneled cleartext passwords, enforce proper key usage, use AllowGroups/AllowUsers. EDIT: The BS with fail2ban is moving the ssh port around. I understand this being a problem, but surely iptables has something similar to OpenBSD pf's: block in quick from <brutes> pass in log on $if_ext proto tcp from any to ($if_ext:0) port ssh keep state \ (max-src-conn 3, max-src-conn-rate 4/32, overload <brutes> flush global)

epic9x 14y ago

Blindly turning off KeepAlive isn't a recipe for awesomeness. KeepAlive is a trade for memory/cpu time; on if you want to speed up in exchange for memory, off if you want to conserve memory and pay the cost of initializing new conections. If you're doing anything like loading a web page with more than a few images, KeepAlive will likely improve connection time as http requests things serially, and you'll have a speed up by re-using the same connection. Protip: run apache's mpm-worker with keepalive on and save memory and speed up your site.

thaumaturgy 14y ago
It just so happens that I have the very best test site possible for this argument: one of my alpha customers has a website built by Not-A-Professional with an incredible 156 requests and 2.39MB of data for the landing page. It is exactly the opposite of an optimized website. So I tested the page load with KeepAlive on and KeepAlive off. I `/etc/init.d/apache2 graceful`'d before each test, and I cleared Chrome's cache before each test. I have nothing else running on my system right now and our pipe is nice and clear. I have a 92ms ping from the office to my web server. KeepAlive On: 5.31s KeepAlive Off: 6.87s 1.5 seconds is an appreciable difference. It works out to roughly 10ms per request, unless it's so late that the math part of my brain has quit for the night. If Yahoo.com were loaded from my web server, having KeepAlive on would delay total page load by about 750ms -- a noticeable difference. (However, given that it takes over 4 seconds to reach page load on yahoo.com for 70+ requests, their page might actually load faster if it were hosted on my server...) Now here's the kicker: that same customer site has been featured on a popular radio show, twice, driving over 6 million hits over 24 hours, with peak traffic at 40Mb/s, thousands of simultaneous connections, and 100+ requests per second, sustained for several hours. The site's loading time during that period was utterly unaffected. Seriously, never even a blip. (I stayed up during the whole period just to personally watch it.) I wasn't about to experiment with turning on KeepAlive during all that fun, but I'm reasonably confident that having KeepAlive turned on would have crushed that server, given that my customer's site was receiving substantially more traffic than even Pinboard did immediately after the Delicious announcement (http://blog.pinboard.in/2011/03/anatomy_of_a_crushing/ http://blog.pinboard.in/2011/03/anatomy_of_a_crushing/) -- traffic that Pinboard's founder notes will usually kill an unprepared site (or server). And keep in mind, this was all on a memory-constrained tiny little vm. So here's my final statement on KeepAlive, which I will link back to from now on: if, as a server admin, you're turning KeepAlive on to speed up your site, then you are optimizing your server and your site in exactly the wrong way.

floomp 14y ago

> - After installing Apache, change the following in httpd.conf: ServerToken -> Prod, ServerSignature -> Off, KeepAlive -> Off > > - After installing PHP, edit php.ini to make it shut up: expose_php -> Off What is the purpose of this? Security by obscurity? Or being really frugal about header length?

thaumaturgy 14y ago
Yep, security by obscurity. AKA, the exact same reason that people move ssh to other ports. If it turns out that there is some kind of exploit floating around for a specific version of Apache or PHP, and if jackasses are looking for vulnerable servers by first looking at the server headers instead of just randomly targeting servers, then I want mine to be totally useless to them so that they (hopefully) just move on to some other poor schmuck's server. Security-by-obscurity is only a problem when you depend on it, or when you are using it to cover up some kind of serious stupidity, like totally untested crypto. There's nothing wrong with using it to frustrate and annoy adversaries.

pilif 14y ago

Regarding keep-alive: yes, it will lead to memory issues when it's on and you use mod_php and the prefork MPM (which you really have to with mod_php). But this is just one configuration. You can easily fix it by either of: - use php-fpm and switch to any other MPM in apache - keep using mod_php but put an nginx or other reverse proxy before apache. It will do the keep-alive and you can configure apache to still close it's connections. - use nginx and php-fpm directly All will mitigate the memory issue while still allowing you to offer keep-alive

thaumaturgy 14y ago
I think prefork/mod_php is still the default setup, and it's a really good one to get away from right away if you plan on handling any serious traffic. Using nginx/php-fpm is great, so long as you don't need support for Apache-style .htaccess files. Since I'm adminning a shared hosting environment, I can't give up support for .htaccess files; if you intend to only host your own site, and your site doesn't need that, then by all means please use nginx & php-fpm, you'll save yourself a lot of headaches. Setting up an nginx proxy seems like kind of a cheat in a discussion about tuning Apache -- "how to tune Apache: 1. don't tune Apache, set up nginx proxies instead..." -- but suffice it to say that setting up proxying nginx servers is on my to-do list. I have not yet though had a traffic-related site outage (see also http://news.ycombinator.com/item?id=4619906 http://news.ycombinator.com/item?id=4619906), so it's not as high on my list as things like "recurring payments system". :-)