Another Win - Redirecting HTTP to HTTPS; Untangling Apache Configuration Files

I posted a while back that I'd enabled SSL on one of my public domains for the first time.  I was running into issues with forcing SSL though.

The specific issue was that I'm running two websites on the Linode host - https://wigglit.com and http://unixfool.us.  One is using SSL certs when the other is not.  Each website had it's own VirtualHost configuration file.  When testing, I was able to reach https://wigglit.com without issue, but when going to http://wigglit.com, to ensure I'd be redirected to https://wigglit.com, the redirect was failing.  That issue causes problems in meeting Google's searching/indexing requirements.

I found that I had to create a third VirtualHost config file, specifically for the redirect to port 443.  So, I have a configuration file for unixfool.us:80, wigglit.com:80 (for the redirect to port 443), and wigglit.com:443.

I'd been struggling with this for days.  It was important that I have both wigglit.com:443 and unixfool.us:80, running on the Linode host, as I use unixfool.us to share photos.

I've been posting quite a bit about using AI/LLMs to assist in solving computing issues.  I'd previously been using ChatGPT.  I sometimes am frustrated with ChatGPT as I've to babysit it a lot - sometimes it's instructions aren't clear and I've also caught it sharing bad data more than once.  I know just enough to be able to question the data it offers.  I tried to leverage ChatGPT again with the SSL/Apache issue, but mid-stream, got frustrated and dediced to try a different LLM.  

I used Gemini (since I already have a Google account and heavly use Google tools).  I immediately noticed that Gemini appears to be the better AI, as it's answers were more clearly understandable (I didn't have to ask for clarification).  Also, I didn't catch it sharing bad data or questionable answers to my issue.  Usually, I am very clear in how I present the problem to the LLM, and in this case, it was no different.  I described the issue, shared the architectural layout of the Apache server and how I had it currently configured.  It was a decent paragraph-worth of information.  Gemini took the info and offered a clean solution!

I think I'll be using Gemini going forward.

Wordpress Woes

I did a dumb thing last week.

I'd been holding back on upgrading my Ubuntu server to 14.04...for good reason:  I was running software versions that weren't compatible with my version of Ubuntu.

Well, I upgraded anyways (after months of holding off).  It broke my web server and also reverted my Wordpress site back a few versions (3.8.x or something like that...I'd been running version 4.0).

That was this past Saturday.  Today is Tuesday afternoon and I'm almost finished restoring the site.

Things that broke:

Wordpress
PSAD
Apache

I'm going to specifically speak to Wordpress now.

This was actually an Apache/Wordpress combination issue.  I believe the version that Apache was upgraded to was 2.4.x.  It changed the default webserver location from /var/www to /var/www/html, which broke a LOT of my content.  The fix was easy:  I moved everything from /var/www to /var/www/html, ensuring the file and directory permissions didn't change.

Then, I found a multitude of issues with my Wordpress site's content:

1. All image links broke, meaning they wouldn't render, even after moving content to /var/www/html (but I could upload new pictures without issue -- and they'd render).
2. I couldn't perform upgrades to v4.0 via the GUI.
3. I couldn't install new plugins.
4. I couldn't install templates.

First thing I did was upgrade (manually, via CLI) to v4.0.  That cleared up some issues.

Next, I worked on trying to get the plugins to work.  I couldn't install new plugins.  I also couldn't update old plugins to new versions.  The error I would get was, "Unable to locate Wordpress content directory".  I'd also get "Unable to locate Wordpress plugin directory".  What I did was download (via web browser) the "third party host fix" plugin.  I loaded it to my Ubuntu server via SCP.  I then unzipped it, and moved the uncompressed directory to the plugins folder.  It still wouldn't work.  I found that a symlink was missing from /var/lib/wordpress/wp-content/plugins, so I created a new one:

lrwxrwxrwx 1 root root 60 Sep 30 19:48 third-party-host-fix -> /usr/share/wordpress/wp-content/plugins/third-party-host-fix

That's linked to /usr/share/wordpress/wp-content/plugins/third-party-host-fix...that also the directory where the actual plugin content is located.

After I did that, I was able to see the plugin in the UI.  I activated it successfully.  I then tried to update a plugin...I got a different error:  "Wordpress could not create directory".  Ugh...

I found the solution on how to fix that issue at https://help.ubuntu.com/community/WordPress.  I went to /usr/share/wordpress/wp-config.php and edited the following:

Changed:

define('WP_CONTENT_DIR', '/var/lib/wordpress/wp-content');

to read:

define('WP_CONTENT_DIR', '/var/www/wordpress/wp-content');

That fixed the issues of installing or updating templates and plugins.

The only issue I need to resolve now is the image rendering issue, but I think I'll just reload all the images, one at a time (there aren't all that many, I believe).

This was a horrible experience but the benefit was that it got me to delve and fix the issue (vs. just wiping everything and reinstalling the whole distribution).

UPDATE:

New issues --

1. Can't remove plugins.  Error message:  "Plugin could not be deleted due to an error: Unable to locate WordPress Plugin directory."
2. Using Photo Gallery plugin - galleries will render but the images will not show within the gallery UI.  I also can't seem to view the images via browser...may be another incorrect coding issue or even a permissions issue.

UPDATE 2:

1. I've fixed the issue with the Photo Gallery plugin.  I basically dumped the picture back in the directory where the plugin was looking for them (/usr/share/wordpress/wp-content/uploads/photo-gallery).  I hate how hodge-podge this is...crap is everywhere without standardization, but I'm to the point where I just want the site functional again.  I just hope things don't break when I next upgrade Wordpress.
2. I'll look into the "can't remove plugins" issue tomorrow.

PHPSysInfo installed on G4 PowerMac

I wanted to better understand the internals of the 'new' system and get a feel for how it deals with load, so I installed PHPSysInfo for Macs.

I had problems getting .php files to render (dunno why, as I run several sites that utilize PHP on my LAN. I guess the issue was that I keep forgetting that Macs are similar to BSD and that I'm still a bit intimidated by the file structure of Macs.), so I did a web search and found the following:

http://www.devarticles.com/c/a/Apache/Using-Apache-and-PHP-on-Mac-OS-X/

cd /etc/httpd

Next step is to use "root" privileges, start up the text editor named "Pico" and edit the "httpd.conf" file.

Use the following command in the Terminal.app:

sudo pico httpd.conf

Type the root password and you are ready to go.

Locate the 4 lines:

#LoadModule php4_module
#AddModule mod_php4.c
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps


Use your arrow keys to navigate the document and remove only the pound signs "#". The best way to navigate is to use the DOWN arrow key and stay to the left Side of the document. To remove the pound sign, hit the right arrow to the right Of the sign and then hit the DELETE key.

Warning: Only remove the pound signs!! Keep the lines of code where they are and do not relocate them!! You have been warned!

The changed lines should look like this:

LoadModule php4_module
AddModule mod_php4.c
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Save the file by hitting the CTRL + X keys. Pico will ask you if you want to save the document, just hit the Y key to say “YES”. By uncommenting the lines you will load PHP as a module and help the Apache Web Server Serve any PHP file types. You can also create PHP files with another extension simply by adding another Type to the list in the "httpd.conf" file.

What if I wanted all of my PHP files to end with the. bozo extension? Simple, just add this line to the "httpd.conf" file situated next to the AddType section.

AddType application/x-httpd-php .bozo

After you save the file and restart the Apache Web Server, any PHP file saved with that .bozo extension would display your PHP coding just like a normal PHP file. Now close and save the file. We have to restart the Apache Web Server for everything to take effect. If Apache is running, turn it off by clicking the "Web Sharing On" button that says, "Stop" located in the "Sharing" Section of the System Preferences.

This helped totally, and I can now monitor my system in a pretty GUI.

I'd still like to give ntop a spin, though. I friend showed me his install of ntop and I was highly impressed. Looks like a new project for me!