XMPP Service Operators - 2021-06-14

  1. mjk

    > 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

  2. mimi89999

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

  3. rob

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

  4. Licaon_Kter

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

  5. rob

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

  6. Licaon_Kter

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

  7. xorman

    are them that dangerous to even bother?

  8. xorman

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

  9. rob

    Not so much dangerous as contribute to a bigger problem

  10. rob

    I can just change ports again

  11. Licaon_Kter

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

  12. xorman

    oh right

  13. rob

    The only thing for now is hiding behind different ports

  14. rob

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

  15. Licaon_Kter

    rob: ejabberd can reload, others dunno

  16. MattJ

    Prosody too

  17. rob

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

  18. Licaon_Kter

    MattJ: tell us more :)

  19. Menel

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

  20. rob

    Which means may as well just restart the container

  21. Menel

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

  22. rob

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

  23. rob

    Then things like reload would work

  24. moparisthebest

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

  25. rob

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

  26. moparisthebest

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

  27. rob

    Could be, I'll do some investigating

  28. rob

    For now I've just changed ports again

  29. rob

    But some automated script would be handy

  30. Menel

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

  31. rob

    Oh nice, thanks

  32. rob

    I finally got my smartd setup going with xmpp notifs

  33. xorman

    rob: care to share your setup?

  34. rob

    The smartd part?

  35. rob

    Or everything 🤓

  36. xorman


  37. xorman

    smartd+xmpp notifs roughly

  38. xorman

    are you using sendxmpp or what?

  39. rob

    Yes I went with go-semdxmpp

  40. rob

    Yes I went with go-sendxmpp

  41. rob

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

  42. rob

    But roughly the info on Arch Linux wiki

  43. rob

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

  44. rob

    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.

  45. ch1234

    i need help

  46. ch1234

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

  47. ch1234

    and it isn't working

  48. ch1234

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

  49. moparisthebest

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

  50. mjk

    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? :))

  51. rob

    It is on both accounts mjk

  52. 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*

  53. jonas’

    mjk, keys expired? :)

  54. jonas’

    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.

  55. mjk

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

  56. mjk

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

  57. rob

    Haha maybe 2nd

  58. rob

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

  59. rob

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

  60. rob

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

  61. mjk

    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

  62. mjk

    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

  63. rob

    Oh yes, that makes sense

  64. rob

    Maybe we can trade accounts with other operators

  65. mjk

    That's an idea

  66. moparisthebest

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

  67. rob

    Haha ya

  68. mjk


  69. mjk

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

  70. rob

    True, like a dead disk

  71. mjk

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

  72. mjk

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

  73. mjk

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

  74. moparisthebest

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

  75. Харпер

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

  76. Харпер

    Big gradient

  77. mjk

    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

  78. moparisthebest

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

  79. mjk

    Yes, lol

  80. moparisthebest

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

  81. mjk


  82. x0n

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

  83. moparisthebest

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

  84. x0n

    moparisthebest: indeed, the cm4 even exposes pci-e

  85. moparisthebest

    Before rpi4 it was a pretty bad setup :)

  86. x0n

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

  87. Харпер

    Can you do mirrored boot?

  88. Харпер

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

  89. x0n

    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

  90. moparisthebest

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

  91. Харпер

    moparisthebest: the degraded flag?

  92. moparisthebest

    Sounds right

  93. Харпер

    But your efi won't boot the other drive iirc

  94. Харпер

    Because grub will update default flag to primary drive everyboot

  95. moparisthebest

    Without choosing the boot drive manually?