How to Install Cassandra on Ubuntu 16.04 LTS

Apache Cassandra is a free open-source database system that is NoSQL based. Meaning Cassandra does not use the table model seen in MySQL, MSSQL or PostgreSQL, but instead uses a cluster model. It’s designed to handle large amounts of data and is highly scalable. We will be installing Cassandra and its pre-requisites, Oracle Java, and if necessary the Cassandra drivers.

Pre-Flight Check

  • We are logged in as root on an Ubuntu 16.04 VPS powered by Liquid Web!
  • Apache Cassandra and this article expect that you are using Oracle Java Standard Edition 8, as opposed to OpenJDk . Verify your Java version by typing the command below into your terminal:

java --version

  • At the time of this article, Python 2.7.11 and later versions will need to install updated Cassandra drivers to fix a known bug with the cqlsh command. You can check your Python version similar to checking your Java version:

python --version

  • If you have Python 2.7.11+ or later, download the required driver by running the pip command. You will need pip installed. Within this tutorial, we will show you how to install pip. However, pip is usually pre-installed with Python by default.

Step 1: Install Oracle Java (JRE)

Cassandra requires your using Oracle Java SE (JRE) installed on your server. First, you will have to add Personal Package Archives to make the (JRE) package available.

sudo add-apt-repository ppa:webupd8team/java

After entering this command, it may prompt you to hit enter to continue.
Once it completes update the package database using the following:

sudo apt-get update

You can now install Oracle JRE with the following:
sudo apt-get install oracle-java8-set-default

A pink screen prompts you to agree to the terms and conditions of JRE. Hit enter to continue from this screen and accept the terms and conditions in the next screen.

Java Installer Screen

 

Once successfully installed verify the default version of Java by typing:

java -version

You’ll receive the following or something very similar :

Java Version Output

 

Step 2: Installing Apache Cassandra

First, we have to install the Cassandra repository to /etc/apt/sources.list.d/cassandra.sources.list directory by running following command (When we made this article Cassandra 3.6 was the current version. You may need to edit this line to reflect the latest release by updating the 36x value. For example, use 37x if Cassandra 3.7 is the newest version.):
echo "deb http://www.apache.org/dist/cassandra/debian 36x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list

Next, run the cURL command to add the repository keys :

curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -

We can now update the repositories:

sudo apt-get update

 

Note
If you get the following error: GPG error: http://www.apache.org 36x InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY A278B781FE4B2BDA
Add the public key by running the following command:
sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-key A278B781FE4B2BDARepeat the update to the repositories:
sudo apt-get update

Finally, finish installing by entering the following:
sudo apt-get install cassandra

Verify the installation of Cassandra by running:
nodetool status

The desired output will show UN meaning everything is up and running normally.

Verifying Cassandra is Installed

 

Step 3: Connect with cqlsh

If you have an older version of Python before 2.7.11, you’ll skip this step and start using Cassandra with the cqlsh command. Good for you! You have successfully installed Cassandra!
cqlsh

You should see something similar to this:
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.6 | CQL spec 3.4.2 | Native protocol v4] Use HELP for help.

Note
For future reference, Cassandra’s configuration file, data directory and logs can be found in:

  • /etc/cassandra is the default file configuration location.
  • /var/log cassandra and /var/lib cassandra are the default log and data directories location.

However, if you get the following error,

Connection error: (‘Unable to connect to any servers’, {‘127.0.0.1’: TypeError(‘ref() does not take keyword arguments’,)}),

you’ll update the Cassandra drivers. These drivers have a known bug with Cassandra and later versions of Python. Check your Python version by typing:
python --version

Luckily, I am going to show you how you can fix this error in 3 easy steps by downloading the drivers.

 

Step 3a: First we will need pip installed. If you don’t have it already, you can get it with the following command.

sudo apt-get install python-pip

 

Step 3b: Once pip is installed, run the following to install the new Cassandra driver. Please note this command may take a while to execute. Grab a snack and wait for it to complete. It can take 5-10 minutes to install fully.

pip install cassandra-driver

 

Step 3c: Finally disable the embedded driver by entering :

