jdev - 2022-01-21

everyone and their brother has a `sendxmpp`, does anyone know of a `receivexmpp` ? and/or how do you do automated end-to-end tests ?

of the "spin up server, send message, ensure message was recieved" variety

moparisthebest: Clix?

Never used it, just heard it mentioned

http://code.matthewwild.co.uk/clix/file/tip/clix/receive.lua looking likely, thanks qy !

ah https://matthewwild.co.uk/projects/scansion/ but I actually need to control how the client connects so probably not

actually this looks perfect https://matthewwild.co.uk/projects/scansion/character-classes/client/

moparisthebest, what's your goal?

there's my xmpp-blackbox-exporter for monitoring tests (I can imagine making it support messages one day), aioxmpp does have an end-to-end test suite used in CI of both aioxmpp and at least OpenFire

scansion is used by prosody e2e tests

(for a certain definition of e2e, though)

moparisthebest: I have a thing for that. Right now it's not made to work outside my own project, but a minimal front end could make it scriptable https://pkg.go.dev/mellium.im/xmpp/internal/integration

Finally merged IBB support… the last time the design doc where I decided to do this was modified was a tiny bit over 2 years ago. That one took a while :)

jonas’, the goal is to set up 2 servers (prosody for now), a DNS server (bind9 probably), and have a client connect to each server and send/recieve a message successfully

It's the kind of thing scansion was designed for, but there are plenty of ways to do it

moparisthebest: what is the thing you are actually testing?

Sam, xmpp-proxy, so DNS lookups, TLS validation, the connectivity between client and server and server and server

MattJ, yep scansion seems perfect for the client end, for the rest I'm thinking docker-compose looks like a good fit but open to suggestions

Yep, I'd definitely reach for docker-compose (or terraform if you want to extend to *actual* servers rather than containers)

oh nifty, I guess I've seen this at some point because it was in my broweser history but I had forgotten. this might be useful to me too if I added it to my integration test library; thanks.

during POC stage it was fine to test manually with 2 prosody's and gajim on my LAN but that's beyond annoying to continue haha

Sam: your test library requires the program, eg prosody, to be installed locally looks like? I guess it could be ran inside a container

Yah, it doesn't download it or anything, it expects to find it in the path. It could be modified to point it at an existing instance easily enough though, probably with an option to locate prosody instead of starting it

For now I have to do some pretty obscene things to the prosody config so I'll take a manual approach I guess

Yah, that's one of the reasons I wrote that library instead of just spinning up a container (I wanted to be able to control the config easier)

plus I have to point it at a custom DNS server and make it trust my fake certificate authority, all really hard/annoying to do locally but trivial with a container

I always just generate a self-signed cert and feed it to both prosody and the client, but at some point I should probably figure out a better way to handle that in case I need to test anything around certs later

Actually, I was forgetting, the big issue I've had when trying to run this in containers is that they refuse to let me fork as anything other than root (even though everything is root by default and I can never figure out how it's possible to get permission denied)

Mostly it's not an issue, but one day I'm going to think something's working and it's going to turn out to be failing as a normal user and I'll be sad.

I think it'll be possible to run all this with rootless podman which would be the ideal situation, but, guess I'll find out :)

I've never looked into how that works; I assume everything in the container is tagged as being owned by the user that executed podman and if you try to do root-y things it will fail?

it uses the linux feature to "allow user X to use UIDs/GIDs 10000-11000" so each user in your container can have their own uid/gid but all mapped to you

and depends what you mean by root-y things, like you still have "root" inside the container and can delete / inside the container etc

oh right, that makes sense

Inside the container is the big problem for me. I can't understand why "sudo -u prosody echo test" works but "fork(prosody, echo test)" or whatever doesn't

with rootless, sudo shouldn't work but fork should, I think...

I'm pretty new to rootless containers though, I've basically only used them for builds so far

Sudo would still work because like you said you're still root inside the container, no? I dunno, I don't really understand Unixy things like this. Been a long time since I did ops work that required debugging this kind of thing

I only know it doesn't because I read this last night lol https://www.redhat.com/sysadmin/sudo-rootless-podman

My only real experience running this in containers was getting it going on Codeberg CI as an experiment. The issues were mostly just "things are root and ipv6 isn't supported", so I have very limited experience TBF

It uses a user namespace

And tl;dr sudo will never work in a user namespace

oh yah, that makes sense

I used to do this sort of thing for a job; I don't think I realized just how much I'd forgotten.

Heh

That makes me wonder if fork/exec is just disabled in this container. I wonder if this CI system supports --privileged

process count limits mebbe?

hmm, nope, --privileged doesn't fix it locally either. Oh well.

Not that it really matters, it's someone elses CI with no secrets on it and limited network access, prosody can just be root.