Posts by epi

    Hab gerade die gleiche Frage und frage mich, ob da nicht der netcup AGB Absatz 6.1 greift:

    Quote

    Soweit nicht anders vereinbart, werden Verträge auf unbestimmte Zeit geschlossen. Solche Verträge sind von beiden Parteien mit einer Frist von einem Monat zum Monatsende kündbar, frühestens jedoch zum Ablauf einer vertraglich vereinbarten Mindestlaufzeit

    Die Verlängerung um 12 Monate wird explizit nur im AGB Absatz 6.2 erwähnt für Verträge mit 24-Monatiger Laufzeit - was bei mir nicht der Fall ist.


    (Habe schon über ein Jahr einen RS 4000 SSD G8 a1 12M, die Mindestlaufzeit ist also bei mir abgelaufen)

    Laut CCP:

    Nächste Abrechnung: 27.08.2020

    Text im Kündigungs-Tab: "Kündigung zum 26.02.2021 eintragen (Rückerstattung nicht genutzter Monate): [Button: Produkt regulär kündigen]"


    Eigentlich hätte ich das jetzt so interpretiert, dass ich entweder über das CPP per "Produkt regulär kündigen" den Server zum Ende des 12-Monats-Intervalls kündigen kann, oder über den Support gemäß AGB 6.1 zum Ende des nächsten Monats (unter Rückerstattung der nicht genutzten Monate).

    Stimmt es wirklich, dass AGB Absatz 6.1 für 12monatige Root-Server nicht greift?

    Boah, die Domains sind sicher handgestrickt "Made in Germany".

    Korrekt - gegen Aufpreis werden die zugehörigen Webhostingtarife in Deutschland* betrieben.


    * teilweise gemanaget aus der Ukraine

    Das Problem hatte ich auch. Dein Hoster hat aktuell Probleme mit .eu und du löst dies über ein Supportticket und fragst um die Erstellung eines neuen Authcodes. Andere Domains gehen wie üblich direkt im RP.

    Die Bestellung im Warenkorb und Eingabe erst später ist die richtige Lösung dafür.

    Danke - das mit dem Warenkorb hab ich so gemacht, und das Problem mit den Authcodes vertagt. Vielleicht war unser alter Provider gestern von Umzugsanfragen für .eu-Domains überhäuft worden? (Wer ist schon von der Perspektive begeistert, ab in einem Monat 21,48€/Jahr pro .eu-Domain zu bezahlen...? Plus 59,88€/Jahr pro Domain Validated SSL-Zertifikat - da es dort kein Lets Encrypt gibt? (Listenpreise - evtl zutreffende Rabatte nicht berücktsichtigt))

    Das verrät mein alter Anbieter leider nicht. Gekündigt habe ich vor 50 Minuten - aber es wurden schon davor irgendwelche Auth-Codes für die Domains angezeigt - ich weiß aber nicht, ob es die gleichen waren. Zum Erneuern der Codes sehe ich leider keine Funktion im Admin-Panel.


    Aber zum Verständnis: Für .eu-Domains muß direkt bei netcup ein AuthCode angegeben werden?

    Frage des Tages: wie transferiert man als Reseller eigentlich eine .eu-Domain zu netcup?

    Wenn ich im CCP bei der Registrierung den Authcode angebe, bekomme ich die Meldung "Invalid authorization information: Authorisation code is expired. Bitte wenden Sie sich an unseren Support."
    Wenn ich keinen angebe, kommt die Aufforderung, einen einzugeben.

    Der angegebene Authcode ist so direkt aus dem Admin-Bereich eines anderen Hosters rüberkopiert (direkt, nachdem die Domain dort gekündigt wurde).

    Läuft der Domaintransfer bei .eu-Domains nicht eigentlich so, dass man den Authcode erst in ein Online-Formular eingeben muß, dessen Link man per Mail bekommt?

    Was tun?

    Ich hatte heute ebenfalls das Problem, dass seit dem Abspeichern der PHP-Einstellungen (Umstellen von PHP 7.2 auf 7.4) für eine Domain besagtes open_basedir-Problem auftrat. Die Einstellungen auf die vorherigen Werte zurücksetzen brachte keine Linderung - wohl aber das Umstellen auf /var/lib/php5/sessions (bisher nie verwendet!) . Von daher scheint es tatsächlich, als wäre da gerade ein kleiner Bug...

    Ich würde es mal so deuten:

    Mit den Black Friday und Adventangeboten testet netcup, wieviel SSD-Space die aktuelle Intel-basierte Hardware unter realen Anwendungsfällen verkraftet. (Irgendwo stand, dass Gen7 zu viel SSD-Space hatte, was sich negativ auf die Performance ausgewirkt hat, und das es deshalb bei Gen8 weniger SSD-Space gab)

    Auf Basis dieser Tests gestaltet dann netcup im neuen Jahr die nächste Generation.


    Evtl. sind sie auch am überlegen, ob als Alternative zu den SSD-RS eher RS mit HDD+Optane Sinn machen, oder RS-Tarife à la Mamba/Pearl/Rentier (=sehr viel SSD, ordentlich RAM, wenig CPU)


    Auf mehr SSD bei den regulären SSD-RS können wir wohl schon hoffen - mit 14-Kernern würde eher nicht rechnen (Hab ich das richtig in Erinnerung - wegen Spectre/Meltdown vergibt netcup nur noch ganze CPU-Kerne - und davor wurden durchaus mehrere Threads pro Kern genutzt?)

    Ich hab wahrscheinlich in den nächsten Monaten den Anwendungsfall, 50-80 Domains zu netcup umzuziehen.

    Da liegt natürlich die Idee nahe, dafür ein Hilfsscript zu bauen, das dies schnell erledigt.


    Ein Studium der API-Doku lässt mich dabei vermuten, dass an zwei Stellen manuelle Nacharbeit nötig wäre (die den Sinn des Hilfsscripts infragestellen):

    • Es gibt bisher keine Funktion, um eine Domain einem Webhostingpaket zuzuweisen (und zwar weder den normalen Webhosting x000, noch den Reseller Webhostingpaketen) - richtig?
    • Es ist immer noch nicht möglich, Domains zu registrieren/transferieren, ohne eigene Nameserver zu betreiben (bzw anschließend für jede die Standardeinstellung manuell wiederherzustellen) - richtig?


    Sind derartige Funktionen in Planung?


    Nebenbei: Diese beiden Funktionen sind meiner Meinung nach nötig, damit die API-Funktionen nicht nur von Groß-Resellern sinnvoll verwendet werden können (die eigene Web-, Mail- und DNS-Server betreiben), sondern auch von den kleineren, die es vorziehen, die Technik (Webhostingpakete) fertig bei netcup einzukaufen. Dies sollte doch auch im Interesse von netcup sein!

    Noch eine Anregung: Kannst du Netzwerkstörungen als Ursache ausschließen? Falls nein, könntest du in deinem Browser HTTP/2 abschalten und schauen, ob es dadurch besser wird!


    HTTP/2 beschleunigt bei fehlerfreier Verbindung die Übertragung - sobald Übertragungsfehler auftreten, wird die Übertragung deutlich langsamer als bei HTTP/1, weil bei HTTP/1 in der Regel mehrere unabhängige Verbindungen parallel aufgebaut werden, und bei HTTP/2 alles über eine Verbindung geht - und wenn es da eine Störung gibt, ist erstmal alles blockiert - Stichwort: TCP Head Of Line Blocking

    mit Basisordner meine ich den neu angelegten www-Ordner.

    Gegen httpdocs spricht, dass neu jede neu registrierte Domain (oder neu angelegte Subdomain) erstmal dorthin zeigt, und - solange sie nicht geändert wird - dann sämtliche Inhalte des httpdocs-Ordners dann darüber greifbar sind.

    ... oder noch besser:

    • eine Baustellen-Seite in den httpdocs-Ordner packen
    • die eigentlichen Installationen in einen gemeinsamen Basisordner, also z.B. /www/website1 , /www/website2, ...

    --> diese Lösung schützt davor, versehentlich oder temporär Domains oder Subdomains zu haben, die den Basisordner komplett freigeben

    Mir ist nicht bekannt, dass mir ein Passwort abhanden gekommen wäre. Und vor allem: wenn jemand meinen Server hart abgeschaltet hätte, dann müsste das doch einen Log-Eintrag im SCP ergeben - oder?


    Also doch ein Problem von Netcup?

    Der Support meint: Am Wirtssystem sind zum genannten Zeitpunkt keine AUffälligkeiten zu beobachten.

    Also wohl doch ein Kernel Panic ohne Log-Eintrag?


    Ansonsten ist bei mir bei "Autostart aktivieren" bereits ein grüner Haken gesetzt.


    H6G : "eingmal fehlgeschlagen" heißt: Der Server wurde trotzdem nicht gestartet?

    Was hat es zu bedeuten, wenn ein RS 1000 G8 im SCP plötzlich auf gestoppt steht (und es im SCP keinen Log-Eintrag dafür gibt)?

    Der Server ließ sich wieder starten - die Logfiles sehen so aus, als wäre der Server hart angehalten worden (liegengebliebene PID-Files, einzelne Application-Logs inkonsistent, aber keinen Hinweis auf ein inkonsistentes Dateisystem). Ich hab keinen Hinweis auf einen Kernel Panic oder einen misslungenen Kernel-Patch (canonical-livepatch) gesehen.


    Auf dem Server läuft ein LAMP-Stack unter Ubuntu 18.04 ( Linux 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ).


    War das wohl ein Problem des Hostsystems, oder doch ein Kernel Panic (der keine Log-Einträge mehr schreiben konnte) - oder kann man letzteres ausschließen (müsste da der Status auf gestartet bleiben?)


    Gibt es etwas, was ich tun kann, um die Situation bei einem wiederholten Auftreten zu verbessern (also entweder für ein ausführlicheres Logging sorgen, oder dafür, dass der Server von selbst wieder startet - was ja eigentlich im SCP so eingestellt ist)?


    Oder (was mir jetzt erst kommt) startet der Server aus dem Grund nicht automatisch, damit ich (vor einem Neustart) die Möglichkeit habe, einen Blick auf die SCP-Konsole zu werfen? Oder zeigt diese im gestoppten Zustand sowieso nix mehr an?

    Ok - Danke für alle Antworten - falls es ein zukünftiger Leser benötigt - hier meine .htaccess-Lösung:

    Code
    1. RewriteRule .* - [E=SCRIPT_URI:http://%{HTTP:Host}/$0]
    2. RewriteCond %{HTTPS} on
    3. RewriteRule .* - [E=SCRIPT_URI:https://%{HTTP:Host}/$0]
    4. RewriteCond %{ENV:REDIRECT_SCRIPT_URI} .
    5. RewriteRule .* - [E=SCRIPT_URI:%{ENV:REDIRECT_SCRIPT_URI}]

    (unter der Annahme, dass RewriteBase auf / sitzt - ansonsten muss die RewriteBase vor $0 jeweils eingefügt werden)

    (Zeilen 4+5 sind nötig, damin die Variable auf den Wert vom 1. Durchlauf der RewriteRules gesetzt wird)

    Ich brauche die Variable, da ich eine Software entwickelt habe, die in verschiedenen Umgebungen laufen können soll (bei einem anderen Webhoster, und auf einem Ubuntu-Server (Version 18.04), auf dem ein Apache/2.4.29 mit PHP-FPM läuft - dort mit SCRIPT_URI...)


    In der Vergangenheit hatte ich schonmal die Software umbauen müssen, da die entsprechenden Variablen nicht überall vorhanden waren - und damals was SCRIPT_URI überall vorhanden!

    SCRIPT_URI ist außerdem die einzige Server-Variable, die einem gleich eine fertige URL samt Protokoll liefert - mit anderen Variablen muss man sich das selbst zusammenbauen, also z.B. grob so:

    Code
    1. $script_uri = (isset($_SERVER['HTTPS'] ? 'https://' : 'http://') . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF'];


    Von daher: Wenn irgendjemand eine Lösung hat, wie man SCRIPT_URI aktiviert, wäre das schön - ansonsten muss ich mal schauen, ob ich es umbaue (oder vielleicht kann man die Variable ja auch per .htaccess-Eintrag setzen?)


    Ansonsten: Falls es sonst wer braucht, der diesen Thread findet - hier die Unterschiede der Variablen am Beispiel eines Direktaufrufs von http://example.tld/dir/test.php/xxx?a=b (was passiert, wenn noch RewriteRules ins Spiel kommen, hab ich hier jetzt nicht berücksichtigt)

    SCRIPT_URI http://example.tld/dir/test.php/xxx
    SCRIPT_URL /dir/test.php/xxx
    SCRIPT_FILENAME /var/www/vhosts/hosting123456.abcde.netcup.net/installationsverzeichnis/dir/test.php
    REQUEST_URI /dir/test.php/xxx?a=b
    SCRIPT_NAME /dir/test.php
    PATH_INFO /xxx
    PHP_SELF /dir/test.php/xxx
    HTTP_HOST example.tld

    Hallo,

    hat jemand eine Idee, was man tun muss, um in PHP-Scripten bei netcup die Variable $_SERVER['SCRIPT_URI'] wieder gesetzt zu bekommen?

    Meines Wissens wird diese Variable von Apache mod_rewrite gesetzt, wenn die RewriteEngine aktiviert ist (Zeile RewriteEngine On in .htaccess).

    Dies hab ich in meiner .htaccess.


    Ich verwende PHP 7.2.16 als "FPM-Anwendung von Apache bedient" auf einem Webhosting 8000 Paket;

    nginx-Apache-Proxymodus: an;

    Intelligente Bearbeitung statischer Dateien: an;

    Statische Dateien direkt durch nginx bedienen: aus


    Mach ich da was falsch, oder gibt es da eine grundsätzliche Einschränkung bei netcup?


    Danke.