SSL Zertifikat und Private Key scheinen nicht zusammenzugehören.

Nachdem ich das Zertifikat, den Private Key und das intermediate Zertifikat mehrfach überprüft hatte, hab ich das SSL Zertifikat aus unserem Onlinepanel mal reinkopiert (PEM-Format). Und siehe da, es klappt. Scheinbar ist das Zertifikat aus der eMail von AlphaSSL im anderen Format. Interessanterweise konnte ich es beim letzten mal bei unserem SSL Zertifikat für webmail.mchosting.eu aus der eMail verwenden. Nun musste ich die Kopie aus dem GlobalSign Webinterface nutzen.

Aber naja, hauptsache es geht nun und ich weiss beim nächsten mal bescheid. nur doof, dass ich jetzt für das Einspielen eines SSL Zerfikates in Confixx über eine Stunde gebraucht habe… Aber gut, man lernt halt nicht aus.

Natürlich muss dieses auch in Confixx eingebunden werden. Da ich davon ausgehe, dass der geneigte Leser weiss wie er ein SSL Zertifikat erstellt gehe ich hier nur auf die Eingabe der Felder innerhalb von Confixx ein:

Sie haben von Thawte per eMail Ihre Zertifikat erhalten. Loggen Sie sich nun in Ihrem Confixx Reseller-Account ein und gehen im Menü auf Kunden -> SSL. Wählen Sie dort den entsprechenden Kunden aus und wählen auf den folgenden Seite

Was ist vorhanden? “Private-Key und Zertifikat (CRT)”

aus.

Sie gelangen zur Eingabemaske mit drei Feldern:

Private-Key
Zertifikat (CRT)
CA Zertifikat (optional)

Tragen Sie hier Ihre daten ein. Den Private-Key haben Sie beim CSR erstellen erhalten. Das Zertifikat haben Sie von Thqwte erhalten und das CA-Zertifikat ist das oben erwähnte Intermediate Zertifikat. Dieses finden Sie auf den Thawte Webseiten unter

https://search.thawte.com/support/

Informationen zum Thema SSL, SSL in Confixx und CSR erstellen ist auch in der Hosting-Hilfe von Methfessel Computers zu finden: http://www.hosting-hilfe.eu

Anregungen gerne hier im Beitrag als Kommentar.

und hier der Link zum Howto:

http://www.hosting-hilfe.eu/index.php?title=Permalinks_im_Wordpress

Aber dank Adit Systems musste ich nicht lange nach einer Lösung suchen:

Wir bearbeiten einfach die idn_functions.php

vi /var/www/confixx/html/include/idn_functions.php

Dort fügen wir ganz oben unter den Kommentaren eine Zeile ein:

setlocale(LC_ALL, “de_DE.UTF-8″);

Und schon klappt es wieder mit den Umlautdomains in Confixx.  Aber Achtung: nach dem nächsten Update von Confixx prüfen, ob die Zeile wieder eingefügt werden muss. Die Datei wird im Rahmen des Updates komplett neu geschrieben.

Nach etwas Tante Google befragen kam ich dann auf folgende Einstellung:

In der Datei

/var/www/confixx/html/ftplogin/ftp_config.php

Gibt es verschiedene Konfigurationsparameter:

/* FTP-Data: */
$ftp_host = “127.0.0.1″;
$ftp_user = $PHP_AUTH_USER;
$ftp_pass = $PHP_AUTH_PW;

$maxEditSize = 200000;
$maxDownloadSize = 200000;
$docRootPath = “/html/”;
$mimeTextTypes  =  “css html htm shtml txt phtml pht php php3 js pl pm cgi inc phtml tex”;

$ftp_host, $ftp_user, $ftp_pass ist ja klar.

$maxEditSize gibt dann an, wie groß eine Datei maximal sein darf, dass man die Datei über das webFTP anpassen kann,
$maxDownloadSize die maximal zulässige Grße für’s Downloaden über webFTP.
$docRootPath wie der Name schon sagt, in welchen Ordner der Client sofort wechselt und $mimeTextTypes welche Dateitypen im webFTP editiert werden können.

