Push ist gar kein Problem, wenn das Ziel ordentlich versioniert. Wer lässt denn den Client vorhandene Backups auf dem Backupserver überschreiben?
Beiträge von NaN
-
-
Den politischen Beißreflex mal außen vor...
Dass der Entwickler seinen Einfluss auf den Code verliert, weil er Russe in Russland ist, ist aber offensichtlich, oder? Und warum man Russen, die in Russland und damit rechtsstaatlicher Kontrolle entzogen sind, aber dafür unter der Fuchtel eines kurzen Geheimdienstdespoten mit territorialem Größenwahn stehen, nicht in der Lieferkette von wichtigen Infrastrukturprodukten haben will, sollte auch klar sein. Dass der Name des Forks Markenrechte verletzt, ist noch das kleinste aller Probleme. Daran ändert auch der Open Source Status nichts.
-
Die Frage ist zu ungenau. Was meinst du z.B. mit "ohne dass die Performance leidet"? Ich würde sagen, probier es einfach aus. Wenn es nicht zu deiner Zufriedenheit funktioniert, nimmst du eben die Zufriedenheitsgarantie in Anspruch. Ich sehe die Grenze zwischen Shared Hosting und eigenem Server nicht in der Performance sondern in den administrativen Freiheiten. Wenn man mit den Funktionen des Shared Hosting auskommt und es schnell genug ist, warum sollte man sich zusätzliche Arbeit mit einem eigenen Server machen?
-
Du musst für alle Fehler, die du in deinem Leben machst, für alles was Du tust, den Kopf hinhalten.
Ich weiß, dass hier gerne der Zeigefinger gehoben wird, aber man muss schon schauen, wer welche Fehler macht. Die Ausgangssituation war, dass jemand etwas am Internet betreibt, dabei durchaus Vorsicht walten lässt, und dann trotzdem durch die Schuld eines Angreifers ein Schaden bei einem Dritten verursacht wird. Als Vergleich dazu wurde auch schon der Klassiker "Auto wurde gestohlen und damit Blödsinn gemacht" genannt. Man ist nicht automatisch für die Taten anderer mitverantwortlich, weil einem das Tatwerkzeug gehört. Der Aufwand, der verlangt wird, um Schäden durch Missbrauch zu vermeiden, so dass man nicht haftet, hängt u.a. davon ab, welche Gefahr von dem Gegenstand ausgeht. So dürfte die von einem einzelnen Server für andere Internetteilnehmer ausgehende Gefahr nicht hoch sein, da diese ebenfalls selbst für ihre Sicherheit sorgen müssen.
Man sieht auch in diesem Thema, dass das Bewusstsein für die Verantwortung schon deutlich darüber hinaus geht, was viele Serverkunden mitbringen. Wenn die "YOLO" Admins aber alle automatisch und unbegrenzt haften müssten, würde man mehr über Privatinsolvenzen durch Serverbetrieb lesen. Überlegt euch doch mal, wer alles Gameserver betreibt. Schaut euch Tutorials dazu an: Sind die für Anwender mit tiefgreifenden IT-Kenntnissen geschrieben? Nichts wird so heiß gegessen, wie es gekocht wird.
-
Eine virtuelle Maschine zu Hause wurde schon als Lernplattform genannt, aber wenn der Internetanschluss das hergibt, kann das auch eine echte Dauerlösung sein. "Dialup"-Zugänge haben ziemliche Narrenfreiheit, weil man an solchen Internetzugängen keine Admin-Kompetenz erwartet und unbehandelte Malwareinfektionen, Spamschleudern und Botnetze an der Tagesordnung sind. Die Upstream-Datenrate ist oft eng begrenzt, was auch das Missbrauchspotenzial senkt, reicht aber für den Zweck eines privaten Servers vielleicht aus. Wenn der Nutzerkreis fest ist und die nötigen Fähigkeiten hat, ein VPN zu nutzen, kann man damit die Angriffsfläche deutlich verringern.
-
It would be weird if 1Gbps for more than an hour caused throttling before the 120TB monthly allowance is exceeded, because a similar condition does not exist for the cheaper "vserver" product line. There it's "exceed 80TB and be throttled", no ifs and buts.
-
Änderungen können an vielen Stellen auftreten, bei deinem Kunden wie auch bei den Empfängern. Eine Möglichkeit wäre z.B., dass dein Kunde kürzlich Spam verschickt hat, oder etwas, was die Empfänger so einordnen. Das kann wissentlich oder unwissentlich passiert sein. Eine andere Möglichkeit ist, dass Mailadmins ihre Anforderungen an eingelieferte Mail verändert haben. Leider sind gerade die Betreiber großer Mailsysteme sehr willkürlich, was sie über die Einhaltung technischer Standards hinaus noch verlangen, und ändern die Regeln ohne Ankündigung oder Erklärung. Der Betrieb eines (sendenden) Mailservers ist deshalb keine Sache, die man nebenbei macht, wenn Mail zuverlässig zugestellt werden soll. Die Empfehlung, mindestens "wichtige" Emails über einen Smarthost eines professionellen Mailanbieters zu verschicken, wurde deshalb ja schon gegeben.
Ein Mailserver in einem IP-Adressbereich eines Massenhosters, der von vielen anderen Admins mit mehr oder weniger gutem Sicherheits-Know-How genutzt wird, ist immer ein Risiko. Es ist quasi nicht möglich, ein Listing bei trigger-happy DNSBLs mit Sippenhaft wie UCEProtect zu vermeiden, ohne die Freiheit der Serverkunden massivst einzuschränken.
-
Terminus technicus: Hexspeak.
-
Man sollte nicht glauben, dass man fehlende Konsequenz gegen einen menschenverachtenden Schlächter, der dabei ist, hunderttausende Menschen ermorden zu lassen, um seine territorialen Großmachtphantasien durchzusetzen, damit rechtfertigen kann, dass die Welt auch sonst nicht gerecht ist. Das ist im besten Fall eine Ausrede, aber dafür gibt es sicher keinen Freispruch. Dass man mit dem Nachplappern der Relativierungen der russischen Propaganda auf den Leim geht, entschuldigt diesen Fehler nicht. Gerade in Deutschland, wo viele Unternehmen Profiteure der abscheulichsten Vergangenheit waren, sollte mehr Konsequenz selbstverständlich sein. Dass sie das immer noch nicht ist, lässt tief blicken.
-
Auf die deutsche moralische Flexibilität ist Verlass. Euer Verhalten ist einkalkuliert.
-
Dann bitte bei den USA anfangen!
Whataboutism kannst du stecken lassen. Wer Russen beliefert ist bei mir unten durch.
-
Dass es deutsche Unternehmen gibt, die diesen Schritt noch nicht schon lange gemacht haben, sondern russische Abnehmer immer noch direkt oder indirekt mit Gütern und Infrastruktur versorgen, ist eine Schande für Deutschland. Ich dachte, sich mit Waffengewalt Länder einzuverleiben und deren Bevölkerung abzuschlachten, wäre in Europa etwas für den Geschichtsunterricht, nicht aus wirtschaftlichen Gründen tolerierbare "Politik". Solidarität mit den Gekündigten ist nicht angebracht.
-
Mein anderer Serverprovider hat mich vor der Zwangseinführung von 2FA mit ausreichender Reaktionszeit informiert. Fand ich besser.
So wie 2FA meistens eingesetzt wird, ist das nur nervtötend aber kaum ein Sicherheitsgewinn. Selbstverständlich landet das Secret als weiteres Passwort im Passwortmanager. Wie schon mehrfach geschildert gibt es operative Anforderungen, die mit einem einzelnen Hardwaretoken für einen Account nicht zu erfüllen sind, solange es nicht wenigstens ein System mit mehreren Unteraccounts und Rechteverwaltung gibt.
BOFH: "Wir haben Sie zur Sicherheit von der Benutzung Ihres eigenen Accounts ausgeschlossen."
-
Die CNAME Records kannst du bei S. genauso anlegen. @ ist ein Platzhalter für die Domain selbst (z.B. deine-domain.example, ohne www). Die entsprechenden Einträge legst du bei S. also direkt für die Domain an. * ist ein Wildcard Eintrag, der für alle Subdomains gilt, die keine anderen Einträge haben, zb. irgendwas.deine-domain.example und asdf1elf.deine-domain.example. Das geht bei S. nicht, aber vielleicht reicht es, wenn du die Subdomains, die du tatsächlich benutzt, als Subdomains anlegst. Dann kannst du für diese Subdomains auch DNS-Einträge machen.
-
Geht nicht. Du kannst aber mit -t die Ausgabe von Set-Inhalten unterdrücken.
-
Ich hatte die IP Adresse, die diesen PTR hat, schon vor 15 Stunden genannt. Seitdem sind mehrere Kommentare dazu gekommen, die die Domain falsch schreiben und Adressen analysieren, die diesen PTR nicht haben, und dann fragst du nach der IP. DESHALB habe ich die Adresse groß geschrieben. Vorher war sie ja offensichtlich nicht lesbar. Und jetzt hat eine Netcup IP-Adresse auch diesen PTR. Als jemand, der auch eine Netcup-IP-Adresse hat, sage ich "Herzlichen Dank" dafür.
-
Stellt sich hin und pinkelt demonstrativ in den Pool und das wird auch noch lustig gefunden? ICH würde meiner IP-Adresse nicht den gleichen PTR geben wie eine IP-Adresse, die im Internet unangenehm auffällt, aber wenn's Spaß macht...
-
-
-
Das geht so wie verlangt nicht. Wenn der DNS-Eintrag auf den VPS zeigt, läuft der Traffic dort auf. Für bestimmte Protokolle gibt es die Möglichkeit, Umleitungen zu realisieren, z.B. HTTP-Redirects. Dann muss der VPS jeweils nur eine kurze Antwort schicken und kann die eigentliche Arbeit und den Datenverkehr einem anderen Server überlassen. Für andere Protokolle, z.B. SSH, gibt es solche Möglichkeiten nicht. Mit einer "Umleitung" durch einen Reverse Proxy laufen die Daten dann komplett durch den VPS.
Du könntest selbst einen DNS-Server betreiben. Das wäre eine Möglichkeit, die Verzögerung durch die nicht in Echtzeit stattfindenden Updates der DNS-Einträge zu umgehen. Auf einem eigenen Server könntest du auch eine extrem kurze DNS-TTL verwenden. Allerdings gibt es etliche Resolver, die für das Caching Mindestwerte ansetzen und noch kürzere TTLs ignorieren. Eine "sofort"-Lösung ist das also nicht. Wenn du Kontrolle über die Clients hast, kannst du Caching dort unterbinden.
