We're assuming an Arch Linux installation, but the steps should be similar for other distributions.
There are two possible ways to serve Nextclouds PHP code: uWSGI and PHP-FPM.
We'll be using PHP-FPM as this is the recommended way and nginx is easier to setup with it, especially if you wish to enable additional plugins such as LDAP.
Be prepared for quite a bit of work, with too many files which look identical, but it's worth it.
This instal guide is based on the [Arch Wiki](https://wiki.archlinux.org/index.php/Nextcloud) and the [Nextcloud documentation](https://docs.nextcloud.com/server/20/admin_manual/installation/source_installation.html). It mainly emphasizes some points which go under in the Arch Wiki article.
We assume postgresql as the database backend, but you can also use mysql/mariadb (which is also the recommended way by Nextcloud). I do this because I run a lot of other stuff on postgresql already and like it :).
PostgreSQL is said to deliver better performance and overall has fewer quirks compared to MariaDB/MySQL but expect less support from Nextcloud devs and community.
Nginx is already assumed to be set up and you have a certbot certificate for your domain.
In these instructions we will use `cloud.example.com` as the domain name, but you should of course replace it with your own.
First, install the required packages:
```sh
pacman -S nextcloud
```
When asked, choose `php-legacy` as your PHP version.
And set the following parameters under `[opcache]` in `/etc/php-legacy/php-fpm.ini`:
```ini
[opcache]
opcache.enable = 1
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 10000
opcache.memory_consumption = 128
opcache.save_comments = 1
opcache.revalidate_freq = 1
```
This should differ from the default only in `opcache.revalidate_freq` but be sure to uncomment all of them anyways.
#### nextcloud.conf
Next you have to create a so called pool file for FPM. It is responsible for spawning dedicated FPM processes for the Nextcloud application. Create a file `/etc/php-legacy/php-fpm.d/nextcloud.conf`.
You can use the file in this repository as a template [Here a link](../static/nextcloud/nextcloud.conf). It should work out of the box without any modifications.
Create the access log directory:
```sh
mkdir -p /var/log/php-fpm-legacy/access
```
#### Systemd service
To overwrite the default php-fpm-legacy service create a file in `/etc/systemd/system/php-fpm-legacy.service.d/override.conf` with the following content:
Now you can `systemctl enable --now php-fpm-legacy`.
##### Keep /etc tidy
As a small bonus you can remove the unnecessary uwsgi config files by adding this to `/etc/pacman.conf`:
```
# uWSGI configuration that comes with Nextcloud is not needed
NoExtract = etc/uwsgi/nextcloud.ini
```
#### Nginx
Finally we're at the nginx part and are almost ready to test our setup.
We're assuming you have a working nginx setup with a certbot certificate for your domain and possible domains are in `/etc/nginx/sites-available/` and symlinked to `/etc/nginx/sites-enabled/` to enable them (like Debian).
The nextcloud documentation has a great [example nginx configuration](https://docs.nextcloud.com/server/20/admin_manual/installation/source_installation.html#example-nginx-configuration) which we will use as a base.
You can find the modified version in this repository [here](../static/nextcloud/nextcloud_nginx).
Simply copy this file into `/etc/nginx/sites-available/nextcloud`, replace `cloud.example.com` with your domain, and symlink it to `/etc/nginx/sites-enabled/nextcloud`.
You should now be able to restart nginx and access your nextcloud instance at https://cloud.example.com.
Nextcloud requires certain tasks to be run on a scheduled basis. See Nextcloud's documentation for some details. The easiest (and most reliable) way to set up these background jobs is to use the systemd service and timer units that are already installed by nextcloud.
Override to the correct php version by adding the file `/etc/systemd/system/nextcloud-cron.service.d/override.conf` with the following content:
You might see in your admin overview (https://cloud.example.com/settings/admin/overview) an error message like this:
Your remote address was identified as "192.168.1.1" and is bruteforce throttled at the moment slowing down the performance of various requests. If the remote address is not your address this can be an indication that a proxy is not configured correctly. Further information can be found in the documentation ↗.
This is because Nextcloud is not able to detect the specific local machine you're connecting from and hence throttles all local connections.
Discussion of this problem can be found here: https://help.nextcloud.com/t/all-lan-ips-are-shown-as-the-router-gateway-how-can-i-get-the-actual-ip-address/134872
Your solution: Set up a local DNS server and resolve your domain to your local IP address, not the public one.
2. Click on the share icon and under share link select "File-drop". This will create a link that you can share with others.
3. Optional: If you want to password protect the link, click on "Advanced settings" under the Sharing tab for the folder detailsand use a password of your choice.
### Human-readable link with redirect
If you want a nice human-readable link you can use your own nginx for this.
Add to your existant server block with port 443 in `/etc/nginx/sites-available/nextcloud` or your domain of choice with the following content:
password.fetch = ["shell", "pass <your_password_path> | head -n1"]
```
Note that <your_user> is not your email address but the username you can also use to login into nextcloud.
You can find it under https://cloud.example.com/settings/users as the smaller text under your display name.
Add to your `~/.config/khard/khard.conf`:
```
[addressbooks]
[[nextcloud]]
path = ~/.local/share/vdirsyncer/contacts/
```
And create `~/.local/share/vidirsyncer/contacts` if not already existing.
We will use this folder to store our contacts.
Initial discovery requires you to run
```sh
vdirsyncer discover nextcloud_contacts
```
once.
You should now be able to sync your contacts with `vdirsyncer sync` and view them with `khard`.
### Cronjob
You can now of course add `vdirsyncer sync` to your cronjob to sync your contacts regularly.
Keep in mind that this will require additional environment variables for pass to work as well, sourcing your `.zprofile` should do the trick with a correct setup.
Ergo your cronjob should look something like this:
Like with `khard` you can now add this to your cronjob to sync your calendar regularly and will also require a sorucing of `~/.zprofile` to work with `pass`. Maybe a wrapper script is appropriate here.
See my [syncclouds.sh script as an example](https://bocken.org/git/Alexander/dotfiles/src/branch/master/.local/bin/syncclouds.sh) which also handles corrupted lockfiles because of unexpected aborts.
TODO: investigate wheter todos are possible to also be synced. Could not get it working myself.