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.

VHD, HyperV and goodbye to heavy iron

The time had finally come to retire my Win10 workhorse. A Dell 4 core Tower PC that had originally come installed with MS Vista, then upgraded thru Win 7 and then finally Win10. Sporting 2 Optical drives, when back in the day , cloning CD’s where the rage, and then upgraded with a DVD Writer for backups was still possible to a single disc before our iCloud and OneDrives exploded with photographs or huge downloadable only games.

The graphics card had been updated several times to keep pace with games, but became less regular as I had less time for gaming and the memory maxed out at 4Gb, the max allowable for the motherboard.

I had tried several times to P2V the OS so I could dispense with the Tower, the full metal construction meant it was deadweight to move around to connect up to the TV, Ethernet and mice/keyboard ever time I needed to access some older programs to achieve a task. In my desire to be modern, I had used Disk2VHD several times to create a VHDX file, only for HyperV on my new Win11 workhorse to cry foul and refused to run.

A quick rummage of some old PC Pro back issues on the P2V process and sticking with the older plain VHD format brought forth a bootable image and then I was finally able to strip the heavy iron beast of its SSDs, Memory, Graphic Card, Multimedia Card adapter and Optical drives for potential reuse (More likely to sit in a box for another 10 years before I accept I won’t ever use them again)

I now have a usable Win10 image of the older apps and utilities I still occasionally need and one less physical device sitting around.

Just to add to the melee of updates, while the P2V process was happening I decided to resurrect an old Netgear Managed switch to permanently cable up some of the PCs kicking around, so I did not have to keep moving my trailing ethernet cable around. Seemed a good idea at the time, but they had been previously used and fixed on a different subnet and needed a laptop on the same IP range as them to re-configure. My DHCP server hands outs 192.168.1.x ids, they had been configured for 192.168.0.x. so I needed to set a manual configuration so the laptop could see both the Switch and the Gateway so it could manage updating the switch.

The Win10 IP manual configuration process was a royal PITA as instead of a usual subnet mask it just wanted the subnet mask value. eg. 16 oppose to 255.255.254.0 but was not very clear, just kept throwing errors messages to check the IP addresses submitted. Once the current subnet value had been submitted it all worked hunky-dory and I was also able to update the device Ip, name and firmware so its is now recognised on the home lan properly.

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.

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.

Rust 1.78 will not build

Free disk space continues to be an issue, I’ve deleted 50Gb of backups but df -h has yet to recognise the new free space. This would not be an issue apart from Rust and Cargo-c appear to want to use up all available free disk space.

I also noted a discrepancy between the Pkg Info command to re-port out of date packages/ports and those that postmaster -da then tried to build as being out of date.

If I manage to resolve these issues I will update this post.

Disk space usage troubles

Whilst trying to update some common ports I keep running out of disk space, causing the Database to halt and then the website to fail. Struggling to find out which package is consuming excessive disk space and fear I need to drop down to single user mode to run fsck (but meaning I need to find a VGA cable and suitable monitor to hook up to ) so seeing which packages consume the most and may be able to go, so run.

pkg info -sa | sort -hk2

FreeBSD – Updating Ruby

The default version of Ruby has been bumped to 3.2, which is fine, but /UPDATING no longer includes the steps needed to bump your installed version.

No problem, just scroll down to see what the instructions were for the last revision bump. And then you hit a problem. All the Ruby port bumps refer you to the 2019 entry, which is fab , stepping thru instructions of how to move from 2.4 to 2.5. , however, UPDATING no longer goes all the way back to 2019. It’s been trimmed. A bit of googling and a found the unedited version of UPGRADING which helpfully had the instructions, which for ease I have pasted below and for even easier usage, have amended the instructions for moving between 3.1 and 3.2

20190420:
  AFFECTS: users of lang/ruby24
  AUTHOR: mfechner@FreeBSD.org

The default ruby version has been updated from 2.4 to 2.5.

If you compile your own ports you may keep 2.4 as the default version by adding the following lines to your /etc/make.conf file:

#
  # Keep ruby 2.4 as default version
  #
  DEFAULT_VERSIONS+=ruby=2.4

If you wish to update to the new default version, you need to first stop any software that uses ruby. Then, you will need to follow these steps, depending upon how you manage your system.

If you use pkgng, simply upgrade:
  # pkg upgrade

If you use portmaster, install new ruby, then rebuild all ports that depend on ruby:
  # portmaster -o lang/ruby25 lang/ruby24
  # portmaster -R -r ruby-2.5

If you use portupgrade, install new ruby, then rebuild all ports that depend on ruby:

# pkg delete -f ruby portupgrade
  # make -C /usr/ports/ports-mgmt/portupgrade install clean
  # pkg set -o lang/ruby24:lang/ruby25
  # portupgrade -x ruby-2.5.\* -fr lang/ruby25

and upgraded version is

20240306:
  AFFECTS: users of lang/ruby31
  AUTHOR: me!

The default ruby version has been updated from 3.1 to 3.2.

If you compile your own ports you may keep 3.1 as the default version by  adding the following lines to your /etc/make.conf file:


  DEFAULT_VERSIONS+=ruby=3.1

If you wish to update to the new default version, you need to first stop any software that uses ruby. Then, you will need to follow these steps, depending upon how you manage your system.

If you use pkgng, simply upgrade:
  # pkg upgrade

If you use portmaster, install new ruby, then rebuild all ports that depend on ruby:
  # portmaster -o lang/ruby32 lang/ruby31
  # portmaster -R -r ruby-3.2

If you use portupgrade, install new ruby, then rebuild all ports that depend on ruby:

# pkg delete -f ruby portupgrade
  # make -C /usr/ports/ports-mgmt/portupgrade install clean
  # pkg set -o lang/ruby31:lang/ruby32
  # portupgrade -x ruby-3.2.\* -fr lang/ruby32