Bei einem git pull kommt erhält man die Meldung "...cannot merge"
$ git pull ... ... file your_file.rb not up to date, cannot merge.
Eine Möglichkeit zur Lösung:
$ git stash $ git pull $ git stash pop
Bei einem git pull kommt erhält man die Meldung "...cannot merge"
$ git pull ... ... file your_file.rb not up to date, cannot merge.
Eine Möglichkeit zur Lösung:
$ git stash $ git pull $ git stash pop
Die Verwaltung von Repositories und (wie wir später sehen werden) von Benutzern geschieht bei Gitosis über ein eigens dafür vorgesehenes Git-Repository, welches bei der Installation auf dem Server erzeugt wurde. Es lässt sich wie folgt auf dem Client klonen:
cd ~/Projects git clone git@SERVER:gitosis-admin.git
SERVER ist wiederum durch den Namen des Servers zu ersetzen. Da wir vorhin den eigenen öffentlichen SSH-Schlüssel auf den Server kopiert haben, ist kein Passwort notwendig.
Das Repository besteht grundsätzlich aus der Datei gitosis.conf
zur Verwaltung der Repositories und Benutzer sowie dem Verzeichnis keydir
, in dem die SSH-Schlüssel ablegt sind:
$ cd gitosis-admin/ $ ls -ln total 8 -rw-r--r-- 1 501 20 167 3 Jan 19:57 gitosis.conf drwxr-xr-x 4 501 20 136 3 Jan 19:57 keydir
Die Datei gitosis.conf
enthält im initialen Zustand folgende Zeilen:
[gitosis] [group gitosis-admin] writable = gitosis-admin members = tom@mymac
Der Abschnitt „group gitosis-admin“ definiert eine neue Benutzergruppe mit dem Namen „gitosis-admin“, die Schreibzugriff auf das Repository „gitosis-admin“ hat und derzeit nur aus einem Mitglied „tom@mymac“ besteht. „tom“ ist hierbei mein lokaler Benutzername, „mymac“ der Name meines Client-Rechners. Entsprechend enthält das Verzeichnis keydir
eine Datei mit dem Namen tom@mymac.pub
.
Ein neues Repository kann nun erzeugt werden, in dem folgende Zeilen der Datei gitosis.conf
hinzufügt werden:
[group developers] writable = test members = tom@mymac
Das Repository hat hier den Namen „test“, gehört zur Gruppe „developers“ und nur mein eigener Benutzer „tom@mymac“ hat darauf Schreibrechte. Im Prinzip hätte es auch ausgereicht, den Bezeichner „test“ an die obige Zeile „writable = gitosis-admin“ mit Leerzeichen getrennt anzuhängen. Es ist aber aus meiner Sicht sinnvoll, gleich von Anfang an die Repositories für Projekte vom Repository für die administrativen Aufgaben zu unterscheiden.
Nach Speichern der Datei gitosis.conf
wird nun gitosis-admin eingecheckt und auf den Server geschoben („push“):
git commit -a -m "Created repository test." git push
Damit hat „tom@mymac“ Zugriff auf das Repository „git@SERVER:test.git“, das Repository selbst existiert aber noch nicht und muss entsprechend angelegt werden:
cd ~/Projects mkdir test cd test git init git remote add origin git@SERVER:test.git
Hat man bereits ein Projektverzeichnis (egal ob mit oder ohne Dateien), kann der Aufruf von „mkdir test“ entfallen. Anschließend können Dateien dem Projekt hinzugefügt und eingecheckt werden. Beispiel:
echo "This is a test file." > README git add README git commit -m "Initial revision."
Beim „push“ auf den Server wird schlussendlich das Repository erzeugt:
git push origin master:refs/heads/master
Bisher hat auf das erzeugte Test-Repository lediglich der Benutzer „tom@mymac“ Lese- und Schreibzugriff. Weitere Benutzer mit denselben Rechten können erstellt werden, indem diese dem Admin ihren öffentlichen SSH -Schlüssel zur Verfügung stellen. Angenommen, der Benutzer „joey@hismac“ schickt seinen Schlüssel, dann sind folgende Schritte durchzuführen:
cd ~/Project/gitosis-admin cp ~/Download/joey@hismac keydir
In der Datei gitosis.conf ist der Benutzer der Gruppe „developers“ hinzuzufügen:
[group developers] writable = test members = tom@mymac joey@hismac
Dann weiter im Terminal:
git add . git commit -m "Added joey to project test." git push
Will man das Repository hingegen für die Allgemeinheit mit Leserechten veröffentlichen (also ohne Abfrage von Benutzername und Passwort), muss auf dem Server die Datei git-daemon-export-ok
innerhalb des Repositories erzeugt werden,
sudo touch /home/git/repositories/test.git/git-daemon-export-ok
und ist dann wie folgt klonbar:
git clone git://SERVER/test.git
Damit endet dieser Artikel über Gitosis. Für weitere Dokumentation sei auf die README-Datei von gitosis verwiesen.
Kommentare, Fragen und Kritik sind wie immer herzlich willkommen.
Mit den folgenden Zeilen lässt sich für ein bestehendes lokales Repository ein Remote-Repository auf einem Gitosis anlegen und pushen:
# git remote add origin gitosis@servername:project.git # git push origin master:refs/heads/master (Zuvor muss mindestens ein Commit bestehen.)
Konfiguration anpassen
Da das lokale Repository noch nicht mit dem Remote-Repository verknüpft wurde, muss nun die Konfiguration entsprechend angepasst werden. Dazu sind folgende Zeilen nötig:
# git config branch.master.merge refs/heads/master # git config branch.master.remote origin
Danach kann das Repository auch ganz regulär mit git fetch und git pull synchronisiert werden. Wird ein Remote-Repository auf das lokale System geklont, besteht diese Konfiguration bereits. So kann auch alternativ das Repository gelöscht und vom Remote neu geklont werden.
root@h50877:~# iptables -L -n
... Chain fail2ban-apache (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-apache-noscript (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-dovecot-auth (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-postfix (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-postfix-auth (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-sasl (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0
root@h50877:~# iptables -D fail2ban-ssh 1
Clearing faults from SC
a) Show the faults on the system controller
sc> showfaults -v
b) For each fault listed run
sc> clearfault <uuid>
c) If there are any disabled components run
sc> clearasrdb
d) Clear ereports
sc> setsc sc_servicemode true sc> clearereports -y sc> setsc sc_servicemode false *To clear the FMA faults and error logs from Solaris:*
a) Show faults in FMA
# fmadm faulty
b) For each fault listed in the ‚fmadm faulty‘ run
# fmadm repair <uuid>
c) Clear ereports and resource cache
# cd /var/fm/fmd # rm e* f* c*/eft/* r*/*
d) Reset the fmd serd modules
# fmadm reset cpumem-diagnosis # fmadm reset cpumem-retire # fmadm reset eft # fmadm reset io-retire
e) Reboot the system
Clearing faults from SC: /eft/* r*/* d) Reset the fmd serd modules # fmadm reset cpumem-diagnosis # fmadm reset cpumem-retire # fmadm reset eft # fmadm reset io-retire e) Reboot the systema) Show the faults on the system controller sc> showfaults -v b) For each fault listed run sc> clearfault <uuid> c) If there are any disabled components run sc> clearasrdb d) Clear ereports sc> setsc sc_servicemode true sc> clearereports -y sc> setsc sc_servicemode false *To clear the FMA faults and error logs from Solaris:* a) Show faults in FMA # fmadm faulty b) For each fault listed in the 'fmadm faulty' run # fmadm repair <uuid> c) Clear ereports and resource cache # cd /var/fm/fmd # rm e* f* c*
Clearing faults from SC
a) Show the faults on the system controller
sc> showfaults -v
b) For each fault listed run
sc> clearfault <uuid>
c) If there are any disabled components run
sc> clearasrdb
d) Clear ereports
sc> setsc sc_servicemode true sc> clearereports -y sc> setsc sc_servicemode false *To clear the FMA faults and error logs from Solaris:*
a) Show faults in FMA
# fmadm faulty
b) For each fault listed in the ‚fmadm faulty‘ run
# fmadm repair <uuid>
c) Clear ereports and resource cache
# cd /var/fm/fmd # rm e* f* c*/eft/* r*/*
d) Reset the fmd serd modules
# fmadm reset cpumem-diagnosis # fmadm reset cpumem-retire # fmadm reset eft # fmadm reset io-retire
e) Reboot the system
Clearing faults from SC: /eft/* r*/* d) Reset the fmd serd modules # fmadm reset cpumem-diagnosis # fmadm reset cpumem-retire # fmadm reset eft # fmadm reset io-retire e) Reboot the systema) Show the faults on the system controller sc> showfaults -v b) For each fault listed run sc> clearfault <uuid> c) If there are any disabled components run sc> clearasrdb d) Clear ereports sc> setsc sc_servicemode true sc> clearereports -y sc> setsc sc_servicemode false *To clear the FMA faults and error logs from Solaris:* a) Show faults in FMA # fmadm faulty b) For each fault listed in the 'fmadm faulty' run # fmadm repair <uuid> c) Clear ereports and resource cache # cd /var/fm/fmd # rm e* f* c*