AD Benutzer werden nicht Synchronisiert / Übertragen

Grandjean · October 7, 2016, 1:59pm

Hallo,

das scheint offenbar doch öfter aufzutreten: [bug]38285[/bug]

Wichtig wäre: Ist der AD DC über hosts/static/ gesetzt? Das sollte man wie folgt herausfinden können:

ucr search --brief hosts/static/

Wenn da der AD DC nicht zu finden ist, dann bitte einmal nach folgendem Muster setzen:

ucr set hosts/static/<IP-des-AD-DC>=<FQDN-des-AD-DC>

Ein Beispiel:

ucr set hosts/static/192.168.1.10='WINDC.ad.example.org'

Zudem würde ich sicherheitshalber bind9 und nscd einmal neustarten, dann eine Änderung im AD triggern und das Log nochmal anschauen.

Schönen Gruß,
Michael Grandjean

matt · October 8, 2016, 6:44pm

Hallo,

super, über den

ucr set hosts/static/<IP-des-AD-DC>=<FQDN-des-AD-DC>

hat es nun geklappt, die User vom AD Synchronisieren wieder. Der Eintrag war bei mir leer … Das Log sieht gut aus.

Allerdings scheint der Eintrag nun auswirkungen auf Zarafa genommen zu haben. Ich kann nun via Fetchmail keine Mails mehr empfangen und der Absender erhält eine undelivery Mail.
Aus dem mail.log lässt sich leider nichts erkennen…

Eine Idee was der Eintrag zur Folge haben könnte?

Grüße
Matt

matt · October 8, 2016, 7:20pm

Hier mal ein Auschnitt aus dem mail.log

Oct 8 20:44:48 mailsrv fetchmail[7477]: 347 messages (346 seen) for vorname.nachname@domain.de at pop.1und1.de (381262097 octets). Oct 8 20:44:48 mailsrv postfix/smtpd[8293]: connect from localhost[127.0.0.1] Oct 8 20:44:48 mailsrv postfix/smtpd[8293]: B170B80636: client=localhost[127.0.0.1] Oct 8 20:44:48 mailsrv postfix/cleanup[8296]: B170B80636: message-id=<74d1mnqn0si56rgmm7pilj1i.1475952157742@email.android.com> Oct 8 20:44:48 mailsrv fetchmail[7477]: reading message vorname.nachname@domain.de@pop.1und1.de:347 of 347 (8595 octets) not flushed Oct 8 20:44:48 mailsrv postfix/qmgr[5795]: B170B80636: from=<matt@gmx.de>, size=8939, nrcpt=1 (queue active) Oct 8 20:44:48 mailsrv postfix/smtpd[8293]: disconnect from localhost[127.0.0.1] Oct 8 20:44:49 mailsrv postfix/smtpd[8300]: connect from localhost[127.0.0.1] Oct 8 20:44:49 mailsrv postfix/smtpd[8300]: 3EEAF80A11: client=localhost[127.0.0.1], orig_queue_id=B170B80636, orig_client=localhost[127.0.0.1] Oct 8 20:44:49 mailsrv postfix/cleanup[8296]: 3EEAF80A11: message-id=<74d1mnqn0si56rgmm7pilj1i.1475952157742@email.android.com> Oct 8 20:44:49 mailsrv postfix/qmgr[5795]: 3EEAF80A11: from=<matt@gmx.de>, size=9677, nrcpt=1 (queue active) Oct 8 20:44:49 mailsrv postfix/smtpd[8300]: disconnect from localhost[127.0.0.1] Oct 8 20:44:49 mailsrv amavis[5141]: (05141-06) Passed CLEAN {RelayedInternal}, LOCAL [127.0.0.1]:35611 [82.212.32.149] <matt@gmx.de> -> < vorname.nachname@domain.de>, Queue-ID: B170B80636, Message-ID: <74d1mnqn0si56rgmm7pilj1i.1475952157742@email.android.com>, mail_id: 7H2yNem_2noL, Hits: 2.195, size: 8939, queued_as: 3EEAF80A11, 506 ms Oct 8 20:44:49 mailsrv postfix/smtp[8297]: B170B80636: to=<vorname.nachname@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.63, delays=0.12/0/0/0.51, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 3EEAF80A11) Oct 8 20:44:49 mailsrv postfix/qmgr[5795]: B170B80636: removed Oct 8 20:44:49 mailsrv postfix/smtp[8301]: 3EEAF80A11: to=< vorname.nachname@domain.de>, relay=smtp.1und1.de[212.227.15.183]:587, delay=0.42, delays=0.09/0/0.21/0.12, dsn=5.0.0, status=bounced (host smtp.1und1.de[212.227.15.183] said: 554-Transaction failed 554 Mail loop suspected. (in reply to end of DATA command)) Oct 8 20:44:49 mailsrv postfix/cleanup[8296]: B0CA580A3D: message-id=<20161008184449.B0CA580A3D@mailsrv.domain.de> Oct 8 20:44:49 mailsrv postfix/qmgr[5795]: B0CA580A3D: from=<>, size=11725, nrcpt=1 (queue active) Oct 8 20:44:49 mailsrv postfix/bounce[8410]: 3EEAF80A11: sender non-delivery notification: B0CA580A3D Oct 8 20:44:49 mailsrv postfix/qmgr[5795]: 3EEAF80A11: removed Oct 8 20:44:50 mailsrv postfix/smtp[8301]: B0CA580A3D: to=<matt@gmx.de>, relay=smtp.1und1.de[212.227.15.167]:587, delay=0.43, delays=0.08/0/0.24/0.11, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=0Mgrgq-1bWzwh2xd2-00M3hj) Oct 8 20:44:50 mailsrv postfix/qmgr[5795]: B0CA580A3D: removed

