Author: kevin

Posted on

Mac OS X and MacOS versions

As someone who tinkers with older Macs, I often forget which versions of Mac OS X are earlier or later just based on name, so for future reference here’s a quick list (summarized from wikipedia):

10.0Cheetah
10.1Puma
10.2Jaguar
10.3Panther
10.4Tiger
10.5Leopard
10.6Snow Leopard
10.7Lion
10.8Mountain Lion
10.9Mavericks
10.10Yosemite
10.11El Capitan – most recent version that can be installed on my 2008 Mac Pro 3,1 without using DosDude’s Patcher or OpenCore Legacy Patcher etc
10.12Sierra
10.13High Sierra
10.14Mojave
10.15Catalina
11Big Sur
12Monterey
13Ventura – new System Settings replaced System Preferences
14Sonoma
15Sequoia
Posted on

GitLab CI – allowing later stages to run if manual job in previous stage is not run

By default, later stages will not run if a previous stage in your GitLab pipeline fails. If you have a manual job in a previous stage, not running that job will also block later stages from running automatically.

To allow a later stage to run, mark any optional/manual jobs with ‘allow_failure: true’

For example:

stages:
- build
- setup
- deploy

build:
  stage: build
  script:
    - doTaskA

optional-setup:
  stage: setup
  script:
    - doOptionalSetup
  allow_failure: true
  when: manual

deploy:
  stage: deploy
  script:
    - doTaskC
  when: manual

Posted on

Configuring nginx virtual hosts with sites-available / sites-enabled

I recently ran into an issue with how /etc/nginx/sites-enabled is used (or not) depending what nginx version you’re running on, or more likely according to this post, whether you’re running nginx on Debian/Ubuntu or the official nginx package.

The difference (which is pretty significant if you’re not expecting it), is that:

  • Debian/Ubuntu versions for nginx have sites-enabled included in nginx.conf by default
  • The official upstream nginx package does not

What this means is on Debian/Ubuntu, in /etc/nginx/nginx.conf you’ll have this include:

include /etc/nginx/sites-enabled/*;

but it’s missing if you run the upstream nginx package, like what seems to be included in the Docker image nginx:latest.

In my case running the Docker image nginx:latest every GET request was getting a 404 and the only clue was in my error.log each request was attempting to serve files from a default /usr/share/nginx/html folder, which is definitely not what was configured as my root in the config in /etc/nginx/sites-enabled:

open() "/usr/share/nginx/html/[url-request-here] HTTP/1.1" failed (2: No such file or directory)

Once I worked out what the issue was I just added the include line for sites-enabled.

Posted on

botsin.space Mastodon bot migration update to https://mastodon.kevinhooke.com/

Quick update on my progress so far on migrating my personal Mastodon bot projects from botsin.space:

So far I have updated and moved:

  • kevinhookebot – over the years this evolved into multiple AWS Lambdas that implemented different parts of functionality. The RNN model text generation Lambda is updated and redeployed and now posting updates every 3 hours at https://mastodon.kevinhooke.com/@kevinhookebot
  • The Lambda that listens to mentions ‘@’ the bot is updated and redeployed. to AWS, it checks for mentions every 5 minutes and replies with a random response, or the adventure game replies if you ‘@’ the bot with ‘go north’ or similar command

The other bots that developed over the years (that never got moved to Mastondon with the others) are either still active on X (assuming that Twitter API and credentials are still working) or no longer working, but are on my todo list to update and move soon:

The Zork adventure game bot that was running on botsin.space also needs to be migrated to https://mastodon.kevinhooke.com/home

Proudly powered by WordPress