VPetkov.net

After years of maintaining a complex WordPress-based blog, Linux servers, and a Datacenter Colo, I decided it was time to simplify. This new site is built with Hugo and focuses on one thing: making it easy to write and share ideas instead of spending my limited free time maintaining infrastructure. At the same time, I think we’re at another inflection point on the internet—one where AI is changing not only how we build software, but also what kinds of technical content are worth publishing.

Last Update: 3-13-21 | Official Raspberry Pi Package now available - see bellow

Last Update: 11-9-20 | Updated ventz-media-pi for new Chromium version (v.84+) and new WideVine setup: v.4.10.1679.0+ NOTE: You MUST re-download and re-run it from this date to fix - lots of changes!

Last Update: 11-2-20 | Updated libwidevinecdm.so_.zip to v.4.10.1679.0 within ventz-media-pi

Last Update: 7-22-20 | Updated .desktop with Chrome User Agent string for CrOS Chrome/77.0.3865.120

Last Update: 7-20-20 | redacted company reached out about creating an official package, also there are conversations happening with redacted company about official support of the Pi

Last Update: 5-6-20 | Specify that “Raspbian with desktop” is assumed and tested

As of 3-30-2020, if you want the “paste-one-line-it-just-works” go to:

vpetkov.net/2020/03/30/raspberry-pi-netflix-one-line-easy-install-along-with-hulu-amazon-prime-disney-plus-hbo-spotify-pandora-and-many-others/

^^^ Please use the post linked above for my “one-line it just works” install ^^^
(Ignore everything bellow this, as it’s the original development work)

If you did not know about this - you should be very worried.

A few hours ago it was discovered that Apple’s FaceTime app allows anyone to connect to any Apple device that supports FaceTime and hear their audio without the person ever accepting the call. What’s worse (debatably?) is that it is incredibly easy to do this.

Listen-in on any remote Apple device in 4 steps

1.) Start a FaceTime call with someone
2.) While the call is “connecting”, quickly swipe up on the FaceTime menu
3.) Click on the “+ Add Person”
4.) Add your own phone number/contact

A long time ago I became frustrated with having to update my WordPress plugins manually, so I created a Perl script and a blog post (vpetkov.net/2011/08/03/script-to-upgrade-plugins-on-wordpress-to-the-latest-version-fully-automatically/) that explained how to automate this. The idea was quite simple: feed a plugin name, have the script check the WordPress plugins page for the latest versioned download, grab it, and extract it over the specified blog plugins directory and thus update the plugin.

The script was simple and it worked very well. It made dealing with plugins many times easier. However, there was one big down side as some users pointed out - it did not actually check if a plugin needed to be updated. It blindly replaced the current plugin with the latest version. This meant that there was no way to “efficiently” automate it. If you cron-ed it directly, it would simply pull and update all your plugins at whatever period you specified. For the longest time this really irritated me, but I didn’t have time to dig through WordPress to understand how the engined checked and signaled for local plugins. One particular user (Joel) forked a copy and made many improvements to deal with this specific issue.

As time went on, I decided to look at this problem again. A couple of years ago I solved it in a really elegant way, but I didn’t have time to update the blog post. A few days ago, after looking at the blog statistics, I realized that the WordPress article was one of the top 10 most popular ones. So, with that said, here is:

A new simple and elegant solution

The idea is to use the WordPress CLI in order to “query” the local plugins database for plugin names, version number, and “activated” status, and then compare the “local” plugin version with the “remote” plugin version. If the plugin is active and in need of an update, fall back to my original Perl script to update it. Aha! And now we have something that can be cron-ed 🙂

To get started, first grab the WP CLI utility. We are going to rename it, move it to an accessible place, and take care of permissions so that we can use it:

curl -O  https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp && chmod +x /usr/local/bin/wp

NOTE: Updated code 10-27-2018

In this day and age where everything is measured, recorded, and available remotely (via a REST API most of the time!), it really bothered me that our heating oil tank measured the remaining gallons of oil by a crude plastic dip stick. It’s not accurate, there is no historical data, and there is no way to audit (for honesty, accuracy, or problems/errors).

So the problem is simple enough: Find a quick and easy way to remotely monitor the number of gallons of heating oil in a home, and alert at pre-set intervals (let’s say 75%, 50%, and 25%) of remaining oil in the tank.

After looking for commercial solutions, the cheapest one I found is $120 with a $10/year fee. In my view, that’s simply ridiculous. I decided that I could build something better for 1/3rd of the price ($40), without an yearly fee.

