change how pipenv is installed to hopefully fix the fucking gitea workflow

.gitea/workflows/production/build-deploy-docs.yml

@@ -1,9 +1,12 @@
 on:
   push:
     # paths:
-    #   - "content/**"
+    #   # - "content/**"
-    #   - "static/**"
+    #   # - "static/**"
-    #   - "templates/**"
+    #   # - "templates/**"
+    #   # - ".conf/**"
+    #   # - ".gitea/**"
+    #   # - ".pipfile"
     branches:
       - "main"
 
@@ -36,14 +39,13 @@ jobs:
           export DEBIAN_FRONTEND=noninteractive
           apt update
           apt upgrade -y
-          apt install -y curl tar p7zip-full python3.11 pip pipx
+          apt install -y curl tar p7zip-full python3.12 pip pipenv
       -
         name: Install pipenv, build blog...
         env:
           PIPENV_USER: ${{ secrets.REGISTRY_USERNAME }}
           PIPENV_PASS: ${{ secrets.REGISTRY_TOKEN }}
         run: |
-          pip install pipenv
           pipenv install
           pipenv run blag build
       -

Pipfile

@@ -9,10 +9,10 @@ verify_ssl = true
 name = "gitea"
 
 [packages]
-blag = {version = "==2.4.0", index = "gitea"}
+blag = {version = "==2.4.2", index = "gitea"}
 pymdown-extensions = {version = "==10.9", index = "pypi"}
 
 [dev-packages]
 
 [requires]
-python_version = "3.11"
+python_version = "3.12"

content/2024/01/17/post-01.md

@@ -4,16 +4,6 @@ Date: 2024-01-17 10:28
 Tags: personal, gitops, devops, technical
 Edited: 2024-09-27 13:50
 
