A Blog that fit’s in the Pocket (2)

A Very Tiny Blog

 — (machine)

page 2 of 2:

There were a few gotchas that I uncovered during the setup phase.  Aren’t there always such things in any of these types of projects?  Anyway, WordPress is a thing that works together with its plugins and its database, and the versions of all the pieces and parts must be kept in synchronization.  Thus, plugin developers who stop developing their plugins eventually have a non-working plugin.  I used a version of WordPress that is already not the latest.  Yes – I know how bad that is, and I should be  ashamed.  But, it’s the only (easy) way to get the needed plugins synced with the larger codebase, without doing the coding.  Over time, the database schema changes.  Then it needs to be synchronized with the plugin.  So, it’s a matter of doing the work the plugin developer would have done (had he continued), or using versions of things that already work.  Using version combinations of things just because they already work together can be BAD.

Why is it a bad sort of thing to do? If you go to the wordpress.org archive site, you will (IIRC) find a disclaimer stating that archived versions could be vulnerable (excepting the latest, not archived version). The latest version is eventually itself retired, and then the same is said of it. And so on, and so on.  In other words, things are always being patched and fixed.  Therefore, someone like me – using the “not quite latest” versions of things, could be “vulnerable”.  Come on, mine isn’t THAT old.  Anyway, like I said, this is to be a private server. If it’s breached such that it’s “no longer private” – I’d consider it to be vulnerable.  In the meantime, I write on it.

Some of the gotchas?

When I first installed the blog, the dashboard worked, I could create new pages and posts, but I couldn’t upload any graphics files to the media library.  It turned out that a tweak was needed in both the Php and Hiawatha configuration files.  First, the Hiawatha changes:

  • MaxRequestSize = 1024
  • TimeForRequest = 60
  • MaxUploadSize = 1024

AFAIK, these size specifications have to be within the “binding config” for the 80 or 443 port binding configurations.  At least, that’s where I put them, inside of the hiawatha.conf file.  There’s a gotcha inside the gotcha on this one!  If more than one megabyte is specified, then the statement is ignored, and the default size is then in effect. The default size is 64 kilobytes, and I don’t have any graphics that small.

In the Php configuration, the upload_tmp_dir item had to be modified.  This may have been the result of my picking a relatively obscure OS, with different alignments for things …

  • Hiawatha

There are a few things that are (maybe) non-obvious to a person configuring the Hiawatha web server.  I really like this little piece of software, and it does a marvelous job with my WordPress installation(s).  I’m not saying I know all of the security angles involved with using it, but performance wise – it has been a pleasure to use.  It never seems to quit.

In the Hiawatha config file (/usr/local/etc/hiawatha/hiawatha.conf on my FreeBSD system) – the ServerId value needs to be the intended process owner of the Hiawatha process.  On my system the Hiawatha process is owned by user “www”. I don’t know if there are any security ramifications about the Hiawatha config, so this isn’t advice.  Works for my  “private” blog though …

As I mentioned on page one, I’m using virtual hosts on Hiawatha.   So, my config file has an entry like this:

  • VirtualHost {
  •         Hostname=www.steelschooner-ap.sea
  •         WebsiteRoot=/usr/local/var/www/hiawatha
  •         TimeForCGI=60
  •         UseFastCGI=PHP56
  •         ShowIndex=yes
  •         StartFile=index.php
  •         RandomHeader=64
  •         EnforceFirstHost=64
  •         PreventXSS=yes
  •         PreventSQLi=yes
  • }

The long CGI time was needed because the Pi can’t always do things fast.  LOL There’s another “Prevent” option that could be used in the config, but I can’t seem to remember what it’s named.  It seems prudent to tell the software to prevent all the nasties it can.  I don’t know how successful it is at doing that, but I’ve had no troubles thus far …

Notice the PHP56 reference.  This is the ID for the FastCGIserver definition block.  That block has to be defined in the configuration file also, since I’ve referenced it in a virtual host definition.  So, I have a block that looks like this:

  • FastCGIserver{
  •        FastCGIid=PHP56
  •         ConnectTo=/var/lib/hiawatha/php-fcgi.sock
  •         Extension=php
  •         SessionTimeout=600
  • }

The Id of the block can be referenced from any other block (such as the Virtual host block I have defined in my own configuration).  The”ConnectTo” line defines the unix socket to be used for communication back to the PHP interpreter.  These are not all of the possible definitions, but are what I use.  I’m not vouching for accuracy, lack of typos, or any kind of security matter.

The unix socket will need to be live before Hiawatha can connect with it.  So, the php-fpm configuration has to specify the exact same socket.  I have something like this in my php-fpm.conf:

  • listen=/var/lib/hiawatha/php-fcgi.sock

There are a ton of php-fpm configuration options.  I’m not going to begin to suggest how anyone should do theirs.  Mine seems to be working OK.

  • SQLite3:

OK, so SQLite3 has no security (AFAIK).  I mentioned that my WordPress is a private blog, and that I wasn’t worrying too much about security.  This fact is underscored by my use of a completely open database.  Verily you are forewarned.

WordPress can’t get along without some definitions in the wp_config.php (the configuration) file.  Because it usually has a user, password, and so forth, that needs to be passed to the database.  But, in the case of SQLite, there are no such things.  But, I needed to create phantom definitions anyway:

 

Read More …

Note: WordPress is under the guardianship of the WordPress Foundation, and WordPress.com is a service provider owned by Automattic, Inc.  Neither has any association with this author, even though this blog is hosted there!

Hiawatha webserver is a nice piece of software maintained by the people (actually I think it is one person) – at hiawatha-webserver.org – and they have no affiliation with this author or site. Likewise, SQLite and its author(s) have no relationship with this site.

Advertisements