Beiträge von kk

Aaaalso... noch mal ganz langsam:
bei HTTPS (SSL) baut der Browser eine TCP-Verbindung zum Server auf. Noch bevor der Browser dem Server sagen kann, welche Domain (zB. "www.kunde1.de") abgerufen werden soll, wird die Verschlüsselung aktiviert - der sogenannte "SSL Handshake" findet statt. Dabei übermittelt der Server dem Browser sein SSL-Zertifikat, damit der Browser das prüfen kann. Nun steht in dem Zertifikat naturgemäß ein Domainname (für den das Zertifikat ausgestellt wurde). Falls das nicht mit dem Domainnamen übereinstimmt, den der Benutzer in den Browser eingegeben hat, kommt eine hübsche Warnmeldung im Browser. Das ist völlig normal und absolut beabsichtigt, da der Server ja noch nicht wissen kann, welche Domain der Besucher überhaupt abrufen will.

Abhilfe soll da nun das SNI-Verfahren schaffen (Server Name Indication). Dabei überträgt der Browser während des SSL-Handshakes vorab die Info, welche Domain nun abgerufen werden soll. Falls der Server für die gewünschte Domain zufällig ein passendes SSL-Zertifikat konfiguriert hat, dann sendet er dieses zurück - im Browser erscheint keine Fehlermeldung. Alles prima.
Hauptproblem: dieses Verfahren funktioniert nicht unter Windows XP mit dem Internet Explorer. Da noch in vielen Firmennetzen WinXP mit IE8 (*grusel*) zum Einsatz kommt, muss jeder selbst entscheiden, ob er es sich erlauben kann/will, diese Benutzergruppe quasi auszusperren.

Eine weitere Alternative ist ein Multi-Domain-Zertifikat. Dabei werden einfach alle Domainnamen, die auf der selben IP laufen und bei denen SSL aktiviert sein soll, zusammen in ein Zertifikat gepackt. Das funktioniert dann auch mit IE unter XP. Nachteil hier: jeder Besucher, der einen Blick in das übermittelte SSL-Zertifikat wirft, sieht zwangsweise auch alle anderen Domainnamen, die hier mit SSL laufen (Information Leakage!).

Nun zurück zum Thema: wenn der Browser eine SSL-Verbindung aufbaut, weiß der Server nur im Falle von SNI, auf welche Domain zugegriffen werden soll und ob es dafür ggf. ein Zertifikat gibt. Bei wem Apache also noch kein SNI beherrscht, der kann das o.g. Verhalten definitiv nicht "abschalten". Man könnte theoretisch eine Default-SSL-Site konfigurieren, die dann irgendwohin umleitet oder eine Fehlermeldung wirft - das ist aber ohnehin erst mal mit einer Browser-Fehlermeldung usw. verbunden.
Wenn SNI unterstützt wird, kann man mit der Apache-Option SSLStrictSNIVHostCheck regeln, was bei "unbekannten" Zugriffen passieren soll. Da einzurichten ist ziemlich einfach - hier ein Beispiel für Debian:
- Datei /etc/apache2/conf.d/sni.conf anlegen, und dort "SSLStrictSNIVHostCheck on" eintragen
- Apache neu starten

Im professionellen Shared Hosting kommt nach wie vor kein SNI zum Einsatz, da es eben noch zu viele "legitime" Besucher gibt, die man damit ausschließen würde. Die sauberste Lösung für Kunden ohne SSL ist es tatsächlich, diese auf eine eigene IP-Gruppe zu legen, bei der kein SSL aktiviert ist (dann ist ein HTTPS-Zugriff schlichtweg nicht möglich).

So - ich hoffe, damit alle Fragen geklärt zu haben.

Viele Grüße

-Klaus Keppler

