sitecopy & strato

[foomaker]

Tach zusammen.

Wer unter Linux (Deb 4.0 r1 etch) 'sitecopy' kennt, wird auch den 'fetch-' Modus kennen.

Der update-Modus 'sitecopy -u mysite' funktioniert tadellos.

Ein 'sitecopy -f mysite' (notwendig, weil ich zuhause Daten uploade, die ich auf der Arbeit brauche und umgekehrt) bringt bei strato den Fehler "550 No such file or directory".

Ein 'sitecopy -f mysite --debug=ftp' bringt dies (aufs Nötigste gekürzt):

sitecopy: Fetching site `mysite' (on www.mydomain.de in /)
...
< 230 User logged in, proceed.

PASV

< 227 Entering Passive Mode (81,169,145,91,238,129)
ftp: Parsed PASV response, using port 61057

LIST -la /

< 150 Opening ASCII mode data connection.
ls: init, topdir: []
ls: [-rw-r-----   1 ftp      ftp           447 Apr 28 11:57 .htaccess]
ls: file (640, 447): [.htaccess]
ls: [drwxr-xr-x   3 ftp      ftp          4096 May  5 08:23 data]
ls: directory (755): data
ls: [-rw-r--r--   1 ftp      ftp           169 Apr 16 09:20 index.html]
ls: file (644, 169): [index.html]
ftp: EOF from DTP connection.
ftp: Fetch finished with 0.
Closing DTP connection...
< 226 Transfer complete. Closing data connection.
File: /index.html
Getting modtime.

MDTM /index.html

< 213 20080416072017
Parsing modtime: 213 20080416072017
Converted to: Wed Apr 16 07:20:17 2008
Got modtime.
Walk finished ok.

PASV

< 227 Entering Passive Mode (81,169,145,91,238,146)
ftp: Parsed PASV response, using port 61074

LIST -la /data/

< 150 Opening ASCII mode data connection.
ls: init, topdir: [/data]
ls: [-rw-r-----   1 ftp      ftp           447 Apr 28 11:57 .htaccess]
ls: file (640, 447): [.htaccess]
ls: [drwxr-xr-x   3 ftp      ftp          4096 May  5 08:23 data]
ls: directory (755): data
ls: [-rw-r--r--   1 ftp      ftp           169 Apr 16 09:20 index.html]
ls: file (644, 169): [index.html]
ftp: EOF from DTP connection.
ftp: Fetch finished with 0.
Closing DTP connection...
< 226 Transfer complete. Closing data connection.
File: /data/info.txt
Getting modtime.

MDTM /data/info.txt

< 550 No such file or directory.
Didn't get modtime.

QUIT

< 221 Goodbye.
sitecopy: Failed to fetch file listing for site `mysite':
sitecopy: 550 No such file or directory.

Wie man unschwer erkennen kann, geht im Basis-Verzeichnis noch alles gut. Wenn aber sitecopy ins subdir 'data' "schaut", liefert der strato-Server wiederum den Inhalt des Basis-Verzeichnisses, was dann zum Fehler samt Abbruch führt.

Habe dieses Problem hier und da beim Googlen wiedergefunden. Die bislang einzige Lösung, die ich finden konnte, ist das neukompilieren von sitecopy mit einem Patch.

Gibt es nicht noch eine andere Lösung? Habt Ihr Erfahrungen diesbezüglich mit strato? Die habe ich noch nicht angeschrieben.

Ja, ich weiss. Bei 1&1 geht's. Ich bleibe aber trotzdem bei Strato. Und auch, wenn es Euch jetzt in den Fingern juckt. Ich möchte hier KEINEN Thread über das Pro und Contra von Strato, 1&1 und Co. initiieren.

Also, wer kennt sitecopy und hat diesbezgl. Erfahrung mit strato?

Vielleicht ein anderes - ähnlich praktisches - Tool? Ich möchte mit einer einzigen einfachen Kommandozeile web-(ftp-)content mit lokalem content synchronisieren können. Und "praktische Alleskönner-FTP-Clients" habe ich auch genug.

Gruß vom foomaker

[crazyscripter]

Hallo.

Wer unter Linux (Deb 4.0 r1 etch) 'sitecopy' kennt, wird auch den 'fetch-' Modus kennen.

Der update-Modus 'sitecopy -u mysite' funktioniert tadellos.

ich nutze filezilla

war damit immer zufrieden

kuck mal [Link:http://samba.anu.edu.au/rsync/@title=rsync]

das müsste was für dich sein

M.

[foomaker]

ich nutze filezilla

war damit immer zufrieden

kuck mal [Link:http://samba.anu.edu.au/rsync/@title=rsync]

das müsste was für dich sein

rsync kann ich vergessen - habe keinen Zugriff auf Server, kann also den deamon nicht installieren.

FileZilla ist eine grafische Lösung.

Was ich an sitecopy schätze ist, dass ich in einem setup file zu jedem Projekt vorgeben kann, was upgedatet werden soll und was nicht und und und.

Mit einem einfachen "sitecopy -u projektX" in der Konsole werden dann alle lokal veränderten Dateien auf der remotesite aktualisiert.
Und genauso schnell habe den lokalen Bestand and den remote Bestand angeglichen.

Nur speziell bei strato gibt es die beschriebenen Probleme.

Weiss keiner Rat?

Gruß vom foomaker

[frankx]

Hellihello

unter Windows mache ich das mit ftp -f myfile (bzw. sftp, wenn denn secureftp installiert ist). Das geht doch mit Linux mit selbigem Befehl auch, oder?

Du kannst auch mal über die Konsole probieren: "ftp> open" etc. pp.

Ich habe im Schulnetzwerk allerdings schon festgestellt, dass das von manchen Rechnern aus nicht ging, obwohl mit Filezilla eine Verbindung via ftp möglich war.

Frag ich mich, ob ftp nicht gleich ftp ist?

Interessant dürfte vielleicht auch sein, was in myfile für ftp-Befehle stehen, und ob dein Router da vielleicht noch was zu beiträgt (s. Probleme im Schulnetzwerk).

Dank und Gruß,

frankx

[foomaker]

Hallo.

Ob ftp oder nicht ftp steht ja nicht im Vordergrund meiner Frage.

Ich kann ja per ssh shell und ftp auf den Server zugreifen. keine Probleme. Weder mit Router noch mit sonstwas.

Auch mit ftp Clients wie FileZilla und Gnome Commander (wie der gute alte mc) klappt's wunderprächtig.

sitecopy "fetcht" auch super bei meinem anderen Provider.
Nur bei strato versagt die fetch-Funktion und damit auch das synchronisieren.

Randbemerkung für alle, denen "rsync" und "sitecopy" nichts sagen: Es geht nicht darum Fullbackups zu fahren oder ganze webinhalte downzuloaden. Beide Tools dienen der Pflege von webcontent. Und dabei will ich auch nicht Buch führen, welche Skripte ich im Laufe des Tages geändert habe um diese dann gezielt up- bzw. downzuloaden.

Wesentlicher Unterschied zw. den Tools:
rsync: uploadet nur die veränderten Teile der geänderten Scripts, also eben nicht die kompletten Scripts. download dito. Benötigt aber einen serverseitig installierten daemon.
sitecopy: einfacher zu handlen als rsync, kein server daemon nötig. Bewegt aber immer ganze Files, nicht nur Teile davon.
In der Praxis:
Ankunft Büro:
=> sitecopy -f projekt (holt aktuelle File Listen vom Server)
=> sitecopy -s projekt (update der lokalen Files mit veränderten Files vom Server)
=> entwickelfummeltestprogrammierärgerändertestspeicher Skripte lokal
=> sitecopy -u projekt (upload der veränderten Skripte)
Ankunft Zuhause:
dasselbe wie im Büro

Dadurch verfüge ich zuhause auch ohne remote-Zugriff auf meinen Arbeitsplatzrechner immer über die aktuellen Projektdateien

Also keiner ne Idee, wie ich sitecopy oder strato dazu kriegen kann, die fetch-Funktion korrekt auszuführen?

fragt foomaker

[frankx]

Hellihello

Ob ftp oder nicht ftp steht ja nicht im Vordergrund meiner Frage.

Nun, ich hätte gedacht, dass sitecopy sich per FTP mit dem Server verbindet. In dem Fall wäre das halt ein Ansatzpunkt. Wie, wenn nicht via FTP, soll sich denn Sitecopy sonst mit dem Server verbinden?

Dank und Gruß,

frankx

[foomaker]

Nun, ich hätte gedacht, dass sitecopy sich per FTP mit dem Server verbindet. In dem Fall wäre das halt ein Ansatzpunkt. Wie, wenn nicht via FTP, soll sich denn Sitecopy sonst mit dem Server verbinden?

Hallo.

Mir missverstehen uns gründlich. ;-)

Natürlich ist es eine ftp-Verbindung. Das sagte ich doch.
Und mittlerweile mehren sich die Stimmen, die sagen, dass der beschriebene Fehler vom Strato-ftp-Server erzeugt wird. Der gibt bei der ftp-Anforderung "ls ./dir/*" (oder so ähnlich) nicht den Inhalt von dir/ wieder, sondern idiotischerweise von ./
Und damit kann sitecopy dann nichts anfangen, weil "seines Wissens" im Wurzelvezeichnis die vom ftp-Server genannten Dateien nicht vorkommen können.

Der Server meines anderen Poviders handlet das korrekt.

Das Problem ist also bekannt. Eine Lösung dafür eher nicht.

Gruß vom foomaker

Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT.

[frankx]

Hellihello

Nun, ich hätte gedacht, dass sitecopy sich per FTP mit dem Server verbindet. In dem Fall wäre das halt ein Ansatzpunkt. Wie, wenn nicht via FTP, soll sich denn Sitecopy sonst mit dem Server verbinden?

Mir missverstehen uns gründlich. ;-)

