Beiträge von kk

Was steht denn in /var/log/liveconfig/liveconfig.log (dort nach "ACME" suchen)?

Zitat von Nosxxx

wenn ich auf Fehlerprotokoll zeigen klicke kommt leider nur ein weises Popup ohne Inhalt:

Wir können das bislang nicht reproduzieren, daher habe ich noch einige Fragen:
- tritt das nur in manchen Browsern auf? (war mir anhand der Beiträge hier nicht ganz klar)
- Single- oder Multi-Server-Setup?
- gibt es Meldungen in /var/log/liveconfig/liveconfig.log, wenn das Popup "leer" erscheint?

Zitat von MK70

Wie lange dauert es, bis eine Ausführung, die einen Fehler hervorruft, im Log erscheint?

Normalerweise ca. eine Sekunde (natürlich nur wenn das Error-Log aktiviert ist). Die "Geschwindkeit" kann man ja über's access-Log testen.

Die Proxy-Unterstützung ist ab sofort in der Preview verfügbar: https://www.liveconfig.com/de/…-LiveConfig-2-1-1?p=12156

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht eine aktualisierte Preview für LiveConfig 2.1.1 (r4121) bereit.
Neben einigen kleineren Verbesserungen und Fehlerbehebungen unterstützt diese Version nun auch HTTP-Proxies für eingehende und ausgehende Verbindungen.

Zur Aktivierung von Lizenzen, Repository-Updates etc. (also ausgehend) kann mit der neuen Option "proxy_http" ein HTTP-Proxy angegeben werden (muss CONNECT unterstützen, Proxy-Authentifizierung wird derzeit noch nicht unterstützt - bei Bedarf bitte kurz an uns wenden).

Zudem kann LiveConfig hinter einem Reverse-Proxy betrieben werden; hierzu kann der Proxy z.B. via "X-Real-IP"-Header die "echte" IP des Clients an LiveConfig durchreichen. LC nutzt diese dann für alle Logs etc..

Die neuen Anweisungen sind in den man-Pages (liveconfig.conf(5)) jeweils dokumentiert, das Handbuch wird mit dem Stable-Release entsprechend aktualisiert.

Viele Grüße

-Klaus Keppler

Das wird doch gemacht...? Wenn die Session abläuft, wird der Hintergrund "ausgegraut" und ein Popup informiert über den Timeout. Eine Umleitung auf eine neutrale oder Anmeldeseite findet absichtlich nicht statt, damit man sehen kann auf welcher Seite man sich zuletzt befunden hatte (komplexere Strukturen mit Popups, eingegebenen Daten usw. lassen sich nicht einfach wiederherstellen).

Zitat von Blizzn

Wenn ich das Template aber via Datenbank aktiviere wird der Inhalt nicht richtig zur Verfügung gestellt, weshalb alle .css und .js Dateien einen 404-Fehler zurückgeben und dementsprechend auch das Design nicht mehr richtig angezeigt wird.

Wie lautet denn die URL, welche einen 404-Fehler zurückgibt?
Hat Ihre Template-Datei die selben Berechtigungen & Besitzer wie die "default.tmpl"?

Ich habe eben testweise die "default.tmpl" in "test.tmpl" umbenannt (und analog den LCDEFAULTS-Eintrag geändert) und kann keine Probleme feststellen.

Um das abzukürzen: es gibt keinen Workaround, da LiveConfig in diesem Fall nur die IP des Proxies sieht. Mit dem nächsten Update kommen aber zwei neue Konfigurationsparameter (http_proxy_ip_header und http_proxy_ip_from) über die man LiveConfig explizit anweisen kann, die IP aus einem bestimmten Header-Feld (z.B. "X-Forward-IP" o.ä.) zu übernehmen.

Viele Grüße

-Klaus Keppler

Nein, es gibt keine einzelnen Dateien (CSS, JPG usw.) die man hier direkt bearbeiten könnte.

Wie man ein eigenes Template erstellen kann steht hier: https://github.com/LiveConfig/templates

Ist aber nichts für Einsteiger.

Ja, mit LiveConfig (oder Änderungen daran) hat das nichts zu tun. Seit jeder führt Apache lediglich ein "Reload" aus (wenn an irgendeinem vHost was geändert wurde). Genau das scheint der Analyse bei StackOverflow nach aber die Ursache für das volle Scoreboard zu sein (also dass die Reloads zu lange brauchen bzw. alte Childs nicht flott genug beendet werden).

In diesem Fall müssen also die Server-Parameter (MaxRequestWorkers, MaxConnectionsPerChild etc.) getuned werden. Ich vermute mal, dass Sie die Prefork-MPM nutzen?

Seitens LiveConfig könnte man höchstens das minimale Warteintervall zwischen zwei Reload-Befehlen hochsetzen (Standard: mind. 60 Sekunden). Dadurch braucht es aber dann etwas länger bis Änderungen aktiv werden.

Viele Grüße

-Klaus Keppler

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)