first software deployed to the beefy new vps is TiddlyPWA, and it is pretty great, and easier to install than i thought it would be. going to use it as a lab notebook and planner for the rest of the things i want to deploy

i was originally reluctant to use it because it doesn't seem like it would handle multiplayer -- multiple people working on the same page at the same time -- very well. but for now i'm the only user and it's great

TiddlyPWA — TiddlyWiki Storage & Sync Solution

also going to break up my existing tiddlywiki5 into multiple separate tiddlypwa's. having to transfer the entire tiddlywiki5 to my mobile device on a spotty lte connection on the other side of the world just to edit a page is not just slow but sometimes totally unusable (timeouts, i think)

a small tiddlypwa continues to work great, even on my mobile device on random networks on the other side of the planet. a far better experience than my big tiddlywiki5 instance.

deno (and node) are both chunkier than i'd like but the utility tiddlypwa provides outweighs that. a problem for later.

try it out! support the author!

TiddlyPWA — TiddlyWiki Storage & Sync Solution

set up systemd socket activation to make deno gtfo when nobody's accessing the tiddlypwa wiki for >= 3 minutes 👍 😎

setting StateDirectory=foo in a systemd unit makes it create the directory /var/lib/foo and set $STATE_DIRECTORY to that
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=

$STATE_DIRECTORY will expand in your Exec= declaration but not in e.g. Environment=

so i can't say

Environment=DB_FILENAME=${STATE_DIRECTORY}/database.sqlite3
...
Exec=/usr/bin/command

instead i have to
Exec=env DB_FILENAME=${STATE_DIRECTORY}/database.sqlite3 /usr/bin/command

is there a prettier way?

systemd.exec

is there a prettier way?

there is!

StateDirectory=%N
Environment=DB_FILENAME=%S/%N/database.sqlite3

systemd.unit "specifiers"

systemd.unit

setting up xmpp service on an ipv6-only vm with a graciously provided sniproxy to reverse-proxy ipv4 traffic to it

xmpp seems fine. i think my fantastic vps will let me forward those ports but even if not you can make xmpp share http(s) ports with a webserver with some hacks

but if i want to do voice and video, i'll need stun/turn to help ipv4 users

stun seems fine. client connects to it, server says "you appear to me to be (address):(port)," done.

turn however...

turn is for when no clever way can be found to connect clients directly to each other; they both connect to a turn server which just proxies: it shovels data back and forth to each client

even though my host would probably grant a request to proxy traffic through their ip4->ip6 machine to my turn service, which would proxy it again, that seems wasteful and squandering of a currently free community resource. i think i will build this out pretending that i can't do that

i'm not sure if there's any need for stun or turn with ipv6 clients, but otoh ipv6 nats are possible

like when your isp assigns you a /64 but you want to set up several subnets

think i'll rely on the reverse proxy to enable xmpp for ipv4-only users, and just say that voice and video is unavailable to them. the only real users of my xmpp server are my immediate family, and if both happen to be on an ip4-only network and need voice/video, they can get on the vpn

i got a ipv6-only vm from my sweet hosting provider
they gave me a /56 worth of ipv6 address space to play in. woah.
said my vm is currently using only the first /64 of it.
my vm's address is (prefix)::1/64, amazing!
so uh
how do i plug servers and containers into the rest of my available space? do i have to request each address get added to a table somewhere? (no)

(to be continued. but i think i did it, and understand it now!) 🎉

(i might do this as a blog instead)

woo! connected to a test instance of prosody xmpp on port 443 (https) using xmpp's direct-tls protocol

which means

  • hopefully, certain employers won't block the traffic anymore
  • hopefully, it can pass through sniproxy the same way https traffic does, which will enable ipv4 users to talk to my ipv6 xmpp server

there's still different ways i can think of to wire all this together, wondering if any would be better

other ways i could wire it up:

  • instead of using a separate ip address so it and caddy can both listen on port 443, i could have caddy reverse proxy to it

  • might need to put it behind a proxy anyway because it might not handle PROXY protocol from sniproxy

  • might need to put it behind a proxy anyway so iocaine can slap the llm scrapers that try it

  • maybe run it in a container and figure out how to get those their own ip address

wow incus (anti-ubuntu fork of lxd) and its web ui is pretty slick

also libvirt and virt-manager connected to lxc offers the ability to create an application container or an operating system container

(compared to incus which says application containers require docker?)

this feels like a deep rabbit hole, hope i can get grips on it soon

all right incus there you go, a whole-ass lvm volume group all to yourself, let's see what you do with it

also: learning wtf a network bridge is and how to use one 🧑‍🎓📖 instead of the usual winging it with vague guesswork and assumptions from context

