Schlagwort-Archive: repository

HOWTO: Der eigene GIT Server mit Gitosis

Veröffentlicht am von | 4 Kommentare

Ich hab ja unlängst über die Vorzüge von Source Control Management Lösungen gesprochen. Deshalb möchte ich nun aufzeigen wie man sich selbst eine entsprechende Versionsverwaltung aufsetzt. Wir werden einen GIT Server aufsetzen und somit auf den Trend den Github und Co vorlebten aufspringen. Um eine einfache Verwaltung für den Zugriff von mehreren Usern auf verschiedene Repositories zu ermöglichen verwenden wir Gitosis

In diesem Tutorial setzen wir Gitosis auf dem neuesten Debian Squeeze Release, Version 6.0.3, auf. Dazu wurde das Betriebssystem in einer Virtual Machine aufgesetzt.

Zu erst installieren wir Git, den Kern unseres Tutorials:

# aptitude install git-core

Danach wird mit der Installation von Gitosis fortgefahren. Dabei könnten, so noch nicht installiert, diverse Abhängigkeiten zu Python installiert werden. Außerdem wird ein User mit dem Namen Gitosis, ebenso wie eine namensgleiche Gruppe und unter /srv/gitosis ein Homeverzeichnis für den User angelegt.

# aptitude install gitosis

Nach der Installation benötigt man einen ssh-rsa Key um sich als Administrator zu registrieren. Diesen benötigt man auf der Client Seite. Unter Windows ist dieser zB mit Puttygen zu erzeugen. Unter Linux wäre der Befehl:

ssh-keygen –t rsa –C “john@example.com”

Dieser funktioniert auch in der Git Bash so man unter Windows auf msysgit zurückgreift.

Dabei werden 2 Files erzeugt: id_rsa (Private Key) und id_rsa.pub (Public Key).

Der Public Key wird nun auf den Linux Server transferiert, der Private Key bleibt nur am Client. Der Transfer kann mittels scp oder wget durchgeführt werden. Abgelegt sollte er unter dem Benutzernamen mit dem man am Server unterwegs ist in folgendes Verzeichnis: /etc/gitosis/sshkeys z.B. /etc/gitosis/sshkeys/theuser

Nicht vergessen darf man, dass man dem gitosis User alle notwendigen Rechte auf den Key verpasst:

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Möchte man das Homeverzeichnis des gitosis Users an einen anderen Ort legen kann man das wie folgt:

# mkdir /home/git

# usermod -d /home/git gitosis

Nicht vergessen rechte geben!

# chown -R gitosis:gitosis /home/git

Nun sind wir soweit, das Admin Repository kann angelegt werden. Gitosis verwendet nämlich ein eigenes Git Repository in dem alle Daten zur Erzeugung der individuellen Repositories und zur Steuerung der Rechte auf diese hinterlegt werden. Dazu wechseln wir auf den gitosis User

# su gitosis

und initialisieren dann den Dienst

$ gitosis-init < /etc/gitosis/sshkeys/thefake

Dabei müssten zwei Zeilen ausgegeben werden die in etwa so aussehen:

Initialized empty Git …
Reinitialized existing Git …

Hat der Server den SSH Port nicht wie standardmäßig auf Port 22 sondern z.B. auf 22222, muss am Client selbst unter ~/.ssh ein File mit dem Namen config angelegt werden. Dort trägt man dann den Host sowie den Port auf dem SSH zu finden ist ein:

Host 10.0.0.3
Port 22022

Nun steht dem initialen Auschecken des Admin-Repositories nichts mehr im Wege. Wir wechseln deshalb auf den Client, auf dem wir Git bereits installiert haben und holen uns das Repository folgendermaßen:

$ git clone gitosis@10.0.0.3:gitosis-admin.git

Dabei erhält man eine lokale Kopie der Configuratinsdatei sowie des Schlüsselverzeichnisses.

Um nun ein neues Repository anzulegen editiert man das Configurationsfile gitosis.conf mit einem Editor seiner Wahl und ergänzt es um folgende Zeilen

[group projektname]
writable = projektname
members = user@example.com

