Posts by tab

Ich hatte das bisher nur für Zertifikate, wo ich die entsprechende (Sub-)Domain zwischenzeitlich gelöscht hatte. Laut der Mail kann es aber auch passieren, wenn z.B. ein Zertifikat für die Domain ausgestellt wurde und später noch ein weiteres, das z.B. auch die www-Subdomain (oder andere, aber bei netcup geht es ja wohl nur mit der www-Subdomain vernünftig) mit abdeckt.

Ist auch kein globales netcup-Problem, habe gerade eine Mail von meinem Mailserver erfolgreich an meinen MS-Testaccount zugestellt bekommen.

Kleiner Tipp: Passwort erst mal ins Feld für den User eingeben, dann sieht man ob es mit dem getippten Passwort übereinstimmt oder ob irgendwelche Zeichen vertauscht werden.

Quote from rosenclosed

Auch der Satz: "Ja die E-Mail ist schon raus, bis die aber im andern Gebäude angekommen ist, kann das schonmal 2-3 Tage dauern" hat mir gezeigt wie es um Hebammen und Digitalisierung steht...

Also DAS nenne ich mal eine sehr schlechte Anbindung. Da brauchen die Daten wahrscheinlich schon eine Stunde, bis sie den PC durch das enge Netzwerkkabel verlassen haben. Oder wie es ein Kunde vor langer Zeit mal formuliert hat: Wir haben alles auf Computer umgestellt. Jetzt geht alles viel schneller, dafür dauert es länger.

Naja, die Domain hast du jetzt schon "käuflich erworben" bzw übernommen und auf eigene Kosten auf deinen Namen registriert. Damit bist du die Domaininhaberin. Falls du mit "Subdomain vermieten" meinst, dass andere deinen netcup-Webspace mit dieser Subdomain benutzen, bist du laut netcup AGB für einen eventuellen Missbrauch verantwortlich, wenn Du die Zugangsdaten weitergibst. Verboten ist es freilich nicht. Wenn du einem anderen Zugang zu deinem CCP/WCP gibst, kann der oder diejenige prinzipiell auch auf die Haupdomain und die anderen Subdomains zugreifen, deren Einstellungen und Inhalte verändern und jeden erdenklichen Blödsinn damit veranstalten. Und natürlich auch dafür sorgen, dass netcup dein gesamtes Webhosting bis auf Weiteres komplett sperren muss. Also darauf achten, wem Du diese Zugangsdaten gibst.

Wenn es nur um die Domain selbst und ihre Subdomains geht, also nur darum, deinerseits DNS-Einträge der (Sub-)Domain so zu setzen, dass die Subdomains auf einem anderen Webspace/Server genutzt werden können, sieht es natürlich etwas anders aus, aber eventuelle Abmahnungen wegen z.B. fehlendem Impressum oder falschen Kontaktdaten werden im Zweifel wohl trotzdem bei Dir aufschlagen, weil Du die Domaininhaberin bist.

Quote from michaeleifel

"SSD Performance"

Wie mans nimmt. Bei den IO-Geschwindigkeiten die hier letztens berichtet wurden, wäre Optane bestimmt deutlich schneller.

Und auch mal schauen, ob im SCP unter Netzwerk bei rDNS, IPv4 und IPv6, auch der gewünschte Servername drinsteht und nicht etwa "v220221271421999999.quicksrv.de"

Na, da bringt mir IPv6 doch mal einen Vorteil. Da hat sich mein Subnetz über Monate nicht geändert, während ich bei meinem DS-Lite über eine fixe IPv4 nicht verfüge.

Wer war das jetzt gleich wieder, der jetzt eigentlich Zerotier ins Spiel bringen müsste

