Tag Archives: FTP

security administration on a shared Apache web server

Running WordPress on a shared Linux web server is an economical way to build a web site without the hassle and expense of maintaining a dedicated server.  However, there are some useful administrative and security functions handled by the host’s Apache web server software configuration, beyond the scope of what is provided by WordPress.  While the main server configuration files generally are not accessible to users whose web sites reside on a shared server, Apache supports a powerful mechanism, .htaccess files, which can give individual users of shared web servers a high degree of control over the security and configuration of their own domains.

In my case, the immediate problem was to find a substitute for FrontPage’s directory-oriented password protection facilities.  In FrontPage, one would create a private “sub-web”, and the FrontPage Server Extensions (FPSE) provided an interface for registering users and assigning them passwords.  My problem was to continue supporting this simple model of access control (which uses the Basic Access Authentication protocol) without depending on FPSE.  This is not the sort of access control that is governed by WordPress’ blog-oriented administration features, but it’s an extremely simple application of Apache security features that can be implemented through .htaccess.

Because .htaccess files have many options and a rather obscure syntax, they can be quite confusing and intimidating.  There are many published tips and tricks on the use of .htaccess – so many that it can be hard to know where to begin.  Before you curse the complexity of .htaccess, though, remember that this mechanism spares you from the vastly greater complexity of managing your own web server, and it gives you a high degree of administrative control over your own web site running in a shared server environment.

An instructive illustration can be found in the solution to my problem of using .htaccess to replicate the access control features that were supported by FrontPage.  The only tool I needed to use was the WebShell file and directory management facility of the HSphere Control Panel, a standard feature offered by my shared web hosting service provider.  (An essential capability of WebShell that was missing from the free FTP program I’m accustomed to using is the ability to see .htaccess files at all – these and other files whose names begin with a period are not displayed in my old FTP utility!)

Using WebShell to peruse the residue of my semi-defunct FrontPage site, I could see that FrontPage’s implementation of password-protected sub-webs actually was based on the .htaccess mechanism.  The root of the password-protected sub-web contained a .htaccess file, and this referred to a standard type of encrypted password file, named service.pwd, residing in FrontPage’s hidden _vti_pvt subdirectory.  Even after the FrontPage Server Extensions ceased to operate, this access control mechanism continued to function properly.  But without the support of FPSE, it was unclear how to go about registering new users or making any other changes to my site’s password protection.

After wading though Apache documentation and various references, here’s what I came up with.  In the directory I wanted to protect I created a new .htaccess file containing this:

AuthType basic
AuthName "Montage subscriber area"
AuthUserFile [server path to password file]
Require valid-user

where [server path to password file] is the local path specification of my encrypted password file within the server filing system.  As for the password file itself, this is a text file containing entries of the following form:


I.e. each line begins with a username, followed by a colon, followed by the user’s encrypted password.  But where do the encrypted passwords come from?  There are a variety of ways to get these, including free online forms that can generate them for you.  Strangely, most of these free services also ask you to provide the associated userid, even though this should not be necessary, since the encryption depends only on the password, not the userid.  Another alternative is to create a simple PHP program, which can generate and display a valid encryption for a given password.  (Note that the encryption is really a hash, and its value is not unique.)

I was able to copy lines from my old FrontPage-generated password file, and these entries worked fine, even though I moved, renamed, and edited the password file.  For the problem of adding new users and passwords, I discovered that the HSphere Control Panel’s WebShell interface makes password file maintenance even easier, using its “Protect Wizard”.  This facility simplifies a number of basic .htaccess maintenance tasks, including the creation of encrypted password file entries in conjunction with adding, deleting, and modifying registered users.  Sheesh – if I had understood this in the first place, I’d never have had to learn as much as I did about the wonders of .htaccess!

Related references:

Here is a sampling of additional references about .htaccess tips and tricks:

WordPress site backup

Whenever I begin using a new development tool, one of my first tasks is to understand how to backup my work and then actually test the backup and restore procedures.  Of course, our web hosting service performs its own regular backups, but I am not content to rely exclusively upon that.  I want to be in control of my own, deliberate backups as well.

The HSphere Control Panel (version 3.5.1) provided by our web hosting service includes a button for launching phpMyAdmin (version 3.5.3), which can be used to generate a backup of the entire MySQL database supporting our WordPress web site.  There is a WordPress Codex page that describes how to use the phpMyAdmin facility, but this documentation is somewhat outdated.  Here are the steps I’ve been using, attempting to reconcile outdated WordPress Codex information with phpMyAdmin 3.5.3:

  1. Launch the HSphere Control Panel for my web site.
  2. Click on the phpMyAdmin icon – this launches in a new browser window.
  3. Select the site’s WordPress database, listed at left on the phpMyAdmin screen.
  4. Click the Export tab.
  5. Choose the option “Custom – display all possible options”.
  6. Under “Output:”, choose “Save output to a file”.
  7. Under “Object creation options, Add statements:”, check the option to “Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT statement”.
  8. Also under “CREATE TABLE options:”, check the “IF NOT EXISTS” option.
  9. Leaving other options at their default settings, click the Go button.
  10. In the Save As dialog, navigate to the desired local directory and save the generated .SQL file.

The resulting .SQL file is just a type of text file, more readable in WORDPAD than in NOTEPAD, because of line termination issues.  The initial size of this file, uncompressed, was 267KB, i.e. well under 1MB.  As the size of this file increases, I will use one of the available compression options that phpMyAdmin supports, e.g. to produce a much smaller ZIP file.

WordPress supports its own administrative facilities for Export and Import (under the Dashboard’s Tools menu), providing a convenient sort of backup/restore capability, although that is not their primary intent.  These commands are mainly intended for moving content from one site to another, including support of many non-WordPress blogging systems, using a special type of XML file representation.  The resulting files are much more compact (initially just 7KB) and readable than the MySQL database dumps generated by phpMyAdmin, but they constitute a less complete form of backup.  Here’s an excerpt from Export screen about WordPress’ XML file format:

This format, which we call WordPress eXtended RSS or WXR, will contain your posts, pages, comments, custom fields, categories, and tags.

Aside from backing up the site’s WordPress data, there is also the matter of backing up its installed programs, plugins, etc.  While our hosting service handled the installation, and they may take responsibility for WordPress updates, I thought it advisable to make a backup of the entire initial WordPress installation.  This was easy to do via FTP in one fell swoop, although it took a fair amount of time to work its way through the entire WordPress sub-tree, which contained 1,755 files in 118 folders, totaling 13.1 MB.  (With ZIP compression this reduced to 5.49 MB.)  I don’t expect to perform this type of FTP-based backup on a regular basis, but it seems like a good idea to do it again after installing any new WordPress plugins.

Related references: