Tag: Atlassian

[Quicktip] Wie man go get und Atlasssian Stash bzw. Gitlab zusammen bringt

In meiner Tätigkeit als Jenkins Admin hat mir das Thema „go get“ und Stash viel Kopfzerbrechen bereitet. Letztendlich ist „go get“ eine Art Alias für git pull, jedoch wird da einige Magic angewendet. Im Normalfall – also mit github und auch plain git Repos funktioniert das ganze wunderbar, sobald man aber Software wie Gitlab oder Stash verwendet, wird es etwas problematisch. Zum einen ist das „.git“, welches sowohl Gitlab als auch Stash an jedes Repo hängen ein Problem, zum anderen aber auch SSH über alternative Ports.

Zum Problem der „.git“ Endung: hängt einfach ein weiteres „.git“ an euren „go get“ Command. Also:

go get git.mydomain.com/foo/bar.git.git

Etwas kniffliger ist die Verwendung eines alternativen Ports und ssh. Stash macht nämlich genau das – der ssh Port ist 7999 in der Default Config. Aber auch hierfür gibt es eine Lösung. Dazu müsst ihr die Datei „.gitconfig“ in eurem Home Folder editieren bzw. anlegen. Die Datei muss dann so aussehen:

[url "ssh://git@stash.yourdomain.com:7999/"]
insteadOf = https://stash.yourdomain.de/

Sobald ihr nun einen Checkout auf

https://stash.yourdomain.de/foo/bar.git

macht, biegt Git diesen Request auf

ssh://git@stash.yourdomain.com:7999/foo/bar.git

um. Somit könnt ihr auf andere Ports gehen, komplett auf andere Domains umschreiben usw.

[Quicktip] Globalen SSH Key in Atlassian Stash hinterlegen

Wenn ihr in Stash viele Repositories habt und ein CI Tool wie Jenkins oder Teamcity nutzt, dann möchtet ihr sicher nicht bei jedem einzelnen Repo den SSH Key des Tools hinterlegen. Da ich lange nach der entsprechenden Stelle in Stash gesucht habe und in den Settings nichts dazu zu finden ist, hier eine mögliche Lösung für das Problem:

Die eine globale Stelle für das Problem gibt es nicht, ABER ihr könnt pro Projekt Zugriffsschlüssel hinterlegen. Ruft dazu einfach das Projekt auf, geht dann in die Einstellungen und dort auf Zugriffsschlüssel. Alle hier hinterlegten Keys können nur lesend oder auch lesend und schreibend für ALLE Repositories dieses Projektes freigeschalten werden. So lange ihr also nicht über allzu viele Projekte verfügt, ist die Einrichtung schnell erledigt 😉

Confluence HSQLDB auf mysql migieren

Folgende Problematik: ihr habt Confluence testweise auf einem Server installiert und nutzt für die Evaluation erstmal die hsqldb – also die integrierte in-Memory Datenbank, die NICHT für den produktiven Einsatz gedacht ist, da sie im Falle eines Absturzes zu Datenverlust führt. Die gestützter sehen das jedoch anders und nutzen das System umgehend produktiv und nun müsst ihr schnell auf eine richtige Datenbank wie MySQL, Oracle usw. umsteigen. Und genau für diesen Punkt ist dieses kleine Tutorial gedacht:

Im Confluence Admin in den Bereich Administration und dort “Sichern und Wiederherstellen” wechseln. “In Sicherungsordner archivieren” sowie “Anhänge sichern” aktivieren und auf sichern klicken.

Das nun erstellte Backup befindet sich (standardmäßig) unter

/var/atlassian/application-data/confluence/backups

Ladet die Datei xmlexport-xxxxxxxx-xxxx.zip herunter – die richtige Datei erkennt ihr am jeweiligen Timestamp.

Anschließen Confluence herunterfahren und die Datei

/var/atlassian/application-data/confluence/confluence.cfg.xml

löschen (auch hier ist der Pfad wieder standardmäßig und kann bei euch evtl. abweichen).

Unter

https://confluence.atlassian.com/display/DOC/Database+JDBC+Drivers

den entsprechenden Treiber für eure zu verwendende DB herunterladen (ist für MySQL und Oracle notwendig), entpacken und die jeweilige .jar Datei in den Pfad (standardmäßig)

/opt/atlassian/confluence/confluence/WEB-INF/lib/

legen.

Mysql my.cnf (/etc/mysql) einstellen:

[mysqld]
character-set-server=utf8
collation-server=utf8_bin
default-storage-engine=INNODB
max_allowed_packet=32M

Mysql neu starten.

Datenbank einrichten:
CREATE DATABASE confluence;
GRANT ALL PRIVILEGES ON confluence.* TO ‘confluenceuser’@’localhost’ IDENTIFIED BY ‘confluencepass’;
FLUSH PRIVILEGES;

Nun müsst ihr Confluence wieder starten und im Browser unter der ursprünglichen URL aufrufen – der Setup Wizard beginnt erneut. Sprache einstellen und dann “Kundenspezifische” Installation wählen. Dort die externe Datenbank Mysql auswählen und auf der nächsten Seite die Zugangsdaten zur Datenbank eintragen:

URL: jdbc:mysql://[db-host]/[db-name]?sessionVariables=storage_engine%3DInnoDB
Benutzer: [db-username]
Kennwort: [passwort]

Anschließend wird die Datenbank erzeugt.

Im nächsten Schritt ganz unten “Wiederherstellen aus Backup” wählen und im folgenden Upload Dialog die vorhin gesicherte

xmlexport-xxxxxxxx-xxxx.zip

wählen. Nun wird die ursprüngliche Datenbank wieder hergestellt und ihr könnt confluence wieder wie gewohnt nutzen.

Confluence zählt LDAP Benutzer mehrfach für die Lizenz

Ein etwas wirrer Titel, aber ich möchte auf folgende Problematik hinweisen – die evtl. auch einfach nur ein Bug ist:

Confluence erlaubt in seinen einzelnen Lizenzpaketen nur eine gewisse Anzahl an Nutzern. Wenn man die Nutzerdaten per LDAP in das System spielt und z.B. nicht alle LDAP Nutzer auch als Confluence User berechtigen möchte, kann man über die Zuweisung von Gruppen regeln, wer Zugriff bekommt und wer nicht.

Anschließend legt man unter “Globale Berechtigungen” einfach die Gruppen oder einzelnen User an und bestimmt, was sie dürfen und was nicht. Nur DIESE User, die entweder der entsprechenden Gruppe angehören, oder aber einzeln gelistet sind, können sich einloggen.

Ein nicht ganz so offensichtlicher Bug/Feature: wenn man den gleichen User in unterschiedlichen Gruppen hinzufügt und diese für Confluence berechtigt, so wird dieser User auch mehrfach für die Lizenz gezählt! Also legt den User einfach in die entsprechend seiner Berechtigungen höchste Gruppe, dann wird er auch nur einmal gezählt.