The need to stay humble

Life requires taking risks, is full of unexpected turns, uncertainty of situations and black swans, as @nntaleb would point out.

Working as a warehouse & driver’s helper for a luggage company has been a learning & rewarding experience. The opportunity to interact with shop owners who share valuable insight to small business survival is priceless.

Small shops catering to local folks and tourists are scattered all over New York City from Canal St. in the heart of China Town, to College Point and along Jamaica Ave. in Queens.

Deliveries take you to through narrow city streets and the Midtown/Lincoln/Holland tunnels going in/out of Manhattan, seeing endless crowds of people and going over the scenic George Washington, Tappan Zee, Verrazano-Narrows & Throgs Neck bridges.

Despite getting berated a few times by moody customers, product fall-outs from the hand truck and my personal backpack stolen by a thug in Brooklyn – these random experiences has taught me the need to stay humble, calm and collected.

All photographs on this post were taken with an iPhone 4S by @danskoya

first impressions: @vultr Bare Metal Server w/ pre-installed FreeBSD 12.0

I signed-up to be on the waiting list last week, but quickly noticed today there was a spot available. They had a promo with 2 x 240GB SSDs so I took the bait and tried out their Bare Metal Server running a pre-installed FreeBSD 12.0-RELEASE amd64 (my choice).

Deployed and in less than 3 minutes, I had access to the box via SSH. I made observations and noted minor issues I had with the default setup.

  • /etc/fstab pointed to /dev/ufs/rootfs
  • drive cyclinder errors on the console window
  • unable to boot your own FreeBSD ISO image to start from scratch

After searching online for hints, I found this thread addressing the exact issues I had with bsdinstall – after running it once more and using /dev/ada1 as the target disk, I’m taken back to a shell prompt instead of the normal reboot after a fresh install.

Proceeded to update /etc/fstab to point to /dev/ada1p2 and rebooted with no issues. Ran the installer once more but this time, used /dev/ada0 as the target disk; updated /etc/fstab to point to /dev/ada0p2 and rebooted with no issues. The “cylinder errors” on the console window I mentioned earlier also disappeared.

YMMV, but this was a learning experience for me. By the way, if you have Floating IPs on the same data center as the bare metal server, you can use those with this setup.

Here’s a closer look at the errors I encountered:

Sep 10 16:53:50 guest kernel: GEOM: diskid/DISK-PHDV723501UJ240AGN: the secondary GPT header is not in the last LBA.
Sep 10 16:53:50 guest kernel: Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
Sep 10 16:53:50 guest kernel: GEOM: diskid/DISK-PHDV723501UJ240AGN: the secondary GPT header is not in the last LBA.

Sep 10 17:15:46 guest kernel: UFS /dev/ada0p2 (/) cylinder checksum failed: cg 5, cgp: 0xf3ecdcef != bp: 0x59b1fb60
Sep 10 17:15:46 guest kernel: UFS /dev/ada0p2 (/) cylinder checksum failed: cg 5, cgp: 0xf3ecdcef != bp: 0x59b1fb60

@vultr, SSH tunneling & jump host

I’ve got a few @vultr instances that have Squid listening for connections that I also use to tunnel through my local machine’s HTTP/HTTPS traffic.

In the example config below, Piscataway is the “jump host” to Frankfurt & Tokyo

Remember to modify the “username”, “ip address” & “port” values accordingly. Also, I’m assuming you already have an IdentityFile setup.

edit ~/.ssh/config and add the lines below:

Host piscataway
        User username
        Hostname piscataway_sshd_ip_address
        Port 22
        IdentityFile /path/to/file
        LocalForward 1234 piscataway_squid_ip_address:3128

Host tokyo
        User username
        Hostname tokyo_sshd_ip_address
        Port 22
        IdentityFile /path/to/file
        ProxyCommand ssh -q -W %h:%p piscataway
        LocalForward 5678 tokyo_squid_ip_address:3128