group benennt eine Gruppe von Usern, über die Kindattribute writable und members werden deren Rechte sowie deren Identitäten festgelegt. So kann im obigen Beispiel der Benutzer user@example.com auf das Projekt projektname zugreifen. Mittels Leerzeichen kann man hier mehrere User oder Repositories angeben. Mehr dazu später oder auf in der Gitosis Dokumentation zur Configurationsdatei.

Der Benutzer user@example.com benötigt einen public ssh-rsa Key der im Administrations-Projekt im Unterverzeichnis keydir hinterlegt werden muss. Dabei gilt die Namenskonvention <gitemailadresse>.pub

Erst commiten wir die neue Configuration ins lokale Repository

$ git commit -a -m “Added new repository ‘projektname’”

Anschließend wird die Configration auf den Server aufgespielt.

$ git push

Und schon können wir ein neues Projekt beginnen. Dazu erstellen wir ein neues Verzeichnis, initialisieren darin ein Git Projekt und legen eine erste Datei an.

mkdir projektname
cd projektname
git init
echo “This is a test file.” > README
git add README

Nachdem wir das lokale Repository mit dem eben konfiguriertem Remote Repository verbunden haben commiten wir unsere lokalen Änderungen und laden diese auf den Server.

git remote add origin gitosis@10.0.0.3:projektname
git commit -a -m “Initial commit”
git push –all

Will man weitere Benutzer hinzufügen muss man deren Public Key wie vorhin beschrieben im Administrationsprojekt ablegen und fügt die Email Adresse in der Konfiguration einfach per Leerzeichen hinzu:

[group projektname]
writable = projektname
members = user@example.com another@example.com

Das ganze wird wieder commited und auf den Server gepushed, und schon ist der neue Benutzer berechtigt auf das Repo zuzugreifen.

Möchte man allgemeine Leserechte in einem Repository vergeben, ohne dass dazu ein User eingetragen werden muss, kann man dies individuell steuern indem man eine Kontrolldatei anlegt:

sudo touch /home/git/repositories/test.git/git-daemon-export-ok

Und fertig ist der Git Server. In einem weiteren Blogeintrag werde ich noch über die Installation einer Webmaske berichten. Also schaut mal wieder vorbei.

——–

Achja, sollte man noch nicht so fit mit Git selbst sein kann ich hier ein paar gute Links empfehlen:

Setting up Git (for Github) – http://help.github.com/win-set-up-git/ Eine Installationsaleitung für Git unter WIndows. Die darin enthaltenen Informationen bezüglich User und User Email möchte ich nochmal hervorheben:

$ git config –global user.name “Firstname Lastname”

Damit setzt man den Namen seines Benutzers für alle Git Instanzen auf dem System

$ git config –global user.email “your_email@youremail.com”

Dieser Befehl setzt die Email mit der auch über Gitosis der Key gematched wird. Sie dient somit als zentrales Element der Identifikation.

Generell sind die Github Manpages recht gute Quellen um sich mit Git vertraut zu machen.

Git Tutorials bei Kernel.org – http://web.archive.org/web/20110613161039/http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Leider derzeit offline, aber in meinen Augen der beste Überblick über die Befehle von Git, über die WayBackMachine noch erreichbar.

Wer sich vertiefend mit dem Thema auseinandersetzen will dem sein zwei Online Bücher ans Herz gelegt:

Git In The Trenches – http://cbx33.github.com/gitt/ bzw der Source vom Buch auf Github https://github.com/cbx33/gitt

ProGit – http://progit.org/book/

Bis zum nächsten Commit!

Ähnliche Artikel:

Maven Repository auf Sourceforge

Veröffentlicht am von | 1 Kommentar

Projektabhängigkeiten

Entwickelt man ein Software-Projekt, kommt man wie ich zu dem Punkt, an dem die eigene Software von fremden Bibliotheken abhängig ist. Im Falle von TrayRSS ist das zum Beispiel: hibernate, jdom, rom, junit, log4j. Lauter namhafte Bibliotheken, die auch in den öffentlichen Repositories von Maven verfügbar sind. TrayRSS setzt seit kurzem auf Maven um alle Abhängigkeiten zu sammeln. Doch TrayRSS setzt auch auf Bibliotheken die vielleicht weniger bekannt sind:

Leider sind beide Librarys in keinem Repository vertreten, sodass diese Abhängigkeiten nicht ohne weiteres über Maven aufgelöst werden können.

Damit es nun einem dem Projekt Fremden dennoch möglich ist den Code aus dem Versionierungssystem beziehen und das Projekt zu bauen, kann man ihm natürlich die Bibliotheken oder die Links dazu zur Verfügung stellen. So ist jeder für sich in der Lage die fehlenden Sourcen nachzuziehen und manuell ins lokale Repository zu laden. Ein Aufwand, der dank den Möglichkeiten eines eigenen Webspaces, wie ihn auch Sourceforge bietet, vermieden werden kann.

Aufbau eines Maven Repository

Ein Maven Repository ist eigentlich nichts anderes als ein Haufen Ordner mit ein paar Dateien, die nach folgendem Schema aufgebaut sind:

/gruppe/artefakt/version/artefakt-version.jar

Dabei entspricht die Gruppe den Regeln, die wir schon von Java Packages kennen. Jedes Unterpaket getrennt durch einen Punkt entspricht einem eigenen Verzeichnis. Der Bezeichner Artefakt entspricht der ArtefaktID welches im POM der jeweiligen Bibliothek definiert ist. Versionsnummer und Artefakt kombiniert ergibt die Benennung des Jar Files, welches darin enthalten ist.

Für die Auflösung der Abhängigkeiten des jeweiligen Artefakts liegt neben der Jar Datei auch eine POM Datei auf, in der die entsprechenden Informationen bereitgestellt werden. Beispielhaft der Inhalt einer solchen POM Datei:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>at.nullpointer</groupId>
  <artifactId>paketname</artifactId>
  <version>0.0.1</version>
  <packaging>jar</packaging>
  <name>paketname</name>
  <description>
    Beschreibung des Pakets
  </description>

  <dependencies>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.4.3</version>
      <type>jar</type>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

Hier lässt sich auch die Information zur Ordnerstruktur hervorragend auslesen.

Zusätzlich können noch diverse zusätzliche Datein vorhanden sein um zB die md4 Checksum zu verifizieren oder ähnliches.

Internes Repository im Projekt Web

TrayRSS ist ein Open Source Projekt und wird auf Sourceforge gehostet. Damit wir nun unsere Bibliotheken allen Usern zur Verfügung stellen können greifen wir auf die Möglichkeiten von Sourceforge zurück. Hier wird unter anderem Webspace zum Hosten der Projektseite angeboten, auf den man projektrelevante Daten ablegen kann. Also auch unser Repository.

Wie man sich über SFTP dorthin verbindet wird in folgendem Wikieintrag von Sourceforge aufgezeigt: http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web

SFTP fähige Clients unter Windows sind z.B. WinSCP und Filezilla. Wenn noch nicht installiert findet man unter Linux ein entsprechendes Commandline Tool in der Paketverwaltung der bevorzugten Distribution.

Nun wird einfach ein Verzeichnis unter htdocs angelegt z.B. mit dem Namen repository. In dieses Verzeichnis spielen wir nun wie oben dargestellt eine entsprechende Maven Verzeichnisstruktur ein.

Hier die Beispielhafte Verzeichnis- und Dateistruktur für jNotification:

repository
----de
--------jutzig
------------jnotification
----------------0.3
--------------------jnotification-0.3.jar
--------------------jnotification-0.3.pom

Zugang zum Repository

Dann fehlt nur noch ein Eintrag ins POM des Projektes nach folgendem Beispiel:

<repositories>
  <repository>
    <id>projekt-repository</id>
    <name>projekt Repository</name>
    <url>http://projekt.sourceforge.net/repository/</url>
  </repository>
</repositories>

Nun noch die Abhängigkeiten ganz normal in Maven eingetragen und Maven kann diese nun z.B. mit mvn eclipse:eclipse aus dem Internen Repository auslesen und das Projekt erfolgreich bauen.

Ähnliche Artikel: