Beiträge von Askaaron

    Die Einstellung für "Client certificates" muss auf "Ignore" bleiben. Ansonsten will der Server nämlich, dass Browser sich mit einem Client-Zertifikat melden.


    Wie von Nafi erläutert, muss man statt dessen das Zertifikat einer Website zuweisen. Und man muss die Website über ihren Namen aufrufen, für den das Zertifikat ausgestellt wurde.

    Ich kann hierzu nur sagen, dass ich mit dem Support von Netcup noch nie Probleme hatte. Auch kompliziertere Probleme bei der Einrichtung einer Failover-IP in Kombination mit einem älteren Server wurden zufriedenstellend gelöst.


    Möglicherweise gab es ein Mißverständnis in der Kommunikation - und das führt dann schnell zum Eindruck, dass der Support keine Ahnung hätte oder sich nicht richtig bemüht. Daher auch von mir die Bitte, solche Behauptungen konkret zu belegen, damit man sieht, was genau schiefgelaufen ist. Eine allgemeine Unmutsbekundung hilft niemandem weiter.

    Momentan sind ja einige Videokonferenzdienste überlastet. Da ich in nächster Zeit eine Konferenz mit c.a 25 Teilnehmern veranstalten muss, habe ich mich nach einer Lösung auf dem eigenen RootServer umgeschaut. Da ich dort Nextcloud schon installiert hatte, ist Nextcloud Talk (auf WebRTC basierend) als einfachste und schnellste Möglichkeit. Da mein Server relativ wenig Power hat, bin ich mir nicht sicher, ob mein Vorhaben überhaupt möglich ist, bzw. ob es sogar schon Erfahrungen gibt.

    Sollte mich nicht alles täuschen, ist WebRTC peer-to-peer basiert, also die Serverpower nicht so stark ausschlaggebend. Also wäre das größte Problem eigentlich die heimische Internet der Teilnehmer?

    Hättet ihr sonst noch Alternativen (am Besten Browser-basiert)?


    Server: RS 500 SAS G7SEa1


    Ich betreibe Nextcloud inkl. OnlyOffice und Talk selber schon länger für aktuell ca. 60 Nutzer. Nextcloud "Talk" in Kombination mit coturn läuft hier recht problemlos auch mit Video. Die Teilnehmer sollten halt aktuelle Browser und eine ausreichende Anbindung von mindestens 2 MBit/s Upstream haben.


    Bei mir läuft Nextcloud allerdings auf einem RS 4000 SAS G7SEa3 (24 GB RAM, 8 Kerne), wo aktuell aber auch rund 40 Websites und ein größerer Mailserver mit Dovecot/Postfix läuft. Nextcloud alleine dürfte auch mit weniger auskommen. Ob ein Server mit 3 GB RAM und 2 CPU-Kernen ausreicht, hängt wohl von dessen aktueller Auslastung ab. Wenn das nur für Nextcloud gedacht ist, könnte es reichen, aber zusätzlich zu bestehenden Websites etc. eher nicht.


    Zu der Teilnehmerzahl:

    Nur mit Nextcloud alleine (und ggf. coturn, damit auch User hinter NAT-Routern keine Probleme haben) würde ich mit nicht mehr als 5-6 Teilnehmern einer Videokonferenz rechnen, wenn man keinen Signalling-Server betreibt (Nextcloud warnt auch, wenn mehr als 4 User verbunden sind und in den Nextcloud-Talk-Einstellungen kein Signalling-Server eingetragen ist). Mangels Bedarf habe ich das selber noch nie eingerichtet, aber https://github.com/saltyrtc/saltyrtc-server-python soll dafür geeignet sein und kann in Nextcloud genutzt werden.


    Ansonsten wäre "Zoom" (https://zoom.us/) eventuell eine Alternative - für 40 Minuten mit bis zu 100 Teilnehmern kostenlos, ansonsten dauerhaft mit einer monatlichen Gebühr nutzbar. Das ist zwar teurer als dein Server, aber immer noch gut bezahlbar, wenn man das nur für einen Monat mietet. Und man muss ich vor Allem nicht selber darum kümmern, dass die Technik läuft. Wenn das nur eine einmalige Aktion ist, würde ich da gar nicht erst anfangen mit einem eigenen Server.

    Bisher habe ich da keine Einstellungen gefunden, wie ich die Seite auf dem Server absichern kann, z.B. würde ich gerne Geoblocking machen. Ist das so, dass man das alles innerhalb von WordPress selbst mit Plugins machen sollte oder habe ich eine Möglichkeit bei Netcup übersehen?


    Geoblocking hat mit "Sicherheit" nichts zu tun. Ein Server wird nicht sicherer davon, dass man den Zurgiff aus bestimmten Regionen unterbindet. Zudem ist eine Zuordnung von IP-Adresse zu Region mitunter sehr ungenau und eine Sperre kann auch legitimer Besucher treffen. Ich würde das nicht machen.


    Der Weg zum sicheren Betrieb einer Website ist auch nicht, sie nachträglich abzusichern, sondern von vorne herein nichts einzurichten, was unsicher ist, also konkret:

    1. Sichere Passwörter vergeben (Länge ist wichtiger als Komplexität).
    2. Jede verwendete Software immer aktuell halten - je länger eine Sicherheitslücke bekannt ist, desto wahrscheinlicher wird es, dass sie auch ausgenutzt wird.
    3. Keine AddOns verwenden, die schon länger keine Updates mehr bekommen haben (also nichts, was z.B. zuletzt vor 1 oder 2 Jahren aktualisiert wurde und nicht mal mit WordPress 5 getestet wurde)
    4. Keine selbstgebastelten PHP-Scripte oder Anpassungen in functions.php oder im Theme verwenden, die man womöglich nur per Copy&Paste aus irgendwelchen "Tipps & Tricks zu WordPress" übernommen hat, aber selber nicht wirklich versteht.
    5. Funktionen, die man nicht braucht, abschalten - also z.B. Kommentare, Pingback, Trackback, RSS-Feed, RPC-Schnittstelle.

    Danke für die Tipps.


    Eine offizielle Rückmeldung vom Support zum Stand der Migration habe ich zwar noch nicht erhalten, aber hdparm -tT /dev/sda liefert jetzt um die 60-80 MB/s, was für mich vollkommen akzeptabel ist. Vermutlich ist der Umzug erledgt und ich wurde nur nicht benachrichtigt.


    Kleiner Nebeneffekt: ich überwache die Kiste auch mit netdata und hatte bislang regelmäßig eine Warnung wegen verworfener Netzwerk-Pakete. Eine Anpassung der Kernelparameter (speziell net.core.netdev_budget etc.) hat zwar die Häufigkeit der Warnungen reduziert, aber ganz wegbekommen hatte ich das nie. Seit gestern Abend treten diese Warnungen nicht mehr auf, ohne dass ich etwas geändert hätte.

    Eine Defragmentierung ist für mich keine echte Option, weil das eine Downtime von mehreren Stunden bedeutet. Der Server wird aber produktiv für mehrere gut besuchte Websites und Postfächer für mehrere dutzend Personen genutzt und mehr als 10-20 Minuten Downtime am Stück sind immer ein Problem.


    Mittlerweile hatte ich Kontakt mit dem Support und mir wurde angeboten, die VM auf einen anderen Node zu migrieren, wobei das im laufenden Betrieb ohne nennenswerte Downtime möglich sein soll. Dem habe ich zugestimmt und warte die Rückmeldung ab, wenn das durchgeführt wurde.


    Zu diesem Anlass:


    Gibt es bei Netcup die Option, mehrere Server als Ausfallsicherheit zu betreiben? Also z.B. extern nur eine IP-Adresse und Forwarding auf die erste Maschine, die erreichbar ist? Dann könnte man ggf. einen Server in Ruhe warten während der Betrieb von einer zweiten Maschine fortgeführt wird. Die Synchronisierung der Daten zwischen den Maschinen wäre für mich kein Problem.

    Ich bin mittlerweile schon eine ganze Weile Kunde bei Netcup und habe u.A. auch einen KVM-Server (RS 4000 SAS G7SEa3). Anfangs lief der Server auch wirklich flott, aber seid einiger Zeit fällt mir auf, dass die HDD-Performance sehr schlecht ist.


    Die Umgebung ist Ubuntu 16.04 LTS, die Festplatte ist laut SCP als "SCSI" eingebunden, was auch empfohlen wird.


    Konkret gemessen mit hdparm -tT /dev/sda komme ich kaum über 20 MB/s Lesegeschwindigkeit. Ja, ich habe vor dem Test auch alle Dienste beendet, die potentiell die HDD beanspruchen könnten (MariaDB, Apache, PHP-FPM, Dovecot etc.). Das Ergebnis ist wie zu erwarten, dass alle Aktionen, die Zugriffe auf Dateien oder Datenbanken benötigen, die noch nicht im Cache liegen, extrem langsam sind. :(


    Auf anderen Servern, die ich für Freunde bei Netcup betreue, werden problemlos mindestens 100 MB/s erreicht, teilweise auch mehr als 300 MB/s. Grundsätzlich geht es wohl - aber offenbar ist der Storage-Bereich, an dem mein Server hängt, mittlerweile durch andere Maschinen so ausgelastet, dass nur noch wenig Leistung übrig bleibt. Die wöchentliche Datensicherung mit backup2l, die vorher in 1-2 Stunden erledigt war, braucht mittlerweile fast 8(!) Stunden - und das für gerade mal etwas über 90 GB Daten.


    Mit ist klar, dass es immer Schwankungen geben kann und ein gemeinsamer Storage für alle KVM-Server zwangsläufig nicht jeden Server immer mit maximaler Leistung bedienen kann. Aber wenigstens 50-100 MB/s lesend im Mittel wären schon wünschenswert.

    Ich bin selber schon länger zufriedener Kunde mit einem Root-Server bei Netcup und habe im Laufe der Zeit auch schon zwei weiteren Nutzern Server bei Netcup empfohlen, so dass insgesamt bereits vier Root-Server bei Netcup durch meine Initiative vermietet sind. Für die Domainverwaltung verwende ich persönlich allerdings einen anderen Anbieter, den ich schon länger kenne als Netcup und was mir die Freiheit gibt, Server-Hosting und Domainverwaltung zu trennen.


    Nun stand bei einer Kundin von mir an, mehrere Websites von unterschiedlichen Hostern zu einem gemeinsamen Paket bei nur noch einem Hoster umzuziehen - auch da dachte ich spontan erstmal an Netcup, wegen der bisher guten Erfahrungen mit Root-Servern. Leider hat sich dieses Unterfangen als ziemlich "hakelig" herausgestellt:


    1. Fallstricke bei der Beauftragung eines Wehosting-Pakets


    Wenn man ein neues Webhosting-Paket mit 6 inklusiven .de-Domains beauftragt, ist in dem entsprechenden Formular keine Plausibilitätsprüfung vorgesehen, dass man bei den Domainname irrtümlich ".de" mit eingibt. Ich hatte mich zwar gewundert, wieso die AUTH-Codes für den Transfer bereits existierender Domains nicht gleich abgefragt werden, aber habe das erstmal so hingenommen.


    Tatsächlich wurde bei Eingaben der Punkt in ".de" einfach ignoriert und "de" Teil des Domainnamens. So wurde dann aus "example.de" im Eingabefeld die Beauftragung der Domain "examplede.de". Zu sehen war das Maleur aber auch nicht - dann bevor man im Kundencenter sieht, welche Domains effektiv beauftragt wurden, muss man erstmal die Vorauszahlung für ein Jahr leisten. Mag sein, dass man die Domainliste direkt vor dem Absenden des Auftrags noch sieht - aber dass aus ".de" ein "de" als Teil des Domainnamens wird, damit rechnet man eben nicht.


    Es wäre schön, wenn sowas künftig abgefangen wird - denn ja, als Kunde rechnet man nicht damit, dass man die TLD nicht eingeben darf und dass Fehleingaben so kreativ "umgeformt" werden. Und es wäre auch schön, wenn man bereits bei der Auftragsbestätigung auch nochmal die Liste der effektiv beauftragten Domains sehen kann - bevor man die Vorauszahlung für ein Jahr leistet.


    Immerhin - nach Rücksprache mit dem Support konnte das bereits bezahlte Paket storniert werden und noch einmal neu mit den korrekten Domains beauftragt werden, ohne dass weitere Kosten angefallen sind.


    2) Fallstricke beim Domaintransfer


    Beim zweiten Anlauf wurde nun bereits bei der Beauftragung korrekterweise auch die Eingabe des AUTH-Codes für den Transfer existierender de-Domains verlangt. Allerdings sind diese Angaben offenbar verloren gegangen. Es endete damit, dass im Kundencenter die de-Domains tagelang im Zustand "wird bearbeitet" waren, ohne dass ersichtlich war, warum es eigentlich nicht weitergeht - auch kein Hinweis auf fehlende AUTH-Code.


    Eine telefonische Anfrage beim Support ergab nur sinngemäß die Auskunft, dass Netcup da auch nichts machen kann, aber man sollte dennoch mal ein Ticket im CCP öffnen.


    Das habe ich dann auch getan. Dann kam die schriftliche Auskunft, dass für den Domaintransfer keine AUTH-Codes angegeben wurden und man diese noch eingeben muss. Aber wo denn? Im CCP kann man nirgends AUTH-Code eingeben! Also nochmal telefonisch nachgefragt und da wurde dann erklärt, dass es in der Tat im CCP keine Möglichkeit gibt, AUTH-Codes einzugeben und man die Code per E-Mail schicken muss.


    Nun also nochmal eine E-Mail mit den AUTH-Codes geschickt - der Transfer sollte nun erfolgen.


    Positiv: wenn man möchte, kann man E-Mails auch verschlüsselt mit GPG schicken - im Wiki findet man unter https://www.netcup-wiki.de/wiki/GPG den Key dafür.


    Fazit


    Das System zur Beauftragung von Webhosting-Paketen hat noch einiges an Verbesserungspotential:


    1. Eingabefelder für Domainnamen sollten immer prüfen, ob unerlaubte Zeichen vorkommen und diese nicht einfach ignorieren! Wenn man "example.de" eingibt, obwohl ein Punkt im Name nicht erlaubt ist, dann sollte der Punkt nicht einfach gelöscht werden, sondern die Eingabe sollte abgelehnt werden - ggf. mit dem Hinweis, dass nur der Name ohne TLD (.de) anzugeben ist.


    2. Wenn man vorhandene Domains umziehen will in ein neues Webhosting-Paket, muss man auch AUTH-Codes angeben. Wieso diese Eingabe nicht im System angekommen ist, weiß nicht nicht. Aber selbst wenn es möglich sein sollte, einen Domaintransfer ohne AUTH-Code zu beauftragen - im CCP sieht man weder, dass AUTH-Codes fehlen, noch kann man diese dort nachträglich eingeben. Das sollte unbedingt geändert werden. Wenn Domains noch nicht endgültig eingerichtet sind, muss da auch stehen, warum das nicht so ist - also ob der Transfer bereits in Arbeit ist oder ob noch etwas fehlt, um den Transfer durchführen zu können.

    Askaaron sicher? Soweit ich weiß ist es erlaubt und gängige Praxis, das der Wert des MX RR einen Eintrag wie mail.domain.de enthält. Lediglich mail.domain.de darf dann kein CNAME sein, sondern muss ein A-RR sein.

    Wobei in der RFC 2181 anscheinend tatsächlich das erwähnt wird, was du sagst, hatte ich das so noch nie vorher gehört geschweige denn Probleme damit bekommen.


    Genau das meinte ich - das worauf der MX verweist, sollte kein CNAME mehr sein, sondern ein A/AAAA-Record.


    Also NICHT:


    MX mail.my.example

    mail.my.example CNAME my.example


    Sondern das hier (beispielhaft 127.0.0.1 / ::1 - natürlich muss der echte Eintrag die richtigen Adresse haben):


    MX mail.my.example

    mail.my.example A 127.0.0.1

    mail.my.example AAAA ::1

    Done. Und die anderen gelöscht. Hm, nächste dumme Frage (nein, es gibt keine dummen Fragen, nur dumme Antworten oder gar keine): ;) Der Nameserver von netcup (empfohlene Defaulteinstellung im CCP) ist ja nicht der einzige im Netz - wie kriegen das die anderen mit?


    Durch die "NS"-Einträge in der Domain - da steht nämlich drin, welcher Nameserver für die Domain zuständig ist und da fragen alle anderen Nameserver dann nach, wenn sie die Daten noch nicht haben. Und diese Daten werden dann bei den anderen Nameservern solange gespeichert, wie im "TTL"-Eintrag angegeben ist ("Time To Live" in Sekunden).


    Beispiel:


    Mein eigener Nameserver geht davon aus, dass für "hkraus.eu" aktuell die IPv4-Adresse 46.38.243.234 gilt (A-Record) und dass die zuständige Server dafür root-dns.netcup.net, second-dns.netcup.net und third-dns.netcup.net sind. Die sind alle gleichberechtigt. Es gibt nur mehrere, damit im Fall einer Störung noch ein zweiter (oder dritter) Server einspringen kann. Falls ein Server nicht antwortet, wird eben der nächste Server befragt:


    https://arnowelzel.de/tools/dns-abfrage?dns_domain=hkraus.eu


    (PS: nein, mein Nameserver ist nicht "arnowelzel.de" - das ist nur die Website, mit der man den Server abfragen kann).


    Der TTL dafür ist aktuell, wo ich das hier schreibe, bei etwa 47000 Sekunden, d.h. mein Nameserver wird diese Daten für etwas über 13 Stunden als gültig erachten und erst danach wieder die in den "NS"-Einträgen angegebenen Server befragen. Wenn man die Abfrage aktualisiert, kann man auch zusehen,wie die TTL immer weniger wird.


    Stellt sich noch die Frage, woher die Daten kommen, wenn ein Nameserver noch gar nichts über die Domain weiß?


    Dann fragt ein Nameserver die Server die für die DNS-Root-Zone zuständig sind. Die ermitteln dann zuerst, wer ".eu" verwaltet und dann, wer für "hkraus.eu" zuständig ist, womit wir dann am Ende wieder bei root-dns.netcup.net, second-dns.netcup.net und third-dns.netcup.net landen.

    Guten Morgen,


    ich bin seit gestern netcup-Kunde und mit meiner Domain hkraus.eu hierher umgezogen. Wie kann ich jetzt die Domain der IP-Adresse meines vServers zuweisen? In meinem CCP steht erst einmal "Zugewiesenes Hosting unbekannt".


    Danke im voraus für zielführende Hinweise.



    Für jede Domain gibt es einen zuständigen Nameserver, der vom Server des eigenen Internetproviders befragt wird - und genau da ist die IP-Adresse als "A" (IPv4) und "AAAA" (IPv4) einzutragen. Die relevanten Daten von "hkraus.eu" sind wie folgt:


    (siehe auch https://arnowelzel.de/tools/dns-abfrage?dns_domain=hkraus.eu)


    A - 46.38.243.234

    NS - third-dns.netcup.net

    NS - root-dns.netcup.net

    NS - second-dns.netcup.net

    MX - mail.hkraus.eu


    Und der Eintrag im MX - "mail.hkraus.eu" sieht wie folgt aus:


    (siehe auch https://arnowelzel.de/tools/dn…dns_domain=mail.hkraus.eu)


    mail A - 193.30.123.82


    Die "NS"-Einträge geben den aktuell zuständigen Nameserver an - das sind Nameserver von Netcup. Also müssen man offensichtlich im CCP von Netcup die entsprechenden Einträge nach Bedarf vornehmen. Wie das im CCP genau aussehen muss, bin ich überfragt, da ich selber keine Domains bei Netcup habe, nur Server. Meine Domains liegen alle bei einem anderen Anbieter (ohne Hosting), den ich vorher schon hatte.


    Ich nehme aber an, es gibt auch im CCP entsprechende Felder, wo man angeben kann, welche IP-Adresse der Domain "hkraus.eu" zugewiesen werden soll und ob noch Subdomains eigene Adressen bekommen sollen. Ggf. sollte man auch noch die IPv6-Adresse ergänzen, falls der Server auch über IPv6 erreichbar sein soll.


    Wenn man etwas ändert, dauert es je u.U. bis zu 24 Stunden, bis alle Nameserver weltweit die Änderung auch übernommen haben. Will man künftig nicht so lange warten, kann man den "TTL"-Wert (Time To Live) entsprechend ändern. Ich habe da z.B. 3600 für eine Stunde (60*60 Sekunden) eingetragen. Deutlich kürzere Zeiten sind meist nicht sinnvoll, da nach Ablauf der TTL die Server der Internetprovider die ermittelte Information als veraltet betrachten und dann den zuständigen "Originalserver" befragen. Das sollte aber eben nicht permanent passieren. Daher ist eine TTL von wenigstens 30-60 Minuten sinnvoll.


    Außerdem:


    Der MX ist der "Mail Exchange" - also der für die Domain zuständige Mailserver. Auch hier muss natürlich die richtige Adresse als A-Record bzw. optional IPv6 mit AAAA eingetragen werden.


    Der Vollständigkeit halber: Gemäß RFC 2181 sollte ein MX eine IP-Adresse haben. Ein CNAME-Record wird nicht empfohlen, auch wenn das manche Leute so handhaben!


    Als Beispiel, wie die Einträge am Ende sinngemäß aussehen sollten (speziell A und MX), nochmal arnowelzel.de:


    (siehe auch https://arnowelzel.de/tools/dn…?dns_domain=arnowelzel.de)


    A - 185.194.142.147

    AAAA - 2a03:4000:1c:2fe:a93f:37e9:8dd9:55e6

    MX - mail.0x0c.de


    mail.0x0c.de ist ein eigener Server der natürlich auch eine eigene Adresse innerhalb von "0x0c.de" hat:


    (siehe auch https://arnowelzel.de/tools/dn…e?dns_domain=mail.0x0c.de)


    mail A - 46.38.230.151

    mail AAAA - 2a03:4000:1c:2fe:a93f:37e9:8dd9:55e7