Skip to content

Git-Server auf CentOS ...

centos Eigentlich ist "Git-Server" etwas hoch gegriffen, da als Server-Komponente SSH zum Einsatz kommt. Nichtsdestowenigertrotz ist das Endergebnis ein Git-Repository-Server, den man sehr bequem nutzen kann.

Für den Server habe ich einen User git (UserID 600) angelegt, mit dem die Repositories verwaltet werden sollen und das Homeverzeichnis soll unter /srv/git liegen:
groupadd -g 600 git
useradd -u 600          \
        -g 600          \
        -d /srv/git     \
        -m -s /bin/bash \
        git


Eine Besonderheit unter CentOS ist, dass dort SELinux läuft und wir dem System bekanntgeben müssen, dass es sich bei /srv/git um ein Homeverzeichnis handelt. Die einfachste Methode ist, den Kontext eines bestehenden Homeverzeichnisses auf das neue Verzeichnis zu übertragen.
semanage fcontext -a -e /home/dirk /srv/git
restorecon -R -v /srv/
ls -Zd /srv/git

Zu SELinux gibt es reichlich Dokumentation, ich verweise hier einmal auf den SELinux User's and Administrator's Guide bei RedHat. SELinux kann man auch abschalten, wenn einem der Aufwand zu hoch ist.

Der Rest ist relativ einfach und geht strikt nach der gitolite-Anleitung.

Den eigenen Public-Key (wird benötigt, um gitolite zu verwalten) in das Verzeichnis /srv/git kopieren, für mich hat sich dafür das Format user-host.pub bewährt (ich habe auf jedem Host einen separaten SSH-Key und nutze nicht überall den gleichen).
git clone git://github.com/sitaramc/gitolite
mkdir -p ${HOME}/bin
gitolite/install -to ${HOME}/bin
export PATH=${HOME}/bin:${PATH}
echo 'PATH=${HOME}/bin:${PATH}' >> ${HOME}/.bashrc
gitolite setup -pk user-host.pub


Fertig!

Die restliche Konfiguration läuft über das admin-Repository, das man auschecken muss und dann bearbeitet. Die neue Konfiguration ist direkt nach einem git push aktiv.
git clone git@host:gitolite-admin.git gitolite-admin-host.git


Dort finden sich im keydir-Verzeichnis alle Public Keys von Usern, die Zugriff auf irgendeines der Repositories haben sollen und im Verzeichnis conf liegt die gitolite.conf mit einem Beispiel-Repository.

Viel Spass!

Screen ...

linux Ach ja, nur um es dokumentiert zu haben, ich nutze einen zentralen Einstieg, um all die Systeme zu verwalten auf die ich Zugriff habe.

Dafür ist das Programm Screen ganz hervorragend geeignet. Zusammen mit Tipparbeit sparen baut mir die folgende Konfigurationsdatei aus dem Linuxwiki namens screenrc mittels screen -c screenrc meine Arbeitsumgebung zusammen. Dazu bitte unbedingt ssh-agent einsetzen.

# screen -RD -c screenrc
# screen -ls
# screen -rx <session>
#
# Tabs
caption always "%{kw}%-w%{ky}%n %t%{-}%+w %=%{bw}@%H%{kw} %D %Y-%m-%d %c"
hardstatus string "[%H]"

