EasyLinux Ubuntu

Hallo Olli,

Am Wed, 01 Feb 2012 18:54:54 +0100

schrieb Oliver Christ :

>

> >>> ssh: connect to host 192.168.178.4 port 22: Connection refused

> >> ist auf dem Zielrechner auch das ssh Paket (client und server)

> >> installiert?

> >>

> > Nein, ist ja auch klar: Mit dem Thema hatte ich noch nie zu tun, und

> > wenn ich es richtig sehe, ist es nicht gerade ein triviales:

> >

> > http://wiki.ubuntuusers.de/ssh

> >

> > Aus Neugierde habe ich jetzt mal 'reingeschnuppert, aber im Grunde

> > möchte ich gern rsync mit Samba zum Laufen bekommen und nicht ein

> > anderes Fass neu aufmachen.

> ich weiss jetzt nicht ob ich deine "Hartnäckigkeit" bewundern soll.

> Wie (wahrscheinlich) die meisten hier sind wir bedingt durch die

> Marktherrschaft mit Windows groß geworden. Auch ich hatte mich schon

> mal tagelang (als Anfänger) mit Samba herum geärgert.

> Bei einer Linux Linux Verbindung ist die erste Wahl ssh bzw nfs.

Obwohl Du der vierte in diesem Thread bist, der offenbar samba ablehnend

gegenüber steht, hat noch niemand "gesagt", warum eigentlich ssh und

nicht samba. Um ein paar Minuten mehr verbratene Zeit geht es mir bei

der Datensicherung nicht (was ja - was ich bisher so lesen konnte - ein

Grund sein soll). Gibt es andere Gründe?

> ssh ist wirklich sowas von einfach

Wirklich? Der oben verlinkte Artikel macht auf mich einen anderen

Eindruck.

> das ich wirklich nur jedem Abrate

> bei einer reinen Linux-Verbindung smb zu benutzen!

Ja, aber warum? Meine Ausgangslage ist ja, dass sich Linux- und

Windows-Rechner in einem gemeinsamen Netzwerk befinden. Ich habe im

Internet öfter gelesen, dass von ssh für den Datenaustausch mit

Windows-Kisten abgeraten wird.

> Für deinen (g)rsync würde ich an deiner Stelle doch mal den Rat von

> den anderen Helfern versuchen.

Dagegen sperre ich mich überhaupt nicht. Eines der beiden Probleme habe

ich aber genannt. Das andere ist, dass ich mit Kräften auch ein wenig

haushalten will: Ich kann überhaupt nicht einschätzen, was es für mich

bedeutet, zwei Netzwerke zu konfigurieren und zu pflegen. Samba war

ziemlich frickelig, und Matthias hat mich vor einiger Zeit tatkräftig

dabei unterstützt, aus einigen Fallen wieder herauszukommen. Wenn das

Ganze mit ssh wieder von vorne los ginge, wäre ich nicht begeistert.

> Mit ssh klappt es bestimmt.

Daran zweifel ich nicht.

> Schließlich willst du doch deine Daten sichern, oder?

>

Klar...

> Wenn ich nach einer gewissen Zeit zu keiner Lösung komme dann versuche

> ich einen anderen "Weg".

> Und wenn das auch nicht funktioniert dann versuche ich es mit einem

> anderen Programm.

>

Ich auch. In diesem Fall hier hat aber bisher niemand auch nur ein Wort

über die Zusammenarbeit von rsync und samba verloren. Ist die Abneigung

gegenüber samba so groß und/oder de Ablehnung so deutlich (oder der

Versuch gar zwecklos, rsync mit samba zum Laufen zubringen)? Ich

verstehe es nicht ....

Viele Grüße

Rainer

_______________________________________________

Ubuntu mailing list

Ubuntu[bei]easylinux[punkt]de

http://www.easylinux.de/Kontakt/Mailinglisten/listinfo/ubuntu

Am 01. Feb 2012 um 23:41 CET schrieb Matthias Müller:

> Hier mal ein Auszug aus der Manualseite von rsync

> There are two different ways for rsync to contact a remote system: using

> a remote-shell program as the transport (such as ssh or rsh) or

> contacting an rsync daemon directly via TCP.

>

> Ich verstehe das so: Wenn du rsync verwenden willst, um Daten von einem

> Rechner auf einen anderen zu übertragen, musst du ssh oder einen rsync

> daemon konfigurieren.

>

> Es sei denn, du gaukelst dem Rechner vor, dass er lokal arbeiten soll.

> In dem Fall montierst du das Verzeichnis, das auf dem entfernten Rechner

> liegt, zB via Samba (smb-Protokoll), an den Rechner auf dem der rsync

> arbeitet.

> Da das aber bei dir ja so ist, wenn ich dich richtig verstanden habe,

> könntest du so tun, als ob das ganze lokal abläuft. Das Betriebssystem

> ist so gestrickt, dass es Dateisysteme, die montiert sind, genauso

> behandelt, wie die lokal vorhandenen.

> Sprich: es ist Linux vollkommen wurscht, ob ein Dateisystem 30cm neben

