Bekijk Volledige Versie : FTP traffic door DELE commando?
Ik heb eind juli 81.000 jpeg bestanden verwijderd van een ftp server met de FileZilla FTP client. Hierbij is FileZilla op een gegeven moment blijven hangen, waarna ik de FTP client opnieuw opgestart heb.
De volgende dag kwam ik erachter dat mijn reseller account Suspended was. Ik dacht eerst dat ik gehacked was, want ik gebruik bij lange na nooit al mijn toegestane traffic. Het bleek bij navraag bij mijn webhost allemaal FTP traffic te zijn. Nu beweert hij dat ik 953 GB aan traffic heb veroorzaakt door het verwijderen van alle JPEG bestanden.
Mijn webhost heeft mijn account nu weer Suspended terwijl ik aangegeven heb dat ik het niet eens ben met zijn redenering. Aangezien de factuur voor het extra traffic nu ook nog verhoogd gaat worden met administratiekosten zou ik graag enige feedback hebben over het volgende.
Ik geloof niet dat een DELE commando voor 12 MB traffic per jpeg bestand (van 50-200 kb groot) kan zorgen. Ik denk eerder dat mijn webhost iets verkeerd geconfigureerd heeft. Is er een bug bekend in DirectAdmin die zorgt dat het FTP verkeer verkeerd gemeten wordt?
Het kan toch niet zo zijn dat een DELE commando echt voor zo veel traffic zorgt?
Het DELE commando geeft wel een log file entry met de size van het bestand dat verwijderd is.
953GB traffic???? Bijna 1TB traffic met wat jpeg'jes?
Pornosite ofzo? ;-)
Het DELE commando op zich genereert niet veel traffic.
DELE filename.jpg
en een daarbij horende reply in de trend van
2xx File deleted.
Uiteraard moet je daar ook nog de nodige CD commandos bij tellen als ze allemaal in verschillende folders staan, maar dan nog zou je niet aan dergelijke traffic mogen komen.
Als het effectief enkel FTP traffic zou zijn, dan moet het dus iets anders zijn dan dat. Ik kan me ook niet inbeelden dat als client is blijven hangen, die dan alsnog zoveel traffic heeft kunnen gegeneren, tenzij je client enkele weken is blijven loopen op hetzelfde commando (aan 100 bytes per delete/reply, zouden dat 10 miljard commando's zijn)
Vraag de logs op waarop hij zich baseerd, want daar moet dan toch duidelijk iets instaan wat dit zou kunnen verlkaren.
Ik heb de logs gekregen van mijn webhost, en hij beweert dat het komt doordat er een soort loop is (maar dat is het niet, het zijn 81000+ JPEGS die ik verwijder). Een loop zou ook meer dan 83000 regels hebben veroorzaakt.
Ik heb het FTP log bestand even hier (12 mb) (http://www.filipucci.nl/meuk/website_ftp_log.txt) gezet voor meer informatie (wel een beetje bewerkt qua login en directory namen).
@IT-worX
Door een bug in deze versie van het CMS wordt van elke gegenereerde thumbnail een kopie opgeslagen. Deze thumbnails blijven gegenereerd worden omdat de kopie nooit opgevraagd wordt. Dom. Maarja.
Ik heb de logs gekregen van mijn webhost, en hij beweert dat het komt doordat er een soort loop is (maar dat is het niet, het zijn 81000+ JPEGS die ik verwijder). Een loop zou ook meer dan 83000 regels hebben veroorzaakt.
Ik heb het FTP log bestand even hier (12 mb) (http://www.filipucci.nl/meuk/website_ftp_log.txt) gezet voor meer informatie (wel een beetje bewerkt qua login en directory namen).
Als die log 12 mb is, moet de datatraffic imo niet veel meer zijn...
En wat zegt DA van stats als je zelf inlogt, want 953GB op een dag tijd lijkt mij wel redelijk veel. Dan zou jij meer dan 90mbit op een dag moeten trekken, en volgens mij is jouw adsl/kabel upload/download niet zo zwaar.
Ik zit op een Ziggo lijntje in een huis met ongeveer 3 (meer mag toch niet volgens algemene voorwaarden Ziggo?) anderen die er ook op zitten. Mijn maximum download is 800 kb/s, en upload rond de 50kb/s schat ik.
Mijn webhost heeft me ervan verzekerd dat de 953GB traffic alleen via de FTP komt en dat dat het logbestand is van de FTP. Deze statistieken komen uit DirectAdmin, ik kon daar inderdaad zien dat de betreffende user zoveel FTP traffic had. Echter, ik geloof gewoon niet dat dit juist is. Wat zou er mis kunnen zijn in de configuratie van mijn webhost? Ik heb geen technische know-how op dit gebied.
Als ik uitga van alle plaatjes 200 KB, dan zou je dus zo`n 15 Gb aan afbeeldingen hebben gehad? En volgens je webhost zou je dan ruim 60x het aantal plaatjes aan dataverkeer heb gegenereerd? Afgezien van het feit dat het een hele knappe prestatie is om bijna 1 TB te trekken met een standaard uplink en een Ziggo abbo.
Lijkt me sterk, heel sterk.
Ik zou zeggen neem nogmaals contact op met je webhost, en probeer uit te leggen dat het onmogelijk is om in 1 dag zoveel verkeer te genereren met je ziggo verbinding.
het downloaden van 953 Gigabyte over een 10mbit verbinding duurt ongeveer 9 dagen...
Mocht je er niet uitkomen dan zou ik op zoek gaan naar technisch beter onderlegde hoster.
rackhost.be
14/09/09, 18:39
DELE maakt idd geen traffic, enkel de logs dewelke hij retourneert en dat zal in totaal ook niets meer kunnen zijn dan uw +- 12MB
heb de log nu niet gedownload, maar over welke tijdspanne gaat het?
Het logbestand gaat over een tijdspanne van 6 uur.
rackhost.be
14/09/09, 18:48
is onmogelijk dan, uw hoster weet blijkbaar niet waarover hij praat ...
Het logbestand gaat over een tijdspanne van 6 uur.
Je webhoster zal waarschijnlijk alle filesizes welke aan het einde van de regel staan, tellen als dataverkeer. Normaal zal er een logregel zo zijn dat een file die via ftp verzonden is, deze in de log opgenomen wordt met de size in bytes. Bij een file transfer krijgen deze regels een STOR, RNFR of RNTO regel. De files die verwijderd worden komen in de log als DELE.
De applicatie om te bepalen hoeveel data verkeer je gebruikt heb, houdt er waarschijnlijk geen rekening mee dat de logregels met een DELE geen dataverkeer zijn geweest.
Ik zet in op dat de verkeerde (/teveel) logregels zijn gebruikt om de hoeveelheid ftp verkeer te bepalen.
Je webhoster zal waarschijnlijk alle filesizes welke aan het einde van de regel staan, tellen als dataverkeer. Normaal zal er een logregel zo zijn dat een file die via ftp verzonden is, deze in de log opgenomen wordt met de size in bytes. Bij een file transfer krijgen deze regels een STOR, RNFR of RNTO regel. De files die verwijderd worden komen in de log als DELE.
De applicatie om te bepalen hoeveel data verkeer je gebruikt heb, houdt er waarschijnlijk geen rekening mee dat de logregels met een DELE geen dataverkeer zijn geweest.
Ik zet in op dat de verkeerde (/teveel) logregels zijn gebruikt om de hoeveelheid ftp verkeer te bepalen.
Dat zou betekenen dat er 953 gigabyte aan bestanden waren? Lijkt me sterk ;)
Dat zou betekenen dat er 953 gigabyte aan bestanden waren? Lijkt me sterk ;)
Nee, Als je het log bestand opend, zie je dat de regels door elkaar staan. Ik heb geen zin om deze netjes te scheiden om daarna per RNFR, RNTO, STOR en DELE te gaan optellen.
Alleen deze 4 samen (RNFR, RNTO, STOR en DELE) geven die ~936GB
Alleen zouden die DELE regels daar eigenlijk bij moeten zitten.
En voor een RNFR en RNTO moet er gekeken worden hoeveel dataverkeer is daadwerkelijk is. Is een RNTO een RenameTO.. zoja, dan zouden deze er eigenlijk ook niet bij moeten zitten.. en wat doet een RNFR?
Ik hoop dat mijn webhost bovenstaande reacties leest en zijn mening herziet over het veroorzaken van FTP dataverkeer door mijzelf.
Ik ben benieuwd of het door lmp aangedragen probleem inderdaad plaatsvindt, maar ik weet helaas niks over de manier waarop mijn webhost of Directadmin aan de berekening van mijn FTP traffic komt. Als iemand nog meer weet of andere ideeën heeft over de oorzaak van dit probleem dan zou ik dat ook graag horen.
Totdusver bedankt voor alle reacties!
Dat zou betekenen dat er 953 gigabyte aan bestanden waren? Lijkt me sterk ;)
Er is een bug bekend die het volgende doet:
1 + 1 = 2 + 1 = 3 + 1 = 4 + n = ...
ipv
1 + 1 + 1 + 1 + n = ...
Dit zou misschien wel de oorzaak kunnen zijn
Nee, Als je het log bestand opend, zie je dat de regels door elkaar staan. Ik heb geen zin om deze netjes te scheiden om daarna per RNFR, RNTO, STOR en DELE te gaan optellen.
Alleen deze 4 samen (RNFR, RNTO, STOR en DELE) geven die ~936GB
Alleen zouden die DELE regels daar eigenlijk bij moeten zitten.
Dan is het nog enorm veel data, en dus onwaarschijnlijk...
Wellicht dat je je hoster nog kan vragen om een "echte" traffic grafiek van de switch poort te sturen die dan ook moet aantonen dat je die traffic hebt genenereerd?
marsipulami
14/09/09, 19:22
Wellicht dat je je hoster nog kan vragen om een "echte" traffic grafiek van de switch poort te sturen die dan ook moet aantonen dat je die traffic hebt genenereerd?
maar ja, dat kan van iedere user afkomen natuurlijk die op die server zit. kan je niet mee aantonen dat het de TS is.
953 GB * 1024 = 975.872 MB
* 8 = 7.806.976 Mbit
6 uur = 21.600 seconden
7.806.976 / 21.600 = 361,43 Mbit/seconde aan ftp-verkeer
netjes
die logfile heeft 31,239,588,306 bytes bij DELE records, 16,277,968 bytes aan STOR, 63,123,137 bytes aan RETR, 3,752 bytes aan RNFR en 7,002 bytes aan RNTO
iets klopt er niet, het totaal is 31,319,134,828 bytes en dat is geen eens 900+GB
die logfile heeft 31,239,588,306 bytes bij DELE records, 16,277,968 bytes aan STOR, 63,123,137 bytes aan RETR, 3,752 bytes aan RNFR en 7,002 bytes aan RNTO
iets klopt er niet, het totaal is 31,319,134,828 bytes en dat is geen eens 900+GB
Ik kom op de volgende waarden:
RETR: 78503894 bytes ( 0.073 Gb) 1527 regels
STOR: 16303721 bytes ( 0.015 Gb) 137 regels
MKD : 134663 bytes ( 0.000 Gb) 18 regels
RNFR: 0 bytes ( 0.000 Gb) 206 regels
RNTO: 0 bytes ( 0.000 Gb) 154 regels
DELE: 1004934721390 bytes (935.918 Gb) 81696 regels
RMD : 0 bytes ( 0.000 Gb) 5 regels
Je gaat bij de DELE de fout in omdat er filenamen zijn met een spatie (omringt door quotes). Je kan dus niet standaard splitten op een spatie en het 8e element pakken voor de file size..
die logfile heeft 31,239,588,306 bytes bij DELE records, 16,277,968 bytes aan STOR, 63,123,137 bytes aan RETR, 3,752 bytes aan RNFR en 7,002 bytes aan RNTO
iets klopt er niet, het totaal is 31,319,134,828 bytes en dat is geen eens 900+GB
Grofweg 30gb aan DELE commando's dus, scheelt zo'n 923 gigabyte...
Grofweg 30gb aan DELE commando's dus, scheelt zo'n 923 gigabyte...
Peanuts zal die hoster wel denken ;)
Misschien handig om dit te melden bij DA?
maar ja, dat kan van iedere user afkomen natuurlijk die op die server zit. kan je niet mee aantonen dat het de TS is.
Dat is inprincipe waar maar het gaat hier om een grote hoeveelheid data in relatief korte tijd waarvan het tijdstip bekend is, dus dan moet je volgens mij wel een piek in de traffic grafiek hebben op het exacte tijdstip. Het lijkt me erg toevallig dat er opeen een andere user is die soortgelijke traffic piek op het zelfde moment doet.
FunnyMedia
15/09/09, 12:04
Wat voor een harddisk zit er in die server dan?
Je kan toch niet meer dan de grote van de harddisk verwijderen?
Is zomaar eens een vraagje waard :-)
Overigens lijkt het mij zeer sterk, en waarom heeft er dan geen server of netwerk beheerder ingegrepen.
Als een server bij ons "plots" 3x meer dan het gemiddelde van de laatste 30 dagen in een tijdsbestek van 30 minuten gaat gebruiken gaat er een sms-je af op de telefoon van de server / netwerk beheerder.
Die kan dan kijken wat er loos is en waarnodig ingrijpen.