Naja, die jail.local ist eigentlich dafür gedacht, dass man darin die Einstellungenen macht, die man eben anders haben will als es in der mitgelieferten jail.conf drinsteht. So ist es eben so updatesicher wie möglich. Steht zuviel drin und man behält die Datei dann auch so bei, wenn durch ein fail2ban-Update die jail.conf - aus möglicherweise guten Gründen - geändert wird, dann kommen diese Änderungen eben nicht zur Anwendung, weil sie in der jail.local mit den alten Werten, mit den Einstellungen aus einer Kopie einer alten jail.conf überschrieben werden. Man kann das auch noch verfeinern, indem man die Änderungen im Verzeichnis /etc/fail2ban/jail.d anlegt. Eine bei systemd gebräuchliche Methode. Bei mir ist da z.B. eine Datei defaults-debian.conf drin. Ich habe die nicht erstellt und sie tut nichts Anderes als das sshd-Jail zu enablen. Falls die Datei so auch bei dir existiert, weisst du dann auch gleich, warum dieses Jail bei dir enabled war, obwohl es in der jail.conf und jail.local nicht drinstand.

Welche jails sind denn tatsächlich aktiviert? Was sagt also

fail2ban-client status

Edit: Ich meine gleich nach dem Start, bevor sich fail2ban wieder beendet. Das hat ja laut Logifle eine gute Viertelstunde gedauert.

Steht irgendwas in der /var/log/syslog oder einer anderen Logdatei, was zu der Zeit passiert ist?

Edit2: Hast du vielleicht versehentlich unter [DEFAULT] alle jails aktiviert? Immerhin deutet der Fehler auf das selinux-ssh jail hin, das du ja eigentlich gar nicht aktiv zu haben glaubst.

Man merkt teilweise schon deutliche Unterschiede, zwischen Webhostings mit Datenbank auf dem localhost und mit Datenbank auf einem separaten Server, bei der Performance eines CMS wie Wordpress, TYPO3, Joomla, Contao ... Jedenfalls wenn die Seite nicht aus dem Cache genommen werden kann, sondern komplett neu aufgebaut werden muss. Und da geht es meist um vom Netzwerk verursachte Latenzen deutlich unter 1ms. Wenn du jetzt freilich bei einer Anwendung nur alle paar Sekunden einen Datenbankzugriff hast, dann wird so ein Unterschied gar nicht auffallen.

Quote from aRaphael

Naja, budcup.de wäre noch frei.

budcup.net wäre auch noch frei, wenn auch etwas teurer als die de-Domain

Also ich habe da so meine Zweifel, dass eine verschlüsselte Verbindung zum Datenbankserver aufgebaut werden kann. Macht man ja lokal meist schon nicht, weil es die Datenbankzugriffe langsamer macht und - hier im Shared Webhosting vielleicht noch wichtiger - der Datenbankserver mehr arbeiten muss. Wozu wird denn die Datenbank überhaupt gebraucht? Wenn Performance halbwegs wichtig ist, würde ich mir lieber lokal einen MySQL/MariaDB -Server installieren. Damit würden gleich mehrere Probleme hinfällig...

