Beiträge von monderka

    Bei mir kam die Meldung heute wieder auf centos 8.1 mit der heutigen SE


    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.



    |

    | 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!

    Ja, das war es. Danke.

    Ich habe in beiden Dateien die betreffende .domain.de Zeile entfernt und den qmail-send neu gestartet.


    Dieses Forum ist einfach immer wieder toll. Eines der wenigen die ich kenne das wirklich als Gemeinschaft funktioniert. Top!

    Hallo Zusammen,


    wir haben bei einem Kunden folgende Fall:

    Der Kunde hat die Domain domain.de bei uns und hat darauf im PD-Admin diverse E-Mailpostfächer postfach@domain.de.

    Nun benötigt der Kunde für eine andere Einheit eine Subdomain mit einem MX auf Microsoft365 quasi für einheit.domain.de der MX auf O365.


    Nun zum Problem. Aus dem PD-Admin soll dann von E-Mailadresse postfach35@domain.de auf info@einheit.domain.de weitergeleitet werden.

    Diese Weiterleitungen kommen aber dort nicht an und verlassen wohl auch den PD-Admin Server nicht.


    Ich hatte bereits versucht eine zusätzliche Subdomain im Kunden anzulegen und dort den MX abzuschalten, aber trotzdem werden die Mails für die Subdomain nicht nach extern gegeben.


    Gibt es dafür eine Idee wie das gemacht wird?


    viele Grüße

    Manfred

    Hallo,


    mehrfach ist mir nun beim Updaten auf aktuelle SE (6-0.365) und PD-Admin v4.66


    folgende Meldung im readproc aufgefallen. Was macht den test-Fehler?


    root@server05 / # ps ax | grep readproc

    475 ? S 0:02 readproctitle service errors: ...enabled. ELF support enabled. Mail files support enabled. OLE2 support enabled. PDF support enabled. SWF support enabled. HTML support enabled. XMLDOCS support enabled. HWP3 support enabled. Self checking every 600 seconds. ./run: 9: test: Illegal number: ./run: 10: test: Illegal number: ./run: 14: [: server05.onit4u.de: unexpected operator ./run: line 12: test: : integer expression expected

    4560 pts/0 S+ 0:00 grep readproc


    Ist das Problematisch und was kann das sein?


    viele Grüße

    Manfred

    Vieles ist hier schon zusammen getragen. Meine TOP3-wären:


    - Migration einzelner Kunden (inkl. Subdomains, E-Mailpostfächern, etc.) von einem Server zum anderen

    Gerade bei großen Kunden mit vielen E-mailpostfächer in IMAP-Nutzung ist eine Migration auf aktuellere Server echt schwer.


    - vollumfänglicher IPv6-Support


    - SSL per letsencrypt auch für alle Serverdienste (gerade jetzt wo es nur noch Zertifikate mit max. 13 monaten gibt kann man auch gleich das ganze viermal im Jahr aktualisieren und wenn das automatisiert wäre würde das arbeit ersparen. Certbot aber möglichst unabhängig und in PD-Admin integriert


    Aber alles was bereits geschrieben wurde ist ebenso wichtig und wünschenswert.

    Hallo Zusammen,


    weil ich im Forum nichts passendes gefunden habe wollte ich mal nachfragen ob es jemanden gibt der auf dem PD-Admin-Hostingplätzen schon mal Node.JS, React etc. installiert hat und weiß wie man da am besten vorgeht?


    Ich habe zwar das hier gefunden, aber bevor ich das ausprobieren wollte ich erstmal andere Meinungen hören.

    https://convertcaffeineintocod…node-js-on-shared-hosting


    Hat jemand Erfahrung damit und dem Hosting von derartigen Anforderungen mit dem pdadmin?


    viele Grüße und Danke schonmal vorab

    Manfred

    Ich war jetzt mal mutig...
    Das hier hat mir geholfen:
    https://www.linuxquestions.org…le-in-dovecot-4175616608/


    Der letzte Eintrag:
    I deleted the dovecot.index.cache file, and I watched the logs. The user was able to login without issue, and Dovecot created a new dovecot.index.cache file.


    Und genau so habe ich es gemacht. Im laufenden Betrieb die betroffenen dovecot.index.cache gelöscht.

    Und es wurde automatisch eine neue angelegt.
    Die ist jetzt auch normal klein, weil eh keine Mails drin liegen in dem Postfach:

    90964058 4 -rw------- 1 popuser popuser 1052 Aug 18 15:09 dovecot.index.cache


    Vielleicht wäre es mit den Limits auch gegangen, aber so scheint es jetzt behoben zu sein, was auch immer das ausgelöst hat.

    Hallo,


    wir haben massenhaft auf einem E-Mailpostfach folgende Meldung:


    Aug 18 08:44:55 server15 dovecot: pop3(service@domain.com): Error: mmap(size=295357744) failed with file /home/popuser/popboxen/domain.com/servicesa/Maildir/dovecot.index.cache: Cannot allocate memory


    In dem Verzeichnis schauen die Files so aus:

    Maildir # du -c -s *

    100 cur

    4 dovecot.index

    288660 dovecot.index.cache

    16 dovecot.index.log

    40 dovecot.index.log.2

    8 dovecot.index.thread

    4 dovecot.mailbox.log

    4 dovecot-uidlist

    4 dovecot-uidvalidity

    0 dovecot-uidvalidity.5b6d89b0

    4 maildirsize

    44 new

    4 subscriptions

    4 tmp

    288896 insgesamt


    Hat einer eine idee was man da macht und das abstellt?


    Manfred

    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?