Reseller Dedicated Server 64 - Umstieg von 32bit-System

[Gast]

Herr Dornblut, erst einmal Danke für Ihre Antworten!

Ein Sicherheitsnetz in der von Ihnen gedachten Weise gibt es nicht und ich wollte auch darstellen, dass das in dem Sinne auch nicht wirklich einen weiterbringt, da wie gesagt die Umstellung früher oder später aus eigenem Interesse erfolgen sollte und nun einmal technisch durchaus ein Paradigmenwechsel ist und auch gewisse Risiken/Aufwände birgt.

Heisst das nicht faktisch, dass es keinen Weg zurück gibt, so wie ich es eingangs geschrieben hatte? Es gibt zwar theoretisch mit sehr viel manuellen Aufwand einen Weg zurück, aber den will dF nicht gehen und der Kunde wird auch nicht in der Lage sein, diesen selbst zu gehen.
Das Argument, die neue Plattform sei die Zukunft, ist ja durchaus richtig. Der Weg dahin ist es, den ich kritisiere. Beim RP gab es damals ein RP Migrate für den Parallelbetrieb. Das war durchaus hilfreich für eine Umstellung. Sicher nicht perfekt und auch sehr wahrscheinlich viel Arbeit für dF, aber diese Arbeit wurde eben zentral von dF als Service für die Bestandskunden geleistet. Bei der neuen Plattorm muss dies durch den Kunden selbst im voraus (zweiten Server zum durchaus teuren Tarif buchen und manuell Projekt für Projekt umziehen, was für Reseller auch bedeutet, das RP2 noch mal zu spiegeln, Probleme mit Abrechnungn zu bekommen etc.) oder im Ernstfall nach der Umstellung (Fixen von eventuell auftretenden Problemen bei ALLEN Projekten und Sites gleichzeitig in sehr kurzer Zeit) geleistet werden. Mag sein, dass dies ein Resellerproblem ist, der Standard Serverkunde von dF hat vermutlich nicht so viele Projekte pro Server und auch keine RP2 Problematik.
Und doch bleibt für mich nun hängen: es gibt faktisch keinen Weg zurück.

[zero81]

So wie ich es (hoffentlich richtig) verstanden habe, bleiben bei einem Tarifwechsel auf 64-bit die RP-Einstellungen usw. erhalten. Nur bei der Zusammenführung von zwei Servern/Aufträgen müssen die RP-Einstellungen von einem Server manuell neu angelegt werden.

[Gast]

So wie ich es (hoffentlich richtig) verstanden habe, bleiben bei einem Tarifwechsel auf 64-bit die RP-Einstellungen usw. erhalten. Nur bei der Zusammenführung von zwei Servern/Aufträgen müssen die RP-Einstellungen von einem Server manuell neu angelegt werden.

Ja, beim direkten komplett Umstieg bleibt alles erhalten. Wenn Du aber einen sanften Umstieg durchführen möchtest, also erst mal einen Testlauf mit einzelnen Projekten auf dem Server wünscht, dann musst Du einen zweiten Server buchen, dort dann das Projekt hinmigrieren (oder kopieren, was aber dann wieder neue Domainnamen mit sich bringt) und falls etwwas schief läuft, wieder zurück migrieren. Und das Verschieben von Aufträgen von einem RP2 in ein anderes ist auch wieder nur durch die Technik lösbar.
Es gibt schlicht keinen einfachen Weg, die neue Plattform sinnvoll und mit Sicherheitsnetz zu testen. Es wird egal bei welchem Weg im Falle von größeren Problemen immer einen Ausfall der umziehende Site zur Folge haben. Und da auf einen Resellerserver vermutlich nicht nur ein Projekt liegt, multipliziert sich das Risiko und das Zeitfenster für Fehlerbehebungen wird für jedes Projekt dann kürzer.
Klar, kann man das wie dF machen und sagen: hey Kunde, am Zeitpunkt x werden wir migrieren. Da kann einiges vielleicht nicht klappen. Hier ist eine (unvollständige) Liste der Änderungen. Wir sind überzeugt von der neuen Plattform. Wird schon. Ach vorher Dinge bereits umstellen und testen (MariaDB) geht nicht. Das musst Du selbst irgendwie machen. Sorry, ist halt ein kompletter Plattformwechsel, den wir ohne mit Dir vorher zu sprechen entschieden haben. Ob und wann die Dinge, die da noch fehlen kommen, wollen wir Dir nicht sagen, das hat in der Vergangenheit immer Probleme gemacht. Also: viel Glück und nur Mut! Wir sind für Dich da.

PS: da die neue Plattform so toll ist, haben wir auch den Preis erhöht und werden in der alten Plattform nichts mehr machen. Da musst Du Verständnis haben.

[zero81]

