UCS Update 4.2.0 >4.2.1 Mailabruf nicht mehr möglich

dark957 · June 25, 2017, 3:57pm

Hallo,
leider ist es nach Update auf 4.2.1 nicht mehr möglich Mails zu versenden und zu empfangen (SMTP-Fehler: 451). Vielleicht hat ein Profi eine Idee!

Log mail.log:
Jun 25 17:45:37 mail fetchmail[2494]: 3 Nachrichten fÃ¼r xxxxx@xxxx.de bei Pop3.strato.de (6681 Bytes).
Jun 25 17:45:37 mail fetchmail[2494]: Nachricht xxxxx@xxxx.de @Pop3.strato.de:1 von 3 wird gelesen (1732 Bytes) (Log-Meldung unvollstÃ¤ndig)
Jun 25 17:45:37 mail fetchmail[2494]: SMTP-Fehler: 451 4.3.0 <xxxxx@xxxx.de >: Temporary lookup failure
Jun 25 17:45:37 mail fetchmail[2494]: nicht gelÃ¶scht

Hier die Fehlermeldung aus Mail.log:
Jun 25 17:42:29 mail postfix/smtpd[2502]: warning: ldap:/etc/postfix/ldap.external_aliases is unavailable. open /etc/postfix/ldap.external_aliases: No such file or directory
Jun 25 17:42:29 mail postfix/smtpd[2502]: warning: ldap:/etc/postfix/ldap.external_aliases lookup error for "xxx@xxxx.de"
Jun 25 17:42:29 mail postfix/smtpd[2502]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 xxx@xxxx.de: Temporary lookup failure; from=xxx@xxxx.de to=xxx@xxxx.de proto=ESMTP helo=<mail.xxxxx.de>
Jun 25 17:42:29 mail fetchmail[2494]: Nachricht xxx@xxxx.de@Pop3.strato.de:3 von 3 wird gelesen (2747 Bytes) (Log-Meldung unvollstÃ¤ndig)
Jun 25 17:42:29 mail fetchmail[2494]: SMTP-Fehler: 451 4.3.0 xxx@xxxx.de: Temporary lookup failure
Jun 25 17:42:29 mail fetchmail[2494]: nicht gelÃ¶scht
Jun 25 17:42:29 mail postfix/smtpd[2502]: disconnect from localhost[127.0.0.1]
Jun 25 17:42:29 mail fetchmail[2494]: 1 Nachricht fÃ¼r xxx@xxxx.de bei pop.gmx.net (93092 Bytes).
Jun 25 17:42:29 mail postfix/smtpd[2502]: connect from localhost[127.0.0.1]
Jun 25 17:42:29 mail postfix/smtpd[2502]: warning: ldap:/etc/postfix/ldap.external_aliases is unavailable. open /etc/postfix/ldap.external_aliases: No such file or directory
Jun 25 17:42:29 mail postfix/smtpd[2502]: warning: ldap:/etc/postfix/ldap.external_aliases lookup error for "xxx@xxxx.de"
Jun 25 17:42:29 mail postfix/smtpd[2502]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 xxx@xxxx.de: Temporary lookup failure; from=bounces+1434781-11c0-xxx=gmx.net@m.reply.ebay.de to=xxx@xxxx.de proto=ESMTP helo=<mail.xxxxxx.de>
Jun 25 17:42:29 mail fetchmail[2494]: Nachricht xxx@xxxx.de@pop.gmx.net:1 von 1 wird gelesen (93092 Bytes) (Log-Meldung unvollstÃ¤ndig)
Jun 25 17:42:29 mail fetchmail[2494]: SMTP-Fehler: 451 4.3.0 xxx@xxxx.de: Temporary lookup failure
Jun 25 17:42:29 mail fetchmail[2494]: nicht gelÃ¶scht
Jun 25 17:42:29 mail postfix/smtpd[2502]: disconnect from localhost[127.0.0.1]
Jun 25 17:57:09 mail postfix/smtpd[5660]: connect from localhost[127.0.0.1]
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases is unavailable. open /etc/postfix/ldap.external_aliases: No such file or directory
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases lookup error for "Jun 25 17:57:09 mail postfix/smtpd[5660]: connect from localhost[127.0.0.1]
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases is unavailable. open /etc/postfix/ldap.external_aliases: No such file or directory
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases lookup error for “Jun 25 17:57:09 mail postfix/smtpd[5660]: connect from localhost[127.0.0.1]
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases is unavailable. open /etc/postfix/ldap.external_aliases: No such file or directory
Jun 25 17:57:09 mail postfix/smtpd[5660]: warning: ldap:/etc/postfix/ldap.external_aliases lookup error for "xxxxx@xxxxxx.de”
Jun 25 17:57:09 mail postfix/smtpd[5660]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 xxxxx@xxxxxx.de: Temporary lookup failure; from=bounces+1434781-11c0-xxxxxxxx=gmx.net@m.reply.ebay.de to=xxxxx@xxxxxx.de proto=ESMTP helo=<mail.xxxxxxxx.de>
Jun 25 17:57:09 mail postfix/smtpd[5660]: disconnect from localhost[127.0.0.1]
"
Jun 25 17:57:09 mail postfix/smtpd[5660]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 xxxxx@xxxxxx.de: Temporary lookup failure; from=bounces+1434781-11c0-xxxxxxx=gmx.net@m.reply.ebay.de to=xxxxx@xxxxxx.de proto=ESMTP helo=<mail.xxxxxxx.de>
Jun 25 17:57:09 mail postfix/smtpd[5660]: disconnect from localhost[127.0.0.1]
"
Jun 25 17:57:09 mail postfix/smtpd[5660]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.0 xxxxx@xxxxxx.de: Temporary lookup failure; from=bounces+1434781-11c0-kerstinpietschmann=gmx.net@m.reply.ebay.de to=xxxxx@xxxxxx.de proto=ESMTP helo=<mail.xxxxxx.de>
Jun 25 17:57:09 mail postfix/smtpd[5660]: disconnect from localhost[127.0.0.1]

