Postfix/Kopano versendet nicht mehr nach Update auf 4.2-1 errata52

german
ucs-4-2
postfix

#1

Hallo zusammen,

habe eben das Update auf UCS 4.2.-1 errata52 gemacht und klar ich musste die transport aus der Backup Datei wieder herstellen.
Wie es scheint, hat sich aber bei Postfix was getan und dieser Meldet nun folgendes:


Jun 21 09:50:54 ucs postfix/smtpd[2672]: connect from localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/smtpd[2672]: A19D86409FD: client=localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/cleanup[3111]: A19D86409FD: message-id=<kcim.594a255e.d7c.27f9bbba2b74436c@ucs.xyz.intranet>
Jun 21 09:50:54 ucs postfix/qmgr[2570]: A19D86409FD: from=<mail@user-xyz.de>, size=1064, nrcpt=1 (queue active)
Jun 21 09:50:54 ucs postfix/smtpd[2672]: disconnect from localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/smtp[3265]: warning: hash:/etc/postfix/tls_policy is unavailable. open database /etc/postfix/tls_policy.db: No such file or directory
Jun 21 09:50:54 ucs postfix/smtp[3265]: warning: hash:/etc/postfix/tls_policy lookup error for "[127.0.0.1]:10024"
Jun 21 09:50:54 ucs postfix/smtp[3265]: warning: smtp_tls_policy_maps, next-hop destination "[127.0.0.1]:10024": policy table lookup error
Jun 21 09:50:54 ucs postfix/smtpd[3397]: connect from localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/smtpd[3397]: EEA776409FE: client=localhost[127.0.0.1], orig_queue_id=A19D86409FD, orig_client=localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/cleanup[2681]: EEA776409FE: message-id=<kcim.594a255e.d7c.27f9bbba2b74436c@ucs.xyz.intranet>
Jun 21 09:50:54 ucs postfix/qmgr[2570]: EEA776409FE: from=<mail@user-xyz.de>, size=1794, nrcpt=1 (queue active)
Jun 21 09:50:54 ucs postfix/smtpd[3397]: disconnect from localhost[127.0.0.1]
Jun 21 09:50:54 ucs postfix/smtp[3430]: warning: hash:/etc/postfix/tls_policy is unavailable. open database /etc/postfix/tls_policy.db: No such file or directory
Jun 21 09:50:54 ucs postfix/smtp[3430]: warning: hash:/etc/postfix/tls_policy lookup error for "smtp.1blu.de"
Jun 21 09:50:54 ucs postfix/smtp[3430]: warning: smtp_tls_policy_maps, next-hop destination "smtp.1blu.de": policy table lookup error
Jun 21 09:50:55 ucs amavis[3385]: (03385-04) Passed CLEAN {RelayedInternal}, LOCAL [127.0.0.1]:35506 <mail@user-xyz.de> -> <user@gmail.com>, Queue-ID: A19D86409FD, Message-ID: <kcim.594a255e.d7c.27f9bbba2b74436c@ucs.xyz.intranet>, mail_id: OQ_CQcY8Oobq, Hits: -2.175, size: 1064, queued_as: EEA776409FE, 287 ms
Jun 21 09:50:55 ucs postfix/smtp[3265]: A19D86409FD: to=<user@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.35, delays=0.05/0/0.01/0.29, 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 EEA776409FE)
Jun 21 09:50:55 ucs postfix/qmgr[2570]: A19D86409FD: removed
Jun 21 09:50:55 ucs postfix/qmgr[2570]: warning: private/smtp socket: malformed response
Jun 21 09:50:55 ucs postfix/qmgr[2570]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 21 09:50:55 ucs postfix/qmgr[2570]: warning: connect to transport private/retry: No such file or directory
Jun 21 09:50:55 ucs postfix/master[2567]: warning: process /usr/lib/postfix/smtp pid 3430 killed by signal 11
Jun 21 09:50:55 ucs postfix/qmgr[2570]: EEA776409FE: to=<user@gmail.com>, relay=none, delay=0.12, delays=0.01/0.12/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)

In der transport stehen eigentlich nur infos für die interne Zustellung.
Dass ganze ist oder war so eingerichtet, dass user auch via gmail etc…versenden konnten und auch mehrere Mailadressen hatten. Hat eigentlich gut funktioniert, bis heute, bis nach dem Update.

transport:
mailtestsystem152@gmail.com lmtp:127.0.0.1:2003

Hoffnungsvoll Carmen


Kein Mail-Transport mehr nach update auf 4.2-1
#2

Hallo Carmen,

von welcher Version / welchem Errata wurde das Update durchgeführt?

Kannst du einmal die Ausgabe von folgenden Befehlen posten:

netstat -tulpn | grep -E "(master|amavis|kopano|2003)"
postconf -n

Wurden manuelle Anpassungen an den Dateien /etc/postfix/main.cf oder /etc/postfix/master.cf vorgenommen?

Viele Grüße,
Tobi


#3

@birkefeld Danke Dir/Ihnen…

Upgedate habe ich von 4.2.0 err25