Die Mails sollten normalerweise via Fetchmail abgeholt und dann in die jweiligen Postfächer verschoben werden. Verschickt wird via Smarthost (relay) von 1und1.de

Das verschicken von Mails funktoniert weiterhin einwandfrei. Nur das Empfangen klappt nicht…

Danke vorab für eure Hilfe.

Grüße

ahrnke · October 10, 2016, 7:19am

Hallo,

das Log zeigt nicht mal ansatzweise den Versuch, an Zarafa zuzustellen. Statt dessen geht es sofort zurück zum Provider und bounced, weil die mit Recht einen Loop sehen.

Entweder die Mailboxen haben nicht die erwarteten Adressen (mit zarafa-stats oder zarafa-admin prüfen) oder eine Konfigurationsdatei ist nicht korrekt.
Im letzteren Fall sollte man über ein pauschales “ucr commit” nachdenken. Damit werden alle von UCS verwalteten Konfigurationsdateien aus den Templates und den UCR-Variablen neu generiert. Lokale Änderungen werden überschrieben.

Weitere Testmöglichkeiten: Mails zwischen den lokalen Mailboxen schicken.
Weitere Logs: /var/log/zarafa , insbesondere dagent.log

Viele Grüße,
Dirk Ahrnke

matt · October 10, 2016, 7:58am

Hallo Ahrnke,

vielen Dank für deinen Beitrag. Inzwischen glaube ich, dass der Fehler in Zarafa durch das Update kommt, nicht durch die hosts/static

Wie ich das sehe, hat sich nach dem Update etwas verändert. Wie es aussieht, versucht Postfix mails nach 127.0.0.1:10024 zuzustellen.
Hat vielleicht was mit dem Virenscanner zu tun?

Viele Grüße

Matt

ahrnke · October 10, 2016, 8:37am

Hallo,

[quote=“matt”]Wie es aussieht, versucht Postfix mails nach 127.0.0.1:10024 zuzustellen.
Hat vielleicht was mit dem Virenscanner zu tun?[/quote]

