Bearbeiten von „StuRa:Server/Eintrittsverwaltung

Zur Navigation springen Zur Suche springen
Warnung: Du bist nicht angemeldet. Deine IP-Adresse wird bei Bearbeitungen öffentlich sichtbar. Melde dich an oder erstelle ein Benutzerkonto, damit Bearbeitungen deinem Benutzernamen zugeordnet werden. Ein eigenes Benutzerkonto hat eine ganze Reihe von Vorteilen.

Die Bearbeitung kann rückgängig gemacht werden. Bitte prüfe den Vergleich unten, um sicherzustellen, dass du dies tun möchtest, und veröffentliche dann unten deine Änderungen, um die Bearbeitung rückgängig zu machen.

Aktuelle Version Dein Text
Zeile 22: Zeile 22:


Ein neues Fenster erscheint und <code>C.UTF-8</code> auswählen.
Ein neues Fenster erscheint und <code>C.UTF-8</code> auswählen.


=== sudo und neovim ===
=== sudo und neovim ===
Zeile 62: Zeile 63:
Jetzt müssen diverse Inputz eingegeben werden. Als Mail wird <code>cert@stura.htw-dresden.de</code> genutzt. Dann den TOS zustimmen. Den EEF-Newsletter nicht abonieren. Und alle Domains für die https-Verbindung auswählen (Default (Enter drücken)).
Jetzt müssen diverse Inputz eingegeben werden. Als Mail wird <code>cert@stura.htw-dresden.de</code> genutzt. Dann den TOS zustimmen. Den EEF-Newsletter nicht abonieren. Und alle Domains für die https-Verbindung auswählen (Default (Enter drücken)).


Wenn die Instanz produktiv für eine längere Zeit genutzt werden soll braucht es jetzt noch ein Autorenewal des Zertifikates. Dazu wird ein cronjob erstellt.
Wenn die Instanz produktiv für eine längere Zeit genutzt werden soll braucht es jetzt noch ein Autorenewal des Zertifikates.


<code>crontab -e</code>


Jetzt wurde ein Editor geöffnet und die nachfolgende Zeile muss eingetragen werden. Damit wird immer zum 1. in jedem Monat das Zertifikat erneuert, sobald es möglich ist.
<code>0 0 1 * * /usr/bin/certbot renew --quiet</code>


=== PostgreSQL 12+ ===
=== PostgreSQL 12+ ===


Als erstes wir PostgreSQL installiert.
<code>apt install postgresql postgresql-contrib -y</code>
Mit nachfolgendem Kommando können wir sehen ob es funktioniert.
<code>sudo -u postgres psql</code>
Wenn jetzt <code>\l</code> eingegeben wird sollten wir die aktuellen Datenbanken sehen.


=== redis ===
=== redis ===
Installation von redis: <code>apt install redis -y</code>
Ob der Server läuft kann mit systemctl getestet werden. <code>systemctl status redis</code>
=== nodejs ===
=== nodejs ===


Installation von nodejs: <code>apt install nodejs -y</code>
Die Version und das es funktioniert kann <code>node --version</code> ausgeführt werden.