• Keine Verschlüsselung notwendig, es kommt kein externer an die Datenbank dran.
• Kürzere Zeit beim Aufbau einer Verbindung und auch bei der Übertragung von Daten (Webhosting ist nur mit 100 MBit angebunden, jedenfalls in der Theorie.
• Keine Ausfallzeit bei Änderung der externen IP.

Anders mag es aussehen, wenn die meisten Zugriffe über das Webhosting passieren und nur die Daten von Zeit zu Zeit von lokal abgefragt werden.

Das bedeutet schlicht, dass der Sender der Weiterleitung (=netcup SMTP-Server) laut dem SPF-Eintrag der Absenderdomain nicht berechtigt ist, E-Mails für diese Absenderdomain zu verschicken. Automatisches Forwarding ist halt nicht so "simpel" wie du denkst. Zumindest auf die Absenderdomain und ihren SPF-Record hast du schon mal in der Regel keinen Einfluss. Insofern bleibt eigentlich nur, dass "mx_von_Zieldomain" solche unauthorisierten Mails toleriert. Wenn du auf diesen Mailserver der Zieldomain auch keinen Einfluss hast und er solche Mails nicht durchlässt - wie es hier laut obiger Meldung der Fall ist - dann kann eine einfache Weiterleitung nicht gelingen, wenn die Absenderdomain darauf besteht, dass Mails mit dieser Absenderdomain von einem nicht zugelassenen Absender gelöscht werden sollen.

Quote from KB19

Hab's vor ca. zwei Stunden neu gespeichert, jetzt ist DNSSEC bei beiden Domains funktionsfähig

War übrigens meine Schuld: Ich Trottel habe den Record 1:1 von deSEC kopiert, anstatt nur den öffentlichen Schlüsselteil ins große Formularfeld einzufügen. Ich dachte fälschlicherweise, dass das CCP sich den benötigten Teil eh selbst extrahiert. Man sollte halt lesen, mit was die Felder beschriftet sind und was nach dem Absenden drinnen steht.

Warum das dann keine Fehlermeldung erzeugt, weiß ich nicht. Offenbar kommt es so ja auch nie bei der DENIC an. Wäre gut möglich, dass gestern aus diesem Grund die Nameserver nie übernommen wurden. Ich glaube da habe ich das genauso 1:1 eingefügt.

Schön, dass es jetzt geklappt hat. Ich denke, da sollte netcup eine Fehlerbehandlung einbauen, damit der Kunde merkt, dass er etwas Falsches eingegeben hat. In Formulare eingegebene Daten weiterzuverarbeiten ohne sie zu validieren, war noch nie eine gute Idee. Das mag an dieser Stelle vielleicht nicht 100% möglich sein, aber zumindest könnte das Formular einen Hinweis ausgeben, wenn Leerzeichen drin sind. Falls das in einem Key zulässig sein sollte, kann man ja eine Möglichkeit zur Bestätigung der Eingabe einbauen. Das würde dem Support wohl so einige Tickets ersparen.

Was sagt DNSviz zu der Domain beimm Thema DNSSEC?

Ich probier jetzt auch mal mein Glück. Habe noch eine nette Domain geschossen zu Ostern, vielleicht bekomme ich da ja auch mal die selben Probleme wie du. Die stelle ich mal auf meinen privaten Server ein und mit Nameserver bei deSEC. Mal sehen ob es klappt und falls ja, wie lange es dauert. Ich starte mal um 22:50 mit dem Eintragen der wichtigsten Records bei deSEC. Danach dann Nameserver umstellen und DNSSEC bei netcup eintragen

- Öffentlicher Schlüssel weiss ich noch nicht

- Flags: KSK (257)

- Algorithmus: ECDSAP256SHA256 (13)

Upps, schon gleich 2 Minuten Verspätung, los gehts.

Edit: So, jetzt heisst es erst mal warten, bis die Nameserver aktualisiert sind.

Edit2: Keine Ahnung was die DENIC schon weiss, aber Google (8.8.8.8) und Cloudflare (1.1.1.1) haben bereits den richtigen A-Record, der in netcups DNS auf geparkt stand. Mein Unbound auf dem Server zeigt die richtigen Nameserver. Also trage ich mal die DNSSEC Werte ein...

Edit3: Die Werte sind eingetragen, jetzt heißt es wieder warten. Ich gehe mal Geschirr spülen ...

00:14 Tadaa! DNSviz sagt, die Zone entenzeit.de ist SECURE, Unbound zeigt mir bei dig das ad Flag. That's it! Ich habe fertig!

Hm, 23 Jahre Mindestlaufzeit?

Quote from Valkyrie

ich bin nicht der größte Nginx Guru, aber ich glaube das sieht in Ordnung aus. Wirst du ja letztenendes bemerken
Aber willst du wirklich alles auf deine xyz.at umlenken? Die neue Domain ist also nur mehr oder weniger eine Weiterleitung?

In dem Fall dann das canonical Tag nicht vergessen im Header.

Quote from KB19

Wie lange dauert das eigentlich normalerweise, bis externe Nameserver bei einer Domain aus dem CCP bei der DENIC landen?

Vor mehr als 24h mit zwei (!) Testdomains ausprobiert und jetzt stehen noch immer die netcup NS drinnen und nicht die von deSEC. Hängt das wirklich gleich bei zwei Domains? Habe ich echt so viel Pech?

Ja, oder ich habe immer Glück. Nach 1-2 Stunden war bisher immer alles durch. Habe zwar nie bei der DENIC gecheckt, aner wenn DNSSEC laut DNSviz ohne Warnung funktioniert, dann muss wohl alles ordnungsgemäß eingetragen sein .