Beiträge von te-online

Ja, damit hast du natürlich recht

Aber es ist halt immer schwierig, ich bin bei solchen Problemen einfach manchmal zu wenig hartnäckig, dafür pragmatisch.
Es handelt sich ja bei beiden Servern um Shared Hosting, sodass ich nicht weiß, wie was überhaupt konfiguriert ist. Die Berechtigungen wurden halt exakt so vom alten Server übernommen, ich kann es ja im FTP-Programm sehen. Wenn ich aber erst alles auf meinen Rechner runterlade und dann wieder auf den anderen Server hochlade, werden die Berechtigungen entsprechend angepasst. Nach welchem Schema und warum, weiß ich aber nicht und wüsste auch nicht, wie ich das herausfinden könnte...

Die Lösung kann manchmal so einfach sein:

Habe den gesamten Webspace einfach ganz altmodisch auf meinen Rechner heruntergeladen und dann wieder hochgeladen. Die Berechtigungen wurden automatisch angepasst – keine Ahnung wie diese Magic funktioniert

Problem gelöst, hat nur länger gedauert.

Danke für den Link. Das wusste ich auch schon. Ein Ändern der Zugriffsberechtigungen ist wohl auch die Lösungen. Bei Ordnern habe ich statt 710 755 als erfolgreich getestet, bei Dateien muss es von 640 auf 754 geändert werden. Auf jeden Fall müssen"others" Leserechte erhalten.

Jetzt frage ich mich natürlich, weil ich was lernen will ;), wie die bei DF die Server konfiguriert haben, damit das so da funktioniert hat.
Gibt es außerdem eine Möglichkeit die Änderung mehr oder weniger zu automatisieren, ohne allen Dateien die selben Zugriffsrechte zu geben?

Hallo zusammen,

habe eine WordPress-Installation bei DomainFactory. Diese soll jetzt bei Netcup laufen. Leider will der Umzug nicht so richtig klappen (und das ist nicht der erste Umzug, den ich mache).

Mein Vorgehen (vielleicht liegt hier irgendwo der Fehler): Habe beide Server per SSHFS auf einem Debian-System eingebunden, dann rsync von einem zum anderen eingebundenen Laufwerk gemacht mit den Parametern -r, --progress und --perms. Dann die wp-config.php angepasst. Die Permissions der Dateien und Ordner sind exakt die gleichen wie auf dem Quellserver (mit FTP-Programm nachgesehen).

Jetzt erhalte ich, egal welche Datei ich aufrufen möchte, die Fehlermeldung "403 Forbidden".

Die Logs sagen dazu gar nichts, obwohl zwischendurch mal Fehler auftauchten, dass er eine htaccess-Datei in einem Verzeichnis nicht finden könne – den Fehler gibt es aber jetzt schon seit einigen Aufrufen auch nicht mehr. Ich musste die Domain jetzt wieder auf den alten Server zeigen lassen, daher kann ich's jetzt im Augenblick auch nicht mehr testen. Möchte erst einen neuen Versuch starten, wenn ich neue Anhaltspunkte habe.

Es handelt sich um ein ExpertM-Hosting. Für die Domain habe ich jetzt mal testweise alle Optionen aktiviert und PHP 5.6 als FastCGI-Applikation eingestellt. Habe aber auch schon andere Optionen durch, das hat jeweils nichts verändert.

Woran könnte das liegen? Hat jemand eine Idee?
Wie kann ich beim Kopieren sicher gehen, dass wirklich alle Zugriffsrechte korrekt übernommen werden (vermute immer noch, dass der Fehler da irgendwo liegt)?

PS: Vermutlich ist das gar nicht die richtige Kategorie hier, aber was passenderes fiel mir nicht ein – ansonsten bitte verschieben

Hallo,

das sind gute Neuigkeiten!

rsync für schnelle Backups wäre noch toll, aber das wurde in der Vergangenheit schon abgelehnt – ich kann es ja trotzdem noch mal versuchen

Viele Grüße

Zitat von [netcup] Felix

Bei Servern mit Management oder Webhosting haben wir uns um den Austausch der Zertifikate bemüht, sofern erforderlich.

Prima, als Webhosting-Kunde kann ich mich dann also zurücklehnen, da mein Zertifikat nicht ausgetauscht wurde ("nicht erforderlich").

