From 6a6a7cba787d9a62a630237685f2707c891ebf7a Mon Sep 17 00:00:00 2001 From: Patrick Spek Date: Tue, 2 Apr 2024 11:01:20 +0200 Subject: Add new Bashtard post --- content/posts/2024/2024-04-02-bashtard-2.1.0.md | 57 +++++++++++++++++++++++++ content/posts/2024/_index.md | 3 ++ 2 files changed, 60 insertions(+) create mode 100644 content/posts/2024/2024-04-02-bashtard-2.1.0.md create mode 100644 content/posts/2024/_index.md (limited to 'content/posts') 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 +--- -- cgit v1.1