Cloudron Forum

@girish said in Expand Matrix app features:

Maybe we can have a single matrix integration app. I think my initial question still remains: are integrations run in-process or out of process? Does anyone have experience running these? If it's out of process, we can just bundle them all together as a separate app. If it's in-process, we have to see if these can be installable as plugins (like WP/Discourse/NodeBB plugins).

@girish Your question is a year old but is something I've been thinking about of late, so thought I'd weigh in here on a couple of thoughts:

• There is an open source alternative integration manager to the one that the matrix folks put out there: https://dimension.t2bot.io/. It adds some useful things from a cloudron perspective: the ability to more "natively" integrate a cloudron etherpad, inc. with authentication (vs the public one) and to integrate things like the Cloudron Jitsi as a widget. This would provide a nice way to tie together a variety of Cloudron apps into the Matrix/Element whole. It sits separately and would be a separate app.

• Having said that, to my mind the biggest things to add would be bridges to Signal and WhatsApp. I have previously set up the Signal bridge (on my laptop and, as a result, only available to a local CLI client) and really liked it. Since then, I've taken out a personal Element One account to experience these two bridges further and really love it. I think it is the killer feature (and a reason why they charge so much for it!). So if it were me, I would focus less on the widget integrations and on these two additional bridges, plus telegram. From what I can tell, they can be run from unconnected to the container running synapse (as I did with Signal) or directly connected to it, which seems to make things easier to set up from the instructions on matrix.org (see the WhatsApp instructions: "If synapse is running outside of docker, you'll need to expose the port. Note that in most cases you should either run everything inside docker or everything outside docker, rather than mixing docker things with non-docker things."; Signal instructions are here; Telegram here). Both would be awesome and, I suspect, would be a real driver of people towards Cloudron generally. But to my mind, I would have WhatsApp, Signal and Telegram bridges built in as default with Cloudron if only because it would be incredible for marketing purposes for you.

Edit: additional language from instructions i wanted to highlight: "When you put the bridge and Synapse in the same docker-compose file, networking should work out of the box, which means you don't need any of the commented ports or networks things in the example compose file."

@girish Just to walk through where I think things stand on this and where some addition input might be needed even after the cron changes allow for autostart and to help anyone who comes here in the interim.

1. Because of the read-only file system, the HBP files cannot be set up as a background daemon run by the init system as detailed in the main guide: https://github.com/nextcloud/notify_push.

2. Nonetheless, HBP files can be made to work (with manual intervention after a reboot) as follows (slight changes/clarifications from above):

• Install (but do not enable) the Client Push app in Nextcloud
• Edit Nginx Find the local IP of your nextcloud container. In the main cloudron server navigate to /etc/nginx/applications and open the .conf for your nextcloud container. Add the location block lhere for push into that file, but changing the IP to the local IP of your nextcloud container. Reload nginx.
• Run the notify push binary. As currently there is no way to run it as a background task (see below) my recommendation here is to enter the container via the main server and use tmux/screen so that you can run the binary and attach the session. Run the following from the /app/code directory: ./apps/notify_push/bin/x86_64/notify_push --allow-self-signed --nextcloud-url http://[Local IP] --port 7867 -- /app/data/config/config.php. Note http, not https and local IP and not the nextcloud URL. The standard way is to use https://[nextcloud url] and you can try it but I believe you will ultimately have trouble with the trusted proxy settings and will need to bypass the proxy server. This appears to be a fairly common issue. Detach the tmux session so that the binary keep. running.
• Update the Nextcloud Config adding the local IP address from above into the trusted proxy array.
• Enable the Notify Push App: occ app:enable notify_push
• Setup the HBP Files: occ notify_push:setup https://[nextcloud url]/push
• Check if everything works: First you should get only green ticks all the way down as it verifies if things are working. Then refresh any browser sessions and close and restart any desktop clients. After that run occ notify_push:metrics and there you should see that there are a number of active connections and requests being made. Then a really nice way to check if it is all working is to go into Talk and have someone (or another device) call you. You should see an instant notification of the call on your desktop (if you use a client) or in your browser vs before when you would have a 15 second delay.

3. Currently this all has to be done manually and will need to be redone whenever you restart the container (with exception of Nginx, which might only be overwritten when the server is rebooted). @girish has fixed things so that from Cloudron version 7.2.1 we can run cron jobs on reboot. So now we need to get things lined up for that. The solution is partially outlined here. We need to put a script in a folder that isn't overwritten, such as the nextcloud config directory and have it run on reboot. A working script would look include:

#!/bin/sh
NEXTCLOUD_BASE="/app/code"
NOTIFY_PUSH_BIN="$NEXTCLOUD_BASE/apps/notify_push/bin/x86_64/notify_push"
if [ -f "$NOTIFY_PUSH_BIN" ]; then
  "$NOTIFY_PUSH_BIN" --allow-self-signed --nextcloud-url http://[Local IP] --port 7867 "$NEXTCLOUD_BASE/config/config.php"
fi

But that will not be sufficient. This will need to be preceded by something that would add the local IP into the config.php file (because this will be overwritten), and followed by the occ enable and notify_push commands in order to get this to work.

My assumption is that this could all be put into one executable and then we can simply have instructions on the cloudron man pages for anyone who wants to enable the HBP Files. Any help with writing this would be much appreciated.

It would be super-useful if there were an option to use an external turn server instead of the Cloudron one. Since our server sits behind a Cloudflare proxy, the Cloudron turn doesn't work out-of-the-box. It can be made to work on an app-by-app basis by changing the turn server address from turn.example.com to the real IP address or by using an external turn server. But neither option is persistent, getting overwritten each time there is an app restart. So an option to set the preferred turn server would be super-helpful to avoid having to do this manually each time.

@robi It's been open source for a while now. I think that was two years ago.

Having said that, there is a nice unofficial docker for it. A nice way to get protonmail into, for example, Nextcloud Mail.

Would be keen to figure out how to package it for Cloudron to make things easier to manage.

@girish @avatar1024 I was trying to follow this just now and am confused how you even got that far. It seems like @avatar1024 was able to create the systemd unit file, but I can't get anywhere with that because it's a readonly file system. Am I missing something here? Is there a way to place a new systemd unit file within a cloudron docker container? [Otherwise, I'm wondering whether @avatar1024 put the unit file into the base of the cloudron server, and not the docker container, which would explain why it doesn't find the relevant binary and config].

It would be really useful to figure this out and understand where and how I must put a systemd unit file within a read-only container. Or if not that to otherwise know how to create a binary that won't get overwritten on restart, but would rather autostart (see e.g. how linuxserver containers do this: https://github.com/linuxserver/docker-nextcloud/issues/194)