export CQLSH_NO_BUNDLED=true

You should now be able to run the cqlsh command.

cqlsh

You should see this if successful :

Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.6 | CQL spec 3.4.2 | Native protocol v4] Use HELP for help.

To exit cqlsh type exit:
cqlsh> exit

Congrats! You have successfully installed Cassandra!

Note

Cassandra should start automatically, but you’ll want to stop Cassandra to make any additional configuration changes. Start and stop it with the following:

sudo service cassandra start
sudo service cassandra stop

Whitelisting in ModSecurity

Broken down into two parts our article’s first section hits on “how to whitelist IPs or URIs,” for people who are somewhat familiar with ModSecurity but want to know further about the process. Our second section examines why we configure ModSecurity and how to prevent the security of the server from getting in the way of our work. If you have a Fully Managed Liquid Web server reach out to our Heroic Support team for assistance with whitelisting!

How to Whitelist IPs or URIs

“ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.” (modsecurity.org).  In simple terms, this means that ModSec, also called mod_security or ModSecurity, is a web application firewall that can actively look for attacks to the system and stop malicious activity. However, sometimes these rules trigger when legitimate work is taking place, blocking your IP and stopping you or your developer’s until you can remove the IP block. The way around for being blocked is known as whitelisting, which essentially allows for a specific IP to access the server.   There are a few ways to whitelist a request in ModSec, either by IP or by URI (URIs are specific pages on the website). 

Getting Started

  1. Find your IP or ask your developer for theirs. (You can find this by going to ip.liquidweb.com)If you or your developer have a static IP (one that will not change), one way you can whitelist the ModSec rules is by IP.
  2. Find the ModSec error in the Apache error logs with the following command (Be sure to modify the command with your IP in place of “IP here.”):
    grep ModSec /usr/local/apache/logs/error_log | grep “IP here”.
  3. The output of this command will give you a list of hits for ModSecurity from you or your developer’s IP, which you can see below. While this looks intimidating, you will only want to pay attention to 3 bits of information highlighted.  Please note, the output will not show these colors when you are viewing the files.
Note
Blue = client, the IP which tripped the rule
Red
= ID number of tripped rule within ModSec
Green = URI, the location where the error started from

[Fri May 25 23:07:04.178701 2018] [:error] [pid 78007:tid 139708457686784] [client 61.14.210.4:30095] [client 61.14.210.4] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "20000221"] [hostname "67.227.209.163"] [uri "/db/index.php"] [unique_id "WwjPWChxvG1CO4kz-D55eQAAACU"]

 

Whitelist By IP:

1. Once you have the correct ModSec error, you will need to edit the ModSec configuration. If you are using Easy Apache 4 you will find the configuration file with this path:
/etc/apache2/conf.d/modsec2/whitelist.conf

2. Open the file with your favorite text editor, such as vim, nano, or file manager like so:

vim /etc/apache2/conf.d/whitelist.conf

3.  The blue text above will be the IP address that you are whitelisting from the original error. You must keep the backslashes (\) and up-carrot (^) in order for the IP to be read correctly. Thus it will always look something like:

“^192\.168\.896\.321”

For for the id, noted in red, you will change the number after the colon, which will be the Apache error log like we saw above. This will look similar to:

Id:2000221

Add the following code with the colored sections edited to match your intended IP.

SecRule REMOTE_ADDR "^64\.14\.210\.4"
"phase:1,nolog,allow,ctl:ruleEngine=off,id:20000221"

 

Whitelist By URI:

If your IP is dynamic (changing) and you keep getting blocked in the firewall, it is best to whitelist it via URI, the yellow item in the ModSec error.

1. Begin by opening the Easy Apache 4 configuration file:

vim /etc/apache2/conf.d/whitelist.conf

2. Add the following text to the configuration. Remember to pay attention to the highlighted parts.  Change the yellow “/db/index.php” to match your URI and the red id to match the id of your error (Do not use the colon in this one).

<LocationMatch "/db/index.php">
SecRuleRemoveById 20000221
</LocationMatch>

3. The final step for whitelisting, before you finalize the process, is to ensure you have correctly set up the whitelist. For Easy Apache 4 you will run the command:
apachectl -t

