Beiträge von Tar Zahn

immerhin, besser als für mysql

Hallo,

ich habe gerade auf einem "Server" einen Crash gehabt. Die Platten waren zwar im RAID, aber es war ein logischer Fehler in einer BTRFS Partition.
Hab noch mit check geprüft, das hat auch ein paar Dinge gemacht/repariert, ist aber irgendwann mit einem Segmentation Fault ausgestiegen.

Nun Frage ich mich, wie man am besten einen neuen Server aufsetzt. Wieder EXT4, wieder BTRFS nur besser?

Es geht mir dabei nicht unbedingt um einen spezifischen Anwendungsfall, sondern allgemein.
Der Server oben hatte ein VMware workstation laufen, es könnte aber auch um andere Dinge gehen, Backup, Samba, Datenbank, Webserver ..

Danke für ein paar Tipps oder Meinungen!

Zitat von D_Dau

Das Problem kenne ich nicht.Ich kaufe meine Rechner beim Fachhändler "um die Ecke".....
Ich gebe an was ich bereit bin zu Zahlen und das Linux auf dem Rechner laufen muss.
Und siehe da....es läuft und ist i.d.R sogar billiger als MediaMarkt & Konsorten.

Warum muss man auf solch einen positiven Beitrag so antworten?

Zitat von Berichtigung

Mit SLES hast du zwar Support bei SUSE GmbH selbst

Was meldet denn dein pscp?
Am besten setzt in Putty das Debug Level höher für ssh*
(Wie das geht, weiß ich nicht, ich bin schon ewig radikal winfreie Zone)

Die SLES Version ist nur mit Installationssupport gekauft. Kann man wahrscheinlich nachkaufen.

Falls von Interesse:
PSC hat einen verbose Schalter -v, damit wird die Ausgabe geschwätziger.
Ich habe zwar über eine benannte Putty Sitzung eine Verbindung via PSCP hinbekommen, die Logging Einstellungen von "Mutterprogramm" Putty werden dabei aber scheinbar nicht berücksichtigt.

Der Fehler unter Putty ist offenbar einer kaputten DOS Box zu verdanken. (Was auch immer hier geschehen ist, ich kann mich an keine Aktionen entsinnen, mit denen ich die Box dazu gebracht haben könnte, keine Verbindung aufzubauen)
Eine benannte Verbindung via PSCP in einer 2. DOS Box hat zu meiner Überraschung funktioniert.
Ein Vergleich eines Putty Registry Exports der verwendeten Connections hat (bis auf die Logging Settings) keinen Unterschied ergeben.
Eine weitere DOS Box hat dann auch klaglos funktioniert.

SFTP ist offenbar ein anderes Thema, da Filezilla und pscp gleichzeitig gezickt haben, war ich der Annahme, es gäbe ein SSH Problem. Da Putty selbst gegen den Server klaglos lief, war die Annahme aber schon wackelig.
Wie ich mittlerweile weiß, arbeitet Filezilla mit Pageant zusammen, wenn es das findet. Pageant habe ich neulich in anderem Zusammenhang neu installiert, vielleicht liegt da der Hund begraben.

Zitat von Sauerland

Benutze dies:
Was ist WinSCP :: WinSCP

Da PSCP "wieder läuft" und ich lieber command line Werkzeuge einsetze, habe ich das noch nicht probiert/installiert, dennoch danke für den Hinweis, ich hatte die Existenz von WinSCP mittlerweile vergessen.

Die SFTP Sache muss ich noch klären, aber ich komme erstmal klar. Damit ist das Thema erledigt, danke.

Hallo,

entgegen der URL dieses Forums betrifft die Frage den Zugriff auf ein SLES System (SLES 11). Kann ich solche Fragen hier stellen oder soll ich woanders schauen?
Es geht darum, dass ich mich auf dem System zwar per Putty (ssh) anmelden kann (root oder ander User), ein pscp aus Windows oder Filezilla Dateiübertragung aber nicht wie gewohnt funktioniert.

