Merge branch 'release/1.1.0'

nextcloud-aci/README.md

@@ -41,7 +41,7 @@ Unfortunately, this approach doesn't work well for two reasons: a technical
 issue, and a pricing issue.
 
 ### The Technical Issue with This Approach
-ended up not working because of limitations in both
+This approach ended up not working because of limitations in both
 Azure Files and Nextcloud. Nextcloud requires `config.php` to be owned by the
 same user account as the web server is running under (i.e. `www-data`) and to
 have permissions of `0770`. Meanwhile, Azure Files uses SMB which does not 
@@ -99,3 +99,6 @@ provides more robust control over volumes at a much more affordable price. F2s
 v2 instances can be used as Kubernetes nodes. This has the added benefit that
 multiple applications can be run on the same VMs in addition to Nextcloud, 
 further increasing the cost effectiveness of your installation.
+
+**See the [nextcloud-aks](https://github.com/GuyPaddock/inveniem-nextcloud-azure/tree/master/nextcloud-aks)
+folder for an approach that works by using AKS.**

nextcloud-aks/addons/helm-ingress/README.md

@@ -0,0 +1,58 @@
+# Helm Ingress Add-on for Nextcloud Running on AKS 
+This folder contains configurations and scripts to assist in setting up an 
+ingress controller on AKS, running over HTTPS with certificates automatically
+issued and renewed by Let's Encrypt.
+
+This approach is based primarily on 
+[Microsoft's Official Documentation](https://docs.microsoft.com/en-us/azure/aks/ingress-tls).
+
+## Using this Kit
+### Providing Settings to the Scripts
+All of the settings needed by scripts need to be provided in `config.env`.
+Copy `config.example.env` to `config.env` and then customize it for your needs.
+
+Some settings are pulled-in from the top-level `nextcloud-aks` `config.env` file 
+as well; make sure both have been configured. See top-level README.md for details.
+
+### Prerequisite: Setting Up Helm and Tiller
+Before Helm can be used to install components on the cluster, the cluster needs
+to be configured with a Tiller server, and provided with TLS certificates to
+secure the connection between the server and Helm clients.
+
+After providing settings in both `config.env` files (the one in the current 
+directory and the one in the top-level folder), run scripts in the following 
+order to perform this setup:
+1. `./generate_ca_cert.sh` (do NOT run this a second time or you will lose CA certs).
+2. `./generate_helm_client_cert.sh`
+3. `./generate_tiller_server_cert.sh`
+4. `./setup_helm.sh`
+
+## Prerequisite: Installing an Ingress Controller and Certificate Issuer
+Before ingress can be deployed for Nextcloud, the cluster needs an ingress 
+_controller_ and a certificate issuer that can use Let's Encrypt to generate 
+SSL certificates.
+
+After setting-up Helm and Tiller, run scripts in the following order to 
+deploy an nginx-based ingress controller and certificate issuer:
+
+1. `./setup_cert_manager.sh`
+2. `./deploy_certmanager_issuer.sh`
+3. `./setup_ingress_controller.sh`
+
+### Deploying the Certificate Manager and Nextcloud Ingress
+You can now deploy an ingress route for Nextcloud in the current Kubernetes 
+namespace by running the following command:
+
+```
+./deploy_nextcloud_ingress.sh
+```
+
+This command is idempotent; you can tweak your deployment and run it again to
+make changes to the ingress configuration.
+
+This configuration automatically routes to the Nextcloud service that is 
+deployed and made available by the top-level `nextcloud-aks` kit. You only need
+to deploy the ingress route once; you don't need to be re-deploy it if/when
+you re-deploy Nextcloud or make changes to your Nextcloud deployment (e.g. 
+adding or removing replicas, updating images, etc). If there are no Nextcloud
+instances available for the ingress to route to, you will get a 503 error.

nextcloud-aks/helm-ingress/config.example.env → nextcloud-aks/addons/helm-ingress/config.example.env

@@ -11,6 +11,8 @@
 # @license GNU AGPL version 3 or any later version
 #
 
+source "../../config.env"
+
 ################################################################################
 # Certificate Settings
 ################################################################################
@@ -91,5 +93,4 @@ CERTMANAGER_NAMESPACE="kube-system"
 #
 # The default is to source from the trusted domain list in the top-level config.
 #
-TRUSTED_DOMAIN_LIST=( ${NEXTCLOUD_TRUSTED_DOMAINS} )
-NEXTCLOUD_INGRESS_HOSTNAME="${TRUSTED_DOMAIN_LIST[0]}"
+NEXTCLOUD_INGRESS_HOSTNAME="${NEXTCLOUD_PRIMARY_HOSTNAME}"

nextcloud-aks/helm-ingress/deploy_certmanager_issuer.sh → nextcloud-aks/addons/helm-ingress/deploy_certmanager_issuer.sh

@@ -21,8 +21,8 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
+source "constants.env"
+source "config.env"
 
 ../preprocess_config.sh "${KUBE_CONFIG_PATH}/certmanager-issuer.template.yaml" | \
     kubectl apply -f -

nextcloud-aks/helm-ingress/deploy_nextcloud_ingress.sh → nextcloud-aks/addons/helm-ingress/deploy_nextcloud_ingress.sh

@@ -23,8 +23,8 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
+source "constants.env"
+source "config.env"
 
 ../preprocess_config.sh "${KUBE_CONFIG_PATH}/ingress-nextcloud.template.yaml" |
     kubectl apply -f -

nextcloud-aks/helm-ingress/generate_ca_cert.sh → nextcloud-aks/addons/helm-ingress/generate_ca_cert.sh

@@ -21,9 +21,9 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
-source "./functions.sh"
+source "constants.env"
+source "config.env"
+source "functions.sh"
 
 mkdir -p "${OUTPUT_PATH}"
 

nextcloud-aks/helm-ingress/generate_helm_client_cert.sh → nextcloud-aks/addons/helm-ingress/generate_helm_client_cert.sh

@@ -20,9 +20,9 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
-source "./functions.sh"
+source "constants.env"
+source "config.env"
+source "functions.sh"
 
 mkdir -p "${OUTPUT_PATH}"
 

nextcloud-aks/helm-ingress/generate_tiller_server_cert.sh → nextcloud-aks/addons/helm-ingress/generate_tiller_server_cert.sh

@@ -20,9 +20,9 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
-source "./functions.sh"
+source "constants.env"
+source "config.env"
+source "functions.sh"
 
 mkdir -p "${OUTPUT_PATH}"
 

nextcloud-aks/helm-ingress/setup_cert_manager.sh → nextcloud-aks/addons/helm-ingress/setup_cert_manager.sh

@@ -21,8 +21,8 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
+source "constants.env"
+source "config.env"
 
 kubectl label namespace \
     "${CERTMANAGER_NAMESPACE}" \

nextcloud-aks/helm-ingress/setup_helm.sh → nextcloud-aks/addons/helm-ingress/setup_helm.sh

@@ -30,8 +30,8 @@
 set -e
 set -u
 
-source "./constants.env"
-source "./config.env"
+source "constants.env"
+source "config.env"
 
 if [[ ! -f "${CA_CERT_PATH}" ]]; then
     echo "CA certificate is missing: ${CA_CERT_PATH}" >&2

nextcloud-aks/helm-ingress/setup_ingress_controller.sh → nextcloud-aks/addons/helm-ingress/setup_ingress_controller.sh

@@ -26,14 +26,14 @@ set -e
 set -u
 
 source "constants.env"
-source "./config.env"
+source "config.env"
 
 helm install --tls \
     stable/nginx-ingress \
     --namespace "${INGRESS_NAMESPACE}" \
     --set 'controller.replicaCount=2' \
     --set 'controller.service.externalTrafficPolicy=Local' \
-    --set-string controller.config.proxy-body-size="512M"
+    --set-string controller.config.proxy-body-size="2G"
 
 # Public IP address of your ingress controller
 for attempt in {1..20}; do

nextcloud-aks/addons/sftp/.gitignore

@@ -0,0 +1 @@
+host_keys/

nextcloud-aks/addons/sftp/README.md

@@ -0,0 +1,75 @@
+# SFTP Server Add-on for Nextcloud Running on AKS 
+This folder contains configurations and scripts to assist in setting up an 
+SFTP server that can grant one or more users direct access to the Azure Files
+volumes that underlie a Nextcloud AKS deployment.
+
+## Using this Kit
+### Providing Settings to the Scripts
+All of the settings needed by scripts need to be provided in `config.env`.
+Copy `config.example.env` to `config.env` and then customize it for your needs.
+
+Some settings are pulled-in from the top-level `nextcloud-aks` `config.env` file 
+as well; make sure both have been configured. See top-level README.md for 
+details.
+
+### Specifying User Names and Passwords
+This is controlled by the `SFTP_USER_ARRAY` array in `config.env`.
+
+See 
+[`config.example.env`](https://github.com/GuyPaddock/inveniem-nextcloud-azure/blob/master/nextcloud-aks/addons/sftp/config.example.env)
+for an example of how to add users and passwords. In the example file, 
+the following users are allowed to log-in to the system:
+- `larry` with a password of `larry-password` (password was encrypted).
+- `moe` with a password of `moe-password` (password was encrypted).
+- `curly` with a password of `curly-password` (password was encrypted).
+
+**NOTE:** All users _must_ have a user ID of `33` to maintain compatibility
+with the way that the Azure Files volumes are mounted in the Nextcloud 
+containers. 
+
+Long story short, Azure Files does not implement an ACL or POSIX ownership 
+controls, but Nextcloud requires specific permissions to function. To 
+accommodate this, the top-level `nextcloud-aks` kit uses options exposed by the 
+Azure Files driver (`mountOptions`) to set the user ID and permissions of each 
+volume at the _Persistent Volume_ level. In the Nextcloud containers, user ID
+`33` is `www-data`. To avoid having to duplicate each persistent volumes just to 
+support SFTP, we are therefore forced to re-use the same user ID in the SFTP 
+container to ensure each user has access to files on those same persistent 
+volumes.
+
+### Specifying which Volumes Users Have Access To
+This is controlled by the `PATH_USERS` associative array in `config.env`.
+
+See 
+[`config.example.env`](https://github.com/GuyPaddock/inveniem-nextcloud-azure/blob/master/nextcloud-aks/addons/sftp/config.example.env)
+for an example of how to grant users access to file shares. In the example file, 
+the following users have access to the file shares specified:
+- Larry and Moe both have access to the `client1` volume/share. It will appear 
+  as `/client1` in SFTP when they log-in to their chroot-ed environment.
+- Only Moe has access to the `client2` volume/share. It will appear as 
+  `/client2` in SFTP when he logs-in to his chroot-ed environment.
+- Curly and Moe both have access to the `client3` volume/share. It will appear 
+  as `/client3` in SFTP when they log-in to their chroot-ed environment.
+
+### Prerequisite: Generating and Deploying Host Keys
+To ensure that users don't get security errors when reconnecting to the cluster
+after an SFTP pod has been cycled, this resource kit requires that SSH server
+keys are pre-generated and deployed as a secret in the cluster.
+
+After providing settings in both `config.env` files (the one in the current 
+directory and the one in the top-level folder), run the following script
+to perform this setup:
+```
+./setup_host_keys.sh
+```
+
+### Deploying the SFTP Server
+You can now deploy the SFTP server to the cluster in the current Kubernetes 
+namespace by running the following command:
+
+```
+./deploy_sftp_app.sh
+```
+
+This command is idempotent; you can tweak your deployment and run it again to
+make changes to the SFTP pod configuration.

nextcloud-aks/addons/sftp/config.example.env

@@ -0,0 +1,71 @@
+##
+# Configuration Constants for the SFTP add-on application.
+#
+# This is an example configuration file for the scripts in this folder. You must
+# tailor it to meet your needs, or you will end up with a less-than-ideal setup.
+#
+# @author Guy Elsmore-Paddock ([email protected])
+# @copyright Copyright (c) 2019, Inveniem
+# @license GNU AGPL version 3 or any later version
+#
+
+source '../../config.env'
+
+################################################################################
+# User Accounts and User Access
+################################################################################
+
+##
+# An array of all the users who should be granted access to the system, along
+# with their encrypted passwords and user IDs.
+#
+# NOTE: User ID MUST be 33 in order to match the Azure Files mount options that
+#       are in place for compatibility with Nextcloud's volume mounts. This
+#       means that all users log-in as the same user ID but with different login
+#       names.
+#
+#       This is safe because:
+#       - Azure Files does not provide any ACL/permission enforcement anyway.
+#       - All users are chroot-ed by login name, so they can't see each other's
+#         files anyway.
+#       - SSH access is disabled, so they can't see who else is logged-in.
+#
+# See documentation here for the format:
+# https://hub.docker.com/r/atmoz/sftp#encrypted-password
+#
+# Per documentation above, passwords can be generated like this:
+# ```
+#   echo -n "your-password" | \
+#     docker run -i --rm atmoz/makepasswd --crypt-md5 --clearfrom=-
+# ```
+#
+SFTP_USER_ARRAY=(
+    'larry:$1$36ZEFQn6$bDdiGy8EFUzaCtO.07xPO1:e:33'
+    'curly:$1$KIB014xD$EOpbnqVSBjPUrJkn2L/Kk1:e:33'
+    'moe:$1$e103gR21$M5JK/a8e2tOIDk.cH9S/5/:e:33'
+)
+SFTP_USER_STRING="${SFTP_USER_ARRAY[@]}"
+
+##
+# An associative array from Nextcloud volume mounts to a space-separated list
+# of users who should have access to that volume mount.
+#
+# Each key defined here must match a value that was defined in the
+# STORAGE_FILE_SHARES value of the top-level config.env file in order for it
+# to be effective.
+#
+declare -A PATH_USERS
+PATH_USERS['client1']='larry moe'
+PATH_USERS['client2']='moe'
+PATH_USERS['client3']='curly moe'
+
+################################################################################
+# Secret Names
+################################################################################
+# The names of ALL secrets must be unique, and must not overlap with any secrets
+# from any other application running on the Kubernetes cluster.
+
+##
+# The name of the secret within Kubernetes that will store the SFTP host keys.
+#
+KUBE_SFTP_CREDS_SECRET="sftp-host-keys"