Beiträge von aho546745

Ja, jetzt keine Fehlermeldung mehr

Also bei mir kommen heute neue Fehler. Debian 11

ich habe:

- unter /etc/apt/sources.list.d alles entfernt

- liveconfig-keyring Paket entfernt, weil es mit dpkg-reconfigure einen Fehler geschmissen hat, dass ihm die entsprechende -dist Datei fehlt

- liveconfig-keyring erneut mit dpkg -i liveconfig-keyring.... installiert

Dadurch werden die beiden Dateien für lc und php-opt unter /etc/apt/sources.list.d wieder angelegt, anschließend kommt dann dieser Fehler:

Hit:1 http://ftp2.de.debian.org/debian bullseye InRelease
Get:2 http://repo.liveconfig.com/debian main InRelease [3,968 B]
Hit:3 http://security.debian.org/debian-security bullseye-security InRelease
Hit:4 http://ftp2.de.debian.org/debian bullseye-updates InRelease
Get:5 http://repo.liveconfig.com/debian bullseye InRelease [1,816 B]
Err:2 http://repo.liveconfig.com/debian main InRelease
  The following signatures were invalid: EXPKEYSIG D409AC6D65FE6664 LiveConfig Package Signer <pkgadmin@liveconfig.com>
Reading package lists... Done
W: GPG error: http://repo.liveconfig.com/debian main InRelease: The following signatures were invalid: EXPKEYSIG D409AC6D65FE6664 LiveConfig Package Signer <pkgadmin@liveconfig.com>
E: The repository 'http://repo.liveconfig.com/debian main InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Sollte nicht genau dieses Problem gelöst werden durch dieses Paket?

Ich habe die Schritte aus: https://www.liveconfig.com/de/…rung-des-repository-keys/ nun mehrmals ausgeführt, das ist doch schon wieder so ein jämmerliches Trauerspiel.

Die vom Paket angelegte Datei mit dem Keyring hat auch ein monatealtes Änderungsdatum, aber ok, es sind wohl beide Keys drin.

Warum wird der alte Key verwendet?

25093# dpkg -i /root/liveconfig-keyring.deb
Selecting previously unselected package liveconfig-keyring.
(Reading database ... 155051 files and directories currently installed.)
Preparing to unpack /root/liveconfig-keyring.deb ...
Unpacking liveconfig-keyring (2023.2-4) ...
Setting up liveconfig-keyring (2023.2-4) ...

25094# l /usr/share/keyrings/liveconfig-keyring.gpg
-rw-r--r-- 1 root root 3580 Sep  7  2023 /usr/share/keyrings/liveconfig-keyring.gpg

Besten Dank

Ich hab die Schritte hier: https://www.liveconfig.com/de/…rung-des-repository-keys/ durchgeführt, allerdings wenn ich das PHP Repo aktiv habe, siehe hier: https://www.liveconfig.com/en/…liveconfig-php-repository dann erhalte ich:

...
Err:3 http://repo.liveconfig.com/debian bullseye InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AFC55937C236EB95
Reading package lists... Done
W: GPG error: http://repo.liveconfig.com/debian bullseye InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AFC55937C236EB95
E: The repository 'http://repo.liveconfig.com/debian bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

25063# cat php-opt-lc.list
deb http://repo.liveconfig.com/debian/ bullseye php

Was ist zu tun?

Ich würde auch gern mal postgres als DB für diverse CMS testen

Mittlerweile hab ich herausgefunden, dass kunden-seitig die Problem-Adresse extra definiert war und daher vom Catchall nicht erfasst wurde, die Änderung wurde dann während meiner Debug-Versuche vorgenommen. Das mit dem Neustart war Zufall. Ich wollte das nur erstmal hier schreiben, damit niemand auf Fehlersuche war, tatsächlich war - da haben sie recht - der Neustart des Postfix nicht die Lösung.

Mittlerweile hab ich herausgefunden, dass kunden-seitig die Problem-Adresse extra definiert war und daher vom Catchall nicht erfasst wurde, die Änderung wurde dann während meiner Debug-Versuche vorgenommen. Das mit dem Neustart war Zufall. Ich wollte das nur erstmal hier schreiben, damit niemand auf Fehlersuche war, tatsächlich war - da haben sie recht - der Neustart des Postfix nicht die Lösung.

Hat sich erledigt, siehe unten

Servus,

seit eben registriere ich ein weiteres seltsames Verhalten.

Ich habe mehrere Catchall-Adressen eingerichtet, für diese kann man den Spamassasin nicht einschalten.

Trotzdem werden Emails abgewiesen:

Jan  2 20:51:33 server6 lcsam[925]: 69.169.224.107: REJECT (SPAM 0.0/0.0/0.0 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_IMAGE_RATIO_06,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS), From: =?utf-8?Q?M=C3=BCnchner=20Singles=20Team?= <team@muenchnersingles.de>, To: testadressex@example.com, MessageID: <01070185740a0962-192f9870-7f66-454b-b16d-8a324ede2d56-000000@eu-central-1.amazonses.com>, Subject: =?utf-8?Q?E-Mail-Adresse=20best=C3=A4tigen?=
Jan  2 20:51:33 server6 postfix/cleanup[1100185]: 8D7225C0276: milter-reject: END-OF-MESSAGE from b224-107.smtp-out.eu-central-1.amazonses.com[69.169.224.107]: 5.7.1 Your message was rejected because it appears to be spam; from=<01070185740a0962-192f9870-7f66-454b-b16d-8a324ede2d56-000000@eu-central-1.amazonses.com> to=<testadressex@example.com> proto=ESMTP helo=<b224-107.smtp-out.eu-central-1.amazonses.com>

Wie kommt den Liveconfig dazu, bei nicht eingeschalteten Spamfilter hier einfach Emails abzuweisen?

Spannend ist, dass das nur bei einer bestimmten Emailadresse auftritt, bei einer anderen Catchall-Adresse nicht.

Was nicht geholfen hat: Löschen der Catchall-Adresse und Neu-Anlegen

Edit: Gelöst durch Neustart des Postfix.

Danke und Gruß, Andre

Edit: Gelöst, siehe unten

Servus,

LiveConfig 2.15.0 auf Debian 11.6 folgendes Fehlverhalten:

Ich unchecke unter Email -> Adresse/Konto anklicken -> Spam-Filter "Greylisting" und speichere rechts unten, keine Änderungen in liveconfig.log, keine Deaktivierung des Greylistings.

Habe Liveconfig neu gestartet, anschließend das selbe Verhalten, allerdings dann wenigestens je Änderung an den Spamfilter-Einstellungen ein Eintrag im Log:

[2023/01/02 20:35:08.053370] [1094476|1094481] [LUA] Adding/updating user account testkonto1@example.com at dovecot config file: /etc/dovecot/passwd
[2023/01/02 20:35:15.873478] [1094476|1094482] [LUA] Adding/updating user account testkonto1@example.com at dovecot config file: /etc/dovecot/passwd
[2023/01/02 20:35:24.381951] [1094476|1094480] [LUA] Adding/updating user account testkonto2@example.com at dovecot config file: /etc/dovecot/passwd
[2023/01/02 20:35:29.814235] [1094476|1094481] [LUA] Adding/updating user account testkonto2@example.com at dovecot config file: /etc/dovecot/passwd

Weiß jemand,

• wie man Liveconfig dazu bekommt, die Änderungen am Spamfilter zu übernehmen?
  

  
  

Manuelles Durchstarten des Postfix half

Danke und Gruß, Andre

Zitat von Jim

Das Vergrößern des table_definition_cache hat tatsächlich geholfen. Der Fehler tritt nun nicht mehr auf und das Ändern des Passwortes einer Datenbank über Liveconfig funktioniert wieder einwandfrei.

Vielen Dank.

Das hat bei mir auch geholfen

Wie ist denn hier der aktuelle Stand?

Ich habe das Problem nach einem Dist-Upgrade von Debian9 auf Debian11 nun auch.

aus crypt ein crypt_md5 machen hat soweit geholfen, dass nach dem Neusetzen eines Passworts danach ein Login wieder möglich war.
Aber schön ist ja nicht.

Bei mir erkennt nach einem Dist-Upgrade von Debian9 auf 11 LC das FPM aus dem Debian Paket nicht.
Ich erhalte dann:

"[2022/03/20 23:29:56.038336] [115292|115296] [LUA] PHP version nil configured as FPM for subscription xxx but no PHP found for this version!
[2022/03/20 23:29:56.038571] [115292|115296] [LUA] PHP version nil configured as FPM for subscription xxx but no PHP-FPM found for this version!
"

Da ich noch mitten um Update bin, hab ich wenigen betroffenen Webs auf FCGI umgestellt.
Das Paket php7.4-fpm hatte ich aus dem Debian Repo installiert, den FPM gestartet, aber LC hat den FPM nicht erkannt, trotz Neustart. LUA-Dateien habe ich nicht angelegt.

Anton: Deinen letzten Beitrag verstehe ich so, dass LC dies einfach so hätte erkennen sollen? Falls ja: Was mache ich falsch?

nu gehts wieder

Was denn für ne Mailflut? Bei mir meldete nur Icinga:

APT WARNING: 0 packages available for upgrade (0 critical updates). warnings detected.

Danke

Wenn man dieses Verfahren anwendet, werden dann bestehende Domains verändert, oder wirkt es sich nur auf Neuanlagen / Änderungen aus?

Cool, auf das Feature freue ich mich ebenfalls

Ok, sehr spannend.

ich habe das das PHP von Debian wieder installiert und dann noch das Paket php-cgi installiert, nun ist der Fehler weg. Zuvor waren die PHP-Pakete von Debian deinstalliert, aber nicht purged

Servus, kennt jemand diesen Fehler und weiß Abhilfe?

[ERR] addPHP: missing parameter 'cgi' (FastCGI binary required!)
[ERR] selected PHP default version 'nil' not found! Using 'nil'...

Fällt mir auf, seit Wechsel von Debian 8 auf 9.
Der Fehler tritt auch dann auf, wenn nur PHP Opt Pakete installiert sind, die aus dem LC-Repo kommen.

20007# /usr/sbin/liveconfig --diag
Running OS diagnostics... (LiveConfig 2.9.1-release)
...
Running Lua diagnostics...
[INFO] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'
[INFO] Detected 'Debian GNU/Linux 9.11 (stretch)'
[ERR] addPHP: missing parameter 'cgi' (FastCGI binary required!)
[ERR] selected PHP default version 'nil' not found! Using 'nil'...
       Distribution name: 'Debian'
   Distribution codename: 'stretch'
     Distribution family: 'Debian'
    Distribution version: '9.11'
Distribution description: 'Debian GNU/Linux 9.11 (stretch)'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.25'
   Package version: '2.4.25-3+deb9u9'
   Modules: core so watchdog http log_config logio version unixd access_compat actions alias auth_basic authn_core authn_file authz_core authz_groupfile authz_host authz_user autoindex cgi cgid deflate dir env expires fcgid filter geoip headers http2 include info mime mpm_event negotiation proxy proxy_fcgi proxy_http reqtimeout rewrite setenvif socache_shmcb ssl status suexec
 - PHP 5.6.40 (code='php56')
   CGI/FastCGI: /opt/php-5.6/bin/php-cgi
   FPM: /opt/php-5.6/sbin/php-fpm
        pool config: /etc/php-fpm/php56-fpm.d
   default php.ini: '/opt/php-5.6/etc/php.ini'
 - PHP 7.0.33 (code='php70')
   CGI/FastCGI: /opt/php-7.0/bin/php-cgi
   FPM: /opt/php-7.0/sbin/php-fpm
        pool config: /etc/php-fpm/php70-fpm.d
   default php.ini: '/opt/php-7.0/etc/php.ini'
 - PHP 7.1.33 (code='php71')
   CGI/FastCGI: /opt/php-7.1/bin/php-cgi
   FPM: /opt/php-7.1/sbin/php-fpm
        pool config: /etc/php-fpm/php71-fpm.d
   default php.ini: '/opt/php-7.1/etc/php.ini'
 - PHP 7.2.26 (code='php72', eol='2020-11-30')
   CGI/FastCGI: /opt/php-7.2/bin/php-cgi
   FPM: /opt/php-7.2/sbin/php-fpm
        pool config: /etc/php-fpm/php72-fpm.d
   default php.ini: '/opt/php-7.2/etc/php.ini'
 - PHP 7.3.13 (code='php73', eol='2021-12-06')
   CGI/FastCGI: /opt/php-7.3/bin/php-cgi
   FPM: /opt/php-7.3/sbin/php-fpm
        pool config: /etc/php-fpm/php73-fpm.d
   default php.ini: '/opt/php-7.3/etc/php.ini'
 - PHP 7.4.1 (code='php74')
   CGI/FastCGI: /opt/php-7.4/bin/php-cgi
   FPM: /opt/php-7.4/sbin/php-fpm
        pool config: /etc/php-fpm/php74-fpm.d
   default php.ini: '/opt/php-7.4/etc/php.ini'
 - default PHP CLI: /usr/bin/php
...

Inhalt der Datei /usr/lib/liveconfig/lua/custom.lua:

postfix.NOUPDATE = true

Danke und Gruß, Andre

Ähm, "danke", ich werde an meinem Vorgehen auch bei weiteren Upgrades festhalten

Das Problem trat während eines Debian Upgrades auf, ich habe das dist-upgrade allerdings nicht komplett durchgeführt, sondern vorerst einzelne Dienste selektiv updated.

Als noch nicht alle Pakete updated warten und das Debian noch der Meinung war, auf Version 8 zu sein, trat der Fehler auf, auch bei diversen Neuerzeuge-Config-Versuchen.
Nachdem das System auf Debian 9 komplett hochgezogen war, hat LC beim nächsten erzeugen der Config den problematischen Parameter nicht mehr in die Config geschrieben.