Gitlab Recovery und Migration nach Omnibus
Hi, ich konnte das Gitlab mit testdisk erfolgreich aus dem kaputten Image recovern und auf git.ffnw.de unter /home/git "from source" installieren. Aktuell liegt auf git.ffnw.de also eine lauffähige Installation mit Stand von Samstag. Die Installation ist aktuell gestoppt ist damit niemand aus Versehen Änderungen vornimmt. Statt diese Installation wieder in Betrieb zu nehmen habe ein Gitlab-Backup angelegt, das wir für eine Migration nach Omnibus nutzen können. Das Backup liegt ebenfalls auf git.ffnw.de unter /backup/1479140543_gitlab_backup.tar Johannes du bist in dem Thema Omnibus ja schon drin. Willst du mit dem Backup nochmal eine Migration nach Omnibus durchführen? Um die alte Installation ans Laufen zu bekommen habe ich folgendes auf git.ffnw.de gemacht: +++ Gitlab omnibus gestopt "gitlab-ctl stop" Gitlab from source installiert existierenden Benutzer "git" entfernt und neu hinzugefügt gitlab-ctl uninstall sudo systemctl disable gitlab-runsvdir.service nginx installiert und gitlab site hinzugefügt +++ Vor einer Migration nach Omnibus müssten diese Steps wahrscheinlich rückgängig gemacht werden. Viele Grüße Clemens
ich kümmere mich dann da mal drum gruß johannes
Am 14.11.2016 um 18:14 schrieb Clemens John via Admin <admin@lists.ffnw.de>:
Hi,
ich konnte das Gitlab mit testdisk erfolgreich aus dem kaputten Image recovern und auf git.ffnw.de unter /home/git "from source" installieren. Aktuell liegt auf git.ffnw.de also eine lauffähige Installation mit Stand von Samstag. Die Installation ist aktuell gestoppt ist damit niemand aus Versehen Änderungen vornimmt.
Statt diese Installation wieder in Betrieb zu nehmen habe ein Gitlab-Backup angelegt, das wir für eine Migration nach Omnibus nutzen können. Das Backup liegt ebenfalls auf git.ffnw.de unter /backup/1479140543_gitlab_backup.tar
Johannes du bist in dem Thema Omnibus ja schon drin. Willst du mit dem Backup nochmal eine Migration nach Omnibus durchführen?
Um die alte Installation ans Laufen zu bekommen habe ich folgendes auf git.ffnw.de gemacht: +++ Gitlab omnibus gestopt "gitlab-ctl stop" Gitlab from source installiert existierenden Benutzer "git" entfernt und neu hinzugefügt gitlab-ctl uninstall sudo systemctl disable gitlab-runsvdir.service nginx installiert und gitlab site hinzugefügt +++
Vor einer Migration nach Omnibus müssten diese Steps wahrscheinlich rückgängig gemacht werden.
Viele Grüße Clemens_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Backup wiederhergestellt Gitlab jetzt auf neuster Version Daten alle wieder hergestellt Jetzt warten bis die neuen DNS Einträge greifen Morgen mach ich ssl fertig Update von gitlab geht zukünftig mit aptitude update && aptitude upgrade Von meinem iPhone gesendet
Am 14.11.2016 um 18:54 schrieb Johannes Rudolph via Admin <admin@lists.ffnw.de>:
ich kümmere mich dann da mal drum
gruß
johannes
Am 14.11.2016 um 18:14 schrieb Clemens John via Admin <admin@lists.ffnw.de>:
Hi,
ich konnte das Gitlab mit testdisk erfolgreich aus dem kaputten Image recovern und auf git.ffnw.de unter /home/git "from source" installieren. Aktuell liegt auf git.ffnw.de also eine lauffähige Installation mit Stand von Samstag. Die Installation ist aktuell gestoppt ist damit niemand aus Versehen Änderungen vornimmt.
Statt diese Installation wieder in Betrieb zu nehmen habe ein Gitlab-Backup angelegt, das wir für eine Migration nach Omnibus nutzen können. Das Backup liegt ebenfalls auf git.ffnw.de unter /backup/1479140543_gitlab_backup.tar
Johannes du bist in dem Thema Omnibus ja schon drin. Willst du mit dem Backup nochmal eine Migration nach Omnibus durchführen?
Um die alte Installation ans Laufen zu bekommen habe ich folgendes auf git.ffnw.de gemacht: +++ Gitlab omnibus gestopt "gitlab-ctl stop" Gitlab from source installiert existierenden Benutzer "git" entfernt und neu hinzugefügt gitlab-ctl uninstall sudo systemctl disable gitlab-runsvdir.service nginx installiert und gitlab site hinzugefügt +++
Vor einer Migration nach Omnibus müssten diese Steps wahrscheinlich rückgängig gemacht werden.
Viele Grüße Clemens_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Sehr cool! Vielen lieben Dank für deinen Einsatz! VG bjo Am 14. November 2016 22:33:00 schrieb Johannes Rudolph via Admin <admin@lists.ffnw.de>:
Backup wiederhergestellt Gitlab jetzt auf neuster Version Daten alle wieder hergestellt Jetzt warten bis die neuen DNS Einträge greifen
Morgen mach ich ssl fertig
Update von gitlab geht zukünftig mit
aptitude update && aptitude upgrade
Von meinem iPhone gesendet
Am 14.11.2016 um 18:54 schrieb Johannes Rudolph via Admin <admin@lists.ffnw.de>:
ich kümmere mich dann da mal drum
gruß
johannes
Am 14.11.2016 um 18:14 schrieb Clemens John via Admin <admin@lists.ffnw.de>:
Hi,
ich konnte das Gitlab mit testdisk erfolgreich aus dem kaputten Image recovern und auf git.ffnw.de unter /home/git "from source" installieren. Aktuell liegt auf git.ffnw.de also eine lauffähige Installation mit Stand von Samstag. Die Installation ist aktuell gestoppt ist damit niemand aus Versehen Änderungen vornimmt.
Statt diese Installation wieder in Betrieb zu nehmen habe ein Gitlab-Backup angelegt, das wir für eine Migration nach Omnibus nutzen können. Das Backup liegt ebenfalls auf git.ffnw.de unter /backup/1479140543_gitlab_backup.tar
Johannes du bist in dem Thema Omnibus ja schon drin. Willst du mit dem Backup nochmal eine Migration nach Omnibus durchführen?
Um die alte Installation ans Laufen zu bekommen habe ich folgendes auf git.ffnw.de gemacht: +++ Gitlab omnibus gestopt "gitlab-ctl stop" Gitlab from source installiert existierenden Benutzer "git" entfernt und neu hinzugefügt gitlab-ctl uninstall sudo systemctl disable gitlab-runsvdir.service nginx installiert und gitlab site hinzugefügt +++
Vor einer Migration nach Omnibus müssten diese Steps wahrscheinlich rückgängig gemacht werden.
Viele Grüße Clemens_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Am Dienstag, 15. November 2016, 14:30:50 CET schrieb Jan-Tarek Butt via Admin:
Morgen mach ich ssl fertig
Hi, ich habe SSL mal eingeschaltet. Schema von Eike passt auf Gitlab glaube ich nicht. Man gibt da einfach nur den Pfad zum Key in der Gitlab Config an, setzt nen reconfigure ab und fertig. Viele Grüße Clemens
On 11/17/16 18:41, Clemens John via Admin wrote:
Am Dienstag, 15. November 2016, 14:30:50 CET schrieb Jan-Tarek Butt via Admin:
Morgen mach ich ssl fertig
Hi,
ich habe SSL mal eingeschaltet. Schema von Eike passt auf Gitlab glaube ich nicht. Man gibt da einfach nur den Pfad zum Key in der Gitlab Config an, setzt nen reconfigure ab und fertig.
Eike kümmert sich gleich darum. Das gitlab ist gerade komplett unerreichbar. vg Tarek
Die VM ist online, da läuft der Nginx wohl nicht Am 17. November 2016 18:58:15 MEZ, schrieb Jan-Tarek Butt via Admin <admin@lists.ffnw.de>:
On 11/17/16 18:41, Clemens John via Admin wrote:
Am Dienstag, 15. November 2016, 14:30:50 CET schrieb Jan-Tarek Butt via Admin:
Morgen mach ich ssl fertig
Hi,
ich habe SSL mal eingeschaltet. Schema von Eike passt auf Gitlab glaube ich nicht. Man gibt da einfach nur den Pfad zum Key in der Gitlab Config an, setzt nen reconfigure ab und fertig.
Eike kümmert sich gleich darum.
Das gitlab ist gerade komplett unerreichbar.
vg Tarek
------------------------------------------------------------------------
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
-- vg Stefan
So... habe mir das ding mal angesehen und wollte dafür sorgen, dass das git sowohl unter git.ffnw.de als auch per git.nordwest.freifunk.net erreichbar ist. Folgende Probleme gab es: - nginx erlaubt ja immer nur ein ssl-cert pro server-block, d.h. neben dem standardmäßig in gitlab eingestellten git.ffnw.de block, bräuchte man einen zweiten mit entspr. Cert für git.nordwest.freifunk.net - die gitlab omnibus-installation bringt ihren eigenen nginx mit, der *theoretisch* mittels eines Config-Parameters um weitere Server-Blöcke ergänzbar sein sollte [0]. Praktisch habe ich das nicht zum laufen bekommen; auch wenn die eingefügten zusätzlichen Blöcke sich auf ganz andere Domains bezogen, funktionierte anschließend selbst gitlabs basis-nginx-config nicht mehr Folgende Lösungsmöglichkeiten sehe ich: (1) quick-n-dirty-Möglichkeit, damit zumindest die Weblinks stimmen, wäre, einfach git.nordwest.freifunk.net auf einem anderen Server landen zu lassen (zB 01, wo ja bereits viele andere nordwest.freifunk.net subdomains vom dortigen nginx gehandelt werden). Und von dort auf git.ffnw.de weiterzuleiten. Alles andere als schön, abhängig von 01 und - Tarek wies drauf hin - Dienste, die die subdomain nicht über nginx/webkram aufrufen, wären tot. (2) omnibus mit externem nginx: Gitlab-Omnibus erlaubt wohl, einen externen nginx-server statt des eingebauten zu verwenden; der ist dann wie gewohnt konfigurierbar, zumindest, wenn das besser klappt als die Option in [0] ;D (3) weg mit omnibus: Statt Verwendung von Omnibus wieder die Verwendung einzelner Pakete; gerade auf nem gut abgehangenen System finde ich sowas eigentlich immer besser. Allerdings habe ich auch nur begrenzt Bock, das Konfigurationsgeraffel zu übernehmen :D Meinungen? Viele Grüße, Eike [0] https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.... Am 17.11.2016 um 19:20 schrieb Jan-Tarek Butt via Admin:
On 11/17/16 19:01, Stefan via Admin wrote:
Die VM ist online, da läuft der Nginx wohl nicht
Der läuft. Alles gut :) Sollte sich beheben sobald ssl wieder funtz
vg Tarek
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Meine Meinung Option 4: Ein neues Zertifikat mit beiden domainnamen erzeugen, das geht einfach. Ei certbot mit -d eine weite Domain die landet im Selben Cert File. Ich bin für Omnibus da die wartbarkeit von diesem Problem jetzt mal abgesehen deutlich angenehmer ist und die regelmäßigen Updates mit quasi einem Befehl eingespielt werden können Gruß Johannes Von meinem iPhone gesendet
Am 17.11.2016 um 22:27 schrieb Eike Baran via Admin <admin@lists.ffnw.de>:
So... habe mir das ding mal angesehen und wollte dafür sorgen, dass das git sowohl unter git.ffnw.de als auch per git.nordwest.freifunk.net erreichbar ist.
Folgende Probleme gab es: - nginx erlaubt ja immer nur ein ssl-cert pro server-block, d.h. neben dem standardmäßig in gitlab eingestellten git.ffnw.de block, bräuchte man einen zweiten mit entspr. Cert für git.nordwest.freifunk.net
- die gitlab omnibus-installation bringt ihren eigenen nginx mit, der *theoretisch* mittels eines Config-Parameters um weitere Server-Blöcke ergänzbar sein sollte [0]. Praktisch habe ich das nicht zum laufen bekommen; auch wenn die eingefügten zusätzlichen Blöcke sich auf ganz andere Domains bezogen, funktionierte anschließend selbst gitlabs basis-nginx-config nicht mehr
Folgende Lösungsmöglichkeiten sehe ich:
(1) quick-n-dirty-Möglichkeit, damit zumindest die Weblinks stimmen, wäre, einfach git.nordwest.freifunk.net auf einem anderen Server landen zu lassen (zB 01, wo ja bereits viele andere nordwest.freifunk.net subdomains vom dortigen nginx gehandelt werden). Und von dort auf git.ffnw.de weiterzuleiten. Alles andere als schön, abhängig von 01 und - Tarek wies drauf hin - Dienste, die die subdomain nicht über nginx/webkram aufrufen, wären tot.
(2) omnibus mit externem nginx: Gitlab-Omnibus erlaubt wohl, einen externen nginx-server statt des eingebauten zu verwenden; der ist dann wie gewohnt konfigurierbar, zumindest, wenn das besser klappt als die Option in [0] ;D
(3) weg mit omnibus: Statt Verwendung von Omnibus wieder die Verwendung einzelner Pakete; gerade auf nem gut abgehangenen System finde ich sowas eigentlich immer besser. Allerdings habe ich auch nur begrenzt Bock, das Konfigurationsgeraffel zu übernehmen :D
Meinungen?
Viele Grüße, Eike
[0] https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx....
Am 17.11.2016 um 19:20 schrieb Jan-Tarek Butt via Admin:
On 11/17/16 19:01, Stefan via Admin wrote: Die VM ist online, da läuft der Nginx wohl nicht
Der läuft. Alles gut :) Sollte sich beheben sobald ssl wieder funtz
vg Tarek
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Ich stimme Johannes zu, wir sollten die Omnibus Installation verwenden. Am 17. November 2016 22:49:58 MEZ, schrieb Johannes Rudolph via Admin <admin@lists.ffnw.de>:
Meine Meinung
Option 4:
Ein neues Zertifikat mit beiden domainnamen erzeugen, das geht einfach. Ei certbot mit -d eine weite Domain die landet im Selben Cert File. Ich bin für Omnibus da die wartbarkeit von diesem Problem jetzt mal abgesehen deutlich angenehmer ist und die regelmäßigen Updates mit quasi einem Befehl eingespielt werden können
Gruß Johannes
Von meinem iPhone gesendet
Am 17.11.2016 um 22:27 schrieb Eike Baran via Admin <admin@lists.ffnw.de>:
So... habe mir das ding mal angesehen und wollte dafür sorgen, dass das git sowohl unter git.ffnw.de als auch per git.nordwest.freifunk.net erreichbar ist.
Folgende Probleme gab es: - nginx erlaubt ja immer nur ein ssl-cert pro server-block, d.h. neben dem standardmäßig in gitlab eingestellten git.ffnw.de block, bräuchte man einen zweiten mit entspr. Cert für git.nordwest.freifunk.net
- die gitlab omnibus-installation bringt ihren eigenen nginx mit, der *theoretisch* mittels eines Config-Parameters um weitere Server-Blöcke ergänzbar sein sollte [0]. Praktisch habe ich das nicht zum laufen bekommen; auch wenn die eingefügten zusätzlichen Blöcke sich auf ganz andere Domains bezogen, funktionierte anschließend selbst gitlabs basis-nginx-config nicht mehr
Folgende Lösungsmöglichkeiten sehe ich:
(1) quick-n-dirty-Möglichkeit, damit zumindest die Weblinks stimmen, wäre, einfach git.nordwest.freifunk.net auf einem anderen Server landen zu lassen (zB 01, wo ja bereits viele andere nordwest.freifunk.net subdomains vom dortigen nginx gehandelt werden). Und von dort auf git.ffnw.de weiterzuleiten. Alles andere als schön, abhängig von 01 und - Tarek wies drauf hin - Dienste, die die subdomain nicht über nginx/webkram aufrufen, wären tot.
(2) omnibus mit externem nginx: Gitlab-Omnibus erlaubt wohl, einen externen nginx-server statt des eingebauten zu verwenden; der ist dann wie gewohnt konfigurierbar, zumindest, wenn das besser klappt als die Option in [0] ;D
(3) weg mit omnibus: Statt Verwendung von Omnibus wieder die Verwendung einzelner Pakete; gerade auf nem gut abgehangenen System finde ich sowas eigentlich immer besser. Allerdings habe ich auch nur begrenzt Bock, das Konfigurationsgeraffel zu übernehmen :D
Meinungen?
Viele Grüße, Eike
[0]
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx....
Am 17.11.2016 um 19:20 schrieb Jan-Tarek Butt via Admin:
On 11/17/16 19:01, Stefan via Admin wrote: Die VM ist online, da läuft der Nginx wohl nicht
Der läuft. Alles gut :) Sollte sich beheben sobald ssl wieder funtz
vg Tarek
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
_______________________________________________ Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
-- vg Stefan
participants (6)
-
Bjoern Franke -
Clemens John -
Eike Baran -
Jan-Tarek Butt -
Johannes Rudolph -
Stefan