drafts

0 posts

Modal Labs

Playing around with Modal Labs One of the first things I tried was a regular cron job… This can get deployed with This function gets deployed as an app that I conveniently call (as far as I can tell the app name can be anything - as I add functions to this same app and deploy with the same name to get a new version) Notice that this also is an example of giving access to a secret - defined in the Modal Labs dashboard We can take a look at the apps running at https://modal.com/apps I then added another function to experiment with custom container images and saw then that Modal will just slap a new version on anything provisioned with the same name (intuitive enough for sure) so when I add functions to my.py script and run over and over, the app called in the Modal apps dashboard just gets a new version This means I can spin up several instances of functionally the same app but with different names/versions etc… Q: Maybe there’s gitops or policy stuff builtin to app names then? I needed…

ssh -v -i ~/.ssh/id_rsa nic@hogwarts

THen we can look at print outs

cat /var/log/auth.log also showed me that I had too wide permissions on files in ~/.ssh -> probably changed from an rsync job

TODO: change title - add –listen or –host or something as 0.0.0.0… that way it listens not on localhost or 127.0.0.1, but on all addresses!

import this; print(this); print("what is taking so long black!!")

Assuming you have a PXE server running you only need small edits to the virt-manager config

Self-hosted Docker registry with proxy pull through

I decided that I want to self-host all my docker images for the purposes of regularly rebuilding and security scanning. The first step is to set up a registry, which coincidently enough you can do with a Docker container 😛! Instructions for setting up the proxy are on the offidical docker docs here Deployment I chose to deploy with Portainer because I already use it for monitoring all my docker containers. I deploy most container with Ansible but use Portainer to setup a few more adhoc or non-git driven applications.

see samba config on hogwarts

When working with tdarr remote nodes, they need to have access not only to the same libraries but also the same transcode cache as the server otherwise the transcodes will fail…

Network Setup

To explain I’ll give a brief overview of my home setup

I have an old Dell PowerEdge R610 as my main server running a live server distribution of Ubuntu. I use ZFS for my NAS file system, and most of my datasets are accesible over my home network. I have a Tdarr server running in a docker container on the R610.

In my office I dailyi drive a gaming desktop with an Nvidia 2060 Super running Ubuntu as well. On that desktop I am running a Tdarr node in a docker container. The container has access to the network folders with my media.

Initial Magic

When I spun up a tdarr node on my desktop, the tdarr server running on my R610 automatically registered the node, which was freaking amazing. That magic though spoiled me and I thought that I didn’t need to read the rest of the docs…

Initial Fail

I setup a transcode cache directory on the R610 locally and a separate transcode cache on my desktop that the remote tdarr node would use. Having them separated led to 2 main issues:

  1. Transcodes were not being migrated back to my library properly
  2. I was running out of disk space on my desktop because tdarr wasn’t deleting the completed cache files properly.

The Fix

Make a transcode cache directory accessible on my network, and give access to that directory to the docker container running my remote tdarr node.

See 02-….yaml in ansible-nas