Das längste Thema

    Zitat von Cictani

    Was würde eigentlich passieren, wenn die USA jetzt ein eigenes Datenschutzgesetz herausbringt, das auch für Firmen in Europa verpflichtend ist, aber im Widerspruch zur DSGVO steht?

    das wäre dann ein Datenschleudergesetz :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Bildschirmfoto_2018-08-08_19-53-53.pngDa debuggt man ein Problem irgendwo zwischen OpenDKIM/DNSSEC/Unbound/iptables und verwechselt beim Testen die Nicht-DNSSEC-Domain mit der DNSSEC-Domain. Ganz großes Kino, wenn man sich wundert, warum der Key immer noch nicht "secure" ist… ||


    Wenn dann zusätzlich die DNS-Server des Domainregistrars nicht synchron sind (siehe Screenshot) und man das nicht gleich merkt, wundert man sich noch mehr über ein Verhalten, das alle paar Minuten anders ist…


    Jetzt muss ich nur noch rausfinden, warum sich OpenDKIM nicht mit meinem lokalen Unbound verträgt.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    zum Thema WHOIS und DSGVO; man bekommt ja im WHOIS keine persönlichen Daten mehr;


    gilt dies nur f. uns EU-Bürger oder ist das jetzt generell so?


    gibt ja WHOIS-Sites wie Sand im Beton, und dort probierte ich bei meiner .info-Domain,

    die Site selbst (https://www.whois.com) ist eindeutig in den USA, aber da waren

    gecachte Infos, welche meine Daten noch enthielten; nach einem Refresh nicht mehr;

    und das selbe mit einer "Zufall"-Domain eines US-Bürgers, über einen ebenfalls in den USA ansässigen Registrars;


    jetzt die Frage: hat jemand einen virtuellen Server in den USA oder außerhalb der EU, und kann dort das verifizieren?

    die "Zufall"-Domain = 123.info;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    mainziman Es kommt auf die Registry an was noch angezeigt wird, ob es Opt-In Möglichkeiten gibt, ob es einen Registrar Whois gibt (der steht im Registry Whois) und ob dieser dann noch Daten anzeigt. In der Regel bekommt man jetzt bei allen fast nix mehr zu sehen. Aber es kann auch Ausnahmen geben.

    Bei einer LI Domain (nicht über netcup registriert) sehe ich z.B. noch immer Name sowie Anschrift. Da hat sich nichts geändert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    KB19 interessant;

    LI wie Liechtenstein ist eigentlich außerhalb der EU - haben die Liechtensteiner diese DSGVO übernommen?

    wobei bei den TLDs wie info, net, com ist ja gar kein expliziter EU-Bezug ...:/

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Was für ein wunderbarer Tag heute....


    Vorgeschichte:

    - managed Server bestellt für Umzug von ein paar Webseiten bestellt

    - paar Tage später wollten wir den einrichten, Server nicht erreichbar weil schonmal der erste Ausfall


    Heute:

    - privater vServer bei Konkurrenz war heute ein paar Minuten nicht erreichbar

    - Bei der Bahn gingen dann keine Türen auf

    - Backupleitung war nachts kurz weg

    - Heute um 10 ein paar Domains zu netcup umgestellt. Kunde: Da ist nichts erreichbar. Schon wieder?! Zeitgleich: Andere Webseiten bei anderen Providern auch down (andere RZ kurz ohne Strom)

    - VPN tot

    - Nachdem alles wieder geht, meint der FF auf dem Monitoring-System plötzlich: Kann kein DNS mehr. Alles andere auf dem Monitoring-System läuft. #214625 -
    DNS: long lines in /etc/hosts breaks all dns lookups - Opened: 2003-07-31. Last comment: I think the imapct of the bug is low though - so marking backlog"

    "Security is like an onion - the more you dig in the more you want to cry"

    Zitat von vmk

    long lines in /etc/hosts breaks all dns lookups

    Wer oder was erzeugt denn in der Praxis lange Zeilen in /etc/hosts, anstatt die Einträge dort zu minimieren und redundante/einheitliche DNS-Server einzusetzen?

    Sind solche Ereignisse nicht willkommene Steilvorlagen, damit ein für allemal aufzuräumen?

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Die Namen in der /etc/hosts sind zum Testen der neuen Live-Umgebung dort gelandet. Und das Monitoring will man ja auch vor dem Umschalten schon gegen die neue Umgebung testen. @m_ueberall: Wie testest du bei einem Serverumzug ob deine Webseiten auf dem neuen Server auch sauber funktionieren?

    "Security is like an onion - the more you dig in the more you want to cry"

    Zitat von vmk

    @m_ueberall: Wie testest du bei einem Serverumzug ob deine Webseiten auf dem neuen Server auch sauber funktionieren?

    Gerade, indem ich durch Kontrolle der/des DNS-Server(s) dafür sorge, dass bei (back-to-back-)Testläufen wie gewünscht entweder die alten oder die neuen Server von einer/mehreren Testmaschine(n) auf der Client-Seite angesprochen werden.


    Im "einfachsten" Fall bei entsprechender vorhandener Konfiguration sind hierzu weder bei den neuen Servern noch bei den dedizierten Maschinen irgendwelche Änderungen vorzunehmen (sofern etwa BIND Views o.ä. zum Einsatz kommen, vgl. diese Diskussion) – d.h. man definiert Server-Zonen und/oder Gruppen von Clients zu Testzwecken, die von denselben im Einsatz befindlichen DNS-Servern bei identischen Anfragen zu unterschiedlichen Auflösungen führen (aber wirklich nur kontrolliert bei den Test-Clients); nachdem die Tests erfolgreich absolviert wurden, werden die Testeinträge die neuen global gültigen.


    Alternativ kann man aber auch einfach auf Testmaschinen einen temporären, zusätzlichen DNS-Server ansprechen, welcher einfach die alten mit den zu testenden Einträgen überschreibt und alle anderen Anfragen einfach an bestehende DNS-Server weiterreicht. Das ist nicht wirklich komplexer in der Konfiguration, aber "robuster" (nicht alle Anwendungen scheren sich unbedingt um Einträge in der /etc/hosts) und IMHO weniger fehleranfällig, weil man hierbei nur den Eintrag des DNS-Servers oder die Suchdomäne (letztere Modifikation nur bei vereinfachter Umsetzung des o.g. Ansatzes; mit Einschränkungen verbunden, IMHO nicht zu empfehlen) o.ä. anpassen muss, je nach gewählter Strategie der Identifikation von Testmaschinen. (Wie gesagt, bei entsprechender Planung/Aufsetzung der Infrastruktur wie im vorherigen Absatz muss man Client-seitig gar nichts ändern.)


    Eine weitere Alternative wäre das Vorsehen von "floating IPs" für die Dienste über welche man Back-to-back-Tests laufen lässt (oder man definiert grundsätzlich parallele Test-Präfixe, etwa "www-test" statt "www", welche von den Servern gleich behandelt werden, aber durch DNS-Eintragsänderung eben gesteuert bei den alten/neuen Servern landen und möglichst nicht von aussen zugänglich sind – also bspw. nur bei Zugriff über ein VPN bedient werden –, um Fehler zu vermeiden). Man muss wiederum nur sicherstellen, dass während der Testphase ausschließlich die internen Testmaschinen über diese "floating references" zugreifen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Danke für den ausführlichen Text mit Links und Abwägungen über die Nutzbarkeit! Das ganze klingt gut.


    Für meinen Fall ist das technisch nicht umsetzbar. Weder habe ich die DNS-Kontrolle noch kenne ich vorher unbedingt die Maschinen von denen getestet wird. Du gehst von einem dediziertem Testlabor mit eigener IT aus, oder? So was habe ich leider nicht zur Verfügung.

    "Security is like an onion - the more you dig in the more you want to cry"

    So, hab mich dann doch mal um ein halbwegs vernünftiges Monitoring gekümmert. Hab nun auf nem VPS Telegraf+InfluxDb+Grafana laufen und auf jedem VPS, root Telegraf.


    Funktioniert soweit ganz gut, die meisten metrics werden in eine zentrale influxdb geschrieben und dann eben in grafana grafisch dargestellt.

    Eine Hand voll metrics wird zusätzlich in andere influxdbs gepackt.


    Jetzt aber zu meinem Problem, ... irgendwie bekomme ich keine Docker Metrics. Warum nicht? Was mache ich falsch?


    Input sieht folgernder maßen aus:


    Und der Output so:


    Code
    [[outputs.influxdb]]
  database = "telegraf_docker"
  urls = [ "http://***:8086" ]
  username = "telegraf_docker"
  password = "***"

  ## Write timeout (for the InfluxDB client), formatted as a string.
  ## If not provided, will default to 5s. 0s means no timeout (not recommended).
  timeout = "5s"


    Egal ob so, oder noch mal gesondert mit namepass = ["*_docker"] im Input, bzw. name_suffix = "_docker" im Output, ...

    aber telegraf_docker bleibt leer, bzw. werden zumindest keine docker daten reingeschrieben


    Datensammeln via Telegraf hingegen scheint zu funktionieren:


    Code
    telegraf -test -config /etc/telegraf/telegraf.conf --input-filter docker

    Spuckt nen Haufen Infos aus, ...

    Hab auf dem Docker Host in etwa 20 Container laufen und hätte schon gerne nen Überblick, zumindest grob, cpu, ram, ntsta ...

    bin mit meinem Latein am Ende, wenn wer nen Tipp hat wäre ich echt dankbar!

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

    Zu Mittag hatte ich mal wieder ein ganz intelligentes Botnetz zu Besuch: Innerhalb von ca. einer Stunde versuchte es 1583 (!) mal auf den SMTP-Port zuzugreifen. Leider war das dahinterliegende Script so extrem blöd programmiert, dass es gar nicht gemerkt hat, dass es durch Postscreen gar nicht bis zur Authentifizierung kommt. Unabhängig davon, dass die Anmeldung auf diesem Port nicht angeboten wird… :D

    Code
    postfix/postscreen: CONNECT from [A]:55555 to [B]:25
postfix/postscreen: PREGREET 14 after 0.58 from [A]:55555: EHLO ylmf-pc\r\n
postfix/postscreen: HANGUP after 1.2 from [A]:55555 in tests after SMTP handshake

    Tja, schon blöd, wenn man die Serverantwort nicht korrekt abwartet. Die vermeintlich eingesparten Ressourcen dieser Aktion wurden halt lieber eine Stunde lang verschwendet, als gleich zu einem Server bzw. Port weiterzuziehen, der die Benutzeranmeldung erlaubt.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Hostet von euch jemand Minecraft Java Edition auf nem VPS/Root? Wenn ja: macht ihr das über screen/systemd oder ähnliches? Ich bastel im Moment eine Art Minecraft Server-Launcher + Konfigurations-GUI mit bash, dialog und screen und suche ein paar Leute zum Testen :)

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

    Zitat von mfnalex

    Hostet von euch jemand Minecraft Java Edition auf nem VPS/Root? Wenn ja: macht ihr das über screen/systemd oder ähnliches? Ich bastel im Moment eine Art Minecraft Server-Launcher + Konfigurations-GUI mit bash, dialog und screen und suche ein paar Leute zum Testen :)

    Hab minecraft auf nem RS1000 G7 SSD laufen. Aber nur bei Bedarf via multicraft on/off.

    Multicraft realisiert das ganze glaube ich via webUi und Bash.

    Für mich auf jeden Fall ausreichend. Gerade da ich mir damit keine Arbeit machen will.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...