Add new Bashtard post

2 files changed, 60 insertions, 0 deletions

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
+---