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
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.
ZitatIch 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
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:
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
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.
Eine Hand voll kleinerer Änderungen wird derzeit noch integriert, ein Release ist noch für diese Woche geplant.
Viele Grüße
-Klaus Keppler
Die PHP-Pakete für Debian wurden auf die neuesten Versionen aktualisiert (5.4.37, 5.5.21, 5.6.5).
Siehe auch: KB#22.
Viele Grüße
-Klaus Keppler
Senden Sie einfach mal von extern eine E-Mail an eine dieser neu angelegten Adressen. Was genau wird anschließend alles in /var/log/mail.log auf Ihrem Server protokolliert?
a) gar nichts: das deutet darauf hin, dass mit dem DNS/MX was nicht passt (evtl noch alter Wert in anderen Caches)
b) Mail wird abgewiesen: dabei sollte der einliefernde Mailserver eigentlich ein Bounce erzeugen
c) Mail wird zugestellt (dann gibt's ein anderes Problem)
Wenn ich dem Emailserver(Debian) ein neues Cert zuweisen will passiert leider nichts. In den logs steht nur das das Dovecot/Postfix neugestartet werden. Das Cert im Dovecot verzeichnis ist aber definitiv noch das alte.
Werden wir uns mal anschauen. Hilft es evtl. die Postfix- bzw. Dovecot-Konfiguration neu zu speichern? (dabei sollte das Zertifikat neu geschrieben werden)
ZitatDas zweite Problem ist das auch das zuweisen nicht funktioniert. Also wenn man ein Cert als Administrator anlegt und es einem anderen User zuweist erscheint es einfach nicht bei einem User(verschiedene Certs und User habe ich probiert) in der Liste.
Wenn Sie als Admin oder Reseller ein SSL-Zertifikat anlegen und einem Kunden zuweisen, dann taucht das nicht in der SSL-Liste des Kunden auf (falls dieser die Berechtigung "SSL-Zertifikate verwalten" hat), sondern kann ausschließlich bei der Webspace-Konfiguration ausgewählt werden (Hosting -> Domains -> (Sub)Domain bearbeiten).
Sinn des Ganzen ist, dass der Endkunde so eben nicht den Private Key des Zertifikats sehen kann.
Das klingt nicht gut...
Schicken Sie uns bitte den Backtrace aus dem LiveConfig-Log (/var/log/liveconfig/liveconfig.log) inklusive der exakten Versionsnummer und Name/Version Ihrer Distribution an support@liveconfig.com damit wir das analysieren können.
Viele Grüße
-Klaus Keppler
Ab sofort steht LiveConfig v1.8.1 (r3397) zum Download bereit.
Dieses Update bringt hauptsächlich Fehlerbereinigungen und Detailverbesserungen - eine vollständige Liste finden Sie im Changelog. Die neuen Funktionen sind im Handbuch beschrieben (u.a. individuelle Konfiguration von ProFTPD, Postfix und Dovecot sowie Änderung von Standardwerten (LCDEFAULTS)).
Ab nächster Woche stellen wir dann die erste Preview der nächsten Version (v1.8.2) bereit, zudem wird nun endlich mal die (öffentliche) Roadmap aufgeräumt.
Vielen Dank nochmals für das großartige Feedback, die Unterstützung bei der Fehlersuche und - last but not least - für die Verwendung von LiveConfig.
Im Namen des gesamten Entwicklerteams
-Klaus Keppler
Tolle Sache, eine Frage noch dazu. Wie sollen leute die SQLite nutzen die lcdefaults anpassen ? Vielleicht wäre eine Einbindung ins GUI hilfreich
Es wird bereits an einem CLI für LiveConfig gearbeitet (Command Line Interface), u.a. um die Automatisierung der Installation zu vereinfachen. Da gibt's dann auch eine Möglichkeit, die LCDEFAULTS-Werte zu setzen.
Viele Grüße
-Klaus Keppler
Ab sofort steht v1.8.1-r3397 als Preview-Version zur Verfügung.
Das Handbuch wird morgen aktualisiert, dann erfolgt auch die "stable"-Freigabe.
Dieses Update enthält insbesondere einige Verbesserungen an den Lua-Scripten sowie einige GUI-Bugfixes.
Viele Grüße
-Klaus Keppler
Hallo,
mit Version 1.8.1-r3397 (ab sofort als Preview, ab morgen dann "stable") können Sie zusätzliche Einstellungen in einer separaten Datei pflegen.
Legen Sie dazu eine Datei namens /etc/proftpd/proftpd.local.conf an und tragen dort Ihre gewünschten Einstellungen ein. Anschließend klicken Sie im LiveConfig in der ProFTPD-Verwaltung den Button "neu konfigurieren" - das war's. In der aktualisierten proftpd.conf sollte nun ein "Include" auftauchen, der Ihre proftpd.local.conf nachlädt.
Ab morgen auch im Handbuch zu finden...
Viele Grüße
-Klaus Keppler
Der Fehler trat auf, wenn nach der Eingabe vom "&" (oder anderen HTML-Entities) im Passwort-Feld das Formular aktualisiert wurde (z.B. aufgrund der Auswahl von Kontaktdaten). LiveConfig hat praktisch "doppelt escaped".
Wurde mit v1.8.1-r3391 behoben (erscheint in Kürze)
Viele Grüße
-Klaus Keppler