Danke für die Auskunft und schöne Ostertage

Bedeutet also jetzt, dass Kunden, die keine Mail erhalten haben, nicht betroffen waren?

Maßnahmen können ja sowieso nur Server-Kunden selbst durchführen. Für die Hosting-Pakete dürfte also wahrscheinlich gelten, dass diese im Wesentlichen nicht betroffen waren (hier läuft ja auch teils CentOs)? Also könnte ich die Mail von meinem SSL-Anbieter bzgl. der Erneuerung des Zertifikats ignorieren?

Danke schon mal für eine Antwort

PS: Jetzt sehe ich auch, dass dieser Thread im Server-Forum ist... Ich bin da einfach nicht sehr geschickt in der Themenzuordnung Vielleicht kann mir trotzdem jemand meine Vermutungen bestätigen?

Hallo,

ich möchte noch mal kurz hierauf zurück kommen, falls andere vielleicht das gleiche Problem haben.

Das Problem ist einfach nur die FTP-Verbindung, die ich mit FileZilla (auch mit UTF-8 erzwungen) einfach nicht zu UTF-8 überreden kann.
Die SSH-Konsole scheint auch Probleme in der Richtung zu haben, da ich dort ebenfalls keine Umlaute eingeben oder anzeigen kann - trotz gewähltem UTF-8.

Lösung: Mit SFTP funktioniert die Dateiverwaltung wie gewohnt - auch mit Umlauten.

Laut dem letzten Stand, den ich vom Support habe, wird an der Sache gearbeitet.

Falls es doch ein Bedienungsfehler sein sollte, freue ich mich über Hinweise!

Ein schönes Wochenende

Vielen Dank! Bei mir funktioniert es jetzt.

Danke für die Antworten!

Eigentlich bin ich es auch gewohnt, keine Umlaute in Ordnern und Dateien auf dem Server zu verwenden.

Ich kann gerne mal sagen, worum es konkret geht. Das hat dann aber endgültig nichts mehr mit dem Control Panel zu tun.

Auf meinem Business-Paket habe ich ownCloud installiert und die Software legt Ordner, die der Benutzer erstellt, genauso auch auf dem Space an - also mit Umlauten. Das funktioniert bisher problemlos.
Das habe ich jetzt auf dem neuen Webspace auch probiert und bin auf das Problem gestoßen, dass die vom anderen Webspace kopierten Ordner mit Umlauten nicht korrekt erkannt werden.
Also habe ich in ownCloud auf dem neuen Webspace einen Ordner erstellt und der erscheint dann eben mit den falschen Umlauten.

Jetzt frage ich mich, welche Konfiguration dafür sorgt, dass es bei den "alten" Paketen geht, bei den neuen aber nicht?

Ich werde auch mal nachfragen, wie die Entwickler bei ownCloud sich das vorgestellt haben...

Im Moment habe ich beim neuen Expert-Tarif das Problem, dass PHP-Skripte keine Ordner mit Umlauten erstellen können.
Vielleicht ist das nicht die richtige Rubrik dafür, aber ich dachte mir, es könnte vielleicht eine Einstellmöglichkeit geben, die ich bisher übersehen habe?

Um den Fehler zu Reproduzieren:
- Eine PHP-Datei auf dem Webspace anlegen mit folgendem Inhalt

<?php
mkdir( 'hällo' );
?>

- Datei im Browser aufrufen
- Per FTP auf dem Server nachschauen
- Es liegt dort jetzt ein Ordner mit dem Namen "hällo"

Wie bringe ich Skripte dazu standardmäßig UTF-8-Ordner zu erstellen?

Weitere Informationen:
Ich nutze für die Domain, bei der der Fehler auftritt folgende Einstellungen:
Hosting-Einstellungen
- Haken bei SSL-Unterstützung
- Haken bei SSI-Unterstützung
- PHP als Fast-CGI-Applikation mit PHP 5.5
sonst keine Haken

Alle anderen Einstellungen sind auf "Standard".

Viele Grüße und vielen Dank vorab

Sehr gerne, anbei ein Screenshot. Ich habe jedoch die E-Mail-Adresse überdeckt. Als Benutzername habe ich ebenfalls die Mail-Adresse gewählt. Diese existiert auch ganz sicher so inkl. Postfach im ControlPanel.

