rnd:projects:homecloud [UWiki XXX]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Home cloud server ======

===== Background =====
We have for years desired a self-hosted solution to unify our fragmented data collections in one centralized location. This was the major impetus behind [[.:wtfs]], for example. Ideally, we wanted a system that was:

  * self-hosted
  * not overly complicated to install and configure
  * easily accessible across our entire infrastructure
  * able to share selected contents through a public link
  * expandable simply by adding more storage devices

We happened upon our current solution quite by accident while reading 2600. In an article titled "5G Hotspots and Tinc"((Issue 38:1, p. 20)), the author explains that after switching from traditional internet service to a T-Mobile hotspot, they lost access to their home Nextcloud server. They go on to describe how they were able to restore access thanks to [[:tinc]]. Having never heard of either application before, this piqued our interest. A short burst of research convinced us that this was the solution we sought. 

===== Deployment =====
==== Tinc ====
We began the deployment with tinc since we, like the 2600 author, had no control over port forwarding at the installation location. Unfortunately, tinc's configuration parameters had changed in the year and change since the article's publication. 

By far the most painful part of setting tinc up is distributing the key files. Every node on the network needs to have the public key of every other node, even if they're connecting to a central hub as in our case((Tinc 1.1 promises an [[https://www.tinc-vpn.org/documentation-1.1/Invitations.html|invitation feature]] to ease this process.)). 

==== Nextcloud ====
As has been the trend with our recent server operation, we opted to install Nextcloud within [[:Docker]] using the instructions at [[gh>nextcloud/docker]]. In the initial installation, we neglected to enable a persistent volume for the Postgres instance; when we later ran ''docker-compose down'', we lost the entirety of our uploads, plugins, and settings to that point. 

Since the server itself is located on our home LAN, we wanted to be able to access it using a local address whenever possible. Nextcloud has a config option called ''overwritecondaddr'' that tells it when to overwrite the requested URL. If the page request comes from an address matching the [[:regex]] in ''overwritecondaddr'', then the server replaces the URL with ''overwritehost''. Unfortunately, the code which performs this check contains a bug that has inexplicably persisted since at least 2017. A relatively minor change to ''lib/private/AppFramework/Http/Request.php'' is all that is needed to fix the issue((https://github.com/nextcloud/server/issues/6914#issuecomment-339072224)). 

==== Nginx ====
The Nextcloud admin guide's page on NGINX usage((https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html)) looks considerably more daunting that the actual process ended up being. The relevant section of our NGINX server definition is included below. This has proven sufficient for even the CalDAV/CardDAV syncing. We also increased ''client_max_body_size'' to 100 M for faster uploads. 

<code nginx>
# replace www.example.com throughout with the actual domain
server {
  server_name www.example.com;
  access_log /var/log/nginx/nextcloud.log;
  error_log /var/log/nginx/nextcloud.error.log debug;
  
  client_max_body_size 100M;
  
  # redirect http connections to https
  error_page 497 =301 https://www.example.com:8080$request_uri;
  
  location / {
    proxy_set_header     Host $host;
    proxy_set_header     X-Real-IP 10.0.0.1;
    proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header     X-Forwarded-Proto $scheme;
    proxy_pass           http://10.0.0.4:8080;
    proxy_read_timeout   90;
  }
  
  listen [::]:8080 ssl ipv6only=on;
  listen 8080 ssl;
}
</code>


===== Results =====
Once configured properly, operation has been very smooth. The user experience is exactly what one would expect from a cloud storage service. Media streaming worked right out of the box, and calendar syncing to Android((Though we will not cover it in detail here, we use DAVx for bidirectional syncing. It's a set-and-forget app that allows the phone to interact with the Nextcloud calendars as though they were native.)) was easy enough to set up. Navigation (including local access) does come with a noticeable lag, most likely due to hardware limitations. On the whole, however, we are very satisfied with the final product. 

===== Future work =====
As of this writing, our Docker data is all stored on a single external hard drive mounted at ''/mnt/nextcloud''. We believe we will be able to add additional storage space by union mounting however many disks we need over that same directory using something like [[https://github.com/trapexit/mergerfs|MergerFS]], but more research is required. 

{{tag>selfhosting}}