Beiträge von kk

Diese Log-Meldungen werden ausschließlich durch Apache selbst erzeugt, mit LiveConfig hat das rein gar nichts zu tun. Wer das genau nachlesen möchte: es ist alles ausführlich dokumentiert.

Zudem dürften diese Einträge ausschließlich in den zentralen Apache-Logs (/var/log/apache2/) auftauchen, und nicht in webspace-spezifischen Logdateien (/var/www/###/logs/).

Die Log-Konfiguration wird durch LiveConfig in die Datei /etc/apache2/conf.d/liveconfig geschrieben. Wenn Sie diese Einstellung "überschreiben" möchten, legen Sie eine Datei an die (alphabetisch) zum Schluß geladen wird - also z.B. /etc/apache2/conf.d/ZZZ-log
In die schreiben Sie dann die CustomLog-Anweisung wie sie in der "liveconfig"-Datei steht und erweitern diese entsprechend:

[B]SetEnvIf Remote_Addr "127\.0\.0\.1" loopback
SetEnvIf [...IPv6-Adressen...][/B]
CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig [B]env=!loopback[/B]

Ach ja, ich rate übrigens von solchen Bastellösungen ab, sofern es keinen dringenden Grund für die Vermeidung dieser Log-Einträge gibt. Es erhöht die Komplexität der Konfiguration, erschwert die Fehlersuche, macht eventuell Probleme bei Updates (weder die Apache-Pakete noch LiveConfig "weiß" etwas von der manuellen Konfiguration) und - last but not least - sorgt für unnötige Zusatzlast bei der Verarbeitung von Log-Einträgen.

Zitat von solidius

Wann werden die Fehler im NGINX endlich behoben ?

Auf welche LiveConfig-Version genau beziehen Sie sich? Mit v1.8.2-r3427 wurden viele Verbesserungen an der NGINX-Konfiguration vorgenommen. (http://www.liveconfig.com/de/lab)

Die Preview für Version 1.8.2 wurde soeben aktualisiert (v1.8.2-r3427).

Die Änderungen sind:

• Anzeige der DNS-Vorlage in Domain-Tabelle
• zeigt Hinweis wenn eine neue LiveConfig-Version verfügbar ist
  (hierfür wird lediglich ab sofort mit dem AppInstaller-Update auch die aktuellste LiveConfig-Versionsnummer übermittelt - es findet also keine zusätzliche Anfrage statt, weiterhin werden dabei keine Daten an uns übermittelt)
• Prüfung des Zertifizierungspfads bei CA-Zwischenzertifikaten
  (damit werden künftig "falsche" CA-Zwischenzertifikate abgelehnt um Fehlkonfigurationen zu vermeiden)
• Caching und automatische Konfiguration von CA-Zwischenzertifikaten
  (damit muss man künftig nicht für jedes einzelne Zertifikat die Zwischenzertifikate importieren - es genügt das einmal pro Zwischenzertifikat gemacht zu haben)
• Prüfung der DNSSEC-Vorausetzungen verbessert
• Markierung abgelaufener SSL-Zertifikate in Zertifikats-Liste
• SNI/SSL-Konfiguration für NGINX korrigiert
• Eingabelängen für Kontaktdaten-Felder vergrößert (für Multibyte-UTF8)
• maximale Länge für Vertragsnamen von 10 auf 63 Zeichen vergrößert
• Verzeichnis-Passwortschutz mit NGINX verbessert
  (Begrenzung der erlaubten Benutzer, bessere Unterstützung von Subdomains in Unterverzeichnissen mit Passwortschutz)

Mit v1.8.2 befinden wir uns nun im "Feature Freeze" - die neuen Funktionen werden nun noch ausführlichst durchgetestet und dann in Kürze produktiv freigegeben. Die Arbeiten an der nächsten Version (v1.8.3) umfassen u.a. das CLI, das Backup und eine bequemere DNS-Verwaltung.

Die Funktion zur automatischen Übermittlung von Stacktraces bei Programmfehlern wird vor der produktiven Freigabe vorerst wieder deaktiviert (in dieser Preview ist das noch aktiv).

Viele Grüße

-Klaus Keppler

Für's Archiv: ist mit v1.8.2-r3422 auf 63 Zeichen vergrößert.

Zitat von easynetwork

Und nach einem kurzem Check beim SSL Zertifikat ist SSL3 auch noch aktiviert ;(.

In frühen LiveConfig-Versionen hatten wir in der OpenSSL-API statt "SSLv23_method()" die Funktion "SSLv3_method()" verwendet. War "damals" (vor POODLE) kein Thema, inzwischen aber ein Problem, da mit "SSLv3_method()" keine TLS-Verbindungen möglich sind (ja, die OpenSSL-API ist an dieser Stelle etwas !$#%&...)
Kurzum: wenn wir SSLv3 abschalten, werden ältere LiveConfig-Versionen keine Lizenz mehr verlängern können. Aktuelle Versionen verbinden sich aber ohnehin via TLS1.2 mit dem Lizenz- und Updateserver.

Last but not least: um POODLE auszunutzen müsste man in der Lage sein, die Kommunikation zwischen Client und Server zu beeinflussen (z.B. via Javascript in einer Website). LiveConfig führt ausschließlich einen einzigen GET-Request aus. Ich bin kein Experte auf diesem Gebiet, soweit ich das verstanden habe ist die Verbindung so aber nicht anfällig.

Zitat

Naja, (in)direkt schon. In meiner Lizenzübersicht steht zu jeder verwendeten Lizenz die IP-Adresse des Servers. Somit ist über diese Zuordnung klar, welcher Lizenznehmer mit welcher Lizenz und ggf. mit welcher Domain der Fehler aufgetreten ist.

Das betrifft bestenfalls die Lizenzen, welche direkt über unseren Shop bestellt wurden. Bei allen über LiveConfig-Partner bestellten Lizenzen (und das ist der Großteil) wissen wir nicht, wer der Kunde ist. Und Domains kennen wir in keinem Fall (es wird nirgendwo ein Domainname übermittelt).

Für uns hat eine offene Kommunikation der an uns übermittelten Daten seit Anfang an größte Priorität. Bei "anderen" Control-Panels muss man ja bereits während der Erst-Installation seine vollständigen Kontaktdaten angeben (fragt mich bitte nicht, wozu...).
Ein Highlight ist es dann, wenn Betroffene gleich mittels iPhone bei Facebook posten, wie unverschämt es ist, dass irgendwelche Daten im Hintergrund übertragen werden...

Nachtrag: oh... das nachträgliche Umstellen von einem Einzel- auf Multiserver-Setup geht derzeit noch nicht so ohne weiteres (erfordert einige Handarbeit). Da bei einem Multiserver-Setup alle Daten zentral auf dem Server mit der Business-Lizenz gespeichert werden, müssten alle bislang separaten LiveConfig-Datenbanken zusammengeführt werden. Hierfür existiert noch kein Migrationspfad bzw. Import-Mechanismus, steht aber schon auf unserer ToDo-Liste.
Ein manueller Import durch uns ist unter bestimmten Umständen möglich; wenden Sie sich bei Interesse bitte direkt an support@liveconfig.com

Na selbstverständlich - kein Problem

Sie richten einen Server mit einer LiveConfig-Business-Lizenz ein. An diesem Server melden sich Ihre Kunden dann auch in der LiveConfig-Weboberfläche (zentral) an. Auf allen weiteren Servern installieren Sie dann lediglich einen LiveConfig-Client (Paket "lcclient") und verbinden diese mit dem zentralen LiveConfig-Server (der mit der Business-Lizenz).
Für die zusätzlichen Server benötigen Sie lediglich eine Standard-Lizenz (im o.g. Setup also insgesamt 1x Business und 1x Standard).

Viele Grüße

-Klaus Keppler

Siehe http://www.liveconfig.com/de/h…tml#advanced.mail.dovecot

In die dovecot.local.conf dann einfach die zu überschreibenenden Konfigurationsanweisungen eintragen (also z.B. "listen = x.x.x.x"), danach in LiveConfig die Dovecot-Konfiguration neu erzeugen lassen (damit die dovecot.local.conf per Include dazu geladen wird).

Viele Grüße

-Klaus Keppler

Wenn Sie einen Mac nutzen, testen Sie den FTP-Zugriff doch einfach mal per Konsole. "Terminal"-App öffnen, und dort "ftp <Server>" eingeben...

Zudem wäre es hilfreich zu wissen, welchen FTP-Server Sie einsetzen (ProFTPD oder vsftpd). Auf Anhieb glaube ich aber nicht, dass das am FTP-Server liegt...

Was das Cron-Script macht kann man ja recht einfach anschauen und nachvollziehen (ist ja nur ein kleines Shell-Script).
Im Grunde liest es für jeden Webspace aus der Standard-php.ini den Wert für "session.gc_maxlifetime" aus und löscht anhand dessen die veralteten Session-Dateien.

Wenn dabei eine Fehlermeldung auftritt, dann stimmt wohl mit mind. einer php.ini-Datei etwas nicht.

Das kommt ganz darauf an, wie Sie die "zusätzliche" PHP-Version(en) installiert haben.
Bei den von uns bereitgestellten Debian-Paketen ist das so, dass die Konfiguration aller PHP-Versionen separat in /opt/php-#/etc/ liegt. Das heißt, da legen Sie dann einfach in /opt/php-#/etc/conf.d/ z.B. eine "zend.ini" an, welche die notwendigen Befehle zum Laden der Extension enthält (zend_extension=...). Außerdem müssen Sie natürlich das Modul selbst (die .so-Datei) ins richtige Extension-Verzeichnis kopieren (da wo auch die anderen .so-Dateien der jeweiligen PHP-Installation liegen).

Hehe... interessante Idee. Aber nein, LiveConfig "bestraft" keine unlizenzierten Server.

Im Nachhinein kann man leider überhaupt nicht sagen, warum der Server langsam war; an der LiveConfig-Lizenz wird das sicherlich nicht gelegen haben. Interessant wäre die Prozesslist zu diesem Zeitpunkt gewesen (die Spalte "CPU" hilft da oft weiter), ggf mal mit "vmstat 1" den I/O auf dem Server etwas beobachten, etc...

Viele Grüße

-Klaus Keppler

Schon lange dokumentiert:
http://www.liveconfig.com/de/h…tutorial.directories.html

Zitat von arnoldB

Provider die ihren Kunden LiveConfig-Admin-Zugang zu Managed-Server u.ä. geben werden dann komische Fragen stellen. Ich als Admin würde das Dashboard dann auch nicht als Applikationsmonitoring nutzen/ missbrauchen.

Die Backtrace-Meldungen würden bei den Benutzern erscheinen, welche die Berechtigung "LiveConfig-Verwaltung" haben. Bei Managed Servern sollte die der Kunde selbst dann eigentlich nicht besitzen.
Eine reine (stille) Ablage im Filesystem nutzt uns nichts - bislang werden die Meldungen ja auch schon ins liveconfig.log geschrieben und dort (leider) meist ignoriert.

Zitat

Ich werde ohnehin demnächst versuchen die HTTP(S) Requests die zu license.liveconfig.com und update.liveconfig.com gehen über einen Proxy zu tunneln, damit ich die Internetverbindung bei den MySQL-Servern endlich kappen kann. Mal sehen wie weit ich komme.

Nicht weit, befürchte ich... Zumindest für license.liveconfig.com nutzen wir SSL-Pinning. Eine Proxy-Unterstützung wurde aber schon begonnen, setzt dann aber CONNECT voraus (ein transparenter SSL-Proxy mit eigenem CA-Zertifikat wird nicht unterstützt). Ich denke in 2-3 Wochen ließe sich das durchaus mal testen.

Viele Grüße

-Klaus Keppler

Zitat von Scopeman

könnte man die FXP Funktion (AllowForeignAddress On) bei ProFTPd bitte als Option mit in die Konfigurationsoptionen nehmen.

Äh... nein.
Es hat schon seinen Grund, warum das standardmäßig deaktiviert ist. Und der heißt "FTP Bounce Attack". Und wer nicht ganz genau weiß, was er da macht, sollte das aus lassen.

Wer dagegen weiß, was (und warum) er da macht, kann das - wie eben schon erwähnt - in die proftpd.local.conf aufnehmen (siehe Handbuch).

Viele Grüße

-Klaus Keppler

In der GNU C-Bibliothek (glibc) ist ein kritischer Fehler bekannt geworden, der es ermöglicht, unter bestimmten Umständen Schadcode ausführen zu lassen. Konkret existiert ein "Proof of Concept" für einen Angriff auf die Mailserver-Software "Exim", wenn diese eine bestimmte Konfiguration aufweist.

Auslöser ist ein Fehler in den gethostbyname*()-Funktionen, konkret wenn eine ungültige IP-Adresse zur Prüfung übergeben wird.

Wir empfehlen dringend, alle Server zu aktualisieren und die betroffenen Programme neu zu starten (es reicht nicht, nur die libc zu aktualisieren). Wer auf Nummer Sicher gehen möchte, rebootet einfach den Server (mit kexec geht das übrigens ohne die komplette Hardware neu zu starten).
Für Debian 7 wurde gestern Nachmittag bereits ein Update für das Paket "eglibc" bereitgestellt, Updates für andere Distributionen sollten inzwischen auch verfügbar sein oder in Kürze folgen.

Bei folgenden Diensten lässt sich laut Qualys der Fehler nicht ausnutzen: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd

LiveConfig verwendet die Funktion gethostbyname() übrigens nicht (ausschließlich getaddrinfo()).

Die vollständige Beschreibung zum Fehler gibt's unter http://seclists.org/oss-sec/2015/q1/274

Viele Grüße

-Klaus Keppler

Doch, eigentlich schon... Server -> Serververwaltung -> E-Mail -> z.B. bei Postfix "bearbeiten..."-Button klicken.
Dann in irgendeinem Feld was ändern so dass der "speichern"-Button aktiviert wird -> speichern klicken.
Die main.cf sowie ggf SSL-Zertifikate sollten dann unmittelbar neu geschrieben werden (siehe Dateiänderungsdatum).
Falls nicht: /var/log/liveconfig/liveconfig.log

Das Statement ist ganz einfach: die Preise stehen fest, ein komplizierteres Modell wird es nicht geben.

Wer beispielsweise die Datenbanken auf einen separaten Server auslagert, der hat ja auch die Kosten für den Server zu tragen. Und wer das auf eine separate virtuelle Maschine verlagert, der hat auch die Kosten für die zusätzliche Administration dieser VM zu tragen. Ich verstehe nicht, warum ausgerechnet wir dafür dann Rabatte auf LiveConfig geben sollten...?
Rechnen Sie bitte einfach mal aus, was ein Administrator oder ein Softwareentwickler durchschnittlich pro Monat kostet. Berechnen Sie dann, wie viele Minuten dessen Leistung Sie für 8,23 Euro (entspricht 9,80 EUR brutto) bekommen.

Für private Anwender mag das sicher relativ teuer sein, vor allem wenn man wie heutzutage schon komplette dedizierte Server für keine 20 Euro pro Monat mieten kann. Das heißt aber nicht, dass ich meine Mitarbeiter hier analog auch mit 600 Euro brutto monatlich nach Hause schicken kann.
Mit einem separaten Wartungsvertrag oder einem fünfstelligen Commitment können wir selbstverständlich über individuelle Preise reden. Alles andere wäre für uns aber ein Draufzahlgeschäft. Es gibt nunmal gewisse Preis-Untergrenzen, sei es für den Strom oder eben die Verwaltungssoftware.

Da wir nicht vorhaben, unser Geschäft in absehbarer Zeit einzustellen weil sich mit Software nichts mehr verdienen lässt, planen wir auch nicht, an den Preisen etwas zu ändern. Vergleichen Sie die Preise gerne auch mit denen anderer kommerzieller Control-Panels - dann werden Sie feststellen, dass LiveConfig nicht wirklich teuer ist.

Viele Grüße

-Klaus Keppler

Danke für das Feedback!
Das SSL für update.liveconfig.com ist bekannt (wird bislang nur intern für die Repository-Anfragen für den AppInstaller verwendet). Und ja, auch ich mag es überhaupt nicht, wenn Software "nach Hause telefoniert". Daher ist es mir wichtig, das offen und transparent zu kommunizieren.

Ein Spooling der angefallenen Daten und selektives Senden ist natürlich möglich. Auch hier haben wir aber die Herausforderung, dass der Admin es eventuell gar nicht mitbekommt, dass da was angefallen ist.

Ich denke daher, dass wir Backtraces daher zwischenspeichern und auf der "Dashboard-Seite" (Übersichts-Seite bei der Anmeldung) einen sichtbaren Hinweis einbauen á la "Es ist ein Fehler aufgetreten - dürfen wir folgende Daten senden? [...(Daten)...]". Mit einem Klick auf "ok" geht das dann raus - eventuell mit einer Checkbox "[ ] künftig automatisch senden".

Viele Grüße

-Klaus Keppler

Ab sofort steht Version 1.8.2 in einer ersten Preview bereit. Diese enthält u.a. folgende Änderungen:

• automatische Meldung von Backtraces:
  Wenn LiveConfig mit einem Segmentation Fault abstürzt, wird künftig automatisch der Backtrace (also die Programmadressen, die zum Absturz geführt haben) automatisch per HTTPS an update.liveconfig.com gesendet. Außerdem wird natürlich noch die genaue Versionsnummer und Kernelversion übermittelt (damit wir wissen, auf welcher Plattform das passiert ist). Eine vollständige Meldung sieht dann z.B. so aus:
  
  
  Code

  Process: liveconfig/server
  Version: 1.8.1-3400:3401M
  Backtrace:
    [ 0] 0x46d410
    [ 1] 0x439316
    [ 2] 0x7fb7ea2a00a0
    [ 3] 0x7fb7e96382b3
    [ 4] 0x46c5ae
    [ 5] 0x40a3b4
    [ 6] 0x439568
    [ 7] 0x43b495
    [ 8] 0x4386b7
    [ 9] 0x4088c1
    [10] 0x7fb7e9580ead
    [11] 0x4089b5
  Additional informations:
   - OS system release: 3.2.0-4-amd64

  Alles anzeigen

  
  Mehr Daten werden nicht übermittelt! Diese Informationen sind nicht sicherheitsrelevant und erleichtern uns die Arbeit erheblich. Unserer Erfahrung nach merken viele Kunden es gar nicht, wenn mal ein Fehler auftritt, da sich die betroffenen LiveConfig-Prozesse automatisch neu starten.
  Dieser Crash Report lässt sich aber auch abschalten (dafür werden wir noch eine Konfigurationsoption schaffen). Wir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.
  

• Fehler beim Löschen einer Subdomain bei von LiveConfig verwaltetem DNS behoben

Eine Hand voll kleinerer Änderungen wird derzeit noch integriert, ein Release ist noch für diese Woche geplant.

Viele Grüße

-Klaus Keppler