Beiträge von bfal

Ja meine TestVM war wirklich nur eine minimale Debian9 Installation wo ich erst einmal nur die PHP Pakete installiert hatte (zum testen) um zu schauen was diese alles mitbringen. Ist natürlich möglich das sonst die "libltdl" schon per Abhängigkeiten mit kommt. Da mir persönlich jedoch das PHP Modul "tidy" fehlt passten die Pakete für mich derzeit nicht.

Ich habe gerade auf einem frischen Debian 9 die PHP Pakete installiert und dabei noch 2 kleine Fehler gefunden.
Zwar nichts kritisches aber könnte ja vielleicht gefixt werden.

1. PHP 7.1 meldet nach der Installation das die "libltdl.so.7" nicht gefunden werden kann.

root@debian9:/# /opt/php-7.1/bin/php-cgi -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/opt/php-7.1/lib/php/extensions/no-debug-non-zts-20160303/mcrypt.so' - libltdl.so.7: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 7.1.6 (cgi-fcgi) (built: Jun 29 2017 09:43:01)
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.1.6, Copyright (c) 1999-2017, by Zend Technologies

Hier hilft die Installation des Debian Paketes "libltdl7". Dies sollte vielleicht in den Abhängigkeiten mit aufgenommen werden.

2. PHP 5.5 meldet das Modul pdo_mysql.so ein "undifined symbol....".

root@debian9:/# /opt/php-5.5/bin/php-cgi -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/opt/php-5.5/lib/php/extensions/no-debug-non-zts-20121212/pdo_mysql.so' - /opt/php-5.5/lib/php/extensions/no-debug-non-zts-20121212/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0
PHP Warning:  Cannot load module 'mysql' because required module 'mysqlnd' is not loaded in Unknown on line 0
PHP 5.5.38 (cgi-fcgi) (built: Jun 29 2017 07:41:30)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Hier fehlt unter "/opt/php-5.5/etc/conf.d" die "mysqlnd.ini" mit folgenden Inhalt.

; configuration for php MySQLnd module
extension=mysqlnd.so

Dann ist auch dieser Fehler behoben.

Ich schließen mich andreas Meinung vollkommen an. Viele zusagen und versprechen aber man merkt nicht das etwas passiert. Auch wurde ja mal Redmine für die Roadmap usw. eingerichtet....aber wirklich gepflegt wurde da nie was. Kein Stable Release seit dem 04.10.2016 ist auch nicht toll....wenigsten das Thema Bugfixing sollte da eigentlich schon neue Bugfix Release bringen.
Mir persönlich ist es als Kunde auch egal was hinter den Kulissen passiert. Fakt ist doch nun einmal das die Informationspolitik dürftig ist, und auch wenn ich immer noch etwas Hoffnung haben kann man das doch nicht wirklich schön reden.

Das würde mich ehrlich gesagt auch interessieren!

Freut mich das es jetzt geht.

Vielleicht sollte die "SSLProxyEngine" Geschichte noch in die Doku aufgenommen werden?!
Zumindest wenn Liveconfig nicht auf Port 443 läuft.

Grüße
Björn

Moin,

er sagt eigentlich schon in der Meldung was er braucht.
Ich habe das einfach über die .httpd.conf gelöst. Einfach im Root des Vertrages die Datei .httpd.conf mit folgendem Inhalt anlegen.

<IfModule mod_ssl.c>
    SSLProxyEngine On
</IfModule>

Danach z.B. die Subdomain neu speichern damit Liveconfig die .httpd.conf einbindet und dann sollte es passen.

Grüße
Björn

Kann ich mit der aktuellen Lab Version 2.3.0 (r4448) nachvollziehen. Auf einer Basic Lizenz wird unter Domains nichts mehr angezeigt.

Es wäre echt toll wenn in der "Domains" Übersicht die Einträge mit DNS Einträgen hervorgehoben werden könnten so das man gleich erkennt wo Einträge vorhanden sind.
Vielleicht mit einem Icon oder ähnliches.

Du kannst doch in den "PHP-Einstellungen", wenn du dich als Admin anmeldest, die Limits setzten wie du Lustig bist. Setze das Limit doch einfach höher?!

Du kannst doch einfach nach der Domain filtern. Dann siehst du nur die E-Mail Adressen welche zur Domain gehören.

Als Admin angemeldet kannst du das unter "PHP-Einstellungen" definieren. Hier kannst du dann den MIN und MAX Wert definieren.

Besser wäre es doch eigentlich die Optionen welche nicht erlaubt sind gleich ganz auszublenden statt diese weiterhin anzuzeigen, egal welche Farbe.

Damit "top" oder "ps" nur die eigenen Prozesse eines Users anzeigen kann man das per fstab konfigurieren.
Der Parameter heißt "hidepid" was dann z.B. folgendermaßen aussehen würde:

proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2 0 0

So sieht User "x" nicht was für Prozesse "y" laufen hat.

Ist hier doch erklärt:
https://www.liveconfig.com/de/forum/threads/2253-Änderungen-an-liveconfig-meta

Ah ok...zugegeben. Einfach den User des Prozesses zu ändern ist eine zu einfache Lösung, so gehts natürlich auch

Ich sehe du kennst das Problem nicht. Denn den OPTIONS Part ändern....bringt beim Cronjob zwecks Spamassassin Rules Update genau nix. Du müsstest im Cron.daily Job auch alle User angaben ändern.
Das spare ich mir hier....oder anders gesagt es ist die kleinste Änderung.

Die eigentliche Frage wäre eher....warum macht Liveconfig hier eine extra Wurst und nutzt nicht die Vorgaben der Distribution?!

Ich befehle mir damit das ich in der "/etc/cron.daily/spamassassin" nach dem Update mit folgendem Befehl die Rechte anpasse so das es keine Probleme gibt.

chown -R spamd.debian-spamd /var/lib/spamassassin/.spamassassin/bayes_* && chmod 660 /var/lib/spamassassin/.spamassassin/bayes_*

Nicht schön....aber funktioniert.

Nicht übel nehmen aber Ubuntu und mehr Sicherheitsupdates ist echt lustig...gerade bei der LTS Version.
Ich verweise mal auf: http://www.heise.de/ct/artikel…s-Wichtigste-3179960.html

Ubuntu ist gerade da viel löchriger.

Beides. Liveconfig setzt eine Grundkonfiguration welche durch den Admin beliebig angepasst werden kann.

Wenn man es genau nimmt verhält es sich doch so wie gewollt. Wenn bei einer Domain "test.de" per SPF Eintrag festgelegt ist welcher Server Mails mit der Domain versenden darf betrifft das doch logischerweise auch Weiterleitungen welche von einem Server kommen der nicht erlaubt ist.
SPF und SRS ist beides eine Krücke, genau betrachtet läuft es aber richtig, zumindest gemäß des SPF Eintrages