Beiträge von monderka

    Hallo Zusammen,


    erstmal Danke für euren Input. Das hat mich auf die Lösung gebracht...

    Das cacert war tatsächlich schuld. Wir hatten das teilweise bereits im Mai getauscht, aber natürlich nicht an die Mailserver gedacht.


    TOLL! DANKE.

    Manfred

    Danke euch schon mal.

    Also das mit den anderen Ports und der IP anstatt localhost hatte ich schon probiert.

    Seltsam ist das es gar keinen Fehler gibt, und das erst seit 29.5.2020 gegen 20 uhr. Es wurde aber gar kein PD-Admin Update gemacht, lediglich auf stunnel umgestellt. Auch der fail2ban kann nicht schuld sein, den hatte ich schon komplett gestoppt und per iptables alles geleert.


    Der Versand per "mail" oder "sendmail" Einstellung geht, aber der Kunde bekommt im o365 umlaute-zerschossene bestellungen was auch nicht toll ist. Deshalb hatten wir letztes Jahr auf SMTP umgestellt und da hat bis dahin tadellos funktioniert.


    Das ist die Meldung die im error_log von gambio dazu steht. Im mail.log auf dem Pdadmin-Server gibt es gar keinen hinweis das überhaupt eine smtp-verbindung probiert wird.



    Request: POST /admin/gm_send_order.php?oID=753&type=send_order

    - duration: ~1227ms

    - server: Apache

    - server address: 88.198.xxx.xxx

    - user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61


    Fatal error: Uncaught RuntimeException: The mail could not be sent, check the debug logs for more information. in /home/hirsedby/www.hirse-paradies.de/admin/gm_send_order.php:323

    Stack trace:

    #0 {main}

    thrown in /home/hirsedby/www.hirse-paradies.de/admin/gm_send_order.php on line 323


    Echt seltsam.


    Hallo,

    wir haben seit kurzem das Problem das aus dem Gambio-Webshop mit der Einstellung für Mailversand per SMTP keine Verbindung mehr funktioniert. Aus dem Outlook von irgend einem PC schon.


    Jetzt stellt sich mir die Frage was das sein kann. Bisher war der Host eben localhost und ganz normal Port 587 und Login mit e-mail und Passwort.


    Hat da jemand eine Idee wo man ansetzen kann zu suchen? Evtl. der qmail-patch oder irgendwas.


    Bin etwas ratlos warum das von jetzt auf gleich nicht mehr geht.


    Manfred

    Ich hatte diese Meldung auch bei Notfall-SE-Update wegen dem Qmail-Leck.


    Jedoch auf dem neu installierten Debian9 hatte ich das nicht.

    |

    | ROUNDCUBEMAIL wird upgegradet.

    |

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    What version are you upgrading from? Type '?' if you don't know.

    Executing database schema update.

    This instance of Roundcube is up-to-date.

    Have fun!

    mysql: [Warning] Using a password on the command line interface can be insecure.

    Ticket_2019102267002761 returned true

    |

    | phpMyAdmin < 4.8.4 and phpPgAdmin no longer available, use $hostname/adminer

    |




    Jedoch auf dem eigentlich identischen Centos8.1 kam der Hinweis:

    |

    | ROUNDCUBEMAIL wird upgegradet.

    |

    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    What version are you upgrading from? Type '?' if you don't know.

    WARNING: Mimetype to file extension mapping doesn't work properly!

    Please check the 'mime_types' config option and run this script again.

    Executing database schema update.

    This instance of Roundcube is up-to-date.

    Have fun!

    mysql: [Warning] Using a password on the command line interface can be insecure.

    Ticket_2019102267002761 returned true

    |

    | phpMyAdmin < 4.8.4 and phpPgAdmin no longer available, use $hostname/adminer

    |

    Bei Debian ist das auch so, aber mit dem mta-dummy ist das dann erledigt, auch wird der exim bei jeden apt-get update nicht wieder installiert. Vermutlich braucht der fail2ban eine Mailfunktion um in bestimmten Konfigurationen direkt über Sperrungen zu informieren.

    Gestern habe ich mit yum -y update das centos8 geupdated.

    Dabei hat er irgendwie wieder exim4 aktualisiert.


    Bei Debian gibt es diesen workaround:

    dpkg -i --force-all /usr/local/pd-admin2/SPECIAL/mta-dummy_1.0_all.deb; aptitude purge $(dpkg -l exim4* |grep ^ii |awk '{print $2}' |tr '\n' ' ')


    Gibt es sowas auch für Centos um exim4 weg zu bringen? Den ein Remove würde ja auch fail2ban etc. deinstallieren.


    yum remove exim

    Dependencies resolved.

    ================================================================================

    Package Arch Version Repository Size

    ================================================================================

    Removing:

    exim x86_64 4.93-2.el8 @epel 4.6 M

    Removing dependent packages:

    fail2ban noarch 0.11.1-6.el8 @epel 0

    Removing unused dependencies:

    checkpolicy x86_64 2.9-1.el8 @BaseOS 1.7 M

    fail2ban-firewalld noarch 0.11.1-6.el8 @epel 366

    fail2ban-selinux noarch 0.11.1-6.el8 @epel 31 k

    fail2ban-sendmail noarch 0.11.1-6.el8 @epel 12 k

    fail2ban-server noarch 0.11.1-6.el8 @epel 1.3 M

    libbsd x86_64 0.9.1-4.el8 @epel 336 k

    libopendmarc x86_64 1.3.2-1.el8 @epel 72 k

    libspf2 x86_64 1.2.10-24.20150405gitd57d79fd.el8

    @epel 210 k

    perl-Carp noarch 1.42-396.el8 @BaseOS 41 k

    perl-Data-Dumper x86_64 2.167-399.el8 @BaseOS 104 k



    Den seit dem centos-Update kommen die Backup-Mails nicht mehr.


    update:

    hier ist das schonmal diskutiert: Probleme mit Alternative MTA

    Muss ich die sendmail symlinks nach jedem yum-update neu setzen?

    Im November letzten Jahres hatte ich wegen einer my.cnf Optimierung schon mal einen Post geöffnet.

    Performance mySQL 5.7 in SE Reihe6


    Aber da bin ich nicht weiter gekommen. Der vadmin-Timeout kommt auch mit der dort von mir verwendeten Einstellung.


    Der mysqltuner.pl liefert auf einem neu installierten PD-Admin auf centos81 folgende Empfehlungen:

    -------- Recommendations ---------------------------------------------------------------------------

    General recommendations:

    Control warning line(s) into /usr/local/pd-admin2/var/mysql/server10.err file

    Control error line(s) into /usr/local/pd-admin2/var/mysql/server10.err file

    When making adjustments, make tmp_table_size/max_heap_table_size equal

    Reduce your SELECT DISTINCT queries which have no LIMIT clause

    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU

    Variables to adjust:

    query_cache_size (=0)

    query_cache_type (=0)

    query_cache_limit (> 1M, or use smaller result sets)

    tmp_table_size (> 16M)

    max_heap_table_size (> 16M)

    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

    Das ist jetzt etwas offtopic, aber passt gerade in den thread. Wie nutzt du mysqltuner.pl?
    Ich bekomme immer folgendes:


    perl mysqltuner.pl --user root --pass xxxxxx --mysqladmin /usr/local/pd-admin2/bin/mysqladmin

    >> MySQLTuner 1.7.19 - Major Hayden <major@mhtx.net>

    >> Bug reports, feature requests, and downloads at http://mysqltuner.com/

    >> Run with '--help' for additional options and output filtering


    [--] Skipped version check for MySQLTuner script

    [!!] Couldn't find mysqladmin in your $PATH. Is MySQL installed?

    Da bin ich bei Sumeragi. ich glaube das sind zwei verschiedene Probleme, die in extra Posts abgewickelt werden sollten.

    Mit der administrator.cgi habe ich nur unter Debian10 probleme und das verwende ich aktuell gar nicht mehr sondern nur noch Debian9 und werde dann auf ab centOS81 wechseln. Mir ist das zu unsicher geworden ein Glückspiel zu haben ob aktuelles Debian geht oder nicht oder warum.


    Aber das mit dem Timeout beim User-Anlegen kann ich auf keiner meiner Maschinen (bis einschl. Debian9.12) nachstellen. Hierzu wären die Fehlerparameter in einem neue Post wieder interessante PD-Admin-Version, SE-Version, OS-Version

    Aha. Sind denn die Probleme aus dem "Test Version"-Post irgendwie schon bearbeitet? Also ich würde da ungern die Live-Systeme die diese MySQL-Fehler werfen ohne die Nebenwirkungen zu kennen umstellen. Aber der mysql-fehler tritt bei uns sehr sehr häufig auf. Auch auf dem nagelneu installierten centos81-System

    Sorry, aber dann verstehe ich nicht was uns Herr Bradler da nun sagen will? Von was die 64-bit version und woher nimmt man die dann? Entweder stehe ich total auf dem Schlauch oder ich raff es einfach nicht.

    Danke Eisenherz. diese Meldung tritt bei uns auch massenhaft auf.

    Dabei ist der Server bereits von Reihe6. Was meinen sie herr Bradler mit 64bit einsetzen? Unser System ist ein Debian 9 mit 64 bit und wir nutzen die PD-Admin-Installation ganz normal in Reihe 6.

    Auf dem Debian9.12 neu installiert:

    locale

    LANG=de_DE.UTF-8

    LANGUAGE=

    LC_CTYPE="de_DE.UTF-8"

    LC_NUMERIC="de_DE.UTF-8"

    LC_TIME="de_DE.UTF-8"

    LC_COLLATE="de_DE.UTF-8"

    LC_MONETARY="de_DE.UTF-8"

    LC_MESSAGES="de_DE.UTF-8"

    LC_PAPER="de_DE.UTF-8"

    LC_NAME="de_DE.UTF-8"

    LC_ADDRESS="de_DE.UTF-8"

    LC_TELEPHONE="de_DE.UTF-8"

    LC_MEASUREMENT="de_DE.UTF-8"

    LC_IDENTIFICATION="de_DE.UTF-8"

    LC_ALL=



    Auf dem centos81 ebenfalls komplett neu installert:

    locale

    LANG=en_US.UTF-8

    LC_CTYPE="en_US.UTF-8"

    LC_NUMERIC="en_US.UTF-8"

    LC_TIME="en_US.UTF-8"

    LC_COLLATE="en_US.UTF-8"

    LC_MONETARY="en_US.UTF-8"

    LC_MESSAGES="en_US.UTF-8"

    LC_PAPER="en_US.UTF-8"

    LC_NAME="en_US.UTF-8"

    LC_ADDRESS="en_US.UTF-8"

    LC_TELEPHONE="en_US.UTF-8"

    LC_MEASUREMENT="en_US.UTF-8"

    LC_IDENTIFICATION="en_US.UTF-8"

    LC_ALL=



    beides wirft den Fehler. Normalerweise bearbeite ich die Texte bei laufenden Systemen auch nicht mehr. Aber gerade bei einer Neuinstallation muss ich es ja bearbeiten. Und da fällt es nun bei beiden Systemen auf. Hier wird wohl nur Herr Bradler helfen können der die Geheimnisse der administrator.cgi kennt.

    Ist bei Mir auf CentOS81 und auf Debian 9.12 aufgetreten.

    Beides komplett neu installierte Systeme von gestern und heute (KW18/2020)


    Auf dem centos ist installiert:
    Package openssl-1:1.1.1c-2.el8_1.1.x86_64 is already installed.

    Package gnutls-utils-3.6.8-8.el8.x86_64 is already installed.


    ich habe folgendes in dieser Datei geändert, auf beiden Systemen Debian 9.12 und centOS81
    /usr/local/pd-admin2/share/mkdhparams


    != anstatt =


    BITS="$DH_BITS"

    if test "gnutls" != "openssl"

    then