Beiträge von tab

    Mir persönlich sind mehrere Dinge aufgefallen. Zum ersten war pünktlich zum Ablauf des Zertifikats eine Synchronisation meiner Nextclouds mit Hilfe des Nextcloud Windows-Clients von meinem Windows 10 nicht mehr möglich. Das betraf alle drei Instanzen. Eine auf meinem Debian 10 Webserver, zwei bei einem netcup Mitbewerber auf unterschiedlichen Servern. Da gab es mittlerweile ein Update des Clients, wobei ich nicht weiss, ob der das Problem gefixed hätte, weil ich es zu dem Zeitpunkt bereits windowsseitig behoben hatte. Zum zweiten bekam ich am Samstag einen Anruf, weil ein Kunde seine IMAP-Mails bzw Mailanhänge nicht mehr mit seinem geliebten Windows Live Mail runterladen konnte, was mir ja gaaanz herzlich leid tut ;). Ich habe ihm empfohlen, sein Outlook stattdessen zu benutzen, auch wenn es nur ein ziemlich armseliger Ersatz ist, z.B. beim Darstellen von HTML-Mails.

    Und natürlich hört man in diversen Foren von dadurch verursachten Problemen.

    Habe es gerade mal mit zwei Subdomains ausprobiert. Die erste (sub1.meinedomain.de) existiert schon lange, wurde aber nie wirklich benutzt. Es war also nur die von Plesk erzeugte index.html und die favicon.ico drin. Ich habe dann zum Testen zwei weitere Dateien in das Verzeichnis kopiert und danach eine zweite Subdomain (sub2.meinedomain.de) angelegt mit dem selben "Dokumentstamm" wie die erste Subdomain. Dann habe ich die erste, ältere Subdomain sub1 in Plesk gelöscht. Danach war das Verzeichnis (Dokumentstamm) immer noch vorhanden und es waren immer noch alle vier zuvor vorhandenen Dateien in dem Verzeichnis enthalten. Danach habe ich die neue Subdomain sub2 auch gelöscht. Danach war dann tatsächlich das Dokumentstamm-Verzeichnis inklusive aller Dateien weg. Datenbank war keine zugewiesen, das wäre also noch zu testen. Ansonsten sieht es für mich so aus, als ob nur gelöscht wird, wenn keine andere Subdomain mehr den selben Dokumentstamm hat. Das muss ich aber auch noch intensiver testen, z.B. auch im Zusammenspiel mit dem Wordpress-Toolkit. Bei den Datenbanken schätze ich es aber kritischer ein, das muss ich noch ausprobieren. Denn die sind ja maximal einer Subdomain zugeordnet. Wenn die dann gelöscht wird, dann könnte die Datenbank eventuell auch gelöscht werden. Obwohl ich mich dunkel erinnere, das mal gemacht zu haben und die Datenbank danach halt einfach nicht mehr zugeordnet war, aber noch existiert hat.

    Aber heute eher nicht mehr, nächste Woche ist auch noch ein Tag ;)

    Ja, Googles Algorithmen sind teilweise recht intelligent geworden. Man sieht auch deutlich, dass z.B. Bing m.E. wesentlich weniger intelligent auswertet. Da ist immer noch viel mit Suchbegriffen in der URL zu machen, was Google nach meinen letzten Erfahrungen kaum noch beeindruckt. Gesehen habe ich das an einer relativ neuen Plattform für Rechtsanwälte. Da werden weitgehend identische Websites erstellt, die praktisch nur aus einer Reihe von Textbausteinen bestehe, bei denen an mehr oder weniger passenden Stellen Ort und Rechtsgebiet eingesetzt werden, die beide auch in der URL vorkommen. Bei Bing und somit auch DuckDuckGo ranken diese Seiten ziemlich gut, bei Google so gut wie gar nicht. Da ranken die eigenen Seiten der Anwälte meist viel besser. Da erkennt Google offenbar die Textbausteine bzw die große Ähnlichkeit der Webseiten und "bestraft" diese Strategie dann ziemlich stark. Dass die dann aber mittels Google-Ads zumindest teilweise als "Anzeige" angezeigt werden, bis halt das Budget aufgebraucht ist, da hat Google freilich nichts dagegen. ;)

    Wo liegt das Problem? Die Warnhinweise sind etwas theatralisch mit der Bestätigung durch OK, aber sie bedeuten im Endeffekt, dass beim Wechsel vom Typ "Website-Hosting" auf den Typ "Weiterleitung" das Verzeichnis gelöscht wird, auf das die Domain vor der Umstellung verwiesen hat. Das würde also nur dann etwas Wichtiges löschen, wenn die Domain zuvor auf das Verzeichnis mit der Multi-Domain Installation verwiesen hat und dann in eine Weiterleitung umgewandelt wird. Und auch hier gehe ich davon aus, dass solange eine Domain auf das Verzeichnis verweist dieses nicht gelöscht wird. Wäre aber mal zu verifizieren um ganz sicher zu sein. Das Standard-Verzeichnis /httpdocs wird wohl auch nicht gelöscht werden, solange die System-Subdomain nicht auf ein anderes Verzeichnis verweist oder in eine Weiterleitung umgewandelt wird (sofern das überhaupt geht). Insofern kannst du für alle deine Domains unbedenklich das Verzeichnis der Multi-Domain Installation angeben, weil sie ja wahrscheinlich zuvor auf das Standardverzeichnis verwiesen haben und nicht auf das Verzeichnis mit deiner Installation. Sonst müsstest du ja auch gar nichts ändern.

    Klar, Server die man nicht anlegen kann, sind logischerweise immer günstiger! :D

    Hilft uns Serversammlern aber erfahrungsgemäß auch nicht weiter. ;(

    (SCNR)

    Ist doch einfach, immer wenn die Leistung der vorhandenen Server nicht mehr zu reichen droht, kauft man halt einen dazu. Oder auch zwei oder drei. Ein Vorrat kann auch nicht schaden :D, damit man auf der sicheren Seite ist, wenn die Prozessoren knapp werden und die Preise steigen ^^. Dann kann man sich einreden "siehst du, war also doch gut, dass du vor 5 Jahren den Aktionsserver gekauft hast". Heute würde er zwei Euro pro Monat mehr kosten!

    Ich zahle lieber 10€/Monat als 10€/Minute :D;(. Minutengenau? Ist das der Einstieg in den Ultrakurzzeit Server-Handel? =O Gegen eine Erstellung von Servern per API habe ich freilich nichts einzuwenden. Ist natürlich auch immer eine Frage wofür und wie man die Server nutzt. Wenn man so einen Server im Schnitt ein paar Stunden braucht, kann man notfalls mal ne knappe Stunde zuviel zahlen und ist immer noch billiger dran als mit minutengenauer Abrechnung bei manchem Mitbewerber.

    Die IPv4 wird geshared mit allen Kunden auf dem selben Server. Die IPv6 ist deinem Webhosting-Paket zugewiesen, wird also nur von dir benutzt. Du gibst ja beim FTP-Login einen Benutzernamen an, damit sind deine Berechtigungen festgelegt, so dass du nur deine Dateien bearbeiten kannst. Andere Kunden können sich mit der selben IPv4 anmelden, haben aber einen anderen Benutzernamen.

    Also wenn ein externes Wiki, dann nicht auf netcup beschränkt. Ansonsten reicht wirklich auch das netcup-Wiki, wo man ja auch Beiträge einreichen kann. Aber auch da sieht man ja, dass es relativ leicht ist, ein Wiki zu erstellen, aber es ist schwieriger, es auch aktuell zu halten. Ich kenne mich auch nicht mit jeder Neuerung beim Webhosting aus, aber im Wiki steht z.B. immer noch was von "Plesk Onyx Panel Webhosting". Plesk Onyx? Ach ja, da war doch mal was ;).

    Dann würde es sich doch eigentlich anbieten, den von einer Verschiebung betroffenen Kunden eine entsprechende Mail zukommen zu lassen und ebenso auch nach erfolgreicher Durchführung eines Upgrades. Dann weiss man zu jeder Zeit, wie der Status des Webhostings ist. Bei meinem Webhosting ist mir das egal, aber andere mögen an diesem Tag eigentlich anstehende Arbeiten an ihrer Software/Website auf einen späteren Termin verschoben haben, weil man ja am fraglichen Tag nichts einplanen kann ohne zu wissen, wann man wieder zuverlässig mit dem Webhosting arbeiten kann. Wenn ihr dann nach nochmaliger Prüfung merkt, dass ihr das Upgrade an dem Tag nicht durchführen könnt, könnte der restliche Tag und auch die folgenden Tage bis zum neuen Termin ggf. noch genutzt werden. Ebenso, wenn ihr morgens um 10 Uhr bereits mit dem Upgrade fertig seid. Nicht jeder Webhosting-Kunde hat ein Monitoring, das sofort merkt, wenn sich die MySQL-Version geändert hat ;) und das Webhosting wieder verfügbar ist. Manche mögen noch nicht mal wissen, wie sie die MySQL-Version überprüfen können.

    Ich habe eine Mail bekommen, dass mein Webhosting am 9.9 umgestellt werden soll. Es läuft allerdings immer noch 5.7.33 und ich habe noch keine weiteren Ankündigungen bekommen.
    Hat jemand von euch ähnliche Erfahrungen gemacht?

    Das ist freilich lustig :rolleyes:^^. Da denkt man, MySQL sei umgestellt, aber man sollte vielleicht erst mal nachschauen, ob das auch tatsächlich so ist. Ich habe das gerade an meinem Webhosting 4000 (a2e4f) verifiziert. Das hätte auch am 9.9. umgestellt werden sollen, zeigt aber ebenso weiterhin 5.7.33. Das war auch das erste Webhosting von mir, das umgestellt werden sollte. Auch bei den anderen angekündigten Umstellungen habe ich keine Vollzugsmeldung. Allerdiings sind drei davon tatsächlich auf MySQL 8.0.25 umgestellt und eins auf 8.0.26. Dabei war die Umstellung auf 8.0.26 allerdings einige Tage früher als die bisher letzte Umstellung auf 8.0.25 ?(. Also hat bei a2e4f die Umstellung entweder nicht stattgefunden oder sie hat nicht funktioniert. Wie bei den anderen die Auswahl der neuen MySQL-Version erfolgt ist erschliesst sich mir erst einmal nicht. Der (geplante) Tag der Umstellung scheint jedenfalls nicht das Kriterium gewesen zu sein.

    Edit: Das sollte doch ein Ticket an den Support wert sein, jedenfalls das nicht umgestellte Webhosting. Wegen der unterschiedlichen Versionen mache ich mir erst mal keinen Kopf, das scheint mir eher eine Kuriosität am Rande zu sein und nicht weiter tragisch..