Nextcloud_Ubuntu / nextcloud.md: making use of it for clean installation attempt

[carling-knock]

Awaiting a INTEL NUC11 ATKC4 Mini-PC in the post today for adding a leftover 2TB Samsung 970 EVO-plus NVMe M.2 and some spare 32GB SO-DIMM DDR4 still flying around in a drawer and want to make use of the "nextcloud.md" description for setting up a Ubuntu 22.04.3 LTS Server with the latest Nextcloud on it as my main self-hosted server in future, added to my Rack-case.

So, I'm not expecting it all going smooth right at 1st attempted, but hope for the best and may have to come back asking for help if encountering any issues. Thumbs up ;-)

Pulled some more general infos together into a personal PDF installation guide (attached here), from the Ubuntu HowTo web page and added your description at the bottom too. Intel-NUC_Ubuntu-Server_install.pdf

Thanks

[jameskimmel]

Hi Yes please, give it a try and report back. I just finished an install and it works great. Hope it is the same for you. Just a heads up, this guide assumes that you already have NGINX reverse proxy up and running. But someone with good knowledge should easely be able to repace that NGINX proxy with just a local Apache2 server.

[carling-knock]

Hey,

right ;-) since I'm very new to Ubuntu and Linux in general, more coming from the FreeBSD easy package installations side, but that's a few years ago now and well yeah $WIN LTS tweaking for free, regarding of setting things up to work. I had some fun to figure out how Ubuntu now works so far. Well, at least the part of the logic behind it, which is quite different to what I know from FreeBSD.

Since my new beefed up NUC11 is in empty stage and can be cleaned out at any time to start all over again from scratch if things going wrong, to repeat with some trial and error once more, while the Ubuntu server setup to a slim and plain stage is a fast easiest part of it, by only plugging in a USB and hitting enter a few times. I managed to set up Nextcloud after a few attends and had it running for the last few days, while being very excited about all the new options that are opening up, but ended up with a plain white screen after installing a few extra plugins... A good chance to start all over again and get it right this time. And now by making use of your scripts for a full setup, instead of only having Nextcloud in local stage only.

A Nextcloud server is definitely something I'm looking forward to as a main back boon behind my other gear,

Well, I'm still confused on how to get it right for my needs. Your very extensive instruction is definitely something I'm looking for, since other Ubuntu/Nextcloud installation recommendations are either old, not covering the latest needs and versions, nor are they as comp leat as this guide of yours.

"Ubuntu 22.04.03 LTS with Apache2, APCu, redis and mariadb behind a NGINX proxy, no Docker, no Snap"

Seams to me the right ticket to go for, since most other guides recommend the Docker part for installing additional packages to accompany by Nextcloud, specially the needed NGINC proxy for remote access over the Web like making use of mobile phone Nextcloud App while being out and about for instant, quite an important issue.

Yeah, well having another go starting up from scratch one more time now, by copying all your command stings of the page in to a plain txt editor for changing all the "placeholder values or variables that always start with x_" to my own once, to make have a quick and easy copy/past sheet at hand to redo all the steps needed to get it up and running ;-)

Now ;-) yeah, sorry for my long introduction, but coming to my final question, but tripped over a small issue on how to correctly alter my personal installation txt-sheet.... Hope I'm not as dump to read your warning about the "x_ placeholder" and only want to clear things up, I may not understand all the intensional meaning on how far the alterations should be taken into account. ;-)

Well everything is clear so far up to the point of the steps regarding for:

NGINX settings on the reverse Proxy "nginx-settings-on-the-reverse-proxy" Create an empty site without ssl.

sudo nano /etc/nginx/sites-available/cloud.x_youromain.conf

server { listen 80; listen [::]:80; server_name cloud.x_yourdomain.com; }

Now, the part I'm not quite clear is about to change the full entry -cloud.x_yourdomain.com- or only -x_yourdomain.com- in the lines that showing up in the description. Should I only replace everything behind x_ or all of it, or should the part -cloude- be replaced by -www- followed by -full_webdomain.net- ?

understand that this doesn't matter to keep this constance for the few: sudo ln -s /etc/nginx/sites-available/cloud.x_yourdomain.com.conf /etc/nginx/sites-enabled/cloud.x_yourdomain.com.conf tobe edited having -cloud- upfront to address this files, but inside the conf-files later on entries like