ja und in der Tat ich wir haben wie im Artikel im kopano Forum das System konfigureirt, dass es mehrere mail relays unterstützt, hier der Link

und netstat -tulpn | grep -E “(master|amavis|kopano|2003)”
postconf -n sagt folgendes:

root@ucs:~# netstat -tulpn | grep -E "(master|amavis|kopano|2003)"
tcp        0      0 0.0.0.0:236             0.0.0.0:*               LISTEN      2111/kopano-server
tcp        0      0 0.0.0.0:237             0.0.0.0:*               LISTEN      2111/kopano-server
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      2609/master     
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      2609/master     
tcp        0      0 127.0.0.1:8091          0.0.0.0:*               LISTEN      1093/kopano-webmeet
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN      2609/master     
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      2609/master     
tcp6       0      0 :::110                  :::*                    LISTEN      985/kopano-gateway
tcp6       0      0 :::143                  :::*                    LISTEN      985/kopano-gateway
tcp6       0      0 :::8080                 :::*                    LISTEN      979/kopano-ical 
tcp6       0      0 :::2003                 :::*                    LISTEN      980/kopano-dagent
tcp6       0      0 :::8443                 :::*                    LISTEN      979/kopano-ical 
tcp6       0      0 :::993                  :::*                    LISTEN      985/kopano-gateway
tcp6       0      0 :::995                  :::*                    LISTEN      985/kopano-gateway
root@ucs:~# postconf -n

Herzlichen Dank C.


#4

Hallo Carmen,

Das gleiche Problem taucht hier auch auf: Postfix smtp stopped after errata 49
Bitte schau nach, ob /etc/postfix/tls_policy existiert.
Wenn nicht, dann: ucr commit /etc/postfix/tls_policy.
Auf jeden Fall postmap postmap /etc/postfix/tls_policy ausführen.

In /var/log/univention/updater.log sollte sich so etwas finden:

Create mail/postfix/tls/client/policy/amavis
File: /etc/postfix/tls_policy

