3
@necrevistonnezr said in fido2support:
And I know many companies who have moved away from hardware keys or cards because of the excessive downtime when users forget those hardware keys somewhere.
Ah, yes. That could be a hindrance or mild annoyance. I find that having a password manager that supports passkeys is helpful as a fallback or a primary way to log in. That, or having users have two physical keys ideally. How do you create backups for FIDO2 keys?
Anything that can be phished will be phished. 
Seriously, though, I just want Cloudron to support better security, and FIDO2 beats OTP. I found getting keys physically or software into users' routines easier than getting OTP codes through apps or (shudder) SMS or Email.
I always try to design for as much stupidity as possible. Users display an amazing capacity for finding ways around security tactics. It's worth making that part of the research during the design phase I think ;-0
What's your experience been?
To add my 2p to this topic: I currently cannot recommend Cloudron to businesses as OTP is phishable.
My recommendation to clients is usually to go with FIDO hardware keys and/or passkeys - especially for mission-critical stuff, thus I cannot recommend Cloudron because it does not support it
Ref. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf, https://www.sectigo.com/resource-library/how-phishers-take-your-one-time-passwords, etc
Sorry I didn't make myself clear, @girish 
The timezone displayed in Cloudron's settings should be BST (British Summer Time) instead of UTC+0, it should be UTC+1.
"In the UK the clocks go forward 1 hour at 1am on the last Sunday in March, and back 1 hour at 2am on the last Sunday in October. The period when the clocks are 1 hour ahead is called British Summer Time (BST)." - gov.uk
For example, my local machine shows:
axel@localhost-live:~$ timedatectl
Local time: Mon 2024-08-26 12:11:54 BST
Universal time: Mon 2024-08-26 11:11:54 UTC
RTC time: Mon 2024-08-26 11:11:54
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
...you know, the one with all the rain! 
️
My time zone is set to Europe/London and the time indicator shows (UTC+0) when it should be showing UTC+1 as it is currently Summer (looking out of the window makes a mockery of that season -ed) 
The server's timezone is set to UTC:
root@my ~ # timedatectl
Local time: Mon 2024-08-26 11:04:58 UTC
Universal time: Mon 2024-08-26 11:04:58 UTC
RTC time: Mon 2024-08-26 11:04:58
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Ref. https://forum.cloudron.io/topic/12255/timezones-w-r-t-backups/4# etc
Quick update to let you know that further testing resulted in some tweaks (will update main post soon) and that sadly email and anything needing different ports still does not work even through the magic of Tailscale 
TL;DR: Yes, you absolutely can run Cloudron through Tailscale (and plain-ol Wireguard too); No, it's not perfect and things that need different ports to 443 will likely not work without additional iptables tweaks if at all
Has anyone attempted to repackage WG-Easy or UI already? (ref. https://docs.cloudron.io/packaging/tutorial/)
@LoudLemur said in [Guide] How to host Cloudron behind a reverse proxy with Tailscale:
- Could you please elaborate on this section:
I'll be happy to try
A lot of people who have a home home/office connection do not have a fixed IP address. If and when it changes, they would lose access.
I meant the remote VPS in the datacenter, not the home server. Sorry, I will aim to clarify that in the next edit. You don't need to worry about opening ports and IP addresses for your home server (anymore)!
- Also, some people would be lucky to have 100 Mbps downlink. They might be tempted to just say to themselves, well I will make do with a 10 Mbps uplink and see how it goes...
I guess this depends on how you use it. I have two Nextcloud instances, one for work and one for the family. Both see quite a bit of use, but I'd struggle to say what the bandwidth allocation needs to be without investigating further.
I'd say 10mbps should be a minimum in both directions. You can also use Nginx Proxy Manager (etc) to cache static assets, but if you are sharing a lot of large media files you will either have to wait or pay for a larger VPS and host it fully remotely.
- Later in the Summer, Cloudron will move to Ubuntu 24.04.1 LTS. Will this section be updated then?
"Prepare the server for Cloudron
Install a fresh VM (ideally) with Ubuntu 22.04 (boo!)."
Ha! I was joking Ubuntu is OK, but I do dislike some of the (stuff they have been called up on before 
previously.
- If somebody could make a desktop recording showing this process, that would be great.
That's a cool idea, and I will look to do a live stream or recording of this next time I set it up. Anything in particular that you would find helpful I'd focus on during the process?
@necrevistonnezr true! Using a VPS with a fixed IP as your exit node is the way around it. You do not need to worry about your home IP, as Tailscale connects you up regardless
I hope I understood what you meant and answered your question. If not, please let me know.
Here's my guide on how to run your local Cloudron from home or office through a public reverse proxy server on a VPS in the 'Cloud' through Tailscale. No port forwarding or network acrobatics are required!
Procure and configure the VPS in the 'Cloud'. I use Vultr.com and you can get a $100 credit for two weeks to test things out (affiliate link) or DigitalOcean.com for $200 for 60 days (affiliate link).
I use Debian 12, but you can choose Ubuntu or something similar. Not tried it with RedH*t or Arch.
Ideally, you should get a VPS with direct access to the internet and an IPv4 address. Watch out as some providers try to save costs, and IPv6 and network shenanigans are out of the scope of this tutorial.
Install Docker: (ref. https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script)
curl -fsSL https://get.docker.com -o get-docker.sh | sudo sh get-docker.sh
You may need to install docker-compose separately:
sudo apt install docker-compose
Pull Nginx Reverse Proxy (or your preferred reverse proxy with Let's Encrypt SSL). I use Docker Compose to keep things neat. You can find out more here: https://nginxproxymanager.com/setup/#running-the-app.
Configure your firewall - I use the one at the provider - to only allow ports 80 and 443 to the public. Wall-off SSH (22) and the Nginx Proxy Manager's admin port (81) by only allowing access from your home/office IP(s) and or Tailscale network.
Install Tailscale and set it to accept routes (this is key):
curl -fsSL https://tailscale.com/install.sh | sh
Get Tailscale online and accept routes (important!):
sudo tailscale up --accept-routes
Make sure you have restarted and tested. You can see your node in the Tailscale control panel, and the routes have been enabled.
Ready? Let's go local.
Install a fresh VM (ideally) with Ubuntu 22.04 (boo!).
Set your VM's IP to be fixed via DHCP or manually, as we don't want it to change again.
Install your favourite tools, such as mc and qemu-guest-agent (if you're using Qemu/Proxmox), git, and curl.
Ensure you install Tailscale on the server and run it with the option to expose its route using the local IP:
sudo tailscale up --advertise-routes=192.168.X.X/32
Log in to the Tailscale control panel and enable the route!
Log on to your VPS and ping the VM's local IP to ensure our proxy can access the server.
ping 192.168.X.X
All good? If not, return a few steps and make sure your routes are exposed and accepted.
On your DNS for the domain you want to use, create two A Records, one for the root domain and one wildcard, both pointing to the VPS IP address.
On the VPS, login to Nginx Proxy Manager (http://<IP of VPS>:81) and create a wildcard SSL certificate for the domain (*.example.com).
Create a new reverse proxy entry using both the root and wild card, pointing at https://<local IP of your VM>:443.
Head over to the local VM and install Cloudron (finally).
wget https://cloudron.io/cloudron-setup && chmod +x ./cloudron-setup && sudo ./cloudron-setup
Once installed, reboot and log on to the configuration wizard (https://<local IP>/).
Now come the critical bits, which took me some trial and error. Be sure to snapshot the VM before you continue to avoid reinstalling everything in case you make a mistake!
If you are sure you have taken a backup/snapshot of your VM at this point, be braver and hit the 'Next' button.
It will take a while to check itself and present you with the Cloudron account set-up screen. If not, watch for errors in the log file (the path is shown on the screen).
If all goes well, browse my.<your domain>.<tld> and log in. If not, restore to the snapshot and try again. Feel free to post your comments and questions below, and I'll do my best to help.
Once logged on, head to settings and set up the backups. I use a local Samba share from my NAS and rsync (no encryption as the volume is already encrypted). This should make for fast, local backups. I just entered my local NAS IP address (e.g. 192.168.x.x) and login details. Remember that while Cloudron is served from behind the proxy on the VPS, the actual Cloudron server is on your local network and you can point it to local services
You can also set up other volumes on your NAS for photos or other stuff.
Check the email set up for our primary domain is working and it is probably showing some red marks if you chose manual DNS set up. In this case, head to your DNS and create the missing records shown in the error messages.
The reverse DNS entry (PTR record) will fail unless you change it on your VPS provider's DNS (where available). While you can host multiple Cloudrons behind the same Nginx Proxy Manager and IP, if you care about performance and email deliverability, I recommend a separate VPS and IPv4 for each or ignore the error and use an external bulk SMTP service like SMTP2GO or Mailgun.
Ensure everything you need is green, and double-check the error logs for messages. Once you are happy, install an app and enjoy your new Cloudron 
The next part of this guide will focus on using Tailscale to access the Cloudron service locally without going out of the network and back in again. One of the strengths of Tailscale (and similar services) is that it can connect services directly for lower latency and increased performance.
Let me know what else you would like to see. I post this primarily as a note to myself and share it hoping you found it helpful.
Let me know your questions or comments on how I accomplished this, and note that I am not affiliated with any of the service providers, Cloudron, or companies mentioned unless stated otherwise.
The help I provide on this forum is free and constitutes my opinion, not that of my employer. Professional services are available via the link in my signature - I cannot provide any paid support in this forum. No warranties are provided or implied.
Hi all, just moving back to Cloudron after a few months on Nextcloud AIO for reasons I leave to your imagination
I saw a few posts online about this topic and thought I'd share how I do it in case it is helpful. I'd love to hear your thoughts and how you do it, so leave me a comment below this post.
Step 1 - Prepare
Backups
Have a backup of your existing install!
DNS
Ensure your domain's DNS record(s) are set to a low TTL (time to live) because you may need to back out of the migration quickly. If it is set to something like 1 hour or longer, that's how long it would take to restore the previous status. Ignore this at your peril 
Comms
Arrange for a day and time with your users to migrate, as you must not have people log in and change stuff
Step 2 - Getting ready
Put the site in maintenance mode and take another backup. I also like to have a VM snapshot of the whole shebang to make backing out of the migration a click away. You can never have too many backups
Check that everything from step 1 is done, especially the user comms thing. You don't want a VIP calling you on Sunday morning to say they desperately need something.
Install the Nextcloud 'user migration' app and start exporting each user. I also like to use the 'impersonate' app to help speed things up for this. Depending on the amount of users and the size of their profiles, prepare to make a lot of cups of tea.
This process will take a long time, so plan for this. If you use a VM/VPS, increase the resources for the duration to speed things up.
While things are being exported, go and make a list of apps in use and their settings. This is a manual and tedious process, and I find screenshots helpful. You could do a db dump of the relevant tables and rows, but the manual route is safest, IMO.
The time-consuming stuff is user migrations and their data, not the apps.
Step 3 - Moving-in
Setting up users
On the new server, it helps to mirror the users and groups before you proceed with the app and data migration. This is a manual process. After the migration, I told the users they would need to reset their passwords.
Copy-n-Tea
Once you have a copy of everything downloaded locally from the old server and a complete record of users, groups, apps and their settings, go to your Cloudron and spin up an app. Downloading TBs of data may take a while... grab another tea (with a biscuit).
Hostname and DNS
If you like, turn off the old server and use the same hostname for the Cloudron Nextcloud. You could do this with a different name, but I assume you are doing a complete migration where everything stays the same.
The first time
Assign the user groups to the Nextcloud app and log in with your Cloudron account first, then log out as the new admin the app created and assign your Cloudron user admin rights. Log out and back in as yourself, then remove the autogenerated admin or disable it.
Step 4 - Apps
Install the apps you need and apply their configs before you migrate the users. Ensure you install the 'impersonate' and 'user migration' apps!
Step 5 - Users and data
One by one, use the 'user migration' app to upload and restore the user profiles.
Log in after each restore to check if it matches the old server (handy if it is still running, and you can log in). You may need to manually re-import contacts and calendars.
This process takes the longest, depending on the number of users and the size of their profiles. Make sure you have (a) tea (b) food and (c) a fast connection to the new server.
Step 6 - Checks and go live
Double-check that everything is working, especially email notifications and email app provisioning if used.
Check the error log and the security guide, and run a proper test to see if you get green everywhere.
Perhaps you like to pick a random user, create a file, and share it with an external test account.
Perhaps you don't and will get lots of angry users on Monday morning 
Step 7 - Turn off your phone and go on holiday
This step is optional but make sure you take a break after the initial hyper care period is over and the dust has settled 
You deserve a pad on the back, a pay rise and the admiration of your favourite person(s). Don't be disappointed if you don't get any of this because you chose to work in IT and it is a thankless world
But cheer up; you are in safe company in the Cloudron community and an open ear to hear how things went for you. Let me know in the comments below.
@nebulon said in LDAP Group support in Nextcloud:
Just a heads up though, in order to use groups, they have to be explicitly selected in the LDAP plugin settings UI within Nextcloud.
Please, can you provide the correct query to use? Just using (|(objectclass=group)) validates but shows 0 groups when it should show 11.
Otherwise, is there a way to specify a group to allow users access from?
Ah, it's a wee bit annoying... perhaps a note in our wiki will avoid disappointment:
When you first install it (or re-install it), you need to set the apps. It looks like this is by design for the self-hosted app.
I think you need to provision the apps first for the user to add them. This means you must set up Google and any other ones requiring API calls during the initial set-up. Otherwise, you will have to reinstall the app!
For Google and Microsoft, you need to create an app or otherwise generate the needed IDs and keys.
Fun fact: if you upload your profile image in the /getting-started/ wizard, it restarts the wizard ... but you neededn't worry as it remembers all your settings. If not, hit refresh again.
OK, render me confused (and thank you for your help by the way)...
I guess the self-hosted version can only use Google etc apps that I need to set up with my own API credentials first. I does not seem to allow CalDav (in beta it seems) nor ICS (broken currently).
My cal.com account works OK and as intended.
