Beiträge von kk

Ich tippe mal darauf, dass /tmp mit dem Flag "noexec" gemountet ist?
Da wird es dann auch bei anderen Paket-Updates krachen.

Update: einer Diskussion auf HackerNews zufolge ist LiveConfig tatsächlich nicht betroffen.
(gefährdet scheint nur Software zu sein, bei der beliebige SQL-Befehle ausgeführt werden können; wo das der Fall ist, hat man aber ohnehin ein anderes Problem: SQL Injections

Hallo,

ab sofort steht LiveConfig v2.7.3 (r5163) zum Download bereit.
Die einzige Änderung gegenüber der vorherigen Version (2.7.2-r5133) ist, dass die enthaltene SQLite-Bibliothek von 3.25.3 auf 3.26.0 aktualisiert wurde.

Vor wenigen Tagen haben Sicherheitsforscher der Firma "Tencent" eine Sicherheitslücke in SQLite entdeckt, welche in manchen Fällen die Ausführung beliebigen Codes erlauben soll.
Nach allem, was wir bislang in Erfahrung bringen konnten, dürfte LiveConfig eigentlich ohnehin nicht davon betroffen sein, da LiveConfig SQL-Befehle ausschließlich als "Prepared Statements" ausführt, und auch keine "fremden" SQLite-Dateien geöffnet werden können. Da aber bislang keine weiteren Details zur Lücke bekannt sind, haben wir uns entschlossen, SQLite sicherheitshalber zu aktualisieren.

Wenn uns weitere Informationen zur SQLite-Sicherheitslücke vorliegen, werden wir hier darüber berichten.

Viele Grüße

-Klaus Keppler

Kurz zur Info: mit LiveConfig v2.8.0 gibt es einen LCDefaults-Key "mail.forwards.blacklist", bei dem man bestimmte Zieldomains für die Verwendung in E-Mail-Weiterleitungen sperren kann (kommagetrennte Liste). Also z.B. so was wie "gmx.de,web.de,t-online.de".
Bestehende Weiterleitungen sind davon nicht betroffen, die Blacklist wird nur beim Anlegen oder Bearbeiten eines Postfachs geprüft.

Zitat von Citytow

https://sslcheck.liveconfig.com/ <-Die Website ist nicht erreichbar sslcheck.liveconfig.com hat die Verbindung abgelehnt.

Nanu, für sslcheck.liveconfig.com war doch tatsächlich noch gar kein SSL aktiviert. Wurde soeben nachgeholt. Letztendlich ist das aber nur eine Weiterleitung auf die genannte LiveConfig-Website.

Zitat von tfi

Wir würden nun gerne den Standard überall auf 7.3 setzen ohne aber die bestehenden Verträge/Webseiten,
die in der Auswahl Standard (und damit 5.6 usw.) gewählt haben, zu beeinflussen.

Soll PHP 7.3 also nur für neue (Sub)Domains als "Standardversion" voreingestellt werden?
Das ist nicht ganz einfach. "Standardversion" bedeutet, dass für die betroffene Domain keine bestimmte Version fest eingestellt ist. Man kann höchstens sagen, dass alle Verträge die aktuell die Standardversion (z.B. 5.6) nutzen, fix auf 5.6 eingestellt werden und anschließend z.B. 7.3 als neue Standardversion festsetzen. Damit sind aber die alten Verträge auf die bislang alte Standardversion "festgenagelt".

Zitat

Speichert sicht LC die PHP-Version für diese Verträge/Webseiten mit der passenden Version oder als "standard"
und wenn wir nun "standard" umstellen, stellen wir auch die PHP-Versionen für die Webseiten um?

Technisch betrachtet speichert LiveConfig bei den Domains, bei denen "Standard" ausgewählt ist, einfach keine Versionsnummer sondern wählt während die vHost-Konfiguration erzeugt wird die Version, die als PHP-Standardversion erkannt bzw. festgelegt wurde.

Zitat

Edit - Auch wenns nicht ganz zum Thema passt:
Ist es möglich sich die Verträge auflisten zu lassen, die eine gewisse PHP-Version verwenden?
Wir wollen uns einen Überblick verschaffen bei welchen Verträgen noch PHP 5.5/5.6 aktiv ist
um diesen Kunden eine Infomail zukommen zu lassen.

grep -l php56 /etc/apache2/sites-available/*.conf

Viele Grüße

-Klaus Keppler

Zitat von pitgrap

Ich habe nun verschiedene Clients aus dem Firmennetz getestet und Clients außerhalb. Alle aus dem Firmennetz erhalten eine Antwort ohne Starttls, alle anderen mit.

Daher tippe ich aktuell auch auf die Firewall.

Die wird es sicher sein. Der Mailserver unterscheidet nicht nach Herkunft der Verbindung - der bietet allen SSL an. In großen Netzen ist es üblich, dass kein verschlüsselter (= nicht scanbarer) Traffic nach außen geht. Einfach mal mit den lokalen (zuständigen) Admins sprechen, ob eine "unverschlüsselte" Verbindung (bis zur Firewall) erlaubt ist, bzw. was die empfehlen würden.

Zitat von pitgrap

ich habe das Problem, dass ein Programm (SAP) E-Mails mittels .NET verschickt.

Das sind sogar zwei Probleme.

Scherz beiseite.

Zitat

EDIT: ich habe mich gerade per telnet mal mit dem Postfix verbunden und nach dem EHLO antwortet dieser nur

Code

250-Requested mail action okay, completed
250-SIZE 20000000
250-ETRN
250-8BITMIME
250 OK

Ich hätte erwartet, dass dort auch sowas wie "250-STARTTLS" zurückkommt. Ich denke, dass dies auch der .NET Client erwartet und deswegen die Fehlermeldung zurück gibt.

Ja, der Server bietet offensichtlich kein SSL an.

Ist denn im LiveConfig SSL für Postfix aktiviert und konfiguriert? Sie können den SSL-Zugriff auch mal via https://sslcheck.liveconfig.com testen.

Da das Ganze offenbar unter Windows stattfindet, kann es auch sein, dass sich ein lokaler Virenscanner dazwischen klemmt. Die akzeptieren häufig keine verschlüsselte Verbindung auf lokaler Seite.

Wenn der SSL-Check (s.o.) also auf den Ports 25 und 587 ein SSL-Zertifikat anzeigt, prüfen Sie mal ob ein lokaler Virenscanner (oder eine transparente Firewall o.ä.) läuft und evtl. die Verbindungen abgreift.

Ja. Um genau zu sein muss dann idealerweise nichts mehr gemacht werden - neue Domains sollen nach dem Anlegen automatisch SSL-Zertifikate erhalten können.

Ist aktuell in Arbeit - sowohl über HostingDomainAdd() als auch über die GUI direkt beim Anlegen der Domains. Dabei wird die SSL-Komponente etwas umfangreicher umgebaut (um auch andere Anbieter automatisiert einbinden zu können), wird bis März 2019 fertig sein.

Hallo,

ab sofort stehen unsere PHP-Pakete für Debian/Ubuntu auch in Version 7.3.0 bereit. Zudem wurden restlichen PHP-Versionen auf 5.6.39, 7.0.33, 7.1.25 und 7.2.13 aktualisiert.

Der Support für PHP 5.6 läuft zum Ende diesen Jahres offiziell aus - es wird dann keine Sicherheitsupdates mehr dafür geben.

Viele Grüße

-Klaus Keppler

In der custom.lua die Variable "LC.web.PHPDEFAULT" auf die gewünschte PHP-Version setzen, z.B.:

LC.web.PHPDEFAULT = "php71"

Anschließend LiveConfig neu starten, dann eine IP-Gruppe, Hostingangebote oder Verträge bearbeiten um die vHost-Konfigurationen neu schreiben zu lassen.

Viele Grüße

-Klaus Keppler

Weil ich gerade sehe dass die Antwort hier noch fehlt: es gibt offenbar einen Bug im PHP Opcache, wenn man auf Phar-Archive zugreift und Opcache die Daten im Shared Memory cached.

Der Fehler lässt sich umgehen, indem man die php.ini-Einstellung "opcache.file_cache_only" von "no" auf "yes" setzt. Damit wird der compilierte Bytecode im jeweiligen Cache-Verzeichnis als Datei abgelegt, und nicht mehr im Shared Memory. Im Zeitalter von SSDs hält sich der "Impact" dabei auch in Grenzen.

Weitere Infos auch im GitHub-Ticket des Contao Managers: https://github.com/contao/cont…47#issuecomment-434752134

Ab LiveConfig v2.7.1 ist die Einstellung "opcache.file_cache_only" in der php.ini-Verwaltung enthalten und kann durch Kunden von "no" (Standard-Einstellung von PHP) auf "yes" geändert werden.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig v2.7.2 (r5133) zum Download bereit.

Mit diesem Update werden einige kleinere Fehler behoben sowie die enthaltene OpenSSL-Bibliothek auf v1.1.1a aktualisiert. Alle Änderungen finden sich wie immer im Changelog.

Viele Grüße

-Klaus Keppler

Ohne zu wissen welcher Prozess die Last verursacht, kann man leider NICHTS machen.

Prozessliste: "ps aux".

Hello,

we've just updated our PHP 7.3 packages for Debian/Ubuntu to version 7.3.0-RC6. Also the APCu and ImageMagick extensions for PHP 7.3 are now available through our repositories.

PHP 7.3 "stable" is expected to be released on 12/06/2018.

Best regards

-Klaus Keppler

Hallo,

wir haben eben die Debian/Ubuntu-Pakete für PHP 7.3 auf die Version 7.3.0-RC6 aktualisiert. Außerdem stehen für PHP 7.3 ab sofort auch die APCu- und ImageMagick-Extensions in den Repositories bereit.

Wenn nichts dazwischen kommt, soll PHP 7.3 "stable" am 06.12.2018 (Nikolaus) erscheinen.

Viele Grüße

-Klaus Keppler

Log in as "admin", and go to "Server Management" -> "Databases". In the box with the MySQL properties, look at the status message (right column). What is displayed there? "Status: Connected"?

In most cases when LiveConfig can't create a database, the MySQL credentials have changed and weren't updated at LiveConfig.

Hallo,

ab sofort steht LiveConfig v2.7.2 als Preview bereit. Neben einem trivialen Bugfix (Wildcard-Subdomains können nun wieder angelegt/verwaltet werden) wurde mit diesem Update auch die Kommunikation zwischen LiveConfig-Client und -Server-Prozess verbessert.
Wer mag, kann das Update jederzeit risikofrei einspielen. Unsere Tests sind alle problemlos durchgelaufen, im Zweifelsfall ist aber ein Downgrade auf 2.7.1 jederzeit möglich (am Datenbankschema hat sich nichts geändert).
Auch die von einigen Anwendern gemeldeten Probleme beim Download von Backups (auf Single-Server-Systemen) könnten damit behoben sein.

Viele Grüße

-Klaus Keppler

(Tech-speak: unter bestimmten Bedingungen (sehr schnelle Systeme, schneller I/O, viele LiveConfig-Threads, viele LiveConfig-Jobs - insbes. DNS-Updates) konnte es dazu kommen, dass aufgrund mangelnder Thread-Synchronisation die Kommunikation "durcheinander kam" (das gab dann Fehlermeldungen mit Hinweis auf's LCCP-Protokoll).

Wir haben ein mögliches Problem in der Client-Server-Kommunikation von LiveConfig behoben. Die Preview von LiveConfig v2.7.2 steht bereits zum Download bereit, ein separater Hinweis dazu erfolgt gleich hier im Forum.