Beiträge von kk

Nicht nur das. NGINX kann (wenn er nicht als "www-data" läuft) überhaupt nicht auf die Webspace-Verzeichnisse zugreifen und somit keinen Content ausliefern.

Zitat von trg2889

Nginx läuft unter folgenden Rechten:nginx/nginx

Das wird vermutlich genau das Problem sein.
/var/www/<Vertrag>/htdocs/ gehört <Vertrag>:www-data (mode=0750), der User "nginx" kommt da also nicht rein.
Unter Debian ist es üblich, dass NGINX auch als www-data:www-data läuft. Das müsste also angepasst werden, dann sollte alles funktionieren.

PHP 7 unter Ubuntu 14 wird dann ohnehin eine Herausforderung, weil die meisten von PHP7 benötigten Bibliotheken gar nicht unter Ubuntu 14 verfügbar sind (einfachstes Beispiel: OpenSSL 1.1).
Ich empfehle dringend ein Dist-Upgrade auf Ubunru 16, damit hält man sich viele Probleme vom Hals. Und es tut auch gar nicht weh.

Naja, im einfachsten Fall nur "./configure" ausführen. Alles weitere kommt eben darauf an, was man braucht und wo PHP installiert werden soll.
Es würde daher auch nichts nutzen, wenn ich die configure-Aufrufe für die von uns bereitgestellten Pakete heraussuche - die Parameter variieren zwischen allen Distributionen und den zu bauenden Extensions.
Vom Bau eigener PHP-Pakete rate ich daher dringend ab, so lange man nicht genau weiß was man tut.
Lieber unsere Pakete oder die von deb.sury.org verwenden.

Immer wenn ein "500 Internal Server Error" generiert wird, erzeugt Apache auch einen Eintrag in der /var/log/apache2/error.log (bzw. wenn im LiveConfig unter "Webspace" der Punkt "Fehlerprotokoll aktivieren" eingeschaltet ist, im dortigen error.log).
Diese Fehlermeldung hilft sicher weiter.

Zitat von dicker

Ich habe es jetzt bei zwei Kunden Accounts getestet. Da hat es funktioniert.

Stelle ich eine Domain, die unter *Mein Hosting* registriert ist auf 5.6.4 um, dann kommt immer error.

Dann vergleichen Sie mal, wie die PHP-Ausführung konfiguriert ist (Vertragseinstellung) - FastCGI, suPHP oder FPM. Das wird beim "eigenen" Vertrag und bei den Kunden vermutlich unterschiedlich sein.
Die Ausgabe von liveconfig --diag ist leider zu sehr gekürzt - die ganze Liste der PHP-Versionen fehlt da. Da würde nämlich stehen, welche PHP-Version wie verfügbar ist (FPM/FastCGI).

Was liefert der folgende Befehl?

/opt/php-5.6/bin/php -v

Und was liefert "liveconfig --diag" (der Abschnitt rund um PHP genügt)

Zitat von weltmeister

Momentan geht die Entwicklung für viele gewünschte Erweiterungen sehr schleppend voran... oder täuscht das?

Die Release-Häufigkeit hat nichts mit der Entwicklungsgeschwindigkeit zu tun.
Es tut sich im Moment *sehr* viel, nur können wir das noch nicht alles gleich freigeben. Bitte noch ein klein wenig Geduld. In v2.8 gibt es große Änderungen.

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 5.6.40, 7.1.26, 7.2.14 und 7.3.1 aktualisiert.

Offizielle Sicherheitsupdates von PHP gibt es ab sofort nur noch für die Versionen ab 7.1 (PHP 5.6 und 7.0 ist nun "end of life").

Viele Grüße

-Klaus Keppler

Zitat von sTeaLth

Ist die Option "date.timezone" in php56 noch kein Standard oder warum wird diese nicht gesetzt

Soweit ich weiß ist diese Option standardmäßig in der php.ini auskommentiert. (PHP kann ja nicht wissen, in welchem Land es gerade eingesetzt wird)

Die sauberste Lösung ist:

• im LiveConfig als "admin" anmelden
• zur php.ini-Verwaltung gehen
• dort einen neuen Eintrag vom Typ "Zeichenkette" anlegen. Name="date.timezone", Wert="Europe/Berlin". Änderungen durch den Kunden ggf. erlauben.

Damit landet diese Einstellung dann in allen mit LiveConfig genutzten PHP-Versionen.

Viele Grüße

-Klaus Keppler

Ihr CMS hat sich irgendeine Malware eingefangen.
Von dieser URL wird Code nachgeladen, der dann auf dem Webserver ausgeführt wird (häufig irgendwas um Malware/Trojaner weiter zu verteilen).

Lassen Sie am besten mal einen lokalen Malware-Scan laufen (z.B. Linux Malware Detect).

Die Website an sich sollte schleunigst abgeschaltet werden, bevor diese bei Google etc. auf einer Blacklist landet.

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.