Danke im Voraus für einen Idee.

mfg dark957

ulf.kosack · June 25, 2017, 5:07pm

Hi,

schau mal, ob die Datei /etc/postfix/ldap.external_aliases vorhanden ist und führe mal ein postmap darauf aus. Wenn sie nicht vorhanden ist, schau mal, ob ein “ucr commit /etc/postfix/*” die Datei erstellt.

Viele Grüße
Ulf

dark957 · June 25, 2017, 7:25pm

Hallo Ulf,
danke für deinen Hinweis. ldap.external_aliases ist nicht vorhanden und die Befehl hat leider auch keine Besserung gebracht. Ich habe jetzt einfach den ganzen Server Wiederhergestellt und damit läuft es wieder.

PS.: LDAP.external ist aber auch in meinem Backup nicht vorhanden und das läuft!?!?

Schwardt · June 26, 2017, 8:22am

Hallo dark957!

ldap.external_aliases wurde mit einem Erratum für UCS 4.2-0 bzw. mit dem Update auf UCS 4.2-1 eingeführt. Daher denke ich, dass du früher oder später wieder in das Problem reinlaufen wirst. Leider kennen wir die genaue Ursache noch nicht.

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:

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

Viele Grüße

Sönke Schwardt-Krummrich

Schwardt · June 26, 2017, 10:42am

Es gibt einen weiteren Thread, in dem ein ähnliches Problem aufgetreten ist. Ist das ggf. genau dein Problem? Dort steht auch schon ein Workaround. Wäre klasse, wenn du eine kurze Rückmeldung geben könntest, ob dieser oder der andere Thread dir geholfen hat.

dark957 · June 26, 2017, 12:11pm

Hallo,
kann derzeit die Probe nicht mach, da ich eine Rolle rückwärts gemacht habe. Kann aber sagen, dass ich die postfix.info modifizieren wollte. Derzeitiger Eintrag ist
“#Type: subfile”
“#Multifile: etc/postfix/main.cf”
“#Subfile: etc/postfix/main.cf.d/31_sender_dependent_relayhostmaps”

Ich möchte nochmal mehr als einen Provider bedienen und des muss ich einen Relayhost einfügen. Workaround ist aber derzeit nur vorbereitet und nicht umgesetzt. Was mich wundert ist, dass es nur an dem Eintrag hängen soll?!?!
Wenn ich die postfix.info also wieder auf Standardformat bringe sollte das Update durchlaufen?

mfg dark957

nengo · June 26, 2017, 2:23pm

Hallo zusammen,

ich hatte nach dem Update auf 4.2.1 auch Probleme mit dem Mailempfang, allerdings mit einem anderen Fehler:

 fetchmail[2757]: SMTP-Fehler: 550 5.1.1 <USER@XXX>: Recipient address rejected: User unknown in virtual mailbox table

Nachdem ich die Emailadresse zusätzlich als alternative Emailadresse hinterlegt hatte, funktionierte der Mailempfang plötzlich wieder problemlos.

Ganz richtig kann dieses Verhalten allerdings auch nicht sein oder?

Viele Grüße

Niklas Engel

troeder · June 27, 2017, 6:15am

Hallo,

die Meldung sollte nur kommen, wenn Postfix den Benutzer nicht im LDAP findet. Habe ich Sie richtig verstanden, dass Emails nur noch an die alternativen Emailadressen angenommen werden, und an die primäre nicht mehr?

Für die Suche werden verschiedene LDAP-Suchen verwendet. Welche das sind, wird durch die UCR Vartiablen mail/postfix/virtual/.*/maps bestimmt. Diese sind aufgeräumt worden. Wenn sie individuell angepasst wurden, kann es sein, dass etwas durcheinander gekommen ist. Bitte einmal den Ausdruck hiervor hier her kopieren:
ucr search --brief mail/postfix/virtual/.*/maps