Die Größeangaben sind übrigens in Byte. Die Zahl 200000 steht also für 200kb. Sinnvoll halte ich den Wert (200000=8MB).

Dank an die Quelle

Nachdem das alte System auf SuSe 9.3 mit Plesk 8 etwas in die Tage gekommen war und ein paar Gäste hatte, erhielt ich den Auftrag das System auf Debian 4 mit Confixx zu updaten.

Da der Server bei 3+3 steht ist man also an die dortigen Begebenheiten gebunden. Confixx wird von 3+3 gar nicht mehr geliefert, da es laut Aussage des dortigen Supports “bereits seit Jahren nicht mehr existiert und man keine Lizenzkeys mehr bekäme…”. Dass ich selber aktiv und vielfach Confixx Lizenzen verkaufen habe ich dem Supporter jetzt mal nicht mitgeteilt

Der Kunde will aber auch keine Extrakosten haben. Verständlich, wenn er knapp über 100,- EUR für einen Root-Server zahlt und dort ein Adminpanel wie Plesk mit 100 Domains inklusive hat. Einen Rabatt gibt es bei Nichtnutzung ja nicht.

Aber Debian wollte er haben. Das ist doch schonmal eine gute sache.

Leider bietet 3+3 kein Debian Image mit Plesk an, sondern nur

• OpenSuSe 11 mit Plesk 9
• OpenSuse 10 mit Plesk 8
• CentOS 5 mit Plesk
• CentOS minimal
• OpenSuSe 10 minimal
• OpenSuSe 11 minimal
• Debian 4 minimal
• Ubuntu LTS minimal
• Ubunto minimal

Ein erneuter Anruf bei der Hotline ergab auch wieder nur die Info, dass man nur die fertigen Images nehmen müsste. Wenn man Debian mit Plesk haben möchte, so wäre dies gar nicht möglich.
Ich klärte ihn also auf, dass ich Plesk wohl dann einfach geschwind selber installiere. Da klang er recht erstaunt konnte mir aber auch nicht mitteilen, wo ich im Kundeninterface den Plesk key bekäme. Es gäbe diesen nur bereits eingespielt mit den fertigen Images.

Ich könne aber dort den Key exportieren. Um den Plesk 9 Key zu bekommen, müsse ich jedoch erst den alten Server von Plesk 8 auf Plesk 9 updaten und dann den Key exportieren…

Gesagt getan, nach einem Upgrade auf Plesk 9 exportierte ich denn den Key und startet die Installation.

Die Zeit während der Systeminstallation nutzte ich dann für ein wenig lesen in den Plesk Releasenotes und entdeckte dort folgende System Requirements:

• Debian 3.1
• Debian 4.0
• Ubuntu 6.06
• Ubuntu 7.10
• Ubuntu 8.04

Nett, dass die einzigen von 3+3 mit Plesk angebotenen Distributionen gar net offiziell von Parallels supportet werden.

Mal wieder eine nette Erfahrung

Das alte System war zwar in den Jahren des Betriebs auch etwas durcheinander geraten, aber der Umzug selber lief recht problemfrei, so dass ich ihn als optimal bezeichnen würde.

Trotz ca. 75 GB Daten habe ich lediglich 5 Stunden benötigt. Das ist neuer persönlicher Rekord auf einem Fremdsystem.

Also hab ich vor einigen Tagen eine entsprechende Gruppe beantragt und gestern bewilligt bekommen.

Ich lade alle Interessierten Herzlich ein sich an der Gruppe zu beteiligen:

http://www.xing.com/group-32271.261995

Directory /var/www is not owned by ...

Um dies zu beheben muss einfach das Verzeichnis /var/www root geschenkt werden. Also www-data wegnehmen und root beschenken.

Und das ganze gibt’s dann auch gleich als Wiki-Eintrag zum erweitern:

http://wiki.dippelschisser.de/index.php/SuPHP_Directory_is_not_owned_by