I have a deep interest in using computers well beyond their expected shelf life. I am writing this in 2023 and have a 2012 iMac that has been in regular use up until I won this 2012 Mac Pro on eBay for the paltry sum of $147 USD. CPU performance gains were starting to plateau around the time these computers were made, and only fairly recently have newer designs such as Apple Silicon and AMD’s chiplet based CPUS begun to push the envelope again, particularly in consumer hardware. Yes, the new Apple Silicon chips and AMD’s Threadripper thrash the Intel Xeon’s in this Mac Pro, but it still holds its own against a multitude of newer CPUs and I think this is very cool.

To run a currently supported version of macOS on an older Mac you have to use OpenCore Legacy Patcher. This provides the environment to allow an unaltered installation of macOS, but first things first…

Do not even attempt to install a version newer than macOS High Sierra unless you have a Metal compatible graphics card.

I learned this the hard way. If you attempt to use OCLP to install a version of the macOS that requires a Metal capable GPU, and you do not have one, you will end up with a blank screen. You won’t even be able to get into the normal Mac boot picker screen, Internet Recovery, anything. You will be terrified that you broke your Mac and will be frantically searching internet forums while drinking yourself into a tupor.

Don’t do this.

I also recommend that if you have a currently booting install of a currently supported macOS on your stock system to preserve that drive. On the Mac Pro you can easily just pull that drive out to keep on hand in case things go wrong. Once you go down the path of OCLP you will not be able to boot from the stock card. You will not have a boot menu. Getting back to normal will be a pain in the ass.

After learning my lesson, I grabbed the cheapest lowest power GPU I could find locally, which was an AMD RX 550 4GB. I chose this because I read it was supported and I didn’t have to worry about power requirements. I do not have high demands for graphics, so I hoped this card would suit me for a while.

The RX 550 allowed me to get macOS Monterey installed and booting, however; hardware accelleration does not work. The model I have is a PowerColor Radeon RX 550 4GB.

Of course I found this bit of documentation after having bought the card, which says to avoid PowerColor branded cards.

Another lesson: OpenCore is a project for hackintoshes that also happens to have a patching tool for legacy Macs. Most things are documented, but I found that I had to look at the hackintosh stuff too for a fuller picture. Fools rush in and I am a fool.

The good news is, at this point I knew I hadn’t ruined anything, the Mac is booting. Now I just needed to settle the graphics issue once and for all…

Read the GPU Buyers Guide. Make your life easy.

And read it carefully. There are a number of gotchas such as brand and power consumption. Some cards have issues with macOS even if the chipset is supported (like the PowerColor cards), and some more powerful cards require more power than experts in the community think the Mac Pro motherboard can supply.

For funky cards, you can apparently flash a new vBIOS onto them, or spoof the device ID so that macOS thinks it is a different card. Or, you can just sell or return your non-macOS-friendly card and get a different one. I chose the latter option.

I am also not interested in modifying the power supply on my Mac Pro. If I needed modern high end graphics performance, maybe I would, or maybe I’d just buy or build a newer computer. This is, at the time of writing this, an 11 year old computer. Expectations should be managed.

Apple has an old support page mentioning specific card makes and models that work in the Mac Pro. I purchased a card from this list, the SAPPHIRE Radeon PULSE RX 580 8GB GDDR5.

This card requires an 8-pin power connector, so an adapter cable is required. I used this one from Amazon.

After installing a proper graphics card I was able to boot into macOS Monterey with full graphics acceleration! Now to upgrade everything else I can!

Here are the Out-Of-Box online help settings for IBM Maximo 7.6.1

UPDATE Nov 2024: I have since moved this site to DigitalOcean. Nothing wrong with Vercel, but DigitalOcean provides more general cloud services and also has the ability to monitor a git repository and automatically build a Hexo site.

This is a static website built using hexo.io. It is deployed on Vercel. I write entirely in VS Code in the Markdown language. Vercel monitors a git repository for changes, and when it detects changes it runs a hexo generate to build the new site. I basically manage zero infrastructure and have a simple static site. No big CMS solution, or tons of code that has to run in your browser. This is ideal for me, as someone who fondly remembers the internet made of personal sites made with very simple HTML markup.

