Mac – Watne Household Site

Restoring Cron Job Functionality in MacOS

August 4, 2021john

I have used cron jobs to do database backups and other maintenance on servers I have run at home, previously on versions of Ubuntu and Linux Mint, and currently on MacOS. Some change that happened to MacOS between the “Mojave” and “Big Sur” versions broke cron jobs that had worked for years. A cron job that would create a database restore query was suddenly creating an empty file on its daily scheduled run. The job that was supposed to update my SSL certificate when it was due for renewal never succeeded in updating it.
As I searched for a solution to this problem, I came across multiple recommendations for two different items, and the combination of the two of them has resulted in my cron jobs working again.

Make sure the full path is specified for all programs and script files executed, both within the cron job itself, and within the script files that it calls. This is probably the true solution, of the two items.
Make sure that cron has “Full Disk Access”. For Big Sur, this is found in
- System Preferences
- Security & Privacy
- [Click the lock to make changes – unless already unlocked]
- Check “cron”.
  - If “cron” is not shown as an option, hit the “+” key under the list and add /usr/sbin/cron [Enter “which cron” in a terminal session to confirm the path].

While Apple recommends switching to using launchcd with .plist files – which would also require specifying full paths for called scripts, from what I could see by trying that switch – I am more comfortable with cron, which seems more flexible, and a lot less verbose. Also, the cron concepts are much easier to translate to Linux, Unix distributions, and even using cron scheduling for Spring applications.

If any other Mac users fall into my category of knowing just enough to be dangerous with running scheduled jobs on them, and they come across the same issue with preexisting cron jobs breaking with version upgrades, I hope these quick tips come in helpful.

Fixing ERR_CONNECTION_REFUSED errors attempting to connect to this site after changes

April 25, 2019john

After upgrading(?) my Mac to MacOS Mojave, I found the hard disk access speed intolerable. Boot ups would take several minutes, and everything took far too long. I finally switched my Mac to boot up off of an external USB Solid State Drive (SSD). After cloning my hard drive to the SSD and switching it to be the default boot drive, the old(ish) Mac is once again pleasantly fast and usable.

However, after this change, I found that, whenever I attempted to connect to this site, any browser I tried to connect to it through would give a message about being unable to connect to the server. One specific message shown in Google Chrome was

ERR_CONNECTION_REFUSED

The first part of the solution came from a Stack Overflow answer by adang. In a terminal, I ran

sudo vi /etc/apache2/httpd.conf

I then uncommented the following lines by removing the pound (“#”) at the start of the line containing them:

LoadModule authz_core_module libexec/apache2/mod_authz_core.so

LoadModule authz_host_module libexec/apache2/mod_authz_host.so

LoadModule userdir_module libexec/apache2/mod_userdir.so

LoadModule include_module libexec/apache2/mod_include.so

LoadModule rewrite_module libexec/apache2/mod_rewrite.so

LoadModule php7_module libexec/apache2/libphp7.so

Continuing with the instructions in the solution, I ran the following two commands:

sudo apachectl restart

apachectl configtest

The configtest revealed that apache was unable to find the specified SSL certificate file. As I compared the finder contents for the new SSD and the original hard drive, at first I thought that the certificate file had not copied over. So, I attempted to copy it from the hard drive to the SSD. However, as I tried to navigate through the folders on both drives, I found that the problem wasn’t that the file had not been copied during the cloning process, it was that I was unable to even see the contents of the folder containing the certificate files due to permissions. I needed to add read and execute rights to the folder as follows:

sudo chmod 755 /etc/letsencrypt/archive/

Once I did this, I was able to

sudo ls /etc/letsencrypt/archive/[domain-name]

and confirm that all files required were, in fact, there. Repeating the two apachectl commands this time resulted in the results being OK.

After doing this, I found that I needed to renew my letsencrypt SSL certificate.

certbot --version

showed that I was running an outdated version of certbot. I ran the following commands to update certbot, renew the certificate, and confirm that it had been updated.

brew update

brew upgrade certbot

sudo certbot certonly -w /path/to/website/ -d [domain-name] --preferred-challenges http

(I chose option 1, apache plug-in, when asked.)

sudo certbot renew --dry-run

After all this, the site is as good as new. I hope my directing people to the original solution for the main problem, and my steps for updating the SSL certificate, may be helpful to others.

Visiting CareLink Site on OS X Mavericks

November 7, 2014john

Here is a tip for people who fall into the same small category as myself. If you

use a Medtronic insulin pump,
use the CareLink site to store your pump history,
use a Mac, and
are running OS X Mavericks for a time – short, I hope – after I write this post,

you will run into the problem that I ran into when I first attempted to upload my pump data after upgrading to Mavericks. You will get an error page stating,

Unfortunately, the configuration of your PC or web browser is not compatible with our standard system requirements.

This is because the only OS X versions supported are “MacOSX 10.5 (Intel), MacOSX 10.6/10.7/10.8”. Unfortunately, Mavericks is version 10.9. Unlike the logic for the browser, which recognized that my Firefox 24.0 met the Firefox 5 requirement, the OS check does not appear to allow for future versions.

The workaround that I am using, for now, is to use the Firefox User Agent Switcher plugin. After installing the plugin and restarting Firefox, create a new “Firefox on Mountain Lion” user agent as follows:

Select Tools / Default User Agent / Edit User Agents…

In the “User Agents” section, choose New / New User Agent…

In the window that appears, you will see “… Intel Mac OS X 10.9;…” in the “User Agent” field.

Change the version from 10.9 to 10.8, and give a helpful description like “Firefox on Mountain Lion” in the “Description” field. Then, before visiting the CareLink site, select Tools / Default User Agent / Firefox on Mountain Lion [or whatever name you gave the user agent]. You will now be able to use the CareLink site!