Beiträge von tab

    Du könntest die Domains für ein Jahr woanders registrieren und dann zurückhole, dann laufen sie als "neue" domains und können als Inkl. Domains verbucht werden - aber der Aufwand erscheint mir zu groß für 5 EUR / Jahr.

    Ach, der Aufwand lohnt sich schon, wenn man nebenbei noch einen Lockvogelanbieter ein wenig ärgern kann.

    Hey, das klingt gut, auf einen "normalen" RS 1000 G9.5 mit mehr SSD-Speicher hatte ich eigentlich gehofft, um meinen Rentier-Server durch etwas aktuelleres abzulösen. Der hat zwar nur 2 Intel Cores, das reicht aber bisher dicke. Die 4 GB RAM hätten aber nicht gereicht. Da wären mir 10 GB statt wie bisher 8 GB sogar lieber gewesen. Aber ok, 8 GB haben seither meist gereicht. Insofern hatte ich die heutigen Angebote zwar schon abgehakt, aber so wird es plötzlich doch wieder interessant.


    Für 8 Cores und 4 GB RAM hätte ich zwar schon die passende Serverdomain gehabt, aber eigentlich wollte ich nicht Flux beitreten. Wie war nochmal gleich die URL? ;)^^

    Im WCP auf der Startseite, "Globale Verwaltung Konfigurationen des Webhostings". Da steht u.a.

    Code
    MySQL-Server: mysqlxxxx.netcup.net IP-Adresse (extern): xxx.xx.xx.xx IP-Adresse (intern): 10.xx.xx.xx

    Hast du die Datenbankzugangsdaten korrekt angegeben, der Datenbankserver ist hier im webhosting jedenfalls auch garantiert NICHT localhost wie vermutlich lokal.

    Ohne Glaskugel kann ich hier wenig bis nichts erkennen. Schau in die Protokolle der entsprechenden Domain, da sollte irgendwo der Fehlercode 500 erscheinen und mit ein wenig Glück noch eine Zusatzinfo dabeistehen.

    Das kann an vielen Dingen liegen, oft an folgenden


    • Falsche Kodierung von Dateien (z.B. UTF8 mit BOM)
    • Unzulässige Einträge in einer .htaccess Datei. Manche Einträge sind vom System her ausgeschlossen, andere passen vielleicht nicht zur Server-API, also z.B. php_value bei FastCGI oder PHP-FPM.

    Ansonsten ist es halt so, dass der Fehler 500 eine Art "Sammelfehler" ist, also wenn ein Fehler nicht in eine andere Kategorie passt. Oft findet sich in den Apache-Logs eine nähere Info zum Fehler.

    Du vergleichst hier Äpfel mit Birnen, da der Vergleich mit dem genannten Mitbewerber hinkt. Denn vergleicht man es mit dem Tarif Webhosting 1000 mit 100 Postfächern mit regulärem Support für 1,99 Euro oder pro Postfach für 0,02 Euro, so bezahlst du beim Mitbewerber pro Postfach mit regulärem Support 3 Euro.


    Das bei einem Preis von 3 Euro pro Postfach mit regulärem Support schon viel mehr bei herumkommen muß, sollte normal jedem klar sein. Denn nimmt man diesen Preis mal 100 bzw. mal 100 Postfächern, so spült es dem Mitbewerber schon mal 300 Euro in deren Kasse.


    Der Tarif bei dem das Postfach nur 1 Euro kostet, hat im Gegensatz zum Tarif mit dem Preis für 3 Euro keinen technischen Support, sondern bezieht sich nur auf die Buchhaltung und dem Zurücksetzen des eigen Paßworts innerhalb von 48 Stunden nur an Werktagen.

    Ganz abgesehen davon, dass mit den 1,99 für das Webhosting 1000 nicht nur der Mailserver bezahlt werden muss, sondern auch der Webserver. Ganz nebenbei kann das Ding ja auch noch Websites hosten, was beim genannten Mitbewerber schwerfällt.


    Was ist die Erkenntnis daraus: Sehr gute Performance und sehr guten Support gibt es halt nicht zum (Beinahe- )Nulltarif. Kann es auch gar nicht geben.

    Also die einzige öffentliche IPv6, die ich hier im Thread entdecken kann ist die aus deiner

    Code
    /etc/network/interfaces.d/50-cloud-init.cfg

    Die lässt sich über das verlinkte Tool zwar anpingen, aber das Ergebnis sieht nicht so gut aus:

    Code
    The response for '2a03:4000:2:f093:98c8:9dff:fe8a:1adf' using IPv6 is:
    
    PING 2a03:4000:2:f093:98c8:9dff:fe8a:1adf(2a03:4000:2:f093:98c8:9dff:fe8a:1adf) 56 data bytes
    
    --- 2a03:4000:2:f093:98c8:9dff:fe8a:1adf ping statistics ---
    5 packets transmitted, 0 received, 100% packet loss, time 4052ms

    ICMPv6 geblockt? Das sollte man jedenfalls nicht tun.

    Du solltest dich da nicht täuschen lassen dadurch, dass die aktuellen Browser die Eingaben anhand des Input Typs überprüfen. Wenn ein Browser das nicht tut, dann wird eben übertragen was der User in das Inputfeld reingeschrieben hat, egal ob das eine legale E-Mail-Adresse ist oder ein Schadcode. Und natürlich hat ein Hacker Tools, die das Formular ausfüllen und abschicken ohne die Überprüfung des HTML5 Input Typs. Du musst also bei der Auswertung trotzdem darauf achten, dass der übertragene String auch das ist was du haben willst und nicht irgendein Schadcode, den du dann der nächstbesten Funktion als E-Mail-Adresse übergibst. Wenn PHPMailer gut programmiert ist, sollte da aber auch nochmal eine Überprüfung der Parameter passieren.

    Wieso ist die Konstellation anders? Ist es eine Domainendung, die nicht per Auth-Code umgezogen werden kann? Bei manchen TLDs ist z.B. die Zustimmung des bisherigen Eigentümers zur Übertragung der Domain noch in anderer Form erforderlich als einfach per Auth-Code. Bei de-Domains läuft das völlig unproblematisch per Auth-Code ab.

    Danke für die Info.

    Ich habe bei Netcup hierzu mal ein Ticket eröffnet, mal schauen was dabei rauskommt.

    Wenn ich ehrlich bin, möchte ich zur Zeit eigentlich nur eine Webseite erstellen und mich nicht auch noch in die Linux Administration einarbeiten.

    Also mit Linux-Administration hat das ja nichts zu tun. Könntest du ja im Webhosting auch gar nicht machen. Ein Ticket kann aber sicher nicht schaden, obwohl, wenn ich ehrlich bin, ich finde es doch wesentlich umständlicher, Plesk zu benutzen für den composer. Composer benutze ich täglich, aber den im Plesk habe ich bis heute noch nicht wirklich verstanden. Wenn ich den die composer.json für eins meiner Projekte suchen lasse, dann findet er immer eine drei Ebenen tiefer. Klar, die gibts auch, aber mein Projekt kann die allein nicht updaten, die ist ja nur für eine Komponente zuständig, also WTF? Die composer.json des Projekts, einige Verzeichnisebenen drüber, hätte er da schon lange vorher gefunden haben müssen. Plesk ist bestimmt ganz toll, man müsste es nur verstehen. Und das will mir über die Webhosting-Grundfunktionen hinaus nicht gelingen. Ich sehe da nur überall Krücken und Hilfskonstruktionen. Sowohl bei Wordpress, node.js als auch Composer.

    Vielleicht sagt Tobles nach über einem Jahr (und 1 Beitrag) ja noch was dazu.

    Ansonsten mache ich solche Sachen auf der Kommandozeile per SSH. Da habe ich alle Freiheiten, welche Composer-Version ich nutzen will für welches Projekt. Nicht so komfortabel vielleicht wie die Plesk-Lösung, aber wenigstens funktioniert es dann.

    Also allereinfachste Variante: Im Projektverzeichnis eine composer.phar platzieren und sicherheitshalber in composer.phar.php umbenennen. Dann Aufruf des Composers per (z.B.)

    Code
    php composer.phar.php update

    Damit kann man auch alle Möglichkeiten des Composers nutzen und nicht nur das, was Plesk zur Verfügung stellt.

    Die ignoriere ich seit nem Jahr :D

    Das beste war der "INTERNED_STRINGS_BUFFER" oder so ähnlich. Da wurde dann geraten, den ursprünglichen Wert mal zu verdoppeln, obwohl die eingestellten paar MB eigentlich reichen sollten. Ich war irgendwann im mittleren GB Bereich allein für diese Strings, seitdem ignoriere ich das auch. Machen alle anderen Nextcloud Nutzer seit der ersten Version auch so. Der eingestellte Wert hat wohl seit der ersten Version noch nie gereicht, aber erst seit kurzem prüft die Nextcloud den Status des OPCache und spuckt dann die Warnungen aus. :D:D