Ja, dort lauscht der Amavis. Den könnte man auch etwas gesprächiger machen.

mail/antivir/amavis/debug/level: <empty> Log level for amavisd-new. Possible values are 0 to 5. If the variable is unset, the default value 0 is used.

Viele Grüße,
Dirk Ahrnke

Grandjean · October 10, 2016, 8:44am

Hallo,

ja, das scheint mir auch wahrscheinlicher. Das einzige was der Befehl “ucr set hosts/static/=” macht, ist eine Zeile in /etc/hosts hinzuzufügen mit genau dem Inhalt ( )

Schönen Gruß,
Michael Grandjean

matt · October 10, 2016, 8:55am

Hallo,

habe das Loglevel erhöht, allerdings wird kein Log geschrieben.

Wie kann ich den Amavis deaktivieren, deinstallieren?

In der Postfix Main sitzt ein Content-Filter Eintrag. Wenn ich den Dienst-Amavis stoppe und diesen Eintrag auskommentiere - kommen dennoch keine Mails an.
Es sieht aus wie ein Loop, Mails werden direkt wieder an das 1und1 relay geschickt und von Fetchmail abgeholt.

Viele Grüße
Matt

ahrnke · October 10, 2016, 9:25am

Bei aktiviertem Debug-Log (>0) schreibt Amavis nach einen Neustart in /var/log/mail.log.

Mit dem manuellen Editieren von Konfigurationsdateien sollte man unter UCS vorsichtig sein.

[code]root@d:/etc/postfix# cat master.cf

Warning: This file is auto-generated and might be overwritten by

univention-config-registry.

Please edit the following file(s) instead:

Warnung: Diese Datei wurde automatisch generiert und kann durch

univention-config-registry überschrieben werden.

Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):

/etc/univention/templates/files/etc/postfix/master.cf.d/10_services

/etc/univention/templates/files/etc/postfix/master.cf.d/30_antivir

/etc/univention/templates/files/etc/postfix/master.cf.d/70_policy

[/code]

Wenn man in 30_antivir nachschaut, findet man die passende UCR-Variable.

mail/antivir: yes If this option is activated, e-mails are scanned for malware/viruses using the scanner ClamAV. If the variable is unset, no scan is performed.

Rein gefühlsmässig denke ich aber nicht, das der Amavis das Problem ist.

matt · October 10, 2016, 9:40am

Nachdem Antivir nun deaktiviert ist gibt es in der mail.log keine Meldung mehr über Amavis.

Irgendwie sieht es so aus, als fühlt sich der Mailserver nicht für die Domain zuständig. Die Domäne ist aber in /mail/domain definitiv korrekt gesetzt.
Postfix sendet die Mails dann wieder via Relay-Host an 1&1 und Fetchmail ruft diese wieder ab -> dadurch entsteht der Loop. De Mails werden auch im Postfach von 1&1 dupliziert.

Jemand eine Idee?

Viele Grüße
Matt

ahrnke · October 10, 2016, 10:04am

Die lokale Domain ist nur ein Teil der für die Mailzustellung verantwortlichen Komponenten.
In /etc/postfix liegen noch ein paar ldap-Maps. Wie der Name sagt, sollen die im LDAP nachsehen ob eine Adresse existiert und wo die Mail ggf. hingehen soll.

Haben Sie denn schon den heute morgen empfohlenen “ucr commit” gemacht?

matt · October 10, 2016, 10:46am

Hallo Ahrnke,

ucr commit habe ich durchgeführt und anschließend das gesamte System neugestartet.

Mails gehen nach wie vor sauber raus. Aber eingehend immer noch die gleichen Probleme.

Gibt es eine Möglichkeit, eine rekonfig für Postfix durchzuführen?

EDIT: Es scheint definitiv etwas mit Postfix nicht zu passen. Selbst wenn ich mir selbst eine Mail schreibe (zarafauser1 zu zarafauser1), wird die Mail nach außen -> also zum Smartrelay transportiert…

