futurama

A system for install flash drives

Last updated on

At work, we have to provision instruments and install applications on different machines throughout the office. I used to have a collection of flash drives that I would toss different drivers, installers, and scripts onto but then I’d end up with lots of them labeled “chip’s junk”. Finally I had enough and merged them all into one drive.

But, then I found syncthing for my laptops and desktops. We have a handful of janky .NET applications that aren’t portable and require strange third party component libraries with proprietary installers. When I was working on one of the apps on a different machine I was tossing new builds to test into my wipshared shared folder, but decided to make an installers shared folder.

Then, I wanted to combine the two, and had a syncthing share that’d do 90% of the work but I had a flash drive that I could take on trips or onto airgapped machines. I used one of my linux desktop machines and configured syncthing to replicate the installers folder onto a mounted flash drive.

Net. via
Syncthing

   └──────────► FlashDrive1

      Crontab     ├───►Primary Flash Drive
      Sync Script │───►Alternate Flash Drive
                  └───►Archive SSD

Syncthing is synchronizing the installers folder onto one flash drive connected to the machine and every minute a synchronize script triggers rsync synchronization from FlashDrive1 onto two more flash drives and an archive SSD.

FlashDrive1 is intended to stay constantly connected to the linux machine while my “Primary Flash Drive” is what I pull and connect to instruments and other PCs to perform installations. The “Alternate Flash Drive” is one that I can give to other folks that need up-to-date installers.

Each of the flash drives is mounted by their block device ID within the fstab file on the machine, this allows for hotplugging of the flash drive (as long as I avoid pulling the drive out as the activity light is flashing).

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
PARTUUID=fdea6754-5d35-44a5-aad4-0a7166b3bd5d /mnt/workarchive exfat auto,uid=1000,gid=1000,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2 0 0
PARTUUID=ed2ae601-01 /mnt/install2 exfat auto,nofail,uid=1000,gid=1000,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2 0 0
PARTUUID=c6d4f689-01 /mnt/installalt exfat auto,nofail,uid=1000,gid=1000,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2 0 0
PARTUUID=e1f303f4-01 /mnt/chipinstl exfat auto,nofail,uid=1000,gid=1000,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2 0 0

fstab even has a helpful hint about using blkid to get the UUIDs

Now when I build a new installer of an application or update a script I toss it into the syncthing folder and within a couple minutes - by the time I walk down to the closet that houses that specific linux machine - the files are present on the flash drives.

In the future I’d like to expand this to automatically sync from our JFrog/S3 buckets that house artifacts so I get a new installer right after CI/CD completes.

Also, I have nginx serving files from the syncthing directory so it’s possible to access files within the drive share over HTTP as yet another option.

Update 1

I forgot to include the cheat sheet for configuring flash drives that can be mounted on most operating systems (AKA exfat)

# Install exfat tools
apt install exfatprogs
# Create filesystem on flash drive
mkfs.exfat -L install1 /dev/sdd1

Thanks for reading! Facts and circumstances may have changed since the publication of this post so it's worth checking for new posts to see if anything's changed before jumping to conclusions.

Have a question or idea? Shoot me an email at _@chip.bz or ping me on mastodon at talking.dev/@chip.