-# Table of Contents <!-- omit in toc -->
-
-- [A new post for a new blog](#a-new-post-for-a-new-blog)
-- [Fixing that old mess](#fixing-that-old-mess)
-- [Static Site Generation](#static-site-generation)
-  - [Using blag](#using-blag)
-  - [Automation](#automation)
-- [Conclusion](#conclusion)
-
-
 # A new post for a new blog
 
 This is a personal project built... because i can. I have this odd fascination with the concept of `gitops` - that is, keeping entire codebases + their documentation within a single self-contained git repository. I also have an interest in self-hosting my own services/infrastructure because it gives me a better fundamental understanding of the hardware/software behind things like `GitHub Actions`. Thus, instead of being run/deployed with any number of cloud services, i've done my best to self-host my own stuff.

content/2024/01/18/baja-tacos.md

@@ -3,21 +3,6 @@ description: Some seafood tacos.
 tags: cooking, recipes
 date: 2024-01-19 05:59
 
-# Table of Contents <!-- omit in toc -->
-
-- [Baja Tacos](#baja-tacos)
-  - [Ingredients](#ingredients)
-    - [Fresh](#fresh)
-    - [Spices](#spices)
-    - [Protein](#protein)
-  - [Directions](#directions)
-    - [Prep](#prep)
-    - [Slaw](#slaw)
-    - [Sauce](#sauce)
-    - [Rub](#rub)
-  - [Assemble](#assemble)
-
-
 # Baja Tacos
 
 ## Ingredients

content/2024/01/18/cheesecake-recipe.md

@@ -4,15 +4,6 @@ tags: baking, cooking, cheesecake, recipes
 date: 2024-01-18 12:05
 edited: 2024-09-27 13:52
 
-# Table of Contents <!-- omit in toc -->
-
-- [New York style cheesecake](#new-york-style-cheesecake)
-   - [Ingredients](#ingredients)
-      - [For the Crust](#for-the-crust)
-      - [For the Filling](#for-the-filling)
-   - [Directions](#directions)
-      - [How to Slice Cheesecake](#how-to-slice-cheesecake)
-
 # New York style cheesecake
 
 Shamelessly stolen from [martha stewart dot com](https://www.marthastewart.com/865202/new-york-style-cheesecake). Thanks `Lucinda Scala Quinn` for a great recipe!

content/2024/01/18/increasing-complexity.md

@@ -4,12 +4,6 @@ tags: technical, gitops, devops
 date: 2024-01-18 01:09
 edited: 2024-09-27 13:52
 
-# Table of Contents <!-- omit in toc -->
-
-- [Increasing Complexity](#increasing-complexity)
-- [Actually doing the thing](#actually-doing-the-thing)
-    - [Getting my fork on my package repo](#getting-my-fork-on-my-package-repo)
-
 # Increasing Complexity
 
 __START TIME: 2024-01-18 01:09__

content/2024/01/31/mediterranean-rice.md

@@ -3,14 +3,6 @@ description: A very tasty rice and veggies recipe.
 tags: cooking
 date: 2024-01-31 18:45
 
-# Table of Contents <!-- omit in toc -->
-
-- [Mediterranean style rice](#mediterranean-style-rice)
-  - [Ingredeints](#ingredeints)
-    - [Spices](#spices)
-    - [Cooking fat](#cooking-fat)
-  - [Cooking instructions](#cooking-instructions)
-
 # Mediterranean style rice
 
 This recipe is inspired by a rice dish served by a mediterranean restaurant I used to go to in my hometown.

content/2024/09/06/2024090601.md

@@ -3,13 +3,6 @@ tags: servers, server layout, gitops, devops
 date: 2024-09-06 03:27
 edited: 2024-09-27 13:53
 
-# Table of Contents <!-- omit in toc -->
-
-- [Some changes have ocurred](#some-changes-have-ocurred)
-- [Pi os](#pi-os)
-- [How I do gitops](#how-i-do-gitops)
-- [How the deployment server works.](#how-the-deployment-server-works)
-
 # Some changes have ocurred
 
 Server layout has undergone some changes, most notably:
@@ -18,7 +11,6 @@ Server layout has undergone some changes, most notably:
 - how i do gitops
 - how the deployment works
 
-
 # Pi os
 
 I needed docker on my pi, so i abandoned freebsd. It was a good run and taught me a lot about unix. But implementing a custom freebsd server is just. not my thing anymore. Docker is so much easier for versioning. And if i want to compile from scratch? I have that option, too, with docker.

content/2024/09/26/configuration-management.md

@@ -4,13 +4,6 @@ tags: post, git, gitops, devops, cicd, tech, scripting
 date: 2024-09-26 05:21
 edited: 2024-09-27 13:53
 
-# Table of Contents <!-- omit in toc -->
-
-- [Managing homeserver configs](#managing-homeserver-configs)
-- [So how do I do things?](#so-how-do-i-do-things)
-- [conclusion](#conclusion)
-
-
 # Managing homeserver configs
 
 I've run my home services a number of different ways over the years. I've split things between multiple virtual machines, I've set up a 'bare metal ' kubernetes cluster distributed between multiple VMs and hardware devices on my home network. I've used FreeBSD and its Jails to run things I compiled by scratch in an effort to lower attack surface. I ran (and run) VMs and containers on proxmox, truenas core and truenas scale. Each method brings its pros & cons, security tradeoffs, and configuration complexity. Though I've practiced more complex enterprise-level user & permission management (ldap/active directory) techniques, I've settled on "good enough" security practices for my uses/needs (I don't have multiple people accessing things over ssh, for example, so I do the unthinkable and - gasp - ssh directly into root with an ed25519 keypair to administer servers). No SSH ports are exposed directly to the internet anyway - well, except for gitea. But that's also protected with keypairs.

content/2024/09/27/scripts-with-passwords-revisited.md

@@ -3,14 +3,6 @@ description: Another look at my entry from 12th May, 2024 where I explore a meth
 tags: security, scripting, unix, linux
 date: 2024-09-27 12:11
 
-# Table of Contents <!-- omit in toc -->
-
-- [Revisiting an old topic](#revisiting-an-old-topic)
-- [The process](#the-process)
-  - [Obfuscation](#obfuscation)
-  - [Deobfuscation](#deobfuscation)
-- [Conclusion](#conclusion)
-
 # Revisiting an old topic
 
 [In this blog entry dated 12th May, 2024](https://blog.raer.me/2024/05/01/20240512.html) I discuss a method where I'm able to keep passphrases stored inside of a bash script, while still being able to execute the bash script. Its been a few months and I've improved the process for obfuscating/deobfuscating scripts, since I'm now using this method as part of my process in writing/editing backup scripts. Thus I'd like to retouch the topic since rereading the previous blogpost leaves me a bit undersatisfied.

content/2025/09/10/blog-entry-192851.md

@@ -0,0 +1,39 @@
+title: An annoying issue with gitea
+description: messing around with gitea stuff gets me into a wild goose chase.
+tags: devops, gitea, sysadmin
+date: 2025-09-10 19:28
+
+# An annoying issue with gitea
+
+Had this really frustrating issue today with gitea that I ultimately discovered was caused by a stale gpg lock file residing in a place I didn't expect.
+
+It started out with me creating some orgs to better manage my personal forks. I have a few repositories that are forks of things from github, but not reflected as such in gitea. I started by making an org for github.com, migrating the repos there, renaming and archiving my copies, forking the repos to my gitea user, then pushing my local copy back to gitea. This allows me to maintain a local mirror of the github copy, and link to it as a fork in gitea. Pure semantics, honestly.
+
+However there was this big issue when trying to view commit graphs on anything I've forked: I would ultimately get a timeout error & no page. Some prodding revealed gitea throwing this error multiple times before timeout:
+
+```
+2025/09/11 02:10:12 ...mmit_verification.go:229:ParseCommitWithSignature() [E] Error getting default signing key: ******** unable to get default signing key: ********, gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: WARNING: nothing exported
+gpg: key export failed: Operation timed out
+, exec(68c22f7a-13:gpg -a --export) failed: exit status 2(<nil>) stdout:  stderr: gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: Note: database_open 134217901 waiting for lock (held by 1502) ...
+gpg: WARNING: nothing exported
+gpg: key export failed: Operation timed out
+```
+
+Some cursory web searches showed that this wasn't something other people have encountered. Then a bit of about the error revealed that this was caused by a stale lock file. Simple enough, I thought. So I navigate to my gitea instance's data directory. I delete `data/git/.gnupg/public-keys.d/pubring.db.lock` only to STILL have the issue. WTF???
+
+So after some more searching and using chatgpt... I find from some github issue that there's a second `.gnupg` dir!!! Seems that gitea uses gnupg in two different contexts requiring two gnupghome directories. Neat. Cool. Awesome.
+
+So finally, I delete `data/gitea/data/home/.gnupg/public-keys.d/pubring.db.lock` and BADDA BING BADDA BOOM! BOBS UR AUNTIE! Problem solved!
+
+Sigh. What a waste of the last hour or so of my life. 'least the issue is fixed and I can view commit graphs again! Somehow, this also fixed a load time issue when loading mirror repos. It should also fix a long standing issue I had with merging pull requests on gitea's webui!
+
+- Freyja (2025-09-10 19:41)

content/2025/11/13/blog-entry-135625.md

@@ -0,0 +1,256 @@
+title: The FHS spec
+description: Notes taken by me on the Unix Filesystem Hierarchy Standard.
+tags: unix, linux, notes, general
+date: 2025-11-13 13:56
+
+# FHS
+
+These are my FHS spec notes from 2024-06-26, uploaded here (nostly so my gf can read it, hi Jamie! :D)
+
+The File Hierarchy Standard is a unix standard defining the minimal required directory hierarchy for a functional, portable, distributable filesystem. Distributable refers to the ability to store certain directories on other devices, mounted to the root directory. These can include /var, /etc, /home, /usr, /boot...
+
+- bin+
+- boot
+- dev
+- etc
+- lib+
+- media
+- mnt
+- opt
+- run
+- sbin+
+- srv
+- tmp
+- usr*
+- var*
+
+(* indicates complex directories)
+(+ indicates a directory that is usually a symbolic link for one inside /usr)
+
+## Table of Contents <!-- omit in toc -->
+
+- [FHS](#fhs)
+  - [Prologue](#prologue)
+  - [(/usr)/bin](#usrbin)
+  - [/boot](#boot)
+  - [/dev](#dev)
+  - [/etc](#etc)
+  - [/home (Optional, apparently. lol)](#home-optional-apparently-lol)
+    - [User mounted stuff](#user-mounted-stuff)
+    - [/home summary](#home-summary)
+  - [(/usr)/lib](#usrlib)
+  - [/media](#media)
+  - [/mnt](#mnt)
+  - [/opt](#opt)
+  - [/root (optional)](#root-optional)
+  - [/run](#run)
+  - [(/usr)/sbin](#usrsbin)
+  - [/srv](#srv)
+  - [/tmp](#tmp)
+  - [/usr](#usr)
+  - [/var](#var)
+  - [Backup strategies](#backup-strategies)
+    - [Example backup strategy](#example-backup-strategy)
+  - [Configuration management strategies](#configuration-management-strategies)
+  - [When do I do things in /opt???](#when-do-i-do-things-in-opt)
+
+## Prologue
+
+I have a bug up my ass about studying the hierarchical directory system used on Linux and other unix-like computer systems. I think its a good idea to study things which we interact with and take for granted, in detail. This is something I implement as sort of a general philosophy of life lately. Thus, it has crept into my ongoing studies into computer science. Hence these notes on the FHS and how I can better conform to this standard so as to improve the fluidity of my workflow managing multiple home servers.
+
+## (/usr)/bin
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html)
+
+Binary files. The basic commands installed on your system. These are things like `rm`, `sudo`, `cp`, `mv` and more. This is usually a symbolic link to /usr/bin.
+
+__ruleofthumb__ though it is standard for /bin to exist as a symbolic link, when doing a shebang to something in this dir I like to use the *real* directory `/usr/bin`.
+
+Historically, this has been *separate from /usr/bin*. However, I think it makes more sense in this day-and-age to conform to a variation of the FHS where /bin is a symlink, since it allows /usr to be *unified system resources*.
+
+## /boot
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s05.html)
+
+This is the boot partition. The bootloader and its various config files reside here, as well as the kernel.
+
+## /dev
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s06.html)
+
+`/dev` is where device files reside. These are special files which refer to hardware (or virtual devices) made accessible to the system via drivers.
+
+## /etc
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html)
+
+Configuration files for the host system. `/etc/opt` should contain config files for apps installed to `/opt`
+
+## /home (Optional, apparently. lol)
+
+FHS doesn't officially standardize *shit* within a user home directory. They specify this, which I find useful:
+
+- "To find a user's home directory, use a library function such as getpwent, getpwent_r of fgetpwent rather than relying on /etc/passwd because user information may be stored remotely using systems such as NIS." [source](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html)
+
+Anyway, here are some standard conventions which I see employed in user home directories - and some ideas I have about how users' home directories *should be dealt with*.
+
+- In systems with DEs, you'll see capitalized directories called `Documents, Downloads, Music, Pictures, Videos`. These hold... what they say they hold. I like to use them as-is. KDE likes to include something called `Templates` which I've never used, or seen used, so I just delete it.
+- `~/bin/` for user-installed binaries or scripts. This is usually defined on the user's PATH variable so they may stick scripts in here for quick execution from their account, without having to stick them in `/usr/`.
+  - I have a tendency to keep my scripts inside of `~/Documents/git/freyjagp/scripts/` because that is a git repo, and I keep my git repos there. Nonetheless, many tools that a user installs may install binaries/scripts in here. Or, into, as we'll describe below....
+- `~/.{TOOL}/` - Many tools will create a hidden directory inside of the home directory for storing config data local to the tool's user. I'm going to think of this as a sort of personal workbench, as opposed to `/usr/bin/` or the like, which are like a community workshop.
+- `~/.config/` *many* user applications will store their configuration files here. Anything that's intended to be run by the user, not as a system-critical program, likes to store configs either here, or `~/.local/share/`.
+- `~/.local/` is similar to `/usr/local` in structure? In practice, I find it to be an inconsistently used place to store stuff that would otherwise be chucked in `~/.config/` or `~/bin/` or `~/.{TOOL}/` directories. It was - I suppose, at some point - supposed to unify how things are done in a `/home/user/` directory but... *sigh*.
+- Other misc. files, such as users' rc files for shells, or shell histories, or somesuch, are also stored in here.
+
+### User mounted stuff
+
+Stuff that's mounted for the user automatically is usually done in `/run/user/...` and having read the standard, this makes sense. Its a runtime mount managed by software since the `/run` dir *should be* cleared on shutdown like `/tmp`.
+
+Anything else that's mounted for the user's usage (and not for the system to have access to) should be mounted to `~/.mnt`. Else, stuff mounted for use by the system (variable or otherwise) should be mounted at `/var/nfs/...` or similar - not `/srv` since `srv` should be for things that are *publically accessible*. Staticfiles, usually.
+
+### /home summary
+
+Basically, `/home/user` stores anything a system user would want to keep backed up should shit hit the fan. It might be *convenient* to maintain backups of the whole system. But what *really matters* is the `/home` dir (to a basic user, at least).
+
+## (/usr)/lib
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s09.html)
+
+Shared libraries and kernel modules. Stuff used by the OS and kernel to make code work properly, to compile stuff written in C/C++, etc.
+
+## /media
+
+[Reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html)
+
+Media on removable devices. Most commonly USB (though, many linux distributions use software that will mount removable media to /run/media/{USER}). Not really used, though, in my opinion.
+
+## /mnt
+
+Temporary mountpoints. So using this for a quick `mount -t nfs ...` isn't a bad idea. But for something in `/etc/fstab` I should actually be mounting to something like `/srv`, `/home/{USER}`, or `/var`. This isn't so much a *universal mountpoint for things that aren't system mounts* but moreso a place for a user or administrator to mount devices in a pinch.
+
+## /opt
+
+Applications/software packages. This blurb explains it better than I unerstand it at the time of writing:
+
+```text
+
+
+    This directory is reserved for all the software and add-on packages that are not part of the default installation. For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here. To comply with the FSSTND, all third party applications should be installed in this directory. Any package to be installed here must locate its static files (ie. extra fonts, clipart, database files) must locate its static files in a separate /opt/'package' or /opt/'provider' directory tree (similar to the way in which Windows will install new software to its own directory tree C:\Windows\Progam Files\"Program Name"), where 'package' is a name that describes the software package and 'provider' is the provider's LANANA registered name.
+
+    Although most distributions neglect to create the directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man they are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the system administrator, but must function normally in the absence of these reserved directories. Programs to be invoked by users are located in the directory /opt/'package'/bin. If the package includes UNIX manual pages, they are located in /opt/'package'/man and the same substructure as /usr/share/man must be used. Package files that are variable must be installed in /var/opt. Host-specific configuration files are installed in /etc/opt.
+
+    Under no circumstances are other package files to exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files in /var/lock and devices in /dev. Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
+
+    The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.
+
+    Generally, all data required to support a package on a system must be present within /opt/'package', including files intended to be copied into /etc/opt/'package' and /var/opt/'package' as well as reserved directories in /opt. The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution installed and locally installed software, especially in the case of fixed pathnames found in some binary software.
+
+    The structure of the directories below /opt/'provider' is left up to the packager of the software, though it is recommended that packages are installed in /opt/'provider'/'package' and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/ 'provider'/lib or /opt/'provider'/bin.
+
+
+```
+
+[source^](https://askubuntu.com/questions/982589/why-should-i-be-installing-my-applications-in-the-opt-location)
+
+after reading the blurb, I understand that opt functions this way:
+
+It can look like this:
+
+- /opt
+  - /bin
+  - /doc
+  - /include
+  - /info
+  - /lib
+  - /man
+
+These are reserved for system admin usage. They should store (if they are used) *copies or symlinks* to stuff inside of `/opt/{PACKAGE}/[bin,doc,include,info,lib,man]`. That's a little complex so I'll just stick to `/opt/{PACKAGE}/...`
+
+`/var/opt` and `/etc/opt` can also serve variable and config files respectively, for applications stored in opt (as opposed to /opt/{PACKAGE}/[etc,var])
+
+In general, though, anything for an application installed to `/opt` to work should be stored inside `/opt/{PACKAGE}/...`
+
+Another valid option is `/opt/{PROVIDER}/{PACKAGE}` but I'll prolly ignore that one.
+
+## /root (optional)
+
+The root user's folder.
+
+## /run
+
+["This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process."](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html)
+
+This is where things like sockets, or ["data relavent to running processes"](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s02.html) are kept.
+
+__`/run` should not be writable for unprivileged users; it is a major security problem if any user can write in this directory. User-specific subdirectories should be writable only by each directory's owner.__
+
+## (/usr)/sbin
+
+[Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [18] Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin. [19]](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html)
+
+System binaries. Stuff used by the root user to do administrative and or system things.
+
+## /srv
+
+I think taticfiles should be served from here. On my nginx server, instead of doing `/var/www/bjongbeuf.com/{NFS-MOUNT}` or `/mnt/httpserve/bjongbeuf.com/{NFS-MOUNT}` I should just be doing `/srv/bjongbeuf.com/{NFS}`. I suppose, that this shouldn't even necessairily be limited to nfs. This should just have *anything* that's being *served to the public* (which in this day-and-age means files served over http). In my opinion, most linux distros do this wrong and it, quite frankly, makes sense for things that are being served to the public to be here. Sure they *can be* variable. But /var is better for shit like logs, in my opinion.
+
+Funny enough, the standard agrees with me (I hadn't actually read it at the time of writing above paragraph). See [here](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html).
+
+There's no standard for how things should be kept here. So I'll probably just do it as I see fit until I settle upon something. For now, I'm thinking something like `/srv/{domain-name}/` since I mostly only serve static files from http anyway, it wouldn't really make sense to put them somewhere like `/src/http/...`.
+
+## /tmp
+
+Temporary files baby. Anything that you don't mind being lost or cleaned up at some point after you're done with it. Some things also put sockets here for some reason.
+
+## /usr
+
+[reference](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html)
+
+This boi is complex, but I think I can boil it down to a couple of simple things. We've already gone over some of the contents of `/usr` with `/bin` and `/sbin` and `/lib`. `/usr` is also meant to hold other directories for system purposes such as `include` and `share` and `libexec`. These aren't terribly important to know off the top of your head. Only that stuff in here that's *not* in the `/usr/local` is intended to be *installed and managed by the system*. If you're manually sticking something in `/usr/bin` it should be to update an existing package. Otherwise, `/usr/local/bin` should be used, as `/usr/local` is reserved for administration by the system administrator.
+
+## /var
+
+Var is kind of... where we chuck things that change with the system as time goes on, that must be stored, that aren't config files, or static files, or what-have-you. Logs, spools, mailboxes, and the like. Officially, you aren't supposed to do what I do - making apps store things here. But I'm going to do it anyway, because I need to for configuration management.
+
+Anyway, the things of note in here are `/var/log` `/var/mail`. And for my purposes, `/var/gitlocal`.
+
+## Backup strategies
+
+A simple backup strategy employed by - I'd wager - most users (at least by myself) is to simply `rsync` (or something else, in my case I use `borg`) the entire `/home/user` directory. This works if all you care about on the system is your userdata. What if the rest of the system isn't quite so expendable? What if you're serving html content from `/srv/example.com` that isn't on an nfs share? What if you've installed binaries from external sources (or compiled them yourself)?
+
+Well, we want to consider backing up other folders, then.
+
+There's not going to be a one-size-fits-all solution here but I'll try to generalize...
+
+### Example backup strategy
+
+A basic strategy would consider backing up all of:
+
+- `/boot`
+- `/home`
+- `/srv`
+- `/var`
+- `/root`
+- `/etc`
+- `/opt`
+- `/usr/local`
+
+A more efficient strategy might try to consider *what exactly do we want to keep from these and why*. It might also discard some directories entirely depending on whether we use them.
+
+(I kinda thought I was cooking here but I wasn't lol).
+
+## Configuration management strategies
+
+Git, git, git, git, git. Git is god here. but *how*?
+
+I'm going to attempt to, finally, devise a configuration management strategy that incorporates git, is scriptable, and compliant with FHS.
+
+Configs are stored in `/etc` and `/usr/local/etc`. On any system I manage, this will be so - EXCEPT with things that run as docker containers, those will use `/opt` and I'll explain why later.
+
+`/etc` and `/usr/local/etc` should each be initialized as git repositories on system initialization. Then, we create *bare git repositories* at `/var/gitlocal/etc.git` and `/var/gitlocal/usr_local_etc.git`. Optionally, we create (or import) a gpg key for the root account to use for signing git commits. Commits are pushed to, at a minimum, the bare git repos mentioned earlier. Any backup strategy employed on a system using version control under this configuration management strategy, must include at *least* `/var/gitlocal`, allowing configuration files to be version controlled and backed up.
+
+## When do I do things in /opt???
+
+The only case I see myself using `/opt` is when I'm deploying docker containers. Binaries installed to the system, but compiled by the sysadmin (such as how I implement nginx) should be installed/configured to `/usr/local/bin` and `/usr/local/etc` respectively. It might make sense to install them to `/opt` at first glance... but I see `opt` as more of a place to keep application binaries and data in one location should you want to do that. In my use-case, I like to avoid dealing with PVE volumes for any sort of configuration or permanent data stored by a docker container. Sometimes I want to poke around in that data, and a PVE is simply too god-damned inconvenient to deal with. They have their usecases, but *not* as persistent data stores in my environments. Therefore, `/opt` is the perfect candidate for my usecase. It has a loosely defined structure that allows me to do things like throwing a valheim server into a directory called `/opt/valheim` with a docker-compose.yml and its own `./etc` and `./var` dirs.
+
+Note that there are optionally defined structures for `/opt` that include symlinking things to `/opt/bin` and using `/etc/opt` and `/var/opt` however I see these as obsolete and unnecessary. A refined standard in my opinion would remove these as options, sticking to opt as a place like I'm using here.

content/love.md

@@ -1,6 +1,6 @@
 title: My lover
 description: Hello love
 
-# To my lover, Jaimie
+# To my lover, Jamie
 
 I love you very much, babydoll. <3 you bring me so much joy and happiness when we're together.

entry

@@ -0,0 +1,50 @@
+#!/usr/bin/env python3
+
+import os
+from datetime import datetime
+
+# Get the current date and time
+now = datetime.now()
+year = now.strftime("%Y")
+month = now.strftime("%m")
+day = now.strftime("%d")
+time_str = now.strftime("%H:%M")
+time_str_sec = now.strftime("%H%M%S")
+
+
+
+if str(day).endswith("1"): suffix = "st"
+elif str(day).endswith("2"): suffix = "nd"
+elif str(day).endswith("3"): suffix = "rd"
+else: suffix = "th"
+
+
+
+# Create the directory structure
+directory = os.path.join("content", year, month, day)
+os.makedirs(directory, exist_ok=True)
+
+# Define the filename
+filename = f"blog-entry-{time_str_sec}.md"
+file_path = os.path.join(directory, filename)
+
+print(file_path)
+
+
+HEADER = f'''title:
+description:
+tags:
+date: {year}-{month}-{day} {time_str}
+
+# Blog Entry
+
+'''
+
+
+# Create the Markdown file and write the header
+with open(file_path, 'a+') as file:
+    header = HEADER
+    file.write(header)
+    file.close()
+
+print(f"Blog entry created: {file_path}")

templates/base.html

@@ -39,10 +39,10 @@
     </main>
 
     <footer>
-      Copyleft 🄯 Freyja R. L. Odinthrir 2024 all wrongs reserved.
+      <a href="/copyright.html">Copyleft 🄯 2024 Freyja R. L. Odinthrir "All Wrongs Reversed"</a>
+      <br>
       Subscribe to the <a href="/atom.xml">atom feed</a>.
       <br>
-      Copyright
       <!-- Contact me via
         <a rel="me" href="https://mastodon.social/[FIXME]">[FIXME] Mastodon</a> or
         <a href="https://github.com/[FIXME]">[FIXME] Github</a>.