cryptpad / helm Goto Github PK

Create some examples on how create/update files on (customize/*) to change look and feel and translations.

Just in case someone is running into that issue, too:

If you are testing the helm chart with an Ingress AND e.g. let's encrypt staging certificates, be aware that the Chrome browser won't let you load scripts from insecure sites and thus give you a console error of "Failed to fetch a worker script".

The problem is present in Firefox. And it is not present in Chrome, if you are using production grade certificates from let's encrypt.

We need to provide support to use OCI-based registry on Cryptpad Helm chart.

On this first version, we will use registry provided by Github: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

A new task can be added on GH action / workflows (release.yaml) to push chart using helm feature.

Will be importante to have this releases signed, with issue #25

https://docs.cryptpad.org/en/admin_guide/installation.html#configure-cryptpad

Once CryptPad is installed, create an account via the Register button on the home page. To make this account an instance administrator:

    Copy their public key found in User Menu (avatar at the top right) > Settings > Account > Public Signing Key

Do I understand this correctly, that I would first install this chart without the adminKeys populated? And then upgrade the chart after I modified the chart's values.yaml to include the adminKeys?

Test with the OpenDesk project deployment, on Kubernetes cluster with NextCloud sync, and OpenID authentication.

Step to reproduce:

• Log to the platform, access a diagram file on NextCloud
• copy the URL of the diagram and open it in a private window
• Expected result: unregistered user will have credentials required
• Current result: unregistered user can access and download the diagram:

Check decide if is required to setup custom ssl dh param on ingress (nginx and others).

See this documentation

##Objective

• Set custom files location customize

The cryptpad documentation that is being referenced in the values.yaml mentions setting both httpUnsafeOrigin and httpSafeOrigin.

The values.yaml however does not contain any values to set this.

Is this being taken from the ingress`s hosts? What happens if I disable the ingress?

The "Enable remote embedding" admin setting needs to be enabled for the Nextcloud integration to work. This can be done manually in the web interface or automatically during the deployment.

This line ["ENABLE_EMBEDDING", true, '', 0] needs to be added to ./data/decrees/decree.ndjson.

@wginolas can help with more info and details.

New CryptPad versions introduced a new port for websocket.

Review license, instructions and docs.

Since we need to use volumes to setup some preferences, the idea is to provide emptyDir volume to run an instance with temporary data volumes.

Remove all values used to fill variables for docker image with nginx:

# CryptPad API subdomain FQDN
apiDomain: ""
# CryptPad files subdomain FQDN
filesDomain: ""
# Trusted proxy address or CIDR
trustedProxy: ""
# Header to get client IP from (`X-Real-IP` or `X-Forwarded-For`)
realIpHeader: ""
# Instruct Nginx to perform a recursive search to find client's real IP (`on`/`off`) (see [ngx_http_realip_module](https://nginx.org/en/docs/http/ngx_http_realip_module.html))
realIpRecursive: ""
# Path to TLS certificate file
tlsCert: ""
# Path to TLS private key file
tlsKey: ""
# Path to Diffie-Hellman parameters file
tlsDhParam: ""
# TODO: remove  Disable HTTP2
http2Disable: ""

Context

As shown on the picture below, some tests are failing when launching the Helm Charts with default values:
The tests could be found at https://localhost:3000/checkup

Objective

Find why the tests aren't working

Objectives

when Other issue will be closed, create a new release with a GitHub Actions.
See the workflow of xwiki-helm

I tried my first cryptpad installation today, but the pod refuses to reach a stable running state.

I increased the resource limits/requests from 128Mi (example value in the values.yaml) to 512Mi to 1024Mi. That seemed to do the trick, it seems to get ready with 100m CPU and 1024Mi RAM.

It seems the example values given in the values.yaml file are way too low to be practical.