== Installation und Konfiguration ==
== Installation und Konfiguration ==
Beim Installieren und Konfigurieren, halten wir uns maßgeblich an die [https://docs.pretix.eu/en/latest/admin/installation/manual_smallscale.html#small-scale-manual-deployment Installationsdokumentation von Pretix] (Aufgerufen am 30.01.2024). Deshalb beschreibe ich nur unsere Abweichungen.
=== Pretix Konfigurationsdatei ===
Die Konfigurationsdatei wird folgendermaßen erstellt.
<code>nvim /etc/pretix/pretix.cfg</code>
####pvb
[pretix]
instance_name=Tix StuRa HTW Dresden
url=https://test.tix.htw.stura-dresden.de
currency=EUR
datadir=/var/pretix/data
trust_x_forwarded_for=on
trust_x_forwarded_proto=on
[database]
backend=postgresql
name=pretix
user=pretix
password=
host=
[mail]
from=tix@stura.htw-dresden.de
host=mail.stura.htw-dresden.de
port=25
admins=admin@stura.htw-dresden.de
[redis]
location=redis://127.0.0.1/0
sessions=true
[celery]
backend=redis://127.0.0.1/1
broker=redis://127.0.0.1/2
####pve
=== [https://docs.pretix.eu/en/latest/admin/installation/manual_smallscale.html#ssl nginx proxy für Pretix] ===
Als nächstes wird die Konfiguration des nginx proxy angepasst mit <code>nvim /etc/nginx/sites-enabled/default</code>
<pre>
# Default server configuration
#
server {
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
####pvb
#server_name _;
server_name test.tix.htw.stura-dresden.de;
#location / {
# # First attempt to serve request as file, then
# # as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404;
#}
####pve
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/test.tix.htw.stura-dresden.de/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/test.tix.htw.stura-dresden.de/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
  ####pvb
        add_header Referrer-Policy same-origin;
        add_header X-Content-Type-Options nosniff;
        location / {
                proxy_pass http://localhost:8345;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header Host $http_host;
        }
        location /media/ {
                alias /var/pretix/data/media/;
                expires 7d;
                access_log off;
        }
        location ^~ /media/cachedfiles {
                deny all;
                return 404;
        }
        location ^~ /media/invoices {
                deny all;
                return 404;
        }
        location /static/ {
                alias /var/pretix/venv/lib/python3.11/site-packages/pretix/static.dist/;
                access_log off;
                expires 365d;
                add_header Cache-Control "public";
        }
####pvb
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
server {
    if ($host = test.tix.htw.stura-dresden.de) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
listen 80 default_server;
listen [::]:80 default_server;
server_name test.tix.htw.stura-dresden.de;
    return 404; # managed by Certbot
}
</pre>
Anschließend nginx neu starten mit <code>systemctl restart nginx</code>. Damit sollte nun die Weboberfläche von nginx mit der passenden URL erreichbar sein.
=== Login und Passwort ändern ===
Jetzt kann man sich einloggen als <code>admin@localhost</code> mit <code>admin</code>. Jetzt ist es wichtig die Logindetails anzupassen.


== Migration von Pretix ==
== Migration von Pretix ==
'''''(Achtung: Dieser Abschnitt setzt die Fähigkeit voraus mit PVE zu arbeiten)'''''
Dieser Guide ist gedacht, sobald Pretix auf eine neue Instanz überführt werden muss. Zum Beispiel wenn pretix endlich als Paket bei nix zur Verfügung steht und wir von unserer Debian Instanz auf NixOS wechseln (leider ist dies noch nicht passiert (Stand 30.01.24)).
Bei der Migration sind die Daten in <code>/var/pretix/data/</code> als auch die Datenbank wichtig<ref>[https://docs.pretix.eu/en/latest/admin/maintainance.html#backups ''Welche Daten sollen gebackuped werden''] Dokumentation von Pretix. Abgerufen am 30. Januar 2024.</ref>.
=== Voraussetzung ===
Es ist wichtig eine neu Aufgesetzte pretix Instanz mit gleicher Pretix Version und PostgreSQL-Version zu haben. Beim testen waren die Domains beider Instanzen unterschiedlich. Man kann bevor die neue Instanz erstellt wird den reverse proxy bei der alten Instanz auschalten. Dann die neue Instanz aufsetzen und mit diesem Guide arbeiten. Dann muss im nachhienein die Konfiguration von nginx nicht verändert werden. Das spart Arbeitsaufwand.
=== Migration ===
In diesem Guide ist bekommt die neue Instanz die VMID 100 (Container 100) und die alte Instanz die VMID 200 (Container 200).
Zuerst soll in beiden Instanzen nginx gestoppt werden, damit die Daten nicht durch das Nutzen der Webseite verändert werden kann.
<code>systemctl stop nginx</code>
Zusätzlich soll in der neuen Instanz pretix gestoppt werden[https://docs.pretix.eu/en/latest/admin/mysql2postgres.html#stop-pretix ''Migration von MariaDB zu PostgreSQL''] Dokumentation von Pretix. Abgerufen am 30. Januar 2024.</ref>.
<code>systemctl stop pretix-web pretix-worker</code>
Auf der alten Instanz muss ein Datenbankdump erstellt. Dazu erst den Container betreten und nachfolgenden Kommando durchführen.
<code>sudo -u postgres pg_dump pretix > pretix_dump290124.sql</code>
Jetzt werden in einer Shell im PVE die relevanten Daten vom alten Container in den neuen Container kopiert. Dazu wird zuerst die beiden Dateisysteme der jeweiligen Container gemounted.
<code>pct mount <VMID></code>
Als Rückgabe sollte etwas wie <code>/var/lib/lxc/<VMID>/rootfs/</code> ausgegeben werden. Damit können wir nun das <code>/var/pretix/data/</code> Verzeichnis im Container 100 löschen (es wird ersetzt mit den Daten aus der alten Instanz).
<code>cd /var/lib/lxc/100/rootfs/var/pretix/data/</code>
<code>rm -r ./*</code>
Dannach kopieren wir die Daten aus dem Verzeichnis von Container 200 in Container 100. Es wird <code>rsync -a</code> genutzt, dass kopiert die Verzeichnisse, Dateien und behält die Zugriffsrechte und -zeiten.
<code>rsync -a /var/lib/lxc/200/rootfs/var/pretix/data/ /var/lib/lxc/100/rootfs/var/pretix/data/</code>
Leider wurde damit nicht die <code>.secret</code> Datei als auch der Datenbankdump kopiert. Das wird jetzt nochmals seperat durchgeführt.
<code>cp -p /var/lib/lxc/200/rootfs/var/pretix/data/.secret /var/lib/lxc/100/rootfs/var/pretix/data/.secret</code>
<code>cp -p /var/lib/lxc/200/rootfs/var/lib/postgresql/pretix_dump_290124.sql /var/lib/lxc/100/rootfs/var/lib/postgresql/pretix_dump_290124.sql</code>
Damit können jetzt beide Dateisystem getrennt werden, weil alle wichtigen Daten nun an richtiger Stelle in der neuen Instanz liegen.
<code>pct unmount <VMID></code>
Im Grunde muss nurnoch die Datenbank in der neuen Instanz wiederhergestellt werden. Dazu wechsle in die Shell der neuen Instanz.
Als nächstes wird die aktuelle Datenbank von pretix gelöscht und neu erstellt, damit das Datenbankschema weg ist. Das Schema wird neu aus dem DBDump erstellt.
<pre>
sudo -u postgres dropdb pretix
sudo -u postgres createdb -O pretix pretix
systemctl restart postgresql
</pre>
Die Datenbank wird dann wie folgt wiederhergestellt:
<code>sudo -u postgres psql -d pretix -f /var/lib/postgresql/pretix_dump_290124.sql</code>
Dann wider alle Services starten.
<code>systemctl start pretix-web pretix-worker nginx</code>
Damit ist nun die Webseite wieder erreichbar und kann wie gewohnt genutzt werden und alle relevanten Daten stehen weiterhin zur verfügung.


= Einzelnachweise =
= Einzelnachweise =
<references />
<references />

Bitte beachte, dass alle Beiträge zu Wiki StuRa HTW Dresden von anderen Mitwirkenden bearbeitet, geändert oder gelöscht werden können. Reiche hier keine Texte ein, falls du nicht willst, dass diese ohne Einschränkung geändert werden können.

Du bestätigst hiermit auch, dass du diese Texte selbst geschrieben hast oder diese von einer gemeinfreien Quelle kopiert hast (weitere Einzelheiten unter StuRa HTW Dresden:Urheberrechte). ÜBERTRAGE OHNE GENEHMIGUNG KEINE URHEBERRECHTLICH GESCHÜTZTEN INHALTE!

Bitte beantworte die folgende Frage, um diese Seite speichern zu können (weitere Informationen):

Abbrechen Bearbeitungshilfe (wird in einem neuen Fenster geöffnet)