Upload Dateien sind bei 0 Byte

[T-Rex]

Moin,

eine dringendes Problem. Die neue Webseite die ich übernehmen soll wirft einen Fehler. Auf dem Weg den Fehler zu lokalisieren bin ich wohl auf ein Serverpoblem gestoßen. Folgendes passiert:

ich versuche eine Datei zu ändern via ftp. Ich werde drei mal gefragt ob ich die bestehende Datei ändern möchte. Alle positiven antworten auf diese Frage werden anscheinend ignoriert. Am Ende hat die Datei 0 Byte und ist somit leer.

Der Versuch die Datei via webftp zu ändern schlägt ebenfalls fehl.

Ich kann neue Dateien hochladen, diese haben dann aber ebenfalls 0 Byte.

Eventuell ist eine Berechtigung auf dem Server falsch gesetzt. Da die Webseite ein Caching System benutzt, kann ich mir gut vorstellen, dass die falsche Berechtigung die Fehler hervorruft.

Jemand eine Idee?

Gruß gestressT-ERX

[localhorst]

Hallo,

das kann unterschiedliche Ursachen haben.

• Quota auf Serverseite erreicht
• Codierungsproblem. Es wird versuchf eine Datei im ASCII-Modus zu übertragen, die aber UTF-8 codiert ist.
• ftp-User bleibt nicht berechtigt, weil im Directory eine falsche Gruppenrichtlinie gesetzt wurde (GID-Flag)

Fragen:

• Welche OS auf beiden Seiten?
• Welcher FTP-Server?
• Welche FTP-Clients?
• Wurde bereits versucht, eine Datei per FTP zu löschen? Ergebnis?

[Felix Riesterer]

Lieber T-Rex,