SirTux · October 10, 2016, 11:40am

Wurden Templates verändert? Bitte ausführen und Ausgabe posten:

univention-check-templates

ahrnke · October 10, 2016, 12:40pm

Mich beschleicht der Verdacht, dass Update Zarafa Collaboration Platform nicht möglich mit dem Mailzustellungsproblem zusammenhängt.
Bei Dovecot wird “mail/postfix/virtual/transport” auf “lmtp:unix:private/dovecot-lmtp” gesetzt.
Bei Zarafa lauscht der dagent auf Port 2003. Dazu muß die o.g. Variable nicht gesetzt sein (ucr unset …)

[code]# grep 2003 main.cf
virtual_transport = lmtp:127.0.0.1:2003

netstat -tpln | grep 2003

tcp 0 0 127.0.0.1:2003 0.0.0.0:* LISTEN 4709/zarafa-dagent
[/code]

matt · October 10, 2016, 1:24pm

univention-check-templates

[code]WARNING: The following UCR templates are modified locally.
Updated versions will be named FILENAME.dpkg-*.
The files should be checked for differences.

/etc/univention/templates/files/etc/default/dovecot
/etc/univention/templates/files/etc/dovecot/conf.d/10-auth.conf
/etc/univention/templates/files/etc/dovecot/conf.d/10-logging.conf
/etc/univention/templates/files/etc/dovecot/conf.d/10-mail.conf
/etc/univention/templates/files/etc/dovecot/conf.d/10-master.conf
/etc/univention/templates/files/etc/dovecot/conf.d/10-ssl.conf
/etc/univention/templates/files/etc/dovecot/conf.d/15-lda.conf
/etc/univention/templates/files/etc/dovecot/conf.d/15-mailboxes.conf
/etc/univention/templates/files/etc/dovecot/conf.d/20-imap.conf
/etc/univention/templates/files/etc/dovecot/conf.d/20-lmtp.conf
/etc/univention/templates/files/etc/dovecot/conf.d/20-managesieve.conf
/etc/univention/templates/files/etc/dovecot/conf.d/20-pop3.conf
/etc/univention/templates/files/etc/dovecot/conf.d/90-acl.conf
/etc/univention/templates/files/etc/dovecot/conf.d/90-quota.conf
/etc/univention/templates/files/etc/dovecot/conf.d/90-sieve.conf
/etc/univention/templates/files/etc/dovecot/conf.d/95-quota-status.conf
/etc/univention/templates/files/etc/dovecot/conf.d/auth-ldap.conf.ext
/etc/univention/templates/files/etc/dovecot/conf.d/auth-master.conf.ext
/etc/univention/templates/files/etc/dovecot/conf.d/auth-system.conf.ext
/etc/univention/templates/files/etc/dovecot/dovecot-ldap.conf.ext
/etc/univention/templates/files/etc/dovecot/dovecot.conf
/etc/univention/templates/files/etc/init.d/dovecot
/etc/univention/templates/files/etc/logrotate.d/dovecot
/etc/univention/templates/files/etc/pam.d/dovecot
/etc/univention/templates/files/etc/rsyslog.d/dovecot.conf
/etc/univention/templates/files/usr/share/dovecot/protocols.d/imapd.protocol
/etc/univention/templates/files/usr/share/dovecot/protocols.d/pop3d.protocol
/etc/univention/templates/files/var/lib/dovecot/sieve/default.sieve
[/code]

ClamAV gibt an, das die Logs nicht mehr verfügbar sind. Können die Logs neu angelegt werden - sollte ich versehentlich den ClamAV Log Ordner gelöscht haben?.. peinlich
Hat aber zunächst nichts mit dem Problem zu tun…

ahrnke · October 10, 2016, 1:41pm

