MB

▄▄▄·▪ ▐ ▄ ▄▄▄ . ▐█ ▄███ •█▌▐█▀▄.▀· ██▀·▐█·▐█▐▐▌▐▀▀▪▄ ▐█▪·•▐█▌██▐█▌▐█▄▄▌ .▀ ▀▀▀▀▀ █▪ ▀▀▀

FROM scratch AS build ARG VERSION COPY --from=stagex/core-busybox . / COPY --from=stagex/core-musl . / COPY --from=stagex/core-make . / COPY --from=stagex/core-llvm . / COPY --from=stagex/core-mold . / COPY --from=stagex/core-onetbb . / COPY --from=stagex/core-zlib . / COPY --from=stagex/core-libzstd . / ADD fetch/grep-${VERSION}.tar.xz . WORKDIR /grep-${VERSION} RUN --network=none <<-EOF set -ex ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --disable-nls make -j "$(nproc)" make DESTDIR="/rootfs" install EOF FROM stagex/core-filesystem AS package COPY --from=build /rootfs/ /

float F(float x, float y,float t){float g=pow(fmod(t,5)/5,5),X=32+ sin((int)t/5* 45.32)*15;return 150/((x-35)*(x-35)*.4+(y-13)*(y- 13))+25*g/((x-X)*(x-X)*.4+(y-13-35 *g)*(y-13-35*g));}main(){float t=0 ;int x,y,i ;for(printf("\x1b[?25l" "\x1b[2J");printf("\x1b[H\x1b[31m" );t+=.3,usleep(90000))for(y=0;y<43 ;y++)for(x=0;x<=80; x++)putchar(x< 80?F(x,y,t)>1?"=+#%*0X@&"[(i=4+( F(x+1,y,t)-F(x-1,y,t)+F(x,y+1, t)-F(x,y-1,t))*2.5,i<0?0:i >8?8:i)]:32:10);}///// /*///drip.c///*/

I am still working on a hard drive mount that won’t melt, but in the meantime the software side is ready. To nobody’s surprise, even this backup server is running Talos Linux managed by Omni. It is a two-node cluster. One worker node is the ZimaBlade that has the hard drive attached, and the one control plane node is a virtual one that is running on my other Omni cluster. You can run Talos as just a normal container, but not when managed by Omni. So it is actually a full QEMU virtual machine, but still running as a pod. Working with this virtual control plane means that the worker node is 100% stateless (except for the backup drive, of course). This helps make my offsite backup extra robust, because I will not always have physical access to the worker.

Because the worker and control plane are not on the same network, everything will need to be networked through NetBird. Luckily, this is easily done with the System Extensions of Talos. So NetBird is running as an OS process, which allows Flannel and Kubelet to talk over the virtual network. So the nodes can be anywhere, and things will just work, even behind symmetric NAT where KubeSpan won’t work. In NetBird, the Bunker cluster (that is what I am calling this small backup cluster) is fully isolated and has only connections between the nodes and a one-way connection from the worker node to my NAS (pull-based backups).

Next, what is running on the cluster. To start, my usual monitoring stack, but no storage of the metrics this time. I am running the Victoria metrics agent to forward all metrics to my other Talos cluster that has a storage server running. For the backup itself, I am running a basic cronjob with rsnapshot, a wrapper tool on to of Rsync that uses Linux hard links for its ‘incremental’ backups. The folder structure looks like full-sized backups each day, but the hard links keep the storage usage low. Encryption is provided at the drive level using LUKS2. Again this just uses basic Linux components, so if I need to I can just plug the drive into my Linux laptop and recover all my files without any special tools. The transfer is pull based happens over SSH with read only permission. This makes it so my data stays safe (at least 1 copy) even if one of my servers gets compromised. And last, I am running a small DaemonSet with hdparm that makes sure the drive is configured correctly to spin down when idle. The ZimaBlade is passively cooled so the system is fully silent once the disk spins down.

Last week when moving over to Codeberg (see post 1778177701) I noticed that I am using the github.com domain in my module names. For my projects (like mb) that fine, I just moved it to codeberg.org when moving the repo. But for libraries I can’t expect everybody to change their go.mod file every time I change were I host my code (not that anybody uses my libs but just go with it). Luckily the Go devs have though of this.

When trying to download a module, like github.com/ncruces/go-sqlite3 for example, go will make a http/https request like shown below. The webserver should then provide a special go-import meta tag that where and how it can pull the code.

curl -s 'https://github.com/ncruces/go-sqlite3?go-get=1' | grep go-import
<meta name="go-import" content="github.com/ncruces/go-sqlite3
    git https://github.com/ncruces/go-sqlite3.git">

Most code forges will handle this for you. But you can also deploy your own server on your own domain that handles this. And that is exactly what I have done, setup my own vanity URL. I made a simple stateless webserver for this that just takes a JSON config, source. Currently it will redirect to Codeberg but when I move my repos again I just have to change a basic config file and all modules will keep working as they are supposed to. I just have to make sure that go.pine32.be doesn’t go down. But it is a stateless app running 2 replicas on a highly available Kubernetes cluster, should be fine.

curl -s 'https://go.pine32.be/id?go-get=1' | grep go-import
<meta name="go-import" content="go.pine32.be/id
    git https://codeberg.org/Pineapple217/go-id">

New NAS!!