antipaucity

fighting the lack of good ideas

don’t worry about the mules…

Don't worry about the mules...Just load the wagon

sshuttle – a simple transparent proxy vpn over ssh

I found out about sshuttle from a random tweet that happened to catch my eye.

Here’s the skinny (from the readme):

  • Your client machine (or router) is Linux, FreeBSD, or MacOS.
  • You have access to a remote network via ssh.
  • You don’t necessarily have admin access on the remote network.
  • The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
  • You don’t want to create an ssh port forward for every single host/port on the remote network.
  • You hate openssh’s port forwarding because it’s randomly slow and/or stupid.
  • You can’t use openssh’s PermitTunnel feature because it’s disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance.

Here’s how I set it up on my Mac

Install homebrew:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Install sshuttle (as a regular user):

brew install sshuttle

Test the connection to a server you have:

sudo sshuttle -r <user>@host.tld -x host.tld 0/0 -vv

I also made sure that my target server could be connected-to via certificate for my local root user – but you can use a password if you prefer.

Check your IP address:

curl https://ipv4.cf

Once you make sure the connection works, Ctrl-C to end the session.

Then setup an alias in your shell’s .profile (for me, it’s .bash_profile):

alias vpn='sudo sshuttle -r <user>@domain.tld -x domain.tld 0/0'

Other things you can do

According to the full docs, there are a lot more things you can do with sshuttle – including running it on your router, thereby VPN’ing your whole LAN through an endpoint! You can also run it in server mode.

This is a super useful little utility!

basic dockerized jitsi deployment with an apache reverse proxy on centos

After a friend of mine told me he wanted to deploy Jitsi on my main webserver, and me saying “sure”, I decided I wanted to get it up and running on a new server both so I knew how to do it, and to avoid the latency issues of videoconferencing from central North America to Germany and back.

Before I go into how I got it working, let me say that the official Quick Start guide is good – but it doesn’t cover anything but itself.

Here’s the basic setup:

What To Do:

Once you have your new CentOS instance up and running (I used Vultr), here’s everything you need to install:

yum -y install epel-release && yum -y upgrade && yum -y install httpd docker docker-compose screen bind-utils certbot git haveged net-tools mod_ssl

I also installed a few other things, but that’s because I’m multi-purposing this server for Squid, and other things, too.

Enable Apache, firewalld, & Docker:

systemctl enable httpd && systemctl enable docker && systemctl enable firewalld

Now get your swap space setup:

fallocate -l 4G /swapfile && chmod 0600 /swapfile && mkswap /swapfile && swapon /swapfile

Add the following line to the bottom of your /etc/fstab:

/swapfile swap swap default 0 0

Restart your VPS:

shutdown -r now

Get your cert from Let’s Encrypt (make sure you’ve already setup appropriate CAA & A records for your domain and any subdomains you want to use):

certbot -t -n --agree-tos --keep --expand --standalone certonly --must-staple --rsa-key-size 4096 --preferred-challenges dns-01,http-01 -m <user>@<domain.tld> -d <jitsi.yourdomain.tld>

Create a root crontab entry to run certbot frequently (I do @weekly ~/renew-le.sh)

Go to the home directory of whatever user you plan to run Jitsi as:

su - <jitsi-user>

Begin the Quick Start directions:

  • git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
  • mv env.example .env
  • Change the timezone in .env from Europe/Amsterdam if you want it to show up in a sane timezone (like Etc/UTC)
  • mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}
  • docker-compose up -d

Now configure Apache for SSL. Start with this reference I posted.

But in the [sub]domain-specific conf file z-[sub]domain-tld.conf, add proxy and authentication lines (so that only people you allow to use your video conference can actually use it):

ProxyPreserveHost on
ProxyPass / http://localhost:8000/ nocanon
ProxyPassReverse / http://localhost:8000/
ProxyRequests       off
ServerAdmin warren@warrenmyers.com
AllowEncodedSlashes NoDecode
<Proxy http://localhost:8000/*>
    Order deny,allow
    Allow from all
    Authtype Basic
    Authname "Password Required"
    AuthUserFile /etc/httpd/.htpasswd
    Require valid-user