> der Tastatur im Rechner eingebaut ist, oder, über welche Methode auch

> immer, montiert (gemountet) ist und in Wirklichkeit in einem Server im

> Regenwald von Brasilien eingebaut ist.

>

> Apropos Samba und Linux: Eigentlich bin ich da völlig leidenschaftslos.

> Wenn das Mittel der Wahl für das smb-Protokoll ist (auch weil Windows-

> Rechner dabei sind), habe ich da keine Probleme damit.

> Ich persönlich bevorzuge und verwende für den Datenaustausch von Linux-

> zu Linuxrechner NFS. Das muss aber nicht heißen, dass es mit Samba nicht

> auch funktioniert.

> Wie gesagt, dass ist persönliche Präferenz und Systemumfeld abhängig.

Ich kann mir nicht vorstellen, daß rsync mit einem eingehängten smb

Verzeichnis vernüftig funktioniert, da sich die Linux Dateirechte auf

einem Windows Filesystem gar nicht speichern lassen und rsync deshalb

z.B. veränderte Dateien nach einem erneuten mounten überhaupt nicht

erkennen kann.

Gruß

Stefan

--

Stefan Lütje Skelli[bei]jabber.ccc[punkt]de

Key fingerprint = BCB2 48E4 9211 C975 5A3F B192 9B6E CCCF 99CC 44FA

"Ich fühle mich geehrt, heute die Hand eines anständigen Irakers schütteln zu

dürfen, dem von Saddam Hussein die Hand abgehackt wurde." George W. Bush

Hallo Matthias,

Am Wed, 1 Feb 2012 23:41:25 +0100
schrieb Matthias Müller :

> > > >
> > > > Wofür steht ".xxxxxxxx.yy"? Da die ganze Liste so aussieht,
> > > > vermute ich, dass Du x und y als Platzhalter benutzt hast, aber
> > > > wofür?
> > >
> > > Stimmt, sind Platzhalter. Sie stehen für mein ganz konkretes
> > > Heimnetz.
> >
> > Gut, aber wofür stehen die Buchstaben? Für eine IP-Adresse?
> ok, breitgeschlagen. Im konkreten Beispiel von oben steht:
> 192.168.2.2 alien.querstr31hbg.local alien

>
OK, im Prinzip hatte sich die Frage eigentlich auch schon erledigt,
weil Du darauf hingewiesen hast, dass die Angaben nur der
Vollständigkeit halber dort stehen.

> snip
> > ssh war bisher noch gar nicht im Spiel, sondern samba, und die
> > Fehlermeldungen beziehen sich alle darauf (und nicht auf ssh).

> Aus deinem Ursprungsposting:

> > ssh: Could not resolve hostname smb: Name or service not known
> ^^^ Hier mault _ssh_, dass etwas nicht stimmt. Nämlich, dass der
> Hostnamen "smb" nicht aufgelöst werden kann. Das Thema ist erledigt.
>
Oh Mann, da habe ich vor lauter Wald die Bäume nicht mehr gesehen ;-)
(das "ssh" in dieser Meldung überhaupt nicht wahrgenommen). Allerdings
ist die Meldung durch den smb vorangestellten Slash auch nicht mehr
aufgetaucht.
>
> >
> > > Du solltest auf beiden
> > > Seiten den ssh-Server freigeben, wie das bei Ubuntu (sind doch
> > > Ubuntus, oder?) zu geschehen hat weiß ich momentan nicht.
> >
> > Ja, es sind Ubuntus. Aber wie ich eben als Antwort auf ein Posting
> > an Joachim geschrieben habe: Das Ganze müsste doch auch mit samba
> > laufen. Ist bei Euch offenbar eher eine ungeliebte Option, aber
> > eine, die ich bevorzugen würde. Die Frage ist eben nur: Wo liegt die
> > Ursache für das Problem?

> Deswegen (siehe oben) der Ratschlag, dass der ssh-Server frei zu
> geben wäre. Und siehe weiter unten.
>
Habe ich gestern Abend noch gemacht, aber wie erwartet: Probleme. Mehr
dazu unten (nach den Antworten auf einzelne Passagen von Dir).
> >
> > > Rechteprobleme und AppArmor könnten noch dazu kommen
> >
Vermutlich ist hier "der Hund begraben".

> Hier mal ein Auszug aus der Manualseite von rsync
> There are two different ways for rsync to contact a remote system:
> using a remote-shell program as the transport (such as ssh or rsh)
> or contacting an rsync daemon directly via TCP.
>
> Ich verstehe das so: Wenn du rsync verwenden willst, um Daten von
> einem Rechner auf einen anderen zu übertragen, musst du ssh oder
> einen rsync daemon konfigurieren.
>
> Es sei denn, du gaukelst dem Rechner vor, dass er lokal arbeiten
> soll. In dem Fall montierst du das Verzeichnis, das auf dem
> entfernten Rechner liegt, zB via Samba (smb-Protokoll), an den
> Rechner auf dem der rsync arbeitet.