----- This is needed so NGINX does not throw warnings. server { server_name

This is needed so NGINX does not throw warnings.

server { server_name cloud.x_yourdomain.com; ssl_certificate /etc/letsencrypt/live/cloud.x_yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/cloud.x_yourdomain.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

Edit config.php file. sudo nano /var/www/nextcloud/config/config.php

overwrite/change: https://'overwrite.cli.url to https://**cloud.x_yourdomain.com**'

Now, this could mess things up if not addressed correctly... and there is a lot to take care about too, at the same time. Just checking to get it right, since I had to take care of my newly free created DynDNS No-IP hostname in parallel as well to make full use of this customised installation as well as setting up the forward issue in my Router in combination with DynDNS settings on top.

Hope you don't mind me asking all this stupid questions, but would very much appreciate it if you could be bothered to set things straight for me, so I can continue in a smooth installation ;-)

Many thanks for all the effort you have put into setting this "Nextcloud_Ubuntu / nextcloud.md" page up, it really is the most resent instruction for the newer Ubuntu 22.04.3 LTS, Ngnix and latest Nextcloud combination without the need of any other additional packages for a slim Server setup.

[carling-knock]

Regarding Port:80 DynDNS forwarding to the Router for a local Nextcloud Server, making it very easy to add the NUC to be accessible for external Proxy too. (other DynDNS Service Provider can be selected too)

among others:

Opening in the browser by only asking for "http://my-real-domain.net" coming up with a login page. http://my-real-domain.net/webpages/login.html With just a plain white display and no 404 warning. If I'm not mistaken, the Proxy is set up alright, even without Nextcloud installed. by changing over to my real "https://my-rael-domain.net" the browser opening right to the web search with some random results.

Finally, checking against my No-IP provider, Port 80 is reachable ;-) DynDNS: D.U.Client automatic IP updating is working as well, so everything on the reverse Proxy should be covered for now to make it work.

[carling-knock]

Hi,

Please check this out ;-)

I may tripped over something missing in this long script, but after I add: sudo nano /etc/nginx/sites-available/cloud.x_youromain.conf

in the NGINX section, nano is opening with a warning ! Directory '/etc/nginx/sites-available' does not exist so I can't add the following snips. :-(

But it looks like that may NGNIX is not installed at this stage. After checking ls -a in /etc there is no nginx folder to find... may a glitch or some previous command is not set.

There are no signs of any (apt install package) for nginx in the main fetch line either, so I guess it still needs to be installed at this point before continuing with this HoTo list ;-)

NGINX settings on the reverse Proxy Create an empty site without ssl.

*** Plaseholder for (sudo apt install nginx) after placed:

sudo apt install nginx

at this point, manually and installed the package successfully, adding the following went throug !!

sudo nano /etc/nginx/sites-available/cloud.x_youromain.conf

server { listen 80; listen [::]:80; server_name cloud.x_yourdomain.com; }

*** so far so good !

sudo nginx -t sudo ln -s /etc/nginx/sites-available/cloud.x_yourdomain.conf /etc/nginx/sites-enabled/cloud.x_yourdomain.conf sudo nginx -s reload

BUT after executing: sudo nginx -s reload nginx [error] invalid PID number "" in "/run/nginx.pid" ***

Soo, is there any need to do some pre-configuration here ???

sudo certbot **** certbot: command not found

I'm stuck now :-( Please let me know if some parts of the command scripts could be integrated during Configure Apache2 prior to starting with the NGINX section. https://apfelcast.com/reverse-proxy-konfigurieren-mit-ssl-verschluesselung-via-lets-encrypt-einfache-beginner-anleitung/

install apache2 apt-get update apt-get install apache2 -y enable moduls a2enmod proxy a2enmod proxy_http a2enmod proxy_ajp a2enmod rewrite a2enmod deflate a2enmod headers a2enmod proxy_balancer a2enmod proxy_connect a2enmod proxy_html service apache2 restart create config for 1st client nano /etc/apache2/sites-enabled/server1.conf <VirtualHost :80> ServerName subdomain11.yourdomain.com ProxyPreserveHost On DocumentRoot /var/www/html ProxyPass /.well-known ! ProxyPass / http://10.1.1.11:80/ ProxyPassReverse / http://10.1.1.11:80/ create config for 2nd client nano /etc/apache2/sites-enabled/server2.conf <VirtualHost :80> ServerName subdomain12.yourdomain.com ProxyPreserveHost On DocumentRoot /var/www/html ProxyPass /.well-known ! ProxyPass / http://10.1.1.12:80/ ProxyPassReverse / http://10.1.1.12:80/ restart apache server service apache2 restart install Let's Encrypt Certbot apt-get install python-certbot-apache create certificates certbot --apache --> certificate only lasts 90 days install crontab crontab -e 0 1 * /usr/bin/certbot renew & > /dev/nul

