XMPP Service Operators - 2021-06-14

> Am I talking crazy, here? I never used Movim, but I speculate it's how its Tenor integration works. At least it totally could work that way

Establishing a secure connection from lebihan.pl to joinjabber.org failed. Certificate hash: 9f340cb01d56d2858109b9a11143a0e834b4da4689769c493e227d07d957cb0c. Error with certificate 0: certificate has expired.

Anyone running coturn, see a lot of connection reset by peer in logs? Just wondering if that's reflection nonsense or what

rob: was discussed last month, move ports to random non standard, as XMPP clients get the port by XEP-0215

I have done that, just wondering if that's what the logs are caused by

Oh, you still get hits? I guess they could scan you and refind it Maybe a script to change the port daily in cron? :))

are them that dangerous to even bother?

maybe a netfilter rule would be more appropiate, like filtering away any IP without an already established TCP session

Not so much dangerous as contribute to a bigger problem

I can just change ports again

xorman: you can't, see backlog, your contact from the other server might endup using your STUN/TURN so you'll reject them?

oh right

The only thing for now is hiding behind different ports

I was thinking automating as well though, every day or so even. But would require communicating to and restarting the xmpp server

rob: ejabberd can reload, others dunno

Prosody too

Prosody only when run as a daemon or no? I'm running in docker

MattJ: tell us more :)

Of course then you have to reload it "inside" the docker.

Which means may as well just restart the container

If you don't mind restarts its perfectly fine of course

I guess I could try to change the container to run the server as a daemon instead of an init service

Then things like reload would work

rob, `docker exec container-name prosodyctl reload` ?

moparisthebest: doesn't work because in the container it's run with the init system

rob, presumably it's just a SIGHUP or something you can send with kill ? probably even from outside docker

Could be, I'll do some investigating

For now I've just changed ports again

But some automated script would be handy

Sighub sounds right. And then add what should be reloaded here: https://modules.prosody.im/mod_reload_modules.html

Oh nice, thanks

I finally got my smartd setup going with xmpp notifs

rob: care to share your setup?

The smartd part?

Or everything 🤓

yes

smartd+xmpp notifs roughly

are you using sendxmpp or what?

Yes I went with go-sendxmpp ✏

And I'll share the script and config in a few

But roughly the info on Arch Linux wiki

So the bash script is just: echo "$SMARTD_FAILTYPE: $SMARTD_MESSAGE" | /home/robbie/go/bin/ go-sendxmpp -f /home/robbie/sendxmpprc rob@loranger.xyz

And in /etc/smartd.conf: DEVICESCAN -m rob@loranger.xyz -M exec /home/robbie/smartnotify .sh However I think the -m address is unnecessary as the script has it hard-coded.

i need help

my employer gave me an adress to use to log on to the xmpp chat

and it isn't working

gave me two dofferent passwords and i believe one of them may have worked if the address was right

That's probably something only your employer could help you with

rob: > I finally got my smartd setup going with xmpp notifs I assume, using your own server? Is it running on the same system that smartd notifies about? :))

It is on both accounts mjk

I'm trying to setup pgp-encrypted notifications using a _public_ server. The xmpp part was working when I made some manual tests a few months ago, but now that I returned to the project, the (resumably) same setup sends me a message that Conversations can't decrypt. Oh well, back to debugging pgp. *muffled swearing*

mjk, keys expired? :)

I have a thing sending pgp emails and it breaks every few months when peoples keys expire. gpg error messages and exit codes are not helpful there.

rob: if/when I'll run my own server, I'll likely still rely on a third party for redundancy

Or is it 'second party' in this case? The sender and receiver technically being me. :D

Haha maybe 2nd

I have redundant disks plus off-site backups, but no redundancy for the server itself. However prosody does not support clustering afaik anyway

I might add some backup power soon, after I upgrade the internet connection to fiber ✏

jonas’: I _think_ my test key doesn't have expiration date set (or it's in very distant future), but I'll check that, thanks

rob: oh I merely meant sending (critical) notifications using accounts on two servers, at least one of which isn't on the same physical machine

Oh yes, that makes sense

Maybe we can trade accounts with other operators

That's an idea

mjk, isn't your XMPP server going down notice enough that your server is dead or :)

Haha ya

:D

Well there may be even more critical things needing attention than an xmpp server :shrug:

True, like a dead disk

So, "my xmpp server is down? Meh, probably power failure"

"Will deal with that later". Meanwhile, the disks are on fire :D ✏

but if the disks are on fire, it's not sending you that message anyway

Had a drive fail, xmpp kept running somehow, didn't realize until I rebooted around 7 hours after failure

Big gradient

moparisthebest: in my particular case, I'll likely run on a pi, with the server not depending on the usb-attached spinning rust. As an example

mjk, just a much-more-prone-to-failure sd card ? :P

Yes, lol

my rpi's all run diskless, nfs root on a server with SSDs

Nice

moparisthebest: I plan on doing that, but with a pi as an nfs server. i know i know...

x0n: rpi4 actually has real gbit nic, real USB3, and real pcie so it's not a bad choice

moparisthebest: indeed, the cm4 even exposes pci-e

Before rpi4 it was a pretty bad setup :)

i'm going with dual ssds in a zfs mirror pool for the root on that machine. over usb ofc ;)

Can you do mirrored boot?

btrfs raid1 can, but the system won't boot if a drive fails

have not yet tried that, boot from zfs does work though and the volume manager is built into the storage layer so my guess is yes

Харпер: yes it will, you have to pass a boot option though

moparisthebest: the degraded flag?

Sounds right

But your efi won't boot the other drive iirc

Because grub will update default flag to primary drive everyboot

Without choosing the boot drive manually?