Cryptpad

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen

Cryptpad

Cryptpad ist ein Online-Office, dass in erster Linie im Internet-Browser zu bedienen ist. Das Alleinstellungsmerkmal ist die Ende-zu-Ende-Verschlüsselung aller Dokumente. Die Entschlüsselung und die Verschlüsselung erfolgen im Browser. Auf dem Server sind keinerlei lesbare Daten abgelegt.

Cryptpad bietet Editoren für formatierte Textdokumente (im HTML-Format) und für Markdown-Dateien und andere Textdateien. Der Anwendungsfall der Tabellenkalkulation wird durch Onlyoffice-Tabellen abgedeckt. Präsentationen können mit Hilfe von Markdown erstellt werden. Bilder und PDF-Dokumente können in die Umgebung hochgeladen und im Browser betrachtet werden. Ein Kalender und ein Kanbanboard zur Aufgabenverwaltung vervollständigen das Angebot.

Das Projekt stellt eine gute Installationsanleitung bereit. Leider ist die Konfiguration des Webservers nur für NGinX dokumentiert, so dass für die Konfiguration des Apache Webserver einige Experimente notwendig wurden.

Installation

Mitglieder, die einen Managed Webspace im Shared Hosting nutzen, müssen für ihre Cryptpad-Installation einen "eigenen Serverdienst" beim Hostsharing-Service anmelden. Diese Option ist im Shared Hosting kostenpflichtig. Für den Serverdienst werden zwei IP-Ports mit dem Server vereinbart. Im Beispiel werden Ports '30001' und '30002' genutzt.

Für die Installation werden mit Hilfe von HSAdmin ein User (hier: 'xyz00-cryptpad') und eine Domain angelegt (hier: 'cryptpad.hs-example.de'). Die Entwickler empfehlen die Nutzung von zwei Domains für eine Cryptpad Installation. Wir nutzen hier eine 'leichtgewichtige' Subdomain 'sandbox.cryptpad.hs-example.de', die bei Hostsharing ohne weitere Konfiguration nutzbar ist.

Für die aktuelle Version wird Node LTS (Version 22.x) empfohlen. Zur Installation (erfolgt weiter unten) siehe NodeJS.

Webserver Konfiguration

Nach dem Aufschalten der Domain 'cryptpad.hs-example.de' passen wir die generierte Verzeichnisstruktur der Domain wie folgt an: 

cd ~/doms/cryptpad.hs-example.de
rm -rf subs/www subs-ssl/www htdocs-ssl/.htaccess
mkdir subs/sandbox subs-ssl/sandbox

In die Verzeichnisse 'subs/sandbox', 'htdocs', 'subs-ssl/sandbox' und 'htdocs-ssl' werden jeweils Dateien mit dem Namen '.htaccess' zur Konfiguration des Apache Webserver abgelegt: 

# cd ~/doms/cryptpad.hs-example.de
# cat subs/sandbox/.htaccess

Redirect permanent / https://sandbox.cryptpad.hs-example.de/

# cd ~/doms/cryptpad.hs-example.de
# cat subs-ssl/sandbox/.htaccess

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:UPGRADE} ^WebSocket$           [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$          [NC]
RewriteRule .* ws://127.0.0.1:30002%{REQUEST_URI}  [proxy]
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

# cd ~/doms/cryptpad.hs-example.de
# cat htdocs-ssl/.htaccess

DirectoryIndex disabled
RewriteEngine On
RewriteBase /   
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:UPGRADE} ^WebSocket$           [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$          [NC]
RewriteRule .* ws://127.0.0.1:30002%{REQUEST_URI}  [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

Eine weitere '.htaccess'-Datei liegt direkt im Hauptverzeichnis der Domain:

  • Beachte die überlangen Zeilen!
  • Wir orientieren uns an der Beispiel Konfiguration des NGinx Servers vom Cryptpad Projekt: [1]
# cd ~/doms/cryptpad.hs-example.de
# cat .htaccess 

# OnlyOffice fonts may be loaded from both domains
SetEnvIf REQUEST_URI ^/common/onlyoffice/.*/fonts/.*$ ALLOW_ALL_ORIGINS
Header Set Access-Control-Allow-Origin "*" env=ALLOW_ALL_ORIGINS
Header Set Access-Control-Allow-Origin "https://sandbox.cryptpad.hs-example.de" env=!ALLOW_ALL_ORIGINS

Header Set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header Set Access-Control-Allow-Headers "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range"
Header Set Access-Control-Max-Age "1728000"
Header Set X-XSS-Protection "1; mode=block"
Header Set X-Content-Type-Options "nosniff"
Header Set Cross-Origin-Resource-Policy "cross-origin"
Header Set Cross-Origin-Embedder-Policy "require-corp"

# the following assets are loaded via the sandbox domain
# they unfortunately still require exceptions to the sandboxing to work correctly.
# if ($uri ~ ^/(?:sheet|doc|presentation)/inner.html) { set $unsafe 1; }
# if ($uri ~ ^/common/onlyoffice/.*/.*\.html) { set $unsafe 1; }
# if ($uri ~ ^/common/onlyoffice/dist/.*/sdkjs/common/spell/spell/spell.js.*$) { set $unsafe 1; }
SetEnvIf REQUEST_URI ^/(sheet|doc|presentation)/inner\.html SET_UNSAFE
SetEnvIf REQUEST_URI ^/common/onlyoffice/.*/.*\.html SET_UNSAFE
SetEnvIf REQUEST_URI ^/common/onlyoffice/dist/.*/sdkjs/common/spell/spell/spell.js.* SET_UNSAFE

# everything except the sandbox domain is a privileged scope, as they might be used to handle keys
# if ($host != $sandbox_domain) { set $unsafe 0; }
SetEnvIfNoCase Host ^sandbox.*$ IS_SANDBOX
SetEnvIfNoCase Host ^(?!sandbox\.).*$ NOT_SANDBOX
SetEnvIfNoCase Host ^(?!sandbox\.).*$ !SET_UNSAFE

# this iframe is an exception. Office file formats are converted outside of the sandboxed scope
# because of bugs in Chromium-based browsers that incorrectly ignore headers that are supposed to enable
# the use of some modern APIs that we require when javascript is run in a cross-origin context.
# We've applied other sandboxing techniques to mitigate the risk of running WebAssembly in this privileged scope
# if ($uri ~ ^/unsafeiframe/inner\.html) { set $unsafe 1; }
SetEnvIf REQUEST_URI ^/unsafeiframe/inner\.html SET_UNSAFE=1

# !SET_UNSAFE: script-src without exceptions
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src 'self'; media-src blob:; style-src 'unsafe-inline' 'self' https://cryptpad.hs-example.de; script-src 'self' resource: https://cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de blob: wss://cryptpad.hs-example.de https://sandbox.cryptpad.hs-example.de; font-src 'self' data: https://cryptpad.hs-example.de; img-src 'self' data: blob: https://cryptpad.hs-example.de; frame-src 'self' https://sandbox.cryptpad.hs-example.de blob:; frame-ancestors 'self' https: vector:" env=!SET_UNSAFE
# SET_UNSAFE: script-src with unsafe exceptions
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src 'self'; media-src blob:; style-src 'unsafe-inline' 'self' https://cryptpad.hs-example.de; script-src 'self' 'unsafe-eval' 'unsafe-inline' resource: https://cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de blob: wss://cryptpad.hs-example.de https://sandbox.cryptpad.hs-example.de; font-src 'self' data: https://cryptpad.hs-example.de; img-src 'self' data: blob: https://cryptpad.hs-example.de; frame-src 'self' https://sandbox.cryptpad.hs-example.de blob:; frame-ancestors 'self' https: vector:" env=SET_UNSAFE

# for debugging
Header Set DebugAllowAllOrigins "allowall" env=ALLOW_ALL_ORIGINS
Header Set DebugAllowOrigins "sandboxonly" env=!ALLOW_ALL_ORIGINS
Header Set DebugSetUnsafe "unsafe" env=SET_UNSAFE
Header Set DebugIsSafe "safe" env=!SET_UNSAFE
Header Set DebugIsSandbox "sandbox" env=IS_SANDBOX
Header Set DebugIsMainDomain "maindomain" env=NOT_SANDBOX

Zwei Datenverzeichnisse werden angelegt und direkt ins 'htdocs-ssl' verlinkt: 

cd $HOME
mkdir data
mkdir data/blob
mkdir data/block
cd $HOME/doms/cryptpad.hs-example.de/htdocs-ssl/
ln -s /home/pacs/xyz00/users/cryptpad/data/blob .
ln -s /home/pacs/xyz00/users/cryptpad/data/block .

Dieser Link muss angepasst werden, wenn der Blob-Speicher in den Zusatzspeicher unter /home/storage verschoben wird (siehe unten)!

Installation von NodeJS

Nach dieser Anleitung hier im Wiki sollte mit Hilfe von 'nvm' 'node' in der Version 22 installiert werden.

Installation des Cryptpad

source ~/.profile
cd $HOME
git clone https://github.com/xwiki-labs/cryptpad.git cryptpad
cd cryptpad 
# aktuelle Version nachsehen
git checkout 2025.3.1
npm ci
npm run install:components
cd config
cp config.example.js config.js
vi config.js

Meine Konfiguration in der 'config.js': 

// $ cat config.js
module.exports = {
 
   httpUnsafeOrigin: 'https://cryptpad.hs-example.de',
   httpSafeOrigin: "https://sandbox.cryptpad.hs-example.de",
   httpAddress: '127.0.0.1',
   httpPort: 30001,
   websocketPort: 30002,
   maxWorkers: 4,
   /*
   adminKeys: [
       "[admin@cryptpad.hs-example.de/xxxxxxxxxxxxxxxxxxxxxxxx=]",
   ],
   */
   inactiveTime: 90, // days
   archiveRetentionTime: 15,
   accountRetentionTime: 365,
   maxUploadSize: 8 * 1024 * 1024,
   filePath: '/home/pacs/xyz00/users/cryptpad/data/file/',
   archivePath: '/home/pacs/xyz00/users/cryptpad/data/archive/',
   pinPath: '/home/pacs/xyz00/users/cryptpad/data/pins',
   taskPath: '/home/pacs/xyz00/users/cryptpad/data/tasks',
   blockPath: '/home/pacs/xyz00/users/cryptpad/data/block',
   blobPath: '/home/pacs/xyz00/users/cryptpad/data/blob',
   blobStagingPath: '/home/pacs/xyz00/users/cryptpad/data/blobstage',
   decreePath: '/home/pacs/xyz00/users/cryptpad/data/decrees',
   logPath: '/home/pacs/xyz00/users/cryptpad/data/logs',
   logToStdout: true,
   logLevel: 'info',
   logFeedback: false,
   verbose: false,
   installMethod: 'unspecified',
};

Der Admin-Key wird später ergänzt. Der erste registrierte User im Cryptpad kann den öffentlichen Schlüssel aus seinem Profil herauskopieren.

Wenn größere Datenmengen erwartet werden, kann der 'blobPath' in den Zusatzspeicher verlegt werden: 

   blobPath: '/home/storage/xyz00/users/cryptpad/data/blob',

Installation von onlyoffice

Es kann onlyoffice installiert werden, um auch das Bearbeiten von z.B. Calc/Excel Dateien zu ermöglichen. 

source ~/.profile
cd ~/cryptpad
/install-onlyoffice.sh --accept-license

Start des Cryptpad

Ich starte das Cryptpad zunächst einfach mit dem 'nohup'-Kommando: 

source ~/.profile
cd ~/cryptpad
nohup node server &

Cryptpad als Dienst starten

Die Cryptpad-Prozesse sollen von Systemd als Dienst automatisch gestartet werden.

Dazu legen wir eine Systemd-Unit an: 

mkdir -p $HOME/.config/systemd/user/
vi $HOME/.config/systemd/user/cryptpad.service

Der Inhalt der Datei soll sein: 

[Unit]
Description=Cryptpad
After=network.target
 
[Service]
Type=simple
WorkingDirectory=%h/cryptpad
Environment="NODE_ENV=production"
Environment="PATH=%h/node_modules/.bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.nvm/versions/node/v22.16.0/bin/node server
Restart=always
PrivateTmp=true
NoNewPrivileges=true
 
[Install]
WantedBy=default.target

(Die Node-Version im Pfad muss ggf. korrigiert werden)

Der Dienst wird aktiviert und gestartet mit: 

systemctl --user daemon-reload
systemctl --user enable cryptpad.service
systemctl --user start cryptpad.service

weiterführende Links


Abgerufen von „https://wiki.hostsharing.net/index.php?title=Cryptpad&oldid=7382“