podcust.transmission package

Submodules

podcust.transmission.custodian module

Custodian Class for Transmission container.

This module is responsible for setting up and maintaining the container.

The container is intended to live inside the users home directory, in a hardcoded location. Namely $HOME/transmission/. The container is deployed within a pod named transmission.

class podcust.transmission.custodian.TransmissionCust(name: str = 'ghcr.io/linuxserver/transmission')[source]

Bases: object

Main class for handling the transmission container.

Parameters:name – The full repository name of the image this class is custodian for.
check_if_new_version_is_available() → bool[source]

Check if there is a new version of the transmission docker image from linuxserver io.

clear_location()[source]

Delete all files within the (hard-coded) path used by the transmission image under the podman custodian.

deploy()[source]

Create a pod named transmission to deploy our container. The steps taken during deployment are the following:

  • Delete path we ‘ll use to ensure a clean start.
  • Create the necessary folders, and give them proper permissions.
  • Write the proper kube yaml file that we ‘ll use to deploy the container.
  • Open the necessary firewall port.
  • Execute the podman play command to start the pod with the transmission container.
pull_latest_transmission_image()[source]

Pull latest transmission container image from linuxserver.io

The relevant shell command is:

$ podman pull ghcr.io/linuxserver/transmission
rm()[source]

Delete transmission pod.

start()[source]

Start transmission pod.

stop()[source]

Stop transmission pod

update_running_image()[source]

Checks if a new image is available and if so, rebuilds the container.

Module contents

Using the Linuxserver.io transmission container image

Design Notes.

  • We will be using podman’s ability to instantiate containers through a kubernetes yaml file.
  • We will use local configuration file to store sensitive information outside of the source code. This is security risk and a better option should be implemented for the long term.
  • A systemd service is to be created to start the container on boot and close it at power off.
  • High level command line commands will be available for common use-cases (instantiate container, run it, stop it, upgrade it.)