Tx

[carling-knock]

Because it seems that it may could be useful to add a few more lines to your extensive installation HoTo script to address some issues with setting up NGINX. Hope I'm not too far off with this contribution ;-) Haven't tried it out yet, but may wait for a qualified reply 1st before continuing installing. It may as well is needed to shift some parts around, one before or after another entry, to make any sense in the main script.

And hey all this is not grown on my own knowledge but rather only on research on the web, so keep that on mind ;-)

Found some interesting things as followed: -------------------------------------- add missing nginx

apt install nginx

---

Sourced from: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04 How To Secure Nginx with Let's Encrypt on Ubuntu 20.04 since this is an older description, but may still work with Ubuntu 22.04.3 for the need task !!

add missing certbot Step-1: Installing Certbot

sudo apt install certbot python3-certbot-nginx

Step-2: Confirm Nginx configuration

sudo nano /etc/nginx/sites-available/cloud.x_yourdomain.conf

server { listen 80; listen [::]:80; server_name cloud.x_yourdomain.com; }

continue with

sudo nginx -t sudo ln -s /etc/nginx/sites-available/cloud.x_yourdomain.conf /etc/nginx/sites-enabled/cloud.x_yourdomain.conf sudo nginx -s reload

Step-3: checking on Allowing HTTPS throug the Firewall Nginx registers a few profiles with ufw upon installation.

sudo ufw status

will probably look like this, meaning that only HTTP traffic is allowed to the web server: Output Status: active OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere

To additionally let in HTTPS traffic, allow the Nginx Full profile and delete the redundant Nginx HTTP profile allowance:

sudo ufw allow 'Nginx Full' sudo ufw delete allow 'Nginx HTTP'

check again: status should now look like this:

sudo ufw status

Output Status: active OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

Follow the certbot instructions. This will create a cert and also change your config to rediret all traffic to https.

Now we let certbot create a cert. For certbot to be sucessfull, you need an A or AAAA record that points to your proxy with the open port 80. instead of using the plain command, but may work alternativly as well $ sudo certbot

Step-4: Obtaining an SSL Certificate Certbot provides a variety of ways to obtain SSL certificates through plugins. The Nginx plugin will take care of reconfiguring Nginx and reloading the config whenever necessary. To use this plugin, type the following:

sudo certbot --nginx -d example.com -d www.example.com

Output Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.

1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration.

Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Output IMPORTANT NOTES:

• Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2020-08-18. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew all of your certificates, run "certbot renew"

• If you like Certbot, please consider supporting our work by:

  Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

**Step-5: Veriffying Cartbot Auto-Renewal Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process. The certbot package we installed takes care of this for us by adding a systemd timer that will run twice a day and automatically renew any certificate that’s within thirty days of expiration.

You can query the status of the timer with systemctl:**

sudo systemctl status certbot.timer

Output ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Mon 2020-05-04 20:04:36 UTC; 2 weeks 1 days ago Trigger: Thu 2020-05-21 05:22:32 UTC; 9h left Triggers: ● certbot.service

To test the renewal process, you can do a dry run with certbot:

sudo certbot renew --dry-run

if you see no errors, you’re all set. When necessary, Certbot will renew your certificates and reload Nginx to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.

[jameskimmel]

Well everything is clear so far up to the point of the steps regarding for: That is great, now lets try to clear out the other problems :) Now, the part I'm not quite clear is about to change the full entry -cloud.x_yourdomain.com- or only -x_yourdomain.com- in the lines that showing up in the description. Should I only replace everything behind x_ or all of it, or should the part -cloude- be replaced by -www- followed by -full_webdomain.net- ? Well it depends. I for one, have other services running to the same domain. That is why I like to run Nextcloud with a "cloud" or "nextcloud" prefix. So lets assume my domain is james.com. Then I would wanna run Nextcloud under cloud.james.com. The thing is, you can use james.com instead of cloud.james.com but then you have to set different PHP and different Apache2 settings.

but inside the conf-files later on entries like Not sure if I understand this one. Do I somewhere not use cloud.x_yourdomain.com?

----- This is needed so NGINX does not throw warnings. I have redone that part to make it a little bit more clear.

Opening in the browser by only asking for "http://my-real-domain.net/" coming up with a login page.
http://my-real-domain.net/webpages/login.html

For that domain, you would have to have different NGINX, PHP and Apache settings. My tutorial assumes that you use cloud.yourdomain.com.