Um Benutzer und Email-Adressen im LDAP zu finden, ist diese Suche hier sehr hilfreich:
univention-ldapsearch -LLL '(|(mailPrimaryAddress=*)(mailAlternativeAddress=*))' uid mailPrimaryAddress mailAlternativeAddress

Gruß
Daniel Tröder

Schwardt · June 27, 2017, 9:10am

@dark957

Ja, alle Dateien unterhalb von /etc, die direkt aus den Paketen kommen, werden als Config-Dateien von dpkg behandelt und nicht automatisch überschrieben, wenn in dem Paket eine neuere Version mitgeliefert wird und die Datei im Dateisystem manuell modifiziert wurde. Wir haben die info-Datei mit UCS 4.2-1 modifiziert und neue Templates mitgebracht, was durch die manuelle Modifikation jetzt dazu geführt hat, dass nur die “halbe Konfiguration” aktiv war und der Postfix sich zurecht beschwert hat.

Bitte die Änderung nicht einfach rückgängig machen, sondern man in dem anderen Thread gucken, den ich oben verlinkt habe. Er zeigt, wie man die sender dependent relay hosts einrichten kann, ohne dass man UCS-Konfigurationsdateien modifizieren muss.
Das Beispiel auf der Kopano-Community-Seite war dahingehen nicht optimal, da die beschriebene Änderung nicht updatefest ist.

Generell ist es keine gute Idee, Konfigurationsdateien, die direkt aus den UCS-Paketen mitgebracht werden, zu modifizieren, da es früher oder später bei Updates zu Problemen kommen wird.

Viele Grüße

Sönke

dark957 · June 28, 2017, 10:02am

Hallo Sönke,
ich sorry das ich nochmal nachfragen muss:
1.) Woran erkennt das Update das die Datei modifiziert worden ist (am Datum der Erstellung oder am Inhalt)? Wenn die Änderung am Datum der Dateierstellung erkannt wird, komme ich nicht mehr auf den alten Stand und somit läuft auch der Updateservice nicht mehr?!?! Ich würde erst mal alles zurück ändern und dann dass Update sauber durchlaufen lassen wollen.
2.) Auf welchen Link referenzierst du? Ich kann keinen link sehen welcher sich auf das Thema Relayhost bezieht.

Anmerkung zum Update: Wäre es nicht günstiger etwaige Änderungen in Update einfach zu überschreiben um das Gesamtsystem lauffähig zu halten, als nur einen Teil zu updaten und damit ein Haufen zusätzlich Probleme zu produzieren? Ich denke aus der Richtung, dass mir die Änderungen welche ich durchgeführt habe bekannt sind und somit ggf. zu reproduzieren gehen.

mfg dark957

Schwardt · June 28, 2017, 2:15pm

Hallo dark957,