# Alt-PageUp/Down and Alt-left/right
bindkey ^[^[[5~ prev
bindkey ^[^[[6~ next
bindkey ^[^[OD prev
bindkey ^[^[OC next

# Ctrl-Shift-T
bindkey ^T screen

# Scrollen im xterm
termcapinfo xterm|xterms|xs|rxvt ti@:te@

# Detach mit logout
bind d
bind d pow_detach
bind ^d pow_detach

# jetzt kommen die Sessions
screen -t rechner01  ssh rechner01 #   0
screen -t rechner99  ssh rechner99 #  98
 

Tipps und Tricks mit ssh ...

Dies ist der letzter Teil der Kurzreihe über ssh. Kurz angerissen habe ich ssh-Authentifizierung mit Schlüssel, ssh-agent einsetzen und Tipparbeit sparen bei ssh.

Hier soll es jetzt um Tipps und Tricks rund um SSH gehen.

Mit "ssh -X user@zielrechner" kann man sich - bei entsprechend eingerichteter Gegenstelle und einem lokal laufenden X-Server - die Fenster grafischer Anzeigen lokal ansehen.

Bei Putty kann unter Connection / SSH / X11 mit "Enable X11 forwarding" das gleiche wie unter Linux / Unix mit "ssh -X ..." erreicht werden.

XMing ist ein freier grafischer X-Server für Windows.

ssh fungiert als Filter. Ein 'cat datei | ssh user@zielrechner "grep suchbegriff" | less' überträgt die Datei auf den Zielrechner, führt dort das grep aus und gibt die Ergebnisse an das lokal laufende less weiter.

'tar cf - daten | buffer -m 10m | ssh user@zielrechner "cd ziel && tar xf -"'
kopiert ziemlich schnell viele kleine Dateien und/oder Verzeichnisse.

Tipparbeit sparen bei ssh ...

Unterhalb des eigenen Homeverzeichnis, im Unterverzeichnis .ssh kann man eine config-Datei (~/.ssh/config) pflegen, die eine Menge Tipparbeit ersparen kann.

In diese config-Datei können alle ssh-Optionen einfließen.

Der Aufbau ist ganz einfach:
Host tisch
  HostName maschine.domain.tld
  User user2
  Port 443

Wenn ich mit dieser Config-Datei eine Verbindung mittels "ssh tisch" aufbaue, werden die Einstellungen aus der Config-Datei genommen. Es wird also eine Verbindung als User user2 zum Rechner maschine.domain.tld über Port 443 aufgebaut, also analog "ssh -p 443 user2@maschine.domain.tld". Da finde ich "ssh tisch" kürzer.

Ein weiterer Eintrag
Host stuhl
  HostName maschine.domain.tld
  User user99
  Port 443

würde beispielweise bei "ssh stuhl" analog eine Verbindung mit den gleichen Einstellungen als User "user99" aufbauen.

Die Einstellungen greifen auch beim Kopieren von Daten. "scp datei tisch:/tmp" kopiert "datei" nach "/tmp" auf "maschine.domain.tld".

Einen habe ich noch.

Um das ganze konsistent zu machen, kann man sich noch entsprechende Aliases anlegen. "alias tisch='ssh tisch'", dann kann mittels "tisch befehl", der Befehl mit den Einstellungen aus der config auf maschine.domain.tld ausgeführt werden.

Ausprobieren!

Der erste Teil und der zweite Teil existieren natürlich auch noch.

ssh-agent einsetzen ...

Wenn man sich die Tipparbeit sparen möchte, immer die Passphrase einzutippen oder wenn man verschiedene Schlüssel für verschiedene Zielrechner verwendet, sollte ssh-agent zum Einsatz kommen.

In der aktuellen Shell wird ssh-agent mit dem Kommando
eval $(ssh-agent)
gestartet.

Einen Schlüssel kann man mit dem Kommando
ssh-add <secretKeyFile>
hinzufügen. Sollte Der Schlüssel eine Passphrase benötigen, wird diese abgefragt.

!!! ssh-add fügt nur Schlüssel hinzu, die ausschließlich vom Benutzer lesbar sind. !!!

Wenn ssh-add ohne Parameter aufgerufen wird, werden automatisch die Standard-Identitäten (~/.ssh/identity, ~/.ssh/id_dsa, ~/.ssh/id_rsa) hinzugefügt. Solltet Ihr noch eine identity-Datei haben (gehört zur Protokoll-Version 1), stellt das bitte schleunigst auf Protokoll-Version 2, auch auf dem Server, um.

Bei einer Standard-Ubuntu-Client-(mit Desktop)-Installation, wird automatisch ein ssh-agent mitgestartet.

ssh-agent kann noch ein paar Dinge mehr, die aber hier den Rahmen sprengen würden.

Das war der zweite Teil, des ssh-Ausflugs, der erste ist hier zu finden.

ssh-Authentifizierung mit Schlüssel ...

Da ich schon sehr häufig danach gefragt wurde, gibt es jetzt einen Kurzkurs zu ssh aus Sicht des Clients.

Um sich bei einer ssh-Verbindung mit einem Schlüssel und nicht mit dem Passwort zu authentifizieren, muß man sich mittels

ssh-keygen

einen Schlüssel erzeugen. Man kann mit dem Parameter -t noch den Typ des Schlüssels (dsa oder rsa) angeben, beide Verfahren gelten als ähnlich sicher. Dabei wird ein öffentlicher Teil (mit Endung .pub) und ein geheimer Teil (ohne Endung) erzeugt. Gibt man keine anderen Dateinamen an, heißen die Dateien entweder id_rsa (geheimer Teil) und id_rsa.pub (öffentlich) oder id_dsa (geheimer Teil) und id_dsa.pub (öffentlicher Teil).

!!! Bitte nie den geheimen Teil weitergeben !!!

Der öffentliche Teil des Schlüssels muss jetzt noch auf den Zielrechner übertragen werden, das geht mit

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<zielrechner>

und funktioniert analog mit einem dsa-Schlüssel, für <user> muss der Username und für <zielrechner> die Adresse des Zielrechners angegeben werden.

Wenn alles geklappt hat, funktioniert ein

ssh <user>@<zielrechner>

nach Eingabe der Passphrase, die für den Schlüssel definiert wurde.

Die Passphrase kann mit

ssh-keygen -p

geändert werden

Weitere geplante Folgen:
- ssh-agent einsetzen
- Tipparbeit sparen bei ssh
- Tipps für die Verwendung von ssh