Beiträge von der_webcode

    Es gibt zwei Möglichkeiten, die einfache ist die default.html in Index.html umzubenennen. Die andere Möglichkeit besteht darin, die Standard Indexdateien unterhalb des WCP >> Websites&Domains >> Einstellungen für Apache&nginx >> Indexdateien selber festzustellen. Dort gehört dann default.html hinein, danach speichern und ca. 5 min warten (kann natürlich auch schneller gehen).

    mainziman


    smtpd_recipient_restrictions = permit_sasl_authenticated,

    permit_mynetworks,

    reject_unauth_pipelining,

    reject_non_fqdn_sender,

    reject_non_fqdn_recipient,

    reject_invalid_hostname,

    reject_unknown_sender_domain,

    reject_unknown_recipient_domain,

    reject_unauth_destination,

    reject_unknown_address,

    check_policy_service inet:127.0.0.1:10023,

    reject_rbl_client zen.spamhaus.org,

    reject_rbl_client ix.dnsbl.manitu.net,

    reject_unverified_recipient,

    permit


    Damit werden schon viele ohne Greylisting herausgefischt, aber verkehrt ist es nicht.

    Ein unwissender Admin kann so nie ein wissender Admin werden wenn ich deinen Gedankengang verfolge... Wie auch immer. Will hier auch nichts vom Zaun brechen, da ich weis dass du auch recht hast... Nichtsdestotrotz muss man ja mal irgendwo anfangen...

    Zuallerallererst mal die Grundlagen und erst dann einen Server. Gerade DNS ist nicht gerade ohne und da ist schon einiges zu berücksichtigen um nicht direkt gehackt zu werden (Stichwort Botnetzwerk etc..). Jeder fängt klein an, das ist schon richtig, aber in der Programmierung startet man auch nicht damit zu fragen ich habe ein Programm gesehen und das will ich auch programmieren, wie mache ich das. Dafür ist auch ein Forum nicht da, sondern Du lieferst ein Problem (was nicht in die Grundlagenschiene gehört) und wir helfen Dir.

    Die obigen Antworten sind auch zu Deinem Schutz da, sieh es einfach mal so.

    Also Du wirfst hier zwei Sachen in einen Topf, Webhosting und vServer/Rootserver. Das sind zwei getrennte Dinge und wenn Du die A/AAAA Einträge auf den Server legst (was ja auch notwendig ist, damit der Zugriff funktioniert) dann funktioniert der DNS Eintrag natürlich nicht mehr auf dem Webhosting. Ergo kann man mittels Webhosting weder auf die Domain zugreifen noch, logischerweise, ein Lets Encrypt Zertifikat über das Webhosting für eine Domain des Rootserver erstellen.

    Es ist notwendig, dass Du Lets Encrypt auf dem Rootserver erstellst und auch dort konfigurierst. Sollte es aber schon an der simplen Aufgabe DNS und Rootserver scheitern, dann solltest Du dir darüber klar werden ob dies das richtige für dich ist.

    Bei mir läuft u.a. HSTS mit folgenden Einstellungen:


    Code
    <IfModule mod_headers.c>
      Header set Referrer-Policy "no-referrer"
      Header set X-Frame-Options "sameorigin"
      Header set X-Content-Type-Options "nosniff"
      Header set X-XSS-Protection "1; mode=block"
      Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" 
    </IfModule>

    HTTPS Redirection würde ich hier aber nicht über die httaccess machen, sondern vielmehr im WCP unter Hostingeinstellungen setzen. Grundsätzlich sollte möglichst wenig in die htaccess gesetzt werden was nicht unbedingt notwendig ist, da diese bei jedem Seitenaufruf erst verarbeitet werden muss.

    Das funktioniert im WCP nicht, da wir hier eine eingeschränkte Umgebung haben. Was Du zitierst ist die Umgebung mit vollständigem Zugriff. Wenn ich es richtig verstanden habe, dann wird die Hauptdomain hier durch das CCP vorgegeben und gesetzt und kann nachträglich nicht geändert werden. Zu deiner zitierten Subdomain sollte es eine Hauptdomain geben und die kannste dann ja nutzen.

    Im Zweifel muss die Domain/Subdomain neu angelegt werden und auf das vorhanden Verzeichnis zeigen.

    Sicher ist immer so eine Frage, allerdings unterliegen sowohl Netcup als auch Apple der DSGVO (ja auch Apple). Beides sind mit den entsprechen Accounts "normale" E-Mailanbieter. Ich finde es ist eher die Frage der Konfiguration des Mailservers, z.B. bezüglich SPAM Aufkommen, DKIM etc.

    Aber im Zweifelsfall kommt man bei Netcup schneller an einen Mitarbeiter und bekommt eine Lösung als dies bei Apple der Fall ist. Netcup ist zwar nicht zertifiziert, aber grundsätzlich denke ich, dass die Daten hier "sicher" sind, auch wenn dies heutzutage keine Gewissheit mehr ist.


    Wenn es auf mehr Sicherheit ankommt, dann könnten unter Umständen andere Anbieter bezüglich E-Mail in Frage kommen, nur werde ich hier öffentlich keine nennen. Ich bin bewusst mit meinem Mailaccount bei einem anderen Anbieter, auch bezüglich der Erreichbarkeit, wenn z.B. der Account wegen eines Hacks gesperrt wurde, dann bin ich per E-Mail weiterhin erreichbar.

    Meiner Vorstellung nach hätte ich es gerne so, dass ich httpdocs/test und httpdocs/live habe und entsprechend nur den dokumentenstamm der domain umzustellen brauche um die domain auf die eine oder andere Wordpress Seite zu verlinken.

    Grundsätzlich installierst Du WordPress in zwei verschiedenen Verzeichnissen, wie von Dir beschrieben, und bei der Einrichtung der MySQL Datenbank gibst Du jeweils die gleichen Zugangsdaten ein. Hierbei ist auch das unterschiedliche Präfix zu achten! andernfalls geht es schief.

    Vom Produktivsystem würde ich sowieso jeden Tag ein Backup, also von der Datenbank, machen. Grundsätzlich geht es natürlich auch ein Backup zurückzuspielen, wenn etwas schiefgeht, wobei Du merken musst, dass etwas mit dem Produtivsystem nicht stimmt.

    Wenn in der Zwischenzeit auf der Testumgebung etwas gemacht wurde was Du nicht wieder zurücksetzen möchtest, aber im Produktivsystem ein Fehler besteht, dann wird es echt kompliziert. Geht natürlich alles mittels SQL, aber es ist dann sehr aufwendig.

    Ich würde zu zwei getrennten Datenbanken raten. Alternativ geht es natürlich auch mit den entsprechenden Prefix in MySQL, welche ich grundsätzlich setzen würde.


    Diese Vorgehensweise setzt zwei unterschiedliche Domains, Domain/Subdomain oder Subdomains voraus.

    Also ich würde davon dringend abraten beide Installationen auf einer Datenbank zusammenzuführen, insbesondere wenn Test- und Liveumgebung darauf laufen sollen. Wenn etwas in der Testumgebung schief geht kannste Dir damit auch die Datenbank der Liveumgebung zerhauen. Zwei Liveumgebungen auf einer Datenbank sind schon, naja, aber eine Testumgebung ....

    Vor allem ist bei WordPress, wie bei anderem CMS auch, die Datenbank das Rückgrat.