NVR Build

While using MotionEyeOS on a raspberry pi 3 worked for a while, eventually I began to need a bit more hardware to handle some of the security camera goals I had. For this, since I already had my hand crafted 19in rack, I wanted to find a decent rack mount server for it, preferably SuperMicro.

I ended up finding a Redwood Director RDIR-1G on ebay for a good price. After doing some research, it l found out that it was a SuperMicro box, specifically it was a 5018D-MF. This is a solid little 1U half depth box with an E3 server processor on it. The listing claimed it had 32GB of RAM, however I found out later that it only had 8GB ram. This was still a pretty decent deal and I went with it.

Of course, once it arrived whats the first thing we do, open it up.

Initial Look Inside
Continue reading “NVR Build”

Virtualized Docker Swarm

Why

Why not? In reality, I always wanted to play with clustering, originally with proxmox and ceph, but I never had enough hardware to do so. I do however have a proxmox node with enough ram that I can host multiple lightweight nodes.

Docker swarm is lightweight enough that I can virtualize the entire cluster on my single proxmox host. While this isn’t fault tolerant like a cluster across multiple nodes, it does mean I can reboot cluster nodes for kernel updates and maintain my uptime. I also am able to add additional docker swarm nodes on separate hardware if I get additional hardware, and there is the benefit of having the cluster load balance itself for which software is running on which node.

Benefits

Each node in the cluster is identical, each can be replaced by following the exact same process and while I don’t have automated deployment of new nodes, they are still closer to cattle than many of my other virtual machines. Due to the goal of replicated storage between the nodes, I should also be able to take a single node and rebuild the entire cluster if needed, since it would have the entire clusters configuration.

Continue reading “Virtualized Docker Swarm”

3D CAD Model Organization

I’ve been trying to come up with a way to handle storing and version controlling my 3D models (both from thingiverse, and models I create myself), however i ran into quite a few deadends when looking for software built for this purpose (PLM/PDM), so I’ve figured it would easiest to build a folder structure with some metadata alongside it to go on top of GIT, and allow GIT to deal with version control. While STL files are text, a majority of my models are in proprietary binary formats, but GIT can still at least store the files and provide a history. I figure the repository would have 3 primary folders, parts, products, 3rd party (more or less unstructured). Each part/product would also have an export folder which will store a copy of STLs, and metadata to go with for a specific published version of a model (might be duplicate data, maybe use some type of tag in GIT to represent each officially published version).

  • Parts: not very useful as a single component, but used to create products, or as spare components to some item
  • Products: a grouping of parts to encompass a single object, or a single piece that makes up the object (think one piece phone stand, vs a multi-piece assembly). While these may seem separate in their usage, they will be the final product of whatever is created.
  • 3rd party: these may or may not follow the data policies, things like the ultimaker 2 models/plans and the backblaze storage pod models which are neat to have, but we won’t be applying our policies to those large assemblies. These can also include the innumerable thingiverse models we all acquire, eventually the goal will be to incorporate all thingiverse metadata into the dataset as well to provide details locally for all models herin.
  • Exports: Each part or product can have versioned exports as well, these will be one specific version of the STL, assembly, and tags, allowing a product to reference the version of the export until both are updated to support newer versions or varients.
Continue reading “3D CAD Model Organization”

IRC Botnet and Jenkins

I wrote a number of IRC bots a number of years ago, hosting them on my infrastructure. Since building a 3 node docker swarm, I decided that these would be good candidates to use in learning Jenkins for both auto building the software, and building containers. I hadn’t made my own dockerfiles before, nor had I setup proper builds outside of my IDE for these bots before.

Continue reading “IRC Botnet and Jenkins”

Sqlite Resolution on UnRaid

Like many, I had issues with sqlite database corruption on Unraid. I found while researching it that it had to do with file locks in the fuse file system unraid uses to merge disks. I found the best way to circumvent this is to use the cache disk for those databases and map them directly. My docker mappings now point to /mnt/cache/share instead of going /mnt/user/share. This solved the issue better than the 6.8.0rc5 fixes. This avoids the system in question completely and solved the stability issues for me.

NextCloud Setup: Joplin

Joplin was relatively simple to setup on NextCloud. The only difficulty is setting the folder it should run out of. This is done via the webdav url that Joplin connects to. An example is shown below on how to get this going.

https://nextcloud.rapternet.us/remote.php/dav/files/<username>/<path to Joplin directory>

The webdav url just needs your username and the path it should utilize, in my case I just have Joplin setup to go to Documents/Joplin. This would go in the tag above, just add a username and it’s done. This does have to be setup the same way on all Joplin clients or you will end up with files missing from one or another, though they will all be in NextCloud.

NextCloud Setup: Desktop Client

Setup is easy enough IF http does not redirect to https. The authentication mechanism for the NextCloud desktop client for some reason doesn’t work when http is redirected to https (ex: in the way let’s encrypt sets it up). With the right server setup after that, everything is straight forward.

3D Printed RPI Rack

PI Rack Mounted in the Rack

I printed out the Raspberry Pi Blade Center found on thingiverse on my Ultimaker 2. This was a relatively easy set of units to print, with a majority of the time needed on it to be spent cleaning up the large number of pi holders. I assembled these with threaded rods and lock nuts. The threaded rods had to be cut to size but in the end, everything was assembled in about a weekend after printing was done. In order to fit RPI 3B+ with the POE hat, I did end up hand modifying some trays, which I don’t have a model for the changes so they can be printed in that form.

Before trimming the threaded rods
Continue reading “3D Printed RPI Rack”

Home Built Server Rack

Finished Product

In order to organize my lab a bit better, I decided to custom build a server rack. This was to be the same height as my desk and also be usable as more work surface area. I determined that a 15u rack would be the the best size, and it would give me some room to grow as well since i only currently have a few things that can fit in the rack (The Fractal Design Define XL R2 is far too big to fit, so its just the vhost, networking equipment and some RPIs). First off, the design, which ended up being slightly incorrect on sizing of one of the components.

Continue reading “Home Built Server Rack”

DNS Structure

The goal of the DNS structure of my lab was primarily to create a very stable foundation. Second to that, was the addition of two services, the first a local DNS server to avoid loopback issues with my ISP, and the second was pihole ad blocking.

To set this up, UCS was chosen as a domain controller/DNS server over FreeIPA. Linux was chosen as the platform of choice as that is what a majority of my systems are, and I don’t have any windows server licenses. UCS was installed to a VM, and a second ubuntu VM was configured with PiHole. These were configured to handle local queries first, then everything else. If one of my local DNS servers is down, the clients won’t notice a change as everything uses Google DNS as backup.