{"id":1799,"date":"2018-06-03T13:41:32","date_gmt":"2018-06-03T13:41:32","guid":{"rendered":"https:\/\/blog.datentraeger.li\/?p=1799"},"modified":"2018-06-11T07:02:02","modified_gmt":"2018-06-11T07:02:02","slug":"gitea-go-git-frontend","status":"publish","type":"post","link":"https:\/\/blog.datentraeger.li\/?p=1799","title":{"rendered":"gitea: go git frontend"},"content":{"rendered":"

Vor langer Zeit hab ich mir mal Gogs<\/a> gebookmarkt, aber nie wirklich weiterverfolgt. Wenn man jedoch ein bisschen recherchiert, ist Gitea<\/a> wohl die bessere Alternative<\/a>.<\/p>\n

Auch von den Features her finde ich Gitea ansprechend. Auf Github hat jemand eine sch\u00f6ne Tabelle erstellt<\/a>, welche die Features vergleicht.<\/p>\n

Generell w\u00e4re ich ja auch von Gitlab nicht abgeneigt, jedoch finde ich die Minumum-Requirements<\/a> einfach zu hoch f\u00fcr unsere paar Repositories. Gitea gibt sich recht schnell zufrieden und soll auch auf eine Raspberry brauchbar laufen.<\/p>\n

Nun eigentlich die Hauptfrage: Warum brauche ich das ? Eigentlich brauche ich es absolut nicht, konnte auch bisher gut ohne leben. Aber trotzdem, halt darum \ud83d\ude09 Und falls Microsoft tats\u00e4chlich Github kaufen wird, werde ich dort alles von mir abziehen. Das ist aber ein Ger\u00fccht, das schon mehrmals in die Welt gesetzt wurde, noch nichts konkretes<\/del>. EDIT 4.6.:<\/em> Das Ger\u00fccht hat sich leider auch schon best\u00e4tigt<\/a> – Github<\/a> geh\u00f6rt nun Microsoft<\/a>…
\nIch habe nichts wichtiges auf Github, aber dennoch will ich einfach keine MS-Dienstleistungen verwenden, aus Prinzip.
\nZudem arbeite ich recht intensiv mit Redmine und dessen Git-Integration (Referenzierung zu tickets etc).<\/p>\n

Installation<\/h2>\n

Die Installation ist kinderleicht – ob man es manuell oder mit einem Package macht.<\/p>\n

sid\/buster<\/h3>\n

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

Nach dem Setup hatte ich jedoch keinen Schimmer, wie ich mich nun als Admin einloggen k\u00f6nnte. Deshalb hab ich mir einfach einen Admin-User angelegt<\/p>\n

# su - gitea\r\n$ gitea admin create-user --name foobar --password admin \\\r\n    --email peter@bar.fuss --admin -c \/var\/lib\/gitea\/custom\/conf\/app.ini                                 \r\n2018\/06\/03 14:58:09 [I] XORM Log Mode: File(Warn)\r\nNew user 'foobar' has been successfully created!\r\n<\/pre>\n
Stable<\/h3>\n
Da unser Git-Server jedoch auf Stretch l\u00e4uft, werde ich Gitea dort manuell montieren. Da das ganze in Go geschrieben ist, auch nicht weiter umst\u00e4ndlich. Zudem hab ich mich derzeit sowieso ein bisschen in Go verliebt…<\/p>\n
Da wir das ganze nicht als Root laufen lassen wollen, legen wir einen User f\u00fcr gitea an<\/p>\n
adduser --disabled-login --gecos 'gitea' gitea<\/pre>\n
oder – wie ich es mache – in einem manifest. Das ! im Passwort<\/a> sollte eigentlich kein Login erlauben, identisch mit –disabled-login.<\/p>\n
user { 'gitea':\r\n  ensure     => present,\r\n  comment    => 'Gitea Daemon',\r\n  home       => '\/var\/lib\/gitea',\r\n  managehome => true,\r\n  password   => '!',\r\n}\r\n<\/pre>\n
und laden das aktuellste Stable-Binary herunter<\/p>\n
su - gitea\r\nwget -O gitea https:\/\/github.com\/go-gitea\/gitea\/releases\/download\/v1.4.1\/gitea-1.4.1-linux-amd64\r\nchmod +x gitea\r\n<\/pre>\n
Theoretisch k\u00f6nnte man nun bereits gitea manuell starten<\/p>\n
su - gitea\r\n.\/gitea web\r\n<\/pre>\n
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.<\/p>\n
Authentifizierung<\/h4>\n
Es werden unterschiedlich Authentifizierungs-Backends unterst\u00fctzt, bspw. LDAP, SMTP, PAM (PAM jedoch nicht in den vorkompilierten Binaries<\/a>). Naja, da wir nicht wirklich viel User auf dem Server haben, hab ich mich f\u00fcr die Gitea-internen entschieden. LDAP ist ja sch\u00f6n und gut, kann aber auch ein Problem sein, wenn der LDAP nicht erreichbar w\u00e4re..<\/p>\n
init<\/h4>\n
Ich m\u00f6chte jedoch noch ein initfile erstellen
\nIn vielen Tutorials wird von supervisor<\/a> gesprochen. Ich kannte das bis anhin gar nicht und frage mich, warum nicht einfach eine systemd-unit, wie es sonst \u00fcblich 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 \u00fcbernehmen…<\/p>\n
[Unit]\r\nDescription=Gitea (Git with a cup of tea)\r\nDocumentation=man:gitea(1)\r\n# syslog is \"socket activated\"\r\n#After=syslog.target\r\nAfter=network.target\r\n#After=mysqld.service\r\n#After=postgresql.service\r\n#After=memcached.service\r\n#After=redis.service\r\n\r\n[Service]\r\n# Modify these two values and uncomment them if you have\r\n# repos with lots of files and get an HTTP error 500 because\r\n# of that\r\n###\r\n#LimitMEMLOCK=infinity\r\n#LimitNOFILE=65535\r\nType=simple\r\nUser=gitea\r\nGroup=gitea\r\nWorkingDirectory=\/var\/lib\/gitea\r\nExecStart=\/var\/lib\/gitea\/gitea web\r\nRestart=always\r\nEnvironment=USER=gitea HOME=\/var\/lib\/gitea GITEA_WORK_DIR=\/var\/lib\/gitea\r\n\r\n[Install]\r\nWantedBy=multi-user.target\r\n<\/pre>\n
Import<\/h2>\n
Es gibt nat\u00fcrlich auch eine Importfunktion<\/p>\n
Import via HTTPS\/Git-URL<\/h3>\n
Um einen Import von Github oder \u00e4hnlichem zu machen, w\u00e4hlt man “Neue Migration”. Der Rest ist eigentlich straight-forward. W\u00e4hlt man “Mirror”, wird das Repository (in der Standardsetting) alle 8 Stunden gespiegelt. Also eigentlich noch ganz gut, um ein Backup zu machen.<\/p>\n
\"\"<\/p>\n
Diese Einstellungen lassen sich aber sp\u00e4ter auch jederzeit anpassen:<\/p>\n
\"\"<\/p>\n
M\u00f6chte man den Mirror aufheben, muss man in den Settings des Repositories “Convert to regular Repository” w\u00e4hlen.<\/p>\n
\"\"<\/p>\n
Ich bin mir zwar nicht ganz sicher, aber soweit ich gesehen hab, werden keine Issues gespiegelt…<\/p>\n
Import von lokalem Directory<\/h3>\n
EDIT 4.6.: Ein lokaler Import ist doch m\u00f6glich, muss jedoch in der app.ini aktiviert werden:<\/p>\n
...\r\n[security]\r\n...\r\n; True when users are allowed to import local server paths\r\nIMPORT_LOCAL_PATHS = true\r\n...<\/pre>\n
Wenn also IMPORT_LOCAL_PATHS gesetzt ist, kann auch einfach der Pfad mitgegeben werden:<\/p>\n
\"\"<\/p>\n
Eine komplette Auflistung der Config-Paramter findet man \u00fcbrigens im Gitea-Cheat-Sheet<\/a>, was noch hilfreich sein kann…<\/p>\n
Da mein Gitea Server auf meinem Git-Server montiert wird (hm, logischerweise), habe ich bestehende lokale Repositories, die ich verwalten m\u00f6chte.<\/del><\/p>\n
Als erstes legt man ein neues Repository in Gitea an. Dann muss man eigentlich nur den URL als Remote erg\u00e4nzen und das ganze pushen<\/del><\/p>\n
git remote add origin https:\/\/your.gogs.com\/youruser\/yourrepo\r\ngit push origin master\r\n<\/del><\/pre>\n
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…<\/del><\/p>\n
Ich habe es mit einem einzelnen Repository getestet und da hat es bei mir tadellos geklappt, als Referenzen haben ich diesen<\/a> und diesen<\/a> Link verwendet.<\/del><\/p>\n
Da ich auch weiterhin “ganz normal”, also auch ohne gitea arbeiten k\u00f6nnen m\u00f6chte, m\u00fcssen die Rechte zum Repository-Pfad entsprechend passen. Nehmen wir an, ich bin Member der Gruppe ‘staff’. Diese Gruppe ben\u00f6tigt volle Rechte beim Repository-Pfad<\/del><\/p>\n
chgrp -R staff \/var\/lib\/gitea\/repository\r\nchmod -R 775 \/var\/lib\/gitea\/repository\r\n<\/del><\/pre>\n
So sollte auch ein “normales” Arbeiten mit meinem Login-User funktionieren (nat\u00fcrlich immer mit dem vollst\u00e4ndigen Pfad zum jeweiligen Repository)<\/del><\/p>\n
EDIT 4.6.:<\/em> Ich habe mich nun doch soweit eingeschr\u00e4nkt, nur gitea-Logins zu verwenden, da es sonst st\u00e4ndig Berechtigungen im Repository auf den Gitea-User zur\u00fccksetzt und bei gr\u00f6ssen Repositories konnte ich es zwar pushen, in gitea war jedoch nichts zu sehen. Man muss sich das Leben ja nicht bewusst schwerer machen…<\/p>\n
SSH<\/h2>\n
SSH kann man entweder mit OpenSSH einsetzen oder mit einem integrierten SSH-Server von Gitea. Falls man den internen verwenden m\u00f6chte, muss man dies in der app.ini festlegen<\/p>\n
[server]\r\n...\r\nDISABLE_SSH      = false\r\n; built-in server verwenden\r\nSTART_SSH_SERVER = true\r\n; built-in server port\r\nSSH_LISTEN_PORT  = 10022\r\n; displayed port in clone url\r\nSSH_PORT         = 10022\r\n...<\/pre>\n
Der integrierte Server hat irgendwie was – l\u00e4sst by design keine Shell-Logins zu und l\u00e4uft unter dem gitea-User… aber funktionieren tut’s mit beiden Varianten.<\/p>\n
Backup\/Restore<\/h2>\n
Backup k\u00f6nnen mit gitea dump angelegt werden. So wie ich es aus der Dokumentation<\/a> verstehe, wird ein Zip mit allen wichtigen Directories\/Files und einem DB-Dump angelegt.<\/p>\n
Fazit<\/h2>\n
Also mein Fazit (obwohl ich noch nicht wirklich viel sagen kann, habe nur den letzten Sonntag damit verbracht):<\/p>\n
Generell ganz sicher die bessere L\u00f6sung, da auch Gitea freie Software ist, nicht wie Github. Sch\u00f6n w\u00e4re es jedoch, wenn es so etwas wie Federation geben w\u00fcrde, um sich mit anderen privaten Servern zu verbinden. Das w\u00e4re 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\u00f6glich gewesen w\u00e4re. Zudem habe ich gerne das Zeugs bei mir, nicht bei einem Closed-Source-Anbieter. Und erst recht nicht bei Microschrott.<\/p>\n
Links\/Referenzen zu anderen Blogs zum Thema:
\nBlog Gitea\/Gogs<\/a>
\nBlog Gitea unter Debian<\/a><\/p>\n
weitere Alternativen<\/h2>\n
es gibt weitere self-hosted Alternativen, einige davon w\u00e4ren:<\/p>\n