Hallo alle! Seit kurzem habe ich ein Problem mit Postfix und Suse 10.0 (Kernel 2.6.13 -15.8). Zuerst funktionierte alles ganz wunderbar, doch plötzlich kann ich keine email mehr an externe Empfänger versenden. Ich bin mir nicht sicher, ob das nach dem Online-Update des Kernels passierte? Hier die Fehlermeldungen aus der /var/log/mail: Apr 18 20:41:29 linux postfix/smtp[13841]: fatal: open database /etc/postfix/sasl_passwd.db: Permission denied Apr 18 20:41:30 linux postfix/master[9013]: warning: process /usr/lib/postfix/smtp pid 13841 exit status 1 Apr 18 20:41:30 linux postfix/master[9013]: warning: /usr/lib/postfix/smtp: bad command startup -- throttling Die Rechte der sasl_passwd.db sind übirgens wie folgt: -rw------- 1 root root 12288 Apr 18 19:35 /etc/postfix/sasl_passwd.db Ich hoffe, es hat jemand eine Idee! Gruß, Marcus -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
t351206@gmx.de wrote:
Hallo alle!
Seit kurzem habe ich ein Problem mit Postfix und Suse 10.0 (Kernel 2.6.13 -15.8). Zuerst funktionierte alles ganz wunderbar, doch plötzlich kann ich keine email mehr an externe Empfänger versenden. Ich bin mir nicht sicher, ob das nach dem Online-Update des Kernels passierte?
Hier die Fehlermeldungen aus der /var/log/mail:
Apr 18 20:41:29 linux postfix/smtp[13841]: fatal: open database /etc/postfix/sasl_passwd.db: Permission denied Apr 18 20:41:30 linux postfix/master[9013]: warning: process /usr/lib/postfix/smtp pid 13841 exit status 1 Apr 18 20:41:30 linux postfix/master[9013]: warning: /usr/lib/postfix/smtp: bad command startup -- throttling
Die Rechte der sasl_passwd.db sind übirgens wie folgt: -rw------- 1 root root 12288 Apr 18 19:35 /etc/postfix/sasl_passwd.db
Ich hoffe, es hat jemand eine Idee!
Gib Postfix wenigstens Leserechte auf die Datenbank! postfix/smtp läuft nicht als root. setfacl -m u:postfix:r /etc/postfix/sasl_passwd.db Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Die Idee mit den rechten hatte ich ja auch schon ... leider führt dein Vorschlag nicht zur Lösung des Problems! DIe Fehlermeldung bleibt die Gleiche! Marcus -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
t351206@gmx.de wrote:
Die Idee mit den rechten hatte ich ja auch schon ... leider führt dein Vorschlag nicht zur Lösung des Problems! DIe Fehlermeldung bleibt die Gleiche!
Setze die Rechte doch mal temporär auf 755 für die Datei, starte Postfix einmal neu und versuche es dann noch einmal. Klappt das jetzt? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Gute Idee! Habe die Rechte mit chmod 755 geändert: -rwxr-xr-x+ 1 root root 12288 2006-04-18 19:35 /etc/postfix/sasl_passwd.db Leider immer noch die gleiche Fehlermeldung .... Marcus -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Nachtrag: Habe sogar mit "postfix reload" neu gestartet ... -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
t351206@gmx.de wrote:
Nachtrag: Habe sogar mit "postfix reload" neu gestartet ...
"postfix reload" != "postfix restart" Aber das sollte das Problem eigentlich beseitigen, es sei denn, dass Postfix smtp im chroot läuft, dann muss ein "postfix stop; sleep 5; postfi start" sein, weil dann die sasl_passwd nur beim Start eingelesen wird. Hattest du eine neue Testmail geschickt oder nur die alte beobachtet? Wenn nur die alte, dann bitte mal mit "postsuper -r ALL" die Mails neu einqueuen. Zeige auch mal die master.cf, ob dort etwas schräg ist mit chroot. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Tuesday 18 April 2006 23:04 schrieb Sandy Drobic:
Nachtrag: Habe sogar mit "postfix reload" neu gestartet ...
"postfix reload" != "postfix restart"
Aber das sollte das Problem eigentlich beseitigen, es sei denn, dass Postfix smtp im chroot läuft, dann muss ein "postfix stop; sleep 5; postfi start" sein, weil dann die sasl_passwd nur beim Start eingelesen wird.
Die Postfix Dämonen lesen die zu ihnen gehörenden Maps nur beim starten. Wird eine Map geändert und der Prozess bekommt dieses mit, beendet er sich baldmöglichst um beim nächsten Start die Map einlesen zu können. Das geht sogar automatisch. So hat der smtp ein Auge auf die $smtp_sasl_password_maps. Wird sie geändert, beendet er sich (baldmöglichst) selber und liest die neue beim nächsten Starten ein. Dieses Verhalten kann man global mit "postfix reload" initiiren. Gelesen wird die Konfiguration bzw. Map zu einem Zeitpunkt wo das chroot noch nicht an ist. Deshalb muss nix was direkt zu Postfix (/etc/postfix/*) gehört ins chroot, zumindest fällt mir spontan nichts ein ;-) Die nahezu einzigen Optionen, die wenn man sie ändert einen Neustart von Postfix erfordern, sind die Sockets wo der master drauf höhrt. Darunter fallen die IPs bzw. Ports aus der master.cf und der Parameter inet_interfaces aus der main.cf. -- Andreas
Alles getestet ... geht immer noch nicht und die Fehlermeldung erscheint weiter periodisch (jede Minute). Hier die master.cf: # Postfix master process configuration file. For details on the format # of the file, see the Postfix master(5) manual page. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd #submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_client_restrictions=permit_sasl_authenticated,reject #smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes # -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes #submission inet n - n - - smtpd # -o smtpd_etrn_restrictions=reject # -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes #628 inet n - n - - qmqpd pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr #tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil #localhost:10025 inet n - n - - smtpd -o content_filter= scache unix - - n - 1 scache # # ==================================================================== # Interfaces to non-Postfix software. Be sure to examine the manual # pages of the non-Postfix software to find out what options it wants. # # Many of the following services use the Postfix pipe(8) delivery # agent. See the pipe(8) man page for information about ${recipient} # and other message envelope options. # ==================================================================== # # maildrop. See the Postfix MAILDROP_README file for details. # Also specify in main.cf: maildrop_destination_recipient_limit=1 # maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} .
Zeige auch mal die master.cf, ob dort etwas schräg ist mit chroot.
-- Gruß, Marcus -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
t351206@gmx.de wrote:
Alles getestet ... geht immer noch nicht und die Fehlermeldung erscheint weiter periodisch (jede Minute).
Hm, so langsam wird es rätselhaft. Was steht denn im Log /var/log/mail, wenn Postfix startet und du eine Mail losschickst? Woher kommt dein Postfix-Paket? Hast du Postfix selbst kompiliert? Da gibt es im Zusammenhang mit SASL ein paar schöne Möglichkeiten, sich in den Fuß zu schießen. Welche Suse-Version? Wenn es die 10.x ist, schau doch bitte mal in /var/log/messages, ob vielleicht AppArmor oder SELinux hier dazwischenpfuschen.
Hier die master.cf: smtp unix - - n - - smtp
Das ist auch in Ordnung, kein chroot. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hier /var/log/messages direkt nach dem Booten:
Apr 19 19:35:56 linux kernel: SubDomain: REJECTING r access to
/etc/postfix/sasl_passwd.db (smtp(5317) profile /usr/lib/postfix/smtp active
/usr/lib/postfix/smtp)
.... [und eine Minute später]
Apr 19 19:36:57 linux kernel: SubDomain: REJECTING r access to
/etc/postfix/sasl_passwd.db (smtp(6093) profile /usr/lib/postfix/smtp active
/usr/lib/postfix/smtp)
Hier /var/log/mail nach dem Booten:
Apr 19 19:35:54 linux postfix/postfix-script: starting the Postfix mail
system
Apr 19 19:35:54 linux postfix/master[5258]: daemon started -- version 2.2.5,
configuration /etc/postfix
Apr 19 19:35:54 linux postfix/qmgr[5274]: 96ABD960: from=
Wow! Habe gerade AppArmor deaktiviert und all die mail in der Queue geht raus! Vielen Dank für die tatkräftige Hilfe! Hast du eine Ahnung was da wohl passiert ist? -- Gruß, Marcus Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
t351206@gmx.de wrote:
Wow! Habe gerade AppArmor deaktiviert und all die mail in der Queue geht raus! Vielen Dank für die tatkräftige Hilfe!
Hast du eine Ahnung was da wohl passiert ist?
Nein, kann ich leider nicht sagen. Ich verwende für meine Server noch die Version 9.2, da gab es AppArmor noch nicht. Vielleicht ist es ja mit einem Update gekommen, dass das AppArmor-Profil für Postfix dann als Standard aktiviert wurde. Jetzt warte ich noch ein paar Wochen, bis die neue Version 10.1 herauskommt, höre mir die Schreie der Early-Adopters an, und überlege dann, ob ich bis 10.2 warte, lieber die 10.0 installiere oder doch jetzt die 10.1 nehme... Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy, hallo wer-auch-immer, hallo Leute, Am Mittwoch, 19. April 2006 20:23 schrieb Sandy Drobic:
t351206@gmx.de wrote: ^^^^^^^^^^^^^^ Hier könnte Dein Realname stehen ;-)
Wow! Habe gerade AppArmor deaktiviert und all die mail in der Queue geht raus! Vielen Dank für die tatkräftige Hilfe!
Hast du eine Ahnung was da wohl passiert ist?
Apr 19 19:35:56 linux kernel: SubDomain: REJECTING r access to /etc/postfix/sasl_passwd.db (smtp(5317) profile /usr/lib/postfix/smtp active /usr/lib/postfix/smtp) Ganz einfach: AppArmor hat den Lesezugriff (r) auf die Datei blockiert (REJECTING). So schwer ist diese Zeile im Log doch nicht zu lesen, oder? https://bugzilla.novell.com/show_bug.cgi?id=146596, gefixt in der uralten ;-) 10.1 beta4. AppArmor ist in der 10.1 übrigens standardmäßig aktiviert (zumindest bei Neuinstallation - bei einem Update bin ich mir nicht sicher).
Jetzt warte ich noch ein paar Wochen, bis die neue Version 10.1 herauskommt, höre mir die Schreie der Early-Adopters an, und überlege dann, ob ich bis 10.2 warte, lieber die 10.0 installiere oder doch jetzt die 10.1 nehme...
*LoL* Ich werde definitiv einen Server mit der 10.1 aufsetzen. (Der jetzige läuft mit der 9.1, für die es ab Juli (IIRC) keine Sicherheitsupdates mehr gibt. Und von Plesk habe ich die Nase auch voll [1] - diesmal wird es Postfix ;-)) Mein Eindruck von der 10.1 (diese Mail schreibe ich auf einer 10.1 RC1): Durch die verlängerte Beta-Phase wurden nicht nur die durch den Austausch des Paketmanagers geschaffenen Probleme beseitigt, sondern auch eine Menge anderer Fehler in diversen Programmen, die es bei einer normal langen Beta-Phase wohl ins Release geschafft hätten :-) Sprich: Der Paketmanager (ja, der hatte die verlängerte Beta-Phase _wirklich_ nötig ;-) ist inzwischen wieder so gut wie vorher - alles andere dürfte deutlich besser als bei einem "normalen" Release sein. Gruß Christian Boltz [1] Ich empfehle (mal wieder) eine Google-Suche nach Plesk in Verbindung mit meinem Namen - das erklärt meine Abneigung gegen dieses "etwas"... -- There is nothing wrong with making mistakes, but... make *new* ones. [D.Sim]
participants (4)
-
Andreas Winkelmann -
Christian Boltz -
Sandy Drobic -
t351206＠gmx.de