</Proxy>
RewriteEngine       on
RewriteRule        ^/meetwith/(.*)$ http://%{HTTP_HOST}/$1 [P]
ProxyPassReverseCookiePath /meetwith /

Reload your configs, and make sure they’re happy, fixing any errors that may exist:

apachectl graceful

Setup at least one user who’ll be able to access the site:

htpasswd -B -c /etc/httpd/.htpasswd <user>

You should also configure firewalld to allow only what you want (http, https, ssh):

firewall-cmd --zone=public --add-service=http && firewall-cmd --zone=public --add-service=https && firewall-cmd --zone=public --add-service=ssh

With any luck, when you now navigate to https://[sub.]domain.tld in your web browser, and enter your username and password you created with htpasswd, you’ll get the Jitsi welcome page!

Other Resources:

alfred nobel was a thief!

cost averaging

There’s often irrational panic in investment markets.

Most recently that’s been due to the Wuhanvirus/coronavirus/covid19 scare.

If you’re selling while the stock market is falling, you’re losing money.

You want to buy low, and sell high – but since you can never know where either the bottom or top is, how can you mitigate against market ups and downs?

Cost averaging.

What is cost averaging? It’s a way of hedging your investments against momentary swings in the stock market by lowering your average cost of each share.

A simplified cost averaging example for Universal Widgets Inc.

Universal Widgets Inc (UWI) is trading today for $10 per share. You like the company, and decide to buy $1680 in UWI shares (a total of 168 shares).

Next month, UWI has dropped to $7 per share. You still believe in the company’s future, and you still have $1680 to invest in the market, so you buy another $1680 worth of UWI stock at $7 per share (240 shares total).

Two months later again, and UWI has dropped to $3/share. Perhaps your confidence in the company has dropped some, but if you sell now, you’re guaranteed to lose over $2000! So instead of selling, and guaranteeing your loss, you again buy $1680 in shares (560 more).

You now have 968 shares of UWI that cost you $5040.

But they’re only worth $2904.

What share price does UWI need to hit in order to show a profit?

Now you merely have a simple math problem: take the cost, subtract the value, and divide by total shares: (C-V)/S

$5040 – $2904 = $2136

$2136 / 986 = ~$2.21

So when UWI gets back above $5.21 per share, you’re in the black.

If/when it recovers to your initial purchase price of $10, your portfolio will be worth $9860!

By cost averaging, you’ve reduced your risk, and increased your likelihood of coming out ahead when investing

Sidebar

This is, more-or-less, how some mutual funds grow (and why beginning investors (and most seasoned investors) should buy-into mutual funds instead of individual stocks).

next update: keeping your let’s encrypt certs up-to-date

I noticed I haven’t updated my previous post on keeping my Let’s Encrypt certs updated since building-out a couple new servers.

systemctl stop httpd.service
/bin/certbot renew --preferred-challenges http-01,dns-01 --must-staple
systemctl start httpd.service
systemctl restart postfix

Not a big change, but one worth making

If you haven’t installed certbot yet, you should

tesla’s cybertruck [almost] does two things i’ve said for a long time

“Telsa will add solar power to the Cybertruck to generate 15 miles per day. Fold-out solar wings for the Cybertruck would generate 30 to 40 miles per day. The average daily commute in the US averages 30 miles per day.”

https://www.nextbigfuture.com/2019/11/solar-power-tesla-cybertruck-could-have-free-15-40-mile-daily-commutes.html (https://twitter.com/elonmusk/status/1197889310550216704)

Or remember my comments on SolarCity 3 years ago?

Offering a solar option (or standard) tonneau cover for the bed is an absolute no-brainer. When you own the solar production plant, why wouldn’t you include it?

But more than this, the multi-motor options are a real-world implementation of something I’ve been saying for 20+ years: it makes far more sense to put a motor at (or very near) each wheel or at least axel in an electric vehicle than it does to have one that’s distributing its work everywhere.

Sure, running the cabling to each wheel/axel is a little complicated – but it’s a lot less complicated than drivetrains.