Falls es ok ist, liefere ich weitere Infos.

Gruß, Tar Zahn

Ok, es hat primär nichts mit der Geräuschkulisse am Rechner zu tun.

Wenn schon der Laptop erwähnt wurde und RAM und Festplatte. Dann noch ein paar Hinweise, die vielleicht hilfreich sind.
Der Laptop ist nicht immer am Strom, Akkus halten nicht ewig. Ein Suspend to RAM hält also auch nicht ewig an bzw. kann nicht ewig halten. Trotzdem dient es natürlich dem Stromsparen, der Akku hält länger, als wenn der Rechner einfach ungenutzt weiter läuft.
Am stationären PC ist es idR etwas anders, weil der dauerhaft Saft bekommt.
Der Tiefschlaf (suspend to disk) benötigt keine Energie, um die RAM Speicher vor Gedächtnisverlust zu bewahren.

Mit der Verwendung der einen oder anderen Technik schlägt man mehrere Fliegen mit einer Klappe.
Schnelles "runterfahren" &
schnelles wieder Hochfahren (in den Zustand vor dem Runterfahren, man kann "sofort" weiter"arbeiten")
Stromersparnis

"indiskutabel" ist natürlich schlecht in einem Forum.
Soll ich mich entschuldigen oder lieber gleich löschen?

@Berichtigung
Wenn man mit einem Test ungewollt Daten überschreibt, war es eher ein Experiment, kein Test.
Auch wenn der TE schreibt, die Namen seien eindeutig: da er mit cp arbeitet ist er ja offensichtlich nicht ganz sicher darin oder einfach nur vorsichtig (genug). Die mv Variante könnte zwar dagegen sprechen, das ist aber spekulativ, genau wie die gegenteilige Annahme. Warum soll man nicht ernst nehmen, was er schreibt? (Ein Messgerät tut auch sicher gut daran, eindeutige Dateinamen zu produzieren, das ist nicht unüblich, schon gar nicht in der Automotive Industrie)

Und was an iterativem Vorgehen hirnkrank ist, weiß ich nicht- auch nicht bezogen auf Anfänger. Solange ich mich mit allen Schritten auf der sicheren Seite bewege und das auch gesichert ist, ist das ein ganz normales, sogar empfohlenes, vielfach praktiziertes Vorgehen.
Iterativ heißt ja nicht, blind drauflos zu wüten, im Gegenteil. Bereits mit der ersten Antwort (von Dir) hatte der TE alle Befehle, um grundlegende Rahmenbedingungen zu klären. Zur Nutzung solcher Inforamtionen kann man dann niemand zwingen.
Und iterativ, damit meinte ich auch den Prozess im Forum. Unsachliche Häme ist da nicht hilfreich. Wenn man es also fachlich ganz besonders genau nimmt, kann man sich die sparen.

@buggy
Ich bin kein Freund von Legendenbildung, kann aber leider nicht mehr soviel dazu sagen, da es schon 3 oder 4 Jahre her ist. Das betroffene System war von einem Bot Angriff verseucht. Ich habe mir das mal aus Interesse angesehen bzw. es versucht. Ein Verzeichnis war vollgeballert mit kleinen Dateien. Ein ls sortiert oder gefiltert war bspw. nicht möglich. Fehlermeldung weiß ich leider nicht mehr.

Also positiv formuliert- falls das Fieber noch nicht gesiegt hat- sollte man die Rahmenbedingungen klären. Mein Vorschlag:
Kopiervolumen ermitteln/bestätigen (du)
(vermutete) Directory- und Dateianzahl ermitteln/bestätigen (find . -type d | wc -l und find . -type f | wc -l)
belegte/freie Inodes, Filesystemtype ermitteln (df -iT)
für alle aktiven Partitionen belegten/freien Speicherplatz ermitteln/bestätigen (df)
alles posten und auf gute Antworten hoffen

Mal zum Sortieren aus meiner Perspektive, also subjektiv und laienhaft(falls der TE nicht bereits ganz verschreckt ist)

Die Platzverhältnisse sind nicht abschließend geklärt, aber wichtig.
Das Dateisystem (die Dateisysteme) sind unbekannt, aber vielleicht wichtig.
Es ist unbekannt, warum der TE den eingesetzten Befehl verwendet, obwohl es simplere Möglichkeiten gibt.

Generell (Teil der Diskussion)
Ich würde von einem Befehl wie bspw.

mv, cp, ls, ..

zunächsteinmal keine Limitierung erwarten. *
Erfahrungswert: Bei sehr vielen Dateien tauchen Probleme auf, z.B. wenn eine (sehr) lange Dateiliste sortiert ausgegeben werden soll oder auch nach Pattern gefiltert. Wenn die Befehle also mit gewissen Parametern versehen sind. Details (Ursachen) hierzu sind mir nicht bekannt.
Das könnte ein Problem beim TE sein.
* Demnach besteht für mich bei Ihrer Anwendung auch zunächst keine Erfordernis von tieferen Kenntnissen des Filesystems (Ausnahme, ich müsste bei

cp

wissen, wieviel kopiert wird und wieviel Platz im Zielverzeichnis/-partition verfügbar ist)

Der angefragte Befehl ist komplexer als

mv, cp, ls

allein

xargs

selbst ist limitiert. Ein limit von xargs kann bspw. mit

getconf ARG_MAX

abgefragt werden.
Das könnte ein Problem beim TE sein.

Das

find

leidet evtl. unter ähnlichen Problemen wie mv, cp, ls. Denn es filtert ebenfalls und baut die Ausgabe um.
Das könnte ein Problem beim TE sein.

kleine Gemeinheiten:
Der Aufruf wie er vom TE gepostet wurde, bietet keinen Schutz davor, irrtümlich die Verzeichnisse unsauber anzugeben (Zielverzeichnis Untermenge des aktuellen Directories, also Teil der Move Menge) - die Aktion wird dadurch ggF. rekursiver als gewollt.
Das Zielverzeichnis kann durch unbekannte Mount Situation viel kleiner sein, als angenommen, sprich eine andere Partition.
Ggf. besteht ein user quota, das zuschlägt.

außerdem unklar/offen, besonders vor dem Hintergrund im proffesionellen Bereich:
was an diesem Verfahren das aufgeführte Backupproblem und die geforderte Traceability sichert.
was an diesem Verfahren Nachvollziehbarkeit garantiert (Logging fehlt).
was an diesem Verfahren Datenverlust (bei fehlender Eindeutigkeit der Dateinamen) garantiert.

Summa summarum spricht das alles dafür, mit einem einfachen Ansatz zu testen, Logging und Sicherheit einzubauen und dann Richtung Skalierbarkeit zu gehen. Damit wäre man m.E. am Ende bei einem Script wie Berichtigung es fordert. Dabei darf man ruhig iterativ vorgehen, also Fragen schrittweise klären, so wie wurzel99 es vorschlägt.

Ok, Fieber erklärt natürliche einiges, aber nun möchte ich @Berichtigung doch Recht geben.
Vorschlag: Antworten lesen und Fragen beantworten, möglichst deutlich (beides) wäre eine Maßnahme, mit der Du Dein Anliegen stark unterstützen könntest.

".. bei der Nutzung von mv mit der kleinen Befehlszeile von mir.."
Was soll das bedeuten? Deine kleine Befehlszeile ist sehr wahrscheinlich das Problem, sie mit anderen Befehlen zu kombinieren nicht hilfreich. Und wenn doch, dann schreib doch einfach deine Versuche hier hin. 1 zu 1 und mit Fehlerausgabe.

Wieso Du genau diese "kleine Befehlszeile" benutzt, was Du damit erreichen möchtest, warum die Vorschläge aus dem Forum nicht in Frage kommen, hast Du auch noch nicht erläutert. Die Erklärung mit den Autobauern ist spannende Prosa, aber enthält keinen informativen Nährwert.