ich verstehe nicht, warum die Leute zuerst hier fragen, wenn die speziellen Umgebungsbedingungen des Webspaces doch nur der Support beim Hoster wirklich wissen kann... m(

Liebe Grüße

Felix Riesterer

[Matthias Apsel]

Hallo Felix Riesterer,

ich verstehe nicht, warum die Leute zuerst hier fragen, wenn die speziellen Umgebungsbedingungen des Webspaces doch nur der Support beim Hoster wirklich wissen kann... m(

Uns wird halt zugetraut, auch dafür eine Lösung oder zumindest den Weg dahin zu kennen. Sieh es positiv.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

ich verstehe nicht, warum die Leute zuerst hier fragen, wenn die speziellen Umgebungsbedingungen des Webspaces doch nur der Support beim Hoster wirklich wissen kann... m(

Uns wird halt zugetraut, auch dafür eine Lösung oder zumindest den Weg dahin zu kennen.

Es hat sich halt rumgesprochen, dass wir Glaskugeln haben.

Es hat sich nur noch nicht rumgesprochen, dass die aus Milchglas sind.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[T-Rex]

Moin,

ich habe nie erwartet, dass mir jemand die Lösung sagt. Deshalb war die Frage auch nach einer "Idee". Ich hätte gehofft das eine Antwort nach der Art von "sowas hatte ich auch mal, damals lag es an ... ". Dann wäre das eventuell ein neuer Ansatz den man verfolgen könnte.

Ein Problem ist ja perse nicht schlimm, sofern man noch Ideen oder Ansatzmöglichkeiten hat. Gehen diese aus wird es unangenehm. Dann steht man einem Problem gegenüber was man nicht greifen kann und da ist man für jeden neuen Impuls dankbar.

Wie auch immer ... am Ende war der Speicher des Servers voll. Ich verstehe die Serverarchitektur noch nicht so ganz. Anscheinend wurde auf einem Webserver nochmals ein virtueller Server aufgebaut. Dieser hat zwei Partitionen. Eine mit 64 gb und eine mit 256 gb. Natürlich liegt die Webseite auf der kleineren Partition und die war voll. Der Hoster hat uns dann eine 8 gb große log Datei gelöscht - seit dem geht es wieder. Unser Systemadministrator hat seit dem das neue Todo einen eigenen Webserver auf zu setzen. Dann hätten wir alles selbst in der Hand.

Gruß gelöster T-Rex

[localhorst]

Moin T-Rex,

ich habe nie erwartet, dass mir jemand die Lösung sagt. Deshalb war die Frage auch nach einer "Idee". Ich hätte gehofft das eine Antwort nach der Art von "sowas hatte ich auch mal, damals lag es an ... ". Dann wäre das eventuell ein neuer Ansatz den man verfolgen könnte.

Deshalb hast Du von mir auch eine imho zielführende erste Antwort erhalten.

Ein Problem ist ja perse nicht schlimm, sofern man noch Ideen oder Ansatzmöglichkeiten hat. Gehen diese aus wird es unangenehm. Dann steht man einem Problem gegenüber was man nicht greifen kann und da ist man für jeden neuen Impuls dankbar.

Wie auch immer ... am Ende war der Speicher des Servers voll. Ich verstehe die Serverarchitektur noch nicht so ganz. Anscheinend wurde auf einem Webserver nochmals ein virtueller Server aufgebaut. Dieser hat zwei Partitionen. Eine mit 64 gb und eine mit 256 gb. Natürlich liegt die Webseite auf der kleineren Partition und die war voll. Der Hoster hat uns dann eine 8 gb große log Datei gelöscht - seit dem geht es wieder. Unser Systemadministrator hat seit dem das neue Todo einen eigenen Webserver auf zu setzen. Dann hätten wir alles selbst in der Hand.

Also Quota erreicht, wenn auch die harte Version... ;-)

Nächstes Mal tu mir bitte den Gefallen, und antworte mir wenigstens auf meine Rückfragen.

Um die Nörgler und Hilfeverweigerer muss man sich hingegen gar nicht weiter aufregen. Die gibt es leider immer. Wehe nur, wenn sie selber mal ein Problem haben.

Godd Luck
localhorst

[localhorst]

Moin T-Rex,

Wie auch immer ... am Ende war der Speicher des Servers voll.

Der Hoster hat uns dann eine 8 gb große log Datei gelöscht

Logdateien sollten jeweils ca. 1MB nicht überschreiten. Dafür gibt es logrotate. Wenn man das vernünftig einrichtet, kann man z.B. alle, die älter als drei Monate sind automatisch löschen lassen. Die Logs im Zeitraum davor werden z.B. aller 1MB, oder einmal am Tag (je nach Einrichtung) automatisch umgebrochen (geteilt). Zwei Stück bleiben im Klartext, alle älteren werden komprimiert. Das spart schon mal enorm.

Und dann sollte man die beiden im Klartext in fail2ban einbinden. Damit kann man dann anhand der Statuscodes (4xx und 5xx) Angriffsversuche erkennen und diese abwehren.

Ein Provider/Hoster sollte das können.

Good Luck
localhorst

[Raketenfürchtenix]

Ich verstehe die Serverarchitektur noch nicht so ganz. Anscheinend wurde auf einem Webserver nochmals ein virtueller Server aufgebaut.

Der virtuelle Server ist dann regelmäßig der gemietete.

Warum macht man das so?

1. Kunde X schießt den Server X-0001 ab und zwar sehr gründlich.
2. Kunde weint.
3. Provider A kickt einfach einen Snapshot der virtuellen Maschinen auf seinem Host-Server dorthin zurück, woher dieser stammte und bootet den virtuellen Server neu.
4. Kunde trocknet seine Tränen.

Der Hoster hat uns dann eine 8 gb große log Datei gelöscht

Oha. Das sowas entstehen kann führt zu 1. und das ist die Frage, die beantwortet werden muss. Sowas hatte ich auch mal: Da hatte jemand die glänzende Idee, eine Logdatei umzubenennen und genau das logrotate eben nicht mitzuteilen.

[Der Martin]

Hallo,

1. Kunde X schießt den Server X-0001 ab und zwar sehr gründlich.
2. Kunde weint.
3. Provider A kickt einfach einen Snapshot der virtuellen Maschinen auf seinem Host-Server dorthin zurück, woher dieser stammte und bootet den virtuellen Server neu.
4. Kunde trocknet seine Tränen.

5. Provider A schickt Kunde X eine Extra-Rechnung für den manuellen Eingriff.
6. Kunde weint erneut.
7. Kunde zahlt die Rechnung widerwillig und hat hoffentlich was gelernt.

Live long and pros healthy,
 Martin

[T-Rex]

Also dieses Logfile hat alle Übertragungen an den Client mitprotokolliert, hat aber nichts mehr gelöscht. Da stand sowas drin wie css Datei wurde um 11 uhr an ip xy ausgeliefert. Pro Tag wurden ca. 100.000 Zeilen erstellt. Die Datei wurde vom Serversystem (Plesk) erstellt und diente wohl für irgendwelche Statistiken. Der Hoster oder der Admin haben das weitere mitprotokollieren abgestellt, zumal keiner weiß wo man sich diese Statistik anschaut :D.

100.000 Grüße T-Rex

[Raketenfürchtenix]

Da stand sowas drin wie css Datei wurde um 11 uhr an ip xy ausgeliefert.

Oh. Oh. Das war a) DSGVO-widrig und b) auch vorher „nur noch nicht erlaubt“.

[T-Rex]

c) fällt mir kein Anwendungsfall dazu ein. Klar, man hat eine hübsche Grafik wie oft etwas abgerufen wird ... und dann? Solang die Dateien richtig ausgeliefert werden und davon gehe ich doch mal bei einem Server aus, kann man die Abgefragten Ressourcen doch anhand der Zugriffsstatistiken selbst zusammenrechnen.

Naja ... ist alles nicht auf meinem Mist gewachsen und sollte jetzt deaktiviert sein.

Gruß Rechenexperte T-Rex