Moin, ich möchte auf einem Linuxsystem ein GIT Repository einrichten. Gängige Methode ist ja, einen SSH Zugang einzurichten, mit dem man dann auf das im Dateisystem liegende Repo zugreifen kann. Damit hat aber jeder, der GIT Zugriff haben soll, automatisch vollen SSH Zugang. Das finde ich irgendwie suboptimal... Gibts keine andere Möglichkeit, bei der ich Usern nur Zugriff auf GIT biete, und sonst nix?
Dr. Sommer schrieb: > https://www.kernel.org/pub/software/scm/git/docs/git-daemon.html Für den öffentlichen read-only Zugriff ok, zum pushen wegen fehlender Sicherheit nicht. Schau Dir mal gitosis oder gleich gitlab an.
Man kann auch in SSH einstellen, dass alle oder bestimmte User darüber nur git-Zugriff haben (ForceCommand und so), dann hat man direkt die nette SSH-Authentifizierung & Verschlüsselung.
Zu welchem Zweck? Für Privates kann man doch Github nehmen und wenn den Code keiner sehen soll evtl. ne Basismitgliedschaft.
Eine einfache Möglichkeit wäre auch, dem User in der /etc/passwd die git-shell als Login-Shell zu geben.
Björn B. schrieb: > Schau Dir mal gitosis oder gleich gitlab an. Ist gitosis nicht quasi tot? Ich würde gitolite nehmen. http://andmag.se/2012/04/hosting-your-own-git-repo-with-gitolite/ http://git-scm.com/book/ch4-8.html
monte schrieb: > Ich würde gitolite nehmen. Sieht interessant aus. Also gitolite nutzt ja ssh als Authentifizierung. Das heißt es gibt einen lokalen user git der sich per SSH verbinden kann. Aber hab ich dann nicht das gleiche Problem, dass man dann per SSH alles mögliche aus dem Rechner machen kann, wenn man sich in den GIT Account einloggt? Vielleicht kann mir ja jemand der sich mit gitolite auskennt, diese Frage beantworten, bevor ich stundenlang unnötigerweise im gitolite manual rumgelesen hab ;-)
Ich habe das nie gebraucht, aber das ForceCommand von oben könnte passen. Der Rest der Arbeit liegt dann aber bei dir.
Ich habe alle durch. Nimm gitolite und für git user einen eigenen neuen key generieren. Sonst wirst du wunderbare probleme mit deinen repos bekommen. Z.b. Klonen geht aber pushen nicht. Niemals den key für deinen ssh zugang benutzen. Gruss Jörg
Der user git hat nur rechte für sich. normale loginversuche Werden von der gitolite shell verhindert. Sorry vom ipad geschrieben;) Gruss Jörg
Wenn es nicht unbedingt git sein muß, bietet sich für Projekte die nicht gerade die Komplexität des Linux-Kernels haben (was die Anzahl und Hierarchie der Entwickler angeht), u.U. auch fossil (http://fossil-scm.org) an. Das besteht aus einem einzigen Binary von weniger als 2MB und kann wahlweise lokal, per SSH, als CGI hinter einem bestehenden Webserver oder über einen kleinen eingebauten Webserver angesprochen werden. Neben der eigentlichen Versionsverwaltung sind noch ein Bugtracker und ein Wiki enthalten, so daß man gerade bei kleineren Projekten dafür keinen extra Aufwand treiben muß. Ich habe den Eindruck, daß sehr oft der Vorschlaghammer git genommen wird, ohne darüber nachzudenken, ob nicht ein leichterer Hammer wie fossil viel besser zu dem feinen Nägelchen passen würde, das man gerade einzuschlagen hat.
R. Max schrieb: > Vorschlaghammer git Das ist ja das Schöne an git, man gibt "git init" ein und man hat sein Repository und kann seine Versionsgeschichte anlegen, man muss keinen Server haben/aufsetzen etc. Für kleine Projekte braucht man vermutlich keine Branches & merges womit sich der große Teil der Komplexität erledigt. git ist dank des kleinen Overheads somit wunderbar auch für kleine Projekte geeignet, da man keine unnötigen Bugtracker oder Wiki's dabei hat...
Antiexperte schrieb: > Das ist ja das Schöne an git, man gibt "git init" ein und man hat sein > Repository und kann seine Versionsgeschichte anlegen, man muss keinen > Server haben/aufsetzen etc. Vielleicht ist das falsch rübergekommen, aber auch bei Fossil mußt Du keinen Server aufsetzen, wenn Du keinen brauchst: "fossil new" und Du hast Dein lokales Repository. Aber die Fragestellung in diesem Thread bezog sich nunmal ausdrücklich auf einen Server, deshalb habe ich diese Eigenschaften herausgehoben. Im übrigen gibt es selbst beim Serverbetrieb von Fossil nicht viel "aufzusetzen". > git ist dank des kleinen Overheads somit wunderbar auch für > kleine Projekte geeignet, Woran machst Du den kleineren Overhead von git denn fest? Alleine der Kern von git ist knapp zwölf mal so groß ist wie Fossil und besteht aus hunderten von Dateien, während Fossil als ein einziges (im Grunde installationsfreies) Binary daherkommt: $ rpm -q --qf '%{SIZE} %{NAME}\n' fossil git-core 1441168 fossil 17032393 git-core $ rpm -ql fossil /usr/bin/fossil /usr/share/doc/packages/fossil /usr/share/doc/packages/fossil/COPYRIGHT-BSD2.txt $ rpm -ql git-core | wc -l 767 Dazu kommt, daß git-core (zunindest auf openSUSE) u.A. Perl und Python benötigt, die ihrerseits nicht eben klein sind, während Fossil nur libz und (optional) openSSL braucht. > da man keine unnötigen Bugtracker oder Wiki's dabei hat... Wenn Du sie nicht brauchst, kannst Du sie einfach ignorieren, ohne daß Dir dadurch irgendein Nachteil entsteht. Wenn Du sie irgendwann dann doch nutzen willst, kannst Du das tun, ohne nochmal zusätzlichen Konfigurationsaufwand dafür zu haben. Einen etwas detaillierteren Vergleich zwischen git und Fossil gibt es übrigens hier: http://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki Versteh' mich nicht falsch, ich sage nicht, daß git schlecht ist. Es ist mit Sicherheit das perfekte Tool für den Linux-Kernel und wurde ja auch genau dafür gemacht. Aber es gibt wohl nur wenige andere Projekte, die mit dem Kernel vergleichbare Anforderungen an die Versionsverwaltung haben, und deshalb sollte man sich beim Start eines Projekts gut überlegen, welches Tool am besten paßt, anstatt einfach blindlings git zu nehmen, nur weil das alle tun.
R. Max schrieb: > "fossil new" und Du > hast Dein lokales Repository. Immerhin. R. Max schrieb: > Woran machst Du den kleineren Overhead von git denn fest? Ob kleiner als fossil weiß ich jetzt nicht, aber mit Overhead meinte ich wie viele (evtl. komplizierte) Befehle man zur Pflege seines Repositories braucht - und git ist da doch recht einfach. R. Max schrieb: > Alleine der Kern von git ist knapp zwölf mal so groß ist wie Fossil Na und, das händelt der Packagemanager für mich (du verwendest ja selber einen), und für die 18MB ist noch Platz auf meiner 500GB Platte (und gerüchteweise ist die noch vergleichsweise klein). IDE's, Desktopumgebungen und Spiele sind da jedenfalls um Größenordnungen platzhungriger (und stehen somit weiter oben auf der nicht-installieren-Liste). R. Max schrieb: > Aber es gibt wohl nur wenige andere Projekte, die > mit dem Kernel vergleichbare Anforderungen an die Versionsverwaltung > haben, Es gibt jedenfalls wenige Projekte, die die Anforderung haben, dass das SCM selbst keine 18MB groß sein darf. git passt wunderbar auf kleine Projekte, und dank github kann man das auch sehr einfach zentral auf einem Server haben. Nur weil git auch für große Projekte wie den Kernel geeignet ist, heißt das nicht, dass es weniger für kleine Projekte geeignet wäre...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.