upgrade

This week I finally moved my gaming/Linux PC into my little office rack—it's that 2U box above the UPS at the bottom:

I remembered seeing Linus Tech Tips' 4U build in a video a couple years ago—but he has a full 42U rack in his basement. I don't have that much space—just 2U (technically 3U if I wanted) in my little under-desk studio rack.

So after working with them last year on a similar build (but with a prototype case), I got in touch with MyElectronics and they sent over their new production Mini ITX short-depth 2U PC case.

For the past year, I've slowly upgraded parts of my network to 10 Gigabit. But 10 Gigabit switches, NICs, and even cabling is a bit more expensive and sometimes annoying to deal with than the very-cheap 1 Gbps equipment most homelabbers are used to.

I dipped my toes into the 2.5 Gbps waters once I got a NAS with 2.5G ports—you can use standard USB NICs that cost less than $50, or PCIe cards for even less. And cabling is easier, since 2.5G works fine over Cat5e (which I already have run to most of my house).

So in order to install a new WiFi 6 Access Point upstairs—and get it's full bandwidth—I upgraded my main 1 Gbps PoE+ switch to a 2.5 Gbps PoE+ switch.

Looking around at options, most switches with more than 4 2.5 Gbps ports with PoE+ seem to cost upwards of $300. And knowing that I'd like to expand my network a bit in the future, I finally splurged a bit and bought this 20-port monstrosity:

I realized I've never posted this playbook to my blog... I needed to grab it for a project I'm working on, so I figured I'd post it here for future reference.

Basically, I need a playbook I can run whenever, that will ensure all packages are upgraded, then checks if a reboot is required, and if so, reboots the server. Afterwards, it removes any dependencies no longer required.

---
- hosts: all
  gather_facts: yes
  become: yes

  tasks:
    - name: Perform a dist-upgrade.
      ansible.builtin.apt:
        upgrade: dist
        update_cache: yes

    - name: Check if a reboot is required.
      ansible.builtin.stat:
        path: /var/run/reboot-required
        get_checksum: no
      register: reboot_required_file

    - name: Reboot the server (if required).
      ansible.builtin.reboot:
      when: reboot_required_file.stat.exists == true

    - name: Remove dependencies that are no longer required.
      ansible.builtin.apt:
        autoremove: yes

Update: The upgrade was a success! The site is now on Drupal 9.0.0, yay!

I'm planning on upgrading my www.pidramble.com website from Drupal 8 to Drupal 9 LIVE on my YouTube channel today, in honor of the #D9Launch today!

The site is currently running on a single Raspberry Pi on my desk in my basement... so this would not only be the world's first live Drupal 9 upgrade, it may possibly be the first-ever Drupal 9 site running on a Raspberry Pi!

Fingers crossed, I hope Drupal 9.0.0 will be ready to go by 5:00 p.m. US Eastern time (today, June 3rd)—if so, the stream will begin at that time, and I've embedded it below:

Recently, while working on the codebase for this very site, I tried running composer update to upgrade from Drupal 8.8.4 to 8.8.5. Apparently I did this at just the wrong time, as there was an issue with Drupal's dependencies in 8.9.x-dev which caused it to be selected as the upgrade candidate, and the default drupal/core-recommended Composer setting was to allow dev stability, so my site got updated to 8.9.x-dev, which was a bit of a surprise.

"No worries," I thought, "I use git, so I'm protected!" A git reset later, then change my composer.json to use "minimum-stability": "stable", and all is well with the world, right?

Well, no. You see, the problem is Drupal 8.9.x changed from an abandoned package, zendframework/zend-diactoros, to a new package, laminas/laminas-diactoros, that replaces the abandoned package.

In October, the Raspberry Pi Foundation released an updated bootloader/firmware for the Raspberry Pi 4 which dramatically reduces power consumption and overall temperatures on the Pi 4 by setting the USB controller and CPU into a more power-friendly mode.

I wanted to post here the instructions for checking the current version, and upgrading, because I have a large number of Pis to upgrade over time, and I needed a quick reference. For more details, check out the Raspberry Pi Documentation page Raspberry Pi 4 boot EEPROM.

Checking if the current bootloader is up to date

Upgrade system packages and install the rpi-eeprom utility:

Check if an update is required:

If you see a difference in the output, you can restart to update to the newer version. If everything's the same, you're already on the latest version.

Thoughts about Drupal 8, Drupal 7, Backdrop, the Drupal Community, DrupalCon's meteoric price increases, DrupalCamps, and the future of the framework/CMS/enterprise experience engine that is Drupal have been bubbling up in the back of my mind for, well, years now.

I am almost always an optimist about the future, and Drupal 8 promised (and usually delivered) on many things:

• Vastly improved content administration
• Views in core, and even better than ever
• Media in core
• Layouts in core
• Modern programming paradigms (fewer #DrupalWTFs)
• 'Getting off the island' and becoming more of a normal PHP application (kinda the opposite of something like Wordpress)

But one thing that has always been annoying, and now is probably to the state of alarming, for some, is the fact that Drupal 8 adoption has still not hit a level of growth which will put it ahead of Drupal 7 adoption any time soon.

tl;dr: See the video below for a run-through of my process upgrading Drupal core on the real-world open source Drupal 8 site codebase Drupal Example for Kubernetes.

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

Over the years, as Drupal has evolved, the upgrade process has become a bit more involved; as with most web applications, Drupal's increasing complexity extends to deployment, and whether you end up running Drupal on a VPS, a bare metal server, in Docker containers, or in a Kubernetes cluster, you should formalize an update process to make sure upgrades are as close to non-events as possible.

I wanted to document this process on my blog, since it's the second time I've had to do it, and it always takes me way longer to figure it out than it should... basically, here's how you can take a laptop with a hard disk that's running an older version of Fedora (in my case, Fedora 23), use the Fedora install media to re-partition the drive, then install a newer version of Fedora (in my case, Fedora 26):

For the past two minor release Drupal core upgrades, I've had major problems trying to get some of my Composer-based Drupal codebases upgraded. For both 8.3.x to 8.4.0, and now 8.4.x to 8.5.0, I've had the following issue:

1. I have the version constraint for drupal/core set to ~8.0 or ~8.4 in my composer.json.
2. I run composer update drupal/core --with-dependencies (as recommended in Drupal.org's Composer documentation).
3. Composer does its thing.
4. A few things get updated... but not drupal/core. It remains stubbornly on the previous minor release.

Looking around the web, it seems this is a very common problem, and a lot of people soon go for the nuclear (or thermonuclear¹) option: