How to Install PhpMyAdmin

---

 

Introduction

While many users need the functionality of a database management system like MySQL, they may not feel comfortable interacting with the system solely from the MySQL prompt.

phpMyAdmin was created so that users can interact with MySQL through a web interface. In this guide, we’ll discuss how to install and secure phpMyAdmin so that you can safely use it to manage your databases from an Ubuntu 16.04 system.

 

Prerequisites

Before you get started with this guide, you need to have some basic steps completed.

First, we’ll assume that you are using a non-root user with sudo privileges, as described in steps 1-4 in the initial server setup of Ubuntu 16.04.

We’re also going to assume that you’ve completed a LAMP (Linux, Apache, MySQL, and PHP) installation on your Ubuntu 16.04 server. If this is not completed yet, you can follow this guide on installing a LAMP stack on Ubuntu 16.04.

Finally, there are important security considerations when using software like phpMyAdmin, since it:

• Communicates directly with your MySQL installation
• Handles authentication using MySQL credentials
• Executes and returns results for arbitrary SQL queries

For these reasons, and because it is a widely-deployed PHP application which is frequently targeted for attack, you should never run phpMyAdmin on remote systems over a plain HTTP connection. If you do not have an existing domain configured with an SSL/TLS certificate, you can follow this guide on securing Apache with Let’s Encrypt on Ubuntu 16.04.

Once you are finished with these steps, you’re ready to get started with this guide.

 

Step One €” Install phpMyAdmin

To get started, we will install phpMyAdmin from the default Ubuntu repositories.

We can do this by updating our local package index and then using the apt packaging system to pull down the files and install them on our system:

• sudo apt-get update
• sudo apt-get install phpmyadmin php-mbstring php-gettext

This will ask you a few questions in order to configure your installation correctly.

Warning: When the first prompt appears, apache2 is highlighted, but not selected. If you do not hit Space to select Apache, the installer will not move the necessary files during installation. Hit Space, Tab, and then Enter to select Apache.

• For the server selection, choose apache2.
• Select yes when asked whether to use dbconfig-common to set up the database
• You will be prompted for your database administrator’s password
• You will then be asked to choose and confirm a password for the phpMyAdmin application itself

The installation process actually adds the phpMyAdmin Apache configuration file into the /etc/apache2/conf-enabled/ directory, where it is automatically read.

The only thing we need to do is explicitly enable the PHP mcrypt and mbstring extensions, which we can do by typing:

• sudo phpenmod mcrypt
• sudo phpenmod mbstring

Afterwards, you’ll need to restart Apache for your changes to be recognized:

• sudo systemctl restart apache2

You can now access the web interface by visiting your server’s domain name or public IP address followed by /phpmyadmin:

https://domain_name_or_IP/phpmyadmin

You can now log into the interface using the root username and the administrative password you set up during the MySQL installation.

When you log in, you’ll see the user interface, which will look something like this:

Step Two €” Secure your phpMyAdmin Instance

We were able to get our phpMyAdmin interface up and running fairly easily. However, we are not done yet. Because of its ubiquity, phpMyAdmin is a popular target for attackers. We should take extra steps to prevent unauthorized access.

One of the easiest way of doing this is to place a gateway in front of the entire application. We can do this using Apache’s built-in .htaccess authentication and authorization functionalities.

Configure Apache to Allow .htaccess Overrides

First, we need to enable the use of .htaccess file overrides by editing our Apache configuration file.

We will edit the linked file that has been placed in our Apache configuration directory:

• sudo nano /etc/apache2/conf-available/phpmyadmin.conf

We need to add an AllowOverride All directive within the <Directory /usr/share/phpmyadmin>section of the configuration file, like this:

/etc/apache2/conf-available/phpmyadmin.conf

<Directory /usr/share/phpmyadmin>    Options FollowSymLinks    DirectoryIndex index.php    AllowOverride All    . . .

When you have added this line, save and close the file.

To implement the changes you made, restart Apache:

• sudo systemctl restart apache2

Create an .htaccess File

Now that we have enabled .htaccess use for our application, we need to create one to actually implement some security.

In order for this to be successful, the file must be created within the application directory. We can create the necessary file and open it in our text editor with root privileges by typing:

