If you've tried to develop a website and the files are on an external drive, you might find that httpd will refuse to serve the files. In your browser you'll see:

And in your Apache error log you'll read:

The trouble is, you've checked that the directory is readable and it is. Permissions are correct! You might even have messed with the "Ignore ownership on this volume" checkbox but it doesn't fix the problem.

For me, the issue was caused by macOS's builtin Security and Privacy controls. I'm using MacPorts to install my development stack. I have MacPorts set to use launchctl to start my httpd server in /Library/LaunchDaemons/org.macports.apache2.plist. This plist uses the daemondo wrapper to start httpd.

After giving daemondo (and thus its child process, httpd) Full Disk Access, everything was happy.

The home network can be a stressful place. When kids are learning from home, outages are agonizing.

For many years I ran the venerable Linksys WRT54GL on our network, but eventually it became too old and was replaced with a Netgear Nighthawk R7000P. This was OK at first but just like I had read in the reviews, it started acting up just after the warranty period expired, to the point where it was spontaneously rebooting about every 10 minutes. This was driving everyone mad. Firmware flashing, factory resets, power sources...nothing worked.

So I bought a Unifi AP AC PRO. I set it up yesterday and my heart sank when I got it running and saw drops and resets after about 12 minutes. Could it be that my Subaru H6 engine to electric generator project* was creating vast amounts of destabilizing radio waves? Then I updated the firmware on the access point to 4.0.80.10875 and it has been rock solid since then.

*Not a real project.

Install XCode via the App Store.

Install XCode command-line tools:

xcode-select --install


Change your shell from zsh to the ancient version of bash that Apple supplies:

chsh -s /bin/bash


Install MacPorts.

Open a new terminal window, which will now have MacPorts paths in $PATH.

Install latest bash with MacPorts:

sudo port install bash


Add the new bash as a valid shell:

sudo vi /etc/shells


Add /opt/local/bin/bash to the list of valid shells.

Change your shell to the new bash:

chsh -s /opt/local/bin/bash


Open a new terminal window and verify that in fact, you are running the latest bash:

$ bash --version
GNU bash, version 5.0.16(1)-release (x86_64-apple-darwin19.3.0)

Bash scripts with #!/bin/bash at the top will still run bash 3.2.57. Using env is one way to get around this; read Daniel's article below.

Note that nobody is saying zsh is not cool.

Reference: Upgrading Bash on macOS by Daniel Weibel.

After upgrading to Sensu 0.23.2-2 on RHEL 6.8 the Sensu server would not start. The logs looked like this:

{"timestamp":"","level":"debug","message":"connecting to redis","settings":{"host":"localhost","port":6379}}
{"timestamp":"","level":"debug","message":"connecting to transport","name":"rabbitmq","settings":{"ssl":{"private_key_file":"/etc/sensu/ssl/client_key.pem","cert_chain_file":"/etc/sensu/ssl/client_cert.pem"},"host":"localhost","port":5671,"user":"REDACTED","password":"REDACTED","vhost":"/sensu"}}
{"timestamp":"","level":"warn","message":"reconnecting to redis"}
{"timestamp":"","level":"warn","message":"unsubscribing from keepalive and result queues"}
{"timestamp":"","level":"debug","message":"not currently the leader"}
{"timestamp":"","level":"debug","message":"subscribing to keepalives"}
{"timestamp":"","level":"debug","message":"subscribing to results"}
{"timestamp":"","level":"debug","message":"{\"name\":\"client.example.com\",\"address\":\"10.1.2.3\",\"safe_mode\":false,\"subscriptions\":[\"os\"],\"version\":\"0.23.2\",\"timestamp\":1463588088}"}
{"timestamp":"","level":"debug","message":"updating client registry","client":{"name":"client.example.com","address":"10.1.2.3","safe_mode":false,"subscriptions":["os"],"version":"0.23.2","timestamp":1463588088}}


The cause of this is that localhost is resolving to ::1 and Redis is not listening with IPv6.

There are two solutions. One is to go through your /etc/sensu configuration files and change localhost to 127.0.0.1 so that you connect via IPv4.

The other solution is to change Redis configuration to bind to 127.0.0.1 and ::1.

Reference: https://github.com/sensu/sensu/issues/1209