Beiträge von tab

    Ist es so hochwichtig, dass die Hauptdomain example.com selbst zum Aufruf verwendet wird? Ich habe mehrere Clouds am Laufen, aber alle (z.B.) über cloud.example.com, also eine Subdomain. So mache ich das jetzt auch beim roten H, so ist das ja auch dort explizit vorgesehen. Das funktioniert dann auch einwandfrei, wenn man es einrichtet wie beim roten H dokumentiert. Hierzu wird dann ein CNAME von cloud.example.com auf die kryptische Subdomain des Storage Share gesetzt. Zusätzlich muss die eigene Subdomain in der Verwaltungsseite der Storage Share eingetragen werden. Bei der kleinen Variante sind - glaube ich - drei verschiedene Subdomains möglich. Ich vermute mal, die erzeugen dann einfach jeweils einen passenden vHost für die Subdomain auf ihrem Server. In der URL des Browsers steht dann (z.B.) https://cloud.example.com/apps/dashboard/#/. Geht natürlich auch mit jeder anderen Subdomain.

    Klappt bei mir wunderbar. Ziehe grade meine Cloud-Daten von meinem gekündigten Strota-Server dahin um. Ein wenig Sorgen mache ich mir nur was passiert, wenn ich dann die dort verwendete cloud-Subdomain per CNAME auf die Storage Share verweise. Ich mache mich vorsichtshalber auf ein paar Stunden Downtime bzw Probleme mit der Erreichbarkeit gefasst. Down ist die Storage Share ja deswegen nicht, nur eben noch nicht über die neue Subdomain erreichbar bis das rote H den gesetzten CNAME-Eintrag erkennt und den Zugriff über die Subdomain ermöglicht.

    Mein VPS A ist auch frei, weil er Nextcloud nicht ausgehalten hat… Aber hergeben will ich den irgendwie nicht…

    Naja, wer kann Nextcloud schon aushalten? Das perfekte Beispiel einer Software, die neue Fehler schneller einführt als sie gefixt werden können. Warum auch noch Fehler beseitigen? Die nächste Version steht ja quasi ständig vor der Tür.

    Ich bin gerade dabei, meine Nextcloud-Inhalte zum roten H zu übertragen, der Server auf dem sie bisher läuft, geht Anfang nächsten Monat in Rente. Scheint ja halbwegs stabil zu laufen dort. Ich weiss zwar jetzt schon, dass ich mich bestimmt gelegentlich mal ärgern werde, wenn irgendeine App nicht in der benötigten Version oder gar nicht zur Verfügung steht oder weil die Datenbank nach einem Index schreit und ich ihn nicht hinzufügen kann, sondern auf das rote H warten muss. Aber das sind vergleichsweise Lappalien, jedenfalls bekomme ich nicht mehr die ewige Meldung, mein OPCache sei falsch eingestellt oder sonstigen Müll. Und falls doch, mache ich ein Ticket auf und lehne mich zurück.

    De Umzug ist allerdings für mich gefühlt um einiges aufwändiger als von Server zu Server, aber dafür ist es jetzt erst mal für eine Weile der letzte Umzug - hoffe ich jedenfalls.

    Geht mir da ähnlich wie ASS. Bei Servern wie auch bei Webhostings. Bei netcup habe ich das 8000er irgendwann gekündigt, aber außer der EiWoMiSau nutze ich keins der anderen (mehr), also ungenutzt:

    Webhosting 16 Years

    Webhosting 2000 SE Plus

    Webhosting 4000 SE WSV2020

    Webhosting Bestprice Classic

    Webhosting 1000 SE ADV20

    "Neuwertig" sind da aber die meisten nicht mehr, teilweise sind Inklusivdomains belegt. Vergleichsweise günstig sind die auch alle, auch nach der Preisanpassung vor einiger Zeit. Also bleiben sie erhalten. :)

    Naja, irgendwann mache ich wohl doch mal Frühjahrsputz. Auch die Domains muss ich mir mal vornehmen. Sind zwar auch günstig aber eben (zu) viele,von denen ich nur einen kleinen Teil zu überhaupt benutzen gedenke. Teils Relikte aus Corona-Zeiten, zumindest die werde ich wohl gelegentlich mal ausmisten.

    Zwei wesentlich teurere Webhostings bei zwei Mitbewerbern kommen noch dazu, die kosten jeweils in etwa so viel, wie die obigen zusammen. Davon werde ich mich (hoffentlich) im nächsten Jahr auch trennen. Eins ist zwar noch in Gebrauch, aber die eine Website, die auf dem noch läuft, könnte ich locker auf dem VPS 2000 ARM G11 unterbringen. Da wird sie zwar wohl etwas längere Reaktionszeiten haben =O :evil: , aber vernachlässigbar.

    Das Webhostingprodukt ist davon im Prinzip gar nicht betroffen. Du musst dort keine Subdomain einrichten. Lediglich die dafür vorgesehene Subdomain muss im DNS auf die IP(s) des VPS geleitet werden. Also ein A und ggf AAAA Record mit der IPv4 bzw IPv6 des VPS als Ziel. Einen Webserver hast du ja wohl schon installiert, da musst du dann eben einen entsprechenden vHost einrichten für die Subdomain. Auch um das LE-Zertifikat musst du dich auf dem VPS kümmern, es gibt ja diverse Möglichkeiten dafür das zu automatisieren. Da wird dir ein Zertifikat im Webhosting nichts bringen, weil Requests an deine Subdomain ja beim VPS aufschlagen.

    Edit: Mann, bin ich langsam! Das muss die Hitze sein, da funktioniert das Gehirn nur noch mechanisch, vermutlich bin ich zwischendurch eingeschlafen.

    Ich denke es war jedem klar dass die komplette Systemlandschaft der Bud GmbH mehrfach redundant aufgestellt ist. So wie man es von multinationalen Großkonzernen mit eigenen Cloudumgebungen halt auch erwarten würde. Vorallem im Bereich der kritischen Infrastruktur wo eine five nine Uptime das Mindestziel sein sollte! 🤪

    Eigentlich empfiehlt es sich im nächsten Schritt, die überwachten Server auf Windows umzustellen. Dann noch CrowdStrike draufspielen und schon hat das Monitoing was zu tun.

    Das ist ja auch schwer, weil sich die Tage in einem Monat ständig ändern. Quasi unvorhersehbar. Und dann auch noch Schaltjahre - quasi unmöglich zu programmieren.

    Ja, ich finde auch, wir sollten besser die Tageslänge so anpassen, dass das Jahr tatsächlich 12 Monate à 30 Tage hat. Um das kleine resultierende Problem, dass dann die Tage manchmal nachts und manchmal tagsüber anfangen kümmern wir uns dann irgendwann später.

    Es hängt damit zusammen, das ein Monat immer 30 Tage hat. Aber das Jahr weiss das leider nicht, es besteht darauf, 12 Monate zu haben und 365 oder 366 Tage, Wenn man nun hergeht und den täglichen Preis eines Produkts berechnet, indem man den jährlichen Preis durch 12x30=360 teilt und hinterher den neuen Preis für ein Jahr mit den tatsächlichen 365 oder 366 Tagen aus dem täglichen Preis berechnet, dann kann das die Inflation anheizen und bei den Kunden für Irritationen sorgen. Die können zwar auch nicht unbedingt besser rechnen, aber sie wundern sich doch, warum ein Produkt durch die Senkung der Mehrwertsteuer manchmal sogar teurer wird. :D;( Vielleicht sollte unser Finanzminister auch mal so kreativ rechnen, da könnte er sicher die paar fehlenden Milliarden im Haushalt leicht herausholen.

    Du musst laut Vertrag immer 30/31 Tage Kündigungsfrist einhalten.

    Nur bei den stundenbasierten Tarifen, wie die nach dem EM-Finale (was auch der Witz schlechthin war, dass man da tatsächlich plötzlich alle VPS ohne Laufzeit anbieten kann und sonst nicht bzw. Nur den 200 und 500) geht das mit der Berechnung "Tatsächliche Stunden / 720 Std. p. Monat". Den Rest kriegst du erstattet.

    Ergo: 1 Monat Kündigungsfrist = mind. 30 Tage zur nächsten "Laufzeit" / Verlängerung. ;)

    Ich bin verwirrt ...

    Die "normalen" X86 VPS gibt es doch auch alle mit 0 Monate Mindestlaufzeit, also nach meiner Auffassung jederzeit kündbar und somit hoffentlich stundengenau abgerechnet!? Ich habe es aber noch nie ausprobiert, das lohnt sich ja auch nur, wenn man den Server nicht für längere Zeit zu brauchen gedenkt. Dass man trotzdem einen Monat im Voraus bezahlen muss ist mir aber geläufig.

    Die ARM VPS haben aber in der Tat eine Mindestvertragslaufzeit von 1 Monat. Da sollte es also schon eine entsprechende Kündigungsmöglichkeit geben. Vielleicht mal den Support fragen (bin schon mal gespannt :):D )?

    Danke, diesen hatte ich auch gefunden - und oben verlinkt. Allerdings unterscheidet sich der Ablauf bei mir im Schritt #9:

    Beim run setup wird von dem Script auch npm aufgerufen, der bei mir nicht gefunden wird. Ich will nicht ausschliessen, dass hier vielleicht auch in meinem Webhosting der Wurm drin ist, aber mir fehlen die Ansätze bzw. das Vertrauen in den netcup-Support, hierbei zu helfen: Es würde bestimmt auf eine "Kundenanwendung" und dessen Verantwortung verwiesen werden - auch wenn ich das Problem in der Plesk-Bereitstellung von Node.js / NPM vermute.

    Du kannst nicht irgendwelche Commands von Github oder sonstwo aus dem Internet übernehmen und in der Konsole ausführen. Das alles geht zum allergrößten Teil ausschliesslich über die Plesk Oberfläche im WCP. In der Konsole steht npm, node usw nicht zur Verfügung. Nur so können diese Commands im Webhosting ausgeführt werden. Also kannst du allenfalls solche Quellen aus dem Internet nutzen, welche die Installation per Plesks Node.js Unterstützung beschreiben. Die sind allerdings wohl sehr dünn gesät. Da muss man sich notfalls Beschreibungen für die Installation anderer Programme anschauen, die ähnliche Dinge ausführen müssen und die dann ggf für Uptime-Kuma anpassen.

    Wie weit kommst du denn im Ablauf gemäß der verlinkten "Doku"? Scheitert es bei dem "run-script"?

    Manuell wirst du wahrscheinlich nicht viel eingeben können, vieles läuft wohl überhaupt nur, weil es von Plesk asgeführt wird undPlesk sicher mit mehr Rechten läuft als ein Webhosting-User. Vielleicht versuche ich das heute Abend oder morgen mal mit Uptime-Kuma. Das wäre für mich prinzipiell auch interessant, willi hc schon länger mal installieren zur Überwachung einiger Websites. Aber letztlich würde ich die produktive Installation sowieso eher auf einem meiner kleinen vServer haben wollen. Wäre aber immerhin interessant zu wissen, wie sowas auf dem netcup Webhosting unter Plesk funktioniert.

    Also abgesehen davon, dass man normalerweise für de-Domains zwei verschiedene NS haben sollte, darfst du bei "Host" im DNS im CCP die Domain selbst nicht mit angeben, also nur ns1 bzw ns2. So wie es eingetragn ist, hast du die Adressen für ns1.meindedomain.de.meinedomain.de gesetzt. Entsprechend auch für ns2...

    Nee, Quatsch, das sind ja die Nameserver-Einstellungen, da muss wohk schon der komplette Name rein.

    Nennt mich naiv, aber ich verstehe den Sinn eines Kontaktformulars mit anschliessendem Mailversand nicht:

    1. Entweder möchte ich die Anfragen strukturiert bearbeiten, z. B. in einem CRM oder Ticketsystem. Dann sollen die Kundeneingaben in einer DB gespeichert werden und es gibt maximal aus diesem System heraus Hinweismails auf ein neuen Ticket an die Solver-Gruppen.
    2. Oder das ist "kompliziert und knifflig" und der Site-Owner kann nur Mail. Dann reicht es doch auch, nur eine (obfuscated) eMail-Adresse mit mailto:-Link anzugeben, und das ganze Problem des Spam-Versands liegt beim Absender.

    Aber wahrscheinlich mache ich mir die Welt wieder zu einfach :)

    Häufig ist der Sinn eines solchen Kontaktformulars mit anschliessendem Mailversand einfach der, dass der Kunde das haben will und darauf besteht. Dazu will er dann noch ein Reply-To mit der Adresse des Absenders, weil er so am einfachsten darauf antworten kann. Schön wäre natürlich noch eine Möglichkeit, dass sich der Absender eine Kopie zuschicken lassen kann. Hier sehen dann manche nach stundenlangen Erklärungen doch ein, dass das ein Risiko birgt, weil diese Funktion für Spam an wildfremde Personen genutzt werden kann.

    Und oft besteht die Solver-Gruppe aus einer Person, dem Kunden und Auftraggeber. Und der will seine Hinweismail aus dem Ticketsystem auch an keine andere Mailadresse haben als beim Kontaktformular. Siehst du ja schon an dem Beispiel hier im Thread. Und ob Google dann eine Spammeldung wegen der Mail aus dem Kontaktformular oder der aus dem Ticketsystem schickt, macht jetzt keinen so entscheidenden Unterschied. Das Resultat ist identisch. Höchstens dass man hier den Reply-To Header vielleicht eher los wird, aber auch das ist in der Regel nur ein frommer Wunsch. Bei Firmen mit Dutzenden Mitarbeitern mag das durchaus anders ausschauen.

    Zudem können oder wollen viele solche Kunden nicht begreifen, dass der E-Mail Versand heutzutage nicht mehr so unproblematisch funktioniert wie vor 20 Jahren und manche an sich nützliche Funktionen von Spammern gnadenlos ausgenutzt werden. Da kommen dann die Klassiker „Das haben wir schon immer so gemacht", „Das haben wir noch nie so gemacht" und „Da könnte ja jeder kommen". "Ich brauche nur Name, Telefonnummer und E-Mail-Adresse, außerdem will ich nicht in noch ein weiteres System reinschauen müssen, meine Mails muss ich sowieso lesen".

    Dann musst du woanders hin wechseln, zu einem Anbieter, dem es egal ist, wenn er von Google Spam-Meldungen bekommt, was in der Konsequenz dann irgendwann bedeuten könnte, dass der Postausgangsserver der netcup-Webhostings von Google gesperrt wird.

    Das Reply-To kann auch ein Problem darstellen. Hatte ich letztens auch bei einem Kontaktformular, das ich zu Testzwecken über meinen eigenen Mailserver an ein anderes meiner Webhostingpakete verschicken liess. Sobald auf irgendeinem an der Übertragung beteiligten Mailserver rspamd mit Standardeinstellungen läuft, kannst du mit einem Reply-To, das nicht zur selben Domain wie der Absender gehört schon ziemlich nah an einer Einstufung als Spam dran sein. Das dürfte in der Regel der Fall sein, wenn derjenige, der das Formular ausfüllt, dort seine Mailadresse eingeben kann. Bei mir war es der rspamd auf dem eigenen Mailserver :rolleyes: . Der hat die ausgehende Mail analysiert und aufgrund des Reply-To einen Spamheader gesetzt. Das wurde dann vom empfangenden Mailserver mit einem entsprechenden Penalty bei der Einstufung der Mail berücksichtigt.

    Insgesamt kann man wohl festhalten, dass es niemals eine gute Idee ist, eine spamverdächtige Mail an Google, Microsoft und andere große Mailhoster zu verschicken. Auch wenn das entsprechende Empfängerkonto einem selbst gehört. Man sollte nicht um Ärger betteln, schon gar nicht bei Google. Es kann also eventuell schon reichen, die vom Ausfüllenden eingetragene Mailadresse nicht als Reply-To zu setzen, man kann die Mailadresse ja auch als ganz normalen Text mitschicken und so zumindest die Reply-To Problematik umgehen.

    Oder durch einen Wechsel des Site-Owners? Scherz beiseite. Wie werden die Mails verschickt? im wünschenswerten Fall über einen SMTP-Server, im Idealfall über einen SMTP-Server von Gmail. Absender=Empfänger hilft in der Regel auch gegen Spam-Automatismen. Eventuell reicht ja aber schon ein anderer Gmail Account als Absender, den werden sie dann hoffentlich auch sperren ;) , was aber selbst bei Sperrung zumindest das netcup Webhosting selbst nicht betrifft.