• sudo nano /usr/share/phpmyadmin/.htaccess

Within this file, we need to enter the following information:

/usr/share/phpmyadmin/.htaccess

AuthType BasicAuthName “Restricted Files”AuthUserFile /etc/phpmyadmin/.htpasswdRequire valid-user

Let’s go over what each of these lines mean:

• AuthType Basic: This line specifies the authentication type that we are implementing. This type will implement password authentication using a password file.
• AuthName: This sets the message for the authentication dialog box. You should keep this generic so that unauthorized users won’t gain any information about what is being protected.
• AuthUserFile: This sets the location of the password file that will be used for authentication. This should be outside of the directories that are being served. We will create this file shortly.
• Require valid-user: This specifies that only authenticated users should be given access to this resource. This is what actually stops unauthorized users from entering.

When you are finished, save and close the file.

Create the .htpasswd file for Authentication

The location that we selected for our password file was “/etc/phpmyadmin/.htpasswd”. We can now create this file and pass it an initial user with the htpasswd utility:

• sudo htpasswd -c /etc/phpmyadmin/.htpasswd username

You will be prompted to select and confirm a password for the user you are creating. Afterwards, the file is created with the hashed password that you entered.

If you want to enter an additional user, you need to do so without the -c flag, like this:

• sudo htpasswd /etc/phpmyadmin/.htpasswd additionaluser

Now, when you access your phpMyAdmin subdirectory, you will be prompted for the additional account name and password that you just configured:

https://domain_name_or_IP/phpmyadmin

After entering the Apache authentication, you’ll be taken to the regular phpMyAdmin authentication page to enter your other credentials. This will add an additional layer of security since phpMyAdmin has suffered from vulnerabilities in the past.

Read More

phpMyAdmin Installation Tutorial

 

All hosting accounts on the SiteGround servers come with pre-installed phpMyAdmin software. The application can be opened from cPanel -> phpMyAdmin tool.

However, you may need to install phpMyAdmin manually. The easiest way is to install the application from the Softaculous tool in cPanel. Alternatively, you can perform the installation manually.

Manual PhpMyAdmin Installation

To install phpMyAdmin manually, you must first download the latest version of the software from the official project download page. Then, upload the downloaded archive on your account via FTP in the public_html folder.

Once the package is uploaded on your account, you must extract it, which will result in a new folder named phpMyAdmin-X.X.X where X.X.X is the version of the software you downloaded. If you want, you can rename that folder to phpmyadmin, so that you can access the application later with http://yourdomainname.com/phpmyadmin.

Next step is to access the folder which you created with your browser. If you have renamed the folder to phpmyadmin, then the URL should be http://yourdomainname.com/phpmyadmin. This will open the phpMyAdmin login page.

To use the software you should input a valid MySQL username and password and click the Go button. You can also use your cPanel username and password, which will allow you to manage all of the databases on your hosting account.

Read More

How To Secure Apache

 

Introduction

Let’s Encrypt is a Certificate Authority (CA) that provides an easy way to obtain and install free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx. In this tutorial, you will use Certbot to obtain a free SSL certificate for Apache on Ubuntu 18.04 and set up your certificate to renew automatically.

This tutorial will use a separate Apache virtual host file instead of the default configuration file. We recommend creating new Apache virtual host files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration.

Prerequisites

To follow this tutorial, you will need:

• One Ubuntu 18.04 server set up by following this initial server setup for Ubuntu 18.04 tutorial, including a sudo non-root user and a firewall.
• A fully registered domain name. This tutorial will use example.com throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.
• Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.
  • An A record with example.com pointing to your server’s public IP address.
  • An A record with www.example.com pointing to your server’s public IP address.
• Apache installed by following How To Install Apache on Ubuntu 18.04. Be sure that you have a virtual host file for your domain. This tutorial will use /etc/apache2/sites-available/example.com.confas an example.

Step 1 — Installing Certbot

The first step to using Let’s Encrypt to obtain an SSL certificate is to install the Certbot software on your server.

Certbot is in very active development, so the Certbot packages provided by Ubuntu tend to be outdated. However, the Certbot developers maintain a Ubuntu software repository with up-to-date versions, so we’ll use that repository instead.