Host frankfurt
        User username
        Hostname frankfurt_sshd_ip_address
        Port 22
        IdentityFile /path/to/file
        ProxyCommand ssh -q -W %h:%p piscataway
        LocalForward 6969 frankfurt_squid_ip_address:3128

To connect to “Frankfurt” & tunnel through, simply type: ssh frankfurt then configure your local machine Proxy settings to point to port 6969

To verify your IP address, you can use

WordPress Security Tips 2019

  • Before you install the latest and greatest hyped WordPress security plugin out there, first, do some basic inventory of what lives in the DocumentRoot – depending on your setup, there may be several of these locations. Manually examine them closely using a shell or file browser.

  • Setup a @vultr VPS for $6/month and utilize the provided IPv4 address to enforce IP-based restriction in any and all your WordPress sites – most importantly, your /wp-admin/ and /wp-json/ areas. There are other uses for such VPS – the IP address stuff is just one of many.

  • Inventory your plugins & themes thoroughly – don’t need it? deactivate then delete it completely from /wp-content/plugins/ and /wp-content/themes/. Don’t let any be a sitting duck waiting to be exploited.

  • And lastly, ensure your site(s) are running the latest WordPress code base. Undefined symbol “RAND_egd”

When you compile Apache 2.4.x & OpenSSL 1.1.x on FreeBSD from source (ports), and you also use “pkg” to install or upgrade applications, you’ll run into all sorts of random errors – one of them is Undefined symbol “RAND_egd”

To fix the problem, try this remedy which seems to work:

cd /usr/ports/security/openssl111/
make deinstall clean
make install clean

add this line to /etc/make.conf 

then continue...

cd /usr/ports/devel/apr1
make deinstall clean
make install clean

cd /usr/ports/www/apache24/
make deinstall clean
make install clean

troubleshooting Apache 2.4.x/mod_dav issues

Resolving issues when you encounter 401 (auth) or 403 (forbidden) related errors is relatively easy. Tailing log files and looking at directory/file permissions from the console is the starting point.

But what happens when you encounter what is called an “500 – Internal Server Error”? It turns out, there are multiple levels of logging available you can set globally or within the context of a <Directory> or <VirtualHost > directive. See for more details.

In one of our hiccups, setting “LogLevel trace8” revealed inadequate permissions were set for the DavLockDB file – rendering endless error 500s when transferring files or creating new folder/directories.

[Sun Dec 30 06:57:17.xxxxxx 2018] [dav:error] [pid xxxxx:tid xxxxxxxxx] [client x.x.x.x:xxxxx] Could not open the lock database. [500, #400]

[Sun Dec 30 06:58:27.xxxxxx 2018] [dav:error] [pid xxxxx:tid xxxxxxxxx] [client x.x.x.x:xxxxx] The locks could not be queried for verification against a possible "If:" header. [500, #0]

A simple permissions tweak to DavLockDB /path/to/file and restarting Apache resolved the problem.

Here’s a few Apache 2.4.x directives to look over whenever similar issues arise:


OpenSSL 1.1.x & TLS 1.3

Looking under the hood, it looks like OpenSSL 1.1.1a is the default install on FreeBSD 12.0-RELEASE base. We use Squid 4.4 & Apache 2.4.37 both of which had to be recompiled.

Just a few notes if you share a similar configuration:

  • build /usr/ports/security/openssl111/ or use pkg
## modify /etc/make.conf to reflect


## modify httpd.conf to reflect something similar to these:

SSLProtocol -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3 

Once all modifications are finalized, restart Apache and fire up to verify.

To verify with Squid, use

$ squid -v
Squid Cache: Version 4.4
Service Name: squid

This binary uses OpenSSL 1.1.1a 20 Nov 2018. For legal restrictions on distribution see

Please note the above configuration purposely disables SSLv3 & TLSv1.0-1.1 – only TLSv1.2 and 1.3 are enabled with corresponding ciphersuites. All other connections will fail.