Aber bitte in einem eigenen Thread!
![]()
Aber bitte in einem eigenen Thread!
![]()
Ich glaube Homwer geht es eher darum, dass seine Domains ebenfalls mal Aktionsdomains waren. Das war nämlich streng genommen die dritte Preisanpassung in wenigen Monaten. Oder geht es um eine andere Geschichte?
So ganz kann ich das auch nicht mehr verstehen, die Kritik ist meiner Ansicht nach berechtigt. Dass sich einige Aktionsdomains um ca. 10 €/Jahr nicht mehr gelohnt haben, kann ich noch nachvollziehen. Aber letztens wurden ja alle COM-Domains auf einen einheitlichen Preis angehoben, weil es laut netcup unter dem Einkaufspreis liegt. Ich persönlich will mich explizit nicht beschweren, aber nachvollziehen kann ich die Kritik schon. Die genannten Gründe wirken so nicht sehr plausibel.
Bud Installiere Dir doch erst einmal alles in einer VM auf Deinem PC, oder auf einem alten PC, Raspberry Pi, … usw. – da kannst Du genauso üben, allerdings gefahrlos und es kostet erst einmal nichts. ![]()
(z.B. mit VirtualBox)
Sorry, Doppel… ähm Dreifachpost. ![]()
Du hast also das als Produkt? Ok, das ist wohl ein Sonderfall und ein Wechselangebot auf die neuen Plesk-Tarife.
Du hast somit wahrscheinlich recht, Du verwendest bereits Plesk, wie bei den aktuellen Tarifen. Sorry für die Verwirrung.
Ok, anders gefragt: Wo landest Du, wenn Du im CCP den Autologin zum Webhosting verwendest?
Weil das ergibt keinen Sinn. Dein Tarif hat "Expert" im Namen, das müsste ein älterer Expert-Tarif sein. ![]()
gmk Der gleiche Wert steht also beim Return-Path und deutet auf eine Domain hin, die netcup verwaltet? ![]()
Oder liest Du da fälschlicherweise den SRS-Teil vom Google-Server heraus?
Mein Tarif heißt "Expert M int 2018". Keine Ahnung ob es ein "Expert-Hostingtarif (PPA)" oder ein "aktueller Hostingtarif (Plesk)" ist. Wie kann ich es unterscheiden?
PPA steht wahrscheinlich für Parallels Plesk Administration, das wurde tatsächlich nur bei den Expert-Tarifen verwendet und von netcup gerne auch als Webhosting-Cloud bezeichnet.
Du kannst das, unabhängig vom Produktnamen (*), mit dieser Information ganz leicht unterscheiden:
Die alten Confixx-Tarife erwähne ich hier nicht mehr, die sind sowieso schon fast alle gekündigt und waren eindeutig als Confixx erkennbar.
* Wenn der Tarif "Expert" im Namen hat, ist es auch ein Expert-Tarif. Blödsinn, siehe weiter unten.
Ich frage mich gerade, ob bzw. wie ich in Proxmox VE irgendwie ein iSCSI-Storage einbinden kann, das nur für wenige Stunden in der Woche online online ist. Der müllt mich nämlich im Sekundentakt mit Meldungen zu und das nervt:
pvestatd: storage 'example' is not online
iscsid: connect to 10.1.2.3:3260 failed (Connection refused)
Bei SMB/CIFS Storages habe ich das immer so gelöst, dass ein Script mittels Cronjob prüft, ob das Zielgerät erreichbar ist und dazu passend pvesm set <STORAGE> --disable <VALUE> ausgeführt wird. Das reicht hier aber nicht, ich könnte maximal noch ein iscsiadm -m node -T <TARGET> -p <IP>:3260 -u nachschieben.
Die einzige andere Idee, die ich noch hätte: iSCSI direkt in der VM verwenden, dann kann es mir egal sein. Das RootFS liegt sowieso nicht auf einem iSCSI-Device.
Fällt euch noch was ein, was ich vielleicht übersehe? ![]()
Habt Ihr vielleicht eine Idee, wie man es näher eingrenzen kann?
Auch mit einem neuen User und einem neuen Passwort kommt der gleiche Fehler.
Probier es mal über SSH mit dem nachfolgenden Befehl:
Das Passwort wird dabei interaktiv abgefragt, das muss man nicht direkt als Argument angeben.
Wenn es damit auch nicht klappt und die Fehlermeldung identisch ist, würde ich den Support kontaktieren.
Das ist prinzipiell vom CPU-Modell abhängig, das für die VM konfiguriert ist: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
Bei einer virtuellen CPU sind relativ wenig Flags standardmäßig aktiv, was historisch glaube ich daran liegt, dass sie garantiert auf jeder Hardware existieren und Live-Migrationen problemlos möglich sind. Zusätzliche Flags müssen immer erst konfiguriert werden, um verfügbar zu sein. Explizit deaktiviert hat die somit eher niemand. Dementsprechend würde ich den Support einmal fragen, ob man das Flag bei den VPS nicht generell in Betracht ziehen könnte. Mehr als eine Absage kannst Du eigentlich nicht kassieren. ![]()
mapled Und Benutzername/Passwort stimmen garantiert überein? Eventuell irgendein Leerzeichen zu viel oder Groß-/Kleinschreibung vertauscht?
Ist aber trotzdem seltsam, das bei der Fehlermeldung die IP des Webservers auftaucht, obwohl er die korrekte IP des DB-Servers als 'dbhost' eingetragen hat.
USER@HOST ist bei MySQL-Fehlermeldungen immer die Source-IP bzw. Hostname des Clients, da die Berechtigungen ja darauf basieren.
Was ist daran seltsam? ![]()
Hast Du beim DB-User die Remoteverbindung für einen beliebigen Host zugelassen? Da es sich um einen anderen Server handelt, ist das zwingend notwendig!
Siehe: https://www.netcup-wiki.de/wiki/Plesk_Ony…utzerverwaltung
Größer als Webhosting 8000 wirds auch nicht mehr.
Beim normalen Webhosting nicht, maximal die erwähnten Managed PS: https://www.netcup.de/professional/m…ivateserver.php
Die grundlegende Frage wäre einmal: Hast Du das nötige Wissen (und Zeit), um einen Server selbst zu administrieren? Denn die genannten VPS/RS Produkte sind keine Managed Produkte, da bist Du für alles selbst verantwortlich, von der Installation und Konfiguration des Betriebssystems sowie der benötigten Serverdienste bis zur andauernden Pflege!
Wenn die Antwort darauf NEIN ist, bleibt eigentlich nur das Webhosting Produkt übrig. (Oder maximal ein Managed PS.)
Mein VPS 200 G10s hat genau die gleichen CPU-Flags.
Das ist nicht das CCP sondern das SCP.
Das bezog sich wohl darauf:
wuerde schon helfen wenn der auch in der drop-down-liste links oben im scp angezeigt wird
Kann man doch einstellen:
[…] weil dig ja funktionierte […]
Ja, über UDP laut Deiner Ausgabe. Oder hast Du es auch mit dem TCP-Flag getestet? ![]()
Wundert mich etwas, weil ich nach dem Aufruf die Einträge bei Netcup direkt sehen und auch abfragen konnte, aber wer weiß wie lang das nach außen braucht.
Dann hattest Du Glück, denn die Zonen werden definitiv nur alle 10 Minuten generiert. Erst dann springt auch die Spalte "gültig" im CCP auf "yes". Ich würde sicherheitshalber immer die doppelte Zeit einplanen.
Ist die private IP-Adresse 192.168.171.2 von Deinem Setup? Da ist also irgendwo eine NAT dazwischen?
Kannst Du von dort aus wirklich den Nameserver erreichen? Über TCP und nicht UDP, denn das wird in der Meldung bemängelt.
Würde ich auch praktisch finden. Aber ich fürchte das ist eine andere (strikt getrennte) DB.
(SCP-Autologin und rDNS-Änderungen u.ä. Dinge laufen wahrscheinlich über eine interne API?)