is xmpp's direct-tls protocol (usually on port 5223) the same as its unencrypted protocol (usually port 5222) wrapped in tls? same as imaps and pops and https? so could i terminate the tls with haproxy and reverse proxy to an unencrypted xmpp server?

the protocol is all spec'd in RFCs for anybody to look at but they don't wanna get in my brain

also, aw, the wikipedia article for xmpp describes as an example a transport for icq, rip https://en.wikipedia.org/wiki/XMPP

XMPP - Wikipedia

the docs don't reveal the info i want, and i don't want to try reading reams of source code in an unfamiliar language right now, so i'll set up an experiment and see how it behaves i guess

(the only activity that ever feels slightly close to doing science in my field of software-jiggling)

my ipv4-only client
-> ipv4-to-ipv6 sniproxy port 443
-> ipv6-only vm
-> haproxy to conditionally unwrap proxy protocol
-> prosody xmpp server

... experiment is working ✨🤩✨

calling it now: even though haproxy has lots of sharp edges, i like it, or its configuration mechanism, way more than caddy's

  • i seem to be able to make stuff work in haproxy that takes struggle and uncertainty in caddy
  • caddy's magical get-your-free-ssl-cert-automatically is nice when you want to stand up an experiment but i like cronned certbot for "prod"
  • otoh caddy has a nice builtin static webserver 🤷

i think i'm going to be stuck using both for a while

migrating xmpp services from my old vps to my colocataires vm is the last thing remaining to do before i'm able to delete the old account (and stop paying for it)