First, add the repository:

• sudo add-apt-repository ppa:certbot/certbot

You’ll need to press ENTER to accept. Then, update the package list to pick up the new repository’s package information:

• sudo apt update

And finally, install Certbot’s Apache package with apt:

• sudo apt install python-certbot-apache

Certbot is now ready to use, but in order for it to configure SSL for Apache, we need to verify some of Apache’s configuration.

Step 2 — Set Up the SSL Certificate

Certbot needs to be able to find the correct virtual host in your Apache configuration for it to automatically configure SSL. Specifically, it does this by looking for a ServerName directive that matches the domain you request a certificate for.

If you followed the virtual host set up step in the Apache installation tutorial, you should have a VirtualHost block for your domain at /etc/apache2/sites-available/example.com.conf with the ServerNamedirective already set appropriately.

To check, open the virtual host file for your domain using nano or your favorite text editor:

• sudo nano /etc/apache2/sites-available/example.com.conf

Find the existing ServerName line. It should look like this:

/etc/apache2/sites-available/example.com.conf

...
ServerName example.com;
...

If it does, exit your editor and move on to the next step.

If it doesn’t, update it to match. Then save the file, quit your editor, and verify the syntax of your configuration edits:

• sudo apache2ctl configtest

If you get an error, reopen the virtual host file and check for any typos or missing characters. Once your configuration file’s syntax is correct, reload Apache to load the new configuration:

• sudo systemctl reload apache2

Certbot can now find the correct VirtualHost block and update it.

Next, let’s update the firewall to allow HTTPS traffic.

Step 3 — Allowing HTTPS Through the Firewall

If you have the ufw firewall enabled, as recommended by the prerequisite guides, you’ll need to adjust the settings to allow for HTTPS traffic. Luckily, Apache registers a few profiles with ufw upon installation.

You can see the current setting by typing:

• sudo ufw status

It will probably look like this, meaning that only HTTP traffic is allowed to the web server:

Output

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Apache                     ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Apache (v6)                ALLOW       Anywhere (v6)

To additionally let in HTTPS traffic, allow the Apache Full profile and delete the redundant Apache profile allowance:

• sudo ufw allow ‘Apache Full’
• sudo ufw delete allow ‘Apache’

Your status should now look like this:

• sudo ufw status

Output

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Apache Full                ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Apache Full (v6)           ALLOW       Anywhere (v6)        

Next, let’s run Certbot and fetch our certificates.

Step 4 — Obtaining an SSL Certificate

Certbot provides a variety of ways to obtain SSL certificates through plugins. The Apache plugin will take care of reconfiguring Apache and reloading the config whenever necessary. To use this plugin, type the following:

• sudo certbot –apache -d example.com -d www.example.com

This runs certbot with the --apache plugin, using -d to specify the names you’d like the certificate to be valid for.

If this is your first time running certbot, you will be prompted to enter an email address and agree to the terms of service. After doing so, certbot will communicate with the Let’s Encrypt server, then run a challenge to verify that you control the domain you’re requesting a certificate for.

If that’s successful, certbot will ask how you’d like to configure your HTTPS settings:

Output

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Select your choice then hit ENTER. The configuration will be updated, and Apache will reload to pick up the new settings. certbot will wrap up with a message telling you the process was successful and where your certificates are stored:

Output

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-07-23. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Your certificates are downloaded, installed, and loaded. Try reloading your website using https:// and notice your browser’s security indicator. It should indicate that the site is properly secured, usually with a green lock icon. If you test your server using the SSL Labs Server Test, it will get an A grade.

Let’s finish by testing the renewal process.

Step 5 — Verifying Certbot Auto-Renewal

Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The certbot package we installed takes care of this for us by adding a renew script to /etc/cron.d. This script runs twice a day and will automatically renew any certificate that’s within thirty days of expiration.

To test the renewal process, you can do a dry run with certbot:

• sudo certbot renew –dry-run

If you see no errors, you’re all set. When necessary, Certbot will renew your certificates and reload Apache to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.

Read More

How To Configure the Apache Web Server

 

What is Apache?

