Beiträge von kk

Eine bestehende LiveConfig-Installation kann nicht in ein Client-System "umgewandelt" werden.
Das hat mit der Datenhaltung zu tun: in einer Multiserver-Umgebung sind alle Daten zentral auf dem Business-Server gespeichert. Man müsste also erst die bestehenden Datenbanken vom künftigen Client in die Hauptdatenbank importieren - was eben (noch) nicht geht (-> wir planen dafür im Laufe des Jahres ein Tool zu entwickeln).

Wie viele Verträge/Webspaces/Postfächer sind denn auf dem zusätzlichen Server schon angelegt?
Im Grunde müssten Sie das Paket "liveconfig" dort entfernen, dann das Paket "lcclient" installieren (wie im Handbuch beschrieben). Anschließend das System dem Business-Server hinzufügen.

Viele Grüße

-Klaus Keppler

Aus aktuellem Anlass möchten wir auf eine aktuelle Sicherheitslücke in der "libc", der Standard-Bibliothek fast aller Linux-Systeme hinweisen:

http://www.heise.de/newsticker…rkfunktionen-3107621.html

Da sich der Fehler ausnutzen lässt indem man z.B. die DNS-Auflösung eines "eigenen" (manipulierten) Hostnamen auslöst, sollten alle betroffenen Server zeitnah aktualisiert und wahlweise alle Dienste oder ggf. der ganze Server rebootet werden.

Viele Grüße

-Klaus Keppler

Antwort per Ticket ging vorhin raus. Wir gehen der Sache auf die Spur...

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 5.5.32, 5.6.18 bzw. 7.0.3 aktualisiert.

Viele Grüße

-Klaus Keppler

Zugriffe: HTTP-Hits (also einzelne HTTP-Requests, egal ob Bild, Webseite, Fehlermeldung, ...)
Traffic: HTTP-Traffic
E-Mails: Summe der empfangenen und gesendeten E-Mails

Die Sortierung wird je nach Auswahl der Dropdown-Box gewählt (also Top10 HTTP-Hits, Top-10 nach HTTP-Traffic oder Top 10 nach E-Mails).

Viele Grüße

-Klaus Keppler

http://www.liveconfig.com/de/handbuch/server.database.xhtml

Welche Datenbank genutzt wird, ist in /etc/liveconfig/liveconfig.conf eingestellt. Die SQLite-Datenbank finden Sie unter /var/lib/liveconfig/liveconfig.db - mit dem Programm "sqlite3" kann man darauf zugreifen. Braucht man aber nicht.
(auf die Datenbank sollte bestenfalls gar nicht, und schlimmstenfalls nur lesend zugegriffen werden - unter KEINEN UMSTÄNDEN schreibend).

Zitat von WolfHenk

Code

