Vor langer Zeit hab ich mir mal Gogs gebookmarkt, aber nie wirklich weiterverfolgt. Wenn man jedoch ein bisschen recherchiert, ist Gitea wohl die bessere Alternative.

Auch von den Features her finde ich Gitea ansprechend. Auf Github hat jemand eine schöne Tabelle erstellt, welche die Features vergleicht.

Generell wäre ich ja auch von Gitlab nicht abgeneigt, jedoch finde ich die Minumum-Requirements einfach zu hoch für unsere paar Repositories. Gitea gibt sich recht schnell zufrieden und soll auch auf eine Raspberry brauchbar laufen.

Nun eigentlich die Hauptfrage: Warum brauche ich das ? Eigentlich brauche ich es absolut nicht, konnte auch bisher gut ohne leben. Aber trotzdem, halt darum 😉 Und falls Microsoft tatsächlich Github kaufen wird, werde ich dort alles von mir abziehen. Das ist aber ein Gerücht, das schon mehrmals in die Welt gesetzt wurde, noch nichts konkretes. EDIT 4.6.: Das Gerücht hat sich leider auch schon bestätigt – Github gehört nun Microsoft…
Ich habe nichts wichtiges auf Github, aber dennoch will ich einfach keine MS-Dienstleistungen verwenden, aus Prinzip.
Zudem arbeite ich recht intensiv mit Redmine und dessen Git-Integration (Referenzierung zu tickets etc).

Installation

Die Installation ist kinderleicht – ob man es manuell oder mit einem Package macht.

sid/buster

Unter sid ist gitea im Repository, also easy-peasy. Als ich Gitea noch gar nicht kannte, war das meine “schnell-mal-reinschauen”-Variante.

Nach dem Setup hatte ich jedoch keinen Schimmer, wie ich mich nun als Admin einloggen könnte. Deshalb hab ich mir einfach einen Admin-User angelegt

# su - gitea
$ gitea admin create-user --name foobar --password admin \
    --email peter@bar.fuss --admin -c /var/lib/gitea/custom/conf/app.ini                                 
2018/06/03 14:58:09 [I] XORM Log Mode: File(Warn)
New user 'foobar' has been successfully created!

Stable

Da unser Git-Server jedoch auf Stretch läuft, werde ich Gitea dort manuell montieren. Da das ganze in Go geschrieben ist, auch nicht weiter umständlich. Zudem hab ich mich derzeit sowieso ein bisschen in Go verliebt…

Da wir das ganze nicht als Root laufen lassen wollen, legen wir einen User für gitea an

adduser --disabled-login --gecos 'gitea' gitea

oder – wie ich es mache – in einem manifest. Das ! im Passwort sollte eigentlich kein Login erlauben, identisch mit –disabled-login.

user { 'gitea':
  ensure     => present,
  comment    => 'Gitea Daemon',
  home       => '/var/lib/gitea',
  managehome => true,
  password   => '!',
}

und laden das aktuellste Stable-Binary herunter

su - gitea
wget -O gitea https://github.com/go-gitea/gitea/releases/download/v1.4.1/gitea-1.4.1-linux-amd64
chmod +x gitea

Theoretisch könnte man nun bereits gitea manuell starten

su - gitea
./gitea web

Beim ersten Start landet man auch gleich auf der /install-Site und die Basis-Konfiguration kann gemacht werden. Man kann aber auch einfach das configfile unter custom/config/app.ini eingetragen werden.

Authentifizierung

Es werden unterschiedlich Authentifizierungs-Backends unterstützt, bspw. LDAP, SMTP, PAM (PAM jedoch nicht in den vorkompilierten Binaries). Naja, da wir nicht wirklich viel User auf dem Server haben, hab ich mich für die Gitea-internen entschieden. LDAP ist ja schön und gut, kann aber auch ein Problem sein, wenn der LDAP nicht erreichbar wäre..

init

Ich möchte jedoch noch ein initfile erstellen
In vielen Tutorials wird von supervisor gesprochen. Ich kannte das bis anhin gar nicht und frage mich, warum nicht einfach eine systemd-unit, wie es sonst üblich ist ? Da ich’s in sid ja zum Testen bereits mal montiert hab, muss ich das ganze nicht mal mehr definieren, sondern kann das von Debian übernehmen…

[Unit]
Description=Gitea (Git with a cup of tea)
Documentation=man:gitea(1)
# syslog is "socket activated"
#After=syslog.target
After=network.target
#After=mysqld.service
#After=postgresql.service
#After=memcached.service
#After=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea
ExecStart=/var/lib/gitea/gitea web
Restart=always
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

Import

Es gibt natürlich auch eine Importfunktion

Import via HTTPS/Git-URL

Um einen Import von Github oder ähnlichem zu machen, wählt man “Neue Migration”. Der Rest ist eigentlich straight-forward. Wählt man “Mirror”, wird das Repository (in der Standardsetting) alle 8 Stunden gespiegelt. Also eigentlich noch ganz gut, um ein Backup zu machen.

Diese Einstellungen lassen sich aber später auch jederzeit anpassen:

Möchte man den Mirror aufheben, muss man in den Settings des Repositories “Convert to regular Repository” wählen.

Ich bin mir zwar nicht ganz sicher, aber soweit ich gesehen hab, werden keine Issues gespiegelt…

Import von lokalem Directory

EDIT 4.6.: Ein lokaler Import ist doch möglich, muss jedoch in der app.ini aktiviert werden:

...
[security]
...
; True when users are allowed to import local server paths
IMPORT_LOCAL_PATHS = true
...

Wenn also IMPORT_LOCAL_PATHS gesetzt ist, kann auch einfach der Pfad mitgegeben werden:

Eine komplette Auflistung der Config-Paramter findet man übrigens im Gitea-Cheat-Sheet, was noch hilfreich sein kann…

Da mein Gitea Server auf meinem Git-Server montiert wird (hm, logischerweise), habe ich bestehende lokale Repositories, die ich verwalten möchte.

Als erstes legt man ein neues Repository in Gitea an. Dann muss man eigentlich nur den URL als Remote ergänzen und das ganze pushen

git remote add origin https://your.gogs.com/youruser/yourrepo
git push origin master

Da es sich bei mir aber um denselben server handelt, muss ich eigentlich nur die Pfade im .git/config korrigieren und git push origin master, that’s it…

Ich habe es mit einem einzelnen Repository getestet und da hat es bei mir tadellos geklappt, als Referenzen haben ich diesen und diesen Link verwendet.

Da ich auch weiterhin “ganz normal”, also auch ohne gitea arbeiten können möchte, müssen die Rechte zum Repository-Pfad entsprechend passen. Nehmen wir an, ich bin Member der Gruppe ‘staff’. Diese Gruppe benötigt volle Rechte beim Repository-Pfad

chgrp -R staff /var/lib/gitea/repository
chmod -R 775 /var/lib/gitea/repository

So sollte auch ein “normales” Arbeiten mit meinem Login-User funktionieren (natürlich immer mit dem vollständigen Pfad zum jeweiligen Repository)

EDIT 4.6.: Ich habe mich nun doch soweit eingeschränkt, nur gitea-Logins zu verwenden, da es sonst ständig Berechtigungen im Repository auf den Gitea-User zurücksetzt und bei grössen Repositories konnte ich es zwar pushen, in gitea war jedoch nichts zu sehen. Man muss sich das Leben ja nicht bewusst schwerer machen…

SSH

SSH kann man entweder mit OpenSSH einsetzen oder mit einem integrierten SSH-Server von Gitea. Falls man den internen verwenden möchte, muss man dies in der app.ini festlegen

[server]
...
DISABLE_SSH      = false
; built-in server verwenden
START_SSH_SERVER = true
; built-in server port
SSH_LISTEN_PORT  = 10022
; displayed port in clone url
SSH_PORT         = 10022
...

Der integrierte Server hat irgendwie was – lässt by design keine Shell-Logins zu und läuft unter dem gitea-User… aber funktionieren tut’s mit beiden Varianten.

Backup/Restore

Backup können mit gitea dump angelegt werden. So wie ich es aus der Dokumentation verstehe, wird ein Zip mit allen wichtigen Directories/Files und einem DB-Dump angelegt.

Fazit

Also mein Fazit (obwohl ich noch nicht wirklich viel sagen kann, habe nur den letzten Sonntag damit verbracht):

Generell ganz sicher die bessere Lösung, da auch Gitea freie Software ist, nicht wie Github. Schön wäre es jedoch, wenn es so etwas wie Federation geben würde, um sich mit anderen privaten Servern zu verbinden. Das wäre meiner Meinung nach ein Killerfeature. Alles andere – ich scheine nicht wirklich etwas zu vermissen, im Gegenteil – jetzt kann ich auch private Repositories machen, was bisher nur mit einem kostenpflichtigen Account möglich gewesen wäre. Zudem habe ich gerne das Zeugs bei mir, nicht bei einem Closed-Source-Anbieter. Und erst recht nicht bei Microschrott.

Links/Referenzen zu anderen Blogs zum Thema:
Blog Gitea/Gogs
Blog Gitea unter Debian

weitere Alternativen

es gibt weitere self-hosted Alternativen, einige davon wären:

• Gitlab das wohl bekannteste
• Gogs (von dem ja Gitea geforkt wurde)
• Fossil SCM
• Gitolite
• Gitweb

wobei diese Auflistung alles andere als komplett ist und ich auch einige davon nicht genauer angeschaut habe.