Re: [PUG] Re: ftp-Server
Wenn man kein gemeinsames Komprimierungstool findet, dann kann man ganz einfache Teile auch selber schreiben. Selbst in COBOL. Das Projekt läuft schon besch... Tatsächlich ist es so, dass auf diesem Wege bereits Migrationen in anderen Firmen gelaufen sind - sicherlich aber nicht mit dieser Masse an Daten. Da hat sich dann keiner Gedanken darüber gemacht, ob mit dem jetzigen Mengengerüst Probleme hochkommen würden. Natürlich soll alles hoppla-hopp gehen. Und in der ersten Phase habe ich ja schon mal durch Austausch des ftp-Servers das Limit von 2 auf ca 20 GB verschieben können. Der Server ist der einzige Linux-Rechner in diesem Unternehmen - notgedrungen *g*, weil das Altsystem außer auf Großrechnern nur unter Unix/Linux läuft. Da kann man sich vorstellen, welche Gesichtsausdrücke man sieht, wenn mal was nicht optimal funktioniert (...O-Ton: läuft die Linux-Büchse endlich wieder?). Bisher waren es allerdings immer Fehler bei den Leuten, die migrieren (falsche Platte mit Daten zugebügelt und gejammert, dass der Rechner hängt u. dgl.) ... Mittlerweile habe ich trotzdem aber auch schon für einen SAP-DB-Server (versuchsweise) die Zustimmung, dass ich so was unter Linux einrichten darf (= Performance und Wartungsintensität mit NT, bzw. W2000 vergleichen ;-)) Kurz und gut(?) ... ich suche noch mal bei den ftp-Servern weiter (proftpd hat es nicht gebracht), werde aber am WE auch andere Alternativen prüfen. Danke für die Informationen Gruß Stephan PUG - Penguin User Group Wiesbaden - http://www.pug.org
[PUG] Re: ftp-Server
[EMAIL PROTECTED] (Stephan Munsch) writes: Wenn man kein gemeinsames Komprimierungstool findet, dann kann man ganz einfache Teile auch selber schreiben. Selbst in COBOL. Das Projekt l+AOQ-uft schon besch... Das war mir nach Deiner Beschreibung sofort klar :-o Viel Erfolg und sorg daf+APw-r, dass Du Deinen Spa+AN8- dabei hast - egal was andere meinen. Jochen -- #include ~/.signature: permission denied PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] Re: ftp-Server
Am Samstag, 1. März 2003 09:56 schrieb Stephan Munsch: ... Kurz und gut(?) ... ich suche noch mal bei den ftp-Servern weiter (proftpd hat es nicht gebracht), werde aber am WE auch andere Alternativen prüfen. Hallo Stephan, Ist FTP überhaupt die richtige Wahl der Mittlel. Sind es wirklich eine Menge User, die da Ihre Daten hochschieben wollen? Oder ist das Problem vielleicht geeigneter per nfs, scp, rsync, ... zu lösen? Ich frage halt mal, weil ich FTP nur noch nutze wenn es sich um eine sporatische Datenübertragung nuze, jedoch nicht, mit Systemen auf die ich einen gewissen Einfluß habe. Gruß Ernst PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] Re: ftp-Server
hi, ich hätte da mal ne ganz blöde Frage, ich habe nicht wirklich Schimmer von diesen Konstruktionen, aber in meiner Naivität frage ich einfach mal, wrum das ganze nicht über AFS/NFS gemacht wird. Man mounted es einfach an irgendeinem Platz auf dem Zielsystem, und kopiert dann die Daten an ihren eigentlichen Bestimmungsort (also auf der lokalen Festplatte) Sorry, war nur so eine Idee cu On Sat, 2003-03-01 at 10:59, Ernst May-Jung wrote: Ist FTP überhaupt die richtige Wahl der Mittlel. Sind es wirklich eine Menge User, die da Ihre Daten hochschieben wollen? Denny Schierz [EMAIL PROTECTED] --- The squeaky wheel doesn't always get the grease. Sometimes it gets replaced. signature.asc Description: This is a digitally signed message part
Re: [PUG] Re: ftp-Server
Stephan Munsch sagte: Das ist etwas pervers, oder? $Kunde hat schon bei der Verarbeitung von Dateien 10GB Probleme; aus den verschiedensten Gründen. Ja ist es! Insbesondere auch deshalb, weil beim Komprimieren kleinerer schon übertragener gleichartiger Dateien zur Sicherung regelmäßig der Faktor 10 erreicht werden konnte. Ich übertrage also mehr als 90% 'Luft'. Wenn man kein gemeinsames Komprimierungstool findet, dann kann man ganz einfache Teile auch selber schreiben. Selbst in COBOL. Ich kenne keinen Server, der das garantiert kann. Meine Frage ist, wie lange eigentlich so ein File-Transfer dauert. Könntest Du mit ssh oder Dingen wie netcat eine Umgehung finden? Habe mich schon intensiv mit den Kollegen unterhalten. Ein Split der Dateien auf der BS2000-Anlage ist wohl nicht möglich (oder zu kompliziert). Auf den Mainframes gibt es immer einen SORT, der könnte so etwas können. Auch ohne zu sortieren. Und GNU split gibt es dafür auch. Aber am Ende ist das Anwendungsdesign so krank, dass Du die Probleme nur mit Technik alleine nicht wirst lösen können. Um eine Konvertierung der Zeichen zu erreichen, muss die BS2000-Anlage die Daten an den Linux-ftp-Server schicken - ein 'Holen' der Daten von Linux aus geht daher nicht. Das sind böse Gerüchte. Auch ein recode oder iconv kann Dateien konvertieren; dafür braucht's kein ftp. Es gibt wohl auch keine einfache Möglichkeit, die Daten im BS2000 zu komprimieren, dann zu transportieren und auf der Linux-Maschine zu entpacken. Habe mich schon gefragt, ob manch ein BS2000-Betreuer sich hinter der Eine Google-Suche liefert praktisch sofort: http://192.109.2.220/vil/oec/vil1/openft/opnft_de/win_de/win_dbl.doc Komplizert- heit verschanzt nach dem Motto: beweis uns erst mal das Gegenteil... :-( Ein solcher Transfer dürfte ca. 14-15 Stunden dauern (aus der Zeit für 18 GB hochgerechnet). Gut - ist innerhalb des Firmennetzes. Dort kann man einigermaßen zuverlässig garantieren, dass die Verbindung nicht zwischendrin mal ausfällt. Ich halte diese Methode auch nicht für besonders gut... In meiner alten Firma würde ich dieses Projekt dem Chef vor die Füsse werfen. Alle wollen, dass es funktioniert; tun aber alles dafür, dass es niemals sauber laufen wird. Jochen -- This space is intentionally left blank. PUG - Penguin User Group Wiesbaden - http://www.pug.org
[PUG] Re: ftp-Server
[EMAIL PROTECTED] (Stephan Munsch) writes: Das Problem ist, es sollen Dateien von 32 GB und darber transportiert werden (am Stck!!!). Das ist etwas pervers, oder? $Kunde hat schon bei der Verarbeitung von Dateien 10GB Probleme; aus den verschiedensten Grnden. Leider kann die BS2000-Anlage, von der die Daten kommen, Dateien nicht gescheit splitten - was auch wegen der Zeichensatz-Umsetzung evtl. noch andere Probleme aufwerfen wrde. Ich transportiere *immer* binr und konvertiere, wenn es denn sein muss, ganz am Ende oder am Anfang. Mit der Strategie knnte man die Dateien erst splitten, dann bertragen und zusammensetzen und erst dann konvertieren. Ich kenne keinen Server, der das garantiert kann. Meine Frage ist, wie lange eigentlich so ein File-Transfer dauert. Knntest Du mit ssh oder Dingen wie netcat eine Umgehung finden? Jochen -- #include ~/.signature: permission denied PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] Re: ftp-Server
Das ist etwas pervers, oder? $Kunde hat schon bei der Verarbeitung von Dateien 10GB Probleme; aus den verschiedensten Gründen. Ja ist es! Insbesondere auch deshalb, weil beim Komprimieren kleinerer schon übertragener gleichartiger Dateien zur Sicherung regelmäßig der Faktor 10 erreicht werden konnte. Ich übertrage also mehr als 90% 'Luft'. Ich kenne keinen Server, der das garantiert kann. Meine Frage ist, wie lange eigentlich so ein File-Transfer dauert. Könntest Du mit ssh oder Dingen wie netcat eine Umgehung finden? Jochen Habe mich schon intensiv mit den Kollegen unterhalten. Ein Split der Dateien auf der BS2000-Anlage ist wohl nicht möglich (oder zu kompliziert). Um eine Konvertierung der Zeichen zu erreichen, muss die BS2000-Anlage die Daten an den Linux-ftp-Server schicken - ein 'Holen' der Daten von Linux aus geht daher nicht. Es gibt wohl auch keine einfache Möglichkeit, die Daten im BS2000 zu komprimieren, dann zu transportieren und auf der Linux-Maschine zu entpacken. Habe mich schon gefragt, ob manch ein BS2000-Betreuer sich hinter der Komplizert- heit verschanzt nach dem Motto: beweis uns erst mal das Gegenteil... :-( Ein solcher Transfer dürfte ca. 14-15 Stunden dauern (aus der Zeit für 18 GB hochgerechnet). Gut - ist innerhalb des Firmennetzes. Dort kann man einigermaßen zuverlässig garantieren, dass die Verbindung nicht zwischendrin mal ausfällt. Ich halte diese Methode auch nicht für besonders gut... Gruß Stephan PUG - Penguin User Group Wiesbaden - http://www.pug.org
