Automating sytem specs and inventory

I work for a company that refurbishes electronics.  We get plenty of servers in, and processing them can take a while, especially on the models that try to obfuscate their specs.

To solve this, I started making a boot drive that can handle all of it automatically – boot, specs, and printing, all in one.

From a previous project, I have a ZP450 printer that’s hooked up to a thin client running CUPS, and it prints on 4×6 labels.

I took a solid state drive and installed Antergos on it (any flavor will work, I just had an Antergos installer laying around for some reason), and installed only the base packages (which, admittedly, was still more than I wanted to have, so I did some paring down later).

Once it was installed, I wrote a simple script that gets server information to pass on to sales, and it then puts that information in a text file for me.  From a previous project, I’d learned to make my life easier by using serial numbers for the filename, so that was fairly straightforward now.  So now my biggest issue was how to print it remotely.

This was fairly easy, actually.  Using SSH keys, I can easily automate the login process, and by having the script run on boot and wait for network access to print, I can easily move the file using SCP (again, automated!) and tell the server to print it.

Overall, pretty simple 🙂

Raspberry Pi 3 Media Server, Part 3

Now that I’ve gone over the initial design, time to start digging into the meat and potatoes of this thing!

The Raspberry Pi 3 has a 1.2GHz quad-core ARM processor, and 1GB of RAM.  While it’s not going to win any awards for raw processing power, for a lot of applications, it’s sufficient, including the ones here.

In my original design, one RPi was going to run Plex Media Server, exclusively, while the other handled transcoding video.  Interesting, Plex does run natively on the RPi (or, specifically, on ARM).  The standard documentation, unfortunately, is out of date if you want to run it on a 3B.

Instead, follow the directions straight from the packager for ARM64

# become root
sudo su
# add my public key
wget -O - | apt-key add -
# add my PMS repo
echo "deb [arch=armhf] jessie main" >> /etc/apt/sources.list.d/pms.list
# activate https
apt-get install apt-transport-https
#enable armhf support
dpkg --add-architecture armhf 
# update the repos
apt-get update
# install PMS
apt-get install plexmediaserver-installer:armhf

Essentially, this makes sure that we get a version that takes full advantage of the hardware.  Once the server is installed, you can just start it up.

sudo systemctl enable plexmediaserver && sudo systemctl start plexmediaserver

Once the server is up and running, just visit the page in your browser


Obviously, replace this with your Raspberry Pi’s IP address, but after that, it’s just a matter of configuring it!

Your Vim May Vary 1 – SCP Editing

Another thing I’ve been learning about lately is Vim.

In the 11 years I’ve been using Linux, I always stuck to simple text editors – nano was a good choice for me, since it’s pretty much entirely visual and the keybindings are printed at the bottom.  But lately, I’ve been doing more scripting, and I’ve needed more functionality from a text editor, so I started learning how to use Vim.  I’m still not particularly advanced in it, but it’s suiting my needs better.  One of my favorite recent discoveries is the ability to edit remote files using a local Vim – I’ve put a small amount of work into my vim configuration, so I’d like to see my work not go away every time I need to edit a remote file.

It’s a pretty simple thing to access, actually.

vim scp://user@host/relative/path/

vim scp://user@host//absolute/path

The user can be omitted if it’s the same name as your current user, and the relative path is relative to the login directory, usually ~ .  I’d recommend setting up SSH keys, just to make it more transparent (although there are plenty of other reasons to set up keys over password authentication).  From there, Vim will treat it almost exactly like a local file, until you save; the buffer is automatically sent to the remote location when you write it.  Pretty useful if you’re constantly working on remote machines!

Transmission Remote Client

If you use a lot of torrents, you eventually realize that shutting off your computer at night means your computer is no longer downloading.  It’s sometimes frustrating; we don’t wanna leave our stuff on all the time… right?

A lot of low-power devices support torrent clients.  The Raspberry Pi, since it runs Linux, supports a handful, but my first experience with a remote BitTorrent client was actually in the form of my router.

My router is an Asus RT-AC68R (the link is to the AC68U which is functionally identical to the older R model).  While it’s running on alternate firmware, the core functionality is actually present in the basic version.  If you install the “DownloadMaster” software package, you can use the router to download torrents to a connected USB device.

