Installing mod_ftp on Apache2.4 on Linux

I just completed the lovely process of modifying the Apache FTP module so that it would work on httpd2.4. The current versions of mod_ftp on the repository are built for apache2.2. Between version 2.2 and 2.4 there were a few changes to the core API, which means the modules need to be updated to work with the new API. To update the current module, you need to make 3 general changes.

Basically you will need to do the following:

1) First uninstall and delete your current version of mod_ftp. If you haven’t yet installed mod_ftp, good, otherwise if you have, save your configuration file before you uninstall so that it won’t need to be recreated.

2) Get a complete version of mod_ftp from the repository. I used the trunk (version 1.0.1) when doing my install.

3) Configure with apxs

4) Modify the source files for the new API by replacing all instances of ‘remote_ip’ with ‘client_ip’ and all instances of ‘remote_addr’ with ‘client_addr’.

5) Add a new data structure to the ftp_data_connections.c file. Directly before the ftp_open_dataconn function add the following code.

#if AP_MODULE_MAGIC_AT_LEAST(20111203,0)
struct core_filter_ctx {
apr_bucket_brigade *b;
apr_bucket_brigade *tmpbb;
};
#endif

6) make, make install and restart httpd

 

Later I’ll go through and completely document the process like I have with the other stuff. I don’t have the time currently but this problem thoroughly annoyed me.

Lack of Content