In diese Datei sollte nicht direkt geschrieben werden. Wenn statt dessen die UCR variable mail/maps/transport/* gesetzt wird, dann bleibt das über updates hinweg erhalten. In diesem Fall müsste das sein:
ucr set mail/maps/transport/ms152="mailtestsystem152@gmail.com lmtp:127.0.0.1:2003"

Gruß
Daniel


#5

@troeder

Dank Dir Daniel, dass hat nun geholfen, funktioniert nun alles perfekt.
Manchmal scheitert man/Frau an Kleinigkeiten ich habe es immer nur geschafft eine UCR variable für die transport zu setzen klar, wenn ich den gleichen Syntax nach /transport nehme…dass ich dann immer nur einen Eintrag habe.

Die Datei tls_policy musste ich händisch anlegen die Datei tls_policy wurde nicht angelegt durch ucr commit, ist der Syntax mit dem Punkt richtig am Ende?
Hoffe dass ist ok so?
Für was wird tls_policy bnötigt und soll ich dies schon vor dem Errata update gesetzt werden?

Danke Euch C.


#6

Der Punkt gehört nicht dazu. Kannst du es noch einmal versuchen mit:
ucr commit /etc/postfix/tls_policy

Was wird angezeigt bei:
ucr search --brief mail/postfix/tls/client/policy

Sollte sein:

mail/postfix/tls/client/policy/.*: <empty>
mail/postfix/tls/client/policy/amavis: [127.0.0.1]:10024 none

Gruß
Daniel


#7

@troeder

Danke noch mal.
Also ich habe es noch mal versucht und

mail/postfix/tls/client/policy/.*: <empty>
mail/postfix/tls/client/policy/amavis: [127.0.0.1]:10024 none

wird auch angezeigt.

Nur wie gesagt
ucr commit /etc/postfix/tls_policy

zeigt nichts im updater.log und die tls_policy musste ich immer noch händisch anlegen, was für mich kein Beinburcht ist, da das System einwandfrei funktioniert.
Hoffe das passt so.

Viele Grüße Carmen


#8

Hallo Carmen,

Wir vermuten, dass die Datei /etc/univention/templates/info/univention-mail-postfix.info modifiziert wurde. Hast du die Datei ggf. absichtlich modifiziert? Wenn ja, warum? Falls nicht, müssen wir etwas weiter debuggen. Ich habe da einen kleinen Fragenkatalog:

  1. Kannst du bitte die Datei /etc/univention/templates/info/univention-mail-postfix.info an diesen Thread anhängen oder mir persönlich zuschicken?
  2. Führe bitte das folgende Kommando aus und schicke mir die Ausgabe zu:
    md5sum /etc/univention/templates/info/univention-mail-postfix.info
  3. Führe bitte das folgende Kommando aus und schicke mir die Ausgabe zu:
    find -ls /etc/univention/templates/info/univention-mail-postfix*
  4. Hast du die Mailserver-App in der Vergangenheit mal deinstalliert und wieder installiert?
  5. Gibt es sonstige mailrelevante Apps (neben Kopano), die auf dem System installiert sind oder es mal waren?
  6. Was ist die initiale UCS-Version mit der das System installiert wurde?

Falls bei dir die Datei /etc/univention/templates/info/univention-mail-postfix.info existiert, kannst du folgenden Workaround ausprobieren, aber bitte erst die Kommandos oben ausführen, da die Ausgaben sonst für uns nutzlos sind:

cd /etc/univention/templates/info/
mv univention-mail-postfix.info univention-mail-postfix.info.modified
mv univention-mail-postfix.info.dpkg-dist univention-mail-postfix.info
ucr update
ucr commit /etc/postfix/*
postmap /etc/postfix/tls_policy
invoke-rc.d postfix restart

Viele Grüße

Sönke


UCS Update 4.2.0 >4.2.1 Mailabruf nicht mehr möglich
UCS Update 4.2.0 >4.2.1 Mailabruf nicht mehr möglich
#9

@Schwardt

Hi Sönke,

danke Dir.

Ja die univention-mail-postfix.info wurde modifiziert.
Laut dieser Anleitung modifiziert, sprich es wurde dies hinzugefügt.

Type: subfile
Multifile: etc/postfix/main.cf
Subfile: etc/postfix/main.cf.d/31_sender_dependent_relayhostmaps

Brauchst Du dann 1-3 noch?

4 Nein
5 nur Fetchmail
6 kann ich nicht mehr sagen, da es irgendwann im Mai war, als wir das installiert haben, war aber schon mit 4.2 glaube ich.

Viele Grüße C.


Postfix smtp stopped after errata 49
#10

Hallo Carmen,

vorhandene Dateien unterhalb von /etc/univention/templates/ zu verändern, ist i.d.R. keine gute Idee, weil es dann früher oder später zu (ggf. schwerwiegenden) Updateproblemen kommt (so wie jetzt).

In diesem konkreten Fall kannst du die drei Zeilen in eine eigene Datei ablegen. Z.B. /etc/univention/templates/info/my-custom-templates.info. Danach musst du dann ucr register my-custom-templates ausführen, um das neue info-File zu registrieren. Jetzt wird das Subtemplate automatisch in die main.cf von Postfix eingebunden und es gibt keine Probleme mehr mit den info-Dateien an sich.

Wenn du die Datei univention-mail-postfix.info.dpkg-dist zurück nach univention-mail-postfix.info per mv verschoben und auch nicht wieder modifiziert hast, sollte es in Zukunft an der Stelle keine Probleme geben.

Viele Grüße

Sönke


Absenderabhängiger Smarthost: 554 Fehler
#11

@Schwardt

Danke Sönke,

jetzt hat es funktioniert, habe testweise die tls_policy noch mal gelöscht und nun wurde sie angelegt.
Denke ich muss dem Autor dieses Artikels dies auch noch mal kund tun…denke es war hier aus dem Forum, damit es dann richtig läuft…bei den anderen.

Hier nun noch eine offtopic Frage, ist dieser Hinweis vor dem getätigten Update normal?
To continue please set the UCR-Variable 'update/cool-solutions/ucs42' to 'yes'. Error: Update aborted by pre-update script of component cool-solutions before calling release script

Viele Grüße Carmen


#12

Hallo Carmen,

schön zu hören, dass es jetzt funktioniert.

Machst du generell für off-topic-Fragen einen neuen Thread auf? Das wird dann von meinen Kollegen und anderen besser gefunden.

Viele Grüße

Sönke


#13

Hallo,

kurze frage, gibt es auch eine Möglichkeit so ein custom template Eintrag zu löschen oder von xycvwer.info auf zzzzzz.info zu ändern, falls man im nachhinein einen anderen Namen vergeben möchte.

Wo ist der Eintrag dann im Webbportal des usc zu finden.

Gruß Theo


#14

Hallo,

das Pendant zu

ucr register my-custom-templates

ist

ucr unregister my-custom-templates

Das unregister deregistriert die .info-Datei, in welcher die UCR-(Sub-)Templates referenziert sind.

Welcher “Eintrag im Webportal” ist gemeint? Sofern sie korrekt registriert sind, wird auf Änderungen von UCR-Variablen reagiert und aus den registrierten Templates dann die eigentlichen Konfigurationsdateien generiert.
Auf welche UCR-Variablen reagiert wird, ist abhängig von der .info-Datei. Die UCR-Variablen müssen natürlich noch mit sinnvollen Werten z.B. über die UMC oder auf der Kommandozeile gefüllt werden.

Viele Grüße

Sönke Schwardt-Krummrich


#15

Danke Sönke @Schwardt

ich meinte ob wenn ich hier suche, ob dieses zu finden ist.

Viele Grüße Theo


#16

Hallo,

wie gesagt, werden über das ucr register ... nur die neuen Templates registriert aber keine neuen UCR-Variablen angelegt. Man kann seine eigenen UCR-Variablen aber einfach über Hinzufügen (Auf dem Screenshot links unten) hinzufügen. Wenn für diese UCR-Variablen dann Werte gesetzt sind, kann man sie auch über den Suchdialog finden.
Das ist aber unabhängig von der Registrierung von Templates.

Viele Grüße

Sönke Schwardt-Krummrich