Apache is the most popular web server on the internet. It is used to serve more than half of all active websites. Although there are many viable web servers that will serve your content, it is helpful to understand how Apache works because of its ubiquity. In this article, we will examine some general configuration files and options that can be controlled within them. This article will follow the Ubuntu/Debian layout of Apache files, which is different from how other distributions build the configuration hierarchy.

How to Install Apache on Ubuntu and Debian

If you do not already have Apache installed, you can do so now by issuing the following commands:

sudo apt-get update
sudo apt-get install apache2

This is all that is necessary to have a working web server. If you visit your VPS’s IP address in a web browser, you will get the default Apache index page:

your_domain_name_or_ip_address

It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.

The Apache File Hierarchy in Ubuntu and Debian

On Ubuntu and Debian, Apache keeps its main configuration files within the “/etc/apache2” folder:

cd /etc/apache2
ls -F

apache2.conf  envvars     magic            mods-enabled/  sites-available/
conf.d/       httpd.conf  mods-available/  ports.conf     sites-enabled/

There are a number of plain text files and some sub-directories in this directory. These are some of the more useful locations to be familiar with:

• apache2.conf: This is the main configuration file for the server. Almost all configuration can be done from within this file, although it is recommended to use separate, designated files for simplicity. This file will configure defaults and be the central point of access for the server to read configuration details.
• ports.conf: This file is used to specify the ports that virtual hosts should listen on. Be sure to check that this file is correct if you are configuring SSL.
• conf.d/: This directory is used for controlling specific aspects of the Apache configuration. For example, it is often used to define SSL configuration and default security choices.
• sites-available/: This directory contains all of the virtual host files that define different web sites. These will establish which content gets served for which requests. These are available configurations, not active configurations.
• sites-enabled/: This directory establishes which virtual host definitions are actually being used. Usually, this directory consists of symbolic links to files defined in the “sites-available” directory.
• mods-[enabled,available]/: These directories are similar in function to the sites directories, but they define modules that can be optionally loaded instead.

As you can see, Apache configuration does not take place in a single monolithic file, but instead happens through a modular design where new files can be added and modified as needed.

Looking at the Apache2.conf File

The main configuration details for your Apache server are held in the “/etc/apache2/apache2.conf” file.

This file is divided into three main sections: configuration for the global Apache server process, configuration for the default server, and configuration of Virtual Hosts.

In Ubuntu and Debian, the majority of the file is for global definitions, and the configuration of the default server and virtual hosts is handled at the end, by using the “Include …” directive.

The “Include” directive allows Apache to read other configuration files into the current file at the location that the statement appears. The result is that Apache dynamically generates an overarching configuration file on startup.

If you scroll to the bottom of the file, there are a number of different “Include” statements. These load module definitions, the ports.conf document, the specific configuration files in the “conf.d/” directory, and finally, the Virtual Host definitions in the “sites-enabled/” directory.

We will focus on the first part of the file to learn how Apache defines its global settings.

Global Configuration Section

This section is used to configure some options that control how Apache works as a whole.

There are some interesting options you may want to modify in this section:

Timeout

By default, this parameter is set to “300”, which means that the server has a maximum of 300 seconds to fulfill each request.

This is probably too high for most set ups and can safely be dropped to something between 30 and 60 seconds.

KeepAlive

This option, if set to “On”, will allow each connection to remain open to handle multiple requests from the same client.

If this is set to “Off”, each request will have to establish a new connection, which can result in significant overhead depending on your setup and traffic situation.

MaxKeepAliveRequests

This controls how many separate request each connection will handle before dying. Keeping this number high will allow Apache to serve content to each client more effectively.

Setting this value to 0 will allow Apache to serve an unlimited amount of request for each connection.

KeepAliveTimeout

This setting specifies how long to wait for the next request after finishing the last one. If the timeout threshold is reached, then the connection will die.

This just means that the next time content is requested, the server will establish a new connection to handle the request for the content that make up the page the client is visiting.

MPM Configuration

The next section specifies the configuration of the MPM (Multi-Processing Module) options. You can cross-reference which section your Apache installation was compiled with by exiting into the terminal and typing:

apache2 -l

Compiled in modules:
  core.c
  mod_log_config.c
  mod_logio.c
  prefork.c
  http_core.c
  mod_so.c

