Differences

This shows you the differences between two versions of the page.

--- server:gitea [2017/11/11 22:37] – Probleme bei SSH-Zugriff mitsamt Lösung ergänzt sascha
+++ server:gitea [2018/08/21 15:40] (current) – Update-Problem auf Gitea 1.5 erklärt sascha
@@ Line 109: / Line 109: @@
 ==== Service starten ====
-Damit sollte alles vorbereitet sein und wir können die geänderten Konfigurationen laden sowie Gitea selbst starten:
+Damit sollte fast alles vorbereitet sein. Bevor wir jedoch den Service starten, ändern wir noch eine Kleinigkeit in der Datei ''/usr/lib/systemd/system/gitea.service''.
+:!: Aufgrund der Konfiguration und den gesetzten Umgebungsvariablen durch die Installation ist es nicht möglich, ein ''custom''-Verzeichnis unter ''/var/lib/gitea'' zu verwenden. Es wird schlicht ignoriert. Stattdessen sucht Gitea im Verzeichnis des installierten Binaries, also unter ''/usr/bin/custom''. Um dies zu korrigieren, muss ''gitea'' die Umgebungsvariable ''GITEA_CUSTOM'' mit auf den Weg gegeben werden. Dazu die eben genannte Datei öffnen und am Ende des ''[Service]''-Blocks die folgende ''Environment'' Zeile einfügen:
+<code - /usr/lib/systemd/system/gitea.service>
+[Service]
+...
+Environment=GITEA_CUSTOM=/var/lib/gitea/custom
+</code>
+So kann Gitea bedenkenlos angepasst werden und Dateien werden nach einem Update nicht überschrieben.
+Nun ist alles bereit und wir können die geänderten Konfigurationen laden sowie Gitea selbst starten:
   # systemctl restart nginx
   # systemctl restart sshd
@@ Line 157: / Line 167: @@
   # journalctl -xe
 wobei
-> TIMESTAMP HOSTNAME sshd[16513]: User git not allowed because account is locked
+> TIMESTAMP HOSTNAME sshd[PID]: User git not allowed because account is locked
 einen Hinweis darauf liefert, dass der Benutzer-Account wegen beispielsweise eines fehlenden Passworts nicht berechtigt ist, Verbindungen via SSH aufzubauen.
@@ Line 164: / Line 174: @@
 FIXME
+===== Update-Probleme =====
+==== Update auf Gitea 1.5 unter Arch Linux ====
+Arch Linux verwendet noch den alten 10.1 Versionszweig von MariaDB, da die [[https://lists.archlinux.org/pipermail/arch-general/2017-September/044255.html|neue Version 10.2 aufgrund von größeren Änderungen an Bibliotheksnamen und Strukturänderungen von Datentypen zu weitreichenden Problemen mit anderen Programmen führt]]. Das Problem beim Update auf Gitea 1.5 ist, dass MariaDB in der alten Version andere kleinere Datentypen verwendet, weswegen die Datenbankmigrationen im Zuge des Updates vermeintlich zu viel Platz beanspruchen. Dies macht sich in den Log-Dateien von Gitea unter ''/var/log/gitea/gitea.log'' bemerkbar:
+> 2018/08/21 13:37:00 [I] Migration: Reformat and remove incorrect topics
+> 2018/08/21 13:37:00 [I] This migration could take up to minutes, please be patient.
+> 2018/08/21 13:37:00 [...itea/routers/init.go:60 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: Sync2: Error 1071: Specified key was too long; max key length is 767 bytes
+Das Problem lässt sich recht einfach lösen, indem man die Option ''[[https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_large_prefix|innodb_large_prefix]]'' aktiviert, welche die Beschränkung auf 767 Bytes, die in der Fehlermeldung auftaucht, aufhebt. Um dies zu aktivieren, muss eine MySQL Shell gestartet werden und die Option aktiviert werden:
+  $ mysql -u root -p
+  > set global innodb_large_prefix = `ON`;
+  > exit;
+Wird nun Gitea mittels ''sudo systemctl restart gitea.service'' neugestartet, schlägt die Migration nicht mehr fehl und der Service kann wieder verwendet werden.