Wenn ich Dich nun richtig verstehe, muss in diesem Fall das
Zielverzeichnis auf dem Rechner eingehängt sein, auf dem rsync
arbeitet. Habe ich auch versucht, sogar vor dem Start von rsync erstmal
über die grafische Oberfläche auf das Zielverzeichnis zugegriffen.
Funktioniert tadellos, rsync aber nicht.

> Da das aber bei dir ja so ist, wenn ich dich richtig verstanden habe,
> könntest du so tun, als ob das ganze lokal abläuft. Das
> Betriebssystem ist so gestrickt, dass es Dateisysteme, die montiert
> sind, genauso behandelt, wie die lokal vorhandenen.

Davon war ich ja auch ausgegangen und wundere mich: Ich hatte erwartet,
dass sich spätestens nach dem Mounten das Zielverzeichnis im
Browserfenster von rsync zeigt. Tut es aber nicht. Insofern hat es mich
nicht wirklich überrascht, dass der Zugriff auch mit der manuellen
Pfadangabe nicht klappt (weder im Browserfenster, noch als Kommando im
Terminal).
>
> Apropos Samba und Linux: Eigentlich bin ich da völlig
> leidenschaftslos. Wenn das Mittel der Wahl für das smb-Protokoll ist
> (auch weil Windows- Rechner dabei sind), habe ich da keine Probleme
> damit. Ich persönlich bevorzuge und verwende für den Datenaustausch
> von Linux- zu Linuxrechner NFS. Das muss aber nicht heißen, dass es
> mit Samba nicht auch funktioniert.

OK, das ist erstmal eine beruhigende Ansage ;-)

So, gestern habe ich mir nach Joachims Posting nun gezielt ssh
vorgenommen (alles andere ist erstmal zurückgestellt). Der Client
(openssh-client) ist ohnehin standardmäßig installiert, den Server
(Paket openssh-server) habe ich erstmal auf diesen beiden Rechnern
installiert, die ich momentan in der Mache habe, sowie beide /etc/hosts
kontrolliert: Beide Rechner sind mit ihren korrekten IP-Adressen und
Namen drin.

Sowohl Versuche mit den grafischen Frontends von rsync (Grsync) und
unison waren erfolglos, als auch rsync auf der Kommandozeile (mit dem
Befehl, der bei Joachim funktioniert). Mit Unison habe ich mich erstmal
auf einen reinen Zugriff beschränkt - also nach Eingabe der
entsprechenden Daten und Auswahl von ssh mit dem generierierten
"ssh://@. Nach Passwortabfrage
und -eingabe kam die Meldung:

"Fatal error - Lost connection with the server"

Egal, mit welcher Variante ich es versuche, also
*ob mit IP-Adresse, statt
*ob mit vorangestelltem /home/ vor dem Zielverzeichnis
*ob mit vorangestelltem /home oder
*ob mit oder ohne gemountetem Zielverzeichnis

nach dem PC-Zutritt ist Feierabend. Momentan gehe ich davon aus, dass
der Zutritt erstmal klappt, denn nach dem Start öffnet sich ein
Abfragefenster für das Passwort, in dem der korrekte PC-Name oder (je
nachdem, was als Ziel verwendet wird) die IP-Adresse zu lesen ist.
Warum danach aber die Verbindung verlorengeht, erschließt sich mir
nicht.

Dann wollte ich die Sache noch mehr eingrenzen und habe es mal mit dem
Befehl versucht, den Thomas vorgeschlagen hat:

ssh -XC @192.168.178.4

Zutritt klappt. Dann "cd /home": klappt. Dann
"cd /home//Dokumente: klappt. Dann gedit "test" (vorher
angelegtes Text-Testdokument). Es öffnet sich zwar, und ich kann es
sogar bearbeiten, aber in der Konsole erscheint nacheinander zig-mal
dieselbe Fehlermeldung:

"GConf-Fehler: Der Konfigurationsserver konnte nicht kontaktiert
werden; mögliche Fehlerquellen sind, dass TCP/IP für ORBit nicht
aktiviert ist oder auf Grund eines Systemabsturzes alte NFS-Sperren
gesetzt sind. Unter http://projects.gnome.org/gconf/ erhalten Sie
weitere Informationen (Details – 1: Verbindung zur Sitzung konnte
nicht abgerufen werden: Failed to connect to
socket /tmp/dbus-eKQ9uiHpJz: Verbindungsaufbau abgelehnt)"

Fazit: Mit Thomas' Kommando funktionieren Zugriff und Bearbeiten wohl,
allerdings nicht sauber. Zugriffe mit rsync und unison aber werden
verweigert, wobei Unison immerhin den ersten Schritt noch mitmacht
(entweder beim richtigen Rechner "anklopfen" und "Ausweiskontrolle" über
sich ergehen lassen - und/oder sogar Zutritt).

Irgendwas ist faul, aber was?

Viele Grüße

Rainer

_______________________________________________
Ubuntu mailing list
Ubuntu[bei]easylinux[punkt]de
http://www.easylinux.de/Kontakt/Mailinglisten/listinfo/ubuntu