Maintenance

While GoAccess provides a shed load of detail about a site's monthly performance it's frequently the case that we need more cumulative stats - how many hits did the site get least year? how about compared to the year before? how many hits so far this year?

So, I've been working on an 'executive overview' kind of representation of site data using XSLT and I've been having an interesting problem. Saxon errors out on some files with:
Failed to read input file file:/path/to/file.html (java.nio.charset.MalformedInputException): Input length = 1

Looking at a such a file using file --mime-encoding /path/to/file.html produces something like 'file.html: us-ascii'

I suspect that the output is more a function of the characters that the 'file' application finds in a file. It's unlikely that GoAccess is intentionally encoding the files this way (reports usually come up 'us-ascii', but sometimes it's 'utf-8', sometimes it's 'iso-8859-1', and sometimes it's the literally unidentifiable 'unknown-8bit').

Looking at the specific point in the file that causes grief it looks like it's generally the result of intentionally malformed requests. GoAccess blithely includes the funky chars and XSLT coughs up a hairball.

So it looks like XSLT is out and I'll need to find another way of processing these files.

I discovered that my code wasn't filtering htaccess (and similar) artifacts that end up on a live server so I've updated it to accommodate. I've also added a cron job to automatically run the script each month.
Note that documentation for the wrapper is available in the README included in the codebase.

I've written a wrapper for GoAccess to process the logs produced for the 30ish project sites that we're watching.
Today I deployed it to the server and ran a wrapup task that will bring all of our reports up to date.
Next month I'll see how it works when run from a cron job.

I edited my cdmirror script to accommodate building a PXE-boot bundle using a configurable target distro (it used to only build the current LTS, but now I can set it to build any distro) so I can now do tests on PXE builds of the soon-to-be-released 20.04.

It looks like the apt-mirror script project is dead. The repo directory structure has changed since 2018 and when I added 20.04 to the mirror it did not download a bunch of stuff.

So, I'm testing debmirror. Which also has problems, but is still being developed. The version of Debian I'm using on guava uses an old version of debmirror, so I grabbed the script off of the git repo and installed it locally.

Along with a wrapper script it seems to be much easier to use than apt-mirror was. Fingers crossed it works well when I start to run it as a cron job.

With the new mirror I've had an initial success with a 20.04 PXE build of one of our new lab NUCs.

It's really 1 command - 2 if you don't already have a key.
If you *don't* have a key already, create one with:
ssh-keygen -t rsa -f ~/.ssh/id_rsa -q -N ""
This (quietly -q) creates an RSA-2048 key in the usual place with NO passphrase on the key (-N "" provides an empty string for the new passphrase).

Once you have a key, you only need to run a command like this to push it to a remote machine:
cat ~/.ssh/id_rsa.pub | ssh ${REMOTE_USER}@${REMOTE_HOST}
where ${REMOTE_USER} is your login name and ${REMOTE_HOST} is a machine name or IP address of the remote machine (like myserver.uvic.ca).

I wrote a slightly more interactive script that does this for you. It's in the Utils repo as well, but I've attached a snapshot version to this post.

For the last couple of weeks I've been noticing some very weird behaviour in the two Jenkins build jobs where the svn repo has GitHub externals. The projects simply build all the time, whether or not there's been any change to any of the repos (svn or git).

We can't have that, of course; it's only happening to two repos right now, but it as more mini sub-projects get shared between repos, we'd end up with Jenkins simply queuing builds endlessly.

I'm still researching this, but I suspect it might have something to do with branch information; when (say) the DVPP repo is subscribed to the master branch of the staticSearch git repo, the master branch may not change, but the dev branch might; that means you end up with weird svn info like this (running svn info . in the external directory inside the Keats project):

URL: https://github.com/projectEndings/staticSearch.git/branches/master
Relative URL: ^/branches/master
Repository Root: https://github.com/projectEndings/staticSearch.git
Repository UUID: 04f9d699-67a6-817a-6227-ce57b7db7bff
Revision: 588
Node Kind: directory
Schedule: normal
Last Changed Author: martindholmes
Last Changed Rev: 570
Last Changed Date: 2020-01-13 11:41:56 -0800 (Mon, 13 Jan 2020)

You'll see that there are two revision numbers; the last-changed is 570, but the current revision is 588. Presumably that's because the master branch last changed in 570 but the dev branch changed more recently (as you'd expect). I have a suspicion that the svn polling mechanism in Jenkins interprets this to mean that there are new changes, and does a build. But it may be some other bug.

Anyway, I'm thinking that it might be a better alternative to pull static copies of the remote repo contents during the build process. The only disadvantage of this is that you can't live-edit the remote repo's code in the context of one of the projects using it, then commit from there back into the real repo. But that really just means that you have to have solid testing components in the original repo rather than relying on the consumer projects to do testing during active development.

The main front page and the Maintenance blog have been tweaked to be a little more useful. Most blogs have not been tweaked and look a bit rubbish. Here are the changes I made. I made it as terse as I could, but they're still kind of clunky.

------

1. Log in to blogs. Toolbar at top->Site->Site Dashboard
2. Select Blog (now called a Collection) from list
3. Look for a row of tabs with titles like 'Collection Dashboard', 'Contents', 'Comments' etc. Select 'Skin'
4. Look for a section titled 'Header Top Settings'. Uncheck 'Display Header Top'. This disables the weird listing of blogs at the top of the page.

5. You can also change some of the colours used for this Collection. The main page and the maintenance blog use the following colours:

   • General Settings section: 'Color Scheme'=#005493
   • Main Header Settings section: 'Site Title Color'=#ffffff; 'Menu Links Color'=#ffffff; 'Main Header BG Color'=#002754
6. There is a save button at the bottom of the page.

7. Next, go to the 'Widgets' tab. We'll be deleting some widgets - in some cases we'll empty sections completely.

   • 'Item Page' section: Seen by, Item Vote
   • 'Item Single' section: Item Location, About Author, Seen by
   • 'Menu' section: Pages, Link to: Collection owner contact form, Link to: Log in form
   • 'Page Top' section: All blogs
   • 'Register' section: Register, Content Block
   • 'Sidebar' section: Random photo, XML Feeds
   • 'Sidebar 2' section: remove everything
   • 'Login Required' section: Log in to your account
8. We'll be editing/adding some widgets too.

9. In the 'Menu' section we'll make the 'Home' link in the header point to the front page of the whole blog system instead of the Collection front page and create a log in link that does not cause confusion.

   • 'Edit' the Link to: Front Page widget and type 'Home' in the "Link text" field. Change "Collection ID" to 1. Save.
   • 'Edit' the Link to: Log in form widget by changing 'Link Type' from "Log in form (disp-login)" to "Go to any URL", type 'Log in' in the "Link text" field, and type 'https://hcmc.uvic.ca/blogs/index.php?disp=login' in the "URL" field. Save.
10. In the 'Sidebar 2' section we're adding a widget called "Public collctions list" - you'll find it at the bottom of the widgets list under 'Other'. Leave the settings alone.

Migrated first JSRDocs_dev then JSRDocs forward to the new AdaptiveDB codebase, and tested. All seems good. That's the last of the important database projects that I'm aware of that will need porting. Backup of the db taken today; backups stored both locally and in the folder of the live site.

So far I've updated both VPN dbs and all four active Landscapes dbs to the latest codebase, meaning that they will run on both PHP 5.6 and PHP 7. For VPN and the Powell St db, I've put the following stuff in .htaccess files to ensure that we're actually running on the new server and taking advantage of PHP 7, because the speed payoff is significant:

setEnv UVPHP_VERSION 70

RewriteEngine On
RewriteBase /
RewriteCond     %{HTTP_HOST} ^hcmc\.uvic\.ca$ [NC]
RewriteRule     (.*)  https://webserver2.hcmc.uvic.ca%{REQUEST_URI}

Once the new server takes over from the old, we'll have to remove the redirects. I have one more database to port, the jsrDocs one.