Der Verdacht erhärtet sich (siehe letzter Post).
Das Paket “univention-mail-dovecot” wurde nicht oder nicht komplett entfernt. Jedenfalls müssen die Dovecot-Templates für ein funktionierendes Zarafa weg.

matt · October 10, 2016, 2:00pm

Hallo Ahrnke,

wie entferne ich die Pakete am besten? Über die WebGui alle Dovecot Pakete suchen und entfernen?
Kann ich ClamAV reconfigueren lassen, damit er die LOG-Ordner neu erstellt?

Danke voarb für eure Hilfe!

Viele Grüße
Matt

ahrnke · October 10, 2016, 3:00pm

Ich kann nicht mit Sicherheit sagen, ob die WebGUI hier das geeignete Werkzeug ist, da ich diese DInge auch lieber von der Kommandozeile ausführe. Zumindest scheint die GUI zu sagen, was wegen der Paketabhängigkeiten auf dem System passieren soll.
Was konkret zu tun ist, dürfte auch vom Zustand abhängen. Mir ist völlig unklar, wie es überhaupt möglich ist, dass Dovecot auf einem Zarafa-Server unter UCS installiert werden kann. Die Einstellungen im Appcenter sollten das verhindern:

ConflictedApps = oxseforucs,kolab,horde,owncloud6,auralis ConflictedSystemPackages = univention-mail-server,univention-mail-cyrus,cyrus-imapd-2.4,cyrus-imapd-2.2,tomcat6,univention-mail-dovecot,dovecot-imapd,dovecot-core

Ich selbst würde mich vermutlich erstmal mit aptitude auf den Weg machen und suchen (“search”), ob irgendwas mit “dovecot” oder “univention-mail” auf dem System liegt und das dann mit “apt-get remove --purge” unter sorgfältiger Beachtung der ggf. angezeigten Warnungen entfernen. Das könnte über die GUI aber auch funktionieren.
Disclaimer: Meine Verfahrensweise ist eigentlich nicht ganz korrekt. Man soll “univention-install” bzw. “univention-remove” nehmen. 5.6.3. Installation/Deinstallation von einzelnen Paketen auf der Kommandozeile.

Das ClamAV-Problem ist mir noch zu diffus. Grundsätzlich sollten Sie “univention-install --reinstall clamav” ohne größere Probleme ausführen können,.

matt · October 10, 2016, 5:53pm

Verstehe ich auch nicht. Zumal der Server bis zum Upgrade wunderbar funktioniert hat. Und erst beim Upgrade die Fehlermeldung aufkam, dass Dovecot und Univention-Mail deinstalliert werden müssen.

Habe nun alle Pakete deinstalliert via (WebGUI wie im Handbuch), die mit Dovecot zu tun haben. Allerdings sieht univention-check-templates immer noch gleich aus. Wie bekomme ich nun die Dovecot-Templates weg?

[quote]Das ClamAV-Problem ist mir noch zu diffus. Grundsätzlich sollten Sie “univention-install --reinstall clamav” ohne größere Probleme ausführen können,.[/quote] war ausreichen und hat funktioniert.

Nach wie vor funktionieren die eingehenden Mails nicht - ausgehend funktioniert ohne Probleme.

Hier mal die Postfix konfig, vielleicht hilf die ja ein bischen weiter.

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry überschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/postfix/main.cf.d/10_general
#       /etc/univention/templates/files/etc/postfix/main.cf.d/30_maps
#       /etc/univention/templates/files/etc/postfix/main.cf.d/50_restrictions
#       /etc/univention/templates/files/etc/postfix/main.cf.d/60_tls
#       /etc/univention/templates/files/etc/postfix/main.cf.d/80_delivery
#

# The message_size_limit parameter limits the total size in bytes of
# a message, including envelope information. Default is 10240000
message_size_limit = 10240000


# mailbox_size_limit limits the max. size of local mailboxes. Default is 51200000
# mailbox_size_limit = 51200000


# some basic path definitions
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix


# some basic mail system settings
myhostname = mailsrv.domain.de
# mydomain is unset - The default is to use $myhostname minus the first component.
myorigin = mailsrv.domain.de
smtp_helo_name = mailsrv.domain.de



append_dot_mydomain = no

inet_interfaces = 127.0.0.1
inet_protocols = ipv4

mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8

masquerade_domains = $mydomain
masquerade_exceptions = root

transport_maps = hash:/etc/postfix/transport


# we need to name a smtp relay host to which we forward non-local
# mails. smtp authentication is also possible.
relayhost = smtp.1und1.de:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth


disable_vrfy_command = no


# banner

sender_canonical_maps = ldap:/etc/postfix/ldap.canonicalsender
recipient_canonical_maps = ldap:/etc/postfix/ldap.canonicalrecipient
local_header_rewrite_clients = static:all



canonical_maps = hash:/etc/postfix/canonical
relocated_maps = hash:/etc/postfix/relocated

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

# smtpd_sender_restrictions is not defined since all relevant checks have been moved to
# smtpd_recipient_restrictions (see below) and every mail has to pass smtpd_recipient_restrictions too.
#smtpd_sender_restrictions =

smtpd_recipient_restrictions = permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        reject_unlisted_recipient

# special recipient_restrictions which may be used by smtps/submission services
# (can be configured via UCR: mail/postfix/submission/restrictions/recipient/...)
# submission_recipient_restrictions =


#TLS settings
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols =
smtpd_tls_exclude_ciphers = RC4, aNULL
smtpd_tls_cert_file = /etc/univention/ssl/mailsrv.domain.de/cert.pem
smtpd_tls_key_file = /etc/univention/ssl/mailsrv.domain.de/private.key

smtpd_tls_received_header = no
smtpd_tls_session_cache_timeout = 3600s

tls_random_source = dev:/dev/urandom

smtpd_sasl_local_domain =

smtpd_sasl_security_options = noanonymous



# smtp client
smtp_tls_security_level = may
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_exclude_ciphers = RC4, aNULL

# Support broken clients like Microsoft Outlook Express 4.x which expect AUTH=LOGIN instead of AUTH LOGIN
broken_sasl_auth_clients = yes

# tls logging
smtp_tls_loglevel = 0
smtpd_tls_loglevel = 0

# EDH config
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem

# use the Postfix SMTP server's cipher preference order instead of the remote client's cipher preference order.
tls_preempt_cipherlist = yes

# The Postfix SMTP server security grade for ephemeral elliptic-curve Diffie-Hellman (EECDH) key exchange
smtpd_tls_eecdh_grade = strong

# if virus scanning is desired, all mails can be redirected through amavis.
content_filter = smtp-amavis:[127.0.0.1]:10024

ahrnke · October 10, 2016, 6:56pm

Wenn die GUI kein “purge” von Paketen anbietet und Sie sich nicht an apt-irgendwas herauntrauen, können Sie die alten Templates wahrscheinlich auch manuell löschen.

In der main.cf fehlen auf jeden Fall ein paar Dinge, die normalerweise aus /etc/univention/templates/files/etc/postfix/main.cf.d/30_maps kämen.

Ich habe nicht alles kontrolliert und mich erstmal auf das schon Beschriebene fokussiert.

Von einem Referenzsystem:

[code]root@showroom:/etc/postfix# ucr search --brief postfix/virtual
mail/postfix/virtual/enabled: true

root@showroom:/etc/postfix# grep virtual main.cf
virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.virtual
virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains
virtual_mailbox_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.virtual
virtual_transport = lmtp:127.0.0.1:2003
[/code]

Bitte vergleichen Sie die UCR-Variablen, insbsondere mail/postfix/virtual/transport.
Aus dem Template:

print '\nvirtual_transport = %s' % configRegistry.get('mail/postfix/virtual/transport', 'lmtp:127.0.0.1:2003')