Hardware How-To

Start with this Instructable I created with the exact parts/steps, and with lots of pictures:
https://www.instructables.com/id/Monitor-Heating-Oil-Tank-Gallons-With-Email-SMS-an/

This should take care of the hardware side.

You need to connect to a Cisco AnyConnect (or Juniper Pulse Connect) VPN, and you cannot stand the default client for a variety of reasons (slow connects, crashes, unable to start, pointless pop-up notifications, crashes, pid-loss, etc), and so, you look for alternatives.

You find OpenConnect - the perfect solution, only to realize that the 3rd-party GUI is basically broken and actually doesn’t work (last checked on 8-14-17) with 2-Factor authentication (ex: Duo).

At this point, you can run OpenConnect from a terminal, which works, but you have to keep the terminal open and you have to wrap the long command in a shell script.

Or, you can use my little solution which seems to work perfectly.

Everything you need to get started is on GitHub:
https://github.com/ventz/openconnect-gui-menu-bar

I needed a way to monitor Docker resource usage and metrics (CPU, Memory, Network, Disk). I also wanted historical data, and ideally, pretty graphs that I could navigate and drill into.

Whatever the solution was going to be, it had to be very open and customizable, easy to setup and scale for a production-like environment (stability, size), and ideally cheap/free. But most of all - it had to make sense and really be straight forward.

3 Containers and 10 minutes is all you need

To get this:

There are 3 components that are started via containers:

Grafana (dashboard/visual metrics and analytics)
InfluxDB (time-series DB)
Telegraf (time-series collector) - 1 per Docker host

The idea is that you first launch Grafana, and then launch InfluxDB. You configure Grafana (via the web) to point to InfluxDB’s IP, and then you setup a Telegraf container on each Docker host that you want to monitor. Telegraf collects all the metrics and feeds them into a central InfluxDB, and Grafana displays them.

Setup Tutorial/Examples

If you have not used Swarm, skim the non-service-discovery tutorial to get a feel for how it works:
vpetkov.net/2015/12/07/docker-swarm-tutorial-and-examples. It’s very easy, and it should give you an idea of how it works within a couple of minutes.

Using Swarm with pre-generated static tokens is useful, but there are many benefits to using a service discovery backend. For example, you can utilize network overlays and have common “bridges” that span multiple hosts (https://docs.docker.com/engine/userguide/networking/get-started-overlay/). It also provides service registration and discovery for the Docker containers launched into the Swarm. Now lets get into how to use it with service discovery - which is what you would use in a scaled out environment/production.

Again, assuming you have a bunch of servers running docker:
vm01 (10.0.0.101), vm02 (10.0.0.102), vm03 (10.0.0.103), vm04 (10.0.0.104)

Normally, you can do “docker ps” on each host for example:
ssh vm01 ‘docker ps’
ssh vm04 ‘docker ps’

If you enable the API for remote bind on each host you can manage them from a central place:
docker -H tcp://vm01:2375 ps
docker -H tcp://vm04:2375 ps
(note: port is optional for default)

But if you want to use all of these docker engines as a cluster, you need Swarm.
Here we will go one step further and use a common service discovery backend (Consul).

Docker Swarm Tutorial with Consul and How-To/Examples

[ updated 10-30-2016 | Upgraded Plex to plexmediaserver-1.1.4.2757-24ffd60.x86_64.rpm and CentOS ]

Recently I tried setting up a Plex server in a docker container. The first problem was the 127.0.0.1:32400 bind which required logging in locally or port forwarding. After doing this once, I realized that you could use the Preferences.xml file, but that meant that you couldn’t truly automate this/deploy it elegantly in a docker container. And what if you wanted to run other servers - for friends? I finally figured out how to do this in the most elegant way possible.

First - Grab your Unique Plex Access Token

Login at https://app.plex.tv/web/app with your username and password
Open your javascript console (in Chrome: View -> Developer -> JavaScript Console)
and type:
console.log(window.PLEXWEB.myPlexAccessToken);

Note the token, which will look like this: “PZwoXix8vxhQJyrdqAbY”

At this stage DO NOT click log out of your account until you register the new server. Otherwise your token will regenerate.
Once you register the server, it won’t matter after that if the token changes.

Grab my Docker Image

Check out: https://hub.docker.com/r/ventz/plex/
You can pull it down by doing:
docker pull ventz/plex