(dreamcompute hasn't been bad, but i like colocataires way better)

now that i've proven to myself that it can work over port 443 and ipv6-only, it's time to configure it properly

next: see if i can move the service over without xmpp clients complaining

but first, sleep 😴

Colocataires: Host with Friends

We offer artisanal server colocation and virtual machine hosting in our Ottawa, Canada-based data center. Pick from our standard rackmount or VM options or propose something custom.

all the clients we usually use on android and linux are now connecting to my new xmpp server at colocataires, with no settings changes, on the https port so it looks like website traffic 😮

i don't have stun/turn turned back on yet, so voice and video calls probably won't work just yet

i don't have the conversations.js web client set back up yet but that's mostly for emergency use

this may be success enough to decommission the old servers! 🎉

also need to double check to make sure i haven't left any gaping security holes open, like exposing a server accepting proxy protocol to the fetid internet

https://conversejs.org/ is back up on my domain and working just fine 🎉

old dreamcompute vps is turned off, sitting there just in case for a bit, then i can delete my account 🎉

(i don't hate dreamcompute but i like https://colocataires.dev way better)

think i'm just gonna leave stun/turn not running for now. if both parties are on ipv6-capable networks, calls should work. let's see how often that's an issue

Converse

Converse.js - Open source, web-based XMPP chat client. Self-hosted, customizable web chat with end-to-end encryption.

if i want to set up stun/turn, i should abandon my somewhat irrational ipv6-purist intentions and pay the loonie for an ipv4 address

if i'm gonna do that then maybe i can keep almost all of my vm ipv6-only, except for one container that runs coturn?

if i'm gonna do that then maybe i can figure out how to make that container, that only does whatismyipaddress and proxy video calls, shareable with my datacenter neighbors 

Loonie - Wikipedia

my prosody xmpp setup in its new server mostly works great (assuming ipv6 capable network) but somewhere i've introduced a timeout that closes the connection after a uniform number of seconds

pretty sure it has something to do with haproxy, though from a skim of the docs these timeouts are supposed to apply to the initial connection setup, not inactivity

also after a chat with someone more knowledgeable i think i'm resigned to eventually acquire that ipv4 address

i think i might have fixed haproxy closing the socket on my long-lived idle xmpp connections by setting timeout tunnel 1h

i'll check again in several hours to be sure

wish i knew more precisely why this fixes the issue. are clients and/or the server sending keepalive messages more often than 1h but less often than 10m? is the tcp keepalive stuff not being used? someday perhaps but more likely i'll leave it unexamined as long as it works

recent impulses have been like

"this is too long for toots i should blog about it"
"but i don't want to put anything new or deploy a new website until i have something installed to block the scrapers like iocaine"
"so let's install it"
"ehh not enough brain rn, maybe next time"

so i set up some rules to block a good portion of bots (until they smarten up)

which frees me up to actually post some blog 👍

i'll install iocaine properly after that

iocaine - the deadliest poison known to AI

i want to set up a photo storage server

photoprism seems like a good browsing interface but what i'm more concerned about rn is the upload

so a client on each android phone that backs up photos to the server

but i want to be able to turn the server off for a while, as a normal/expected thing one does, and not have the clients moan about it. they should just retry occasionally until the server comes back online

anybody have a setup like this running already?

musing about how to do high(ish)-availability systems on the cheap, goblin style

  • i got this sweet vm on a friend's server
  • someday i wanna convince employers they're better off in there, than on aws
  • if the host, or the whole datacenter, or the hose from the internet to that datacenter get orbital-lasered to slag in the middle of the business day, how to automatically shunt traffic to backup systems?
  • dns records are too cached, too slow to flip

...

  • also don't want to send all traffic through a load balancing proxy, expensive and another single point of failure

but wait i have some tradeoffs that might enable some tricks:

  • i want high availability for existing users but new users can wait for dns to propagate
  • the site can be a "progressive web app" that gets mostly cached in the browser

so in this specific case i think i could do client-side js failover. maybe even a service worker?

also trying to learn incus vs podman vs docker nope vs kubernetes not u

wait, how often does the whole region disappear anyway?

that was never a concern multiple employers ago when i got to help out at the datacenter

they did redundant everything inside the rack, regular cable-yank failover tests and everything, but no geographical redundancy iirc

maybe i'll inquire about a vm on another host within the same rack when i get closer to dragging clients on board and just forget about higher availability than that for now

embarrassed to admit that i've today taken one halfhearted step toward learning wtf snmp is by way of (re)reading the rrdtool tutorial

no, not smtp the email sending thing. snmp the monitoring of hardware status thing

all because i want to put up some pretty charts of computer doing inscrutable computer thing

(accuracy? that's like number seven or twelve down the list of nice-to-haves)

RRDtool - rrdtutorial

well, actually,
my ipv4-only client
-> colocataires' ipv4-to-ipv6 sniproxy on port 443
-> my ipv6-only vm
-> haproxy to unwrap proxy protocol
-> prosody xmpp server
... experiment is not working ✨😕✨

so:

did it never work and i mistakenly thought that it did?
or
did it work at first but i broke it?

an easy fix would be to get an ipv4 address which obviates the need for sniproxy. but dammit before i do that i want answers: is this setup possible? if so, what'd i mess up?

(maniacal cackling)

i have finally got iocaine installed. wasn't even hard, just needed to sit down and do the steps and brain is real good at not that sometimes

hooked it up to the apt-installable anarchism faq for its markov corpus and the biggest canadian flavored apt-installable wordlist i could get

feels good. like the invulnerability you get from your favorite winter gloves and jacket before going out to play in the blizzard

now it's safe to blog again 🎉

i um only just now noticed that the apt-installable anarchism faq, in uncompressed markdown format, which i fed to iocaine for its markov corpus,

is twelve megabytes. of text.

almost 1.9 million words.

iocaine seems to be doing just fine so far

accidentally set caddy to syslog every request sent to iocaine 3 and oh gosh my website is pumping so much poison markov trash into chatgpt and claude rn 😍 💕

and it's using less cpu and memory than systemd-journald to do so

might need to look into setting bandwidth limiters on this thing

i'm still casting around for anti-cloud(flare) mechanisms of regional failover. like if the cable to the datacenter i use gets cut, or there's political upheaval, how to automatically shunt traffic to a different datacenter faster than a dns update would propagate through caches

i'm vaguely aware of this technology called anycast but i don't know much

https://grebedoc.dev/ uses https://rage4.com/ to do it

https://en.wikipedia.org/wiki/Anycast

up front: cloudflare and aws are non options

still trying to figure out how to shunt traffic to a backup vm elsewhere if my nearby vm faceplants

seems like my options are:

for now i'm experimenting with https://bunny.net, whom i haven't heard bad things about but they're in the middle just like cf 😕

Rage4 Networks Polska

Affordable, best of breed, state-of-the art DNS service for reasonable money

@pho4cexa unless I'm really missing something, rage4 is not very meaningfully different from any other GSLB service (although I know nothing about the actual consumer offerings available here, it may be totally in line with what you can get elsewhere)

For "real" anycast (that's visible on the public internet), you need to have a
/24 for IPv4 or a /48 for IPv6, and you can only do anycast on the entire block at once. (You can do whatever you want when routing inside of your network, but you could already receive the packet and do that anyway).

Rage4 is doing anycast on their network (presumably), and then they route the packets to you once they receive them. They might
truly do anycast within their private network (to let you receive the traffic), but this doesn't seem functionally different from a load balancer of another type, where any CDN will also be doing anycast.

I don't actually know anything about products that would be within your price range, but I'm happy to talk more about anycast on larger networks if that helps in any way.
@brie thank you so much for the reply. just learning the "GSLB" acronym has been helpful in searching up info and comparative services.
@pho4cexa happy to help

Or, like I said, happy to answer any other questions. I mostly know this stuff from the perspective of a larger company, I know less about hosting smaller services. All of my self hosted stuff is low availability: everything is on a single server, if it goes down I have issues. (Except for DNS, that's resilient and I can answer questions about DNS set up)