Beiträge von r00xster

Das ist die Datei coming-soon.html aus /usr/share/liveconfig/html

Wenn die IP im Betriebssystem konfiguriert ist muss liveconfig oder lcclient (bei Multiserver-Setup) neugestartet werden, damit er diese erkennt. Anschließend kann man im Webfrontend unter "Serververwaltung" -> "Web" die neue IP-Adresse per Checkbox dem Webserver zuordnen und danach mittels IP-Gruppe (gleiche Seite) einem Vertrag exklusiv zuordnen.

Hierzu muss im Kundenzugang bei der entsprechenden Domain in den Einstellungen ganz unten das Häkchen bei "Aktiviere E-Mail mit dieser Subdomain" entfernt werden. Danach sollte der Mailserver sich nicht mehr für diese Domain verantwortlich fühlen.

Wir verwenden Roundcube zusammen mit LiveConfig. Das funktioniert auch vollkommen problemlos.

zu 1.) Das ist falsch. Nutzer können sich direkt anmelden, sobald der IMAP-Account auf dem Server aktiv ist. In der Roundcube-Konfiguration kann man festlegen, welche Ordner direkt angezeigt werden sollen und welche Ordner für Spam, Postausgang etc. sind. Dinge wie Signatur etc. kann der Nutzer dann direkt in Roundcube einstellen.

zu 3.) Roundcube benötigt eine eigene Datenbank. Hier werden alle Einstellungen des Nutzer zwischengespeichert. Die Zuordnung erfolgt über die E-Mail-Adresse.

Zitat von kk

Hmm, interessant...
Seit r2311 versucht LiveConfig die aktuelle PHP-Version automatisch zu erkennen, um diese bei der Erzeugung der php.ini-Dateien zu berücksichtigen.
Könnten Sie bitte mal die Ausgabe von folgendem Befehl posten?

Code

dpkg -l | grep php

ii  libapache2-mod-php5              5.4.4-14                   amd64        server-side, HTML-embedded scripting language (Apache 2 module)
ii  php-pear                         5.4.4-14                   all          PEAR - PHP Extension and Application Repository
ii  php5                             5.4.4-14                   all          server-side, HTML-embedded scripting language (metapackage)
ii  php5-cli                         5.4.4-14                   amd64        command-line interpreter for the php5 scripting language
ii  php5-common                      5.4.4-14                   amd64        Common files for packages built from the php5 source
ii  php5-curl                        5.4.4-14                   amd64        CURL module for php5
ii  php5-gd                          5.4.4-14                   amd64        GD module for php5
ii  php5-mcrypt                      5.4.4-14                   amd64        MCrypt module for php5
ii  php5-mysql                       5.4.4-14                   amd64        MySQL module for php5
ii  php5-tidy                        5.4.4-14                   amd64        tidy module for php5
ii  php5-xcache                      2.0.0-4                    amd64        Fast, stable PHP opcode cacher

Unter Debian wheezy wurden beim mir heute bei Build 2334 keine Änderungen an der Apache-Konfiguration gespeichert. Der Configtest des lcclient hat folgendes Meldung ausgegeben:

Zitat

sh: 1: /usr/bin/php-cgi: not found
Can't run /usr/lib/liveconfig/lua/liveconfig.lua: /usr/lib/liveconfig/lua/web.lua:140: attempt to concatenate local 'v_patch' (a nil value)

Ich kann in der Benutzerverwaltung bei keinem Benutzer die PHP.ini-Verwaltung aktivieren. Sie ist lediglich über den von LiveConfig bei der Installation erstellten admin-Nutzer einsehbar, wobei auch bei diesem Nutzer kein Häkchen in der Berechtigungsliste sichtbar ist.

System ist Debian wheezy mit der neusten LiveConfig-Build.

Wir setzen auch auf das MySQL-Backend und das ohne die genannten Probleme. Eingesetztes OS ist bei uns Debian.

Die ownCloud-Installation des Kunden ist der erste SSL-Vhost für diese IP, den der Webserver findet. Daher wird Sie auch auf der Server-Domain bzw. jeder anderen Domain, die auf diese IP verweist und per HTTPS aufgerufen wird, angezeigt.

Um das zu verhindern müsste ein Default-Vhost angelegt werden. Oftmals tritt dieses Szenario aber überhaupt nicht auf, da Kunden eine eigene IP für ihr SSL-Zertifikat bekommen, da die Unterstützung von mehreren verschiedenen Zertifikaten auf derselben IP (SNI) noch nicht von allen Browsern unterstützt wird.

Das Problem mit den Weiterleitungen ist bekannt. Hier im Forum stand, dass eine Lösung in Arbeit sei.

Wird sieve denn in der dovecot.conf als Modul eingebunden?

Bei mir sieht das so aus:

protocol lda {
mail_plugins = $mail_plugins sieve
}
protocol lmtp {
mail_plugins = $mail_plugins sieve
}

Das ist dovecot-sieve

Upps ... das habe ich doch glatt übersehen. Aber schön, dass es schon behoben wurde

Seit r2061 sind in der Domainliste beim Kunden bei den Subdomains vor dem Domainnamen 5 nbsp-Einträge zu sehen. Da wird der HTML-Code wohl nicht fehlerfrei geparsed.

Gerade bei Postfix wäre eine Auswahl der IPs ähnlich wie beim Webserver eine sinnvolle Sache, damit man auch die ausgehende IP festlegen kann. Ist keine IP ausgewählt nutzt Postfix normalerweise die erste IP des Interfaces. Dies muss ja aber nicht zwangsläufig der Mailserver sein und dann sind die Probleme mit dem nicht passenden Reverse-DNS-Eintrag vorprogrammiert.

Das ging ja fix mit der Fehlerfindung Eine Eingabeaufforderung ist auch definitiv nicht erschienen.

Am Mittwoch hatte ich einen Fehlerthread versehentlich im falschen Forum erstellt. Den hier beschriebenen Fehler konnte ich soeben beim Update auf r2002 erneut reproduzieren.

Mir ist sowohl heute morgen beim Update auf Release 1986 als auch gerade auf 1987 aufgefallen, dass beim Update die lcclient.conf fehlerhaft aktualisiert wird.

Unser LiveConfig-Hauptserver lauscht auf einem abweichenden Port, entsprechend hatte ich im Client die Variabe "server" auf dessen IP + Port eingestellt. Nach dem Update war die IP noch richtig eingestellt, der zugehörige Port inkl. ':' davor war aber in beiden Fällen aus der Konfigurationsdatei verschwunden. LiveConfig meldet dann natürlich, dass der Client nicht mehr verbunden ist. Nach manueller Anpassung war alles wieder ok.

Beide Systeme laufen unter Debian testing.

So schlimm ist das derzeit nicht da wir nginx nur außerhalb von Liveconfig verwenden.

Vielleicht sollte zumindest auf Debian/Ubuntu nach dem Paket nginx-common gesucht werden. Dies wird von allen nginx-Paketen als Abhängigkeit installiert. Es gibt ja auch noch weitere Versionen wie z.B. nginx-light.

Zitat von kk

Welches Debian-Paket genau haben Sie für den Webserver installiert? (apache2/nginx/...?)
In unserer Testumgebung wird NGINX problemlos unter Debian 7 erkannt.

nginx-full