We now have these Wisdom items in stock: 2001 (Pink), 7001 (Pink) & 130406 (Black) & 2015 (Black)
We now have these JWorld items in stock: JW-100 -Urban, Graffiti, Atlas & Road Trip as well as DJB-22 Atlas, LD-06 Blue Raspberry & DJ-19 Black & Pink Logo.
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
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
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 https://danskoya.com/ipmoose.php
- 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.
Our favorite websites offering remittance & eLoad/pasaload services for loved ones in the Philippines.
For an added layer of security, use 2-Factor Auth if the service supports it. Touch/Face-ID support is also available for most recent iOS devices.
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 mod_ssl.so: 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 DEFAULT_VERSIONS+=ssl=openssl111 then continue... cd /usr/ports/devel/apr1 make deinstall clean make install clean cd /usr/ports/www/apache24/ make deinstall clean make install clean
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 https://httpd.apache.org/docs/2.4/en/mod/core.html#loglevel 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:
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 DEFAULT_VERSIONS+=ssl=openssl111 ## modify httpd.conf to reflect something similar to these: SSLProtocol -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3 SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA
Once all modifications are finalized, restart Apache and fire up https://www.ssllabs.com/ssltest/ 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 https://www.openssl.org/source/license.html
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.