I must apologize for the lack of content recently. We have recently been revamping our software into a platform-as-a-service model. Later this summer we will be moving all this content to our website (http://www.avastechnology.com). In the mean time new we have brought on board a couple interns to help edit and organize the backlog of content and get it posted.

Over the last two years we have been developing a custom Content Management System for small businesses, particular service firms who work on a project basis. About a month before the proposed launch, the business model was changed to operate more like a platform-as-a-service than just a software offering. For the last two months we have been working on automating the application and platform management so web design companies can easily signup and use our platform with their clients.

Compressing all HTML pages with Apache2 on AWS

The Apache2 web server has two mods which can be used to compress data sent to the client (ie browser); mod_deflate and mod_gzip. The gzip mod is more versatile but more challenging to setup. For simple compression of HTML, CSS and JavaScript files, the deflate mod works just file.

Compression is particularly important on Amazon Web Services (AWS) because:

  • HTML is very redundant and bulky
  • Smaller files are sent to the client faster
  • AWS charges you based upon OUTPUT bandwidth; smaller files = less bandwidth usage per file

Simple activation of mod_deflate

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available and a SCP client (like WinSCP) to use when editing the configuration files.

  1. Log in to your instance via the SCP client then open the apache2 virtual hosts configuration file (“/etc/httpd/conf.d/vhosts.conf” for the default setup mentioned in other instructions here).
  2. Add the “AddOutputFilterByType DEFLATE text/html text/plain text/xml” Filter to each virtual host (virtual hosts are the groupings starting with “<VirtualHost “). You should inclose the filter in a conditional module statement (“<IfModule xxxx.x>”) to make sure your web server keeps running even if you happen to remove the deflate module.
  3. Save the virtual hosts configuration file.
  4. Open the SSH client and transfer to the root user (“sudo su”)
  5. Restart the apache2 service (“service httpd restart”).

The changes to the virtual hosts configuration file

  • <VirtualHost *:80>
  • ….
  • <IfModule mop_deflate.c>
  • AddOutputFilterByType DEFLATE text/html text/plain text/xml
  • </IFModule>
  • </VirtualHost>

Summary of command line inputs

  • $ sudo su
  • $ service httpd restart

Error with phpMyAdmin 3.5.4 showing Blank Screen

Earlier this week, I was going to update some database tables and attempted to log in to phpMyAdmin when I got a blank screen. If you’ve ever programed much in PHP, a blank screen almost always means one of two things:

  1. You never accessed the PHP file
  2. The PHP Script had a fatal error and error codes are set to off

After some debugging (detailed below) it turns out phpMyAdmin v3.5.4 has a fatal error where the script files are loaded in the wrong order. With PHP errors fully on, PHP kicked “Fatal error: Call to undefined function PMA_sanitize() in /usr/share/phpMyAdmin/libraries/Message.class.php on line 540”. All it took to fix was adding a line to call the sanitizing libraries before allowing the message class to be loaded. Hopefully Amazon’s repository will be updated with v3.5.5 soon, so no one else encounters this problem.

Debugging Blank Screen

Accessing the PHP Issue

For me, I found out after the fact that this step was not even necessary, but that is how debugging goes.

  1. Log into your AWS via SCP (like WinSCP)
  2. Find you installation of phpMyAdmin (the default YUM installed phpMyAdmin on an AWS Linux system is /usr/share/phpMyAdmin)
  3. Open the file “index.php” and add the following two lines on two new lines directly after the “<?php” at the beginning of the document. (‘echo “I AM phpMyAdmin”;’ and ‘exit;’) and save the file.
    • <?php
    • echo “I AM phpMyAdmin”;
    • exit;
    • /* vim: set expandtab sw=4 ts=4 sts=4: */
    • /**
  4. Attempt to access phpMyAdmin as you normally would. You should see a white screen with “I AM phpMyAdmin” on it. If you do, delete the two lines you just added, save the file and try to access phpMyAdmin again. If you get a blank screen this time then skip to the next section, since the web server is accessing phpMyAdmin.
  5. Log into your AWS server via a SSH client (like PUTTY)
  6. Type “sudo su” to transfer to the root user
  7. Restart the Apache2 web server (type “service httpd restart”). You should get two “OK”s
  8. Attempt to access phpMyAdmin as you normally would. You should see a white screen with “I AM phpMyAdmin” on it. If you do, delete the two lines you just added, save the file and try to access phpMyAdmin again. If you get a blank screen this time then skip to the next section, since the web server is accessing phpMyAdmin.
  9. Open the “phpMyAdmin.conf” file for apache2. The default AWS Linux location is /etc/httpd/conf.d/phpMyAdmin.conf.
  10. The default installation prevents everything but the localhost from accessing phpMyAdmin. Most likely you will add an exception for your computer’s IP address, or that of your VPN system. DO NOT, as per phpMyAdmin’s instructions, add the line “Require 0.0.0.0” or “Allow All” or “Allow 0.0.0.0”. All three of these settings create significant security holes. The resilience to brute force attacks is minimal and you will be hacked eventually.
  11. Restart the Apache2 web server (type “service httpd restart”). You should get two “OK”s
  12. Attempt to access phpMyAdmin as you normally would. You should see a white screen with “I AM phpMyAdmin” on it. If you do, delete the two lines you just added, save the file and try to access phpMyAdmin again. If you get a blank screen this time then skip to the next section, since the web server is accessing phpMyAdmin.
  13. Remove phpMyAdmin and reinstall it.

Identifying Fatal PHP Error

These steps identified the real problem and allowed for the quick patch.

  1. Log into your AWS server via a SCP client (like WinSCP)
  2. Open the apache2 configuration file for phpMyAdmin (“/etc/httpd/conf.d/phpMyAdmin.conf”) and add the following lines to the “<Directory /usr/share/phpMyAdmin/>” then save the file.

        <IfModule mod_php5.c>
    php_admin_flag engine on
    php_admin_value display_errors on
    php_admin_value error_reporting 30711
    php_admin_flag ini_set on
    </IfModule>

  3. Log in to your AWS server via SSH and restart apache2 (“service httpd restart”)
  4. Attempt to access phpMyAdmin as you normally would. Instead of a blank screen, you should get an error message along the lines of “Fatal error: Call to undefined function PMA_sanitize() in /usr/share/phpMyAdmin/libraries/Message.class.php on line 540”
  5. Open the file “/usr/share/phpMyAdmin/libraries/Message.class.php”
  6. At the top of the header comments, add the line “require_once(‘./libraries/sanitizing.lib.php’);”
  7. Save the Message.class.php file.
  8. Attempt to access phpMyAdmin as you normally would. It should work fine now. If you want to, you can go back to the apache2 phpMyAdmin configuration file (/etc/httpd/conf.d/phpMyAdmin.conf) and remove the lines you entered. If you have a public installation of phpMyAdmin, then you should remove them for security reasons.

Installing and Configuring phpMyAdmin on AWS Amazon Linux AMI running Apache2 PHP and MySQL

Installing and Configuring phpMyAdmin on AWS Amazon Linux AMI running Apache2, PHP and MySQL (see the links for instructions on installing each software package).

This is actually really easy, assuming you are using the base version of PHP (5.3.X) from the AWS package repository. YUM has phpMyAdmin as a package and most of the default settings work just fine. The first time I install on an AWS instance it took maybe 15 minutes to complete.

Installing phpMyAdmin

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available and a SCP client (like WinSCP) to use when editing the configuration files.

  1. Log in to your instance via the SSH client. Transfer to the root user (“sudo su”).
  2. Use YUM to install phpMyAdmin
  3. Press “Y” when it asks if you want to install phpMyAdmin
  4. Open the SCP client and go to the apache2 configuration files directory (default is “/etc/httpd/conf.d”)
  5. Open the “phpMyAdmin.conf” file.
  6. Add an access exception to apache2 authentication protocol. There are three safe ways to allow access to phpMyAdmin;
    1. Allow Exception from a static IP Address Under the Directory tag “/usr/share/phpMyAdmin/”, add the following line at the end of the <IfModule mod_authz_core.c><RequreAny> tag, “Require ip XXX.XXX.XXX.XXX” and the following line at the end of the <IfModule !mod_authz_core.c> tag, “Allow from XXX.XXX.XXX.XXX”. In each situation you should be replace XXX.XXX.XXX.XXX with the actual IP address.
    2. Allow access from a VPN You will need a Virtual Private Network setup already, which is well beyond these instructions. Under the Directory tag “/usr/share/phpMyAdmin/”, add the following line at the end of the <IfModule mod_authz_core.c><RequreAny> tag, “Require ip XXX.XXX.XXX.XXX” and the following line at the end of the <IfModule !mod_authz_core.c> tag, “Allow from XXX.XXX.XXX.XXX”. In each situation you should be replace XXX.XXX.XXX.XXX with the actual IP address.
    3. Use SSL Certificate for authentication These instructions are not complete yet.
  7. Save the edited “phpMyAdmin.conf” file.
  8. Verify the installation occurred correctly by starting/restarting the httpd service (in SSH “service httpd restart”)

Summary of command line inputs

  • $ sudo su
  • $ yum install phpmyadmin
  • …..
  • Do you want to install phpMyAdmin 5.x (Y/N): Y
  • $ service httpd restart

First few lines of phpMyAdmin.conf file with default installation path, edited for access by a single IP address

# phpMyAdmin – Web based MySQL browser written in php
#
# Allows only localhost by default
#
# But allowing phpMyAdmin to anyone other than localhost should be considered
# dangerous unless properly secured by SSL

Alias /phpMyAdmin /usr/share/phpMyAdmin
Alias /phpmyadmin /usr/share/phpMyAdmin

<Directory /usr/share/phpMyAdmin/>
<IfModule mod_authz_core.c>
# Apache 2.4
<RequireAny>
Require ip 127.0.0.1
Require ip ::1
Require ip XXX.XXX.XXX.XXX
</RequireAny>
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
Allow from XXX.XXX.XXX.XXX
</IfModule>
</Directory>

Configuring phpMyAdmin

The default configuration of phpMyAdmin needs only a few changes to get it working correctly.

  1. Log in to your instance via the SCP client (like WinSCP)
  2. Open the phpMyAdmin base directory (default AWS installation directory is “/usr/share/phpMyAdmin”)
  3. Open the file “config.sample.inc.php”
  4. Go down to the line “$cfg[‘blowfish_secret’] = ‘XXXXXXXX’;” where XXXXXX is some alphanumeric combination. Add a bunch more letters and numbers within the single quotes.
  5. Go down to the line “$cfg[‘Servers’][$i][‘controlhost’]” and make sure it is uncommented. After it, add “= ‘localhost’;”
  6. The next line should be “$cfg[‘Servers’][$i][‘controluser’]”and make sure it is uncommented. After it, add “= ‘USERNAME’;” where USERNAME is the username you want to log into phpMyAdmin using.
  7. The next line should be “$cfg[‘Servers’][$i][‘controlpass’]”and make sure it is uncommented. After it, add “= ‘PASSWORD’;” where PASSWORD is the password associated with the previously entered username.
  8. Save the file as “config.inc.php”.
  9. Use YUM to install phpMyAdmin
  10. Press “Y” when it asks if you want to install phpMyAdmin
  11. Open the SCP clint and go to the apache2 configuration files directory (default is “/etc/httpd/conf.d”)
  12. Open the “phpMyAdmin.conf” file.
  13. Direct your browser to “http://XXX.XXX.XXX.XXX/phpMyAdmin&#8221; where XXX.XXX.XXX.XXX is the IP address of your server. You should be prompted for a username and login. Enter the pair you just saved in the config file and you should run phpMyAdmin.

Creating a New Cron Job on AWS Linux AMI

Cron is a time-based program used explicitly to initiated other programs at particular times on a Linux system. AWS Linux AMI comes with cron pre-installed and configured, like every other modern Linux installation. The base configuration allows for set up of a task that should be run hourly, daily, weekly or monthly as well as any other time period.

Quick Job Setup

Setting up a job to run hourly, daily, weekly or monthly is very quick. These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Go to the ‘/etc’ directory
  3. Open the appropraite ‘cron.XXXXX’ directory. For example, if you want to add an hourly task, open the ‘cron.hourly’ directory.
  4. Create a new file (shift+F4)
  5. Add a single line for each job you want run. For example if you want to run a PHP script, type “/usr/bin/php -q /path/to/script/script.php”, substituting for the correct path to PHP and the script file.
  6. Save the file. The name doesn’t really matter so long as it is unique. Cron will call every file in the directory at the appropriate time and run the commands in each file.

Custom Job Setup

Setting up a job to run at custom time requires you to understand the crontab syntax. The syntax is not terribly complex (it is similar than Regular Expressions) but is complex enough that you don’t want to deal with it if you do not need to.

Crontab Syntax

Crontab is the configuration structure for cron jobs. Simply, the files are composed of two parts: the settings followed by the jobs.

Crontab settings

The settings section states what should be run, where it is located, who should run it (as in Linux User) and a few other special commands. In the below example, the first 4 lines are settings and the last line is a job.

Example crontab file

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
01 * * * * root run-parts /etc/cron.hourly

  • “SHELL” identifies which shell state you want to run the scripts under. If it is not included, most systems will default the shell indicated in ‘/etc/passwd’ or just fail to run.
  • “PATH” is location of the cron initiated scripts. If you are regularly running scripts in ‘/usr/bob/scripts’ you could add the path here to avoid having to type ‘/usr/bob/scripts’ for every script. In the above example, the PATH line would become “PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bob/scripts”
  • “MAILTO” is the address of the webmaster who will receive an email every time these scripts are run.
  • “HOME” is the home directory for cron. It is basically prefixed to any relative path name you use in any script. It is only actually useful if you are going to be running many scripts from the same crontab file.

Crontab jobs

The settings section is the easy part of crontab files. Each job is composed of seven fields each separated by a space. Any field that is not set identified with an asterisk (*).

minute hour day month weekday user cmd

  • minute is the minute the job is to be run.
  • hour is the hour (on a 24 hour clock) when the job is to be run.
  • day is the numerical representation of the day of the month. The values range from 1-31.
  • month is the month’s numerical representation. The values range from 1-12.
  • weekday is the day of the week you want the job to be run on. The values range from 0-7, with Sunday being 0 & 7. If the day and weekday are both specified, the command runs when EITHER is true.
  • user is the Linux user you want to run the command.
  • cmd is the command to be run. This is no different than the commands in the quick job setup section above.

With the exception of day and weekday, all of the other time commands must be true in order for the script to run.

Crontab also supports step function (non-whole number inputs) and ranges. Ranges work just like page ranges do in most word processors with comma (,) separating individual values and dashes (-) representing all values from the first number to the second number. For example, “3-5,7” would fire on 3, 4, 5, and 7. Step functions use a forward slash to fire when the value becomes a whole number. For example a minute value of “*/15” would fire every 15 minutes, when the current minute divided by 15 is a whole number.

Creating a new Crontab File

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Go to the ‘/etc/cron.d’ directory
  3. Create a new file (shift+F4)
  4. Add each setting value as its own line at the beginning of the file. The above example file’s values should work on the AWS Linux AMI installation.
  5. Add crontab job lines for each job you want to run.
  6. Save the file. The name doesn’t really matter so long as it is unique. Cron will call every file in the directory at the appropriate time and run the commands in each file.