Verstehe, das ist natürlich ein Problem, vor dem ich auch bald stehe, sobald die alten PHP Versionen auch in den neuen Tarifen verfügbar sind. Bei uns ist zumindest der Vorteil, dass wir keine Skripts usw. laufen haben, großteils einfache Joomla/Wordpress Seiten, wo ich eigentlich zuversichtlich bin, dass es relativ unproblematisch werden sollte. Das mit MariaDB hab ich bis jetzt nicht ganz durchschaut, laut dF auch kein großes Problem.
RP2 haben wir nur bei einigen Kunden, weil wir den Server damals von jemanden übernommen haben. Ich persönlich würde es sonst gar nicht verwenden, da wir auch nicht darüber verrechnen usw. Der größte Vorteil ist eigentlich nur die Möglichkeit, einen Kundenzugang zu erstellen. Vor allem kriegt man Kunden gar nicht mehr aus dem RP raus, ohne irgendwelche Kündigungen von Domain usw., soweit ich in Erfahrung gebracht habe. Und was mich mit Abstand am Meisten nervt, ist das Fenster der DNS-Einstellungen im RP, welches man nicht mal vergrößern kann. Manchmal möchte ich einen Screenshot machen, um den Kunden die Einstellungen nochmal zu übermitteln (die meisten Kunden haben bei uns keinen eigenen Zugang) und dann kann sich das irgendwie zusammenschneiden.

[masterframe]

Und was mich mit Abstand am Meisten nervt, ist das Fenster der DNS-Einstellungen im RP, welches man nicht mal vergrößern kann.

Du kannst problemlos das Stylesheet anpassen ind alles nach deinen Vorstellungen gestalten.

[zero81]

Hab jetzt in den Scheme Einstellungen nachgesehen, finde dort aber den Wert nicht, mit dem die Höhe des inneren Kästchen mit Scrollbalken gesteuert wird.

[Nils Dornblut]

Herr Dornblut, erst einmal Danke für Ihre Antworten!


Heisst das nicht faktisch, dass es keinen Weg zurück gibt, so wie ich es eingangs geschrieben hatte? Es gibt zwar theoretisch mit sehr viel manuellen Aufwand einen Weg zurück, aber den will dF nicht gehen und der Kunde wird auch nicht in der Lage sein, diesen selbst zu gehen.

Nein, es heißt, dass wir den Rückweg nur im Extremfall gehen würden. Wo dieser liegt ist Einzelfallabhängig.

Das Argument, die neue Plattform sei die Zukunft, ist ja durchaus richtig. Der Weg dahin ist es, den ich kritisiere. Beim RP gab es damals ein RP Migrate für den Parallelbetrieb. Das war durchaus hilfreich für eine Umstellung. Sicher nicht perfekt und auch sehr wahrscheinlich viel Arbeit für dF, aber diese Arbeit wurde eben zentral von dF als Service für die Bestandskunden geleistet. Bei der neuen Plattorm muss dies durch den Kunden selbst im voraus (zweiten Server zum durchaus teuren Tarif buchen und manuell Projekt für Projekt umziehen, was für Reseller auch bedeutet, das RP2 noch mal zu spiegeln, Probleme mit Abrechnungn zu bekommen etc.) oder im Ernstfall nach der Umstellung (Fixen von eventuell auftretenden Problemen bei ALLEN Projekten und Sites gleichzeitig in sehr kurzer Zeit) geleistet werden. Mag sein, dass dies ein Resellerproblem ist, der Standard Serverkunde von dF hat vermutlich nicht so viele Projekte pro Server und auch keine RP2 Problematik.
Und doch bleibt für mich nun hängen: es gibt faktisch keinen Weg zurück.

Also: Mit dem RP gibt es keine wirklichen mir bekannten Probleme beim Wechsel. Hier ändert sich faktisch auch nicht wirklich viel. Daher ist eine solche Lösung hier nicht nötig. Der Vergleich ist also nicht wirklich gegeben.

Wir beschreiben sehr genau vorher was sich ändert, was weiterhin geht und was nicht mehr geht. Nach unseren bisherigen Erfahrungen haben Kunden dadurch ein sehr klares Bild und wissen vorher gut Bescheid.

Wie schon von mir angesprochen, gibt es die Möglichkeit einen Tarif vorab zu buchen und im Zweifel auch die Möglichkeit der Geld-zurück-Garantie. Lassen Sie uns das Thema bitte nicht zu sehr theoretisieren hier, das führt denke ich nicht zu einem zufriedenstellenden Ergebnis. Es gibt die technische Möglichkeit eines sanften Übergangs naturgemäß bei einem Tarifwechsel dieser Art nicht. Da können wir noch lange über theoretische Möglichkeiten diskutieren, sie sind aber leider nicht lieferbar, auch nicht mit wesentlich größerem Aufwand.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Hab jetzt in den Scheme Einstellungen nachgesehen, finde dort aber den Wert nicht, mit dem die Höhe des inneren Kästchen mit Scrollbalken gesteuert wird.