Beyond that, it looks like I have been able to get notify push to work by simply calling the binary itself within the nextcloud container. The steps I took were as follows (following this guide https://github.com/nextcloud/notify_push) :

1. Install and enable notify_push app in Nextcloud
2. In the terminal of the nextcloud container directly run the binary with the relevant variables (./app/data/apps/notify_push/bin/x86_64/notify_push --allow-self-signed --nextcloud-url https://[Nextcloud URL] --port 7867 -- /app/data/config/config.php)
3. In the overall cloudron server edit the relevant nginx config for the Nextcloud container to add the location block as per the github readme (changing the IP address to that of the container) and reloading nginx
4. Open another terminal for the nextcloud container and add the relevant IP address to the trusted proxies array in the Nextcloud config.php
5. Enable the app (occ app:enable notify_push)
6. set the url of the push server (occ notify_push:setup https://url/push)

Once done I get a nice confirmation that everything is working with green ticks for all of the relevant parts:

✓ 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

And when I run occ notify_push:metrics it gives me metrics that appear to confirm that everything is working well.

So, as I say, it all seems quite possible, though nothing is going to survive a reboot and I'd love to find a way to at least autostart running the binary if not setting it all up as a systemd service within the docker container. Any help would be much appreciated.

@jdaviescoates said in Jitsi session recording:

Ah, yeah, I see now having read a little more about Jibri that is basically works the same way as how recording locally with OBS works: another (OBS or Jibri) user joins the meetings and it gets recorded by that user.
And, yeah, given it can only record one meeting at a time anyway, and hence it takes a whole other Jibri instance per meeting one wants to record, I think for now the easiest option is for me to just record locally using OBS.

You've landed on the right solution if you ask me. Over the last few years I've occasionally tried to add Jibri for recording on our Jitsi and found it not at all worth the hassle. Far better to use OBS for general recording (or indeed live streaming as you have more options), which we do regularly.

If you really want a service that has good recording in-built I would suggest BigBlueButton. For conferences and webinars where you want to have a really useful record, the recording feature in BigBlueButton is stellar. You can start and stop as you wish and it will seamlessly put it together into one stream. It records the chat and slides (if any) and in playback you can manipulate to focus on what you want. And you can immediately forward to a particular slide and the discussion around that. There's also a failsafe if you forget to actually press record, which allows you to resurrect the whole thing if you catch it in time (i think 24 hours). It's really an unbelievably good recording solution and one that is properly built into the server, as a major feature, rather than an add on.

@girish it looks like this simple script works:

#!/bin/sh
NEXTCLOUD_BASE="/app/code"
NOTIFY_PUSH_BIN="$NEXTCLOUD_BASE/apps/notify_push/bin/x86_64/notify_push"
if [ -f "$NOTIFY_PUSH_BIN" ]; then
sed -i "/[Trusted_Proxy_IP_0_in_config.php]/a \ \ \ \ 1 => '[LOCAL_IP]'," $NEXTCLOUD_BASE/config/config.php
sudo -u www-data php $NEXTCLOUD_BASE/occ app:disable notify_push
  "$NOTIFY_PUSH_BIN" --allow-self-signed --nextcloud-url http://[LOCAL_IP] --port 7867 "$NEXTCLOUD_BASE/config/config.php" &
sudo -u www-data php $NEXTCLOUD_BASE/occ app:enable notify_push
sudo -u www-data php $NEXTCLOUD_BASE/occ notify_push:setup https://[NEXTCLOUD_URL]/push
fi

Save it into /app/code/config in the nextcloud container, make it executable and run it. Runs the notify_push command in the background, so no need of the tmux hackyness from my earlier post. It makes the set up simpler, requiring just installing the app in the Nextcloud portal, changing the nginx config (as per the prior post) and creating and running this script. The script adds the necessary trusted proxy before running the other commands, getting around the fact that it gets overwritten on restart of the container.

So now it's just about testing the cron concept you have and testing this out on others' systems to see if it works for all. Any feedback from others much appreciated.

@girish said in What's coming in 7.5:

@girish said in What's coming in 7.5:

Add optional flag for turn addon.

This is implemented now - redis and turn can be optional (depending on the app).

The turn option is huge, thank you! I cannot wait to implement it. Is it in the 7.5.0 pre-release?

@girish I'm pleased to say that it worked. I had to disable docker and box and reboot, even though I didn't get the exact error you mentioned but something else related to creating the network (duplicate network). I also had to reboot after enabling and restarting box because otherwise the upgrade got stuck, I believe for a similar network creation problem. But once I did that everything worked well and I'm now happily sitting with version 7.6.3 after two subsequent updates. Many thanks for the help with this! Hopefully this thread will be useful for anyone else who might have this issue in future.

@brutalbirdie said in Add External Turn Server:

This is your case, not everyone is using Cloudflare.

Indeed, I know that this is specific to my case and that not everyone uses something like Cloudflare. But it is a big player, so worth addressing. As I say, it can be worked around and still use the Cloudron turn by using the real IP instead of the domain name in turn configs. But that gets overwritten, and an option to use external turn server would, frankly, be very helpful indeed given some of the other challenges with the Cloudron turn server that you highlight.

[By the way, and not related to my specific request, I will say, that I have had fits in the past trying to get the BigBlueButton's suggested turnserver configuration working and really have found the whole 443 setup to be too difficult. So even for our BigBlueButton server, we've just ended up using an external turn server running on 3478 and 5349. The challenge I think is that the turn server monopolizes 443]

@potemkin_ai said in What's coming in 7.5:

@eganonoa just for my information - why are you looking for external TURN servers for Synapse/Matrix and NextCloud? What are the benefits?

A couple of reasons that make calls requiring a turn server not function well.

• We run our services behind Cloudflare, and turn servers don't work well (or at all) via reverse proxies like that as the server cannot accurately direct traffic to the correct IP addresses.
• Even if we didn't use Cloudflare proxying, we have many calls with people in academic and government environments with policies limiting what ports they can connect to, usually only allowing 443. Because Cloudron monopolizes that port its turn server has to run on a different port, so those people cannot use the Cloudron turn server even if we turned off Cloudflare proxying (which we don't want to do).

As a result, the ability to use an external turn server with Cloudron is critical and a very welcome development.

@girish said in Nextcloud backup crashes:

@opensourced I have been testing things on the side and tried copying over such amount of data to a CIFS mounted Hetzner Storage and just cp -r command failed in the middle. rclone failed as well since the Hetzner storage box mount point disconnects/breaks randomly. I am getting farther with rsync but currently cloudron does not have an adapter for rsync. We are still working on this. Fundamentally, backing up 2.5TB of data reliably is a very complicated task.

All this to say, I don't really have a solution but if someone has ideas, I can try something else.

@girish A few years ago you helped me out with a similar issue (not on forums but via a support ticket) with backing up a large Nextcloud instance (2TB+). The issue was with timeouts and you advised how and where to update to extend the timeout window significantly. I was using a Hetzner Storage Box in Germany and a VPS in Sweden using a CIFS mount. Later I moved it to an sshfs, rsync to a local server.

This fixed the issue and allowed me a couple of years of backups of that large Nextcloud instance (with many other apps running concurrently) without problem. I don't have those emails any more or access to that instance but wanted to mention in case a reminder is useful to you here as it seems to be a similar issue.

@nebulon Thanks. If there is someway to do it it would be much appreciated. I know it is somewhat niche, the problem we're having is caused because of proxying via Cloudflare. It impacts Nextcloud and, even more critically, Matrix/Element.

With Nextcloud you can manually edit the external turnserver every time you've rebooted and it will work fine because you are doing it via the Nextcloud interface, so it is just an annoyance.

But with Matrix/Element that does not work, as you need to edit the homeserver.yaml and then restart synapse. If you reboot the Matrix instance entirely, then it will completely override the turnserver settings in homeserver.yaml. And we've tried restarting synapse via synctl (in /app/code/bin, pointing to the homeserver.yaml in /app/data/configs), but that doesn't appear to perform a true running restart of synapse. So we're basically stumped there unless we stop proxying via Cloudflare, but that provides an important level of security for our system.

Before we moved to Cloudron we were able to make it work using an external turnserver, so we know it works. We just cannot find a workaround with Cloudron's overwriting of the turnserver settings. So, in case the whole system change to allow an external turnserver is too much, we'd really appreciate if there was some change in the Cloudron matrix, as we roll it out across our community.

@girish said in What's coming in 7.5:

@eganonoa synapse update is now pushed and has optional turn.

Really wonderful. Thank you. Now restarting matrix does not overwrite that section of homeserver.yaml, with the added bonus that if you ever want to revert to the in-built turn you just "flip a switch" as it were and the settings revert to default. That's a very nice implementation.

@jdaviescoates said in Jitsi session recording:

To be clear, you record using BBB, and then record the mixed together BBB playback using OBS?

Exactly. Takes additional time, of course. But gives you complete control over what you are posting online. It allows you to manipulate the BBB recording session in playback to emphasise the things that you want emphasised. Ensures that you can cut out anything that a participant wouldn't have wanted posted. And, I think most importantly, gives you a period of pause and reflection to think about whether actually the thing you are posting should be posted at all.

@girish I was just now wondering whether cron could do something like this! That seems ideal. I'm going to see if I can make it work.

Noticed that the app-level nginx conf is getting overwritten daily, breaking the backend. Am trying the fix suggested by @girish here.

@necrevistonnezr

"…. but you can’t do that as a Cloudron admin or was that directed at @girish ?"

Sorry, I don't quite understand what you are meaning here. If you mean, can a Cloudron customer add something into /app/code/config and have that survive a reboot, surprisingly the answer is "yes". That folder isn't read only and whatever is put in there survives a reboot.

"Have you noticed performance improvements - in particular against the improvements coming with NC 24?"

Keep in mind that we are only a small team (10 people). They say that the speed increase will only be marginal for a team my size.

Having said that, yes! We're noticing a big increase in speed on two fronts:

(1) File Sync: Last Tuesday I was giving a new person a walk through Nextcloud. I was showing how sync works by creating a new file on the cloud and showing how that shows up on the desktop. It took forever for it to happen and was a bit embarrassing given all I had said in advance. Now it is as close to instant as you can get. Create new document online and immediately see it reflected on the desktop. Very nice.

(2) Notifications These are nearly immediately coming through. Start a call and the "join call" button shows up on the desktop within 2-3 seconds. Send a direct message to someone and it seems to nearly instantly arrive.

As it happens, I did this before upgrading to NC 24, but also wanted to see how things work with it, so did an upgrade. I don't see NC 24 adding that much additional speed to those two things vs the HPB files. But NC 24 is clearly a positive upgrade, just from a day of use. Getting positive comments from the team on the browser performance (inc. people in places with much worse internet than me). Some nice additions to certain apps (e.g. mail, office, text editor, all noticeably improved, file locks on desktop files being edited online). And if you are on Windows and presumably Mac you can reply to directed messages from the desktop client (sadly we use linux desktops so don't have that).

All-in-all I'd say we had a solid upgrade with Nextcloud between figuring out the HPB Files (that was the biggest) and NC 24 (a smaller but meaningful upgrade) (in addition to recently adding the high-performance back-end for talk). Would love to see what happens if/when Cloudron updates to PhP 8. But irrespective Nextcloud is getting closer and closer to being an all-in-one solution for us, which is pretty nice. Not there yet, but I can imagine it now that things are snappier.

@girish said in High Performance Back-end for Nextcloud Files:

@eganonoa thanks for the notes! I will test this out once we have get 7.2 out and see how we can fix up nextcloud.

Awesome. Thank you. Glad I've been able to help out somewhere. Cloudron is a very important business to us.

@chetbaker I think there are plenty of alternatives, but not a single all-in-one suite.

Etherpad, for instance, is in my mind as good as it gets for collaborative document editing. I say that because it is fast and light. And because I think the idea of people collaborating over a document's format (i.e. the final document) is just silly. People should be collaborating over content and then sending the final document to someone to produce the published/finished version.

Collabora is becoming really great (but, again, I really do not believe you need a full-featured suite for collaborative work).

Nextcloud, for instance, does group folders and file sharing much better than either Google or Office 365, which have always ended in a mess. I also think Nextcloud has by far the superior administrative options, especially for a smaller organization needing something simple.

Slack and/or Element are significantly better chat clients than either Google or MS offers.

Similarly, Jitsi, BigBlueButton and Zoom each do group calling better than what Google and MS offer. And Nextcloud talk is, I think, the very best for one-to-one calls.

There are loads of Kanban services out there that provide excellent team management services. Nextcloud Deck is pretty OK in this regard.

Google provides the gold standard in calendaring and email. Nextcloud's calendar is pretty good, but not nearly as good. Outlook is alright, but Gmail and Google Calendar are still the best.

etc, etc, etc.

The fallacy, I think, is that you need one single cloud service to provide everything. I'd rather specialist services, with something capable of tying things together. Nextcloud does a pretty good job of that. You can piece a lot of stuff together in one place, inc. element, jitsi, bigbluebutton, etherpad, though the mail client is seriously lacking. Element is also quite good at bringing various things together.

But, the one thing that I think gets missed in all of this is the desktop! This is still the place, and the OS itself, to bring everything together in one place. And if you look at it like that, the whole idea of one cloud portal that tries to do it all (whether Google, MS, Zoho, Nextcloud, or whatever) seems ultimately a silly idea: both unobtainable and not sufficiently flexible or specialized enough.