As long as the command returns “Syntax Ok” you are safe to make the whitelist active by restarting Apache. Otherwise, review the whitelists to make sure the syntax matches up correctly with the above directions.

4. Lastly, restart Apache with the following command.

/scripts/restartsrv_httpd

You have successfully whitelisted yourself in ModSec!

 

Using ModSec

Cyber Security is a hydra; once one threat is cut off, two more grow back. While this is not a new analogy, it’s important to understand as we battle threats to our network, computers, and servers. With all the complexities that come with security, I want to talk about adequately configuring ModSec to deter threats while still allowing you to work on your websites. Often, when it comes to server security, too much protection can hinder effectiveness.

For example, say you have the following set up on your server:

  • You do not allow root SSH login to the server
  • utilize dual-factor authentication for any SSH logins
  • use an SSH key for the sudo user and require other security safeguards

While this type of configuration is secure, it takes longer to log into your system to make a quick edit to your settings, a double-edged sword; how can you keep the server safe while not tying your own hands?  A great example of how this plays out is using ModSec.

ModSec can block your IP if it falsely flags your work. While this module improves system security, you’ll need to be aware of properly implementing and “scoping” the technology. Scoping in this sense means to manage risks, the focus of what is important for security while still allowing work on the server with minimal interference. To tune out legitimate requests to your server, such as when you are editing your website’s code via a plugin, ModSec has the options to whitelist rules or IPs and keep your work on track.

Whitelisting an IP from the rules that ModSec follows is a great option so long as the IP never changes (i.e. a static IP, see article here to learn more https://support.google.com/fiber/answer/3547208?hl=en) and is limited to only people you trust. This method prevents ModSec from viewing your requests as malicious and blocking your IP. This practice has the drawback that if someone (say an unhappy employee) has access to your network, they now have a way around ModSec to attack your server.

With non-static (dynamic) IPs the problems of whitelisting an IP are readily apparent. With the continual change of a dynamic IP, it creates the potential of exploiting your server, as someone could use an old IP to access the server. Whitelisting specific rules comes to save the day! When you whitelist by rules, you can edit with granularity and limit the rules to particular domains and URIs, protecting the rest of the server from attacks related to that same rule!

Example of ModSecurity

ModSec reads a series of rules and applies them to incoming requests being made to the web server. An example of what a block looks like is:

[Sat Jun 30 02:21:56.013837 2018] [:error] [pid 79577:tid 139862413879040] [client 120.27.217.223:24397] [client 120.27.217.223] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "2000064"] [hostname "67.227.192.139"] [uri "/mysql/index.php"] [unique_id "WzchhAjuZ6wPAzo9AwW1WwAAAE8"]

This error shows Apache stopped a potential attack on a file at /mysql/index.php. This is an error similar to what appears when the code is being written or edited within programs like Drupal or WordPress.

Evaluating ModSecurity

If you are persistently being blocked in your firewall while working on your code, ModSec is the likely culprit. The ModSec errors can be found in the Apache error log (in cPanel the path is /usr/local/apache/logs/error_log). The phrase “ModSec” can be quickly isolated from the log (via the command ‘grep “ModSec” /usr/local/apache/logs/error_log’). By comparing you or your developer(s) IP to the log, you’ll be able to identify stopped requests that are legitimate. Verify these are valid requests by double-checking that someone in your organization made them. Once you have done so, you can move forward in setting up a whitelist for the error, per the steps above.

Again, we want to scope to allow the least amount of wiggle room for an attack and ensure we can keep working. If you are unable to have a trusted static IP, you’ll need to use the whitelist URI  method, providing the specific page as an exemption. Once completed, remove both whitelisted items from the configuration file, in case of a genuine attack.

On a parting note, I encourage you to explore ModSec and learn more of the ins and outs of the software. Exploring different methods of whitelisting can be a lot of for to learn and most importantly helps to tighten server security. As always, our Fully Supported Customers can contact our Helpful Human Support team for assistance. Check out articles on security in our Knowledge Base, like this one on Maldet! It’s another excellent way to learn about your server and develop an understanding of server security.

How To Install Apache Tomcat 8 on Ubuntu 16.04

Apache Tomcat is used to deploy and serve JavaServer Pages and Java servlets. It is an open source technology based off Apache.

Pre-Flight Check

  • This document assumes you are installing Apache Tomcat on Ubuntu 16.04.
  • Be sure you are logged in as root user.

Installing Apache Tomcat 8

Step 1: Create the Tomcat Folder

Logged in as root, within the opt folder make a directory called tomcat and cd into that folder after completion.

mkdir /opt/tomcat

cd /opt/tomcat

 

Step 2: Install Tomcat Through Wget

Click this link to the Apache Tomcat 8 Download site. Place you cursor under 8.5.32  Binary Distributions, right click on the tar file and select copy link address (as shown in the picture below). At the time of this article Tomcat 8 is the newest version but feel free to pick whatever version is more up-to-date.

Tomcat 8's Download Page

Next from your server, use wget command to download the tar to  the tomcat folder from the URL you copied in the previous step:

wget http://apache.spinellicreations.com/tomcat/tomcat-8/v8.5.32/bin/apache-tomcat-8.5.32.tar.gz

Note
You can down the file to your local desktop, but you’ll then want to transfer the file to your Liquid Web server. If assistance is needed, check out this article: Using SFTP and SCP Instead of FTP

After the download completes, decompress the file in your tomcat folder:

tar xvzf apache-tomcat-8.5.32.tar.gz

 

Step 3: Install Java

Before you can use Tomcat you’ll have to install the Java Development Kit (JDK). Beforehand, check to see if Java is installed:

java -version

If that command returns the following message then Java has yet to be installed:
The program 'java' can be found in the following packages:

To install Java, simply run the following command (and at the prompt enter Y to continue):
apt-get install default-jdk

 

Step 4: Configure .bashrc file

Set the environment variables in .bashrc with the following command:

vim ~/.bashrc

Add this information to the end of the file:
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
export CATALINA_HOME=/opt/tomcat/apache-tomcat-8.5.32

Note
Verify your file paths! If you downloaded a different version or already installed Java, you may have to edit the file path or name. Older versions of Java may say java-7-openjdk-amd64 instead of java-1.8.0-openjdk-amd64 . Likewise, if you installed Tomcat in a different folder other then /opt/tomcat (as suggested) you’ll indicate the path in your bash file and edit the lines above.

Save your edits and exit from the .bashrc file, then run the following command to register the changes:

. ~/.bashrc

 

Step 5: Test Run

Tomcat and Java should now be installed and configured on your server. To activate Tomcat, run the following script:

$CATALINA_HOME/bin/startup.sh

You should get a result similar to:

Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-7-openjdk-amd64/
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Tomcat started

 

To verify that Tomcat is working visit the ip address of you server:8080 in a web browser. For example http://127.0.0.1:8080.

Apache Tomcat 8 Verification Page

 

How To Install Apache Tomcat 7 on Ubuntu 16.04

Apache Tomcat is used to deploy and serve JavaServer Pages and Java servlets. It is an open source technology based off Apache.
Pre-Flight Check

  • This document assumes you are installing Apache Tomcat on Ubuntu 16.04.
  • Be sure you are logged in as root user.

Installing Tomcat 7

Step 1: Create the Tomcat Folder

Logged in as root, within the opt folder make a directory called tomcat and cd into that folder after completion.

mkdir /opt/tomcat
cd /opt/tomcat

 

Step 2: Install Tomcat Through Wget

Click this link to the Apache Tomcat 7 Download site. Place your cursor under 7.0.90 Binary Distributions, right click on the tar.gz file and select Copy Link Address (as shown in the picture below).  At the time of this article Tomcat 7 is the newest version but feel free to pick whatever version is more up-to-date.

Tomcat Version 7.0.90

Next, from your server, use wget command to download the tar to  the tomcat folder from the URL you copied in the previous step:

wget http://www.trieuvan.com/apache/tomcat/tomcat-7/v7.0.90/bin/apache-tomcat-7.0.90.tar.gz