The workflow with Hexo is quite simple:

1

hexo new draft "This very post"

This creates a Markdown file under /source/_drafts called This-very-post.md. Open this in your favored editor and write blog posts as comfortably as you would write code.

1

hexo publish This-very-post

When you are done writing your post it’s easy to publish it. This will at a timestamp to the posts’s front matter (the bit at the top) and move the file to /source/_posts.

1

hexo generate

The generate command will build the actual static website files. To preview your site just do

1

hexo server

…and your site will be at http://localhost:4000

It is not complicated to update posts after they have been published. Simply edit the Markdown in /source/_posts. You can even adjust the timestamps or anything else in the front matter. The hexo generate command will have no problems updating your blog.

If for some reason you want or need to build your site from a clean starting point, just run…

1

hexo clean

… all of your post data will still be there. Hexo will just purge its generated content so you can do a clean build.

Hexo supports plugins as well. I use hexo-generator-feed to publish the site’s RSS feed. Because hexo is a node.js application you can install plugins with npm.

Configuring various options for your site is simple too. Hexo reads your settings in _config.yml. The developers of hexo, plugins, and themes will provide guidance on what to put in your _config.yml to set them up.

I really enjoy blogging this way. I don’t have to login to some website or app and suffer some half-baked editor or deal with awful Markdown support and rendering. Best of all I have all my content saved automatically as source code. My content itself is not stored in any proprietary format, just Markdown.

For fun, to generate my site and send it up to git I have a little script called yeet.sh. Nothing fancy at all but it saves typing.

1
2
3
4

#!/bin/bash
echo "Yeeting the blog"
hexo generate && git add * && git commit -m "update" && git push
echo "The blog has been yote"

The internet is for information, not tons of JavaScript and trackers and ads or obstrusive UI. That’s why I like this. If you visit this site all you get is the content. There’s nothing else here, and the effort for me is minimal!

While developing for Maximo you will sometimes need to refresh your development environment from production so that you can have fresher data or work with, or to return your development environment to the production baseline if something has gone awry.

There are some configuration items I have updated in the past before starting the app back up and disabling Admin Mode.

If you have maxmessages that reference your environment name, you should update these.

1
2
3
4

UPDATE maximo.maxmessages
   SET value = 'DEV - ' || value
 WHERE msggroup = 'system'
   AND msgkey = 'example';

Disable External Systems so that you can control which start processing in your development environment. Maybe you have some that are only intended for production.

1
2

UPDATE maximo.maxextsystem
   SET enabled = 0;

Update URLs for your BIRT, Cognos, hostname, webapp, etc.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

-- BIRT
UPDATE maximo.maxpropvalue
  SET propvalue = 'https://mydevenv.com'
WHERE propname = 'mxe.report.birt.viewerurl'
;

-- COGNOS
UPDATE maximo.maxpropvalue
   SET propvalue = 'https://mydevenv.com'
 WHERE propname = 'mxe.report.cognos.serverURL'
   ;

-- webappurl
UPDATE maximo.maxpropvalue
   SET propvalue = 'https://mydevenv.com'
 WHERE propname = 'mxe.int.webappurl'
 ;

-- hostname
UPDATE maximo.maxpropvalue
   SET propvalue = 'https://mydevenv.com'
 WHERE propname = 'mxe.hostname'
 ;

 --help host

 UPDATE maximo.maxpropvalue
   SET propvalue = 'https://mydevenv.com'
 WHERE propname = 'mxe.help.host'
 ;

Update your DOCLINKS settings to point to the correct URL

1
2
3
4

UPDATE maximo.maxpropvalue
  SET propvalue = 'C:\mydoclinks=https://mydevenv.com'
WHERE propname = 'mxe.docklink.path01'
;

These are a just a few things you may want to update when doing a refresh. There may be other things specific to your environment you would want to do, such as setting the status or permissions of certain users and ensuring certain crontask instances are configured properly for the target environment.