Dort wüsste ich auch keine passende Einstellung. Ich denke, masterframe hat das auf andere Weise gelöst.

Was Sie in jedem Fall machen können ist ein Rechtsklick auf den Scrollbalken und dann auf "Untersuchen" klicken. Dann das passende CSS-Attribut anpassen für den Screenshot. Sicher jetzt nicht die Ideallösung, sollte aber schnell einen Screenshot ermöglichen

Mit freundlichen Grüßen

Nils Dornblut

[masterframe]

Hab jetzt in den Scheme Einstellungen nachgesehen, finde dort aber den Wert nicht, mit dem die Höhe des inneren Kästchen mit Scrollbalken gesteuert wird.

Ah, o.k, die Höhe geht tatsächlich nur mit etwas Trickserei.

[zero81]

Ah, o.k, die Höhe geht tatsächlich nur mit etwas Trickserei.

Ich habs jetzt einfach mit Element untersuchen (Firefox) und Anpassung der Fensterhöhe in Pixel probiert, das scheint soweit zu funktionieren. Hätte ich auch früher draufkommen können danke für die Anregung.

[Nils Dornblut]

Ich habs jetzt einfach mit Element untersuchen (Firefox) und Anpassung der Fensterhöhe in Pixel probiert, das scheint soweit zu funktionieren. Hätte ich auch früher draufkommen können danke für die Anregung.

Kein Problem und gerne. Tut mir leid, dass das aktuell nicht genereller geht.

masterframe : Ich hätte jetzt nichts gegen die Details zur Trickserei, auch wenn sie offiziell von uns nicht supportet wird. Aber vielleicht hilft sie einigen Hilfesuchenden.

Mit freundlichen Grüßen

Nils Dornblut

[masterframe]

Nils Dornblut
Der „Trick“ beruht darauf, dass man das RP2 mittels Apache-Proxy-Direktive tunnelt.
Dann kann mann gezielt einzelne CSS Dateien durch eine lokale Kopie ersetzen und somit Style-Elemente erreichen welche nicht im Editor verfügbar sind.
Wir hatten im alten Forum dazu einen Thread. Kannst du mal bitte gucken?

Oder man arbeitet mit der Entwicklerkonsole. Da kann man auch lokale, permanente Overrides machen. Aber das wirkt sich natürlich nur an dem einen Rechner aus.

[s-mac]

Nils Dornblut und alle Reseller
Ich betreibe derzeit quasi den sanften Umzug auf meinen 64-Resellerserver vom alten 32-Ultimate. Nun meine Frage, die evtl. schon angeklungen ist: Kann ich die alten RP-Einstellungen an einer Stelle übernehmen, auch bei manuellem Umzug, oder muß ich im neuen System das RP neu aktivieren und händisch alle Kunden neu einrichten. Ich stelle mir das so vor, daß ich per ssh die Daten aus rp-hosting übertrage und dann den Übertrag der alten RP-Einstellungen über meinen Ansprechpartner beauftrage. Geht das so?

Herzlichen Dank
Jan

[Nils Dornblut]

Nils Dornblut
Der „Trick“ beruht darauf, dass man das RP2 mittels Apache-Proxy-Direktive tunnelt.
Dann kann mann gezielt einzelne CSS Dateien durch eine lokale Kopie ersetzen und somit Style-Elemente erreichen welche nicht im Editor verfügbar sind.
Wir hatten im alten Forum dazu einen Thread. Kannst du mal bitte gucken?

Oder man arbeitet mit der Entwicklerkonsole. Da kann man auch lokale, permanente Overrides machen. Aber das wirkt sich natürlich nur an dem einen Rechner aus.

Ich habe eben noch einmal gesucht und finde bei der Suchen rund um CSS oder auch Proxy da nichts. Hier bräuchte ich andere Suchwörter. Tut mir leid.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Nils Dornblut und alle Reseller
Ich betreibe derzeit quasi den sanften Umzug auf meinen 64-Resellerserver vom alten 32-Ultimate. Nun meine Frage, die evtl. schon angeklungen ist: Kann ich die alten RP-Einstellungen an einer Stelle übernehmen, auch bei manuellem Umzug, oder muß ich im neuen System das RP neu aktivieren und händisch alle Kunden neu einrichten. Ich stelle mir das so vor, daß ich per ssh die Daten aus rp-hosting übertrage und dann den Übertrag der alten RP-Einstellungen über meinen Ansprechpartner beauftrage. Geht das so?

Da muss ich einmal nachfragen und es meldet sich ein Kollege.

Mit freundlichen Grüßen

Nils Dornblut