Beiträge von jay

    Leider hat mir der netcup Support vorhin mitgeteilt, dass auch bei .com-Domains die vorausbezahlte Laufzeit nicht berücksichtigt wird.

    wie gesagt, das wird von provider zu provider verschieden gehandhabt.

    ich habe die erfahrung, daß "althergebrachte" provider das "korrekt" machen, neuere aber die deutsche "unart" auf alle domains umlegen.

    was ich aber für wahrscheinlich halte:

    deine domains verlängern sich eventuell bei nc immer zum umzugsdatum um ein jahr und werden dir auch dann berechnet.

    die laufzeit verlängert sich aber um ein jahr des registrierdatums.

    das bringt dir zwar nichts für die laufzeit bei nc, aber evtl bei nem weiteren umzug, oder bei kündigung der domain.

    diese läuft dann eben bis zum echten auslaufdatum weiter...

    so kenne ich es zumindest bei den providern, die "nicht anrechnen".


    jay


    Wenn eine Domain den Provider wechselt verlangt die Registrierungsstelle (bei .de-Domains die DENIC) erneut die Jahresgebühren und kassiert ein zweites mal ab.

    Keine Rückzahlungen sind möglich.

    das gilt ausschließlich für .de domains. alle anderen domains verlängern beim renew die laufzeit.

    d.h. wenn du eine .com domain heute verlängerst, und sie dann bis 2.4.19 läuft, sie danach zu einem neuen registrar umziehst, so verlangt der zwar eine jahresgebühr, deine domain läuft dann allerdings bis zum 2.4.20.

    jay

    ps: wie nc dir das berechnet ist eine andere sache. das mit dem "laufzeit verfallen" gibt es aber nur bei .de (welche 1. eh sau billig sind und 2. denicmitgliedsintern quasi tages/monatsgenau abgerechnet werden.

    ist es wirklich so, daß man die ostereier immer sieht, sie auch anklicken und die beschreibung lesen kann,

    dann aber bei "in den warenkorb" die meldung "nicht verfügbar" sieht?


    ah, und: ist der osterei vps wirklichd as günstigste angebot dieses jahr?

    oder gibts noch sowas wie die vserver a b und c letztes jahr?

    kleiner zwischenstatus:

    vorab: das bezieht sich nicht auf den server gestern, sondern auf den heute, bei dem ich 120gb übertragen muss.


    der berliner ist schuldlos.

    dorthin kann ich problemlos daten mit 140megabit übertragen (zumindest solange, bis der netcup shaper zuschlägt).

    wenn ich die agb richtig verstanden habe, so sollte bei meinem rs server das shaping überhaupt erst aktiv werden, wenn ich über 10tb liege. und auch dann erst nach 60 minuten dauerfeuer.


    was das ganze quasi unbenutzbar macht ist nun wider erwarten erstmal nicht der shaper, sondern die cpu! mit tar komme ich auf 140mbit/s. mit tar.gz kommt das ganze auf etwa 80kilobit/s.

    und das obwohl das ding 2 angeblich dedizierte kerne hat!

    es kann doch nicht sein, daß nur das packen den tar prozess auf ein 1400stel dezimiert!??


    kommentare erwünscht :)


    jay:


    ps: nach wie vor aber auch gerne ein konkretes verfahren, den traffic auf 80mbit/s zu begrenzen.

    mein ihr, ich sollte dazu ein eigenes thema aufmachen?

    hallo fisi,

    diese umschreibungen die oft missverständnisse erzeugen find ich "lustig".

    es geht aber auch garnicht eigentlich um diesen bestimmten provider.

    den onlinespeicher "in berlin" hab ich auch nur deshalb, weil die mir irgendwann mal als kundenbindungsangebot einen unschlagbaren preis dafür gemacht hatten.

    so finden die häufigeren backups zu mir nachhaus statt.

    mittlerweile habe ich auch eine recht gute 100er anbindung zuhause.

    vom nc server 5 hops und 5millisekunden latenz.

    da gehn also vermutlich bei großen backups mehr als 80mbit im schnitt drüber.

    mein eigentliches problem besteht also noch immer :-/

    jay

    hallo,


    >Das habe ich mit Hilfe des SFTP-Client von beiden Servern aus zum Zielserver in Berlin >gemessen.


    ah, es steht also nirgends festgeschrieben. also könnte es je nach "tagesform" auch erheblich mehr sein...


    >Damit man dein Problem besser eingrenzen kann, meinte ich mit der Frage "Welchen Server - genaue Produktbezeichnung - hast du denn?" deinen Problemserver.


    der server mit dem gestern die probleme bestanden war ein RS 1000 SAS G7 SE a2.
    der mit dem ich heute nacht bzw morgen früh versuchen werde etwa 120 gig zu übertragen ist ebenfalls ein RS 1000 SAS G7 SE a2.

    >Wenn ich mich richtig daran erinnern kann, wurde in diesem Forum schon mal das Tool TC, >welches ich aber auch nicht nutze, zur Bandbreitenbegrenzung vorgeschlagen.


    ja, den thread mit dem vorschlag habe ich ja oben verlinkt. leider steht da nur "schau ich mir mal an", aber keine weiteren berichte oder gar eine lösung.


    >Ich persönlich regle die Bandbreitenbegrenzung über einen meiner vielen OpenVZ 7 Container unter OpenVZ 7 auf einen großen Root-Server.

    >Dessen Bandbreite wird präzise auf 9 MB/s (9 MB/s entspricht 72 Mbit/s) begrenzt.


    du benutzt also eine extra beschränkte vm auf einem rootserver bei einem andren provider als backup ziel!?
    elegant. leider geht das ja bei hidrive nicht. und ich habe auch nicht nur einen zielserver für meine backups...


    jay

    hallo andreas,

    jay ,

    Da du mit der Bandbreite der Gegenstelle aus Berlin mit ca. 4,5 MB/s noch weit darunter liegst, wird mit höchster Wahrscheinlichkeit Netcup dir die Bandbreite auch nicht drosseln.

    das wäre ja ok.aber - woher hast du das mit den 4,5MB/s? selbst wenn, so würde das ja auch nur mein problem zum hidrive lösen, nicht aber zu anderen servern, zb bei he**ner, die dediziert 1gb haben.

    Zitat

    Welchen Server - genaue Produktbezeichnung - hast du denn?

    ich habe nicht nur einen server.
    ich habe da einen bunten mix:
    VPS 100 G7 SE O2017
    VPS 500 G7SE O2017
    VPS A Ostern 2017
    RS 1000 SSD G7SE O2017
    VPS B Ostern 2017
    VPS 500 G7SE OStern 2017
    RS 1000 SSD G7SEa1
    RS 1000 SAS G7 SE a2
    VPS 2000 G7SEa1
    und nicht nur jeweils einen.
    die meisten server sind modell
    RS 1000 SSD G7SEa1.

    da können bei backups schonmal ein paar hundert gig anfallen. sowohl zwischen den servern, als auch zu denen anderer provider, oder zu mir nachhaus.


    am meisten wäre mir mit einer methode geholfen, mit der ich den durchschnitt unter 80Mb/s halten könnte.


    jay

    ich vermute beim webhosting gilt das nicht, denn das ist ja quasi ein netcup eigener server.

    die beschränkungen sind ja sogar bei vservern und rootservern unterschiedlich wie man hier lesen kann:

    1426-root-jpg

    1425-vps-jpg

    jay

    hallo de_bonner,

    die in diesem link gemachte aussage trifft also nicht mehr zu?

    falls doch, wie kann ich das verhindern?

    machst du die backups von einem vserver oder rootserver aus?

    danke

    jay

    könnte mir vielleicht jemand den weg zu dem thread wegen der drosselung bei zuviel lan-bandbreitenverbrauch schicken?

    oder auch eine bestätigung, daß es NICHT gedrosselt wird?

    ich weiß nicht einmal mehr, ob ich das in diesem forum las...

    danke

    jay

    danke für die antwort.

    aber schrieb ich nicht bereits, daß die verbindung zu hidrive getesteterweise schnell genug war?

    aber ok. ich werde das große backup zwischen 2 netcup vservern versuchen. vielleicht ist ja zumindest firmenintern das shaping raus...

    jay

    hallo,

    ich bin gerade dabei ein backup eines servers zu erstellen.

    dies geht tierisch lahm.

    offensichtlich schlägt hier ein traffic shaper zu.

    was ich getan habe: server mit der rescue cd gebootet.

    platte gemountet

    per sshfs ein st**to hidrive gemountet.

    dort läuft nun ein tar der platte hin.

    das ganze läuft nun seit 4-5 stunden und er hat gerade mal 3,5 gigabytes übertragen.

    zum glück hat dieser server nur 8 gig.

    ich glaube gesehn zu haben, dass die ersten 10-20megabytes schnell gingen. seitdem geht kaum noch was durch die leitung.

    am hidrive liegt es nicht. das habe ich von einem andren server aus getestet.

    ist es wirklich unmöglich, ein eigenes backup auf einen drittserver zu machen?

    wie kann ich das shaping verhindern?

    ich glaube mal etwas von einem iptables befehl gelesen zu haben. aber diesen finde ich nicht mehr.

    auch bräuchte ich dann noch die grenzen, um nicht dem shaper zum opfer zu fallen.

    heute abend muss ich noch ein backup von einem server mit 120 gig machen. ich hoffe, daß mir bis dahin jemand den erhellenden tipp geben kann. das würde ja sonst 6 wochen laufen :)

    danke

    jay

    Sicherlich im Interesse der eigenen Zusatzprodukte ;). Der Storagespace von netcup lässt sich per nfs mounten. Sicherlich soll die Einrichtung damit erleichtert werden.


    aaaaah! DAS wäre natürlich ein guter grund. :)
    allerdings würde ich dann auch erwarten, dass rpc per default auch auf das netcup ip range beschränkt wäre...

    Zitat


    Verstehe auch nicht, weshalb netcup seit einiger Zeit die Images mit deutscher Sprache ausliefert.


    hm, weil es eine deutsche firma ist, die sich an deutsche nutzer richtet?
    das halte ich (obwohl nicht bedürftig) schon für ein gutes default. vor allem weniger wichtig, da es keine ports nach außen öffnet, von denen der unbedarfte user nichts weiß.


    jay

    hallo,

    jay Bei Ihm geht es zwar nicht um rpcbind, sondern um NetBIOS


    huch, das habe ich tatsächlich überlesen, da ich dasselbe zeitgleich zu einem server erhalten habe, auf dem ich tatsächlich noch den nfs kram aktiv hatte :)

    Hab die gleiche E-Mail bekommen wegen Port 111. Kann das aber lokal auf der Maschine nicht nachvollziehen dass der offen sein soll.


    der scan könnte uralt sein. das bsi verweist in seiner mail (zumindest bei dem nfs hinweis) auf den timestamp der angehängten logs.
    diese hat nc aber leider aus der weiterleitung gelöscht, sodass du jetzt nur raten kannst...


    jay

    du deaktivierst bzw deinstallierst am besten die nfs commons und rpcbind. ich bezweifle, daß du die brauchst.
    das ist ein unsinniger default...
    jay

    hallo,


    Ich denke hier haben wir unterschiedliche Sichtweisen auf den Umgang mit Vermutungen. Wenn ich Vermutungen äußere, versuche ich auch zu erklären wie ich zu diesen Vermutungen gekommen bin.


    ja, verschiedene definitionen sind oft die ursache von missverständnissen. :)
    ich komme eher aus dem mathematischen bereich und dort ist die definition: "Vermutung, klassische unbewiesene Sätze".
    die begründung liegt oft einfach in intuition...


    Zitat

    Ihre Vermutungen haben Sie davor geäußert. Wenn Sie derartige Vermutungen äußern, sollten Sie auch damit rechnen das diese ggf. widerlegt werden oder Vorschläge kommen, was ein Betroffener hätte anders machen können. Derartiges würde ich dann nicht direkt als Smalltalk bezeichnen, sonst kommt schnell die Vermutung auf, dass man sich ungern andere Meinungen zu dem Thema anhört ;)


    den smalltalk sehe ich weniger in den technischen ausagen, sondern darin fahrlässiger handlungen bezichtigt zu werden, gefolgt von fadenscheinigen rechlichen mutmaßungen. die technische diskussion eines themas finde ich durchaus ok. eine versuchte schuldzuweisung, vor allem mit solch seltsamen "argumenten" ist für mich beim besten willen nurnoch smalltalk. und - besteht nicht ein smalltalk gerade darin, sich andere meinungen eben anzuhören?
    schon wieder eine definitionsfalle. ;)


    Zitat


    Wenn ich das richtig auffasse geht es hier nach wie vor darum, dass eine Partition aufgrund eines vermutlichen Hacks voll gelaufen ist. Tipps wie sich Hacks in der Zukunft vermeiden lassen, sind immer gerne willkommen und kein Smalltalk hier im Forum. Auch eine kritische Auseinandersetzung mit unseren Images ist willkommen.


    ähm, ich habe das so verstanden, als sei das eigentliche thema für den threadersteller längst erledigt.
    er hat einen fremden login aus china auf seinem server entdeckt. danach ist doch jede weitere fehlersuche verschwendete zeit, da ein kompromittierter server (in 99,5%) neu formatiert gehört.
    "du handelst grob fahrlässig" ist m.e. kein tipp zur vermeidung eines problems. und auch keine auseinandersetzung mit nem image...


    gruß
    jay

    hallo herr preuß,


    Guten Morgen,


    können Sie Ihre Aussagen fundiert begründen? Zuerst meinten Sie die Passwörter könnten in kurzer Zeit via Bruteforce erraten werden. Jetzt schreiben Sie den oben zitierten Satz. Wie kommen Sie denn auf diesen Aussagen?


    vermutungen haben keine begründungen, denn es sind vermutungen. mit begründung wären es behauptungen.
    ich dachte das betont zu haben. vermutungen gehören m.e. erstmal eher in den bereich smalltalk/gedankenaustausch/verschwörungstheorie. :)


    auch war es umgekehrt. aus meiner eigenen erfahrung vermutete ich als erstes eine bisher nicht ausgenutzte lücke in froxlor, da der aus china gehackte server bei mir selbst mit dem froxlor image auftrat.
    habe ich nicht weiter verfolgt, da ich danach den server einfach mit dem minimalimage überbügelt und das ssh logon entsprechend abgesichert habe, sowie froxlor nicht einsetze.
    an den support meldete ich dies ausschließlich als information und ausdrücklich NICHT als supportanfrage (wie oft heißt es sonst "wieso hast du denn nix gesagt"...).


    als ich nun die frage des threaderstellers las, kam mir das ganze bekannt vor und ich habe meine vermutung, daß es auch hier ein hack aus china sein könnte, im forum geäußert.
    diese vermutung hat sich dann ja scheints bewahrheitet.
    die aussage des threaderstellers, daß er nicht froxlor sondern das minimal image benutze, ließ meine vermutung in die richtung passwortgenerator umschwenken, da ja im minimalimage außer ssh mit passwortauth kaum ein sonstiger einhackpunkt gegeben ist. bewiesen ist hier natürlich auch nichts, denn wenn ich dafür beweise hätte, hätte ich das ganze ja längst mit begründung an den support gemeldet, damit das behoben werden kann.


    seit den aussagen von oliver.d geht es von meiner seite eh nurnoch um smalltalk und um kein ernstzunehmendes thema mehr...


    Zitat


    Das Image welches wir mit Froxlor ausliefern haben wir in der aktuellen Version bereits mehr als 10.000 mal ausgeliefert. Was meinen Sie was passiert, wenn hier eine bekannte und leicht ausnutzbare Sicherheitslücke vorhanden wäre?


    nunja, wenn es wirklich eine lücke gibt, so ist sie ja bisher offensichtlich allenfalls wenigen chinesen bekannt. ob sie dann auch noch leicht auszunutzen ist, bleibt dann ebenfalls abzuwarten. ich denke 2 auf ihren images basierende server die auf mutmaßlich demselben weg, von mutmaßlich derselben stelle gehackt wurden, sind da noch kein großes alarmzeichen. aber jedes leck beginnt mal mit ersten, zaghaften vermutungen.


    ihnen ist ja die vermutung jetzt gewahr und wenn es, so unwahrscheinlich es ist, irgendwann gehäuft zu solchen vorkommnissen kommen sollte, so werden sie sich sicher rechtzeitig erinnern und auch an dieser stelle suchen...


    gruß
    jay