In this chapter, you learn how to install Apache safely on macOS, Linux, and Windows and get it up and running in its default configuration.
At the end of this chapter, you’ll be able to load up your browser and visit http://localhost/ to see a running default installation of Apache. But before we dive headlong into the guts of Apache, let’s do a little review to get everybody up to speed.
How Web Servers Work
A work flow explains the actions that happen before a web browser displays the web page where the web server retrieves the file from the storage, scripting engine executes the programs, and sends the contents to the web browser.
A typical workflow for showing a web page
The HyperText Transfer Protocol
A network is best thought of as a combination of communication layers; each layer represents a method of communication and is assigned a unique connection point known as a port number; there are 65,536 ports available in all, and many of those are reserved for known network protocols. One of these reserved ports is for HyperText Transfer Protocol (more commonly known as HTTP), which communicates on ports 80 and 443 (other examples of TCP ports include POP email (port 110) and FTP (which uses ports 20 and 21)).
The transaction starts when the browser requests a file from the web server (GET http://www.apachebook.com/index.php). When this request is received, the web server checks to see if the file exists at the location specified and if the browser has permission to view the page. If an error is encountered, the web server will return the error to the browser, often followed by a brief explanation of the error. The most common of these errors is 404 (file not found), 403 (forbidden), or 500 (script error).
A full list of the HTTP error codes can be found in the appendix.
A (Very) Brief History of Apache
In June of 1991, the first web server was born in the most ironic of locations. In a room at CERN (a particle physics laboratory in Geneva, Switzerland), the first version of httpd (HyperText Transfer Protocol Daemon) was created. Little did they know they would be opening the door to an entirely new universe. Or, maybe they did; it was a physics lab, after all.
Tim Berners-Lee, the creator of the Web, first started working on the basic concept of linked documents as early as 1980 while on a short contract with CERN. While there, he created Enquire, a program used privately to store information using random associations. Though never published, a seed was planted firmly in his mind. When he returned to CERN in 1989, he brought a massive improvement to Enquire.
The World Wide Web (WWW), as Berners-Lee called it, was Enquire on a global scale. The basic idea behind WWW was to allow a group of high-energy physicists to combine their knowledge into a library of interconnected work. Are you referring to a colleague’s paper on quantum mechanics? Why merely cite the paper and leave it up to the reader to search through a library for it when you can just provide a link to it within your own paper?
In 1991, after a year or so of internal development at CERN, Berners-Lee released httpd (the first web server) and WorldWideWeb (the first web editor and incidentally the first WYSIWYG editor) to the public at large through the Internet and made their own HTTP server publicly accessible. The idea hit the ‘net and exploded. According to Berners-Lee, the load on the CERN web server grew by a factor of 10 every year. Berners-Lee spent the next three years defining the language of the Web—HTML—and further developing the httpd web server, working heavily with feedback from the Web’s early adopters.
Around the same time, the National Center for Supercomputing Applications (NCSA) was working on its own version of the httpd server. Complaining that the CERN web server was “too large and complex”, Rob McCool (yes, his actual name) worked with several others at NCSA to create a leaner, simpler version of the web server. He worked on NCSA’s web server until 1994, when—as Apache’s timeline states—he “left to get a real job.” (In fact, he left to help form Netscape, one of the first widely-used commercial web browsers).
When Rob McCool left the httpd project, development crept to a halt. By early 1995, as the Internet became more accessible to the general public, use of the Web started booming, and webmasters soon discovered that httpd could no longer serve their needs adequately. As a result, in February 1995, eight brave souls started working together to develop the next generation of web servers—Apache. Working from the source code for httpd, these developers started writing patches to the NCSA httpd server (and according to Apache’s history, the name “a patchy server” was born). In April 1995, the group made the first official public release of the Apache web server.
Over 25 years later, it is a thriving open-source community project with hundreds of developers regularly contributing source. In 1999, the Apache Software Foundation (ASF) was created as an official entity to help organize developers and provide legal and financial support. Apache powers more than 286 million sites, and it serves 45% of the Web’s busiest sites.1 It’s available for any operating system that has networking, including Linux, Windows, macOS, and even long-lost systems like OS/2 and BeOS.
Before You Begin…
Like any grand adventure, there are some things you must prepare before you embark on your quest. You’ll want to keep notes, become familiar with your operating system’s terminal or command line, gather documentation, and do resource planning.
Keep Notes
Keep running notes in your favorite notes application or desk-side notebook. There will be several points throughout this book where you must refer to various directories and configuration options, and having quick access to these will be helpful.
Get Familiar with Your Terminal
Regardless of which operating system you choose to install Apache, you must be comfortable with the command line or terminal. This text-only interface to your computer unlocks the ability to access parts of your computer that are normally hidden behind your desktop UI. For macOS, Linux, and Windows (using the Linux subsystem), this is critical for accessing and editing the configuration files for Apache and other elements.
As you move through this book, several examples use the command line to access and modify configuration files. It’s highly recommended that you become comfortable starting up a terminal and learning its basic commands.
On macOS, the command line is accessed through Terminal, which can be found in the Applications ➤ Utilities folder in Finder. You can also use Spotlight to find the Terminal application quickly.
On Windows, the command line is accessed through the command prompt (cmd.exe), which can be found in the Windows System folder in the Start Menu. You may also install PowerShell through the Windows Store, which provides some extra tools for navigating the command line.
On Linux, the command line is accessed directly (if no desktop GUI is installed) or through a terminal application. On Ubuntu, this can be found by clicking Show Applications, opening the Utilities folder, and clicking Terminal.
Several courses and resources are available to help you learn about the command line, such as tutorials by Ubuntu2 or The Odin Project3 for UNIX-based terminals and Microsoft’s documentation for its command prompt and PowerShell.4
Be Prepared to Read Documentation
Homebrew: https://docs.brew.sh
XAMPP: www.apachefriends.org/docs/
Ubuntu: https://help.ubuntu.com
What to Know Before Installing Apache
There are a few things you need to consider before installing Apache. These include which operating system to use, what additional software is needed, and which version of Apache to install.
How complex is your site? The more complex the site, the busier the web server. If you are experiencing heavy traffic, the web server slows down significantly. It also needs more RAM to keep the site in its working memory. The best way to mitigate this is by increasing the amount of RAM allocated to the server.
Which scripting environments are currently being used for the website? Apache supports most scripting environments (PHP, Node.js, etc.), and some run better under Apache. Apache can even be configured to indirectly support .NET (C#) sites, though it requires a more advanced setup than what’s covered in this book.
How large is the website, and how long do I want to keep server logs? With the growth in services like Amazon S3 and advances in hard drives, storage drive space is cheaper than ever. Add as much hard drive space as you can afford to. Modern websites often have significant storage needs for uploaded assets, frameworks, and libraries. You also want to provide space for your website’s logs. The longer you keep log data, the more information you have to work with when building website statistics or troubleshooting issues.
Who do I want to have access to the web server? This is probably the most important question to ask. Anyone who has access to the web server machine also has access to the website stored on it. Though you can secure the website’s directories under both Linux and Windows, it’s not 100% secure so long as a user has access to the drive. If you use tools like ngrok or port forwarding on your router to provide outside access to your web server, this is especially important. That said, you will most likely be setting this up on a personal laptop or desktop machine, using Windows or macOS. Going forward, this is referred to as your development environment.
Using the Right Development Environment
It’s never a good idea to make changes to your live website. Your website is your organization’s digital presence in the world; you only want to update it when you are completely certain your code is good and bug-free.
Deployment Environments
Environment | Description |
|---|---|
Local Development | This is a sandbox for the developer to test code on as they write it. This is often their desktop or laptop, though a dedicated computer on their network may also be used as a development environment (a Raspberry Pi, for example). |
Testing | The environment where more formal testing is performed. A quality control team ensures that the new code does not impact the existing functionality and tests major functionalities of the system after deploying the new code in the test environment. It is most commonly a server located within a corporate network or on a dedicated server outside the network. |
Staging | A mirror of the production environment used for user acceptance and validation. It is generally available over the Internet but hidden from search engines and may be behind some form of authentication. |
Production/Live | This is your live website, available to anyone over the Internet. |
Adapted from https://en.wikipedia.org/wiki/Deployment_environment | |
This book only concerns the first tier, where you will build and check your code. This is the local development environment and, most commonly, your own laptop or desktop. In the coming chapters, I’ll show you how to install and configure Apache on this environment so that you can view and test your website code in real time, regardless of whether you’re connected to the Internet.
Apache can be run on virtually any commercial operating system. If it can connect to a network, chances are there’s a version of Apache available for it. This book focuses primarily on macOS since it’s currently the most used operating system among digital professionals. I’ll point out the differences between macOS, Linux, and Windows as they emerge.
Apache vs. Other Web Servers
Apache is just one of many different web server applications available in a development environment, including free applications such as Nginx and Node.js’s built-in app server and licensed applications such as Microsoft’s Internet Information System (IIS) and Litespeed. On the surface, they seem to operate similarly (after all, they provide the same basic functionality), but underneath, each web server application has its own benefits and quirks.
Although Apache is the most commonly used web server, it’s still useful to compare it to the other available options.
Choosing Apache Over Nginx
Apache and Nginx (pronounced “engine x”)5 are the two most popular web servers as of this book and have a roughly equal share of the web server market for public websites. They are often used together to provide a robust web service for high-traffic websites. In fact, that’s why Nginx was originally developed as a supporting tool for Apache that helped solve a performance problem.
In the early 2000s, the amount of website traffic had been growing to the point where Apache could not handle all the simultaneous incoming requests. It had a rough limit of 10,000 requests at the same time.
That seems like a lot of requests, right? However, you must consider this: modern websites often have dozens of associated files on any page: style sheets, JavaScript files, and images or other media. Add to that functionality that requires the page to make additional requests asynchronously, such as accessing an API, which adds up very quickly. If you consider an average of 70 requests per page on a website,6 that means only about 140 to 150 people can access a website at the same time without experiencing issues.
Nginx was developed as a front-end proxy for Apache that would quickly serve static files, such as HTML, CSS, JavaScript, and images, and pass more computationally-involved scripts (such as PHP) to Apache to process separately. The combination of the two removed the 10,000 connections limit in Apache alone and set the stage for a highly performant web.
There are some downsides to using Nginx, however. First, it’s more complicated to configure than Apache, as it uses a scripting-like format for its configuration files. Nginx doesn’t allow directory-level overrides (discussed later), which lets you test configuration on the fly without restarting the server. Finally, Nginx is less flexible for scripting languages such as PHP, as it needs to pass these to separate applications to be interpreted and run (often through Apache).
All these decisions are made for better performance for high-traffic web servers, where milliseconds add up quickly over a large number of connections. To set up a development environment, however, Apache on its own is more than sufficient. You won’t ever have any concerns around server performance or high loads due to many concurrent site visitors on your development environment. You won’t see any benefit from using Nginx.
If you’re interested in learning more about Nginx, check out Rahul Soni’s excellent Nginx: From Beginner to Pro (Apress, 2016).
Apache over npm start for Node Development
Node.js is very friendly for on-the-fly testing in your browser. It lets you quickly start up a node application on a custom port by running node app.js and accessing the port on localhost (e.g., http://localhost:3000). This is great for very quick testing.
The downside is that the site is only available so long as the node application you started runs in your terminal, and you don’t mind accessing things through non-standard URLs. If you close the terminal window or quit the node program, your testing server dies with it. If you try to access http://localhost/ without supplying the port, you will not be able to view your Node.js project.
Apache can be configured to work with Node.js, however, and create an always available Node.js server that’s accessible without supplying a custom port number. This is covered in more detail in Chapter 3.
Obtaining Apache
Apache has a few system requirements, but they’re not nearly as bad as you might think. The first of these is disk space. Apache needs a jaw-dropping 50 MB to install. After it’s installed, it needs only 20 MB to run. No, that’s not a typo. One of the strengths of Apache is its lean nature. Similarly, you don’t need much RAM or a powerful processor either; Apache runs on as little as 0.5 GB of RAM on a 1 GHz CPU if running a UNIX-based system such as Linux. If you follow the system requirements for your operating system, you stand a good chance of being able to run Apache. For comparison, Microsoft’s Internet Information Server (IIS) requires at least a 1.4 GHz CPU, 2 GB of RAM, and 32 GB to operate.7
I’d suggest giving your Apache web server as much RAM and hard disk space as possible, however, and spending a little less on the processor unless you plan on using your server heavily or accessing a database frequently. The more RAM you have available for Apache, the happier it is and the faster it performs. And keep in mind it is running alongside other applications, such as your code editor and browser, which all compete for access to RAM and disk space as well as any database servers or scripting environments you may be using, such as PHP or Node.js.
Installing Apache on macOS
Advantages and Disadvantages of Using macOS
Advantages | Disadvantages |
|---|---|
You probably already use a Mac in web design, UX, or web development, as they’re popular within those disciplines. | macOS has a built-in version of Apache that might interfere with the operation of the version installed in this chapter. |
macOS, like Linux, is built on a UNIX core, which gives you a very stable and secure environment on which to develop. | Apple’s shift to their own proprietary CPU in 2021 initially added some performance and compatibility issues. |
Apple provides several other developer-friendly tools through XCode, like Git, SCP, and SSH. | Apple’s computers are priced at a premium, making them more expensive than other commodity desktops or laptops. |
With its roots in UNIX, macOS was born and raised as a multiuser operating system that could handle multiple users and run multiple applications. |
Installing Apache Through Homebrew
While you can enable and configure the built-in Apache as a development environment, I suggest that you use Homebrew. This tool provides the ability to install packages such as Apache, PHP, and many other UNIX tools.
I recommend that you use Homebrew,8 a package manager for macOS that makes it a bit easier to install and manage software packages like Apache, PHP, and MySQL (among many others). Homebrew has been actively maintained for macOS as an open source project since 2009 by a team of dedicated contributors. It provides a safe way to install this kind of software on your system without interacting with the core operating system.
Brew installs tools locally, outside of the protected system directories in macOS. This also makes it simpler to modify configuration files since you don’t have to use administrator privileges to do so.
To install Homebrew, visit https://brew.sh and follow their installation directions. I’ll wait.
This starts the installation process and puts a local copy of the Apache httpd server into your computer’s /usr/local/ directory.
It lists the DocumentRoot as /usr/local/var/www. DocumentRoot is an Apache configuration directive explored in more detail in the next chapter. For now, just know that this is the directory where the website’s files live on your computer and are accessible to the browser. On install, this contains an empty cgi-bin directory and an index.html file.
It lists the default ports Apache is configured for. In the preceding example, these are ports 80 and 443 (for secure web). Do note that if you have enabled the built-in copy of Apache in macOS, these ports may be different, such as 8080 and 80443.
It provides you with the command to start up Apache manually: /usr/local/opt/httpd/bin/httpd -D FOREGROUND. It’s better to set this up as a service, however, so you don’t have to remember to start Apache up every time you reboot your computer.
Running Apache as a Service Through Homebrew
Apache can be run when you need it using the preceding command, or it can constantly run as a background service on macOS. Running a program like Apache as a service is a bit more convenient, as it starts every time you restart your computer.
Once you’ve done that, you can skip to the “Basic Configuration” section at the end of this chapter.
Installing Apache on Linux
Linux offers the security and stability of a UNIX system without the cost; the Linux operating system (as well as the bulk of applications available for it) is placed under the General Public License (GPL) and made available to all, free of charge. It’s developed under the philosophy of open source and, as such, is generally rock solid and secure. There is also a large range of low-cost hardware available that is compatible with Linux, such as the Raspberry Pi or an old desktop system sitting in a closet.
Since Linux itself consists solely of the basic operating system (and no applications or utilities), it has been packaged with a set of applications and utilities and a method of installation by several organizations. These different packages are called distributions; if you choose to install Linux, the fastest and easiest way is to decide upon a distribution.
There are hundreds of distributions to choose from, but only a few are generally accepted by most Linux developers, including Ubuntu, Debian, and Red Hat. Ubuntu is the most commonly used for desktop or laptop installations, with Debian often used for server installations.
However, a problem with using Linux is that there is likely a larger initial learning curve if you aren’t already familiar with it. Though Linux does have a graphical desktop, most administration is done through a text-only command-line interface. As a result, there’s a new set of commands that you must learn and remember. However, most—if not all—of the information you might need about Linux is readily available on the web.
Advantages and Disadvantages of Using Linux
Advantages | Disadvantages |
|---|---|
Linux is far more secure, stable, and reliable than Windows. Due to the open nature of development, vulnerabilities are found and repaired quickly by Linux developers. Patches are often available within hours of a vulnerability being reported. | Linux offers an unfamiliar interface; most administration is done through the command-line interface. |
With its roots in UNIX, Linux was born and raised as a multiuser operating system that could handle multiple users and run multiple applications. The Linux development team has decades to hone this ability and make sure that it handles multiple users with far more ease than Windows. | No single commercial entity is responsible for Linux, which might go against some corporate IT policies. All major Linux kernel (the core operating system) releases go through a rigorous code-review process administered by a dedicated community of developers sponsored by the Linux Foundation. |
Linux performs better than Microsoft Windows since very little processing power goes into the display. | Linux has a larger learning curve than macOS and Windows. |
Linux is built for network performance. Every major Linux distribution comes with the network tools needed to get a web server up and running. | Graphical administration tools aren’t available for all system functions. You’re going to need to be comfortable with the command line. |
Linux offers far better remote management capability. Several methods, including Secure Shell (SSH) and remote desktop, allow you to connect to your server quickly and efficiently. | No commercial support is available for some distributions. |
Linux is much more modular than other operating systems. The operating system needs only a couple hundred megabytes of disk space, and you only install the applications you want to use on the server. | The configuration directory structure is different from what Apache recommends. This can cause confusion if you are looking at examples online. |
Linux servers rarely need to be rebooted; all system services and applications can be modified or reinstalled without a reboot. | |
Linux has a much lower cost of entry than the other operating systems, which makes it easier and inexpensive to have a separate dedicated development server apart from your personal workstation. You can even install it on an entry-level Raspberry Pi for a fraction of the cost for Windows or Mac. |
Choosing the Source Installation
Apache is and always has been open source software. This means that the source code is available for anybody to download, read, modify, and recompile. The source code is a series of instructions and commands that define individual functions (for example, reading the contents of a file and placing it in memory). These functions, when bundled together, create a complete application. However, to get to the application from the source code, the application must be compiled for your operating system (translated from the programming language source code to an executable file and its supporting library files).
One of the strong benefits of using open source software is security. Apache’s source code is reviewed by literally thousands of eyes and is developed by a group of programmers who volunteer their time.
What does that mean to you? It means two things: quality and security. Because Apache is developed in an open environment, the greater the likelihood that bugs, vulnerabilities, and security problems are found. Even if a bug slips through, it is generally found and corrected in a matter of days.
Customizing the application. Some people installing the Apache web server may need to make changes to the source code to meet proprietary needs. For example, they may need to change how Apache transfers information over the network. Generally, they need to do something that the standard Apache configuration files don’t allow them to do. These people have a heck of a lot more programming knowledge than I do.
Security auditing. Another reason for downloading the source code is to review it for vulnerabilities and bugs before compiling and running it on your server. Many organizations require all software installed on their servers to be audited before being deployed publicly. If this sounds familiar, you may want to download a copy of the Apache source code to hand over to the powers that be.
Education. Just like it sounds. If you’re trying to learn a programming language, what better way than to use an existing application as an example? Apache has thousands of lines of code, all publicly open for viewing. It serves as an excellent educational tool for aspiring programmers.
Unless you’re running an operating system that doesn’t have a package manager (such as Ubuntu), you don’t want to choose the source install. It’s mainly there for the super techie folk. You gain some amount of geek credibility by saying you were able to compile an application from the source. Of course, you also spend much longer getting it to work than if you had just grabbed a binary install from your package manager in the first place.
The Apache source code can be found at www.apache.org/dist/httpd/. If you want to travel down this road, follow the process documented by the Apache group at http://httpd.apache.org/docs/install.html#traditional.
The Benefit of Binary Installation
OK, maybe getting the source code isn’t right for you, so you’ve decided to do a binary install. This is a precompiled version of Apache for your operating system. Binary installs are available for Windows, Linux, most commercial versions of UNIX, and macOS X.
The benefit of the binary file is that you significantly reduce the time between downloading the Apache install and running an Apache web server. The drawback, of course, is that you completely remove the ability to customize Apache before installing it (not that you need or want to).
For this book, I will use Ubuntu as the Linux distribution of choice; however, the instructions work for any DEB-based distribution, such as Debian, Knoppix, or Raspberry Pi’s Raspbian OS.
A coding window is labeled darren at apachebox. Inside the text input field are seven lines of code.
Installing Apache on Ubuntu
This installs Apache and some helper utilities like apachectl (which starts and stops the Apache server). Ubuntu also configures Apache to run as a service automatically, so it starts up whenever you reboot the operating system.
Once you’ve done that, you can skip to the “Basic Configuration” section at the end of this chapter.
Installing on Windows
Windows is the second most common choice for installing Apache, since most organizations have a ready supply of Windows servers. There are some definite advantages to using Windows (see Table 1-4); most people are already familiar with the Windows interface, so there’s little time required to learn how to configure things. You may also only be allowed to use Windows by your organization’s IT department, which removes the possibility of using Linux or macOS.
A Linux subsystem in the Windows Store allows you to follow the Linux installation instructions. This lets you remove any potential compatibility issues in moving your code from a Windows development environment to a UNIX-based one. If you go down this route (I’d recommend it!), follow the installation instructions for Linux/Ubuntu instead of these instructions.
Advantages and Disadvantages of Using Windows
Advantages | Disadvantages |
|---|---|
An immediately recognizable user interface for most people | The vast majority of production web servers run on UNIX-based systems like Linux. Because of that, there’s a small chance that there may be compatibility issues when you deploy code developed on a Windows system. |
Smaller learning curve | Windows isn’t as secure as macOS or Linux. Vulnerabilities are routinely found in Microsoft Windows, and viruses are common. This puts any sensitive information you use as part of your web development at risk of exposure, even in development environments. |
Graphical tools for administration | Due to the closed development model often takes Microsoft days to release a patch after a vulnerability has been reported. Numerous other vulnerabilities may have already been found but not reported. |
An existing maintenance agreement with Microsoft | System requirements for Windows are often much higher than for Linux performing the same tasks. |
Performance doesn’t match Linux on the same system specifications; Linux servers offer more reliable network and file operations than Windows, using the same hardware. | |
Windows machines are more prone to mysterious crashes and must be rebooted more often. | |
Customization of Apache or PHP on Windows is much more complicated than on Linux or macOS. |
Installing Apache Through XAMPP
I recommend using XAMPP for Windows to install Apache. XAMPP is fully open source, free of charge, and supported by a non-profit organization, Apache Friends. It is kept up to date with releases of Apache, PHP, and MariaDB (a common, open source database system based on MySQL). Other options, such as WAMP, MAMP, and AMPSS, operate similarly but may impose licensing costs. In this book, however, refer to filenames and locations in XAMPP.
You can download XAMPP at www.apachefriends.org. Follow the on-screen directions to install the software, selecting C:XAMPP as the Installation folder. During the installation, keep the default options selected. At a minimum, you should install Apache and PHP because they are used later in this book.
Installing Apache as a Service in Windows
A windows menu where the following are highlighted, X A M P P, the tab More in the dialog box, and Run as administrator in the list of options.
Running XAMPP as administrator on Windows
A window of X A M P P Control Panel v 3.3.0 contains a confirm prompt window with options to install the Apache Service, after the module is chosen.
XAMPP control panel
Apache now starts up whenever you reboot your Windows computer.
Basic Configuration
So now that you have Apache installed, what do you do with it? The simplest configuration for Apache is one that serves up static HTML files and any linked files like graphics, CSS, or JavaScript.
Where to Put Your Website Files
Default Location of Public Website Files
On… | File location |
|---|---|
macOS (Homebrew) | /usr/local/var/www |
macOS (Native) | /Library/WebServer/Documents/ |
Ubuntu | /var/www |
Windows 10 /11 | C:xampphtdocs |
Location of Apache’s Configuration Directory
On… | File location |
|---|---|
macOS (Homebrew) | /usr/local/etc/httpd |
macOS (Native) | /etc/apache2 |
Ubuntu | /etc/apache2 |
Windows 10 / 11 | C:xamppapacheconf |
Configuration Directory Structure
Contents of Apache Configuration Directory
macOS and Windows | Ubuntu Linux |
|---|---|
[Apache configuration directory] |- extra (directory) | |- *.conf |- httpd.conf |- magic |- mime-types |- original (directory) | |- extra (directory) | | |- *.conf | |- httpd.conf | /etc/apache2/ |- apache2.conf |- conf-available | |- *.conf |- conf-enabled (directory) | |- *.conf (symbolic links to ../conf-available) |- envvars |- magic |- mods-available (directory) | |- *.conf |- mods-enabled (directory) | |- *.conf (symbolic links to ../mods-available) |- ports.conf |- sites-available (directory) | |- *.conf |- sites-enabled (directory) | |- *.conf (symbolic links to ../sites-available) |
In this book, I focus on the macOS and Windows directory structures when talking about configuration. Though I recommend you follow Ubuntu’s provided directory structure on Linux, you can work outside of that structure to follow the examples in this book. Apache is flexible that way!
Now let’s review what those configuration files do.
httpd.conf/apache2.conf
All of Apache’s basic configuration is handled in the httpd.conf file, located in the directory indicated for your operating system. This is a text file that can be edited using any plain text editor or code editing tool and contains a lot of configuration instructions called directives, which you’ll learn more about in Chapter 2.
The default httpd.conf installed with Apache contains many more directives than you need; several directives and examples are commented out within the httpd.conf configuration file. This is done by placing a # at the beginning of the line. These commented directives come in very handy. For example, let’s say you need to load the mod_userdir module, which allows your users to maintain their web pages on your server. Instead of trying to figure out what the proper name of the module is, you can just remove the comment character. All the directives discussed in the next chapter are in httpd.conf, unless specified otherwise.
mime.types
If you need to add a new file type, this is the place to do it. I discuss it a little more in the “Adding New File Types” section in Chapter 2.
Configuring a Default Site
A default site is already configured for you when you install Apache. But I find the location configured by the Apache installer is often inconvenient to get to in your file browser and sometimes has restricted permissions that require you to access administrative privileges to add or edit files.
A screenshot of the local host page with the text, It Works.
Apache’s default website
http://project.local stored in /home/darren/sites/project/
http://funtoy.local stored in /home/darren/sites/funtoy/
http://skunkworks.local stored in /home/darren/sites/workproject/
Make your own sites directory, and jot the location down in your favorite notes app. You reference this directory in the httpd.conf or apache2.conf file later in this book. In the next chapter, you set up Apache to point to your new sites directory and set up some basic configuration options.
Summing It Up
Congratulations! You now have a solid foundation of server fundamentals and Apache installed in its most basic form. If you do nothing else, you can start building static websites and making them available to the browser. You should be comfortable installing Apache anywhere, whether your computer or a cloud-hosted Linux server, and where you can find the configuration files needed to customize your Apache installation.
Chapter 2 explains Apache’s configuration. You set up a basic Apache site pointing to http://localhost/ and develop an understanding of the configuration directives. You also learn about the structure of Apache’s configuration files and local overrides through the .htaccess file. See you there!