Package: yog
OverviewAn opinionated docker-and-ssh-centric declarative system management tool.pip3 install yogFeatures:Like puppet or ansible but a lot smaller and focused on docker, files, and cronagentless - runs entirely on top of sshentirely defers auth(z/n) to ssh and the remote system's user permissionsNon-features:No intentional ipv6 support. I don't have anything against IPv6, but my ISP doesn't give me a v6 address and as such I
don't run ipv6 on my lan. So since I can't test it at all, I just kind of disregard it, especially where it lets me
make the ipv4 UX better.Command summary:yog: Applies configurations to hosts. e.g.yog myhost.mytldapplies the config from./domains/mytld/myhost.yml.yog-repo: Manages a docker repository.yog-repo pushuses the contents of./yog-repo.confto build an image and
push it to the configured registry with the configured name and tag.Example run:usage.webmSetupConfigure docker to listen on localhost's port 4243 (which is the default). See below.Usessh-copy-idto copy your ssh key to all the servers you wish to manage. You can look into ssh certificates if
you want a more general ssh PKI solution.Configure the target system to allow you to use sudo without a password. [2]That's it. You now serve the nameless mist. Do you hear whippoorwills?Docker port listening setup (step 1)sshmyhost
sudosystemctleditdockerAnd add-H tcp://127.0.0.1:4243to the command. So for me, that file looks like:[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:4243Yog will apply files before docker containers, so you might also want to add a yog file entry like so:files:-src:docker-override.confdest:/etc/systemd/system/docker.service.d/override.confroot:yeshupcmd:sudo systemctl restart dockerUsageYog uses YML files that it calls "necronomicons" for configuration of hosts. It's organized hierarchically so
that a necronomicon for "mytld" will be applied to all hosts under that TLD.Let's learn by example:Suppose we have a folder, that can be named whatever we want, at~/projects/my-config. This is the root of a
git repo, and is also the root of our yog configuration. Make this your current working dir, or pass--root-dir.$ cd ~/projects/my-config.
├── domains
│      ├── com
│      │      └── example
│      │          └── myhost.yml
│      └── com.yml
└── files
    ├── example.txt
    ├── hello_world.html
    └── helloworld-nginx.conf

4 directories, 5 filesFiles that can be sent to hosts are stored underfiles.Host configurations - necronomicons - are stored underdomains.If we want to applymyhost.yml, we run:yog myhost.example.comExample output:$ yog myhost.example.com
[2022-12-26 11:01:52,514] [INFO]: [myhost.example.com]
[2022-12-26 11:01:59,121] [INFO]: [myhost.example.com][files]: OK [hello_world.html]
[2022-12-26 11:01:59,274] [INFO]: [myhost.example.com][files]: OK [helloworld-nginx.conf]
[2022-12-26 11:02:07,117] [INFO]: [myhost.example.com][docker]: OK registry@sha256:8be26f81ffea54106bae012c6f349df70f4d5e7e2ec01b143c46e2c03b9e551dNecronomicon formatLet's look at a necronomicon.files:
  - src: hello_world.html
    dest: /srv/hello_world/hello_world.html
    root: yes
  - src: helloworld-nginx.conf
    dest: /etc/nginx/conf.d/helloworld.conf
    root: yes
    hupcmd: sudo systemctl restart nginx


docker:
  - image: registry
    name: my-registry
    fingerprint: sha256:8be26f81ffea54106bae012c6f349df70f4d5e7e2ec01b143c46e2c03b9e551d
    volumes:
      images: /var/lib/registry
    ports:
      - container: 5000
        host: [ 5000 ]
    env:
      REGISTRY_STORAGE_DELETE_ENABLED: true

pki:
  certs:
    - authority: my-ca
      storage: /srv/pki/myhost/
      validity_years: 2
      refresh_at: 1
      names:
        - myhost.local
        - myapp.localFilesFiles are checked for equality via hash-comparison. I've found this a useful way to manage:cron files in /etc/cron.d/Root certificates to put in the system trust store[1]random config filesAttributes:src: the source. This is arelativepath rooted at thefilesdirectory in the hierarchy. You can use