In Thunderbird funktioniert alles, mit der Mail-App nur unverschlüsselt über Port 143.

Danke für die ausführliche Reaktion!

Sie haben Recht, der Preis ist nicht das Problem. Ich stimme ebenfalls zu, dass der Expert-Tarif sehr viele Einstellungsmöglichkeiten bietet - zu viele für die meisten Standard-Projekte (aber genau richtig für umfangreiche Projekte).
Die Standardpakete wären von den Features her oft absolut ausreichend. Ich kann aber konkret nennen, woran es im Moment mit einem Standard-Paket scheitert:

- In der Produktbeschreibung steht, dass sich die Document-Root nicht ändern lässt. Der Support sagte mir auf Nachfrage, das sei technisch bedingt, aufgrund der Verwaltungsoberfläche und preislich bedingt. Auch für ein normales Projekt ist mal eine Subdomain mit anderem Verzeichnis nötig. Vielleicht kann man das auch mit einer passenden htaccess nachbilden, aber das kann nicht der Sinn der Sache sein. Absolut nachvollziehbar, dass man für 1,49 / Monat 24 Monate Vertragslaufzeit und einige Einschränkungen voraussetzt. Aber wenn Sie 1 Euro draufpacken und z.B. 3 statt einer Datenbank und veränderbare Dokumentenverzeichnisse anbieten, sind der Preis und die wesentlichen Leistungen nah am früheren Business-Paket - und das wäre perfekt.

Der zweite Punkt hat sich, wie ich sehe, erledigt. SSL-Zertifikate. Im Augenblick finde ich keinen Hinweis darauf, dass die Standard-Pakete keine SSL-Zertifikate unterstützen. Das hatte ich falsch in Erinnerung. Das ist schon sehr gut!

Interessant wäre ja vielleicht so ein "Leistungsboost" wie es ihn früher mal gab, der vielleicht 2 zuätzliche FTP-User und 2 zusätzliche Datenbanken und veränderbare Document-Roots enthält. Da ist man dann aber preislich sicher wieder schnell bei den Expert-Tarifen - tja, es wird nicht einfacher

Viele Grüße

Zitat von crizzler

Tariflich ist für mich leider nichts dabei... es fehlt mir ein Tarif zwischen Web Standard XL und Web Expert M.
Quasi ein Standard XL mit Expert Features. Vielleicht tut sich ja da was noch? Aber ansonsten Top Angebote.

Genau der gleichen Meinung bin ich auch. Für kleine Projekte sind die Expert-Tarife zu umfangreich/teuer, bei den Standard-Tarifen fehlen jedoch wichtige Features wie SSL-Zertifikate oder beliebige httpdoc-roots.

Es ist für mich äußerst schwierig, Kunden jetzt für Einzelprojekte ein passendes Hosting bei Netcup zu empfehlen. Entweder ich buche ein weiteres großes Paket und muss selbst stückeln und weitervermieten (höherer Aufwand) oder ich empfehle einen anderen Hoster (auch Einarbeitungsaufwand bzgl. der Konfiguration für mich). Vielleicht ist ja noch ein "Zwischenpaket" in Planung?

Genauso müsste es funktionieren.

Wenn Du die Domains in Confixx auf einen beliebigen Ordner auf dem Webspace zeigen lässt, bekommt niemand was davon mit. Der Inhalt dieses Ordners ist direkt über diese Domain erreichbar ohne Unterordner, Weiterleitungen o.ä. Von außen ist davon absolut nichts sichtbar.

Auch ich habe ein Problem beim Abruf der Mails über IMAP per SSL.

In Thunderbird funktioniert das Abrufen über den mxf-Server, Port 993 und mit den Einstellungen SSL/TLS und "Verschlüsseltes Passwort" einwandfrei.

Die Windows 8 Mail-App jedoch kann mit dem gleichen Server auf dem gleichen Port mit dem gesetzten Haken bei SSL keine Verbindung herstellen.

Mit beiden Programmen ist der Versand über Port 587 und SSL-verschlüsselt problemlos möglich.

Mit meinem bestehenden Business-Paket funktioniert das Abrufen über die Windows 8 Mail-App ohne Probleme über Port 993.

Vielleicht liegt es an einer strikteren Konfiguration an einer bestimmten Stelle?
Eine Lösung dafür wäre auf jeden Fall toll!