about blog projects contact

The Cogwheel Blog

# Web Server Setup: A Descriptive Guide *Per the title, this is meant to be a ***descriptive*** (albeit ***nonexhaustive***)* *guide to setting up ***Apache*** and ***Nginx***, the two most popular* *web servers. I decided to collate my notes in the hopes of establishing an* *overall rationalization of setup steps rather than a checklist which* *can easily be sourced elsewhere. If you're looking for a mere checklist, read* *no further.* <div id="toc"> <p id="toc-header">Contents</p> <ol> <li><a class="toc-link" href="#background">Background</a></li> <li><a class="toc-link" href="#overview">Overview: Apache & Nginx</a></li> <li><a class="toc-link" href="#summary-comps">Summary Comparison</a></li> <li><a class="toc-link" href="#setup">Setup</a></li> <ul> <li><a class="toc-link" href="#installation">Installation</a></li> <li><a class="toc-link" href="#global-cfg">Set Global Configurations</a></li> <li><a class="toc-link" href="#virtual-hosts">Setup Virtual Hosts</a></li> <li><a class="toc-link" href="#wsgi">WSGI Applications</a></li> <li><a class="toc-link" href="#venv">Virtual Environments</a></li> <li><a class="toc-link" href="#firewalls">Firewall Settings</a></li> <li><a class="toc-link" href="#cfg-activate">Activating/Reloading Configurations</a></li> </ul> <li><a class="toc-link" href="#conclusion">Conclusion</a></li> </ol> </div> <a id="background"></a> ## Background <a class="toc-link" href="#toc">(Back to Contents)</a> Thanks to the growth of web-based applications and the proliferation of VPS/private cloud providers, there is no shortage of documentation on setting up web servers, the software which handles incoming http requests from clients. From firewall settings to Unix socket management, there is a step-by-step manual out there to guide you every step of the way on what was once largely relegated to the domain of the mysterious and reclusive sysadmin. Some VPS providers have been especially active on this front, motivated by the prospect of increased subscriber numbers/accounts via the elucidation of these once arcane steps. Adding to this literature is the seemingly endless regurgitation of these steps in blog posts for which the vast majority appear to be ***blogging for*** ***blogging's sake*** rather than any insightful commentary on the purpose or meaning behind the steps involved. To be sure, the task at hand does indeed require a list of tasks to be performed and it's helpful to maintain checklists for these along the way. However, I can't help but feel that one might be better served by an understanding of the *reasoning* behind these key steps. Grasping the rationale of the setup in this way may help avoid redundant cross-checks of the steps it appears many of the list-only guides appear to be serving. As such, I offer below a summary web server setup *alternative guide* (a verbose commentary-filled read which will hopefully facilitate key concept retention better than performing a rote list of steps) for Apache and Nginx, the two most popular web servers. <a id="overview"></a> ## Overview <a class="toc-link" href="#toc">(Back to Contents)</a> To put things in context for the descriptive steps ahead, it helps to have a little background knowledge about these web servers which I present here in broad brush strokes (skip at will, if you are already familiar with background information on these web servers). ### Apache Written by Robert McCool after splitting from the [NCSA HTTPd project](https://en.wikipedia.org/wiki/NCSA_HTTPd), Apache was released in 1995 and underwent a major upgrade in 2002 to accommodate multithreading and filtering and a license upgrade in 2004 to the Version 2.0 Apache Software Foundation license. Thus, all processes, directory names, etc. are called 'apache2', (not 'apache'). Apache evolved in tandem with the *Common Gateway Interface* or CGI (itself authored in part by Apache's creator), the original protocol which standardized the communication between web server software (like Apache) and webpage generating scripts like Perl (at the time) and the likes of PHP, Python today. Its architecture consists of a small core to handle http request/response processing surrounded by a satellite of modules ('mods') to extend this core functionality. One key advantage is that a language processor of choice can be embedded within Apache by installing modules like mod\_python which means execution of dynamic content can take place internally within the web server without the need for any further configuration. This process can be made yet more efficient by way of installing other complementary third-party modules like *mod\_wsgi* (the Web Server Gateway Interface for Python, as an example) which standardize scripting language - web server communication. Apache's traditional architecture to answer http requests involved spawning new processes which meant resource consumption increased with the number of connections made to the server, in contrast with the Nginx approach (see below). The development of FastCGI, an alternative to CGI which keeps a persistent process running that itself handles tasks via multiple threads (thus dramatically lowering the process-spawning overhead associated with pure CGI) has mitigated, though not entirely eliminated, this performance drawback. Version 2.4 introduced the Event MultiProcessing Module (MPM) to fix performance bottlenecks when serving static pages. Nevertheless, Apache is still perceived to be better at handling server-heavy tasks (such as those involving database transactions or calls to server-side routines in the application) and thus better suited for handling dynamic websites. ### Nginx Developed in 2002/released in 2004 by the Russian Igor Sysoev, Nginx rose to the challenge of solving the 10k concurrent connection problem which was a limitation many web servers had at the time (including Apache). Nginx was built specifically with the intention of beating Apache at its own game. In contrast to Apache, Nginx's architecture is one of an asynchronous event driven model in which individual worker processes can handle thousands of threads by way of a rapid looping process which checks for incoming requests and processes them as it catches them. Events (connections) within the loop are served asynchronously in a non-blocking manner and then removed when the connection is closed. The result is a small memory footprint and more predictable resource consumption which translates to easier scalability as compared with Apache. The Python WSGI standard proved so successful that it spawned the popular server container *uWSGI*, itself written in C, which acts as a universal Python interpreter for a variety of application languages and processes incoming requests by invoking the Python-equivalent callable. Nginx boasts native support for *uwsgi*, the very fast binary communication protocol of uWSGI. While Apache modules supporting uwsgi do exist, they are perceived to be [awkwardly implemented](http://uwsgi-docs.readthedocs.io/en/latest/Apache.html), in comparison. Speed aside, given that Apache modules can run scripting languages, a lot of the heavy lifting for server-side back-end applications (thus dynamic sites) tends to be delegated to Apache whereas Nginx is perceived to be the better choice for serving static contents at scale (and speed). In fact, many Nginx configurations hand off such server-side tasks to other processes and/or Apache itself. The traditional rivalry between these two web servers has evolved in recent years to a complementary approach wherein Nginx may well serve as a reverse proxy for and/or load balancer in front of Apache. Nginx themselves expresses the desirability for this complementary approach in their [own documentation](https://www.nginx.com/blog/nginx-vs-apache-our-view/). <a id="summary-comps"></a> #### Summary Comparison: <a class="toc-link" href="#toc">(Back to Contents)</a> ***Apache:*** * most popular (40-50% of websites, depending on poll) * multi-process architecture is resource-intensive * satellite modules for extensibility (including FastCGI) * performance drag with many connections for static sites * good for server-side heavy (dynamic) applications ***Nginx:*** * second most popular (20-30% of websites, depending on poll) * event driven aysnch model means low memory footprint * FastCGI, WSGI and uWSGI-native * higher performance serving static than Apache * hands off server-heavy transactions to other processes (incl Apache) <a id="overview"></a> ## Setup <a class="toc-link" href="#toc">(Back to Contents)</a> *Note: to simplify things, I assume an Ubuntu Linux distribution for the steps* *which follow. (Naturally, the choice of OS will impact configuration options* *but I have tried to keep the following commentary as OS-agnostic as possible,* *except where noted):* </br> <a id="installation"></a> ### 1). Install Apache and Nginx: <a class="toc-link" href="#toc">(Back to Contents)</a> <pre class="snippet"> sudo apt-get install apache2 sudo apt-get install nginx </pre> Enough said. </br> <a id="global-cfg"></a> ### 2). Set Global Configurations: <a class="toc-link" href="#toc">(Back to Contents)</a> As a first step, we need to set some high-level configurations for both Apache and Nginx. Despite being very top-of-the-trees, they are crucially important. For instance, we need to specify the directory for error logs. If we don't know the location of the error logs, we won't be able to track down errors and debug issues if and when they crop up. Assuming the web servers were installed using default settings, the *global* configuration files for each web server will be the following files: <pre class="snippet"> /etc/apache2/apache2.conf /etc/nginx/nginx.conf </pre> *(Recall the '/etc' directory is the applications configuration directory* *in Linux systems. Also note that modifications to configurations files here* *typically require admin/superuser privileges, thus on Ubuntu you'll need to* *prefix editing commands with 'sudo').* While these files differ in their structure and content, they conveniently allow for configurations to be specified in space separated key-value couplings as in: <pre class="snippet"> ``` <parameter> <argument> ```</pre> Both Apache and Nginx allow for the *include* directive which means that further configurations can be loaded as sourced from the indicated directory and/or file argument following the include keyword, as in: <pre class="snippet"> include /path/to/my/dir/or/file </pre> For *many* (though not necessarily *most*) use-case scenarios the default settings in these global configuration files tend to serve just fine the way they are. Between the two of them, the apache2.conf file is heavily commented right out of the box; thus, plenty of guidance is available in these comments for various settings (nginx.conf comments are more terse in comparison, but this is mitigated by the self-explanatory names of the directives in it). The operative attribute of the apache2.conf file is that it acts like a spine which includes other apache configuration files, namely: ports, mods-enabled, conf-enabled, and sites-enabled configuration files (more on these later). Directives in the nginx.conf global configurations file, by contrast, come grouped in three sections, which we'll also look at more closely. </br> #### Global Configurations: Common Concepts Ignoring comments and their default listed order, some important configuration settings in the **apache2.conf** file are as follows: <pre class="snippet"> User ${APACHE_RUN_USER} Group ${APACHE_RUN_GROUP} PidFile ${APACHE_PID_FILE} ErrorLog ${APACHE_LOG_DIR}/error.log IncludeOptional conf-enabled/*.conf IncludeOptional sites-enabled/*.conf KeepAlive On KeepAliveTimeout 5 </pre> Note the similarity to their counterparts in the **nginx.conf** file: <pre class="snippet"> user www-data; pid /run/nginx.pid; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/* keepalive_timeout 65; </pre> As can be seen from these global settings, both Apache and Nginx allow values for user run-profiles to be set here. The Apache settings in curly brackets are environment variables that were established during installation but the parameters are similar (indeed, the default Apache user is even 'www-data', per the default entry in the ngfinx.conf file). Both files allow for configuring where the process id file is to be written which is useful for monitoring purposes and the access and error log locations may also be set here. While there is no access log file configuration in the apache2.conf file, the default location is merely the apache2 counterpart to the setting in the nginx.conf file, namely: **/var/log/apache2/access.log**. **Available vs. Enabled** In both the Apache and the Nginx ecosystems, sites and configurations must first be made available before they can be enabled. What this means is that both web servers take advantage of *nix environments wherein symbolic links to physical directories/files determine what components are made 'active' or 'enabled'. Thus, a configuration for a certain site must reside in a directory (conventionally annotated as 'available' in the web servers' parlance) but the site is not made active unless a symbolic link pointing to it is also included in the directory annotated as 'enabled'. This is a convenient way for site administrators to control what sites or configurations they wish to make active (enabled). By simply creating or removing a symbolic link, they can switch the site/configuration's status on or off without having to delete/modify the underlying files/directories. The 'include' and 'IncludeOptional' directives in the global configurations file specifies the location of the enabled configuration and sites directories. **Virtual Hosts** The concept of a *Virtual Host* is another characteristic these two web servers have in common. Similar in concept to *virtual environments*, virtual hosts, configured by virtual host files, allow both Apache and Nginx to be configured for multiple sites which may require separate configurations. These are the meat and potatoes of site configurations for both servers which will require more delving into but for now note that the configuration files for virtual hosts reside *sites-available* sub-directories for each server (and also the *sites-enabled* sub-directory as symlinks if they are enabled/active). Now that we've seen the common configuration directives between the two web servers, let's have a look at what makes them different. *(Note: I only touch upon what I consider to be ***salient*** characteristics* *of each web server's setup, not every detail. As such, the usual caveat* *applies here: please refer to the official documentation for more information)* </br> #### Global Configurations: Disparate Concepts ***Apache-Specific:*** <pre class="snippet"> Include ports.conf IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf AccessFileName .htaccess Timeout 300 MaxKeepAliveRequests 100 Mutex file:${APACHE_LOCK_DIR} default HostnameLookups Off LogLevel warn </pre> As noted in the background section, Apache's core functionality is extended by modules or 'mods.' A default set of modules comes with the Apache installation but other non-standard/custom modules may be installed to further extend functionality. These reside in the mods-available and mods-enabled child directories. The *.load files govern how the module is loaded into Apache while the *.conf files specify how the modules are to be used within it. The *.htaccess* files is a somewhat outdated configuration file that enables configurations changes to be made to virtual hosts for setups in which site administrators may not have root access on the server system to edit the virtual host configuration file directly. Apache advises against use of the .htaccess file but it should be noted that it *can* exercise an override for uses such as permissioning if configured to do so. Since it overrides the host configuration files, it should be used with care (if at all). There is no such equivalent in Nginx. A key setting we should pay attention to is the ports configuration. From the outset, Apache requires that we specify what ports it is meant to listen on for HTTP connections. This is specified in the: <pre class="snippet"> /etc/apache2/ports.conf </pre> file and is by default port 80 (for HTTP). If you are pursuing a non-standard setup which might require another port entry, such as perhaps a simultaneous installation of Nginx which does not act as a reverse proxy for Apache, you may need to edit this so that it listens on a different port from the one Nginx is configured to listen on. Miscellaneous other settings hint at some of Apache's limitations as a web server, specifically with regard to its multi-process (and blocking) architecture. For instance, the *KeepAlive*-related settings are used to configure keeping open a given TCP connection between Apache and a remote client to improve efficiency and to override the default behavior of an HTTP connection to close upon transfer of a file. However, there is a limit to how many of these may be kept open after which the server would not be able to accept any more HTTP connections. A good description of this may be found [here](https://www.nginx.com/blog/http-keepalives-and-web-performance/). </br> ***Nginx-Specific:*** <pre class="snippet"> --first section: worker_processes auto; --events section: events { worker_connections 768; # multi_accept on; } http { ...; server_names_hash_bucket_size 64; ...; include /etc/nginx/mime.types; ...; } </pre> As mentioned before, the nginx.conf file comes in three sections and these Nginx-only directives stand out (again, refer to the official documentation for information on the other settings). The worker-process variable specifies how many simultaneous threads of nginx to run. Nginx's own documentation says this should correspond to the number of cores available on the server. Setting this to 'auto' will instruct Nginx to fetch this information and set this variable automatically. The events variable is a reference to incoming/client-generated traffic. You can set the maximum number of worker connections in this section as well as permission a worker process to accept multiple connections in the multi_accept parameter. The hash bucket size parameter is generally commented but it may be worthwhile to *uncomment* this parameter so as to avoid running into hash memory bucket issues. This is just the memory allocated by Nginx to look up the servers in a hash table it uses for this purpose. Finally, the mime.types file setting is a path to a file which by default is itself replete with many file format settings. Since these run the gamut from txt, html, css to gzip and others, there's a fair chance that it will include many file format requirements but may be referenced/edited to ensure it meets your very specific needs. <a id="virtual-hosts"></a> ### 3). Setup Virtual Hosts: <a class="toc-link" href="#toc">(Back to Contents)</a> Both Apache and Nginx come with default virtual host files which may be used as templates for setting up your own virtual hosts. To repeat, a virtual host file is the configuration file which defines your sites' particulars, such the port it should be served on the server, what the domain name is, and the like. The sample host files are heavily commented and the recommended practice is to copy the default sample files to use as boilerplates to modify as you desire. The files in question are: <pre class="snippet"> /etc/apache2/sites-available/000-default.conf /etc/nginx/sites-available/default </pre> Let's have a look at these without the comments. ***Apache:*** <pre class="snippet"> ``` <VirtualHost *:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> ```</pre> ***Nginx:*** <pre class="snippet"> ``` server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html; index index.html server_name _; location / { try_files $uri $uri/ =404; } ```</pre> Here again the two web servers share some commonality in the configuration of virtual hosts. As can be seen from the two files, configurations which set the server (hostname) and document root serve the same function in both cases. Ports to listen to for the specific host are also set in these files. For **Apache** this happens in the line: <pre class="snippet"> ``` <VirtualHost *:80> ```</pre> whereas for **Nginx** this is configured in the line: <pre class="snippet"> ``` listen 80 <...>; ```</pre> By default, both Apache and Nginx expect website directories to be housed in the '/var/www' or 'var/www/html' directory. Indeed, default installations of each web server will result in a generic "index.html" file being placed in the latter so that when the web server is activated and configurations are read, a the corresponding Apache or Nginx welcome page will appear in the browser, if the web server has been set up successfully. The ability to specify virtual hosts for both Apache and Nginx means that multiple domains/sites can be hosted by one the same server with each host having its own configuration file. For instance, the relevant Apache entries would look something like: <pre class="snippet"> ``` ServerName www.apache1.com DocumentRoot /var/www/apache1.com ServerName www.apache2.com DocumentRoot /var/www/apache2.com ```</pre> Similarly, Nginx entries would look something like: <pre class="snippet"> ``` root /var/www/ngix1.com; index index.html; server_name www.ngix1.com; root /var/www/nginx2.com; index index.html; server_name www.ngix2.com; ```</pre> The default document root directories need not be used for host sites; however, alternative locations should be chosen carefully as the original intent was to disallow access to the root filesystem outside of these directories for security reasons to prevent, for instance, the likes of [directory traversal attacks](https://en.wikipedia.org/wiki/Directory_traversal_attack). As can be seen from these configurations, the document root directory is configured directly within the host files (which would override any other document root directories specified elsewhere, as with Apache global configurations). For Apache host configurations serving files outside of the default directory requires an *alias* entry along with permissioning to override the default access settings, like so: <pre class="snippet"> ``` Alias "/otherRoot/" "/otherRoot/path/to/my/project/" <Directory "/otherRoot/path/to/my/project/"> Order allow,deny Allow from all Require all granted </Directory> ```</pre> *(Note: for versions of Apache 2.4 or above, the directory permissions syntax* *changed from 'Order allow,deny Allow from all' to 'Require all granted').* One Nginx-specific host file configuration is the entry: <pre class="snippet"> ``` listen 80 default_server; ```</pre> This is meant to serve as the fallback/default server name in the event that a client connection should be attempted to an invalid endpoint on the server. This is more a legacy configuration as nowadays clients are likely to attempt connections using names, meaning such failures are likely to be extremely rare. <a id="wsgi"></a> ### 4). WSGI Applications: <a class="toc-link" href="#toc">(Back to Contents)</a> *At this point, I would like to digress a bit from my application-agnostic* *approach to include a few tips on setup-related issues pertaining to* *Python-specific web applications. Full disclosure: the need for me to detail* *these arises from my own Python-centric development tendency.* If you're serving a Python-based or other WSGI-protocol compliant application, some modifications to the default setup steps described above are in order. ***Apache*** For the Apache web server, the *mod_wsgi* module must first be installed, ergo: <pre class="snippet"> apt-get install libapache2-mod-wsgi </pre> Next, a *.wsgi file must be created in the project directory. This file will be the entry point into the web application/site-project. Thus, a sample wsgi file called 'controller.wsgi' might have the following full path: <pre class="snippet"> /var/www/www.apache1.com/controller.wsgi </pre> Edit this file so that the top of it reads as follows: <pre class="snippet"> import sys sys.path.insert(0, '/var/www/www.apache1.com') </pre> ( where /var/www/www.apache1.com is the path to the project folder ). The Apache host file configuration would also require modification to add the following lines: <pre class="snippet"> ``` <VirtualHost:*80> WSGIDaemonProcess appName user=user1 group=group1 threads=5 WSGIScriptAlias / /var/www/www.apache1.com/controller.wsgi </VirtualHost> ```</pre> where appName is the name of the application which must be run in order to serve the site. ***Nginx*** The modifications required to run a WSGI application in Nginx differ from those in Apache server. Recall from the introduction that Nginx has native support for the uwsgi wire communication protocol. However, the project environment (whether virtual or physical) must also have uwsgi installed. For Python-based applications, this can be installed using the pip installer: <pre class="snippet"> pip install uwsgi </pre> A quick test to serve the application on localhost (port 5000) from the command line may then be run as follows: <pre class="snippet"> uwsgi --socket --protocol=http -w wsgi:app </pre> where app is the name of the application (without extension). If the project is in a virtual environment, the environment should first be activated before running the above command. Once this is working, we will need to create a uWSGI configuration file for use with Nginx. Like the sample *.wsgi file per our Apache example, this file will reside in our project directory but with an *.ini extension as this will later be used as an argument into a systemd file which is responsible for launching processes upon server reboots. A sample ini file may look as follows: <pre class="snippet"> [uwsgi] module = wsgi:appName master = true processes = 5 socket = www.nginx1.com.sock chmod-socket = 660 vacuum = true die-on-term = true </pre> where the header signifies the file is a *uwsgi* configuration files and appName is the name of the application serving the site. The remaining specs instruct Nginx to launch a master process to supervise worker processes spawned, processes indicates the number of processes to spawn, socket is the name of the Unix socket the uwsgi protocol is instructed to create/use which is subsequently permissioned for use with chmod. Finally, the parameters vacuum means to clean up on closed/interrupted connection and die-on-term means to kill the process if manually terminated, per expected behavior. A systemd service file (nginx1.service) file may then be created as follows: <pre class="snippet"> ``` [Unit] Description=uWSGI instance to serve nginx1 project After=network.target [Service] User=<user> Group=www-data WorkingDirectory=/var/www/www.nginx1.com Environment="PATH=/var/www/www.nginx1.com/virtualenv/bin" ExecStart=/var/www/www.nginx1.com/virtualenv/bin/uwsgi --ini controller.ini [Install] WantedBy=multi-user.target ```</pre> One helpful resource which details the use of Python-based web applications and their uWSGI configuration requirements for Nginx can be found [here](https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uwsgi-and-nginx-on-ubuntu-16-04). Finally, the corresponding uwsgi entries will need to be added to the Nginx virtual hosts file to ensure that Nginx serves our application through the uWSGI entry point. Specifically, note that we need to further qualify the **location setting** in our Nginx host file to read along the lines of the following: <pre class="snippet"> server { ...; ...; location / { include uwsgi_params; uwsgi_pass unix:/var/www/www.nginx1.com/www.nginx1.com.sock; } } </pre> This invokes the uwsgi parameters and specifies the socket connection over which Nginx should communicate with the application. <a id="venv"></a> ### 5). Virtual Environments: <a class="toc-link" href="#toc">(Back to Contents)</a> If your application folder has been setup to run in a virtual environment, then still more modifications need to be made to these setups. For Apache, these two extra lines are required at the top of our wsgi file: <pre class="snippet"> activate_this = '/var/www/www.apache1.com/virtualEnvDir/bin/activate_this.py' execfile(activate_this, dict(__file__=activate_this)) </pre> This is required so that Apache executes code within the virtual environment rather than in the physical/non-virtual project path where one or more required components may be missing for functionality of the site. Under Nginx, note that our \*.service file sets the *Environment* variable to the virtual environment path in the www.nginx1.com directory: <pre class="snippet"> ... Environment="PATH=/var/www/www.nginx1.com/virtualenv/bin" ... </pre> thus ensuring the application runs from within the virtual environment setup. <a id="firewalls"></a> ### 6). Firewall Settings: <a class="toc-link" href="#toc">(Back to Contents)</a> With our Apache and Nginx global configurations set, our virtual hosts files configured, and WSGI-specific and virtual environment settings/configurations in place, we have to ensure our firewall settings are correctly permissioned. Under Ubuntu distributions, this is where the 'ufw' utility comes in handy. Per some of the other setup steps reviewed thus far, changing firewall settings will require super user privileges, hence the 'sudo' prefix for the following commands. The command is simple and is as follows: <pre class="snippet"> ``` sudo ufw allow <port> ```</pre> If our requirements are that we must allow incoming traffic on ports 80 and 8080, for instance, then we would simply run the following commands: <pre class="snippet"> sudo ufw allow 80 sudo ufw allow 8080 </pre> Of course, this assumes our firewall is enabled. If not, *take care to ensure* *that it is configured with all the correct settings ***before enabling**** so as to avoid undesirable outcomes like being locked out of your own server(!) A shorthand available for Nginx ufw use is: <pre class="snippet"> sudo ufw allow 'Nginx Full' </pre> This will enable Nginx for both HTTP and HTTPS (the secure/encrypted protocol we have *not* touched upon here). To check that your ports are open, you can run the following command: <pre class="snippet"> sudo ufw status </pre> to see a list of active ports. For more on using Nginx as a reverse proxy for Apache (rather than merely listening on different ports), [here](https://lukearmstrong.github.io/2016/12/use-nginx-apache-at-the-same-time/) is a good article for that. <a id="cfg-activate"></a> ### 7). Activating/Reloading Configurations: <a class="toc-link" href="#toc">(Back to Contents)</a> Bear in mind that whenever a change is made to a configuration file or a host file is added, configurations will need to be re-read by the corresponding web server. Sometimes this may mean stopping/restarting the web server while other times it might mean just forcing configurations to be reloaded. Both Apache and Nginx come with a set of very handy utilities for these. As with other facets of these two servers, these also resemble each other. Some utilities for Apache are as follows: <pre class="snippet"> sudo a2ensite www.apache1.com sudo a2dissite www.apache1.com sudo systemctl start apache2.service sudo systemctl stop apache2.service sudo systemctl restart apache2.service </pre> These commands enable (creating a symlink in enabled directory), disable, start, stop, and restart Apache respectively. The Nginx equivalents are: <pre class="snippet"> sudo systemctl start nginx sudo systemctl stop nginx sudo systemctl restart nginx sudo systemctl reload nginx sudo systemctl disable nginx </pre> Similarly, these commands tart, stop, restart, reload, and disable Nginx. Enabling/disabling is a manual process of creating/destroying symbolic links. <a id="conclusion"></a> ## Conclusion <a class="toc-link" href="#toc">(Back to Contents)</a> Despite the disparate architecture of the Apache and Nginx web servers, I have attempted to present here the overlapping set of configuration requirements involved in setting up each web server. I have also attempted to contrast the important respects in which their setup requirements diverge from each other. In so doing, I have attempted to convey a rationalization of the setup steps involved - taken as a whole - in order to facilitate *key concept retention* better than might otherwise be possible when following a mere checklist of steps alone. I hope you find this descriptive guide to be as helpful to you as it was to me. For official documentation on these two web servers, see: [Apache](https://httpd.apache.org/) and [Nginx](http://nginx.org/).

-A. Ozan Akcin