LiveConfig erstellt gar keine .htaccess-Datei, sondern schreibt die entsprechenden Anweisungen in die vHost-Konfiguration. Somit funktioniert das Ganze auch mit NGINX (der ja so was die .htaccess nicht kennt), und man braucht keine Angst haben, dass irgendwelche .htaccess-Dateien überschrieben würden.

LiveConfig unterstützt derzeit mod_fcgid, nicht mod_fastcgi. Beide machen zwar im Grunde das selbe (FastCGI-Protokoll zur Kommunikation mit dauerhaften PHP-Prozessen); wie diese das technisch machen ist aber völlig unterschiedlich. So kümmert sich beispielsweise mod_fcgid selbständig um's Starten und Stoppen von PHP-Prozessen, gleichzeitig können diese aber beispielweise keinen gemeinsamen Opcode-Cache (zB. APC) teilen - jeder Prozess hat seinen eigenen Cache.

Alle Varianten haben ihre Vor- und Nachteile, alle haben ihre Daseinsberechtigung - mit Google lassen sich tausende Diskussionen darüber finden, also können wir uns das an dieser Stelle sparen.

Inzwischen liest LiveConfig ja bereits die vorhandenen Apache-Module aus und zeigt diese an. Wir möchten diesen Bereich demnächst ausbauen, so dass LiveConfig die Auswahl der PHP-Methoden automatisch entsprechend einschränkt (wenn z.B. kein mod_php vorhanden ist, dann soll das auch gar nicht erst in der Dropdown-Box auftauchen). In diesem Schritt wäre es dann nur eine Kleinigkeit, auch die entsprechenden Konfigurationsanweisungen für mod_fastcgi oder meinetwegen auch mpm_itk in's "apache.lua"-Script aufzunehmen. Ganz unverbindlich plane ich das mal für v1.7.1 ein (v1.7.0 soll neben DNS-Verwaltung auch die Auswahl der PHP-Version über die GUI mitbringen).

Viele Grüße

-Klaus Keppler

Geplant ist, Ende nächster Woche (voraussichtlich Donnerstag, 25.04.) die Preview letztmalig vor der offiziellen Release zu aktualisieren. Dort sind dann alle angekündigten Features (Mail-Login, Passwortschutz, php.ini-Verwaltung u.v.m.) voll funktionsfähig enthalten, wir brauchen dann nur noch ein paar Tage um unsere Tests entsprechend zu erweitern.

Sehr geehrter bfal,

wir werden uns etwas einfallen lassen, wie wir den Entwicklungsprozess eventuell noch etwas transparenter gestalten können. Bei diesen relativ kurzen Release-Zyklen von 4-8 Wochen werden wir aber weiterhin keine Termine nennen können - das könnte man nur dann machen, wenn man z.B. nur ein oder zwei mal im Jahr eine neue Version herausbringen würden.

Zur Information: ".htaccess-Verwaltung" (bzw. um genau zu sein: Passwort-Verzeichnisschutz - hat letztendlich mit .htaccess nichts zu tun) ist ebenfalls bereits fertig und im nächsten Update enthalten.

-Klaus Keppler

Ja, genau so ist das auch implementiert (war wohl etwas zu knapp formuliert). Ab r2265 kann pro Server, Angebot und Vertrag eingestellt werden, ob externer MySQL-Zugriff konfiguriert werden kann/darf.

php.ini-Verwaltung: ist in Arbeit (wie allgemein bekannt) und der letzte "Showstopper" für die kommende Version 1.6.2
Ext. MySQL-Zugriff: ist seit r2265 erledigt und somit auch im nächsten Update enthalten.

Fragen á la "wie lange dauert es bis..." lassen sich nunmal nicht exakt beantworten. Und wie "langsam" die Entwicklung ist, liegt immer im Auge des Betrachters.

Ja, das htdocs-Verzeichniss muss der Gruppe www-data gehören und Mode 750 haben.
Das php-fcgi-starter.sh muss dafür web1:web1 gehören.

