diff options
19 files changed, 606 insertions, 23 deletions
diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..d909803 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,8 @@ +FROM alpine + +RUN apk add --no-cache hugo + +WORKDIR /usr/src +COPY . . + +CMD [ "hugo", "serve", "--baseURL", "https://www.tyil.nl","--bind", "::" ] diff --git a/content/posts/2018/2018-05-07-sparrowdo-getting-started.md b/content/posts/2018/2018-05-07-sparrowdo-getting-started.md index fa458c4..419e98d 100644 --- a/content/posts/2018/2018-05-07-sparrowdo-getting-started.md +++ b/content/posts/2018/2018-05-07-sparrowdo-getting-started.md @@ -210,7 +210,7 @@ sparrowdo --local_mode {{< admonition title="note" >}} If you want to run this on a remote machine to configure that one instead, you can use `--host=<ip>` instead of `--local_mode`. -{{< admonition >}} +{{< / admonition >}} You can check whether it actually worked by inspecting the files in `/etc/dnsmasq.d` and your `/etc/resolv.conf`. The easiest way to check their diff --git a/content/posts/2023/2023-05-23-bashtard-2.0.0.md b/content/posts/2023/2023-05-23-bashtard-2.0.0.md index 3fc253b..654435f 100644 --- a/content/posts/2023/2023-05-23-bashtard-2.0.0.md +++ b/content/posts/2023/2023-05-23-bashtard-2.0.0.md @@ -1,5 +1,4 @@ --- -draft: true date: 2023-05-23 title: Bashtard v2.0.0 tags: diff --git a/content/posts/2023/2023-07-13-getting-emoji-to-work-in-kde-on-debian.md b/content/posts/2023/2023-07-13-getting-emoji-to-work-in-kde-on-debian.md new file mode 100644 index 0000000..a5b0980 --- /dev/null +++ b/content/posts/2023/2023-07-13-getting-emoji-to-work-in-kde-on-debian.md @@ -0,0 +1,138 @@ +--- +date: 2023-07-13 +title: Getting Emoji to Work in KDE on Debian +tags: +- Debian +- GNU+Linux +- KDE +--- + +This is going to be a relatively short and uninteresting post for most, it'll +just document how to get emoji to work in KDE. + +While it will work with most applications out of the box, this doesn't appear to +work in Qt applications by default, including the notification panel. As I use +my notifications for messages I get from my work chat, and I dislike seeing the +squares, I set out to find the solution. I've had to string together a couple +sources of information to get to the correct setup, and this blog post intends +to show just the useful bits. So here goes! + +You'll need an emoji font (in my case `fonts-noto-color-emoji`), add two +configuration files for fontconfig, rebuild the fontconfig cache, and most +likely log out and back into KDE. Installing the emoji font is probably the easy +bit and won't need any additional explanation I hope. So let's get started on +the first configuration file, which will enable the Noto emoji font to be used, +and also force it to be used in favour of other emoji fonts if any application +was using that specifically. I have it saved as +`/etc/fonts/conf.d/75-noto-color-emoji.conf`. + +```xml +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE fontconfig SYSTEM "fonts.dtd"> +<fontconfig> + <!-- Add generic family. --> + <match target="pattern"> + <test qual="any" name="family"><string>emoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + + <!-- This adds Noto Color Emoji as a final fallback font for the default font families. --> + <match target="pattern"> + <test name="family"><string>sans</string></test> + <edit name="family" mode="append"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test name="family"><string>serif</string></test> + <edit name="family" mode="append"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test name="family"><string>sans-serif</string></test> + <edit name="family" mode="append"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test name="family"><string>monospace</string></test> + <edit name="family" mode="append"><string>Noto Color Emoji</string></edit> + </match> + + <!-- Block Symbola from the list of fallback fonts. --> + <selectfont> + <rejectfont> + <pattern> + <patelt name="family"> + <string>Symbola</string> + </patelt> + </pattern> + </rejectfont> + </selectfont> + + <!-- Use Noto Color Emoji when other popular fonts are being specifically requested. --> + <match target="pattern"> + <test qual="any" name="family"><string>Apple Color Emoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Segoe UI Emoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Segoe UI Symbol</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Android Emoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Twitter Color Emoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Twemoji</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Twemoji Mozilla</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>TwemojiMozilla</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>EmojiTwo</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Emoji Two</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>EmojiSymbols</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> + <match target="pattern"> + <test qual="any" name="family"><string>Symbola</string></test> + <edit name="family" mode="assign" binding="same"><string>Noto Color Emoji</string></edit> + </match> +</fontconfig> +``` + +The second configuration file, saved as `/etc/fonts/conf.d/local.conf`, simply +adds the Noto emoji font as a fallback. This enables the use of it when an emoji +is going to be rendered. + +```xml +<?xml version='1.0'?> +<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> +<fontconfig> + <match target="pattern"> + <edit name="family" mode="append"> + <string>Noto Color Emoji</string> + </edit> + </match> +</fontconfig> +``` + +And after this, a relog of your (graphical) session should be all that is needed +in order to make it work. You can easily test it with `notify-send`, or trying +to render some emoji in `konsole`. diff --git a/content/posts/2023/2023-07-24-new-server-rack-mieshu.md b/content/posts/2023/2023-07-24-new-server-rack-mieshu.md new file mode 100644 index 0000000..f024784 --- /dev/null +++ b/content/posts/2023/2023-07-24-new-server-rack-mieshu.md @@ -0,0 +1,89 @@ +--- +date: 2023-07-23 +title: "My New Server Rack: Mieshu" +tags: +- GNU+Linux +- Gentoo +- Systemd +- Garage +--- + +After saving up for a long while and thinking about what I want in my new home, +I have finally taken the leap and gotten myself a server rack for home use. Its +has a 15U capacity, which should be plenty to get started, but this same brand +has larger racks too, in case I do want to upgrade it and keep the same style. + +That said, for now there's only two 4U units in them, one for (file) storage, +and one for database purposes. I sadly don't have anything dedicated for +workloads yet, so for now, both of these servers are intended to also run some +light workloads. I haven't made my mind up yet on how to solve the workload +issues. Now that I have a rack, I obviously want something rack-mountable, and +I probably want it to run a Kubernetes cluster too. + +In this regard, I _could_ go for a set of [Raspberry Pi](https://www.raspberrypi.com/) +units, there's [3U mounts that can hold up to 12 Raspberry Pi machines](https://www.uctronics.com/uctronics-19-inch-3u-rack-mount-for-raspberry-pi-4-with-8-mounting-plates.html), +which would be a nice amount. However, I am not yet completely sold on full-ARM +workloads, and I'm not entirely convinced of the power of Raspberry Pi units in +general. I'd much rather standardize on another brand, [Odroid](https://www.hardkernel.com/), +as they have more types of units available, and are not limited to just ARM. But +since they're not the popular kid in class, there's very few off-the-shelf +rack mounting equipment for it. I'll be thinking about this for just a bit more +before making a decision. + +For now, though, I wanted to talk about the setup of the first server, Mieshu, +who will be used as a storage server. Mieshu currently runs 8 HDDs, and 2 NVMe +drives. One of the NVMe drives is used for the rootfs, and the other is used for +caching in certain applications. The HDDs themselves offer the data storage +capacity. + +The HDDs are currently comprised of four 16TB drives, and four 8TB drives. The +smaller disks come from my desktop, Edephas, which used to serve as data storage +until Mieshu took over. All disks are configured into pairs, which themselves +make mirrors. This means I have four sets of mirror pools, two times 16TB, and +two times 8TB, for a total of 48TB of storage. I'm currently using about half of +this, and it should give me plenty of time before needing to increase the size +again. + +I chose to use mirrors since it has a good chance of your data being recoverable +on disk failure, and it allows me to buy disks per two, rather than in larger +numbers. This hopefully keeps the cost of expansion within reasonable limits. +The mirrors themselves are currently [ZFS](https://openzfs.org/wiki/Main_Page) +pools, but I hope to be able to use [bcachefs](https://bcachefs.org/) very soon +as well. + +Just a bunch of mirrors is rather inconvenient, however, so I'm also leveraging +[MergerFS](https://github.com/trapexit/mergerfs) to combine all the mirrors into +a single usable pool. This slightly odd setup was chosen over RAID-0 or RAID-Z* +to lower the impact of disk failure. Even if two disks in the same mirror were +the die at the same time, I wouldn't lose _all_ data, just the bits on that +particular mirror. It would be very annoying, but it wouldn't be disastrous. + +Apart from generic mass storage, I also host S3 buckets for personal use. This +is where I upload CI artifacts to, and [my MissKey instance](https://fedi.tyil.nl/@tyil) +uses it for storing objects as well. Future services such as [Mimir](https://grafana.com/oss/mimir/) +will probably leverage S3 for storage as well. This is achieved through +[Garage](https://garagehq.deuxfleurs.fr/). I've also tried [SeaweedFS](https://seaweedfs.github.io/), +which is a very neat project on its own, but Garage is just simpler to +configure, and allows a replicated setup with only two servers, whereas SeaweedFS +demands an odd number of master servers. + +And lastly, Mieshu runs [K3s](https://k3s.io/) for its Kubernetes component. It +is currently not serving anything yet, as the other server is supposed to become +the database server, which is needed for most workloads. Once that is up and +running, Mieshu will start hosting things such as +[Grafana](https://grafana.com/oss/grafana) and [Loki](https://grafana.com/oss/loki/), +monitoring stuff basically. Perhaps I'll move [Laminar](https://laminar.ohwg.net/) +to this server as well, but I'm unsure if I will run that as a Kubernetes service. + +The server itself runs on Gentoo, as it still is the most stable experience I +can get out of any GNU+Linux distribution. I am, however, not using the default +of OpenRC as the init system and service manager. For the first time, I'm +running Gentoo with systemd. After several years, it appears to have become +stable enough to trust with serious workloads. With its increased use, however, +some things have become simpler by just using systemd. I hope to get a better +understanding of it, and learn to bend it to my will as needed, by simply using +it on my own systems. + +I hope to have time to work on the other server sooner rather than later, so +I can finish up the base of my new setup. Be on the lookout for the next post, +where I'll go into detail on Nouki, the database server. diff --git a/content/posts/2023/2023-08-05-new-server-rack-nouki.md b/content/posts/2023/2023-08-05-new-server-rack-nouki.md new file mode 100644 index 0000000..fbbc326 --- /dev/null +++ b/content/posts/2023/2023-08-05-new-server-rack-nouki.md @@ -0,0 +1,88 @@ +--- +date: 2023-08-05 +title: "My New Server Rack: Nouki" +tags: +- GNU+Linux +- Gentoo +- PostgreSQL +- Prometheus +- Systemd +- ZFS +--- + +After setting up [mieshu](/post/2023/07/23/my-new-server-rack-mieshu/), nouki is +the next server to work on in my home rack. Nouki is intended to live as my main +database server, mainly for PostgreSQL, but perhaps later on in life MySQL if I +ever want a service that doesn't support superiour databases. + +The setup for nouki is much simpler in that regard, the base system is almost +identical. This server has ZFS with 2 NVMe disks running in a mirror +configuration. It is also a Gentoo based system, and again with systemd rather +than openrc. The experience of systemd with mieshu was much less painful than I +anticipated. It would seem that it has had time to mature, though I still +dislike how it kills diversity in init/service managers on GNU+Linux. + +Both PostgreSQL and ZFS have received some tweaking to run more smoothly. I'm no +DBA, so if you see anything silly in here, do let me know so I can improve my +life. + +For ZFS, tweaking was rather minimal. I've made a seperate dataset for +PostgreSQL to use, with `recordsize=8K` as option. For PostgreSQL, I've altered +a bit more. First and foremost, the `pg_hba.conf` to allow access from machines +in my tinc-based VPN. + +```conf +host all all 10.57.0.0/16 scram-sha-256 +``` + +The `postgresql.conf` file received the following treatment, based solely on the +guidance provided by [PGTune](https://pgtune.leopard.in.ua/). + +```conf +listen_address = 10.57.101.20 +max_connections = 200 +shared_buffers = 8GB +effective_cache_size = 24GB +maintenance_work_mem = 2GB +checkpoint_completion_target = 0.9 +wal_buffers = 16MB +default_statistics_target = 100 +random_page_cost = 1.1 +effective_io_concurrency = 200 +work_mem = 5242kB +min_wal_size = 1GB +max_wal_size = 4GB +max_worker_processes = 12 +max_parallel_workers_per_gather = 4 +max_parallel_workers = 12 +max_parallel_maintenance_workers = 4 +``` + +With this, PostgreSQL seems to perform very well on this machine, applications +using it are noticably faster. Sadly I have no timings from when it all ran on +my desktop, so I cannot make an exact statement on how much faster everything +has become. + +Additionally, I wanted to start gathering metrics of my machines and services, +so I can start thinking about dashboards and alerts. I've chosen to use the +current industry standard of Prometheus for this. Since I consider Prometheus to +be a database for metrics, it has been deployed on my database server as well. + +Prometheus is currently set to scrape metrics from the `node_exporter` and +`postgresql_exporter`, and seems to work fine. I expect I may need to tweak it +in the future to configure how long I want metrics to be available, since I've +seen it use quite a large amount of memory when storing a large amount of +metrics for a very long time. + +To actually see the metrics and have alerts, I currently intend to go with +Grafana. I already have ntfy running, and it appears relatively simple to mold +Grafana alerts into ntfy notifications. To do this properly, I will require some +machines to handle regular workloads. Most likely these will be Intel NUCs, or +similar machines, as they draw very little power for reasonable performance. +Raspberry Pi units would be cheaper, but also seem vastly less powerful, and I'd +need to ensure all my intended workloads can run on ARM which could become a +nuisance very quickly. + +As I already have an Intel NUC to play with, that's what I'll be doing for the +coming few days to see if this can work for my desires. Perhaps I can try out a +highly available cluster setup of K3s in the near future! diff --git a/content/posts/2023/2023-08-29-releasing-raku-modules-with-fez.md b/content/posts/2023/2023-08-29-releasing-raku-modules-with-fez.md new file mode 100644 index 0000000..edc1914 --- /dev/null +++ b/content/posts/2023/2023-08-29-releasing-raku-modules-with-fez.md @@ -0,0 +1,74 @@ +--- +date: 2023-08-29 +title: "Releasing Raku modules with fez" +tags: +- Argo +- Raku +--- + +Last week I got a message on Matrix, asking me to update one of my +[Raku](https://raku.org/) modules, +[`Config::Parser::TOML`](https://git.tyil.nl/raku/config-parser-toml/). One of +the dependencies had been updated, and the old one is no longer available +through the module installer `zef`. Its not that big a change, and there are +tests available, so its a reasonably small fix on itself. + +Recently I've set up [Argo Workflows](https://argoproj.github.io/workflows/) for +my CI/CD desires, and I found this a good and simple Raku project to try and +incorporate into a workflow. Since I had some additional quality checks ready to +use in my workflow, this has resulted in [REUSE](https://reuse.software/) +compliance for this Raku module, in addition to the regular `prove` tests +already available in the project. Additionally, the de facto default module +authoring tool `fez` also brings a few new checks that have been incorporated. + +While all that is good, there were some annoyances I encountered while +configuring this. Notably, I've found `fez` to be a chore to work with when it +comes to non-interactive use. All CI/CD jobs run in their own Kubernetes pods, +and _should_ not require any interaction from myself during these runs. I am +writing this blog post mainly to write down the annoyances I encountered, hoping +that `fez` can be improved in the future. + +Lets start with the first issue I encountered while setting up the workflow: +`zef install fez` fails by default. `zef` gives the advice to `--exclude` one of +the dependencies, and going by the issues reported on their Github repository, +this seems to be accepted workaround. However, I'd argue that this workaround +should not be needed to begin with. Especially seeing as `fez` works fine and I +have absolutely no clue what this `z` is or how I can supply it. Either drop +this dependency, or document its use and upstream so people can package it. + +The second issue I encountered was with the `login` functionality of `fez`. +There seems to be no way to handle this non-interactively. The way around this +for me has become to use `expect` scripts, but this is obviously not very pretty +and will break whenever the interactive interface of `fez` changes. A good means +of non-interactive authentication would be great to have. I've considered to +just mount `fez`'s config/cache into the containers, but the documentation warns +that tokens aren't permanent to begin with. + +Next up there's the actual `upload` command. I'm running it twice in my +workflow, once with `--dry-run` and once with `--force`. The first one is done +as a preliminary quality check to see if there's any obvious issues that ought +to be fixed beforehand. I noticed on a subsequent run (the one with `--force`) +that the _dry_ run isn't all that dry. It leaves an `sdist` directory, which in +turn will get included in the next step. There's a flag to create this `sdist` +directory, but no flag to do the inverse. My solution is to end this step with +`rm -fr -- sdist` to clean it up again. + +And lastly, when all quality assurance checks have passed, the `fez upload +--force` command is ran on the working directory. I'd rather not force anything +here, but the alternative is that another interactive question pops up and the +job hangs forever. I don't know all the possible prompts `fez` can generate, and +for this one I didn't even bother to try and look that up. Rather than a +`--force` to practically say "yes" to everything, I'd prefer an option to say +"no" to everything, failing the pipeline immediately. + +Another pet-peeve of mine is that `fez` seemingly doesn't use exit codes. No +matter what happens, even something quite important such as `login` with +incorrect credentials, it _always_ returns `0` as exit code. This should +obviously be fixed sooner rather than later, as it is quite simple and it is the +basis for _many_ systems to check the exit code to deduce something is wrong. + +Uploads of module updates are currently working, which is good, but I feel like +a lot of workaround code I had to write should not be necessary. If `fez` can +fix these issues, it will be much more of a breeze to use, which in turn +hopefully encourages more automated testing and distributing of Raku modules. +This can be a great boon for the module ecosystem and overall community. diff --git a/content/posts/2024/2024-04-02-bashtard-2.1.0.md b/content/posts/2024/2024-04-02-bashtard-2.1.0.md new file mode 100644 index 0000000..9485dd5 --- /dev/null +++ b/content/posts/2024/2024-04-02-bashtard-2.1.0.md @@ -0,0 +1,57 @@ +--- +date: 2024-04-02 +title: Bashtard v2.1.0 +tags: +- Bash +- Bashtard +- FreeBSD +- GNU+Linux +--- +Its been about another year since I made a post about Bashtard, its [2.0.0 +release](https://www.tyil.nl/post/2023/05/23/bashtard-v2.0.0/). Today marks the +[2.1.0 release](https://www.tyil.nl/projects/bashtard/releases/2.1.0), meaning +I've gone almost a year without breaking backwards compatibility. To me, this is +a very good sign. + +The release today isn't as big as the 2.0.0 release was, mostly because most +of the functionality I want to have is already present. Some new features were +added over the year, though. The most important one is _variable references_. +This allows re-use of a variable's value for another variable. Its quite +simplistic in how it works, due to the nature of Bashtard being written in Bash +and trying to keep things rather simple and lightweight. It does however get the +job done for most use-cases I had for it. + +Another feature that was added in this release is the `zap` subcommand. It is a +convenience command more than anything, simply removing an existing registry +entry without going through `playbook_del()`. The use case for this is mostly +for testing new playbooks. I found that while writing a playbook I'd often +remove the playbook entry from the registry to re-run the `playbook_add()` +function to see if it works exactly as desired, and I wanted this to be more +convenient. In theory this new `zap` subcommand is also useful for dealing with +entries of broken or removed playbooks. + +For a future release I'd like to add `import` and `export` subcommands, for +making it easier to handle external playbooks. The `import` subcommand is +intended to take an URL and optionally a name to simply add an existing +repository as a submodule in the `playbooks.d` directory. + +The `export` subcommand should take a name as it exists in the `playbooks.d` +directory and turn it _into_ a git submodule, so it can be pushed to its own +repository. The intent is that you can just make a regular playbook for use +within Bashtard, and if you decide "hey, this could actually be useful for +others in its current state", you can simply export it, and push it to a +repository for other people to pull from. + +Additionally, I would like to remove the `backup` subcommand from Bashtard, as I +feel it adds a level of bloat and scope-creep which simply should not be there. +While this would result in a 3.0.0 release of Bashtard, keeping it just for +backwards compatibility seems a little silly to me. + +I'm on the fence for the `ssh` subcommand, as it seems more closely aligned to +Bashtard being used to manage several systems, and ssh can be very useful to +check something across your entire network. Considering the recent [SSHd +vulnerability](https://www.cve.org/CVERecord?id=CVE-2024-3094), it was quite +easy to run a single command across all my machines and get an overview of which +machines were affected. + +Let's see what the rest of this year brings in Bashtard changes! diff --git a/content/posts/2024/_index.md b/content/posts/2024/_index.md new file mode 100644 index 0000000..5321fd3 --- /dev/null +++ b/content/posts/2024/_index.md @@ -0,0 +1,3 @@ +--- +title: 2024 +--- diff --git a/content/projects/bashtard/releases/2.0.1.md b/content/projects/bashtard/releases/2.0.1.md new file mode 100644 index 0000000..e8bf49c --- /dev/null +++ b/content/projects/bashtard/releases/2.0.1.md @@ -0,0 +1,19 @@ +--- +title: Bashtard v2.0.1 +date: 2023-09-25 +type: project-release +packages: + bashtard-2.0.1.deb: https://dist.tyil.nl/bashtard/bashtard-2.0.1/bashtard-2.0.1.deb + bashtard-2.0.1.tar.gz: https://dist.tyil.nl/bashtard/bashtard-2.0.1/bashtard-2.0.1.tar.gz +--- + +### Added + +- A new `make` target has been added to build a .tar.gz distributable. + +### Changed + +- The `svc_` utils should now check which init service you're using when using a + linux system. The supported options are still only openrc and systemd. +- The `pull` subcommand should now properly return with exit-code 0 if no + problem were encountered. diff --git a/content/projects/bashtard/releases/2.0.2.md b/content/projects/bashtard/releases/2.0.2.md new file mode 100644 index 0000000..5acaaa9 --- /dev/null +++ b/content/projects/bashtard/releases/2.0.2.md @@ -0,0 +1,13 @@ +--- +title: Bashtard v2.0.2 +date: 2024-02-28 +type: project-release +packages: + bashtard-2.0.2.deb: https://dist.tyil.nl/bashtard/bashtard-2.0.2/bashtard-2.0.2.deb + bashtard-2.0.2.tar.gz: https://dist.tyil.nl/bashtard/bashtard-2.0.2/bashtard-2.0.2.tar.gz +--- + +### Fixed + +- Configuration values with `=` in their value part should now work properly + with `file_template`. Keys with `=` in them are still *not supported*. diff --git a/content/projects/bashtard/releases/2.1.0.md b/content/projects/bashtard/releases/2.1.0.md new file mode 100644 index 0000000..24caa53 --- /dev/null +++ b/content/projects/bashtard/releases/2.1.0.md @@ -0,0 +1,29 @@ +--- +title: Bashtard v2.1.0 +date: 2024-04-02 +type: project-release +packages: + bashtard-2.1.0.deb: https://dist.tyil.nl/bashtard/bashtard-2.1.0/bashtard-2.1.0.deb + bashtard-2.1.0.tar.gz: https://dist.tyil.nl/bashtard/bashtard-2.1.0/bashtard-2.1.0.tar.gz +--- + +### Added + +- Configuration variables can be assigned values of other variables with the + `&=` assignment. This allows a single value to be re-used dynamically, rather + than having to explicitly set the same value several times. +- A `zap` command has been added to remove a playbook from the registry without + running the playbook's `playbook_del()` function. This is intended to easily + remove registry entries when a playbook itself has been deleted or is + otherwise broken in a way that the regular `del` subcommand cannot fix. + +### Changed + +- The `description.txt` is now allowed to be used without the `.txt` suffix. + Usage with the `.txt` suffix continues to be supported as well. + +### Fixed + +- Passing an empty string as default value to `config` should now properly + return an empty string without a warning about the configuration key not + existing. diff --git a/content/recipes/dishes-side/waffles.md b/content/recipes/dishes-side/waffles.md new file mode 100644 index 0000000..4a5165d --- /dev/null +++ b/content/recipes/dishes-side/waffles.md @@ -0,0 +1,56 @@ +--- +title: Waffles +date: 2024-04-15 +preptime: 10 +cooktime: 5 +serves: 2 +tags: +- warm +- sweet +- vegetarian + +ingredients: +- label: Flour + amount: 100 + unit: grams +- label: Granulated Sugar + amount: 30 + unit: grams +- label: Baking powder + amount: 10 + unit: grams +- label: Salt +- label: Milk + amount: 100 + unit: milliliters +- label: Egg + amount: 50 + unit: grams +- label: Vanilla Extract + amount: 1 + unit: teaspoon +- label: Butter + amount: 25 + unit: grams + +stages: +- label: Preparation + steps: + - Put the butter in the microwave until it is completely melted + - Mix all ingredients together in a mixing bowl until the batter is smooth +- label: Baking + steps: + - Ensure your waffle iron is on optimal temperature + - Apply the appropriate amount of batter to the waffle iron + - Let bake until lightbrown +--- + +Sweet and fluffy waffles. Great as a snack or as a side-dish to a larger meal. + +<!--more--> + +These waffles can be served with ice cream and/or fruit to create a simple but +delicious snack or dessert. The instructions for the baking itself are rather +simplistic, but it appears that waffle irons differ wildly in size and settings +even in my own country, let alone in other countries. For this reason, you may +need to experiment a little with your waffle iron of choice. diff --git a/content/recipes/snacks/cheesecake-basque-burned.md b/content/recipes/snacks/cheesecake-basque-burned.md index 0da9318..e59b9b2 100644 --- a/content/recipes/snacks/cheesecake-basque-burned.md +++ b/content/recipes/snacks/cheesecake-basque-burned.md @@ -16,13 +16,16 @@ ingredients: amount: 500 unit: grams - label: Flour - amount: 40 + amount: 50 unit: grams - label: Granulated sugar amount: 300 unit: grams -- label: Heavy cream - amount: 550 +- label: Heavy cream (35% fat) + amount: 500 + unit: grams +- label: Creme Fraiche + amount: 125 unit: grams - label: Salt amount: 1 diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html index 74338f3..f69ca6a 100644 --- a/layouts/_default/baseof.html +++ b/layouts/_default/baseof.html @@ -5,7 +5,13 @@ <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> + <link rel="canonical" class="u-url" href="{{ .Permalink }}"> <link rel="stylesheet" type="text/css" href="{{ $cssMain.Permalink }}"> + <link rel="me" href="https://fedi.tyil.nl/@tyil"> + <link rel="me" href="https://git.tyil.nl"> + <link rel="me" href="https://sr.ht/~tyil"> + <link rel="me" href="https://www.tyil.nl" class="h-card"> + <link rel="me" href="mailto:p.spek@tyil.nl"> {{- range .AlternativeOutputFormats }} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" title="{{ $.Site.Title }}" href="{{ .Permalink }}"> {{- end }} diff --git a/layouts/posts/list.html b/layouts/posts/list.html index 40a0ba5..b5ec8ca 100644 --- a/layouts/posts/list.html +++ b/layouts/posts/list.html @@ -6,11 +6,13 @@ <ul> {{- range .Pages }} <li> - <a href="{{ .Permalink }}">{{ .Title }}</a> + <a class="u-url" href="{{ .Permalink }}"><span class="p-name">{{ .Title }}</span></a> <small> - {{ .Date | dateFormat "2006-01-02" }} + <time class="dt-published" datetime="{{ .Date | dateFormat "2006-01-02" }}"> + {{ .Date | dateFormat "2006-01-02" }} + </time> {{- range .Params.tags }} - <a href="/tags/{{ . | lower }}">#{{ . }}</a> + <a class="p-category tag" href="/tags/{{ . | lower }}">{{ . }}</a> {{- end }} </small> </li> diff --git a/layouts/posts/single.html b/layouts/posts/single.html index cab9527..eca87b9 100644 --- a/layouts/posts/single.html +++ b/layouts/posts/single.html @@ -1,10 +1,13 @@ {{ define "main" }} -<article> +<article class="h-entry"> <header> - <h1>{{ .Title }}</h1> - {{- range .Params.tags }} - <a href="/tags/{{ . | lower }}">#{{ . }}</a> - {{- end }} + <h1 class="p-name">{{ .Title }}</h1> + <p> + {{- range .Params.tags }} + <a class="p-category tag" href="/tags/{{ . | lower }}">{{ . }}</a> + {{- end }} + — Published on <time class="dt-published" datetime="{{ .Date | dateFormat "2006-01-02" }}">{{ .Date | dateFormat "2006-01-02" }}</time>. + </p> {{- if .Draft }} <section class="admonition"> <div class="admonition-title"> @@ -19,7 +22,7 @@ </section> {{- end }} </header> - <main> + <main class="e-content"> {{ .Content }} </main> <footer> diff --git a/layouts/recipes/list.html b/layouts/recipes/list.html index de18df0..b758a2b 100644 --- a/layouts/recipes/list.html +++ b/layouts/recipes/list.html @@ -10,11 +10,11 @@ </div> <div class="description"> <h2> - <a href="{{ .Permalink }}">{{ .Title }}</a> + <a class="p-name" href="{{ .Permalink }}">{{ .Title }}</a> </h2> <ul class="taglist"> {{- range sort .Params.tags }} - <li><a class="tag" href="/tags/{{ . | lower }}">{{ . }}</a></li> + <li><a class="p-category tag" href="/tags/{{ . | lower }}">{{ . }}</a></li> {{- end }} </ul> {{ .Content }} diff --git a/layouts/recipes/single.html b/layouts/recipes/single.html index c4876a9..353abd2 100644 --- a/layouts/recipes/single.html +++ b/layouts/recipes/single.html @@ -1,14 +1,10 @@ -{{ define "head" }} - <script type="text/javascript" src="/js/cookbook.js"></script> -{{- end }} - {{ define "main" }} <article> <header> - <h1>{{ .Title }}</h1> + <h1 class="p-name">{{ .Title }}</h1> <ul class="taglist"> {{- range sort .Params.tags }} - <li><a class="tag" href="/tags/{{ . | lower }}">{{ . }}</a></li> + <li><a class="p-category tag" href="/tags/{{ . | lower }}">{{ . }}</a></li> {{- end }} </ul> {{- if .Draft }} @@ -28,7 +24,7 @@ </section> {{- end }} </header> - <main> + <main class="e-content"> {{ .Content }} <table> <tbody> |