Richten Sie für irgendeine (Sub)domain einen Wildcard-A-Record ein, der auf den Webserver zeigt.
Wenn Ihr Webserver etwa die IP 1.2.3.4 hat, dann richten Sie im DNS einen Wildcard-Eintrag ein:
*.example.org. IN A 1.2.3.4
Im LiveConfig fügen Sie beim gewünschten Vertrag dann eine entsprechende Domain hinzu, z.B. "web1.example.org".
Viele Grüße
-Klaus Keppler
Hallo,
das geht bereits, ist aber - zugegebenermaßen - recht versteckt. Klicken Sie beim jeweiligen Kontakt auf "ändern": es öffnet sich das Popup-Fenster mit der Liste aller Kontakte. Dort suchen Sie den gewünschten Kontakt, klicken diesen an - es werden die Kontaktdetails angezeigt, darunter ein Button "bearbeiten...".
Der Workflow soll aber überarbeitet werden, so dass beim Klick auf "ändern" gleich der jeweils aktuelle Kontakt in der Detailansicht gezeigt wird (und somit direkter ein Ändern möglich ist).
Viele Grüße
-Klaus Keppler
Wird umgehend geklärt (Issue #112), ist also auch zum kommenden Update erledigt.
- Passworterzeugung für Mailpostfächer kommt ins nächste Update mit hinein.
- definierbare Passwort-Komplexität wird als Feature-Request mit aufgenommen
Zitatauch die Standard-Passwörter sind ziemlich kurz, wir drücken aktuell immer 3* auf "Zufall" und hängen das aneinander...
Die Passworterzeugung findet übrigens nach dem FIPS-181-Standard statt. Die Passwörter wirken "vertraut", werden aber aus künstlich erzeugten Silben zusammengesetzt - da kommt man mit Wortbuch-Attacken auch nicht weiter. Die Idee hinter FIPS-181 ist, dass sich die User das Passwort noch tatsächlich merken können.
Ein unglaublich langes und somit unmerkbares Passwort muss letztendlich immer irgendwo abgespeichert werden - und da ist dann die Frage, ob die User das tatsächlich mit so etwas wie "pwsafe" machen, oder ob die das Passwort nicht am Ende doch einfach nur in irgendeiner Textdatei speichern oder gar bei erster Gelegenheit auf ein viel zu einfaches Passwort ändern. :-/
Ja, nur wird diese dann bei der nächstbesten vHost-Konfiguration wieder überschrieben.
Eine "eigene" ~/.php5/php.ini wird von LiveConfig nicht überschrieben.
Das ist völlig normal und beabsichtigt, dass ein Kunde seine php.ini nicht direkt bearbeiten kann.
(sonst könnte er sich ja beliebig hohe Limits für Arbeitsspeicher, Ausführungsdauer usw. setzen)
Ab der nächsten Version (v1.7.0) können Sie direkt im LiveConfig php.ini-Einstellungen pro Vertrag ändern.
Ansonsten legen Sie ggf. eine Datei namens ~/.php5/php.ini (also /var/www/webXY/.php5/php.ini) an (als Vorlage können Sie ja die Datei ~/conf/php5/php.ini nehmen), passen diese wie gewünscht an, und lassen anschließend im LiveConfig die vHost-Konfiguration des Kunden neu erstellen (z.B. durch erneutes Speichern irgendeiner Domaineinstellung).
Hallo Herr Walter,
die o.g. offenen Punkte verwalten wir im Issue-Tracker unter https://www.liveconfig.com/dev/
Da es häufiger Nachfragen gibt, ob dieser oder jener Punkt schon in Arbeit ist etc. erfassen wir seit einigen Tagen alle Aktivitäten im Issue Tracker - somit spiegelt etwa die Aktivitätsliste den aktuellen Entwicklungsfortschritt besser wider.
Den aktuellen Stand für v1.7.0 finden Sie hier. Die größten Punkte (Backup und DNS-Management) befinden sich in der Zielphase, die erste Preview wird also in Kürze erscheinen.
Viele Grüße
-Klaus Keppler
Hallo,
das sind nur Warnungen - der Apache funktioniert trotzdem "ganz normal".
Mit dem kommenden Update kann ja nun aber auch SSL wieder in der Oberfläche deaktiviert werden (siehe #97), damit hat sich das dann auch erledigt.
Viele Grüße
-Klaus Keppler
In der Datei /etc/dovecot/passwd finden Sie den Speicherort für jedes Postfach. Schauen Sie einfach in diesen Ordner, ob dort tatsächlich Mails liegen. Die von LiveConfig gemeldeten Mails wurden durch Dovecot gezählt; häufig sind das z.B. Mails die in den Ordnern "Gelöscht", "Entwürfe", "Gesendete Nachrichten" etc. liegen.
Wenn eine Mail (angeblich) nicht ankommt, ist die einzige und gleichzeitig zuverlässigste Quelle für Informationen die Logdatei /var/log/mail.log - suchen Sie dort nach der Absenderadresse der "vermissten" Mail.
Viele Grüße
-Klaus Keppler
Diese Einträge sind soweit alle in Ordnung und sollten auch keine Probleme verursachen. Welche Fehlermeldung genau erhalten Sie von Apache, wenn Sie diese Einträge aktiviert lassen?
(siehe /var/log/apache2/error.log)
Hallo,
ich habe versucht, dieses Verhalten zu rekonstruieren - aber leider erfolglos.
Hierzu habe ich einen LiveConfig-Server sowie einen zusätzlichen LiveConfig-Client quasi identisch konfiguriert, einem Kunden zwei Verträge zugewiesen (web1 und web2 -> jeweils auf einem der beiden Server). In jedem Vertrag habe ich dann jeweils eine Anwendung installiert (in meinem Fall "Gallery" - jeweils mit dem Namen "gallery"). In der App-Übersicht (Hosting -> Anwendungen) werden beide installierte Anwendungen angezeigt.
Haben Sie irgend etwas anders gemacht?
Viele Grüße
-Klaus Keppler
Anmerkung: Die Inhalte habe ich entfernt.
Äh - das hilft leider nicht weiter. Genau das wäre interessant - welche Befehle genau Sie auskommentiert haben...
ich habe hier wie oben beschrieben das gleiche Problem nach einem Restart des Apachen. Ich nutze Debian Squeeze.
Bekomme den Fehler nur beseitigt wenn ich in der default die Zeilen auskommentiere. (Das kann doch nicht die Endlösung sein!)
Besteht der BUG immer noch?
Könnten Sie "das gleiche Problem" etwas genauer beschreiben? Welche Zeilen genau müssen Sie auskommentieren?
Absolut normal. Irgendein Bot wird da irgendwas im Internet suchen.
Apache schreibt eben 404er auch ins error_log - entweder den LogLevel erhöhen oder einfach ignorieren.
Danke für den Hinweis, der Fehler wurde eben beseitigt (#107). Der zuständige SQL-Befehl enthielt einen Fehler, wodurch der Wert quasi mit der Anzahl der Domains multipliziert wurde.
Viele Grüße
-Klaus Keppler
Danke für den Hinweis, Fehler ist gefunden und wurde eben beseitigt (#106). Beim Löschen von MySQL-Zugangsdaten fehlte die Sonderbehandlung von Underscore-Zeichen im Datenbanknamen (beim Anlegen einer Datenbank muss das mit einem Backslash escaped werden, da der Underscore sonst als Wildcard-Zeichen interpretiert wird und ein Benutzer dann nicht nur eine, sondern über 40 Datenbanken anlegen und nutzen kann).
Wir werden das voraussichtlich auch noch in die aktuelle 1.6.4-Version "backporten" und kurzfristig ein Update bereitstellen.
Viele Grüße
-Klaus Keppler
Ok, könnten Sie dann bitte mal auf der Konsole "liveconfig --diag" ausführen und den Abschnitt über den erkannten MySQL-Server hier posten?
Gibt es ansonsten noch irgendwelche Meldungen in /var/log/liveconfig/liveconfig.log?
Enthielt der Benutzernamen irgendwelche Sonderzeichen? (im Sinne von "alles außer Buchstaben und Zahlen")
Ich habe das eben mal getestet und kann das nicht bestätigen - die MySQL-Benutzer sind erfolgreich gelöscht.
Stehen die Benutzer bei Ihnen noch in der Tabelle "mysql.user" drin? Falls nicht - führen Sie bitte mal in MySQL den Befehl "flush Privileges" durch, und versuchen danach noch mal eine Anmeldung.