Die Paketverwaltung dpkg erkennt am Dateiinhalt (md5-Summe), ob die Datei modifiziert wurde. Relevant ist nachfolgendes nur, wenn die Datei manuell modifiziert wurde und nicht mehr mit der md5-Summe aus dem Paket übereinstimmt:
Wir haben den Paketmechanismus so konfiguriert, dass zunächst immer die alte, modifizierte Datei beibehalten wird und die neue Dateiversion mit der zusätzlichen Dateiendung .dpkg-dist daneben gelegt wird (in diesem Fall univention-mail-postfix.info.dpkg-dist). D.h. in univention-mail-postfix.info befindet sich nach dem Update der alte Inhalt plus deinen manuellen Anpassungen und in univention-mail-postfix.info.dpkg-dist die neue Version der Datei ohne Änderungen.
Mit dem Update auf UCS 4.2-1 bzw. mit dem Erratum 49 für UCS 4.2-x haben wir die info-Datei angepasst, weil wir neue Templates mitgebracht haben. Insofern: ja, es hängt nur an diesem selbstdurchgeführten Eintrag.
Wenn du deine Änderungen zurücknehmen willst, kommt es leider auf jedes Zeichen, Leerzeichen, Zeilenumbruch usw. an. Ist nur ein Zeichen anders, stimmt die md5-Summe nicht mehr und die Datei wird als manuell modifiziert betrachtet. Daher ist es wohl das einfachste, wenn du zunächst das Update auf UCS 4.2-1 durchführst und dann die folgenden Schritte ausführst, um zunächst in den UCS-Ursprungszustand zurückzukehren:

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/*
ucr commit /etc/postfix/tls_policy
postmap /etc/postfix/tls_policy
invoke-rc.d postfix restart

Wie ich in folgendem Thread bereits beschrieben habe, ist eine Anpassung der univention-mail-postfix.info gar nicht notwendig (siehe unten):

Bei UCS ist es generell keine gute Idee, bereits vorhandene, von UCS mitgelieferte Dateien unterhalb von /etc/univention/templates/ zu verändern, weil es dann früher oder später zu (ggf. schwerwiegenden) Updateproblemen kommt. Wir überschreiben die manuell angepassten Dateien absichtlich nicht, da dies u.U. zu mehr Problemen führt, als die alte Datei beizubehalten.

In diesem konkreten Fall kannst du die drei Zeilen für dein eigenes Subtemplate für main.cf

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

in eine eigene Datei ablegen. Z.B. /etc/univention/templates/info/my-custom-templates.info. Danach musst du dann den Befehl 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.

Viel Erfolg bei den Anpassungen,

Sönke

nengo · June 29, 2017, 2:14pm

@troeder

Hallo Herr Tröder,

ja das ist korrekt, eingehende Mails wurden immer abgewiesen und eine Fehlermeldung an den Absender gesendet.
Bewusst geändert habe ich an den Variablen mail/postfix/virtual/.*/maps nichts.

Die Ausgabe von ucr search --brief mail/postfix/virtual/.*/maps bleibt leer, ich denke da wird was fehlen.

Die LDAP Suche sieht okay aus.

dn: uid=USER,cn=users,dc=example,dc=local
uid: USER
mailPrimaryAddress: USER@example.local
mailAlternativeAddress: USER@example.local

Gruß
Niklas Engel

troeder · June 29, 2017, 3:49pm

Das ist i.O. Der Default sollte trotzdem in der Postfix config eingetragen werden. Können Sie einmal folgendes ausführen und die Ausgabe hierher kopieren?
postconf virtual_alias_maps virtual_mailbox_domains virtual_mailbox_maps
Und:
grep query_filter /etc/postfix/ldap.virtual*

Gruß
Daniel Tröder

nengo · June 30, 2017, 7:42am

Ausgabe 1:

virtual_alias_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal, ldap:/etc/postfix/ldap.virtual
virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains
virtual_mailbox_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal, ldap:/etc/postfix/ldap.virtual

Ausgabe 2

/etc/postfix/ldap.virtual:query_filter = (&(objectClass=univentionMail)(mailAlternativeAddress=%s)(!(univentionCanonicalRecipientRewriteEnabled=1)))
/etc/postfix/ldap.virtualdomains:query_filter = (&(objectClass=univentionMailDomainname)(cn=%s))
/etc/postfix/ldap.virtual_mailbox:query_filter = (&(objectClass=univentionMail)(mailPrimaryAddress=%s)(!(univentionCanonicalRecipientRewriteEnabled=1)))
/etc/postfix/ldap.virtualwithcanonical:query_filter = (&(objectClass=univentionMail)(|(mailAlternativeAddress=%s)(mailPrimaryAddress=%s))(univentionCanonicalRecipientRewriteEnabled=1))

troeder · June 30, 2017, 12:27pm

Hallo,

es sieht so aus, dass zwar die templates für /etc/postfix/ldap.virtual* aktualisiert wurden, aber das Sub-Template /etc/univention/templates/files/etc/postfix/main.cf.d/30_maps für die Erzeugung der /etc/postfix/main.cf nicht.

Das passiert, wenn es händisch angepasst wurde. Bitte schauen Sie nach, ob es in /etc/univention/templates/files/etc/postfix/main.cf.d/ eine Datei 30_maps.dpkg-dist gibt. In ihr sollte es folgende Zeile geben:

default_virtual_mailbox_maps = 'ldap:/etc/postfix/ldap.virtual_mailbox, ldap:/etc/postfix/ldap.sharedfolderlocal'

(Das ist der Wert der nach main.cf für virtual_mailbox_maps geschrieben wird, wenn mail/postfix/virtual/mailbox/maps leer ist.)

Wenn Sie die Datei /etc/univention/templates/files/etc/postfix/main.cf.d/30_maps mit dieser ersetzen, und
ucr commit /etc/postfix/main.cf
ausführen, sollte diese mit den korrekten Einstellungen erzeugt werden.

Gruß
Daniel Tröder

nengo · July 3, 2017, 9:18am

Hallo Herr Tröder,

das hat bestens geklappt. Ich müsste jetzt allerdings noch die von mir erstellte Datei sender_canonical (für die Funktion sender_canonical_maps) updatesicher einfügen, um den Absender umzuschreiben.

Wie gehe ich da am besten vor?

Schwardt · July 3, 2017, 9:36am

Hallo,

wenn bereits eine Datei /etc/postfix/canonical_sender erstellt wurde (Achtung: nicht sender_canonical!), kann einfach die UCR-Variable mail/maps/canonical/sender/enable auf den Wert file gesetzt werden:

ucr set mail/maps/canonical/sender/enable=file
postmap /etc/postfix/canonical_sender

Es wird dann automatisch in die main.cf die Zeile

sender_canonical_maps = hash:/etc/postfix/canonical_sender

eingetragen.

Analog verhält es sich zur der Option recipient_canonical_maps:

ucr set mail/maps/canonical/recipient/enable=file
postmap /etc/postfix/canonical_recipient

Viele Grüße

Sönke Schwardt-Krummrich

nengo · July 3, 2017, 10:22am

Hallo Herr Schwardt-Krummrich,

es funktioniert wieder alles!

Vielen Dank für die schnelle Hilfe, auch an @troeder

Gruß

Niklas Engel

dark957 · August 15, 2017, 2:44pm

Hallo Zusammen,
ich tue mich sehr schwer bei dem Einrichten des Domainabhängigen Mailversands für zwei oder mehrere unterschiedlichen Mailprovider und bin nicht recht viel weiter gekommen. Ich habe die Änderungen rückgängig gemacht und jetzt laufen auch die Updates wieder, dass Problem besteht aber immer noch . Ich habe einen Frage und eine Bitte:
1.) Die nachfolgende Anleitung beschreibt die Einrichtung eines Mailrelays auf Basis einer Paketinstallation: http://wiki.univention.de/index.php?title=Mailrelay_unter_UCS
Hier kann der Mailversand scheinbar für unterschiedliche Provider über einen Registereintrag in den Emailoptionen eingestellt werden. Funktioniert das noch unter Kopano http://wiki.univention.de/index.php?title=File:Mailrelay_mailmapping.png? Wenn ja, wie kann ich das Paket installieren? Habe schon mal in die Kopano System und Domaineinstellungen geschaut und hier in die Paketverwaltung, jedoch gibt es so ein Paket nicht zum Installieren.
2.) Kann einer von den Profis eventuell ein Manual zum Thema Mailrelay verfassen, wie welche Einstellungen vorgenommen werden müssen, damit die Einstellungen auch Updatesicher laufen und was auch für nicht Profis wie mich verständlich ist?!

Danke!

Moritz_Bunkus · August 15, 2017, 6:36pm

Kleine Tangente zum eigentlichen Problem.

Das ucr commit würde nichts bringen, wenn die neu zu erzeugende Datei nicht existiert. Was passieren würde:

Die Shell (bash) sieht ein Glob-Zeichen, das *, und ersetzt also /etc/postfix/* durch alle darauf zutreffenden Dateinamen, u.a. /etc/postfix/main.cf und /etc/postfix/master.cf.
Da die neu zu erzeugende Datei nicht existiert, wird die bash den Namen auch nicht aufführen können, und da der Name nicht an ucr commit übergeben wird, erzeugt ucr commit den auch nicht neu.
Selbst wenn in /etc/postfix keine einzige Datei existieren würde, so würde die bash schlicht das unmodifizerte Argument an ucr übergeben. ucr kenn aber kein Template für die Datei mit dem exakten Namen /etc/postfix/* und macht daher nichts.

Fehlende Dateien kann man daher nur mit entweder expliziter/manueller Angabe des exakten Namens oder aber durch Weglassen sämtlicher Argumente (also nur ucr commit) erzeugen lassen; letzteres, da das alle bekannten Templates neu schreibt.