Beiträge von tab

    Wie sollen wir das klären? Wir kennen ja noch nicht mal die Domain und selbst wenn ...


    Ist es eine Inklusivdomain oder eine Zusatzdomain? Was hast du im DNS eingetragen? Richtige Syntax, also bei Host '@' für die Domain selbst , '*' für Wildcard Subdomains', 'sub' für sub.deinedomain.tld? Also jedenfalls nicht 'sub.deinedomain.tld' oder 'deinedomain.tld als Host eintragen, sonst gilt der Record für für deinedomain.tld.deinedomain.tld bzw sub.deinedomain.tld.deinedomain.tld. Dann kannst du lange warten bis das für (sub.)deinedomain.tld greift ^^;) . Wenn die korrekten DNS-Einträge nach mehreren Wochen immer noch nicht greifen, dann kann dir nur der Support helfen. Und nach so langer Zeit wird sich der Support da schwerlich mit der o.g. Aussage rausreden können. Ansonsten musst du das Ticket halt eskalieren.

    Bist du hier im richtigen Forum? Wenn es dir wirklich um einen vServer geht und nicht etwa ein Webhosting-Paket, dann ist der Server genau so installiert, wie du ihn eben installiert hast. Du hast da ja vollen root-Zugriff.

    Naja, der größte Unterschied zwischen Linux und Windows ist in dieser Beziehung wohl, dass ich unter Windows bei einer nichtssagenden Fehlermeldung beim googlen die Windows-Version angebe und bei Linux die Linux-Version. Und dass ich da alternativ mich ein paar Stunden lang in den Quellcode eingraben kann um darin dann herauszufinden, was denn jetzt eigentlich der Fehler ist. Falls ich denn die entsprechende Stelle finde. Also wenn ich mir zum Beispiel den Output von Logwatch so anschaue, da war ich schon mehrfach in Panik, z.B. als mir zum ersten Mal im Abschnitt SSHD die "Network Read Write Errors" aufgefallen sind. Da brauchte ich dann auch erstmal die Übersetzung durch Durchforsten des Quellcodes, wodurch sich dann herausgestellt hat, dass das jetzt Mitnichten auf ein Netzwerk-Problem meines Servers hindeutet. ;)

    Wo der CEO sitzt ist doch unerheblich, solange sich die Seite an deutsche Verbraucher richtet. Bei einer de-Domain mit einer deutschsprachigen, gewerblichen Website wird man davon ausgehen können. Das gilt auch für Eigentümer und Hosting außerhalb Deutschland.

    Am einfachsten wäre es, beim Export nur die Tabellen der alten Datenbank zu exportieren. Ansonsten kann man doch die Export-Datei, den MySQL-Dump, notfalls runterladen, lokal editieren (z.B. Notepad++, nicht unbedingt mit dem MS-Editor/Notepad). In der Datei wird ziemlich oben ein Abschnitt wie der folgende drinstehen:

    Code
    --
    -- Datenbank: `kxxxxx_xxx-xx_db01`
    --
    CREATE DATABASE IF NOT EXISTS `kxxxxx_xxx-xx_db01` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
    USE `xxxxx_xxx-xx_db01`;

    Den Abschnitt, also insbesondere die zwei SQL-Befehle, löschst du einfach raus. Dann kannst du den Rest, also die Tabellen und ihre Inhalte, Indexe usw, in jede beliebige, existierende Datenbank importieren.


    Edit: Die neue Datenbank sollte vor dem Import natürlich möglichst leer sein ;)

    Also falls wirklich per CLI aufgerufen werden soll, das geht in meinen Webhostings nicht, sowohl gs als auch ImageMagick. Eventuell per PHP mit exec oder wie auch immer. Vorhanden sind die Binaries auf dem Server, PHP kann sie ja benutzen, auch im PHP-CLI ist imagick als Modul vorhanden.

    Ich hab jetzt kein Reseller-Webhosting mehr, möglicherweise gibt es eine Einstellung, die einem Kunden erlaubt bzw verbietet die ihm gesetzten Limits zu überschreiten. Jedenfalls solange insgesamt trotzdem noch die restlichen Kunden ihre zugesicherten Ressourcen komplett nutzen können, ohne dass dadurch die Ressourcen deines Reseller-Pakets überschritten würden. Dann wäre es ja immer noch nicht überbucht. Ein größeres Paket lindert natürlich die Ressourcenprobleme bei gleichbleibender Kundenzahl. Die andere Frage verstehe ich nicht. Welches DNS würden sie nutzen wollen ohne (Sub-)Domains zu haben?

    In der Regel ein Fehler in deinen Einstellungen. Schaue nochmal genau nach, wieviele Subdomains, Datenbanken etc in den deinen Subscriptions zugeordneten Service Plans enthalten sind. Das hat nichts mit den tatsächlich genutzten Subdomains/Datenbanken/Plattenplatz usw zu tun, sondern mit den den Kunden in ihrem Service Plan zugesicherten Subdomains/Datenbanken/... Die Meldung kannst du also locker bekommen, auch wenn kein einziger Kunde/Subscription auch nur 1 Subdomain oder Datenbank nutzt. Er könnte es aber ... je nach deinen definierten Service Plans. Du kannst die Ressourcen deines Reseller-Webhostings also nicht überbuchen. Wenn jeder Kunde 10 Prozent der in deinem Reseller-Webhosting enthaltenen Subdomains oder Datenbanken gemäß des entsprechenden Service Plans nutzen darf, dann kannst du eben nur 10 Kunden anlegen, weil damit deine Ressourcen verbraucht sind.


    Bei den Konflikten mit der serverweiten Security-Einstellung gibt es nur die beiden in der Meldung erwähnten Möglichkeiten. Entweder du entscheidest dich, die Einstellung trotz des Konflikts beizubehalten oder du bringst deine Einstellungen wieder mit den serverweiten Einstellungen in Übereinstimmung. Beides ist zulässig. Die serverweiten Einstellungen kannst du sicher nicht ändern. Es hindert dich aber niemand, deine Einstellungen trotzdem so zu machen, das sie eben im Konflikt dazu stehen. Funktionieren werden sie trotzdem. Das betrifft in der Regel Perl/Node.js, ...

    Habe ich, ehrlich gesagt, gar nicht draufgeschaut, sondern nur meinen Standardeinwurf bezüglich Impressum fallengelassen. :S

    Musst du auch mal gelegentlich aktualisieren, den RStV gibt es nicht mehr, er wurde 2020 vom Medienstaatsvertrag (MStV) abgelöst ;) .

    Und freilich heisst "nur mit Login" nicht, dass die Website zwingend privat ist und kein Impressum braucht. Kommt halt auch darauf an, wer sich da registrieren und anmelden kann und was da angeboten wird. Auch registrierte Benutzer haben Rechte ;) . Solange von denen niemand Probleme hat mt dem fehlenden Impressum oder dem Betreiber der Plattform wird es freilich in der Praxis keine Probleme geben.

    Es ist halt so, dass du per SSH im Webhosting in einer chroot Umgebung bist. ImageMagick z.B. ist auf dem Webhosting-Server vorhanden, aber du hast über die Konsole keinen direkten Zugriff darauf. Über den Webserver kann PHP mit Hilfe von imagick/ImageMagick z.B. Vorschaubilder von PDF-Dateien generieren. Prinzipiell dürfte das auch per PHP auf der Konsole gehen. Binaries kannst du aber prinzipiell da ablegen und ausführen. Ob sie dann auch 100% funktionieren, das wird man im Einzelfall sehen müssen.

    Genau. Ich weiss jetzt nicht mal, im Zuge welchen Updates die Änderung bei den LE-Zertifikaten eingeführt wurde. Für alle, die noch nicht so lang Webhosting-Kunden sind: Davor gab es die Möglichkeit eines Wildcard-Zertifikats bei netcup nicht, sondern nur Zertifikate, welche entweder die Hauptdomain, wahlweise inklusive www-Subdomain, oder einzelne Subdomains abdeckten. Diese wurden automatisch verlängert. Daran hat sich jetzt geändert, dass zusätzlich auch Wildcard-Zertifikate immerhin überhaupt möglich sind, auch wenn hier dann eine automatische Verlängerung nicht gegeben ist. Die Einzelzertifikate für Hauptdomain oder Subdomains werden auch weiterhin automatisch verlängert. Schwach oder nicht schwach, ich kenne mehrere renommierte Webhoster, da gibt es gar keine LE-Zertifikate, egal ob mit oder ohne automatische Verlängerung. Und die sind alle deutlich teurer als vergleichbare netcup-Angebote, soweit man Webhostingpakete mit Dutzenden Bestandteilen überhaupt so pauschal vergleichen kann.


    Ich bin kein Ex-Präsident der USA, ich sage nicht, dass meine Atomrak... ähhh Webhostings hier bei netcup Tippitop sind, sie haben durchaus auch ihre Schwächen. Aber LE-Zertifikate gehören da aus meiner Sicht nicht wirklich dazu.

    Die Doku für den Plesk Composer bzw für die in Plesk implementierte Oberfläche für Composer wird sich wohl bei Plesk finden lassen. Warum willst du an die composer.jsons in den untergeordneten Verzeichnissen drankommen. Die darin enthaltenen Pakete werden doch typischerweise sowieso beim composer update oder composer install im Hauptverzeichnis woanders her geladen und sind im Prinzip eigentlich andere Projekte, die aber wiederum Abhängigkeiten haben können, die dann in deren composer.json im Unterverzeichnis drinstehen. Im Prinzip ist doch die composer.json im document root bzw Installationsverzeichnis die einzige, die man bearbeiten sollte? Bin jetzt nicht der Composer-Experte, aber so verstehe ich das jedenfalls.

    Naja, die natürliche Anlaufstelle für Composer wäre wohl https://getcomposer.org/

    Ich habe jetzt nicht geprüft, welche Composer-Version in der Shell global installiert ist, aber du kannst Composer nötigenfalls auch für deinen User oder sogar pro Projekt installieren.

    Ganz blöde Frage: Hast du nach dem Einblenden schon mal nach unten gescrollt? Bei mir am Desktop mit FF 100 erscheint die Tastatur ganz unten und es ist auch nur die oberste Reihe der Tasten ohne Scrollen sichtbar. Ist natürlich sehr praktisch, weil wenn man runterscrollt um an die Buchstaben ranzukommen, dann sieht man oben nicht mehr was man tippt. Das mag besser werden, wenn der Bildschirm mal gefüllt ist, direkt beim Login ist es aber (bei mir) erst mal so. Naja, das Passwort sieht man ja beim Tippen sowieso nicht.

    Also die DNS Records deiner Domain(s) anschauen, insbesondere der Domain deines Admin-Accounts, und Ausschau halten nach TXT-Einträgen mit einem Text, der in etwa so aussehen kann:

    Code
    v=DMARC1; p=quarantine;sp=quarantine;pct=100;rua=mailto:<deine Admin-Adresse>;adkim=r;aspf=r

    Insbesondere das "rua=mailto:..." ist ursächlich für die Reports, der Rest kann anders aussehen oder auch teilweise fehlen.

    Bei Google und MS kommt bei mir täglich ein Report, sofern von Google/MS an einem Tag auch mindestens eine Nachricht an meine Domain geschickt wurde. Wie es bei Amazon aussieht weiss ich nicht, von denen habe ich bisher noch keine Reports erhalten. Hatte also entweder noch keine Mails von Amazon auf meinen eigenen Domains oder Amazon hat erst kürzlich mit dem Versenden von Berichten angefangen. Bei mir wäre beides eine mögliche Ursache, weil ich bei Amazon eine GMX-Freemail-Adresse hinterlegt habe. Da bekomme ich natürlich keine Reports.

    Bei mir nicht, jedenfalls nicht mit der IP. Mit anderen schon, aber mit der IP kommt nach einigen Sekunden:

    Code
    resolve call failed: DNSSEC validation failed: no-signature

    resolvectl query 91.204.46.70 liefert mir z.B. korrekt:

    Code
    91.204.46.70: a2e46.netcup.net                 -- link: eth0


    dig -x 54.240.1.131 liefert den PTR sofort korrekt zurück.


    Ich habe mal DuckDuckGo und Google bemüht, könnte eventuell auch ein Bug in systemd/resolved sein. :/?(:rolleyes:

    Da gab es wohl schon öfter Probleme, mit dem sehr unschönen Workaround "DNSSEC=no" zu setzen anstatt "DNSSEC=allow-downgrade"

    Jedenfalls vertage ich das jetzt auf später und gehe an der Matratze horchen bevor es wieder hell wird.


    Netcup scheint da aber - Stand jetzt - unschuldig zu sein


    Denn es funktioniert auch mit den Resolvern von Google nicht.

    nan0 : Kannst du sie über alle Netcup DNS-Resolver auflösen. Klappt das immer, also 7/24? Ich weiss, schwer zu verifizieren ;) .


    Aus eigener Erfahrung muss ich sagen, ich hatte zwei Mal Schwierigkeiten mit der Namensauflösung. Beim ersten Mal habe ich es nicht realisiert, dass die netcup Resolver die Ursache waren, ich habe es im Gegenteil so gut wie ausgeschlossen, obwohl deren Zuverlässigkeit damals hier im Forum in diversen Threads Thema war. Ich habe es aber trotzdem zunächst als Ursache ausgeschlossen, weil ich die Probleme nur sporadisch und nur auf einem von drei Servern hatte und alle drei Server die selben netcup Resolver benutzten. Aber als ich nach tagelanger Suche absolut keine andere Ursache finden konnte, habe ich testhalber dann doch mal die DNS-Resolver auf dem problematischen Server geändert, von netcup auf Google, die Probleme waren sofort wie weggeblasen und sind seitdem nicht mehr aufgetreten.

    Beim zweiten Mal waren die Symptome etwas anders und die Signale in Richtung netcup Resolver wesentlich deutlicher. Zudem hatte ich den ersten Fall noch im Hinterkopf, habe also diesmal schneller den Test mit den Google Resolvern gemacht. Und wieder hat sich das Problem umgehend in Luft aufgelöst.


    Auch bei diversen Fehlern im DNSSEC von Domains war es jeweils ein netcup Problem, diesmal u.a. mit den Nameservern, insbesondere mit einem. Mit welchem weiss ich nicht mehr, da müsste ich mal schauen, ob ich die damaligen Logfiles noch habe. Auf meinen beiden Servern mit Intel-Prozessoren sind beide oben erwähnten Probleme nie aufgetreten. Ich habe gerade eben mal nachgeschaut und festgestellt, dass dort immer noch die netcup-Resolver benutzt werden. Beide Server sind aber zumindest absolut unauffällig. Zufall? Die Wahrscheinlichkeit dafür ist bei nur vier beobachteten Servern natürlich relativ groß. Werde jetzt aber doch mal in den nächsten Tagen die Logfiles genauer unter die Lupe nehmen, vielleicht findet sich ja doch was.

    Den DNS-Resolver hast du entweder mit einem Image von netcup eingestellt bekommen oder du hast ihn bei der Installation deines OS irgendwo angegeben. Ansonsten würde dein Server ja überhaupt keine Namen auflösen können. Hast du ein Image von netcup installiert und den DNS-Resolver nicht geändert, dann nutzt du die netcup Resolver.