Tag Archives: WordPress

HeidiSQL+pLink+putty=Joy

Leave a reply

Logo for HeidiSQL, a slick GUI front-end for mySQL

After manually changing a hundred blog posts imported with another theme from “published” to “draft”, I figured it was time to actually look at my WordPress database, since we may wish to do some global link updates,  once we get all of the media imported from another blog.  One of the best tools for this on Windows is the wonderful HeidiSQL program.

My Ubuntu server which hosts mySQL wants an SSL connection to accomplish this, so SSL must be used with HeidiSQL. This is done by using a intermediate program called plink which sits between HeidiSQL and Putty (the terminal program for accessing the Linux command line).

I found an explanation of how to use pLink with HeidiSQL.  However, if you can reach the command line using Putty and an SSL connection on port 22,  then you don’t have to do the first part of the instructions, because you already have the server’s certificate installed on your machine. It was cool to be able to verify this in the Windows registry by looking at the registry key.  And then, I was in.

heidisqlscreen

 

 

Install Ubuntu 16.04 on VirtualBox

Leave a reply

The following is a step-by-step run through for installing Ubuntu 16.04 server as a virtual machine running under a Windows 10 host.  Two prerequisites:

Prepare the VirtualBox VM:

Click on “New” to create a new virtual machine: You’ll get this initial screen to choose the operating system you wish to install and choose a name for the your VM.

Ubuntu Install1.jpg

The next screen asks what you want to RAM memory. The recommended memory size is 768MB,  but I’ve had decent luck by boosting this to 4 gigs, (on my 8 gig Windows 10 workstation.).

UbuntuInstallMemory.jpg

Accept the next suggestion to create a virtual hard disk. The default 8GB is fine, because VirtualBox will expand this if necessary.

UbuntuHD.jpg

Accept the default next screen, to choose the file type.

VirtualHardDisk.jpg

… and accept the default “dynamically allocated”

DiskFixedSize.jpg

 

Finally you can choose the file size:

FileSize.jpg

In this case,  I chose 16 gigabytes.

Once you have completed the screens above, you need to change two other parameters before starting the actual installation:

Under Settings,  change the networking connection to “bridged adapter”

NetworkSettings.jpg

Under storage, point the little CD image to your .iso file.

StorageSettins.jpg

 

Install Ubuntu 16.04

At this point you are ready to start the VM, and go through installing Ubuntu from the .iso file.  This is the standard Ubuntu installation from here on out… run from a  console command line interface. Terminal.jpg

After making your keyboard and language selections, there are several prompts for additional information:

Choose a HostName: UBSandbox

Choose an initial account: larryk

Choose a login name for this account: larryk

Choose a password: mypassword

Encrypt your  home directory?  No

Set your time zone. Setup will suggest your local timezone and then ask
Is this time zone correct?   Yes

Partitioning Method:  Choose “Use Entire Disk”,  don’t worry about LVN

Select Disk to partition…. choose the defaults.

Write changes to disk? Yes

At this point the files are copied to the disk, and the installation continues ore or less on its own for five minutes or so,  then you’ll see a question about the use of an http proxy. This relates to the configuration for the package manager which is used to update the operating system. You can probably ignore this unless you know you are in a corporate environment that uses an http proxy server.

Proxy.jpg

The next screen asks you about updating. I would answer this with the default “no automatic updates”. .

Updates.jpg

Finally there is a screen that allows you to select additional software packages to be installed. I would include the LAMP server, and the OpenSSH server.  LAMP will be the usual Linux+Apache web server + PHP + mySQL

install.jpg

But wait! There’s more!   You will be asked for a password for the  mySQL database. Ignore this at your peril…and choose the same password as you used for your user account at the beginning of your installation.

mysqlpassword.jpg

At this point the installation will run for a few minutes and then …

Will this ever end?   Accept the default ‘Yes” to install the GRUB boot loader.

grubboot.jpg

And then….  we’re done.

alldone.jpg

At this point, you should have a working web server that is running an IP address on your network.  To figure out that address. run ifconfig from the VM console.  In our case we’re at 192.168.219.213

ifconfig.jpg