in the NGINX section, nano is opening with a warning !
Directory '/etc/nginx/sites-available' does not exist
so I can't add the following snips. :-(

That is strange. Maybe this depends on how you install NGINX. I think I followed (that was years ago) this method: https://nginx.org/en/linux_packages.html#Debian. As you can see, my NGINX proxy is A: on a different machine and B: Debian instead of Ubuntu. Maybe you can find out where your default page config files is. Some have it on /usr/local/nginx/conf/nginx.conf.

But it looks like that may NGNIX is not installed at this stage.

NO! Sorry if that was not clear but, this guide assumes you already have a NGINX reverse Proxy up and running. I added that.

nginx [error] invalid PID number NGINX is probably not running only installed. Enable it with systemd or even better follow the instructions from NGINX: https://nginx.org/en/linux_packages.html#Ubuntu

sudo certbot
**** certbot: command not found

It also assumes you have certbot running. I installed it from apt because I don't like snap. But certbot will recommend you to use snap to install it. sudo snap install --classic certbot

Hope this helps you clear out some questions. If I skipped something, please ask again.

[jameskimmel]

I also added something about local split DNS! This is pretty important!

[jameskimmel]

I hope this will help you setting up your instance. Please let me know if there are additional problems you encounter or if you have more questions.

[carling-knock]

Hi,

Right ;-) Well by now I figured it out regarding the "cloud.x_xxx.com" prefix ;-) Yep makes sense if there are several domains registered and need to be configured in different conf.files as well, specially if running on several virtual ports:80 in (nano /etc/apache2/sites-enabled/cloud1.x_xxx.com.conf) like "ServerName subdomain12.yourdomain.com" subdomain counting up, all clear on that issue now, Thanks ;-)

Yep definitely working a bit more on the proxy settings to get DNS calls right... getting there slowly ;-)

again thanks

[carling-knock]

Hi ;-)

Just one last question about the long NGINX settings on the reverse Proxy script, more like followed by it. Well may for convenience. ;-)

After doing all the "NGINX settings on the reverse Proxy" before moving on to “Install Nextcloud” Would it make any sense to execute or add the following few lines at that stage ?

create certificates certbot --nginx

--> certificate only lasts 90 days

install crontab crontab -e 0 1 * /usr/bin/certbot renew & > /dev/null

[jameskimmel]

I don't think so, because the automatic renewal by crontab should have been done by certbot already. It makes more sense to test it with sudo certbot renew --dry-run I added that into the manual.

[carling-knock]

ahh ok, thanks :-) was just wondering because it was mentioned in: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04

And I found this entry at the end of my description, I posted earlier too https://apfelcast.com/reverse-proxy-konfigurieren-mit-ssl-verschluesselung-via-lets-encrypt-einfache-beginner-anleitung/

All good then

[carling-knock]

Meanwhile, I even managed to get my DNS setup for Nextcloud up and running with full https://mydomain.com via Apache config and got a certbot key for that, probably by accident somehow, still the setup is mixed up with Nginx settings somewhere else. Been mucking about in that area a bit, since I didn't strictly stick to your manual letter-by-letter, but rather using it as a close global guideline ;-) Learned a lot out of it over the last few days, cleared up a lot as well ;-) The whole thing is a bit like a jigsaw puzzle, things need to get in line in the right order, just dropping in place in the end. At least my reverse Proxy is working, and now I know how to place it in my personal installation script for another clean start, which is easy enough if the script is sorted out by copypasta, and I would prefer your NGINX setup instead of the Apache option. Tx

[carling-knock]

Another little quirk I tripped over yesterday, was the missing sudo mysql in your manual, because of the following: MariaDB [(none)]> didn't show up, so I had to improvise to be able to continue there ;-)

Create the database sudo mariadb

open SQL dialoge sudo mysql

You should now see "MariaDB [(none)]>"

[jameskimmel]

Been mucking about in that area a bit, since I didn't strictly stick to your manual letter-by-letter, but rather using it as a close global guideline ;-)

Totally get that and would even encourage you to do so. Just watch out that some things change when you do that. Like for example, I have to use IPv4_ofNextcloud for my proxy pass, because it is on a different machine. You could probably use something like localhost.

Or if you wanna use mydomain.com you would need to change how Apache2 is configured.

For your setting (only one host, no subdomain, no other hosts, no reverse proxy) you would probably be better of by using only Apache2. You could use my tutorial, but leave out the nginx part, use certbot for apache instead of nginx and follow these steps: https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#apache-configuration-label

Viel Glück ;) Und berichte wie es gelaufen ist!