As you can see, in this server, “prefork.c” is a module that was compiled in and is also in the “apache2.conf” file. Your installation may have multiple to choose from, but only one can be selected.

You can adjust the configuration of the prefork MPM in the appropriate section.

Exploring the Default Virtual Host File

The default Virtual Host declaration can be found in a file called “default” in the “sites-available” directory.

We can learn about the general format of a Virtual Host file by examining this file. Open the file with the following command:

sudo nano /etc/apache2/sites-available/default

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
. . .

The default Virtual Host is configured to handle any request on port 80, the standard http port. This is defined in the declaration header where it says “*:80”, meaning port 80 on any interface.

This does not mean that it will necessarily handle each request to the server on this port however. Apache uses the most specific Virtual Host definition that matches the request. This means that if there was a more specific definition, it could supersede this definition.

Virtual Host Top Level Configuration

These options are set within the Virtual Host definition outside of any other lower level sub-declaration. They apply to the whole Virtual Host.

The “ServerAdmin” option specifies a contact email that should be used when there are server problems.

This can be inserted into an error page if you have “ServerSignature” set to “Email” in the “/etc/apache2/conf.d/security” file, so make sure you are willing to receive the mail if you adjust that setting.

If we were using this as a template for other Virtual Host definitions, we would want to add a “ServerName” definition that specifies the domain name or IP address that this request should handle. This is the option that would add specificity to the Virtual Host, allowing it to trump the default definition if it matches the ServerName value.

You can also make the Virtual Host apply to more than one name by using the “ServerAlias” definition. This provide alternate paths to get to the same content. A good use-case for this is adding the same domain, preceded by “www”.

The “DocumentRoot” option specifies where the content that is requested for this Virtual Host will be located. The default Virtual Host is set up to serve content out of the “/var/www” directory on Ubuntu.

Directory Definitions

Within the Virtual Host definition, there are definitions for how the server handles different directories within the file system. Apache will apply all of these directions in order from shortest to longest, so there is again a chance to override previous options.

The first directory definition applies rules for the “/”, or root, directory. This will provide the baseline configuration for your Virtual Host, as it applies to all files served on the file system.

By default, Ubuntu does not set up any access restrictions to the filesystem. Apache recommends that you add some default access restrictions. You can modify this like so:

<Directory />
	Options FollowSymLinks
	AllowOverride None
	Order Deny,Allow
	Deny from All
</Directory>

This will deny access to all content unless specified otherwise in subsequent directory definitions.

The next directory definition is for the document root, so it specifies the “allow from all” option that overrides the “/” option for this directory.

The “AllowOverride” option is used to decide whether an “.htaccess” file can override settings if it is placed in the content directory. This is not allowed by default, but can be useful to enable in a variety of circumstances.

Alias and ScriptAlias Statements

Directory definitions are sometimes preceded by “Alias” or “ScriptAlias” statements. Alias maps a url path to a directory path.

ScriptAlias operates in the same way, but is used to define directories that will have executable components in them.

For instance, this line in a Virtual Host that handles request to “example.com” would allow access to content within “/path/to/content/” by navigating to “example.com/content/”:

Alias /content/ /path/to/content/

Following the alias, you should remember to define the directory with access privileges as discussed in the previous section.

Enabling Sites and Modules in Apache

Once you have a Virtual Host file that meets your requirements, you can use the tools included with Apache to transition them into live sites.

To automatically create a symbolic link in the “sites-enabled” directory to an existing file in the “sites-available” directory, issue the following command:

sudo a2ensite virtual_host_file_name

After enabling a site, issue the following command to tell Apache to re-read its configuration files, allowing the change to propagate:

sudo service apache2 reload

There is also a companion command for disabling a Virtual Host. It operates by removing the symbolic link from the “sites-enabled” directory:

sudo a2dissite virtual_host_file_name

Again, reload the configuration to make the change happen:

sudo service apache2 reload

Modules can be enabled or disabled by using the “a2enmod” and “a2dismod” commands respectively. They work in the same way as the “site” versions of these commands.

Remember to reload your configuration changes after modules have been enabled or disabled as well.

Read More