Looks promising.  Now,  we can open a web browser from our Windows workstation (or any other machine on the network, and we should see the Apache web server home screen.

Screenshot_111816_125839_PM.jpg

We’re ready install WordPress.  Before doing that however, you might create a snapshot* of the current state of the VM.  This means we will always have a backup of the current machine that we can fall back to as we’re experimenting with installing things. If you haven’t already installed Ubuntu three or four times, you can always delete the whole VM and reinstall if you want to start from square 1.

 

*I know….this is for a future blog post.

Install WordPress Using VirtualBox Part 2

Leave a reply

Because WordPress is such a popular program, there are tons of resources available. After searching for installing WordPress on Ubuntu Server … I found this page.  I followed all of the instructions, with the two exceptions:

  • I did not configure a static IP address for the sandbox server.
  • I prefaced all commands with sudo.

 Once this was accomplished,  I ended up with the default installation page at:

192.168.219.212/wordpress/

wordpress_install

The first page that comes up is a page which asks for information which will will be written to the wp-config file.   Note that all of the parameters are identical to the ones that were used when setting up the mySQL database in the initial step.

wpsetup

The next page asks for the WordPress site name, and a login password.

wpinstall2

About 30 seconds later, you should see a message that WordPress was installed, and that you can now log in with the name and password that you just created in the last screen.  Do that and the familiar WordPress dashboard will come up.  Hooray!

wpdashboard

Install WordPress Using VirtualBox Part 1

Leave a reply

Now that we’re WordPress experts,  I’m looking to get an instance of WordPress up and running to be able to experiment.  I’ve been trying this using VirtualBox on Windows 10.  I wanted to create a virtual web server using the latest Ubuntu server 16.04.

  1. Download the .iso file from Ubuntu
  2. Create a new virtual machine, “Ubuntu Server 16.04” within VirtuaBox. I gave it 4 gigs of RAM (half of the physical RAM in my workstation), and excepted all defaults for disk size, etc. The only difference afterwards is to change the Network Adapter from NAT to Bridged.virtualbox1

    3. Install Ubuntu. 
    During the Ubuntu installation, choose the option to install a LAMP server. This includes mySQL, the Apache web server, and the PHP language.

linux_install

4. Once Ubuntu is installed, the server will reboot. You will probably see that there are updates available.  So, to get these run the following commands:

sudo apt-get update
sudo apt-get upgrade

5. Figure out your local IP address:

ifconfig

If this address isn’t on your own subnet, then you can change the network specifications for the VM in VirtualBox from NAT to Bridged Adapter, then reboot the VM.

If all is well so far, you should see the Apache default home page when you type in the ip address into your browser.

apachedefault

At this point, we have a working web server running on our virtual machine.  Now we can actually install WordPress.  My first instinct for this was to use the apt-get method to install the files.

sudo apt-get install wordpress

This appeared to work but didn’t yield a running installation. So after searching I used these instructions to get to get a running WordPress installation.

 

Progress with MailClark, Slack, FileMaker, WordPress

Leave a reply

Somemotor-1381998_1280times you just have a week where you are grinding away at things, and nothing particularly new or spectacular happens, and no new revelations are on the horizon. This was one of those weeks.

MailClark and Slack

The MailClark experiment is moving into its third week. As I hoped, it  appears to be working well as an application for low-volume  email customer support. In another couple of weeks, I will introduce this to the rest of the customer support team, so that more than one of us can respond to emails and questions sent in to our help address.

FileMaker CRM

Our FileMaker CRM is taking shape. I have built the basic tables, and am working on the data entry screens. I’ve hosted it on a new Mac Mini with an SSD drive using FileMaker Server. This is the first time I’ve ever used an SSD up close and personal (all Linodes are SSD based), and I’m impressed with the speed.

FileMaker has been steadily improving the web client of the application called WebDirect. This is an effective implementation of the regular FileMaker desktop interface, but rendered in HTML5 and CSS for a web browser, which eliminates the need to install the FileMaker software client on your desktop workstation.  My thought is that we will provide access to the CRM via a virtual private networking connection rather than allowing direct access through our firewall.

Similar to FileMaker Go, the FileMaker client that runs on iPhones and iPads, I  expect to build dedicated data entry screens for the web clients. This means that each platform gets its  own screens….desktop,  iDevice, and web.  The startup script for the application will contain a CASE statement which determines which platform you are connecting with, and point you to the correct screen.

So far the data design and use cases appear to be pretty accurate and for the most part remain unchanged. One thing I have done is add a “reference” section. This will provide a front-end for the National Center for Educational Statistics database of public and private schools.

WordPress and Apache

I spent a couple days faffing about with my Apache / WordPress installation, trying to figure out what what slowing down our blog. It turns out to be hidden in plain sight, and here is one explanation.

 

Troubleshoot Apache with mod_status

Leave a reply

We are having a bit of a contretemps with one our of Linode blog hosts. This host is running Ubuntu Linux 12X  LTS and WordPress, and seems to be having fits of high CPU utilization. One way to see into the web hosting process is to examine the Apache mod_status page.

Mod_status is an Apache module which prints statistics about the Apache application. By default the page will be accessible using the the suffix of /server-status on your root web site URL. http://mysite.com/server-status. However, by default this is restricted to a request from a browser at the 127.0.0.1 address.

If you log into the console, you can attempt to see the status by running the following:

apachectl status

or if you aren’t logged in as root,

sudo apachectl status

This returns the status page.

Screenshot_071516_011101_PM

If you are attempting to access this from a browser on another workstation via http://mysite.com/server-status, you get a 403 message:

Screenshot_071516_110946_AM

The first thing is to find where this restriction is located. It is going to be in one of the Apache configuration files. These are located within /etc/apache2. If the status module is enabled, there will be a status.conf file that can be edited.

sudo nano  /etc/apache2/mods-enabled/status.conf

Screenshot_071516_112041_AM

Edit the lines after the <Location /server-status> line, per the instructions. After editing mine looked like:

<Location /server-status>
   SetHandler server-status
   #Require local 
   Require ip 192.168.xxx.0/24
</Location>

where “xxx” is your local subnet.  In the above example, I’m accessing the server from inside the firewall from a workstation located on the same subnet as the Apache server. (In reality, I’m actually accessing a server running within a VirtualBox virtual machine, located on my Windows machine. )

Once these changes are made you have to restart Apache.

service apache2 restart

 

If this is successful,  you get a page similar to the character-based page, but nicely formatted in html. Since the data is similar, however, if there is any issue trying to get at the statistics, probably the character-based method at the console is the first thing to try.

Screenshot_071516_011525_PM

Ah…but what if you get a page, but it isn’t a status page?  This is the problem we have with our WordPress site, and it has to do with which page is served as the default. http://myblog.com/server-status  returns the default page from the blog rather than the server-status page.  Stay tuned for that fix.

Tech Friday: Debugging the WordPress White Screen of Death

Leave a reply

motor-1381998_1280Problem: I attempted to change a password for a user of the WordPress web site. I got into the administrator’s dashboard, choose “Users”, found the person’s entry, changed their password, clicked on “save changes” and Poof! I get a blank screen.

 

It turns out there is a name for such screens, and the name is called the WordPress White Screen of Death, or WSOD.

There are a ton of possible causes for this, but many of them relate to a problem with PHP code located someplace  within WordPress, or within WordPress plugins. Since the WSOD is just that…it doesn’t show any kind of detailed error message, one approach to finding the problem is to enable error checking and display at the PHP level. This is a quick entry in the WordPress wp-config.php file located in the root WordPress directory.  Here’s the file as it shows up in FileZilla.

WP_Config

And here is the contents of the file as displayed in Notepad++

WP_DEBUG

The trick is simply to change false to true to enable the display of error codes.  And sure enough,  once I did that and retried the password change operation I saw the following message:

Fatal error: Call to undefined function curl_init() in /var/www/html/wordpress/wp-content/plugins/gmail-smtp/class.phpmaileroauthgoogle.php on line 171

This was an indication that a plugin which I had added was causing the error. Once I removed the plugin, I could change my user’s password without problems and the WSOD was banished, at least for now.

WordPress: Troubleshooting Contact Forms

Leave a reply

Down the rabbit holeI’m trying to get a contact form working on our WordPress site, and it is a little more complicated than I thought it might be.

The contact form plugin itself in WordPress. We’re using Contact Form 7. Documentation for Contact Form 7 says something to the effect “we’re sending upteen zillion eMails a day, and CF form “just works” for everybody.  Well, kinda, sorta. There are several other issues involved:

  • an MTA (mail transfer agent) which maybe (?)  has to be on the WordPress server
  • the php_mail() function which is part of PHP (the programming language for WordPress)
  • the wp_mail() function which may or may not call the php_mail() function
  • Restrictions on to and from addresses.

I wanted to just run everything through our Google Mail SMTP account, but that seems to add an additional layer.  So first I started with our blog site which is on another server, and tested whether the contact form worked there. It actually doesn’t,  that is, it appears to send mail correctly from the users’s perspective, but no email was received anywhere.

 

Per this note I checked to see if anything was listening on port 25, the usual SMTP port.

$ netstat -tanpl | grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3030/master
tcp6 0 0 ::1:25 :::* LISTEN 3030/master

$ lsof -i :25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 3030 root 12u IPv4 9667 0t0 TCP localhost:smtp (LISTEN)
master 3030 root 13u IPv6 9668 0t0 TCP ip6-localhost:smtp (LISTEN)

Looks promising.  it appears that both IP4 and IP6 are listening.

So, I created a basic PHP script to test at the server command line, and saved this as testphpmail.php. There are three parameters, the receiver’s address, the subject and the body of the message.

//This is a test of the basic PHP eMail function.

<?php
mail('joeblow@blow.com', "Test PHP Mail", "Test mail from PHP Mail");
?>

Run this script from the command line with the following command:

php -f testmail.php

This worked; I received the eMail. It shows that it comes from root.  At least  I knew that at least the fundamentals are in place on the server.

Checking the mail log,  at /var/log/mail.log I see the following:

$ cat/var/log/mail.log
May 20 14:28:17 li239-124 postfix/pickup[28709]: 11864F123: uid=0 from=<root>
May 20 14:28:17 li239-124 postfix/cleanup[28806]: 11864F123: message-id=<20160520142817.11864F123@localhost>
May 20 14:28:17 li239-124 postfix/qmgr[3039]: 11864F123: from=<root@localhost>, size=351, nrcpt=1 (queue active)
May 20 14:28:17 li239-124 postfix/smtp[28808]: 11864F123: to=<lkkg@myserver.org>,
relay=aspmx.l.google.com[173.194.204.27]:25, delay=0.21, delays=0.01/0.01/0.1/0.09, 
dsn=2.0.0, status=sent (250 2.0.0 OK 1463754497 e92si18328547qga.115 - gsmtp)

So this shows that the message was sent, using root@localhost as the sender’s address and my work eMail as the target.  And indeed, I received this email at work.

I checked the log file at /var/log/mail.log which presented various points of interest…including the fact that we are running the Postfix sendmail email server.  But there is also a status=bounced message for IP6.

$ cat /var/log/mail.log 
May 20 13:50:15 li239-124 postfix/pickup[13030]: 2973DF23B: uid=33 from=<www-data>
May 20 13:50:15 li239-124 postfix/cleanup[14078]: 2973DF23B: message-id=<49922f80371c574883b8b8d699f47d9b@blog.kidsgardening.org>
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 2973DF23B: from=<www-data@localhost>, size=869, nrcpt=1 (queue active)
May 20 13:50:15 li239-124 postfix/smtp[14080]: 2973DF23B: to=<lkkg@myserver.org>, relay=aspmx.l.google.com[2607:f8b0:400d:c08::1a]:25, delay=0.41, delays=0.01/0.01/0.09/0.3, dsn=5.7.1, 
status=bounced (host aspmx.l.google.com[2607:f8b0:400d:c08::1a] said: 550-5.7.1 [2600:3c03::f03c:91ff:fe6e:916c] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication. 
Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information. a139si18154032qkc.140 - gsmtp (in reply to end of DATA command))
May 20 13:50:15 li239-124 postfix/cleanup[14078]: 8DAAAF23C: message-id=<20160520135015.8DAAAF23C@localhost>
May 20 13:50:15 li239-124 postfix/bounce[14081]: 2973DF23B: sender non-delivery notification: 8DAAAF23C
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 8DAAAF23C: from=<>, size=3381, nrcpt=1 (queue active)
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 2973DF23B: removed
May 20 13:50:15 li239-124 postfix/local[14082]: 8DAAAF23C: to=<www-data@localhost>, relay=local, delay=0.01, delays=0/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 8DAAAF23C: removed
root@li239-124:~# dpkg -S 'which sendmail'
dpkg-query: no path found matching pattern *which sendmail*.
root@li239-124:~# netstat -tanpl | grep:25
grep:25: command not found
root@li239-124:~# netstat -tanpl | grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3030/master
tcp6 0 0 ::1:25 :::* LISTEN 3030/master

Just to be sure, I ran the PHP script again having it send to my home email address which is outside my work domain.  This bounced and I didn’t receive it at the home address.  Now,  in theory, this might not be a bad thing, since all of the Contact Form 7  messages from the blog page should be sent to an address within the same domain, like customerservice@myserver.com.

So far, then we’ve established:

  • PostFix is installed on the blog’s server.
  • Contact Form 7 shows that it is sending message, but the messages are bouncing.  (Hmm…I wonder what I’ve been missing all those times? )

This is so typical of IT. You think you’re troubleshooting an issue on one server, and upon investigating the same issue on another server that you think is working…you find that it isn’t and down the rabbit hole you go!

WordPress Woes and .htaccess

Leave a reply

After spending months working on our new WordPress site hosted at Linode, we were ready to flip the DNS from xxx.xxx.xxx.xxx to a realdomainname.org.

“Not so fast!” said the SEO expert… “you need to have your 301s in place.” So, we went through the drill and identified the top 100 pages on the old site. These were pages that had been visited in the previous month or so, and also ones that we knew were especially popular. We then created an .htaccess file, which is a file containing instructions for any visitor who arrives at the new site via a search on an old URL from the old site.   Here’s a snippet of what it looks like to start.

# LK 5/2/2016 
Options +FollowSymLinks
RewriteEngine on
Redirect 301 /node/96821 http://www.realdomainname.org/toolbox/
Redirect 301 /node/120 http://www.realdomainname.org/designing/
Redirect 301 /node/2 http://www.realdomainname.org/
Redirect 301 /node/11522 http://www.realdomainname.org/basics/
Redirect 301 /node/13152 http://www.realdomainname.org/toolbox/
Redirect 301 /node/12931 http://www.realdomainname.org/activities/

So far so good. Except this is ass-backwards. We should have worked out the WordPress URLs before creating the .htaccess file because WordPress itself has something to say about the contents of the .htaccess file, viz:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

These entries in the WordPress file are created based on a WordPress setting under Settings->Permalinks which allow you to change what shows as a URL for access. You can choose among a number of options including having the blog post title in the URL as well as the post’s category. (another reason for assigning a post to only one category).

One you have saved the permalinks setting, WordPress will write to your .htaccess file. If this is the first time, you will see that the .htaccess file contains lines similar to those in the # BEGIN WordPress block above.  Otherwise, my guess is that WordPress rewrites the block to accommodate how you want the permalinks to appear.

Other issues:

Note the lines

<IfModule mod_rewrite.c>
RewriteEngine On

refer to an Apache web site module called mod_rewrite. This is a piece of code in the the Apache web server which accomodates the rewriting of URLS.  So, for example, maybe you have a post that is physically located at:

 /var/www/html/wordpress/wp-content/posts/mylovelypost.html

A default URL for a blog post might look something like:

http://www.realdomainname.com/index.php/wp-content/mylovelypost/

However, after implementing your pretty permalinks it will automatically reset itself to

http://www.realdomainname.com/mylovelypsost/

or even

http://www.realdomainname.com/mylovelycategory-mylovelypost/

if you choose to include a category.in the URL formula. This “virtual” URL is the one that gets indexed by the search engines, and so is worth giving some serious thought so that you get it right the first time.

Note that this whole exercise is possible only on self-hosted WordPress sites, not on sites hosted at WordPress.com. So, at this writing, the techfornoprofits.com  site is hosted at WordPress.com, and so URLs are fixed using the formula of http://site+year+month+day+blog_post_title.

https://techfornonprofits.com/2016/04/12/ten-ways-to-improve-a-grant-application/

So, having gotten the permalinks thing squared away, I then added the 301 redirects to the .htaccess file.  These are in the  format of:

Redirect 301 /node/96821 http://www.realdomainname.org/toolbox/

Statement = Redirect 301
Old site page name
New site address.

The /node/96821 address for the old site page is a convention from Drupal. (Drupal is another content management system. Our new WordPress site is  a conversion from a Drupal 6.7 site).

Two notes regarding the .htaccess file:

  1. The .htaccess file is normally a hidden file, so it isn’t visible within a normal directory listing. There is a setting in FileZilla which permanently “show hidden files”  If the file name is prefixed with a period, it is considered a “hidden” file.
    .
  2. Once the .htaccess file has been created the best practice is to turn off the ability for it to be written to by changing the file permissions. Conversely, if you either don’t see any changes or get an error message when attempting to adjust the Settings-Permalinks in WordPress….the .htaccess may either be non-existent, or flagged as read-only. WordPress has to be able to write changes to the .htaccess file.

At this point the permalinks are squared away, and the 301 redirects are in place. But our woes are just beginning!

WordPress: Fix the File Upload Size Limit

Leave a reply

On our WordPress site we want to allow the site manager the ability to upload PDF files which can then be downloaded by our blog viewers. While working out this process we ran into a problem with the file size; any file larger than 2 megabytes was not allowed to be uploaded to the site.

Rather than having this setting located somewhere within WordPress, it turns out that the setting is set by the PHP installation.  (PHP is the language that WordPress is written in, and WordPress the application is written as a series of PHP files).

As I was working through this issue, the first embarrassment was that I couldn’t even find the WordPress installation on my Linux server. Usually WordPress is supposed to be installed somewhere relatively transparent, like the /var/html/wordpress folder. Instead mine was buried under  /srv/www/li999-999.members.linode.com/public_html; somehow related to my virtual host from Linode

As my plumber says, when looking at the latest plumbing problem in our basement, “I wonder why they did that?”  Whatever. The way I finally found this out was to search for the one file that is in every WordPress site; wp-config.php.  I did this by firing up the FileZilla FTP program, and doing a search for remote files.

SearchRemoe

Having found the root directory of my WP installation,  I now needed to find the location of the PHP configuration file. I used a similar search in FileZilla and came up with two php.ini files.  Which was the “real” one?

Actually, I didn’t need to do that. Instead, I needed to get to have a script that calls the phpinfo() function which displays a nice list of all the php configuration parameters. Placed in the root directory of my web server, and then called from a web browser, this script displays all of the inner workings of the php configuration of my site.  Here’s the script:

<?php
// Show all information, defaults to INFO_ALL
phpinfo();

?>

This script is saved as GetPHPInfo.php and copied back to the root directory of the web server.

http://mywebsite/GetPHPInfo.php

Call this script in the web browser and it produces  the following:

PHP1

The above is just the tip of the iceberg. Scrolling waaaay down, I find the following parameter in the “core” section of the page:

php2

That is the size restriction, and it is this parameter that I need to change.  I’m thinking that 12 megs should be plenty.  Looking back up top in the 6th line, I see the “Loaded Configuration File” is located at:  /etc/php5/apache2/php.ini  This is the file I’m going to change. So, its back to FileZilla to find it, download it and edit it in Notepad++

PHPini

I downloaded the wp-config.php file to my local machine using FileZilla.  Then I edited the file using Notepad++. to change the  2M to 12M.  Then I uploaded the file via FileZilla back to the web server.

At this point I needed to reboot the web server, Apache2. Depending on the your installation, there are a couple ways to do this at the command line:

$ sudo /etc/init.d/apache2 restart

Or,  in the case of the lazy systems administrator, I just rebooted the whole server. This takes less than two minutes.

The result is now we can upload files that are a maximum of 12 megabytes in size.

I get to do this on another WordPress server too.  Oh joy!