[jameskimmel]

Another little quirk I tripped over yesterday, was the missing sudo mysql in your manual, because of the following:
MariaDB [(none)]> didn't show up, so I had to improvise to be able to continue there ;-)

Not sure if I get that one. sudo mariadb should give you the exact same outcome as sudo mysql. Unless you installed mysql instead of mariadb.

[carling-knock]

You could probably use something like localhost.

All static IP setup on my end ;-)

For your setting (only one host, no subdomain, no other hosts, no reverse proxy) you would probably be better of by using only Apache2. You could use my tutorial, but leave out the nginx part, use certbot for apache instead of nginx and follow these steps: https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#apache-configuration-label

Yeah, tried that Apache2 only script because I thought it may, would be easier, but well I still can give it another try later on if NGINX is not working for me as expected ;-) As a Backup solution. Yes cool, as described in your Link, how to make use of Apache Proxy, that's pretty much how I had it already, at least tried it out, definitely will keep that record to look into if Nginx is getting too complicated or may doesn't work as expected ;-)

Viel Glück ;) Und berichte wie es gelaufen ist!

Bessten Dank, wird schon werden, bis jetzt ist es halt noch die Lernphase dran ;-)

sudo mariadb should give you the exact same outcome as sudo mysql. Unless you installed mysql instead of mariadb.

Nob, gave me a empty prompt, after sudo mariadb

Installed this at the very beginning, so should have ben ok: sudo apt install apache2 mariadb-server exif imagemagick redis-server bzip2

Well anyways either way it only was a little quirk ;-)

[jameskimmel]

That is strange. Will create a VM to test this. I opened an issue https://github.com/jameskimmel/Nextcloud_Ubuntu/issues/2

[carling-knock]

That is strange. Will create a VM to test this. I opened an issue #2

Not sure if that matters, but I may, should point out that I'm using the PHP 8.2 modules instead of 8.1 as recommended in your manual ;-) That's so far as not sticking to it as strictly but rather experimental ;-)

[carling-knock]

Another thing about my Proxy setup, since NGINX is actually not running due to some error in 0.0.0.0:80 already in use or similar, the whole Server with it's working on apache with certbot config anyway, I may just keep it that way for convenience.

[jameskimmel]

That makes total sense! There can't be two services listening on the same port and you already have Apache2 😊

[carling-knock]

So yes, the Nginx part of the manual is skipped and Apache2 did take over, and because I managed to get a No-IP as DNS resolver, recognising Port:80 on the open web, plus certbot to deliver a proper certificate, everything looks OK for use.

Even Firefox browser asked to import the cert, showing up with the little padlock not crossed out, it all looks like it's set up, even if I type only my local 192.168.x.x Server IP instead of the full domain name It still rerouteing up to the full HTMS://my.full-domain.com

Ohh Bollocks ;-) after rebooting the server... I get this up now: NGINX has taken over by only typing my local 192.168.x.x

Typing in https://my-full.domain.com now stating "unable to connect".... :-(

Happened for starting Nextcloud window up...

[carling-knock]

two options there now. 1st continuing to get nging running as expected by painstaking editing any config files or 2nd just wipe the server clean and start all over from scratch by copypasta my backup scrips ;-)

[carling-knock]

Well, gone trapped in exactly that issue you pointed out ,-)

Just watch out that some things change when you do that. Like for example, I have to use IPv4_ofNextcloud for my proxy pass, because it is on a different machine. You could probably use something like localhost.

Thought, why not give it a try and start editing and adjusting for: sudo nano /etc/nginx/sites-available/cloud.x_youromain.conf by adding the whole of your script to the file, since the initial sudo nginx -t sudo ln -s /etc/nginx/sites-available/cloud.x_yourdomain.conf /etc/nginx/sites-enabled/cloud.x_yourdomain.conf sudo nginx -s reload went throug, even managed to get a new cert for 443, but after trying to restart NGINX I run in exact that issue: invalid number of argument in "add_header" directive in /etc/nginx/sites-available/cloud.x_youromain.conf:17 seams to have problems here now:

location / { proxy_pass http://x_nextcloud_host_IPv4/; proxy_set_header Host $host;

for a fry I changed from my http://192.168.x.x to localhost without luck reversed it back to IP number and changed $host to $localhost no luck either, still the same error after trying to restart ngonx

Question! Does it has something to do with this, like being related to the above ?

counting the active lines down to No.17 (like shown in the error is stated ) I'm getting down to one of this depending on if the 1st line with "server {" is counting too.

proxy_set_header Host $host; proxy_http_version 1.1;

My guess is either $host or proxy_http_version.....

well I'm off to dreamland now and continue tomorrow ;-)

[carling-knock]

Just rebooted the NUC server once again after having all NGINX config files altered to exactly what's written in the scripting. Wonder happened overnight. ;-) A simple reboot resolved all issues.

All problems seam to be solved, starting with “localhost” like 192.168.x..x in the settings of /etc/nginx/sites-available/x_youromain.conf like without the prefix “cloud” in about all settings, with a new nginx server file, and yeah most important Nextcloud starting up as expected with https://my_owndomain.com without issues in another tab in Firefox.

I'm just not sure which of the two reverse Proxy are running, since both Amache2 and NGINX are configured with their own server files, so either of them in in chare now, can't tell which one it is:

Apache2 with config: /etc/apache2/sites-available/nextcloud.conf

<VirtualHost *:80> DocumentRoot /var/www/nextcloud/ ServerName my_owndomain.com Redirect permanent / https://my_owndomain.com

<Directory /var/www/nextcloud/> Require all granted AllowOverride All Options FollowSymLinks MultiViews Satisfy Any

<IfModule mod_dav.c>
  Dav off
</IfModule>

<VirtualHost *:443> ServerName cloud.nextcloud.com

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

NGINX with its own: nano /etc/nginx/sites-available/my_owndomain.conf Without "cloud prefix"

server { server_name my_owndomain;

listen [::]:443 ssl http2 ipv6only=on;
listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/my_owndomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/my_owndomain.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

# security headers
# add_header X-XSS-Protection          "1; mode=block" always;
# add_header X-Content-Type-Options    "nosniff" always;
# add_header X-Robots-Tag              "noindex, nofollow" always;
add_header Referrer-Policy           "no-referrer" always;
add_header Content-Security-Policy   "default-src 'self' http: https: ws: wss: data: blob: 'unsafe-inline'; frame-ancestors 'self';" al>
add_header Permissions-Policy        "interest-cohort=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# logging
access_log              /var/log/nginx/access.log combined buffer=512k flush=1m;
error_log               /var/log/nginx/error.log warn;

# reverse proxy
location / {
    proxy_pass            http://192.168.x.x/;
    proxy_set_header Host $host;

    proxy_http_version                 1.1;
    proxy_cache_bypass                 $http_upgrade;

    # Proxy SSL
    proxy_ssl_server_name              on;

    # Proxy headers
    proxy_set_header Upgrade           $http_upgrade;
    proxy_set_header Connection        $connection_upgrade;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header Forwarded         $proxy_add_forwarded;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host  $host;
    proxy_set_header X-Forwarded-Port  $server_port;

    # Proxy timeouts
    proxy_connect_timeout              60s;
    proxy_send_timeout                 60s;
    proxy_read_timeout                 60s;
}

location /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}

}

server { if ($host = my_owndomain.com) { return 301 https://$host$request_uri; }

listen      80;
listen      [::]:80;
server_name my_owndomain.com;
return 404;

}

Either one of them is running after rebooting the NUC server box with a legit certbot key, and so far as I can tell it works either way.

Funny anove: sudo nano /var/www/nextcloud/config/config.php

Set the trusted_domains array 0 => 'my_owndomain.No-IP.com', 1 => 'my_owndomain.com',

also change or add these settings:

'trusted_proxies' => ['192.168.x.x'], 'default_language' => 'en', 'default_locale' => 'en_GB', 'default_phone_region' => 'DE', 'overwrite.cli.url' => 'https://my_domain', 'overwriteprotocol' => 'https', 'overwritewebroot' => '/', 'overwritecondaddr' => '192.168.x.x', 'htaccess.RewriteBase' => '/',

Just woks ;-) But please let me know if you may have any further suggestions, many thanks for the support :-) If I'm not mistaken, it looks like my new tweaked Nextcloud server is up and running to be finally setup with all Nextcloud userland fun-stuff now ;-)

the only thing that's may worth to look after is this nagging Security warning in Nextcloud, Any idea on your behave? Tx

[carling-knock]

After adjusting for CRONE settings, things getting better ;-)

[jameskimmel]

2nd just wipe the server clean and start all over from scratch by copypasta my backup scrips ;-) I always document my steps and probably needed 10 runs to get to this script. I have ZFS Snapshots, so rolling back is easy.

for a fry I changed from my http://192.168.x.x/ to localhost without luck Problem is that you need to specify a port. For example, you could run apache2 on Port 8080 instead of 80 <VirtualHost *:8080> and then use http://localhost:8080 as proxy pass on NGINX. That also solves your error that two things are listening on port 80.

But please let me know if you may have any further suggestions, many thanks for the support :-) I would recommend restarting from scratch, just to make sure there are no rouge old settings. It is pretty complex and easy to make errors if you are new to this.

the only thing that's may worth to look after is this nagging Security warning in Nextcloud, For my reverse proxy settings, this is done on NGINX. But my guess is that you don't actually make use of NGINX in your current setting

[jameskimmel]

Either way, you have to decide between Apache2 or NGINX. You can only have both, if NGINX only acts as a proxy. But then NGINX is also responsible for SSL, so cerbot would need to run for NGINX and not Apache (which seems to apply to your current setting)!

Ohh, and just to be sure, you need to portforward port 80 and 443.

[carling-knock]

But then NGINX is also responsible for SSL, so cerbot would need to run for NGINX and not Apache (which seems to apply to your current setting)!

how about rerun certbot once more with certbot --apache ? and get a overwrite cert issued

[carling-knock]

Ohh, and just to be sure, you need to portforward port 80 and 443.

where exactly ;-) just copy a port 80 section, change it to 443 adding a new section below somewhere ?

[jameskimmel]

If you uninstall NGINX and don't wanna use NGINX, that could be ok. But then you have to find out how to set the Apache settings for yourself, because I don't really know apache.

For example this NGINX setting to clear one of the security warnings add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; I have no idea how that is done in Apache2.

Portforward both 80 and 443 on your TP-Link router. You can't do them both in one, you need two rules.

[carling-knock]

Yes I figure that it would be easier to start from scratch, but than I would like tho know how to work around it as well at this stage, since it all looks pretty good ;-)

[carling-knock]

If you uninstall NGINX and don't wanna use NGINX, that could be ok. But then you have to find out how to set the Apache settings for yourself, because I don't really know apache.

For example this NGINX setting to clear one of the security warnings add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; I have no idea how that is done in Apache2.

Portforward both 80 and 443 on your TP-Link router. You can't do them both in one, you need two rules.

*VirtualHost :443> ServerName cloud.nextcloud.com IfModule mod_headers.c> disabled: Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"; preload running -> Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"; /IfModule> /VirtualHost>**

got this in my: nano /etc/apache2/sites-available/nextcloud.conf it may want to be the same figures as in NGINX setting

[carling-knock]

Portforward both 80 and 443 on your TP-Link router. You can't do them both in one, you need two rules.

Yes had that already done ,-) Thought that would come in handy.

May should change naming from No-IP-Port: to NC-Port: or better Nextcloud-Port:80 / 443 Looks better too ,-)

[carling-knock]

For example this NGINX setting to clear one of the security warnings add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; I have no idea how that is done in Apache2.

Having an idea on how to do that ,-) copypast the 443 section and add it under (VirtualHost *:80)

sudo nano /etc/apache2/sites-available/nextcloud.conf

(VirtualHost *:80) DocumentRoot /var/www/nextcloud/ ServerName spooky-crow.ddns.net Redirect permanent / https://my_owndomain

(<Directory /var/www/nextcloud/>) Require all granted AllowOverride All Options FollowSymLinks MultiViews Satisfy Any

(IfModule mod_headers.c)
  Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains";
(/IfModule)

(IfModule mod_dav.c)
  Dav off
(/IfModule)
 (/Directory)

RewriteEngine on RewriteCond {SERVER_NAME} =my_owndomain RewriteRule ^ https://&{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] (/VirtualHost)

(VirtualHost *:443) ServerName my_owndomain (IfModule mod_headers.c) Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"; (/IfModule) (/VirtualHost)

This should take care about it tin the same way. At least: sudo a2ensite nextcloud.conf sudo a2enmod rewrite headers env dir mime sudo systemctl reload apache2

is happy about this settings without any complayns ;-)

[carling-knock]

I just realised that I haven't completely finished off all the following steps after the NGINX section in your manual, because I was stuck there for to long without knowing that I had to continue installing all the rest of it too ;-)

So yes I'm ticking boxes further down and it looks like things like Caching, Redis and so on still had to take care about

[carling-knock]

After all the added settings left to do, and a new reboot I still get this complayns in Nextcloud:

The OPcache interned strings buffer is nearly full. To assure that repeating strings can be effectively cached, it is recommended to apply opcache.interned_strings_buffer to your PHP configuration with a value higher than 8.

Where exactly do I have to change or add the values? is nano /var/www/nextcloud/config/config.php the right place to add any addition? Or may somewhere else?

**Sorted out! Found the needed settings in "nano /etc/php/8.1/apache2/php.ini" and enabled "opcache.interned_strings_buffer=8" to value 16. This may should be done right together with:

We search for these settings to change (use ctrl+W to search in nano). memory_limit = 1G upload_max_filesize = 50G post_max_size = 0 max_execution_time = 3600 date.timezone = Europe/Amsterdam opcache.interned_strings_buffer=16 (disabled by default and value 8 to small or only minimim)**

There are a few other disabled options they ma need to addresset to in thas section of "nano /etc/php/8.1/apache2/php.ini" file too. May woth while checking out this as well. https://help.nextcloud.com/t/the-php-opcache-module-is-not-properly-configured/135870

[carling-knock]

Things starting to work out ;-)

[jameskimmel]

I wonder why you needed to change the opcache value and I don't see any warnings.

Congrats on having an A+ rating!

[carling-knock]

Well this is the only warning I have left now, managed to sort all the other once out ;-)

[carling-knock]

Congrats on having an A+ rating!

Beginners luck :-) But thank you so much for your support and patience with my Ubuntu/Nextcloud novice stage of getting my hand on it, couldn't have done it without your help in just a few days setting it all up ;-)

Starting to fill up Nextcloud Userland now with some applications to make it all work, integrating my mobile App's that going along with it and so on, adding additional user and so on, syncing Bookmarks, calendars, contacts, all that admin stuff ;-)

[jameskimmel]

Ohh I forgot that I already had HSTS for my main domain up and running. I added this in the tutorial, hope it helps. https://github.com/jameskimmel/Nextcloud_Ubuntu/blob/main/nextcloud.md#http-strict-transport-security-hsts

[carling-knock]

Ahh yes been on that page while searching for the issue of this nagging notice. That's where I had this higher figures from in the line and coppied it in to my config files.

"Strict-Transport-Security: max-age=63072000; includeSubDomains; preload" (but dropped the "preloaded" part). By now I reduced the figures down for apache config matching your's in nginx config file to be consistent on it, But well once my head is cooling down a bit after all this mammoth session setting it up, I'm having a bit relaxing fun within Nextcloud global Userland setup ;-) Just clicking away working through the menus ;-)

But since I'm still getting this message I may have a deeper reading into it.

here are some warnings regarding your setup. The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described.

[jameskimmel]

here are some warnings regarding your setup.
The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described.

I use the minimum 365 days, while nextcloud recommends 15552000 or 180 days. But I agree, 63072000 or two years is even better. I also noticed some cutoff in the line before and edited it.

[carling-knock]

I use the minimum 365 days, while nextcloud recommends 15552000 or 180 days. But I agree, 63072000 or two years is even better. I also noticed some cutoff in the line before and edited it.

Ahh, yep that could explain some quirks ;-) going to compare that against my settings ;-)

[jameskimmel]

Wait, I am redoing it!

[jameskimmel]

Done, NGINX should be good now!

[carling-knock]

OK, So you basically got rid of the entry for "Strict-Transport-Security" altogether for a start ;-)

And what about this one? My interpretation was to add http://192.168.x.x:8080, so your version would put the full http://pmy_owndomain in place without a trailing port:8080 ?? Well, if I'm reading that correctly :-)

location / { proxy_pass http://x_nextcloud_host_IPv4/; proxy_set_header Host $host;

every thing else seams to be unchanged by flying over it. Will give it a go and do my corrections now. Tx

[carling-knock]

getting a error after editin, my just a typo on my foggy eys at this tim of the day.

nginx: [emerg] unknown "connection_upgrade" variable nginx: test feild to start

well have check it out, what I missed out

missed out on http2 in the 1st two lines for a start ;-)

[jameskimmel]

So you basically got rid of the entry for "Strict-Transport-Security" altogether for a start ;-)

Ups, added it again.

My interpretation was to add http://192.168.x.x:8080, That seems right.

so your version would put the full http://pmy_owndomain in place without a trailing port:8080 ??

pmy? Not sure what that is supposed to be. Either way, if you use NGINX and Apache on the same host, you should probably be able to use localhost:8080.

every thing else seams to be unchanged by flying over it. Some minor corrections on NGINX and added the HTSP for Apache2 at the end.

nginx: [emerg] unknown "connection_upgrade" variable

Did you use
proxy_set_header Connection $connection_upgrade; in the 443 server part of NGINX?

Are you using NGINX reverse Proxy and Apache2 for Nextcloud?

Could also be a simple formating issue.