SSL renewals fixed

Certbot was struggling to auto-renew my domain SSL cert due to changes in OpenSSL 3 support for legacy protocols. Something is clearly wrong with my my openssl config but fearful of breaking the whole set up I only want to address the Certbot renewal failures.

ChatGPT gave some fixes, but the only one that actually worked was setting the CSH variable setenv CRYPTOGRAPHY_OPENSSL_NO_LEGACY 1 which stops certbot trying to use the legacy protocols that are no longer there allowed CERTBOT renew to skip thru the steps happily and now the server is ok until February by which time I truly hope to have retired the current server.

Busy with updates – FreeBSD 14.3

Finally found some time and upgraded both servers to 14.3 and trying to establish a stable baseline of installed apps like Apache, MySql, PHP, Perl, and Samba so I can easily port the remaining services over to the “new” server and retire the older one before it expires.

Setting up a new Wifi SSID for the older devices meant the Washing Machine, and cycle computer now connect easily and the Cameras appear to be more stable.

iOS 26 dropped last month but with no real massive technical changes, but now waiting for a new iPhone 17 to see Apple Intelligence live and in action as current iPad and iPhone are too old to benefit.

Its been quite a successful month with just the iKettle left to fix, but this seems to be an issue with the App or backend server as I can see its connected to the Wifi fine and can ping it fine, and I don’t seem to be the only one with issues with the smarter.io kettle range.

New Home

No posts of activity in July as busy moving house and the server was in boxes. I have now built my new Home Office and set the server up in the corner while I decide how best to kit out and layout the office.

Looks like FreeBSD have been busy and there are new updates to install and a new SSL cert to apply asap before the server is safe on the web, so that is what I am currently doing.

Perl updated to 5.40

so that means another forced updated of everything built with PERL. Not sure why /usr/ports/UPDATING keeps pointing us back to 2023 when they could just post the postmaster commands to update from the last default version to new default version… heyho.

portmaster -o lang/perl5.40 lang/perl5.36

portmaster -f `pkg shlib -qR libperl.so.5.36`

Domain Name Mismatch – Your site is insecure

I don’t know if Apple, and Google upped the ante, or I had not noticed before, or the SSL tools on the server had not kept updated, but I started getting warnings that my site was not secure. Letsencrypt has done a pretty good job for the last 5 years so I was confused as to why suddenly now , the browsers no longer liked up. Even harder now that MS Edge do not let you easily view the full cert.

A quick test at SSLlabs confirmed that the SSL for farcorfe.org.uk was all ok, but the sub-domain of www.farcorfe.org,uk was the actual issue. The SSL cert had not been validated for the www redirect.

Some quick Googling found this page – https://stackoverflow.com/questions/41097696/letsencrypt-certificate-for-www-and-non-www-domain with the required Certbot commands to add the www to the cert and a restart of Apache got the issue fixed.

Upgrade complete. 13 >> 14.2

I was very wary about the jump to 14 due to the change in Openssl from 1.1 to 3.0 and the pain that might entail. Also the deprecation of portsnap and getting used to Git was just something I did not have time for.

As I have created a new mirror site , see earlier post, I finally decided to bite the bullet over the festive break and did the freebsd-update upgrade option to 14.2, skipping out 14.0 and 14.1 in the process.

I was a little daunted and it failed to automatically upgrade everything to openssl 3.0 and although built the kernel and rebooted nicely, user land was still doggedly sticking to 1.1. I tried tinkering with make.conf in /etc with various default entries for openssl , but in the end removing the ssl version and just ssl=openssl and then making the usr/ports/openssl allowed 3.0 to install side by side with 1.1 thereby not breaking SSH or anything else until I was able to rebuild all of user land port by port. I was then able to complete freebsd-update install and now have another stable freebsd server for testing and training purposes.

Now I only need to fire this box up when I need Samba to move files around the network or download stuff off YouTube or run a Clamav as a 2nd pass for AV scanning and when I have time to dabble some more with FreeBSD.

New Home / New Start

After 7 years faithful service, its about time to retire the 2nd incarnation of my home based server. This one has gone thru about 7 different FreeBSD builds and despite various fun and games regarding loss of disk space, which turned out to be the large ZFS snapshots taken every time FreeBSD had a major upgrade its performed tirelessly.

 I will keep the M58 on as backup, but no longer needed to keep my feet warm running under my desk 24/7 and reduce my household electric bill a little.

Its also time to start house-hunting again after 3 happy years in the flat, but its time to move on, so also not needing to find a cubby hole in a new house with Cat6 , power and ventilation is also one less worry. Its probably means I won’t have as much to post about as keeping the server regularly patched and upgrade has been how I have self taught myself most of my Unix/Linux experience, but does mean I don’t need to worry if an upgrade fails and work late into the night to rebuild it any more.

A mirror site is now up at https://www.hollybob.co.uk/

Disk space solved – ZFS snapshots – DRAFT

Finally resolved the diminishing lack of free disk space for future FreeBSD updates. It seems that since version xx.x each upgrade as made a ZFS snapshot taking 1-3Gb each for each successive version. As the hardware has been running since 2017 that’s an awful lot of major and point revision snapshots.

DU and DF hid those successive snapshots and I was blaming my ever expanding OneDrive offline sync for taking excessive amounts of disk space even though I was convinced I had move the sync folder to the slave disk some time ago.

As I have never needed to roll back a ZFS snapshot I had never needed to explore what amount of space they took, or even how to display their usage, even less so how to delete them. Necessity being the mother of all invention, or least the need for a proper Google session I finally found the commands and confidence to delete 12 previous incarnations of FreeBSD and give me back the free disk I need to apply the next edition of FreeBSD.

Rebuilding server

updates are quite slow as found some new hardware to migrate the existing server onto, but work has been quite busy so finding the time to set aside an evening or two to migrate all the config over and rebuild is a challenge.

Python updated to 3.11

Might have found my Rust 1.78/1.79 is not building, as checking the dependencies, it wants Python 3.11, but my make.conf file holds python at 3.9. Not sure why Postmaster was not complaining at build time with a more helpful error message, but this seems a good place to start, so now off to rebuild Python.

20240529:

  AFFECTS: users of python

  AUTHOR: rm@FreeBSD.org

  The default version of python3 and python was switched to 3.11.

  For ports users wanting to keep version 3.9 as default,

  add DEFAULT_VERSIONS+= python=3.9 python3=3.9 to make.conf

  Following procedures may ease the upgrade:

  For users of pre-build packages:

  # sh

  # for i in $(pkg query -g %n ‘py39-*’); do pkg set -yn ${i}:py311-${i#py39-}; done

  # pkg upgrade

  For portmaster users:

  # sh

  # portmaster -o lang/python311 python39

  # REINSTALL=”$(pkg info -oq ‘*py39*’)”

  # pkg delete -f “*py39*”

  # portmaster $REINSTALL

  # REBUILD=$(pkg query -g “%n:%dn” ‘*’ | grep py3 | grep -v py311 | cut -d : -f 1 | sort -u)

  # portmaster $REBUILD

  # REBUILD2=$(pkg list | grep python-39 | xargs pkg which | awk ‘{print $6}’ | sort -u)

  # portmaster $REBUILD2

  Final steps (for pre-built packages & portmaster):

  If no longer required, Python 3.9 can be removed via

  “pkg remove python39” and the directory /usr/local/lib/python3.9 can

  then be deleted afterwards, if not empty.