Beiträge von kk

Zitat von loswebos.de

ich nutzte PHP 5.4 und die PHP.ini Verwaltung schreibt mir nun per Default magic_quotes_gpc und safe_mode in die php.ini des Accounts.

Das resultiert unter PHP 5.4 in einem StartUp Fehler, sodass die Anwendung nicht mehr läuft. (LiveConfig kennt ja die eingesetzte PHP Version nocht nicht?)

Hmm, ja, das ist ein Problem. Wir werden kurzfristig noch die Erkennung der PHP-Version mit hinzufügen (Wheezy bringt ja standardmäßig auch PHP 5.4 mit). Es gibt ja die Möglichkeit, die "gültige" PHP-Version bei .ini-Optionen mit anzugeben, nur wurden diese mangels Kenntniss der "aktiven" PHP-Version ignoriert.
Update müsste heute im Laufe des Abends fertig sein.

Zitat

Da der Löschen Button einer PHP Option nicht funktioniert, bleibt einem nur die PHP Option direkt aus der Liveconfig DB zu entfernen:

Wir haben das eben reproduzieren können: mit Firefox & IE klappt das, mit Opera nicht. Verwenden Sie auch Opera, oder einen ganz anderen Browser?
Bugfix ist bereits in Arbeit, ist auch im kommenden Update mit drin.

Viele Grüße

-Klaus Keppler

Zitat von bfal

1. Wo kann ich denn den Verzeichnis Passwort Schutz einrichten? Irgendwie finde ich nirgends eine Option dafür. Es ist auch keine Freigabe im Angebot soweit ich das sehen kann.

Das was ein Fehler im Build - die Passwort-Verwaltung war nur im Debug-Build verfügbar Wir aktualisieren die Preview in den nächsten Stunden noch mal, im Update ist das dann enthalten.

Zitat

2. Unter PHP.ini Einstellungen ist der Button für "Neue Vorlage" ausgegraut. Ich kann keine neue Anlegen.

Derzeit kann man noch keine weiteren Templates anlegen (kommt mit einem der nächsten Updates); bis dahin werden wir diesen Button wohl besser mal ganz entfernen, da das sonst zu sehr verwirrt.

Zitat

3. Müsste ich die PHP.ini Vorlage nicht auch irgendwo zuordnen können? Ich hätte jetzt gedacht im Angebot....aber da finde ich es nicht.

Ja, sobald es die Möglichkeit gibt mehrere Templates zu verwalten, sollen diese auch ausgewählt werden können. Bis dahin gilt für alle Webspaces das Standard-Template.

Viele Grüße

-Klaus Keppler

Ab sofort steht LiveConfig v1.6.2-r2302 (Release Candidate) als Preview bereit.

Die wichtigsten Änderungen sind - neben einigen Bugfixes und Detailverbesserungen:

• die lange erwartete php.ini-Verwaltung
• eine Zwei-Faktor-Authentifizierung (z.B. per Google Authenticator App)
• externer Zugriff auf MySQL-Datenbank kann pro Angebot und pro Vertrag eingeschränkt werden
• Verzeichnis-Passwortschutz (a.k.a. ".htaccess-Passwortschutz" - hat aber mit .htaccess nichts zu tun)

Einige kleinere Details fließen in den nächsten 2-3 Tagen noch mit ein (z.B. ausstehende Anpassungen für Gentoo sowie voraussichtlich noch die Bearbeitung der php.ini-Einstellungen durch Kunden). Ende kommender Woche soll dann die produktive Freigabe erfolgen.
Außerdem überarbeiten wir aktuell unseren Entwicklungs-Planung, um kürzere Zyklen und transparentere Terminplanungen zu ermöglichen. Details hierzu kommen ebenfalls nächste Woche (die Website erfährt da einige größere Aktualisierungen).

Viele Grüße & ein schönes Wochenende!

-Klaus Keppler

Moin,

ja, genau so ist das gedacht. Der AXFR kann neben IP-Adresse optional auch noch auf konfigurierbare TSIG-Schlüssel eingeschränkt werden. Außerdem wird es eine SOAP-API geben, mit der man sehr bequem und einfach die Liste aller Zonen für bestimmte sekundäre Nameserver abrufen kann.
So könnte man beispielsweise ein Script schreiben, welches neue Zonen auf einem nicht von LiveConfig verwalteten Secondary-DNS anlegt.

Details zur DNS-Verwaltung folgen nun in den nächsten 2-3 Wochen - nächste Woche wird noch v1.6.2 produktiv freigegeben, dann machen wir direkt mit DNS weiter.

Viele Grüße

-Klaus Keppler

Naja, so wie es aussieht steckt ein Leerzeichen in den Zieladressen ("steffi @blabla.de", "patrick @blabla.de"). Das ist also durchaus eine eher ungültige Weiterleitungsadresse.
Mag sein, dass Confixx das erlaubt hat - LiveConfig erlaubt es jedenfalls nicht.

Hmm, interessante Frage... die Funktion gibt es tatsächlich noch nicht, ich werde da gleich mal einen Feature Request aufmachen.

Hier ist der "saubere" Workaround: wenn tatsächlich keine Webspaces mehr mit NGINX konfiguriert sind, melden Sie sich an der LiveConfig-Datenbank an (je nachdem - per MySQL oder "sqlite3 /var/lib/liveconfig/liveconfig.db") und führen dann diesen SQL-Befehl aus:

UPDATE WEBSERVERS SET WS_MANAGED=0 WHERE WS_TYPE="nginx";

Damit wird das Management aller nginx-Webserver wieder deaktiviert (vorsicht also, falls Sie mehrere Server verwalten).

Viele Grüße

-Klaus Keppler

Für's Archiv: es handelte sich um einen Konfigurationsfehler in der "my.ini" - hatte also nichts mit LiveConfig zu tun.

Bei "liveconfig --diag" wurde der Fehler während der Paketerkennung mit ausgegeben und konnte sodann durch den Kunden beseitigt werden.

Senden Sie uns bitte mal die Ausgabe von "liveconfig --diag" (am besten an support@liveconfig.com)
Ohne die Info, welche Distribution Sie einsetzen, kann man nicht viel sagen...

Danke für den Hinweis - da hat Gentoo wohl eine sehr eigene Vorstellung vom "apache2ctl" (eigentlich ist das ein Tool, das vom Apache direkt mitgeliefert sein sollte).
Wurde jedenfalls mit v1.6.2-r2184 korrigiert - da ruft LiveConfig nun direkt "/usr/sbin/apache2 -M" auf.

Danke für den Hinweis - ist ab v1.6.2-r2283 korrigiert.

Viele Grüße

-Klaus Keppler

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.