Posts by Curio

    Hallo Leute,


    Ich habe heute meine i-MSCP-Installation von der Version 1.1.13 auf die 1.1.16 geupdatet. Das Update verlief völlig ohne Probleme.


    Nun zeigen sich bei allen E-Mail-Accounts allerdings SMTP-Probleme. Mails können nicht mehr versendet werden. Beim Mailempfang gibt es keine Probleme.
    Die Fehlermeldung im Mail-Client lautet:


    Die entsprechenden Einträge in der mail.log:

    Quote

    Nov 3 14:22:44 srv postfix/smtpd[32550]: NOQUEUE: reject: RCPT from ipb21a403e.dynamic.kabel-deutschland.de[x.x.x.x]: 554 5.7.1 <ipb21a403e.dynamic.kabel-deutschland.de[x.x.x.x]>: Client host rejected: Access denied; from=[email protected][/email] to=<[email protected]> proto=ESMTP helo=<Home-PC>


    Ich verwende Dovecot zur SASL Authentifizierung.
    Nach dem Update enthält die Postfix main.cf allerdings eine andere Konfigunration:

    Code
    1. smtpd_sasl_type = cyrussmtpd_sasl_path = smtpd


    Dies habe ich geändert in:

    Code
    1. smtpd_sasl_type = dovecot
    2. smtpd_sasl_path = private/auth


    Danach erhalte ich nun folgende Meldung vom E-Mail-Client:


    Und die Entsprechung in der Mail.log:

    Quote

    Nov 3 14:04:45 srv dovecot: imap([email protected]): Disconnected: Logged out in=781 out=4828
    Nov 3 14:05:47 srv postfix/smtpd[31020]: connect from smtprelay.dred.com[78.136.20.157]
    Nov 3 14:05:47 srv postfix/smtpd[31020]: warning: SASL: Connect to private/auth failed: Connection refused
    Nov 3 14:05:47 srv postfix/smtpd[31020]: fatal: no SASL authentication mechanisms
    Nov 3 14:05:48 srv postfix/master[26776]: warning: process /usr/lib/postfix/smtpd pid 31020 exit status 1
    Nov 3 14:05:48 srv postfix/master[26776]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling


    Hat sich etwas in der Postfix-Konfiguration bzw. in der von Dovecot geändert, dass die SASL-Authentifizierung über Dovecot nicht mehr funktioniert?


    MfG, Curio

    Nein, keine Rede von Webmail. Wobei dies auch von dem Problem betroffen ist bei der unter Punkt 2 erwähnten Domain/E-Mail-Adresse.
    Wenn ich die Notiz richtig interpretiere, versucht ein php-Programm mit plaintext-Auth auf den Mailserver zuzugreifen. Oder?
    Ich habe allerdings keinen Plan, um was für ein Programm es sich dabei handeln könnte. Ich schließe mal ganz kühn externe php-Programme aus, da all meine User nur über die üblichen Mailclients und per SSL bzw. TLS auf den Mailserver zugreifen und diese Zugriffe im mail.log auch keine Probleme anzeigen.

    Hallo Leute,


    Ich habe seit ca. 2 Wochen ein E-Mail Problem. Dies äußert sich folgendermaßen:

    • Im i-MSCP Admin Panel öffnet sich der "E-Mail"-Reiter einer Domain stark verzögert. Unter den aufgelisteten E-Mail-Konten erscheint folgende Notiz:

      Quote

      Notice: Unknown: SECURITY PROBLEM: insecure server advertised auth=plain (errflg=1) in Unknown on line 0


      Diese Notiz erscheint auf allen E-Mail-Reitern sämtlicher Domains.

    • Eine E-Mail-Adresse dieser Domain hat mindestens 3 mal pro Woche das Problem, dass der Outlook-Client jedesmal aufs Neue das Passwort anfordert. Ich muss es dann im i-MSCP Admin Panel neu eingeben, dann läuft es eine Weile weiter problemlos.
    • In /var/log/mail.logs kann ich keine Fehlermeldungen entdecken.

    Ich kann mit der Meldung nichts anfangen. Kann jemand dieses Problem nachvollziehen?
    Mein System: Rootserver, Webserver Apache2 itk, Debian 7.3, i-MSCP 1.1.0, mit Postfix und Dovecot (Standardkonfiguration nicht geändert)
    Wäre nett, wenn mir jemand etwas auf die Sprünge helfen könnte.


    Gruß, Curio

    Ich habe die Anmerkungen zu den Änderungen im Email-Quota-Management gelesen.
    Bin allerdings davon ausgegangen, dass das Upgradescript alles entsprechend einrichtet.


    mrpink:

    Quote

    Probier mal folgendes aus und teste ob dann wieder alles funktioniert.
    Code:
    /var/www/imscp/engine/setup/imscp-setup -r po


    Vielen Dank für die kompetente Hilfe. Dein Vorschlag hat prima funktioniert.
    Was bedeutet die Reconfigure-Option "po"?
    Ich hatte den Inhalt meiner alten dovecot.conf in die neue übertragen. Natürlich hatte ich dann Probleme.


    Gruß, Curio

    Hallo Leute,


    Ich habe gestern mein i-MSCP über Git-Master auf die neueste Version upgedatet.
    Danach beschwerten sich meine Kunden, dass sie nur Emails versenden aber nicht empfangen können.


    Im Mail.log zeigte sich, dass Dovecot Probleme macht:

    Code
    1. Nov 12 02:28:10 srv dovecot: dict: Error: Can't open configuration file /etc/dovecot/dovecot-dict-sql.conf: No such file or directory
    2. Nov 12 02:28:10 srv dovecot: dict: Error: Failed to initialize dictionary 'quotadict'
    3. Nov 12 02:28:10 srv dovecot: lda([email protected]): Error: read(/var/run/dovecot/dict) failed: Remote disconnected
    4. Nov 12 02:28:10 srv dovecot: lda([email protected]): Error: Internal quota calculation error
    5. Nov 12 02:28:10 srv dovecot: lda([email protected]): msgid=<020d01cedf41$454d1170$cfe73450$@[email protected]>: save failed to INBOX: Internal error occurred. Refer to server log for more information. [2013-11-12 02:28:10]
    6. Nov 12 02:28:10 srv postfix/pipe[27430]: ABA322B4180: to=<[email protected]>, relay=dovecot, delay=2223, delays=2222/0.01/0/0.15, dsn=4.3.0, status=deferred (temporary failure)


    Es scheint die Datei "/etc/dovecot/dovecot-dict-sql.conf" zu fehlen.


    Während des Updates ist kein Fehler aufgetreten. Ist das ein Bug oder habe ich eventuell etwas nicht beachtet?
    Oder hat sich etwas an der Dovecot-Konfiguration geänder?


    Gruß, Curio

    TheCry
    Noch mal vielen Dank für die kompetente und sofortige Teamviewer-Hilfe. Das nenn ich Service! :)
    Da die Suche nach der Ursache des Bind9 Problems beim Update nicht nachvollzogen werden konnte, war die beste Lösung eine Rekonfiguration über:

    Code
    1. # cd /usr/local/src/i-mscp# perl imscp-autoinstall -dr


    Damit konnte der Fehler korrigiert werden.


    Das Problem mit der SSL-Konfiguration während der Installation oder des Updates besteht eigentlich nur darin, dass man seine SSL-Zertifikatsdateien schon vorher auf dem Server liegen haben sollte, und dass man genau weiß, welche Datei davon den Privatkey enthält, welche das intermediate Zertifikat enthält und welche die eigentliche Zertifikatsdatei darstellt.


    Nuxwin
    Thanks for the hints with:

    Code
    1. # perl imscp-autoinstall -r help
    2. oder
    3. # perl imscp-setup -r help


    It is good to know how to get quick help when one is somewhat unclear during Installation.


    Gruß, Curio

    Hallo Leute,


    Ich versuche gerade ein i-MSCP-Update auf die aktuellste Git-Hub Version.

    Code
    1. # git clone git://github.com/i-MSCP/imscp.git i-mscp# cd /usr/local/src/i-mscp# perl imscp-autoinstall


    Leider stoppt das Update mit folgender Fehlermeldung:

    Code
    1. iMSCP::File::get: Unable to open /etc/imscp/bind/parts/cfg_entry_.tpl
    2. Servers::named::bind::addDmnConfig: A template has not been found
    3. iMSCP::Debug::END: Exit code is 1!


    Einzige Besonderheit bei mir: Hatte Bind 9 mittels "insserv -r bind9" deaktiviert. Dies hatte bei ähnlichen Updates von i-MSCP allerdings nicht zu Fehlermeldungen geführt. Ich musste lediglich Bind9 jedes mal aufs neue deaktivieren.


    Kennt jemand dieses Problem und könnte mir weiterhelfen? Leider hänge ich jetzt mit einem nicht funktionierenden i-MSCP da. Ein Reaktivieren des alten i-mscp-Ordners unter /usr/local/src/ aktiviert nicht, wie ich erwartet hatte, die alte i-MSCP-Version. Das Admin-Panel bleibt weiter unerreichbar.


    Meine Serverdaten:
    Hetzner Rootserver, Debian Wheezy, letze Github-Version von i-MSCP


    Gruß, Curio

    biologist
    Danke für die Aufklärung über Zonentransfer zwischen Master- und Slave-DNS-Server. Die Fehler sind damit gut erklärt.


    Nun aber noch mal zu Bind9. Da ich ein externe Domainverwaltung mit den dortigen Nameservern nutze, brauche ich keinen eigenen DNS-Server.


    Da ich es auf meinem System leider nicht testen kann, würde ich gerne von Leuten wissen, die es schon mal versucht haben: "Kann man bind9 problemlos per aptitude purge bind9 deinstallieren ohne dass es irgendwelche Probleme mit i-MSCP gibt?"


    Die Lösung von biologist kann ich nicht nachvollziehen. Ich habe es vorerst so gelöst, dass ich den Bind9-Dienst gestoppt habe und die Symlinks aus den Runleveln auf das Bind9-Start-Stop-Script gelöscht habe.

    Quote

    insserv -r bind9


    Bin jetzt nicht sicher, ob diese Methode das nächste große Update von i-MSCP überlebt. Aber ich kann damit problemlos Reboots durchführen ohne dass Bind9 wieder gestartet wird.


    Insgesamt wäre mir allerdings eine Lösung mit kompletter Bind9-Deinstallation lieber als so eine deaktivierte Leiche im Keller. Was steht also einer solchen radikalen Lösung konkret im Wege?


    Gruß, Curio