Prüfen Sie bitte, ob suexec installier & aktiviert ist, und evtl eine Fehlermeldung in /var/log/apache2/suexec.log auftaucht.
Die Fehlermeldung deutet darauf hin, dass gar keine FastCGI-Prozesse gestartet werden können.

In Ihrem Webspace-Verzeichnis existiert aber schon das Verzeichnis ~/conf/ mitsamt ~/conf/php5/php-fcgi-starter ?

So wie es aussieht haben Sie die /etc/passwd, /etc/group etc. nicht mit gesichert?
In diesem Fall müssten Sie die Benutzer "von Hand" erneut anlegen.

Für den Benutzer "web1" sollte es mit etwa folgendem Befehl klappen:

useradd -d /var/www/web1 -s /bin/false web1

Der Gruppenname ist immer identisch mit dem Benutzernamen.

Ich habe doch gefragt, welche Fehler auftauchen.
Sie werden vermutlich kaum jemanden finden, der nichts besseres zu tun hat als kostenlos fremde Server zu installieren... :confused:

Hmm, und was für Fehler?

Wenn Sie Unterstützung bei der Installation brauchen, werfen Sie am besten mal einen Blick auf unsere Partner-Seite (http://www.liveconfig.com/de/partner) - dort finden Sie mit Sicherheit einen Anbieter, bei dem Sie die Lizenz kaufen und einen Installationsservice buchen können. Darüber hinaus empfehle ich Ihnen, ggf. auch noch ein Server-Management mit zu buchen, da ein einmal installierter Server trotzdem regelmäßige Updates benötigt.

Wenn Sie eine App installieren, müssten zwei Dinge passieren:
- das Installationsscript wird von unserem Server (update.liveconfig.com) heruntergeladen und in /var/cache/liveconfig/installer gespeichert
- anschließend wird das eigentliche Installationspaket vom jeweiligen Server (z.B. SourceForge) heruntergeladen und in /var/cache/liveconfig/downloads/ gespeichert

Landen bei Ihnen während einer Installation in diesen Verzeichnissen irgendwelche Daten?
Oder haben Sie eventuell ausgehende Verbindungen von Ihrem Server per Firewall blockiert?

Viele Grüße

-Klaus Keppler

Danke für den Hinweis; zu Testzwecken wurde dort die Wartezeit verlängert - offenbar wurde die leider "vergessen".
Der Dereferer wurde nämlich kürzlich überarbeitet, um auch "#"-Angaben in URLs mit in die Weiterleitung zu übernehmen (damit z.B. bei einem Link auf's Handbuch gleich an die richtige Stelle gescrollt wird).

Ist beim nächsten Update der Lab-Version wieder behoben (ab r2160).

Viele Grüße

-Klaus Keppler

Die Preview wurde eben noch mal aktualisiert: Version 1.6.2-r2258.

Viele Grüße

-Klaus Keppler

Zitat von tyrann619

Jedoch klappt das senden nicht so richtig. Will ich eine Email von Outlook über mein Emailkonto senden, bekomme ich die Nachricht, dass die Nachricht Unzustellbar ist mit dem Fehler Relay access denied.

Bitte aktivieren Sie im Outlook noch die Option (sinngemäß) "Postausgangsserver erfordert Authentifizierung". Die Benutzerdaten (Login/Passwort) sind die selben wie für den Abruf der E-Mails. Bitte nicht die Option "Sicheres Passwort (SPA)" aktivieren.

Zitat

aber wieso versuchen Fremde auf den Mailserver zuzugreifen..und wie kann ich das unterbinden? Laut log kommen die zwar eh nicht herein aber das ganze verursacht doch trotzdem Rechenleistung und Traffic?!

Das ist leider absolut normal. Der Traffic dürfte sich in Grenzen halten, und die Rechenleistung dafür ist i.d.R. vernachlässigbar.
Rein zur Information: bei uns kommen auf eine erfolgreich zugestellte E-Mail weit über 100 abgewiesene Sendeversuche.

Zitat

Wieso scheitern manche an der authentication (ok sie haben die daten nicht) aber der Log hier drüber scheitert erst an "Relay access denied" wie ich.. heißt das das der die Daten hat? Password etc?

"Relay access denied" bedeutet, dass jemand über Ihren Mailserver ohne vorherige Anmeldung eine Mail an irgendeinen anderen (fremden) Mailserver senden wollte, was natürlich abgelehnt wurde. Ein Passwort ist hier nicht im Spiel.

Die "SASL LOGIN authentication failed"-Meldung zeigt wiederum, dass irgendjemand sich anmelden wollte, aber dabei gescheitert ist.

Wie gesagt - zwar lästig, aber leider völlig normal.

Viele Grüße

-Klaus Keppler

Öh - sorry, ich habe das nun noch ein zweites Mal durchgelesen.
Wenn in der vHost-Konfiguration schon gar keine SSL-Einstellungen auftauchen, dann stimmt irgendwas anderes nicht.

Zur Aktivierung von SSL mit LiveConfig sind i.d.R. folgende Schritte notwendig:
- unter Serververwaltung -> Web die entsprechende IP-Gruppe bearbeiten und damit SSL aktivieren
- unter Kunden -> (Kunde auswählen) -> Verträge den entsprechenden Vertrag öffnen und dort HTTPS (SSL) aktivieren. Verwaltung von SSL-Zertifikaten durch den Kunden ist hierzu *nicht* notwendig.
- unter "Hosting" -> "SSL-Zertifikate" ein Zertifikat anlegen/importieren und am Ende dem gewünschten Kunden zuweisen.
- der Kunde kann nun unter "Hosting" -> "Domains" eine seiner (Sub)Domains zum Bearbeiten öffnen, dort dann HTTPS (SSL) aktivieren und das gewünschte SSL-Zertifikat auswählen.

Viele Grüße

-Klaus Keppler

Ist mod_ssl eventuell nicht aktiviert? Bitte gehen Sie in LiveConfig auf "Serververwaltung" -> "Web" - dort wird eine Liste der aktiven Apache-Module angezeigt - das Modul "ssl" sollte auch mit einem grünen Haken versehen sein.

Falls das nicht der Fall ist: auf der Konsole "a2enmod ssl" ausführen, anschließend "/etc/init.d/apache2 restart".

Viele Grüße

-Klaus Keppler

Hallo,

die URL bleibt die selbe, nur sollte dann im Hintergrund eben AWStats die Statistiken erzeugen.
Bitte öffnen Sie die aktuelle Statistik und drücken dann im Browser mal die F5-Taste (oder <Strg>+<R>), um die Anzeige zu aktualisieren.
Werden die Werte von Webalizer derzeit noch aktualisiert (sprich: Sie haben vor zwei Tagen umgestellt - sind trotzdem noch die Zahlen von gestern im Webalizer zu sehen?) Falls nicht, dann ist eventuell "awstats" nicht auf dem Server installiert - bitte klären Sie das dann mit Ihrem Anbieter ab.

Viele Grüße

-Klaus Keppler

Zitat von Jim

Der Kunde hat nicht ein Passwort geändert sondern eine seiner Datenbanken gelöscht.
Da nach einem Import von Confixx ja alle Datenbanken den gleichen Datenbank-Benutzer haben ist dies ein Problem, da dem Anschein nach durch das Löschen einer Datenbank auch der Datenbank-Benutzer gelöscht wird obwohl dem Benutzer noch mehr Datenbanken gehören.

Das Problem wurde mit v1.6.2-r2236 beseitigt; LiveConfig prüft dabei noch mal unabhängig direkt in den MySQL-Benutzertabellen, ob einem Benutzer evtl. noch weitere Datenbanken gehören, und löscht diesen dann ggf. nicht.

Viele Grüße

-Klaus Keppler