[2016/02/10 19:27:47.343486] [794|794] LiveConfig 2.1.0-4085 starting...
[2016/02/10 19:27:47.371222] [794|794] Database driver loaded: SQLite (3.10.2)
[2016/02/10 19:27:47.753814] [794|794] License is valid.
[2016/02/10 19:27:49.189579] [1051|1051] [B][COLOR=#b22222]Database connection failed: unable to open database file[/COLOR][/B]

Da stimmt wohl was nicht. Prüfen Sie, ob /var/lib/liveconfig/liveconfig.db existiert, ob diese liveconfig:liveconfig gehört und mode=0600 hat.

Viele Grüße

-Klaus Keppler

Zitat von aziegler

seit wann gilt denn, dass die IP für autoconfig nicht für HTTPS-Webspace genutzt werden darf?

Das war schon immer so und liegt in der Natur von Autodiscover. Mag sein dass das mit AutoConfig (Thunderbird) geklappt hatte - unsere Anleitung berücksichtigt aber beide Systeme.
Outlook versucht zuerst eine HTTPS-Verbindung zur Autodiscover-Subdomain aufzubauen, und erwartet natürlich ein SSL-Zertifikat mit der Domain der E-Mail-Adresse. Wenn da ein Dienst mit einem anderen SSL-Zertifikat antwortet, gibt's 'ne Fehlermeldung und die Suche ist beendet. Daher darf dort nur HTTP gesprochen werden, und es muss eine 302-Weiterleitung auf irgendeine andere HTTPS-Adresse sein.

Zitat

Da wäre ein changelog und eine Migrationsanleitung für bestehende autoconfig-Setups schon angebracht...

Es gab absolut keine Änderung in dem Protokoll, wir haben lediglich die Beschreibung überarbeitet und an einigen Stellen klarer formuliert. Neu ist lediglich die Vereinfachung, falls LiveConfig direkt auf Port 443 erreichbar ist (dann kann man sich den Reverse-Proxy sparen). Wenn ein bestehendes Setup also funktioniert, muss daran auch nichts geändert werden.

Die "alte" Anleitung müsste in der DokuWiki-History noch zu finden sein (ungetestet).

Gibt es Meldungen in /var/log/liveconfig/liveconfig.log zu dem Zeitpunkt?
Lässt sich der Fehler auch von anderen Rechnern aus reproduzieren?

Wirklich das root-Passwort? Oder meinen Sie das Passwort vom "admin"-Account in LiveConfig?
Anzeigen lassen geht nicht - das wird als sicherer Hash gespeichert und kann daher nicht entschlüsselt werden. Sie können das Passwort aber zurücksetzen, wenn Sie sich als "root" per SSH anmelden:

LCINITPW="NeuesPassword" liveconfig --init

siehe Handbuch.

Viele Grüße

-Klaus Keppler

Zitat von Joeym

Sorry für den Doppelpsot aber wir möchten auch gerne weiter kommen. Liegt es eventuell dran, dass wir PHP Version 5.6 haben? Früher hatten wir 5.3..

Ja, das macht durchaus einen Unterschied... :p

Mit PHP 5.6 brauchen Sie einen ganzen Schwung weiterer Parameter zur Initialisierung Ihres SOAP-Clients, wenn Sie auf LiveConfig mit selbst-signiertem SSL-Zertifikat zugreifen möchten.
Beispiel:

$client = new SoapClient(
   $wsdl_url,
   array(
     'soap_version' => SOAP_1_2,
     'trace' => 1,
     'stream_context' => stream_context_create(
       array(
         ssl => array(
           'verify_peer' => false,
           'verify_peer_name' => false
         )
       )
     )
   )
 );

(in $wsdl_url gehört dann natürlich die URL zu Ihrem LiveConfig)

Zitat von bfal

Scheinbar wird der "Auto-Konfiguration" Eintrag aus der Serverkonfiguration nicht für die CNAME Einträge im DNS benutzt. Als Ziel für die Autodiscover Einträge steht der Mailservername und scheinbar nicht der Eintrag aus der "Auto-Konfiguration".

Waren bei der Domain schon vorher CNAME-Einträge für autoconfig/autodiscover angelegt? Oder wurde erst nach dem Update AutoConfig dafür aktiviert?
Wenn CNAME-Einträge angelegt werden sollte das in /var/log/liveconfig/liveconfig.log sowie (falls Fehler auftreten) auf dem Primary DNS in /var/log/messages protokolliert werden.
Ich habe das eben noch mal getestet - auf dem Testsystem hier wird korrekt der bei "Auto-Konfiguration" hinterlegte Name bei den CNAMEs eingetragen...

Danke - wurde eben mit r4085 korrigiert.

Danke für den Hinweis! Ist offenbar ein Tippfehler (Exex -> Exec). Welche Distribution nutzen Sie denn? Bislang ist das nämlich niemandem aufgefallen... :confused:

Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig 2.1.0 (r4084) bekanntgeben zu dürfen. Das Changelog ist recht umfangreich, die wichtigsten Punkte sind:

• AutoDiscover: die "autoconfig"- und "autodiscover"-Subdomains werden nun automatisch durch LiveConfig angelegt. Als CNAME wird dabei der Name eingetragen, den man unter Serververwaltung -> Mail für Autodiscover hinterlegt hat (zur Erinnerung: das muss ein Hostname sein, auf dessen IP nur ein Redirect stattfindet und auf der KEIN HTTPS (Port 443) erreichbar ist - die Doku hierzu wurde heute aktualisiert).
  Während des Upgrades auf LiveConfig 2.1.0 werden die beiden Subdomains automatisch für alle Domains angelegt, die von LiveConfig verwaltet werden, wenn Autodiscover aktiviert ist. AUSNAHME: wenn bereits autodiscover/autoconfig-Subdomains existieren, dann werden diese nicht geändert.
• die Hostnamen für SMTP und POP3/IMAP-Server (die dann u.a. auch vom Autodiscover-Service ausgegeben werden) waren bislang automatisch gleich dem Hostnamen. Ab sofort können diese frei geändert werden. Wenn man den SMTP-Hostnamen ändert, werden z.B. auch automatisch alle MX-Einträge entsprechend aktualisiert.
• Autodiscover kann nun pro Domain ein- und ausgeschaltet werden
• Autodiscover kann zudem pro Postfach konfiguriert werden (ob keine Konfiguration ausgegeben werden soll, oder ob POP3 oder IMAP priorisiert werden sollen)
• Let's Encrypt: auslaufende Zertifikate werden automatisch 30 Tage vor Ablauf verlängert und auf den Webservern ersetzt (für Mail/FTP wird das auch in Kürze automatisch erfolgen, ist aber noch in Arbeit).
• Zudem wurde die Behandlung von Fehlern oder unerwarteten Antworten vom Let's Encrypt-Service verbessert, Fehlermeldungen werden vollständig ins LiveConfig-Log geschrieben.
• Für alle Dienste stehen nun systemd-Unitfiles bereit.

Vielen Dank an dieser Stelle insbesondere auch an das Feedback der Preview-Versionen!

Die nächsten Features und Verbesserungen sind in Arbeit, voraussichtlich gibt's am Mittwoch schon die erste Preview auf die nächste Version.

Zitat von Joeym

failed to load external entity "URL" in /var/www/web1/htdocs/admin/index.php(72) : eval()'d code:78

Was steht denn in dieser Datei in Zeile 72?
Ohne den Code, der den Fehler auslöst, wird man nicht viel sagen können...
Wenn der Fehler schon beim Laden/Parsen vom WSDL auftritt prüfen Sie mal, ob vielleicht das SOAP-Passwort oder der admin-Benutzername geändert wurden.

Hallo,

heute Nachmittag wurde ein OpenSSL-Update bereitgestellt welches zwei Sicherheitslücken behebt, eine davon ist unter Umständen sicherheitskritisch.

LiveConfig ist (und war) von keinem dieser beiden Probleme betroffen - sowohl die Option SSL_OP_SINGLE_DH_USE als auch SSL_OP_NO_SSLv2 werden schon immer gesetzt.

Das kommende Update enthält trotzdem die aktualisierte OpenSSL-Version.

Viele Grüße

-Klaus Keppler

Danke für die Rückmeldung! Die Preview wurde eben auf r4082 aktualisiert. Dort prüft das Unit-File für lclogparse künftig ob die o.g. Datei existiert.

Kann es sein, dass die Datei /etc/liveconfig/lclogparse.conf auf dem betroffenen System nicht existiert? Dann haben wir den Fehler gefunden.
(es ist in Ordnung wenn die nicht existiert, in dem Fall soll lclogparse nämlich auch gar nicht laufen)

Zitat von RB-Media-Group

server: Job for lclogparse.service failed. See 'systemctl status lclogparse.service' and 'journalctl -xn' for details.
server: invoke-rc.d: initscript lclogparse, action "start" failed.
server: dpkg: Fehler beim Bearbeiten des Paketes lcclient (--configure):
server: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück

Was geben denn systemctl status lclogparse.service und journalctl -xn aus?