Cloudron Forum

@SirFiChi yes please send to support@cloudron.io I will see it there

@james Yes, I know very well that Repos is not managed by Cloudron, but whole process can interfere with Cloudron installations and be critical specially when configuring a new Cloudron in a case of disaster recovery or switching Cloudron instances with backup/recovery, or simply when installing a new Cloudron instance. In fact, if repository cannot be reached, Cloudron cannot be installed. Hetzner give a good guide on how to switch, and also their repository is always reachable, fast and stable. How @robi suggested, it could be interesting to add to Cloudron install script some strings to avoid this kind of issue. Could be a speedy mirror or ability to pass parameter in ./cloudron-setup eg. ./cloudron-setup -h or something where user can chose wich mirror to use. -h = Hetzner, and so on. At this point, script will manage all the whole process and continue installation of packages and Cloudron instance.

Hi @james so the fix will be in the 9.2.0 release ? Do you know when this will be pushed ? I am now on 9.1.6 and cloudron says it's latest ? I am waiting for this fix to lauch a project to production

@imc67 said: In “What’s coming in Cloudron 6.3”, I suggested features inspired by Wordfence including blocking by IP/location and geo-blocking, and specifically calls out the idea of geo-blocking of countries as a desirable security improvement. https://forum.cloudron.io/topic/4723/what-s-coming-in-cloudron-6-3/4 You got an upvote for me in any event, but for this feature: https://docs.cloudron.io/guides/community/blocklist-updates

@LoudLemur well done, sounds like you have had fun (!). I'm not clear. You mentioned your production system - is that your own build or using my ALPHA community app ? Or you already cloned/fixed mine ? If the latter, I can try to make changes as you describe. But I am in the middle of a couple of big projects, so it won't be immediate. If timing is an issue, you might want to clone/fix and publish your own repo/community app.

Can’t answer for their business decisions - it is a slot you backup to. I’ll feed this back to them! Thanks for the reply. Edited to add: Turns out the slot was a jailed ssh so I could just ssh-copy-id from my machine instead of going through their client portal. All good, able to use sshkeys now!

Via a custom script - when I change a version, I have to do this in several places in the app, so I wrote a script where I specify the version number and it does this automatically.

Both. I want to understand if both are correct programmatically, but I can't test them against having an existing docker image, because I find that counter-intuitive - why would I build the docker image before knowing if everything is correct?

@andreasb said: it looks like notify_push is up and running I honestly don’t understand how you managed to get this working. I spent about 5 hours today trying to set it up and still didn’t get the result I expected. @reboot cron job simply doesn’t work. It’s mentioned in the docs but I’ve never seen it run in the logs. @service does run but only once. Аfter subsequent Nextcloud restarts the job never triggers again. My version of the script works fine if I run it manually from the terminal like this /app/data/notify_push.sh. The service starts and all checks pass. root@71780ea5-011c-4c09-886e-5f7e17e0b670:/app/code# /app/data/notify_push.sh ; sleep 1 ; ps aux | grep notify_push ; ss -tlnp | grep 7867 ✓ redis is configured ✓ push server is receiving redis messages ✓ push server can load mount info from database ✓ push server can connect to the Nextcloud server ✓ push server is a trusted proxy ✓ push server is running the same version as the app configuration saved => notify_push started on port 7867 root 265 0.3 0.0 25676 8796 ? Ssl 15:57 0:00 /app/code/apps/notify_push/bin/x86_64/notify_push --allow-self-signed --nextcloud-url http://172.18.20.152 --port 7867 /app/code/config/config.php root 286 0.0 0.0 4104 2100 pts/1 S+ 15:57 0:00 grep --color=auto notify_push LISTEN 0 128 0.0.0.0:7867 0.0.0.0:* users:(("notify_push",pid=265,fd=10)) If I set up a cron job to run every 5 minutes. */5 * * * * echo "=> Enabling notify_push" && /app/data/notify_push.sh I can see in the logs that everything looks fine: Apr 16 18:30:41 ✓ redis is configured Apr 16 18:30:41 ✓ push server is receiving redis messages Apr 16 18:30:41 ✓ push server can load mount info from database Apr 16 18:30:41 ✓ push server can connect to the Nextcloud server Apr 16 18:30:41 ✓ push server is a trusted proxy Apr 16 18:30:41 ✓ push server is running the same version as the app Apr 16 18:30:41 configuration saved Apr 16 18:30:41 => notify_push started on port 7867 But in reality the process doesn’t survive after the script finishes. If I check manually with ps aux | grep notify_push ; ss -tlnp | grep 7867 there’s nothing in the terminal. Claude suggested this might be a cgroup-related issue in containers. The process started from cron gets attached to its cgroup and when the cron job exits, the process is killed along with it. I’m not sure how accurate that is. Maybe most people who claimed to have notify_push working probably didn’t verify it properly, since the warning disappears from the Nextcloud admin panel. It looks like it’s working, even when it actually isn’t.