intermediate dirs.dest: the destination filepath on the managed host. This is an absolute path.root: whether tosudoto root for the file put. This mainly picks who owns the file + can access files, but this
might have other useful properties for your use case. If set tono, the put operation is run as your ssh user.hupcmd: a command to run after the file is placed. A common thing in ye olde days was to send SIGHUP to a process
which would handle it by reloading the config. Commonly nowadays you might be
usinghupcmd: sudo systemctl reload nginxDocker containersDocker containers are compared on all specified attributes and won't unnecessarily restart containers.Attributes:image: the docker repository name. e.g.itzg/minecraft-serverordockerrepo.local:5000/mythingname: the container name.fingerprint: sha digest of the desired version. Tags are bad news bears so we don't support them. This is called
fingerprint instead of digest because I didn't know they were called digests when I first coded this and then never
changed it once I did.volumes: volumes to attach. see below.ports: ports to open. see below.env: environment variables to set.VolumesFor volumes, the key is the volume name and the value is the mount point.For bind mounts, the key is the host path and the value is the container path.PortsIt's a list of:container: port/protocol
host: [interface_ip:port, interface_ip:port]For the container, you can omit the protocol to get tcp by default.For the host, you can omit the interface ip to get0.0.0.0which binds all interfaces.Examples:- container: 53/tcp
  host: [ 192.168.1.103:53, 127.0.0.1:53 ]
- container: 53/udp
  host: [ 192.168.1.103:53, 127.0.0.1:53 ]
- container: 33200 # tcp is implicit default, this is the same behavior as docker
  host: [ 33200 ] # binds 0.0.0.0
- container: 3000
  host: [ 8080 ]Public Key Infrastructure (PKI)Yog supports low-fuss local/private PKI management.You'll define certificate authories incas.ymlwhich is in your yog root (so, right next todomainsandfiles).Examplecas.yml:-ident:my-castorage:"myhost.local:/srv/yog/ca/my-ca/"validity_years:3As you can see, yog tries to keep you out of the crypto weeds.identis both how you'll refer to this CA in necronomicons, and also the X.509 Common Name.storageis a string of format<host>:<path>where the trust material will be stored. More on that below.validity_yearsis how long the cert will be valid for upon generation.Once you've definedcas.yml, you can runyog-pki.$ yog-pki
Generating new CA...Now you can use it in necronomicons.pki:certs:-authority:my-ca# this has to refer to an "ident" in cas.ymlstorage:/srv/pki/myhost/validity_years:2refresh_at:1# yog runs will only renew a cert once the remaining validity time is < this number of yearsnames:-myhost.local# first entry becomes X.509 Common Name-myapp.local# subsequent names are X.509 Alternative NamesTrust Material Formats and StorageWhen yog or yog-pki write trust material to disk, it will restrict read access for private material but allow it for
public.Yog writes multiple formats to facilitate as many use-cases as possible with the same PKI:FilenameFormatEncodingPublic/PrivateNoteskey.pem.opensslTraditional OpenSSLPEMprivategood for nginxkey.sshSSHSSHprivatekey.pem.pkcs1.publicPEMPKCS1publicjava's JCE likes thiskey.ssh.publicSSHSSHpublickey.crtX.509 CertificatePEMpublicgood for nginxCrypto RemarksYog tries to keep you out of the weeds and also to be a good, expressive, concise tool for what it considers itself good at.You don't need to, and shouldn't want to, read this section. It is here to help reassure anyone who knows
too much about cryptography and wants to know some details.Yog-pki uses Python's Rust-based cryptography module and doesn't do anything clever at all (which is dangerous in crypto).It uses elliptic-curve keys, and uses the NIST P-384 R1 curve (known asSECP384R1in python's cryptography module).
This is a 384-bit key, roughly equivalent to the hardness of a 7000-bit RSA key.It uses CN and Alternative Names to set the "names" that certificates represent.Nothing else is configurable. Small tweaks come in the future but generally speaking,
I don't intend for yog-pki to handle huge, complicated PKIs. If you need to do so,
you might want to look athttps://smallstep.com/. (You can use Yog's docker and file capabilities to
deploy a smallstep installation!)Footnotes[1] This is one of those things where I feel like you probably shouldn't manage root certs like this but I have yet to
regret it? It's not a cryptographic secret, so.[2] Also something that people say you probably shouldn't do but I've yet to regret. If your user is in the docker group
it's basically root anyway from a threat modeling perspective.yog-repoYog also includes a tool for pushing images to your local docker registry. I haven't documented it yet, apologies.