Bare metal Nextcloud installation reddit / selfhosted ---------------------------------------------------------------------- BeebBoobBot · 2023-12-23 09:58 I wrote a bare metal Nextcoud installation tutorial. Maybe someone here want's to setup Nextcloud over the holidays. The goal of this guide is to have no warnings in the admin center and the instance should get a perfect security score from scan.nextcloud.com. The official documentation is pretty good, but it can be a little bit overwhelming to newcomers because you need to jump from one topic to another and have to read up on multiple things. This guide should offer you a more streamlined experience. [https://github.com/jameskimmel/Nextcloud\_Ubuntu/blob/main/nextcloud. md](https://github.com/jameskimmel/Nextcloud_Ubuntu/blob/main/nextclou d.md) Would love to hear some feedback. English is not my native language so language feedback would also be appreciated. Happy holidays and good lucky with your selfhosted projects. ---------------------------------------------------------------------- ro55mo · 2023-12-23 10:43 Your language looks pretty much perfect. Only one comment. What if your server host name is different from the name of the SSL cert you want? Can certbot be configured to take account of this? ---------------------------------------------------------------------- Fire597 · 2023-12-23 11:33 Seems pretty good to me. I wish I had this tutorial when I setup mine. ---------------------------------------------------------------------- BeebBoobBot · 2023-12-23 11:49 Thank you :) Regarding your question, I am not sure if I get it. The SSL cert has to be the same name as the server hostname, otherwise a browser would throw an error because of the mismatch. If my SSL cert is for nextcloud.mydomain.com but my host is cloud.mydomain.com it won't work. Certbot will automatically scan your VirtualHost ServerName, ask if it should get a cert for that domain and then try to get one. Hope that helps and answers your question. ---------------------------------------------------------------------- ro55mo · 2023-12-23 12:20 You have answered the question in saying that certbot uses the 'VirtualHost ServerName from Apache2'. I thought you were saying that certbot (I don't have experience with it) would use the name from /etc/hostname ---------------------------------------------------------------------- KD_done · 2023-12-23 14:01 I compared your manual with an old checklist of mine, and it lines up .. so, seems valid! Actually.. I have to do a migration from one box to the other, so.. I'll use your manual. There is one point of critique that I have, which is "Split DNS". It's a circumstance, not a requirement for a successful installation of Nextcloud. And what I mean by that a Split DNS for you was correct way to go in your case. Don't start with that, but give it as an added "bonus" instruction. ---------------------------------------------------------------------- mousenest · 2023-12-23 17:29 Yes it can. You can setup to get several certs. In some of my VMs I have it get the hostname and several CNAMEs that map to it as well. ---------------------------------------------------------------------- Pico_me · 2023-12-24 03:07 Can you use this with cloudflare tunnel? Like are there some extra steps that needs to be done ---------------------------------------------------------------------- BeebBoobBot · 2023-12-24 09:43 That is a good input. I get where you are coming from. I think it is basically a requirement for a Nextcloud instance, because otherwise is almost unusable. I experienced that for myself. I went with dual stack, but the amount of times when my Laptops (macOS and Windows) woke up from sleep and used IPv4 instead of the preferred IPv6 and then I got a cert error and had to restart the Nextcloud client was pretty high. Sure it is technically not a requirement for the installation, but it is one for normal use. Another reason is that I don't wanna lure people into installing it locally instead of a VPS just so they find out in the end further requirements. I think I will change it to this: Rename it to requirements, mention the VPS option and while we are at it also add the CG-NAT problem. ---------------------------------------------------------------------- BeebBoobBot · 2023-12-24 09:55 Unfortunately I can't answer you that question because I never used Cloudflare. My guess is that it should work, you would swap cloudflared with certbot. Exaggerated rant: To be completely honest, I never understood why the /r/homelab and /r/selfhosted had such a high opinion of a man in the middle attack from a tech giant. I have heard that it is pretty easy and pretty secure. If you use a simple router and host some not so secure software like Jellyfin, I get that you would use Cloudflare. But for something like Nextcloud, where you have brute force detection and 2FA I don't really see the need for this. ---------------------------------------------------------------------- BeebBoobBot · 2023-12-24 10:21 > I thought you were saying that certbot (I don't have experience with it) would use the name from /etc/hostname Ahh sorry for the misunderstanding, no that is not what I meant. I edited it. Certbot does not care about the servername of Ubuntu. That is a great input, thank you very much! I will change that. ---------------------------------------------------------------------- KD_done · 2023-12-24 13:55 But what you are describing is a requirement for your network, not for Nextcloud :) You description of normal use is abnormal for me, overly complicated and an admin nightmare in MY network.. but at the same time it's your ideal way of getting it online. Like I said, it's not wrong, but it's not a part of Nextcloud. And telling other people it is would suggest they have to change their network or way of working to make use of Nextcloud. We can argue on the use of proxy servers, NAT, nameservers and what not, but they are not as you said "necessary". ---------------------------------------------------------------------- Mensch88 · 2023-12-25 06:56 and now version with docker-aio behind reverse proxy would be good because the official one is weird ---------------------------------------------------------------------- BeebBoobBot · 2023-12-25 09:41 > You description of normal use is abnormal for me, overly complicated and an admin nightmare in MY network Hmm... how would you make it simpler? What makes it an admin nightmare? Am I overlooking a possibility? I would guess that a VPN is probably the easiest way but then you can't share files with others. > but they are not as you said "necessary" Not sure if I would agree on that one. Let's assume you like most newcomers just want to use IPv4 but also wanna reach it from outside. Would you not setup the Nextclient client on your laptop and your smartphone? Both would not work inside your Wifi because you get a cert error. ---------------------------------------------------------------------- KD_done · 2023-12-25 21:54 Let me skip the boring talk about design at work and what is "normal", because lets be honest.. all regulations/restrictions.. pff, humbug. Lets cherry pick the best parts of that corp culture. Lets build a service. Lets build a very legit service that offers movies, you know, the stuff you didn't download but copied from your personal DVD collections. And lets use ipv4, as that's a main concern for you (although it should not be a cause/reason to adjust your MO in setting up new service). We pick an application that will not freak us out, lets say jellyfin. Let's do a non-docker install, because otherwise this is a poor example :P And this is where I pause, and even before I start downloading, I take a look at the requirements page of jellyfin. We start to document the various directories (cache, config, log, data) and third party tools jellyfin requires to run (ffmpeg). I'm almost done with the exploration. How do I access jellyfin? Well, in my case it's via http://172.172.195.10:8096.. but it binds to \*:8096. The moment I can reach jellyfin on the network, we are done. To make jellyfin work it is not necessary to do anything else. But besides the filling of the fin and the organizing of the metadata and such, we need to make it available. But this is where the writing of the documentation and planning stops (for jellyfin). Now, where I run the jellyfin service is of importance, for sure. But choosing a place where to run it is driven by the needs of the application. But not all jellyfins are the same! We start the whole process that I described above again, without an application as goal, but a requirements to facilitate that type of behavior. Let's go! I wanted to offer jellyfin with a nice name, something that my appletv or ipad don't care much about, but when I'm using a browsers I don't want to think about port numbers and what not. Besides, I'd like to be able to take my tablet outside and watch my M.A.S.H 4077 collection at all times if needed! So, I need to be able to assign a name, a method to redirect traffic (from 443(with SSL) to 8096, but also 80 to 443, or if I'm running a multitude of docker images with a plethora of port numbers.. this could be anything. But.. at the same time, I want to make it available to the outside but not always. So, I need to create 2 funnels, 1 internally and one externally. There are many options to serve a single application to the outside world.. like a cloudflare-tunnel, or a tailscale, or a VPN.. but, just DNS does not make a full solution. I also wanted a little more "traditional" approach so I could focus all efforts on keeping something secure (firewalls etc) in one place. The logical (to me :D) choice was for a proxy in a DMZ. Perhaps I'm just old-fashioned talking about DMZ as you kids love tailscale, cloudflare tunnel vpn jazz, but, a DMZ with a proxy server still works like a charm. Besides, it's easier to run a WAF in 1 place then multiple places. And we have a lot of options, NPM, Traefik, haproxy, caddy, apache, nginx and a whole lot of others.. so, options enough. I installed a proxy server, and pointed a wildcard (\*.cookiejar) for all internal traffic towards the proxy server. So, jellyfin.cookiejar configured on the proxy server directing traffic to http://172.172.195.10:8096. And, because I'm extra and have had my own namservers ever since I started in IT one or 2 ago, I used my private dyndns for a public connection. I added a \*.public.domain.com, and voila.. Whenever I am home OR away, the public services are reachable, and what needs to stay on the lan, stays on the lan. (missed an opportunity for a good pun, calling my lan Vegas). So.. in effect, if I want to add a new application I install it, and add a new proxy host/rule, and requests certs where and if needed. ---------------------------------------------------------------------- BeebBoobBot · 2023-12-26 12:14 If reddit is a good indicator for anything, most Jellyfin users use it primarily locally or from remote with a VPN. I don't believe that to be true for Nextcloud. If it were just about local access they would just use SMB. And if you wanna share a file, remote access becomes necessary. What I am trying to say, they have different requirements so comparisons are hard. But even Jellyfin suffers hugely from the same problem! Chromecasts devices need a valid cert to stream to. Forums and github issues are full of users that don't get split dns. > Perhaps I'm just old-fashioned talking about DMZ as you kids Haha same :) There is also a NGINX revers proxy tutorial in the same repo. ---------------------------------------------------------------------- KD_done · 2023-12-26 14:38 I don't think reddit is a good indicator for much.. but that's a whole different kettle of fish :) Replace jellyfin with cloudbeaver, or portainer, or just about anything else with a webbased interface. And the whole setup would still be valid. Because any type of infrastructure adjustments (split dns, proxy/DMZ, vpn etc.) is not mandatory for the application to run. As I explained, your infrastructure choice is NOT mandatory/necessary for the use of the app, and would work counter productive if I would assume your instructions to be true.