Note
You can down the file to your local desktop, but you’ll then want to transfer the file to your Liquid Web server. If assistance is needed, check out this article: Using SFTP and SCP Instead of FTP

After the download completes, decompress the file in your Tomcat folder:

tar xvzf apache-tomcat-7.0.90.tar.gz

You will end up with a file called apache-tomcat-7.0.90.

 

Step 3: Install Java

Before you can use Tomcat, you’ll have to install the Java Development Kit (JDK). Beforehand, check to see if Java is installed:

java -version
If that command returns the following message then Java has yet to be installed:
The program 'java' can be found in the following packages:
To install Java, simply run the following command (and at the prompt enter Y to continue:
apt-get install default-jdk

 

Step 4: Configure .bashrc file

Set the environment variables in .bashrc with the following command:

vim ~/.bashrc
Add this information to the end of the file:
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
export CATALINA_HOME=/opt/tomcat/apache-tomcat-7.0.90

Note
Verify your file paths! If you downloaded a different version or already installed Java, you may have to edit the file path or name. Older versions of Java may say java-7-openjdk-amd64 instead of java-1.8.0-openjdk-amd64 . Likewise, if you installed Tomcat in a different folder other then /opt/tomcat (as suggested) you’ll indicate the path in your bash file and edit the lines above.

Save your edits and exit from the .bashrc file, then run the following command to register the changes:

. ~/.bashrc

 

Step 5: Test Run

Tomcat and Java should now be installed and configured on your server. To activate Tomcat, run the following script:

$CATALINA_HOME/bin/startup.sh

You should get a result similar to:
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-7-openjdk-amd64/
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Tomcat started.

 

To verify that Tomcat is working by visiting the IP address of your server:8080 in a web browser. For example http://127.0.0.1:8080.

Tomcat 7.0.90 Test Page

 

What is a LAMP stack?

The LAMP stack is the foundation for Linux hosted websites is the Linux, Apache, MySQL and PHP (LAMP) software stack.

The Four Layers of a LAMP Stack

Linux based web servers consist of four software components. These components, arranged in layers supporting one another, make up the software stack. Websites and Web Applications run on top of this underlying stack. The common software components that make up a traditional LAMP stack are:

  • Linux: The operating system (OS) makes up our first layer. Linux sets the foundation for the stack model. All other layers run on top of this layer.
  • Apache: The second layer consists of web server software, typically Apache Web Server. This layer resides on top of the Linux layer. Web servers are responsible for translating from web browsers to their correct website.
  • MySQL: Our third layer is where databases live. MySQL stores details that can be queried by scripting to construct a website. MySQL usually sits on top of the Linux layer alongside Apache/layer 2. In high end configurations, MySQL can be off loaded to a separate host server.
  • PHP: Sitting on top of them all is our fourth and final layer. The scripting layer consists of PHP and/or other similar web programming languages. Websites and Web Applications run within this layer.

We can visualize the LAMP stack like so:

Applying what you’ve learned

Understanding the four software layers of a LAMP stack aids the troubleshooting process. It allows us to see how each layer relies on one another. For instance; when a disk drive gets full, which is a Linux layer issue. This will also affect all other layers in the model. This is because those other layers rest on top of the affected layer. Likewise, when the MySQL database goes offline. We can expect to see PHP related problems due to their relationship. When we know which layer is exhibiting problems. We know which configuration files to examine for solutions.

Some Alternatives

The four traditional layers of a LAMP stack consist of free and open-source products. Linux, Apache, MySQL and PHP are the cornerstone of a free, non-proprietary LAMP stack. There are several variants of the four stack model as well. These variants use alternative software replacing one or more of the traditional components. Some examples of these alternatives are:

  • WAMP: Windows, Apache, MySQL & PHP
  • WISA: Windows, IIS, SQL & ASP.net
  • MAMP: MacOS, Apache, MySQL & PHP

You can explore these alternative software stacks in greater depth using online resource. The LAMP stack Wiki is a great place to start:

How can we help?

The LAMP stack is an industry standard and is included in all of our Core-Managed and Fully Managed Linux based servers. Our support teams work hand in hand with the LAMP stack on a daily basis. You can rest assured we are at your disposal should you have questions or concerns. To learn more you can browse our latest product offerings.

Installing and using UFW on Ubuntu 16.04 LTS

On an Ubuntu server the default firewall management command is iptables. While iptables provides powerful functionality it’s syntax is often seen as complex. For most users a friendlier syntax can make managing your firewall much easier.

The uncomplicated firewall (UFW) is an alternative program to iptables for managing firewall rules. Most typical Ubuntu installations will include UFW by default. In cases where UFW isn’t included it’s just a quick command away! Continue reading “Installing and using UFW on Ubuntu 16.04 LTS”

Choosing Your Cloud Sites Technology Setup

Behind Cloud Sites, racks full of both Linux and Windows servers power over 100,000 sites and applications. Every Windows-based page is served from clusters built and optimized especially for Windows, and every Linux-based page is served from clusters built and optimized especially for Linux. We use advanced load balancing technologies to automatically detect the type of technology you are running and route each request to the proper pool of servers.

This is a great example of the power of cloud computing, since you no longer have to make a hosting choice between Linux and Windows. Both PHP and .NET are included, allowing you to choose the technology you need site by site.
Continue reading “Choosing Your Cloud Sites Technology Setup”

Error: sec_error_ocsp_try_server_later [SOLVED]

Pre-Flight Check

  • These instructions are intended specifically for solving the error: “sec_error_ocsp_try_server_later”.
  • This error can be displayed anytime a user visits a secure website using the https:// protocol in Firefox or Internet Explorer. It does not indicate a problem with the site itself, but occurs due to a change in the method these specific browsers use to check for revoked SSL certificates.
  • We’ll be logging into WebHost Manager as root to resolve the error.

Certificate revocation checks can help prevent you from accidentally visiting a site that’s using a compromised security certificate. Historically, the web browser typically would check a Certificate Revocation List directly. But the newer process, known as OCSP stapling, relies on the web server to make the check and pass along the Certificate Authority’s cached response to the browser. Because this is a newer process and not yet an Internet standard, some servers may require a minor configuration change in order to comply with the browser’s request. If you see this error when connecting to a site on your cPanel server, you can easily enable OCSP stapling on your server directly from WHM.

Step #1: Open the Apache Include Editor in WHM

  1. In WHM, locate and select Apache Configuration in the left menu (you can start typing “apache” to quickly narrow down the choices) to open the Apache Configuration page.

    WHMIncludeEditor

  2. Scroll down to Include Editor and click on it.
  3. On the Include Editor page, scroll down to the Pre VirtualHost Include section and select All Versions underneath “I wish to edit the Pre VirtualHost configuration include file for:”

    EditAllVersions

  4. Scroll past any directives that may be listed in the include, and add the following two lines at the very bottom:

    SSLUseStapling on
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    Note: Do not edit or alter any other directives that may be listed; make sure you’re simply adding the two lines above to the very bottom of the file.
  5. Click on the blue Update at the bottom to save the include file.

Step #2: Restart Apache to Apply the Settings

All you need to do to apply the new settings is to restart Apache. WHM makes that easier by presenting you with a Restart Apache button once you’ve saved your changes in the previous step.

RestartApache
 

How To List Which Apache Modules are Enabled on Fedora 23

The Apache web server is one of the most popular and powerful web servers in the world due in part to its ease of administration and flexibility. This flexibility is a result of Apache’s modular design, which allows for such features as URL rewriting for native SSL encryption natively. Administrators can modify Apache to meet their needs by adding or removing modules as needed.

Pre-Flight Check

  • These instructions are intended specifically for viewing enabled Apache modules on Fedora 23. The process is the same on most Linux servers running Apache.
  • In this case, we’ll be working as root on a Liquid Web Self Managed Fedora 23 server running Apache 2.4.

Viewing Loaded Apache Modules

For a list of all loaded Apache modules, run:

httpd -M

To see the list in alphabetical order, run:

httpd -M | sort

On some versions of Linux operating systems, you can substitute “apachectl” for the “httpd” in those two commands to achieve the same result.