I recently got a tip from IBM support about a friendler tool to use for creating WebSphere profiles. Previously I had used the graphical WebSphere Toolkit to create profiles on a new install but on the latest Windows Server 2019 images we were issued this tool would no longer work. It would crash with a Java error. IBM support discouraged use of this tool, instead they said to use the manageprofiles.bat command line tool. This tool is fine, however it is tedious to use because you have to enter in so many command line parameters.

IBM has a better tool called Manage Profiles Interactive. This tool provides a nice menu in the command prompt and steps you through the required and optional parameters to get your profiles created. I found this to be very easy to use and to document for the next person who has to do a server install from scratch in our environment.

Manage Profiles Interactive

I definitely recommend this tool!

If you need to create a custom cron task for IBM Maximo using Java here is some code to get you started.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

import psdi.server.SimpleCronTask;
import psdi.server.CrontaskParamInfo;
import psdi.util.MXException;
import java.rmi.RemoteException

public class MyCustomCron extends SimpleCronTask {

    // You must extend SimpleCronTask and must override
    // cronAction()

    // Your main processing goes in cronAction()

    @Override
    public void cronAction(){
        // Do stuff here

        // How to access a parameter if you are using them
        String param = super.getParamAsString("Param 1);
    }

    // If you want to use parameters you override getParameters()

    @Override
    public CronTaskParamInfo[] getParameters() throws MXException, RemoteException {
        CrontakParamInfo parameters[] = new CronTaskParamInfo[2];
        parameters[0] = new CrontaskParamInfo();
        parameters[0].setName("Param 1");
        parameters[0].setDefault("Default Value");
        parameters[1].setName("Param 2");
        parameters[1].setDefault("Default Value");

        return parameters;
    }

}

Today I came across a qemu provider for Vagrant. I have a PC set up with Proxmox, however; I kind of don’t want to have this machine hooked up and running all of the time. It is very underutilized. I only use it when I have the time or interest to experiment.

Setup is easy:

1
2

brew install qemu
vagrant plugin install vagrant-qemu

And then we can try using a provided example:

1
2

vagrant init ppggff/centos-7-aarch64-2009-4K
vagrant up --provider qemu

Vagrant will start setting things up and you will be prompted for a username and password for SMB.

At this point you will probably get an error if you are on macOS complaining about an authentication failure for SMB. All you need to do is set up SMB File Sharing for macOS if you haven’t done so already. HashiCorp has a note on it here.

Once the qemu VM has been started up by Vagrant you can connect to it with vagrant ssh

Your home directory on your host will be mapped to /vagrant in the VM.

This solution seems the best for me right now on the M1 Mac. Qemu is very powerful and should even allow me to run operating systems for architectures other than ARM using Vagrant.

Today I learned that for self-signed certs you need to add the root CA of your server to Vagrant’s cacert.pem

On my system this file is at /opt/vagrant/embedded/cacert.pem

The certificate for Proxmox’s self-signer root is at /etc/pve/pve-root-ca.pem

Just copy the contents of pve-root-ca.pem and paste it at the bottom of cacert.pem. This should resolve issues with Vagrant and self-signed certs.

References:

https://forum.proxmox.com/threads/vagrant-proxmox-issue.36204/

Ahh yes, the everything-as-code infrastructure dream. I have been familiar with the concepts for a long time, and know the names and functions of many tools. I can create infrastructure on AWS or Azure, I can grab magic ephemeral servers from Docker, etc. I have not had any opportunity to use any of this in a professional environment. The places where I have worked are very slow to adopt new methodologies and technologies. This has posed a bit of an issue for me, because I typically learn things on the job. I like the immediate and direct application of skill to keep the world from burning down.

So, I am playing with things from a book. DevOps for The Desperate by Bradley Smith, published by the fantastic No Starch Press. The book takes you through examples with Vagrant, Ansible, Docker, and Kubernetes. It’ s a bit of a crash course.

I ran into some challenges almost immediately. The examples are written primarily from the perspective of controlling VirtualBox with Vagrant. I am using an M1 based MacBook Air, which VirtualBox does not support. The book provides examples on how to use different providers with Vagrant, cool, I’m not totally dead in the water.

1

vagrant plugin install vagrant-parallels 

This command installs the plugin which adds Parallels as a provider for Vagrant. The catch is that only Parallels Pro supports being remotely controlled. I do not currently have Parallels Pro, but I do have a Proxmox server.

1

vagrant plugin install vagrant-proxmox

This is the point I learned of Ruby dependency hell.

The original GitHub repo for vagrant-proxmox (which contains the version which is on RubyGems) appears to be abandoned. It has out-of-date dependencies which Ruby’s package manager was unable to resolve. Fortunately someone else forked this repo and have kept the dependencies more up-to-date. So all I had to do was build the gem and install.

Right…

Right?

Well, no.

First I learned the version of Ruby that Apple ships with macOS is an outdated version packaged in a Universal Binary. This post explains everything. I was getting errors from the FFI library as described. I decided to deal with this by installing the latest version of Ruby from Brew

1

brew install ruby

And then update my PATH as described in the warnings from Brew so that my terminal grabs the right Ruby

1

echo 'export PATH="/opt/homebrew/opt/ruby/bin:$PATH"' >> ~/.zshrc

So now I have the latest arm64 Ruby and it’s time to build that gem from the rakefile…

1

rake build

Which tells me…

1
2
3

“Could not find rake-10.5.0 in any of the sources

Run `bundle install` to install missing gems.”

Okay, great.

1

bundle install

Which tells me…

1

“minitest-5.14.0 requires ruby version ~> 2.2, which is incompatible with the current version, ruby 3.1.2p20”

I found a suggestion to delete Gemfile.lock, so I did and ran bundle install again.

1
2
3
4
5
6
7
8
9

“Bundler found conflicting requirements for the Ruby version:

  In Gemfile:

    Ruby

    vagrant (= 2.2.4) was resolved to 2.2.4, which depends on

      Ruby (~> 2.2, < 2.7)”

Okay, my installed version of Vagrant is 2.3.1 so maybe I just need to update the gemfile and the vagrant-proxmox.gemspec.

Success! Now to try rake build again

1
2
3

“rake aborted!

Gem::LoadError: You have already activated rake 13.0.6, but your Gemfile requires rake 10.5.0. Prepending `bundle exec` to your command may solve this.”

I updated the rake dependency in vagrant-proxmox.gemspec and it worked! I now have a gemfile!

Lets install it!

1

vagrant plugin install ./vagrant-proxmox-0.3.0.gem

Oh no I am going to implode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

“Vagrant failed to properly resolve required dependencies. These

errors can commonly be caused by misconfigured plugin installations

or transient network issues. The reported error is:

conflicting dependencies activesupport (~> 5.0) and activesupport (= 7.0.4)

  Activated activesupport-7.0.4

  which does not match conflicting dependency (~> 5.0)

  Conflicting dependency chains:

    activesupport (= 7.0.4), 7.0.4 activated

  versus:

    vagrant-proxmox (= 0.3.0), 0.3.0 activated, depends on

    activesupport (~> 5.0)

  Gems matching activesupport (~> 5.0):

    activesupport-5.2.8.1”

Yet again I updated the dependency in vagrant-proxmox.gemspec, then run bundle update, then rake build. And success!! I got the plugin to install!!

So this is my first crash course into dealing with Vagrant. From here I should be able to whip up a vagrant file to control my Proxmox server instead of VirtualBox or Parallels. I will write about this later.

My fork of vagrant-proxmox lives here: https://github.com/mikeOSX/vagrant-proxmox

References:

https://stackoverflow.com/questions/17028132/vagrant-install-plugin-from-github

https://www.ruby-lang.org/en/documentation/installation/#homebrew

https://github.com/lehn-etracker/vagrant-proxmox

https://betterprogramming.pub/ruby-on-apple-silicon-m1-macs-fb159849b2f5