where did October go? Installing Apple updates across phone, iPad, Watch, TV and laptop probably accounts for half of it!
Apple and FreeBSD update
The update to PERL also managed to break SSL, with no clear culprit of what had failed. rebuilding all the of PERL dependencies did little to fix it. and oddly Apache still tried to serve up the webpages but in plain text on the internal network.
Going thru the Freebsd-update fetch and install route and rebuilding OpenSSL once the patch update had been applied allow Apache to once again happily serve up the site pages.
iOS 17 is not far away from being launched but I have been running the Beta’s on phone, iPad, Watch and AppleTV quite happily for a month now. After upgrading the AppleTV the big screen FaceTime is a bonus but watching the Apple Launch event now sure I need the finger double tap for the watch or the USB-C connections for iPhone so will wait to see how the prices pan out or if a battery replacement on each will buy another year of service and see what next September brings.
GoAccess parsing issues resolved
Since Webalizer fell into disrepair some years ago, I dabbled with GoAccess for website stats and sort of got it working. Several OS or Apache updates later it decided to stop working and I never found the time to fix.
Well, todays persistent rain and nothing better to do, I resolved to fix why GoAccess refused to parse my Apache logs.
The initial fault seemed to stem from GoAccess not being able to decide if I had CLF ( Common Log Format) or Combined Log Format. Apache was insistent that I had set Combined Log Format looking at httpd.conf, but GoAccess complained on start-up that this was not the case.
As this is a hobby server and I had not needed to rotate the logs for several years I can only guess the httpd-access.log had been corrupted or mixed with CLF at some point, so a forced log rotation stopped the error messages on startup and allowed the basic details of the log to be parsed.
However the referrer and user agent still was not parsed. It seems there is a error in the sample goaccess.conf file and the %R and %u fields need double quotes to be parsed fully. A post way back from 2014 seemed to flag this but the MAN page still does not pick this up, maybe its a FreeBSD specific issues
Anyhoo, fixing this is the Combined Log file format parse string now has the file being parsed happily. The OS and Browser detections still seem a bit pants, Safari and Apple iOS and MacOS seemed to be lumped under Linux, but job for another day.
The analytics can be found here
Solved – MYSQL refusing to start
I had upgraded my version of Mysql Server via the ports a few weeks back and usually ports is very good at addressing any compatibility issues bumping up the versions. A quick read of UPDATING had not flagged any real concerns, but on the reboot Mysql was steadfastly refusing to start. No obvious error messages where thrown and it just silently refused to budge.
Googling presented several solutions, but none palpable (wipe config and dbs and start again). However one suggestion was to check the {hostname}.err file contained within /var/db/mysql and lo and behold a quick TAIL {hostname}.err displayed the error that I have been missing. Namely that query_cache_type=0 and query_cache_size=0 had been deprecated starting with v8 and needed to be deleted from my.cnf file.
Fixing the my.cnf file and a quick service mysql-server start restored my Databases and we are back up and running.
Updating Ruby via Ports
Oh I do hate /usr/ports/UPDATING when they refer you to an entry 3 years prior on how to update the current version of a major revision bump and then you need to dig out and correct the numbers to make it work. So I am just going to down my editing here so I can find more easily.
If you use portmaster, install new ruby, then rebuild all ports that depend on ruby:
cd /usr/ports/lang/ruby31 and Make install
# portmaster -o lang/ruby31 lang/ruby30
# portmaster -R -r ruby-3.1
Useful CSS Checker
Whilst trying to fix the style sheet for another website I came across this CSS analyser that has many useful features. https://www.projectwallace.com
Heat vs Bills
As its gone incredibly chilly in the UK at present, its a question of leaving the server on to help heat up the room vs pay the increasing energy bill.
Hardening the Server
For many months, the nightly security emails have been warning that db5 and gcc9 were out of date and no longer supported. Numerous attempts to remove just threw up package dependencies, so today I set out to tackle them.
gcc9 proved to be the easiest and whatever previous package had been holding it back had clearly gone and a simple sudo pkg delete gcc9 did not throw up any other package dependencies and soon went.
Not so for db5.
Webalizer, apr and apache24 still insisted on db5. All relatively mainstream packages but all still using db5. Several Googles showed others have had similar problems ever since it was first mentioned as deprecated but the amount of error messages had decreased since July,
Adding dbd=18 to make.conf as the default db version seems to have resolved the problem after a Make Deinstall Clean on apr1, apache24 and the webalizer ports. All 3 then re-built nicely and did not call in db5 which previous attempts to remove and rebuild have done.
Hopefully now after fixing PHP 8.1 and now db5 plus gcc9 the server will live on for another year as a test-bed and platform for my ramblings.
Energy Bills
With the current cost of living crisis in the UK, driven by the increase in energy costs I am limiting the amount of hours I leave the server up and online these days. Certainly over the summer when I had little time to dabble with the various services that I run, its make good economic sense to shut the server down if I am not going to be working on its for a few days.
Therefore expect to see erratic uptime for this website/server, unless I take the plunge and migrate all the content to one of the cloud accounts I am already paying for. The downside will be the loss of local services and a properly offline OneDrive copy that I use for backup purposes.
PHP 8.x upgraded
With the pending retirement of PHP 7.3 the last thing on last months list of things to do was to update PHP to a supported version.
re-building from ports is not easy, but is straight forward. First generate a list of all your installed php packages and save safely where you can access it. Then use pkg delete -f to remove each package on your list. Not forgetting mod_php73 and then find the version of php you want to replace with in /usr/ports/lang and then install php80 and php80_extensions.
I had planned to jump straight to PHP 8.1, but the php81-dom extension is no longer available to install. Ditto php81-hash and php81-json. Thankfully I didn’t need -hash nor json and rolling back to PHP8.0 sufficed.
60 minutes later after manually deinstalling and then installing I had a working system. Well, almost, in my haste to reboot the server, I had forgotten to install mod_php80 so on the reboot Apache failed to start as it did not recognise some of the php injects in the httpd.conf. Rem’ing the errant comments out did not work either as when Apache now started, it could not interpret the .php files and dumped them straight to the screen. Then the penny dropped and a quick install of mod_php80 and reboot finally made Apache happy and everything working again.
Why reboot and not just stop/start Apache et al. Well its a small test rig and not running any production grade services so a complete clear out of the memory from any residual horlicks I have made in past configs or port building means I give it the best hope of running smoothly until the next big upgrade.