Den Eindruck kann ich nicht teilen, auch nach der Lektüre dessen, meine ich, Dich zu verstehen. Scheints konnte ich mich nicht verständlich machen oder was ich denke ist Unsinn, weil Sitecopy zB. nicht konfigurierbar ist.

Natürlich ist es eine ftp-Verbindung. Das sagte ich doch.
Und mittlerweile mehren sich die Stimmen, die sagen, dass der beschriebene Fehler vom Strato-ftp-Server erzeugt wird. Der gibt bei der ftp-Anforderung "ls ./dir/*" (oder so ähnlich) nicht den Inhalt von dir/ wieder, sondern idiotischerweise von ./

Das liegt aber auch daran, dass Scitecopy den Befehl so absetzt, oder? FileZilla nutzt scheints für die Anforderung der Verzeichnisauflistung eine andere Pfadangabe (sytaktisch, nicht inhallich).

Und damit kann sitecopy dann nichts anfangen, weil "seines Wissens" im Wurzelvezeichnis die vom ftp-Server genannten Dateien nicht vorkommen können.

Ja, und weil Scitecopy nicht den FileZilla-"Dialekt" spricht, den der "Strato"-FTP Server ja versteht. Vermutlich kommt doch auch bei Strato ein lizenfreier OpenSource FTP-Server zum Einsatz, und keine eigene Programmierung, oder?

Der Server meines anderen Poviders handlet das korrekt.

Das Problem ist also bekannt. Eine Lösung dafür eher nicht.

Jau, wenn sich Scitecopy nicht entsprechend konfigurieren lässt. Ich habe übrigens aber auch schon festgestellt - wie geagt - dass eine Verzeichnisauflistung via Konsole unter Windows-ftp> nicht ging ("Permission denied"), aber mit FileZilla dann schon.

Dank und Gruß,

frankx