Hallo Linuxfreunde,
ich bearbeite Dateien auf meinem VServer via scp. Nun möchte ein weiterer Entwickler L/S-Zugriff auf ein Verzeichniss haben. Wie stellt man da am besten an? Ohne FTP.
Ich hab erstmal einen neuen User angelegt, mittels dem kann die Person schonmal lesen (warscheinlich aber alle Verzeichnisse, das ist aber OK, ich vertraue der Person). Schreibzugriff hab ich für eine einzelne Datei mittels 775er Recht zugelassen was funktioniert hat. Was sicher nicht der beste Weg ist. Ich hab kurz versucht mit dem Paket scponly ans Ziel zu gelangen was an der Meldung: "equivalent of ld.so" scheiterte (bei Recherchen viel auf das es kaum Doku zu scponly unter Debian gibt und das es seit 2008 scheinbar auch keine neuen Einträge gibt.)
bin wie immer für jeden Tipp dankbar :D Grüße
Hi,
On Wed, March 2, 2011 10:43, streber wrote:
ich bearbeite Dateien auf meinem VServer via scp.
Scp ist fuer die Installation ja erstmal ok.
Hmm. Wieso bearbeitest Du die Dateien auf dem Server?
Hast Du keine lokale Kopie (z.B. auf Deinem PC oder Laptop) wo Du alles erst mal ausprobierst?
Nun möchte ein weiterer Entwickler L/S-Zugriff auf ein Verzeichniss haben. Wie stellt man da am besten an? Ohne FTP.
Warum braucht der Zugriff auf das Verzeichnis? Und dann noch schreibend?
Ich hab erstmal einen neuen User angelegt, mittels dem kann die Person schonmal lesen (warscheinlich aber alle Verzeichnisse, das ist aber OK, ich vertraue der Person).
Ist ja an sich erstmal lobenswert dass Du Freunde hast. Hat aber mit Entwickeln nix zu tun.
Schreibzugriff hab ich für eine einzelne Datei mittels 775er Recht zugelassen was funktioniert hat. Was sicher nicht der beste Weg ist.
Ist es nicht. Ein kleiner Fehler und einer von Euch beiden hat keinen Zugriff mehr. Die Rechteverwaltung wird bald mehr Kopfschmerz machen als eine richtige Loesung aufzusetzen.
Ich hab kurz versucht mit dem Paket scponly ans Ziel zu gelangen was an der Meldung: "equivalent of ld.so" scheiterte (bei Recherchen viel auf das es kaum Doku zu scponly unter Debian gibt und das es seit 2008 scheinbar auch keine neuen Einträge gibt.)
Das es seit 2008 nix neues gibt liegt daran, dass scponly einfach mal stabil ist. Ohne den exakten Output kann ich Dir leider nicht sagen was das Problem ist. Bei mir geht scponly prima (Debian).
Ich wuerde Dir empfehlen Dich mal mit einem Versionskontrollsystem anzufreunden. Das ist schon eine gute Idee, wenn man alleine entwickelt (man hat reichlich Backups die man bei Bedarf auch vergleichen kann). Wenn man zu zweit entwickelt ist es einfach mal Pflicht ("hab ich gestern nicht in Zeile x ein y gemacht? Warum ist das heute weg?").
Die Vorgehensweise ist dann ganz einfach: Ihr beide entwickelt jeweils in einer lokalen Kopie (im Slang: "working copy") in der auch erstmal gruendlich getestet werden kann. Dann wird es eingecheckt und der andere kann es sich bei Bedarf ziehen und mit seinen eigenen Aenderungen mergen ("moerdsch'n"). Wenn eine neue Version hinreichend stabil ist gibt es zwei Varianten sie auf den Server zu bekommen - entweder hat der Server auch nur eine working copy und Du machst einen checkout/update oder Du kopierst den Inhalt deiner working copy per scp auf den Server. Ein netter Nebeneffekt: die Administration bleibt bei einer Person und damit ist auch klar wer es kaputt gemacht hat wenn es mal nicht geht (das ist nicht boese, sondern erleichtert die Diagnose).
Es spricht auch nix dagegen das zentrale Repository auf dem selben Server zu speichern, der auch das Ziel der Entwicklung ist - nur halt in einem anderen Verzeichnis.
Du hast die Wahl zwischen vielen Systemen, die alle ihre Vor- und Nachteile haben.
Finger weg von kommerziellen Systemen: die sind entweder grottenschlecht (MS Source Safe) oder sehr teuer (Clearcase, etc.).
CVS - der Klassiker, wird nicht mehr weiterentwickelt. Ist relativ einfach aufzusetzen, hat aber viele Nachteile. Macht Probleme wenn Entwickler unterschiedliche Systemaccounts haben. War mal das Standardsystem, wird aber nur noch von einigen aelteren Projekten eingesetzt. Ignoriere es bitte, Du wirst nur ab und zu Verweise auf CVS sehen (meistens im Kontext von "im Gegensatz zu CVS funktioniert hier XYZ").
SVN (Subversion) - wenn auf dem Server schon Apache laeuft ist das sehr einfach aufzusetzen: installier einfach die Pakete fuer das Subversion-Apache-Modul und dann bau Dir Dein Repository. Die Doku ist Klasse. Es ist einfach zu administrieren und einfach zu verstehen. Deine Entwickler brauchen nicht unbedingt einen echten Account, sondern muessen nur in der Passwort-Datei von SVN stehen. Ist heute einer der Quasi-Standards (z.B. KDE und viele andere Projekte).
SVK - gut zur Umgewoehnung auf dezentrale Tools, setzt auf SVN auf.
Git - dezentrales Tool, was fuer die Entwicklung des Linux-Kerns entwickelt wurde. Ist heute eines der Standard-Tools. Keine Ahnung wie man es aufsetzt - ich benutze bisher (immernoch) SVN. Die Konzepte hinter dezentralen Tools sind etwas schwierig zu verstehen - sie skalieren aber besser auf viele Entwickler.
Mercurial - ebenfalls dezentral, streitet sich mit Git um die Vorherrschaft in diesem Feld.
Es gibt noch einige mehr, aber mit SVN, Git oder Mercurial machst Du keine Fehler.
Konrad
Hallo,
Konrad Rosenbaum schrieb:
Es gibt noch einige mehr, aber mit SVN, Git oder Mercurial machst Du keine Fehler.
SCP sendet alle Daten verschlüsselt, richtig? Um selbiges mit einem webbasiernden SVN zu erreichen, brauch ich aber wieder SSL (bzw. es empfielt sich) oder? Das könnte dann wieder zu Problemen führen, da Port 443 bei mir bereits für SCP verwendet wird. (Ein leider notwendiger Umbogen für eine FW hinter der ich ab und zu sitze).
Danke und Grüße
2011-03-02 14:02, streber skrev:
Hallo,
Konrad Rosenbaum schrieb:
Es gibt noch einige mehr, aber mit SVN, Git oder Mercurial machst Du keine Fehler.
SCP sendet alle Daten verschlüsselt, richtig? Um selbiges mit einem webbasiernden SVN zu erreichen, brauch ich aber wieder SSL (bzw. es empfielt sich) oder?
Nein, du kannst SSH über einen Eintrag in der Datei authorized_keys anweisen, nur (z.B.) svn-Befehle auszuführen.
Beste Grüße Fabian
On Wed, March 2, 2011 14:05, Fabian Hänsel wrote:
2011-03-02 14:02, streber skrev:
SCP sendet alle Daten verschlüsselt, richtig? Um selbiges mit einem webbasiernden SVN zu erreichen, brauch ich aber wieder SSL (bzw. es empfielt sich) oder?
Nein, du kannst SSH über einen Eintrag in der Datei authorized_keys anweisen, nur (z.B.) svn-Befehle auszuführen.
Dann waeren wir wieder bei Problemen, die CVS schon mit unterschiedlichen Systemnutzern im selben Repository hatte...
Konrad
2011-03-02 15:09, Konrad Rosenbaum skrev:
On Wed, March 2, 2011 14:05, Fabian Hänsel wrote:
2011-03-02 14:02, streber skrev:
SCP sendet alle Daten verschlüsselt, richtig? Um selbiges mit einem webbasiernden SVN zu erreichen, brauch ich aber wieder SSL (bzw. es empfielt sich) oder?
Nein, du kannst SSH über einen Eintrag in der Datei authorized_keys anweisen, nur (z.B.) svn-Befehle auszuführen.
Dann waeren wir wieder bei Problemen, die CVS schon mit unterschiedlichen Systemnutzern im selben Repository hatte...
Ich hatte sowas lange produktiv laufen. Alle Leute selbe Gruppe, umask entsprechend.
Beste Grüße Fabian
On Wed, March 2, 2011 14:02, streber wrote:
Es gibt noch einige mehr, aber mit SVN, Git oder Mercurial machst Du keine Fehler.
SCP sendet alle Daten verschlüsselt, richtig?
Richtig. Es sei denn Du nimmst explizit den NULL-Cypher, aber um das zu machen musst Du Dich richtig anstrengen... ;-)
Um selbiges mit einem webbasiernden SVN zu erreichen, brauch ich aber wieder SSL (bzw. es empfielt sich) oder?
Ja. Installier das Apache Paket fuer SSL, das erzeugt normalerweise auch gleich den noetigen Key. Ein teures Zertifikat brauchst Du fuer Deinen Anwendungsfall nicht.
Das könnte dann wieder zu Problemen führen, da Port 443 bei mir bereits für SCP verwendet wird. (Ein leider notwendiger Umbogen für eine FW hinter der ich ab und zu sitze).
Akzeptiert die FW noch andere Ports? 8080, 74? Nimm einen von denen fuer SSH.
Wenn Du das Repo nicht von hinter dieser speziellen FW erreichen musst dann leg' HTTPS doch auf einen anderen Port.
Ansonsten gibt es Weichen, die Port 443 zwischen HTTPS und SSH teilen koennen. Ich selbst habe aber noch nie sowas aufgesetzt.
Konrad
Konrad Rosenbaum schrieb:
Ja. Installier das Apache Paket fuer SSL, das erzeugt normalerweise auch gleich den noetigen Key. Ein teures Zertifikat brauchst Du fuer Deinen Anwendungsfall nicht.
SVN läuft jetzt. Aber eben noch komplett für jeden einsehbar über den weblink. das SSL probier ich dann mal. ...
Akzeptiert die FW noch andere Ports? 8080, 74? Nimm einen von denen fuer SSH.
Nein. Nur 80 und 443. Und das wird das Problem werden. Und ja, ich muss oft von hinter dieser FW auf den Server: SCP, SSH, http und halt jetzt noch SSL (wenn ich das richtig verstanden haben. Ich bin in diesem Protokolldjschungel nicht so fit)
Ansonsten gibt es Weichen, die Port 443 zwischen HTTPS und SSH teilen koennen. Ich selbst habe aber noch nie sowas aufgesetzt.
Ja, mit diesem Tunnelkrempel hab ich mir mal eine halbe Woche versaut. War froh das ich mein SCP auf 443 umstellen konnte der zufällig noch offen ist. Das will ich nicht nochmal durchmachen. :)
beste Grüße
Hallo Robert,
das Port-Sharing von HTTP und SSH ist kein großer Deal.
Das wichtige, was man verstanden haben muss, ist warum das Port-Sharing funktioniert: das Timing der Nachrichten.
HTTP seine SSL-Variante senden sobald sie sich zu ihrem Port verbunden haben ihre Daten an den Server. SSH (und scp, was darauf aufsetzt) warten zuerst auf einem Begrüßung durch den Server.
Unter Debian hast du zur Unterscheidung das Paket "sslh", dem in der Config-Datei der Port mitgegeben wird, auf dem er hört ( z.b. 443 ) und der Port des lokalen HTTPS-Servers ( den man z.B. auf 8443 umlegt oder nur auf 127.0.0.1 lauschen lässt) und den des anzusprechenden SSH-Servers.
Solange aus dem lokalen Netzwerk der HTTPs-Server gut auf dem gewünschten Port zu erreichen ist, wird es relativ leicht.
Meine Konfiguration sieht so aus, dass mein Router, der die WAN-Verbindung hält per Portforward den externen Port 443 auf den sslh-Server mit Port 8443 umlegt. Wenn sslh dann eine HTTPS-Verbindung vermutet, leitet es die Verbindung an localhost:443 um, im Falle einer SSH-Verbindung zu localhost:22.
Damit kannst du die Konfiguration sowohl im internen wie auch im externen Netz verwenden.
Wenn du noch ein paar konkrete Hilfen brauchst, ich habe inzwischen so ziemlich jeden Fall durch, den eine Firewall oder ein restriktiver Proxy erstellen können.
Gruß Andre
On Wed, Mar 02, 2011 at 03:33:31PM +0100, Robert wrote:
Konrad Rosenbaum schrieb:
Ja. Installier das Apache Paket fuer SSL, das erzeugt normalerweise auch gleich den noetigen Key. Ein teures Zertifikat brauchst Du fuer Deinen Anwendungsfall nicht.
SVN läuft jetzt. Aber eben noch komplett für jeden einsehbar über den weblink. das SSL probier ich dann mal. ...
Akzeptiert die FW noch andere Ports? 8080, 74? Nimm einen von denen fuer SSH.
Nein. Nur 80 und 443. Und das wird das Problem werden. Und ja, ich muss oft von hinter dieser FW auf den Server: SCP, SSH, http und halt jetzt noch SSL (wenn ich das richtig verstanden haben. Ich bin in diesem Protokolldjschungel nicht so fit)
Ansonsten gibt es Weichen, die Port 443 zwischen HTTPS und SSH teilen koennen. Ich selbst habe aber noch nie sowas aufgesetzt.
Ja, mit diesem Tunnelkrempel hab ich mir mal eine halbe Woche versaut. War froh das ich mein SCP auf 443 umstellen konnte der zufällig noch offen ist. Das will ich nicht nochmal durchmachen. :)
beste Grüße
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Moin,
neuer tag, neues Glück.. hoffentlich :D
Konrad Rosenbaum schrieb:
Das es seit 2008 nix neues gibt liegt daran, dass scponly einfach mal stabil ist. Ohne den exakten Output kann ich Dir leider nicht sagen was das Problem ist. Bei mir geht scponly prima (Debian).
Die ld.so Sache und einiges anderes konnte ich in den Griff bekommen. Nun lüft der scponly scheinbar aber der Zugriff via winscp klappt nicht. Schon bei der Installation von scponly wird ja ein Tipp gegeben wie bei einem winscp Fehler zu verfahren ist.:
if you experience a warning with winscp regarding groups, please install the provided hacked out fake groups program into your chroot, like so: cp groups /home/marcoscp/bin/groups
hab ich gemacht (wie hier: http://www.picxl.de/scponly-chroot). Hat auch geplappt. Soweit ich das beurteilen kann.
Beim Verbinden mit winscp kommen jetzt aber viele Fehler und ein Zugriff ist nicht möglich.: -------------------------------------------------------------------- Command 'groups ; echo "WinSCP: this is end-of-file:$status"' failed with invalid output ''.
Command 'pwd ; echo "WinSCP: this is end-of-file:$status"' failed with invalid output ''.
Command 'ls -la -d ".." ; echo "WinSCP: this is end-of-file:$status"' failed with invalid output ''.
Server returned empty listing for directory ''. --------------------------------------------------------------------
Eingige meinten jetzt winscp benötigt eine shell mit ls und echo und andere das chroot ein /dev/null benötigt (The solution appears to be to create a devfs in the scponlyc chroot.)
Meine Frage nun, musstes Du soetwas auch machen beim einrichten? Und wie mache ich das? Ich hab doch keine Ahnung wie man eine shell baut oder ein /dev/null einrichtet.
beste Grüße, Robert
Am Mittwoch, 2. März 2011, 13:01:18 schrieb Konrad Rosenbaum:
Git - dezentrales Tool, was fuer die Entwicklung des Linux-Kerns entwickelt wurde. Ist heute eines der Standard-Tools. Keine Ahnung wie man es aufsetzt - ich benutze bisher (immernoch) SVN. Die Konzepte hinter dezentralen Tools sind etwas schwierig zu verstehen - sie skalieren aber besser auf viele Entwickler.
Ich betreibe einen Git-Server mit Gitolite. Wenn man ein bisschen Ahnung hat, wie SSH funktioniert (was ich bei einem vServer-Betreiber als gegeben voraussetze), ist das absolut simpel aufzusetzen und wunderbar dokumentiert. Einziger möglicher Nachteil: Benötigt eine relativ aktuelle Git-Version (1.7 gabs bei Lenny nur in den Backports).
Gruß Stefan
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Fabian Hänsel -
Konrad Rosenbaum -
Robert -
Stefan Majewsky -
streber