Differences

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

--- server:gitea [2017/11/09 22:49] – sascha
+++ server:gitea [2018/08/21 15:40] (current) – Update-Problem auf Gitea 1.5 erklärt sascha
@@ Line 102: / Line 102: @@
   # usermod -aG git git
 hinzugefügt.
+:!: Wichtig: Damit der SSH-Zugriff über diesen Benutzer funktioniert, muss er ein Passwort besitzen. Sollte dies nicht der Fall sein, kann ihm mittels
+  # passwd git
+ein Passwort zugewiesen werden.
 ==== 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 122: / Line 136: @@
 Um den SSH-Zugriff für einen Benutzer zu aktivieren, muss dieser lokal ein neues [[https://wiki.archlinux.org/index.php/SSH_keys#Generating_an_SSH_key_pair|SSH-Schlüsselpaar generieren]], sofern er noch keins besitzt. Der Inhalt der erzeugten Datei ''~/.ssh/id_rsa.pub'' muss in den Einstellungen des Benutzers unter SSH / GPG Schlüssel als neuer SSH-Schlüssel hinzugefügt werden.
+==== Test & Probleme ====
+Um zu testen, ob der SSH-Zugriff funktioniert, muss als erstes wie gerade beschrieben ein öffentlicher Schlüssel hinterlegt sein. Ist dies der Fall, kann lokal mittels
+  $ ssh -p PROTNUMMER git@git.domain.tld
+versucht werden, sich via SSH zu authentifizieren. Falls als Ausgabe
+> Hi there, You've successfully authenticated, but Gitea does not provide shell access.
+> If this is unexpected, please log in with password and setup Gitea under another user.
+erscheint, hat alles funktioniert und der SSH-Zugriff ist gewährleistet.
+Sollte dies nicht funktionieren, kann mit ''-v'' eine erweiterte Ausgabe von Debug-Meldungen erzwungen werden.
+Möglichkeiten, warum der Zugriff nicht funktioniert, können sein:
+  * Die [[https://wiki.archlinux.org/index.php/SSH_keys#Key_ignored_by_the_server|Berechtigungen für die SSH-Dateien]] sind zu großzügig und die Verwendung wird abgelehnt.
+  * Der falsche SSH-Schlüssel wird verwendet. Dazu kann es sinnvoll sein, lokal die ''~/.ssh/config'' zu modifiezieren:
+    <code - ~/.ssh/config>
+    Host git.domain.tld
+        HostName git.domain.tld
+        User git
+        IdentityFile ~/.ssh/id_rsa.git  # privater Schlüssel zu dem bei Gitea hinterlegten öffentlichen Schlüssel
+        IdentitiesOnly yes
+    </code>
+  * Dem Benutzer ''git'' ist auf dem Server kein Passwort zugewiesen, s. [[server:gitea#benutzer_anlegen|Benutzer anlegen]].
+Letzteres kann sich beispielsweise darin äußern, dass scheinbar alles korrekt konfiguriert ist, allerdings beim Versuch des Verbindungsaufbaus (Ausgaben mit ''ssh [...] -v'')
+> debug1: Offering public key: RSA SHA256:<random_looking_characters> /home/USER/.ssh/id_rsa.git
+> ...
+> debug1: No more authentication methods to try.
+> git@git.domain.tld: Permission denied (publickey).
+zurückgeliefert wird. Dabei kann es sinnvoll sein, einen Blick in die Logs auf dem Server zu werfen, in diesem Fall
+  # journalctl -xe
+wobei
+> 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.
+===== Mailer-Konfiguration =====
+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.