The web interface for DownloadMaster kinda sucks, to be frank.  It presents very few options, it’s slow, it freaks out easily… and it’s a pain to add torrents when you’re used to the convenience of a desktop-based client.

Fortunately, we have a really easy workaround!  The DownloadMaster application is actually a package, and the BitTorrent client used in it is actually a daemonized version of the open-source Transmission client.

Once we know this, it’s really easy to get the best of both worlds – easy configuration, monitoring, and adding of torrents, while running on a lower power device.

Transmission has a great remote client.  If your router, or RPi, or any other device, is running the transmission daemon, chances are, you can use the remote client to make managing it a lot easier.

For this, we’ll be discussing the transmission-remote-gtk client, which is available for Windows and Linux (and probably Mac, but I’ve honestly never tried it).

Check out the Windows client or install it on your Linux distribution:

sudo apt-get install transmission-remote-gtk

on Debian based systems (Ubuntu, Linux Mint).  The package name is fairly constant between distributions, so use your distribution’s package management software to install it.

Once it’s installed, open it up, and you’ll see what looks like a fairly basic torrent client.  For the most part, it is – Transmission never has tried to be the most feature packed client, but it does what it does well.

In the remote client, click the “Connect” button in the upper left, and fill in the details for your device (IP address, user name, password, etc) – if you’re using the DownloadMaster setup from Asus, you can use your router username and password, and the default ports.  It’s pretty straightforward.  Save your settings and click connect again, and you’ll see your list of torrents in the main frame of the application.

From here on out, it functions just like a regular torrent client; you can even click links to add them (assuming your system is set up to send the link to the remote client; on Windows, make sure the association is set and you’re good to go.)

The remote client lets you specify a fair bit more, such as download locations, files to download – essentially, the things you expect to see in a modern client.

Overall, I’d strongly recommend using a setup like this – it’s simple to do, offers a lot of flexibility, and is just plain interesting.

Not a fan of Transmission for some reason?  Other clients, such as Deluge, also support this sort of remote access!

Raspberry Pi 3 Media Server, Part 2

I had a plan when I ordered the parts; it’s not that ambitious, in the grand scheme, but likely the most interesting thing I’ve worked on.

Design (Initial)

  • 2x Raspberry Pi 3
  • 1x 2TB External HDD
  • 1x Wireless Router with NFS/SMB support
  • Plex Media Server

My initial plan was to use two RPi for this.  One would strictly handle media server functions, the other would strictly handle transcoding (in testing, I’m able to transcode about 12 hours of HD video per day if the RPi is running all day long.)  Unfortunately, no plan survives first contact with the enemy, but that’s something we’ll get into later.

The external HDD is actually going to be the existing media server hard drive in an enclosure.  There’s a significant amount of media already stored, and it seems a waste to do it any other way.

I started testing using my Asus router.  It’s a good router, but that’s with some custom firmware (Merlin, if anyone wants to check it out, I can recommend it).  The custom firmware adds support for a few things, like NFS, but the stock firmware actually supports torrents natively using the open source Transmission torrent client running as a daemon. This opens up some pretty amazing options for this project (or, well, if I was able to use my personal router for this project, it would).

Plex Media Server is being used partly for a technical reason, partly for familiarity.  It’s a good piece of software; it handles the vast majority of media tasks on its town, which great for building, say, a media server for your parents.  Add in the apps and smart-device support, and we have a simple winner!

Raspberry Pi 3 Media Server, Part 1

So, my parents like having TV shows to watch.  A few years ago, we investigated cutting the cord, and I was asked to build a media server setup for the house.

The existing solution, honestly, kinda sucks.  Adding new shows to the RSS feeder is clunky as hell, to the point that I’m the only one who can do it; the media server is a pretty big machine, really, and sucks down about 6KWh per day.  But that’s not the worst part any more.

My parents are retiring soon, selling the house, and they’re going to travel the country in an RV.  There’s a kink now – the media server is kinda… big.  It’s honestly the biggest (and most power-hungry) machine in the RV, and it’s not exactly fault-tolerant.

My mom isn’t retiring until next year, which leaves me approximately a year to build this.  I’ve received the parts, and I’ve been working on it for some time now!

Part 2 is posted, read it here!