summaryrefslogtreecommitdiff
path: root/content/posts/2021
diff options
context:
space:
mode:
authorPatrick Spek <p.spek@tyil.nl>2021-12-15 10:45:58 +0100
committerPatrick Spek <p.spek@tyil.nl>2021-12-15 10:45:58 +0100
commit5c086bc52fa3a226bcf706b1f420a5d98ea377dd (patch)
treeda5b28238542247efbe36c49cbc6cfd4e49f3e36 /content/posts/2021
parent64e0495846f8b680288280920cba6bcb28e4092f (diff)
Redo most of the blog in Hugo
Missing posts will have to be added later
Diffstat (limited to 'content/posts/2021')
-rw-r--r--content/posts/2021/2021-05-13-a-new-irc-client.md85
-rw-r--r--content/posts/2021/2021-05-22-raku-on-libera-chat.md35
-rw-r--r--content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md194
-rw-r--r--content/posts/2021/_index.md3
4 files changed, 317 insertions, 0 deletions
diff --git a/content/posts/2021/2021-05-13-a-new-irc-client.md b/content/posts/2021/2021-05-13-a-new-irc-client.md
new file mode 100644
index 0000000..7003cb5
--- /dev/null
+++ b/content/posts/2021/2021-05-13-a-new-irc-client.md
@@ -0,0 +1,85 @@
+---
+date: 2021-05-13
+title: A New IRC::Client
+tags:
+- Raku
+- IRC
+- Programming
+social:
+ email: mailto:~tyil/public-inbox@lists.sr.ht&subject=A New IRC::Client
+---
+
+The Raku programming language has a popular module for creating IRC bots,
+[`IRC::Client`](https://github.com/raku-community-modules/IRC-Client). However,
+it's been stale for quite a while, and one of the bots I host,
+[Geth](https://github.com/Raku/geth), is having troubles on a regular basis.
+
+I've looked at the source code, and found a lot of neat tricks, but when
+maintaining a library, I generally want clean and straightforward code instead.
+To that end, I decided to just write my own from scratch. Given that [the IRC
+protocol is rather simple](https://tools.ietf.org/html/rfc2812), this was the
+easiest way to go about it.
+
+Sure enough, after a couple hours of playing around, I had something that
+worked reasonably well. A few more hours a day afterwards brought me to an
+`IRC::Client` that is usable in mostly the same way as the current
+`IRC::Client`, to save me effort in getting my current bots to make use of it
+for a few test runs.
+
+Geth was my main target, as I wanted it to stop from getting timed out so
+often. For the past week, Geth has been running stable, without any time
+out, so I think I've succeeded in the main goal.
+
+However, how to continue next? Since it is mostly compatible, but not
+*completely* compatible, if I were to adopt `IRC::Client` from the Raku
+ecosystem and push my version, many people's IRC bots would break when people
+update their dependencies. There is a solution for this built into the entire
+ecosystem, which is using the correct `:ver` and `:auth` (and in some cases,
+`:api`) so you can ensure your project is always getting the "correct"
+dependency. However, from personal experience, I know these additional
+dependency restrictions are rarely used in practice.
+
+I hope that with this blog post, I can inform the community in time about the
+changes that are coming to `IRC::Client`, so people have ample time to set
+their dependencies just right to keep their projects working. Of course, the
+real solution for the long term would be to make the small changes required to
+use the latest `IRC::Client` again.
+
+For convenience sake, I've added a small number of methods for backwards
+compatibility as well, though these will generate [a deprecation
+warning](https://docs.raku.org/routine/is%20DEPRECATED), and will be removed in
+a later `IRC::Client` release.
+
+There's two major changes that are not backwards compatible, however. The first
+one is the removal of the ability to have a single `IRC::Client` connect to
+multiple servers. This is also the easiest to remedy, by simply creating
+multiple instances of `IRC::Client`.
+
+The second major incompatible change is how events are dispatched to plugins.
+This used to be handled by going through all the plugins sequentially, allowing
+one plugin to stop the dispatch to another plugin. In my new version, events
+are dispatched to all plugins in parallel. This allows for faster execution,
+and for multiple plugins to handle an event without having to use `$*NEXT`
+(which has been removed). My main motivation is that a buggy plugin will no
+longer interfere with the interactions provided by other plugins. The ordering
+of your plugins will also stop being an issue to worry about.
+
+Geth's updates to actually use my updated `IRC::Client` module was introduced
+in
+[`edc6b08`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa),
+and most if it was updates to the way it handled logging. The actual changes
+needed to make Geth play nice were
+
+- [Adding the `IRC::Client::Plugin` role to `Geth::Plugin::Info`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R14);
+- [And to `Geth::Plugin::Uptime`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R24);
+- [Using `nicks` instead of `nick`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R34);
+- [Using `start` instead of `run`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R46);
+- [Using `privmsg` instead of `send`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-c388af832470886cdd4304aeb17c4c2f406ac184d33afb956b0ef8a92b69855bR57);
+
+The last two changes aren't strictly necessary, as there are backwards
+compatibility methods made for these, but it's a rather small change and
+reduces the amount of noise in the logs.
+
+With this, I hope everyone using `IRC::Client` is prepared for the coming
+changes. If you have any comments or questions, do not hesitate to reach out to
+me and share your thoughts!
diff --git a/content/posts/2021/2021-05-22-raku-on-libera-chat.md b/content/posts/2021/2021-05-22-raku-on-libera-chat.md
new file mode 100644
index 0000000..87ce7ff
--- /dev/null
+++ b/content/posts/2021/2021-05-22-raku-on-libera-chat.md
@@ -0,0 +1,35 @@
+---
+date: 2021-05-22
+title: Raku is moving to Libera.chat
+tags:
+- Raku
+- LiberaChat
+- IRC
+social:
+ email: mailto:~tyil/public-inbox@lists.sr.ht&subject=Raku is moving to Libera.chat
+---
+
+Earlier this week, the staff at the Freenode IRC network have resigned en
+masse, and created a new network, Libera. This was sparked by [new ownership of
+Freenode](https://kline.sh/). Due to concerns with the new ownership, the Raku
+Steering Council has decided to also migrate our IRC channels to Libera.
+
+This requires us to take a couple steps. First and foremost, we need to
+register the Raku project, to allow us a claim to the `#raku` and related
+channels. Approval for this happened within 24 hours, and as such, we can
+continue on the more noticable steps.
+
+The IRC bots we're using for various tasks will be moved next, and the Raku
+documentation has to be updated to refer to Libera instead of Freenode. The
+coming week we'll be working on that, together with the people who provide
+those bots.
+
+Once this is done, the last step involves the Matrix bridge. Libera and
+Matrix.org staff are working on this, but there's no definite timeline
+available just yet. This may mean that Matrix users will temporarily not be
+able to join the discussions happening at Libera. We will keep an eye on the
+progress of this, and set up the bridge as soon as it has been made available.
+
+If you have any questions regarding the migration, feel free to reach out to us
+via email (`rsc@raku.org`) or on IRC (`#raku-steering-council` on
+irc.libera.chat).
diff --git a/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md b/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md
new file mode 100644
index 0000000..c182654
--- /dev/null
+++ b/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md
@@ -0,0 +1,194 @@
+---
+date: 2021-06-04
+title: Managing Docker Compose with OpenRC
+tags:
+- Gentoo
+- OpenRC
+- Docker
+- DockerCompose
+---
+
+On one of my machines, I host a couple services using `docker-compose`. I
+wanted to start/restart/stop these using the default init/service manager used
+on the machine, `openrc`. This would allow them to start/stop automatically
+with Docker (which coincides with the machine powering on or off,
+respectively).
+
+I've set this up through a single `docker-compose` meta-service. To add new
+`docker-compose` projects to be managed, all I need to do for `openrc`
+configuration is creating a symlink, and configure the path to the
+`docker-compose.yaml` file.
+
+The meta-service lives at `/etc/init.d/docker-compose`, just like all other
+services managed by `openrc`. This file is quite straightforward. To start off,
+a number of variables are set and exported.
+
+```sh
+name="$RC_SVCNAME"
+description="OpenRC script for managing the $name docker-compose project"
+
+# Set default values
+DOCKER_COMPOSE="${DOCKER_COMPOSE:-docker-compose} $DOCKER_COMPOSE_ARGS"
+
+COMPOSE_PROJECT_NAME="${COMPOSE_PROJECT_NAME:-$name}"
+
+# Export all variables used by docker-compose CLI
+export COMPOSE_PROJECT_NAME
+export COMPOSE_FILE
+export COMPOSE_PROFILES
+export COMPOSE_API_VERSION
+export DOCKER_HOST
+export DOCKER_TLS_VERIFY
+export DOCKER_CERT_PATH
+export COMPOSE_HTTP_TIMEOUT
+export COMPOSE_TLS_VERSION
+export COMPOSE_CONVERT_WINDOWS_PATHS
+export COMPOSE_PATH_SEPARATOR
+export COMPOSE_FORCE_WINDOWS_HOST
+export COMPOSE_IGNORE_ORPHANS
+export COMPOSE_PARALLEL_LIMIT
+export COMPOSE_INTERACTIVE_NO_CLI
+export COMPOSE_DOCKER_CLI_BUILD
+```
+
+One of the services I use is also configured with its own `external` network. I
+want it to be created if it doesn't exist, to ensure that the service can start
+up properly. I do *not* want it to be removed, so I left that out.
+
+```sh
+# Set up (external) networks
+for name in "${DOCKER_NETWORKS[@]}"
+do
+ # Create the network if needed
+ if ! docker network ls | awk '{ print $2 }' | grep -q "$name"
+ then
+ einfo "Creating docker network '$name'"
+ docker network create "$name" > /dev/null
+ fi
+
+ # Expose some variables for the networks
+ network_id="DOCKER_NETWORK_${name}_ID"
+
+ declare -gx DOCKER_NETWORK_${name}_ID="$(docker network ls | awk '$2 == "'"$name"'" { print $1 }')"
+ declare -gx DOCKER_NETWORK_${name}_GATEWAY="$(docker network inspect "${!network_id}" | jq -r '.[0].IPAM.Config[0].Gateway')"
+
+ unset network_id
+done
+```
+
+And lastly, there's the four simple functions to declare dependencies,
+configure how to `start` or `stop`, and how to get the `status` of the service.
+
+```sh
+depend() {
+ need docker
+}
+
+start() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" up -d
+}
+
+status() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" ps
+}
+
+stop() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" down
+}
+```
+
+Now, to actually create a service file to manage a `docker-compose` project, a
+symlink must be made. I'll take my
+[`botamusique`](https://github.com/azlux/botamusique) service as an example.
+
+```
+ln -s /etc/init.d/docker-compose /etc/init.d/botamusique
+```
+
+This service can't start just yet, as there's no `$COMPOSE_PROJECT_DIRECTORY`
+configured for it yet. For this, a similarly named file should be made in
+`/etc/conf.d`. In here, any variable used by the service can be configured.
+
+```
+$EDITOR /etc/conf.d/botamusique
+```
+
+In my case, it only pertains the `$COMPOSE_PROJECT_DIRECTORY` variable.
+
+```
+COMPOSE_PROJECT_DIRECTORY="/var/docker-compose/botamusique"
+```
+
+And that's it. For additional `docker-compose` projects I need to make only a
+symlink and a configuration file. If I discover a bug or nuisance, only a
+single file needs to be altered to get the benefit on all the `docker-compose`
+services.
+
+For reference, here's the full `/etc/init.d/docker-compose` file.
+
+```sh
+#!/sbin/openrc-run
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+name="$RC_SVCNAME"
+description="OpenRC script for managing the $name docker-compose project"
+
+# Set default values
+DOCKER_COMPOSE="${DOCKER_COMPOSE:-docker-compose} $DOCKER_COMPOSE_ARGS"
+
+COMPOSE_PROJECT_NAME="${COMPOSE_PROJECT_NAME:-$name}"
+
+# Export all variables used by docker-compose CLI
+export COMPOSE_PROJECT_NAME
+export COMPOSE_FILE
+export COMPOSE_PROFILES
+export COMPOSE_API_VERSION
+export DOCKER_HOST
+export DOCKER_TLS_VERIFY
+export DOCKER_CERT_PATH
+export COMPOSE_HTTP_TIMEOUT
+export COMPOSE_TLS_VERSION
+export COMPOSE_CONVERT_WINDOWS_PATHS
+export COMPOSE_PATH_SEPARATOR
+export COMPOSE_FORCE_WINDOWS_HOST
+export COMPOSE_IGNORE_ORPHANS
+export COMPOSE_PARALLEL_LIMIT
+export COMPOSE_INTERACTIVE_NO_CLI
+export COMPOSE_DOCKER_CLI_BUILD
+
+# Set up (external) networks
+for name in "${DOCKER_NETWORKS[@]}"
+do
+ # Create the network if needed
+ if ! docker network ls | awk '{ print $2 }' | grep -q "$name"
+ then
+ einfo "Creating docker network '$name'"
+ docker network create "$name" > /dev/null
+ fi
+
+ # Expose some variables for the networks
+ network_id="DOCKER_NETWORK_${name}_ID"
+
+ declare -gx DOCKER_NETWORK_${name}_ID="$(docker network ls | awk '$2 == "'"$name"'" { print $1 }')"
+ declare -gx DOCKER_NETWORK_${name}_GATEWAY="$(docker network inspect "${!network_id}" | jq -r '.[0].IPAM.Config[0].Gateway')"
+
+ unset network_id
+done
+
+depend() {
+ need docker
+}
+
+start() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" up -d
+}
+
+status() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" ps
+}
+
+stop() {
+ $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" down
+}
+```
diff --git a/content/posts/2021/_index.md b/content/posts/2021/_index.md
new file mode 100644
index 0000000..1287d56
--- /dev/null
+++ b/content/posts/2021/_index.md
@@ -0,0 +1,3 @@
+---
+title: 2021
+---