Cloudron Forum

@girish Thanks a lot for this great support and that you want to take a look at it It's not a must have, but it come's very handy for monitoring my Cloudron instance and get warnings if something goes weird or reaches high loads. Netdata is also something i did not think about earlier, so maybe that will workout for me as well. I must say (apart from this topic), i am really 100% satisfied till so far about Cloudron and the active community that's behind it. Many answers to my questions i did already find here in the forums Also a big thanks to the Staff of Cloudron, that picks up problems really quick and solve's them as much as they can. I hope Cloudron will live for a long time in the upcoming future, because it's the solution i was looking for a long time Really glad i came accros all this and thanks to everybody

@HulaCloud We don't have plans to support netdata out of the box but I think it's a good idea to atleast have some interoperability instructions. Let me give this a try and get back.

This appears to be someone/bot trying out common usernames in one of your apps. Unfortunately this is not too uncommon, but also not an a real issue if you have strong passwords. The requests will be rate-limited as well to prevent proper brute-force attacks. The internal IP is associated to an app, it may or may not change when an app is restarted. However the ldap logs might indicate there are multiple apps configured to use LDAP. The port is actually dynamic per request, so that is the reason why it does not show in docker ps/inspect

@mehdi Thats kind of scary, thanks for the correction.

@staypath Continuing my conversation with myself Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick: [sshd] port = ssh #logpath = %(sshd_log)s #backend = %(sshd_backend)s backend = systemd enabled = true maxretry = 1 bantime = 14d

@Trankery Is your comment somehow related to the original subnet question (or did you post in the wrong thread) ?

@oatwalker from those posts, I assume you installed mumble on the side on your Cloudron. While this might work, it could break on future updates as we cannot reliably test such setups. If you are interested, you might want to look into https://cloudron.io/documentation/custom-apps/tutorial/ to see how you could package mumble as a Cloudron app. Also the firewall would have been setup by the platform automatically then.

@988uh is there any update on this from your side?

@necrevistonnezr That is true, however the configuration steps are different than what has been described before when trying to work around this issue.

Ran into this again, with an easy solution since Cloudron already allows the TURN server port range, we can adopt it for mosh client side. Simply explicitly ask for a starting port and it will connect: mosh -p 50000 user@host Otherwise server side: set the MOSH_PORT env var so mosh-server starts searching from port 50000: # System-wide for all users echo 'export MOSH_PORT=50000' | tee /etc/profile.d/mosh.sh

@niko was there any error restarting cloudron-firewall service or such? This should still work as expected, so maybe you hit a bug somewhere? Also could you share your ports.json config here so we can try to reproduce this? If you don't want to expose your port settings here, you can also send them to support@cloudron.io