What are the basics of running a Web Server?
This is a proposed Canonical Question about Beginning Web Server Administration.
Assuming that you are a beginning SysAd, are new to WebOps, or a small team with little or no experienced Web Server SysAd support (and cannot afford it right now), what should you do to configure and secure a Web Server for your business?
Solution 1:
Before We Begin:
Having quality people will save you money. Just like having a good Lawyer (possibly NSFW for swearing) or an accountant, having a quality SysAd will probably save you money, often by simply helping you to avoid costly mistakes. You may not have the money to pay for the expertise now, but as soon as you can, you should make that investment.There is no simple, singular answer to this question. If you are one to ask this question, you must realize that this question is the core of a field that professionals invest years of study and practice in. The analogous question to a Developer would be "how do I write a Web Application?"; Sure, we could point you to a directions to installing Ruby-on-Rails and a RoR "Hello World". While that would 'answer the question', it wouldn't actually help you. This Q/A is an attempt to actually help you.
You should know:
Web Server Administration is a large topic, and it is intrinsically interweaved with many different disciplines. To do it well you will need a fundamental understanding of TCP/IP, your host OS, your WebServer Application, and some understanding of running the application stack.Be prepared to read. A lot.
Identify your needs:
Requirements
- Are you running a plain, static website (maybe with some Javascript effects), or
- (more likely) are you running an application that happens to have a web interface?
- Do you have persistent data? (Do you need a database?)
- Are there user credentials involved? Is there another reason that you'd need the connection between the user and website to be secured? (SSL)
- Are you handling payments of any kind? In addition to having SSL requirements, there are additional considerations that you'll need to research (dependent on region). These will also vary depending on the payment processor that you use.
Identify your stack:
How are you going to write and run this?
- Platform (Windows, Linux, other Unix, etc)
- App requirements (Ruby/Rails, Python, Perl, PHP, .NET, etc, etc)
- Database (...)
- Caching? (Honestly, don't worry about this now; be aware that this solves some problems, and can create others. This is a problem of performance, and right now you're just trying to get started.)
Some of these choices will inform others. For instance, If you're running a .NET app, you probably want to use MSSQL and IIS; If you're running Ruby on Rails, you probably want a Linux server; etc...
Get to Know your Product:
Now that you've decided on what your stack will look like, you need to get to know it. This is where you should spend most of your time. Searching for "Configure [product]" or "[product] Admin Guide" should get you plenty of resources.
For instance, if you are running Apache on Ubuntu, you should absolutely read:
- http://httpd.apache.org/docs/2.2/
- https://help.ubuntu.com/12.04/serverguide/httpd.html
Look for similar docs, articles, blog posts for your stack.
Install the bare minimum:
There is a vast array of modules for Apache, but if you're not going to use PHP (for example), don't install mod-php.
It also should be stated here that you should avoid installing a GUI if it's a Linux server; GUI's use up a significant amount of system resources.
Securing the site:
- Ensure minimal permissions to function. This applies not only to the filesystem, but also to services and processes
- Keep server ports disabled for unneeded services. (Again, only install the minimum.)
- Restrict application interfaces to the internal environment (if, for instance, running a web application on the same server (such as Rails), restrict it to only listen to localhost)
In Closing:
This is only the beginnings of what you should do to get a site up and running. This doesn't even begin to touch the problems of maintaining servers or how to handle problems of scaling (should your project become successful), nor any of the other myriad issues that a knowledgeable SysAd will solve for you.