Beiträge von tab

    Scheint ja doch länger zu dauern:

    um 4:30:

    ...aktuell liegt ein Ausfall am Webhosting Server a2e46 vor. (...) Uns ist der Ausfall bekannt und wir sind bemüht diesen so schnell wie möglich zu beheben...

    eben, um 12:20:

    ...aktuell liegt weiterhin ein Ausfall am Webhosting-Server a2e46 vor. (...) Wir arbeiten weiter aktiv an der Behebung und daran, dass Ihre Dienste schnellstmöglich wieder zur Verfügung stehen. Es finden hier von uns aktuell weiter Reparatur-Arbeiten statt, um das System wieder vollständig betreiben zu können...

    Was hast du denn da kaputt gemacht? Die selben Mails habe ich auch ;). Ich frage mich, ob das ein echter Ausfall ist (Hardware) oder ob da vielleicht schon das angekündigte Plesk-Update im Gange ist. Momentan geht jedenfalls vom Webserver her gar nichts, weder Websites noch Details im CCP/WCP, allerdings ist der Zugriff per SSH mittlerweile problemlos möglich, die Kiste läuft also.

    Das erinnert mich an eine alte Anekdote, die wohl hoffentlich frei erfunden ist. Da beklagt sich ein User bei der Hotline, dass sein Bildschirm schwarz ist. Und nach langem hin und her und Überprüfung der Verkabelung stellt sich dann heraus, dass die dort gerade Stromausfall haben. :rolleyes:;(

    Leider kann man beim Bestprice-Classic keine externen Domains aufschalten, jedenfalls nicht umsonst, kostet einmalig 5,-€. Das sollte aber auch mit deiner ch-Domain möglich sein. Da bin ich mir zwar ziemlich sicher, aber im Zweifel mal beim Support nachfragen. Edit: Kommando zurück, ist ja Schwachsinn. Du hast hier bei Netcup eine ch-Domain als zusätzliche Domain gebucht. Diese lässt sich jedem beliebigen netcup Webhosting ohne weitere Kosten zuweisen, also auch einem Bestprice Classic. Sagt jedenfalls mein CCP.

    Ansonsten halt jemanden suchen, der einen eigenen Mailserver betreibt.

    Ist da schon Inhalt eingepflegt odere sonst was installiert, was größere Mühe machen würde wenn es weg wäre? Ansonsten tendiere ich dazu, entweder die Sache dem Support zu melden oder die Brechstange zu benutzen: Im Homeverzeichnis per SSH mal eben rm -rf httpdocs. Etwaige Installationen in Unterverzeichnissen davon sind dann freilich auch weg, eventuell vorher außerhalb von /httpdocs sichern. Aber eine Installation in einem Unterverzeichnis einer anderen Installation ist aus meiner Sicht sowieso ein NoGo.

    Das heißt dann im Klartext, das wurde ja auch geschrieben: Für Backups ist der Kunde zuständig. Und ich füge dann von meiner Seite her hinzu: Lieber Kunde, mache deine Backup bloss ja nicht (nur) auf Storage Space bei netcup, denn hier ist eine räumliche Trennung in verschiedene Brandabschnitte zwar durchaus möglich, aber nicht garantiert. Ohne eine mehrfache Sicherung auf unterschiedliche, an unterschiedlichen Orten aufbewahrten Medien ist nach der 3-2-1 Regel die Sicherheit der Daten ohnehin nur Schall und Rauch (Und wo Rauch ist, ist auch Feuer ;);() .

    Das glaube ich nicht. Netcup hat 2010/2011 ein altes Het zner Rechenzentrum gekauft oder übernommen (komplett gepachtet) und 2016 wurde Netcup gekauft und jetzt gehört das RZ vermutlich Anexia und nicht mehr dem Tochterunternehmen Netcup und Netcup "mietet" nun einen Teil und die Verwaltung sowie der nicht von Netcup verwendete Teil hängt bei Anexia und Netcup kann schreiben "Wir können dazu keine Aussage treffen, sind nur Mieter" ^^

    (alles nur Spekulation)

    Öhm, ja ... "Wir können dazu keine Aussage treffen, sind nur Mieter", so könnte man sich freilich auch disqualifizieren. Selbst wenn ein Webhoster, der eigene Server betreibt, die dafür notwendige Rechenzentrumsfläche nur mietet, erwarte ich eigentlich schon dass man sich vor Unterzeichnung des Mietvertrags das Rechenzentrum mal anschaut.

    SBG1 hat auch etwas abbekommen, vier Räume haben einen schweren Schaden abbekommen (Kommunikation aus deren FAQ) und acht haben es überlebt.

    Ich habe leider die Niete gezogen und einer meiner Maschinen scheint wohl DSGVO konform dahin geschmolzen zu sein :S.

    Das nennt man dann wohl (CPU-) Kernschmelze.

    Na, das probiere ich doch heute Nachmittag gleich mal aus. Muss da sowieso noch was testen, was mich letztens, als ich nur mal kurz den Dialog mit den für die Aufschaltung einer externen Domain einzustellenden DNS-Records anschauen wollte, etwas erschreckt hat im Zusammenhang mit externen Domains. Wobei "erschreckt" nicht der richtige Ausdruck ist, weil es anderswo auch funktioniert. Also eher "enttäuscht", weil ich die früheren Aussagen dazu hier im Forum anders verstanden hatte.

    So, alles eingerichtet mit einer Inklusivdomain eines meiner Webhostings hier bei netcup. Zwei E-Mail Testaccounts erstellt, Domain extern anderswo aufgeschaltet und dort einen dritten E-Mail Testaccount erstellt mit der selben Domain. Im DNS einen weiteren MX record mit niedrigerer Prio erstellt, der auf den dortigen Mailserver verweist. Nachdem es anfangs so aussah, als könnte ich tatsächlich alle drei Accounts gleichzeitig voll nutzen - was eigentlich nicht gehen sollte - hat es sich jetzt so zurechtgeruckelt wie ich es vermutet hatte. Account 1 und 2 bei netcup können sich gegenseitig noch Mails schicken und auch Mails nach extern schicken, nur von extern kommt nichts mehr zu ihnen durch, weil der externe MX mit der niedrigsten Prio das abbügelt und sagt:

    Code
    Diagnostic-Code: smtp; 550 5.1.1 <test1@meinedomain.de>: Recipient address rejected:
        User unknown in virtual alias table

    Der dritte Account ist voll funktional, kann senden und empfangen.

    So würde es wohl auch aussehen, wenn man die Google MX-Records erstellt und die netcup MX-Records entsprechend mit einer höheren Prio versieht, so wie Google das haben will.

    Ob Webmail jetzt bei netcup noch funktioniert mit Account 1 und 2 habe ich nicht getestet, mache ich vielleicht noch, ich lasse das Ganze jetzt eh mal ein paar Tage ruhen und schaue dann nochmal, wie sich das verhält, wenn sich die DNS-Einstellungen überall rumgesprochen haben. Ich habe die drei Accounts alle in Thunderbird eingerichtet, die zwei bei netcup mit dem dortigen Mailserver, den dritten mit dem entsprechend anderen Mailserver jeweils für IMAP und SMTP. Die andere Geschichte mit externen Domains hat sich leider bestätigt, da werde ich wohl mal den Support kontaktieren, weil das so - zumindest bisher - nicht gewollt war, was ich auch gut und richtig fand. Auch wenn es bei anderen Hostern größtenteils genauso funktioniert.

    Soweit ich weiß funktioniert das nicht, weil das Netcup-Hosting-System direkt reagiert, falls ein weiterer MX-Eintrag vorhanden ist. Ich wollte bei einer Domain mal einen Backup-MX mit Postfix-Relay hinzufügen und daraufhin wollte der Hosting-Service gar keine Mails mehr empfangen.

    Support meinte daraufhin, dass man entweder die Mailserver von Netcup nutzen kann *oder* externe aber niemals beides gleichzeitg (auch keinen einfachen Relay).

    Na, das probiere ich doch heute Nachmittag gleich mal aus. Muss da sowieso noch was testen, was mich letztens, als ich nur mal kurz den Dialog mit den für die Aufschaltung einer externen Domain einzustellenden DNS-Records anschauen wollte, etwas erschreckt hat im Zusammenhang mit externen Domains. Wobei "erschreckt" nicht der richtige Ausdruck ist, weil es anderswo auch funktioniert. Also eher "enttäuscht", weil ich die früheren Aussagen dazu hier im Forum anders verstanden hatte.

    Hat der Support vor der Antwort bei der Technik nachgefragt? ;)

    Anyway, nachfassen kann man immer, bloss wird hier zumindest kein Kunde eine definitive Antwort geben können. Ausser jemand verifiziert die vermuteten Sicherheitslücken von Roundcube mit einem Exploit, dann ist der Fall klar. Ansonsten bliebe jederzeit die Möglichkeit, die Angelegenheit über das entsprechende (Beschwerde-) Formular zu eskalieren. Immer in der Hoffnung, dass dann intern geprüft wird, welche der widersprüchlichen Aussagen denn nun den Tatsachen entspricht und danach eine definitive Antwort gegeben wird. Das Webhosting sollte davon aber jedenfalls nicht betroffen sein, außer man hackt über den Webmailserver dann auch den Rest der Infrastruktur. Mail liegt ja auf einem anderen Server als der Webspace.