Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #5252 > unrolled thread

[Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1

Back to article view | Back to de.comm.software.mailserver

Contents

  [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-03 19:39 -0500
    Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-04 05:06 +0000
      Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-04 15:59 -0500
        Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Sven Hartge <sh-162@svenhartge.de> - 2016-03-04 22:05 +0100
          Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-04 16:22 -0500
            Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Sven Hartge <sh-162@svenhartge.de> - 2016-03-04 22:43 +0100
              Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 dseppi@a1.net (David Seppi) - 2016-03-04 22:14 +0000
                Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Sven Hartge <sh-162@svenhartge.de> - 2016-03-04 23:20 +0100
                  Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-03-04 23:39 +0100
        Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-05 09:36 +0000
          Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-05 15:51 -0500
            Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-03-05 23:02 +0100
              Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-06 18:33 -0500
                Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-03-07 19:57 +0100
                  Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-07 19:00 -0500
                    Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Marc Haber <mh+usenetspam1118@zugschl.us> - 2016-03-08 06:14 +0100
                      Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-08 17:45 -0500
            Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Christian Garbs <mitch@cgarbs.de> - 2016-03-06 01:25 +0100
              Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-06 18:36 -0500
                Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-03-07 20:01 +0100
            Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-06 04:45 +0000
              Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-06 17:59 -0500
                Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-07 05:30 +0000
                  Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-07 18:43 -0500
                    Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-08 05:17 +0000
                      Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Andreas Kohlbach <march.10.ankman@spamgourmet.net> - 2016-03-08 17:23 -0500
                        Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 "Juergen P. Meier" <nospam-1984@jors.net> - 2016-03-10 04:57 +0000
          Re: [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1 Thomas Hochstein <thh@inter.net> - 2016-03-06 00:25 +0100

Page 1 of 2  [1] 2  Next page →

#5252 — [Postfix Debian Linux] "/usr/sbin/postdrop -r" exited with status 1

Ich nutze Postfix. Sendmail ist nicht installiert, zumindest nichts
wissentlich. Ohne mir einer Änderung bewusst zu sein - außer die in der
~/.authinfo eines USERS, wo Postfix nichts zu suchen haben sollte -
bekomme ich beim Versenden von Mails nun:

| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1

Bis gestern funktionierte es noch.

Mir ist eben auch aufgefallen, dass ich eine /usr/sbin/sendmail vom
26. Februar diesen Jahres habe. IIRC hatte ich die nie vorher. In den
Logs von aptitude (Paketmanager) steht, so weit ich zurück schauen kann
(30. September 2015), nichts über die Installation oder Update von
sendmail selbst.

postdrop selbst hat das selbe Datum wie o.g. sendmail, und folgende
Dateiattribute:

-r-xr-sr-x 1 root postdrop 10280 Feb 26 23:05 /usr/sbin/postdrop

Og. /usr/sbin/sendmail ist kein Link etwa auf Postfix, sondern ein
ELF 32-bit LSB executable.

Die habe die /usr/sbin/sendmail mal aus dem Weg geschoben, wo nach nicht
mal mehr die Meldung oben kam, sonder etwas mit "child" (habe ich
vergessen, sorry). Daraufhin Postfix neu installiert. Die
/usr/sbin/sendmail wurde wieder angelegt, aber Postfix will trotz
Neustartens nicht versenden.

Ich habe im Web noch gefunden, zu schauen ob eine Gruppe postdrop
existiert (tut sie), und eine Zeile setgid_group = postdrop in die
/etc/postfix/main.cf einzufügen, was aber auch nicht hilft.

Eine Websuche nach dem Betreff bringt mich auch nicht weiter.

[Supersedes]

Wenn ich mal nach der richtigen Meldung gesucht hätte, hätte ich doch
etwas gefunden. Die Meldung wäre

| unable to execute /usr/sbin/postdrop -r

gewesen. Und dann findet man u.a, dass eine neu installierte Version von
Selinux, wie das auch in meinem Fall ist, Schuld haben soll. Ich werde
also abwarten, ob das bald gefixt wird.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [next] | [standalone]

#5253

Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
> Ich nutze Postfix. Sendmail ist nicht installiert, zumindest nichts
> wissentlich. Ohne mir einer Änderung bewusst zu sein - außer die in der
> ~/.authinfo eines USERS, wo Postfix nichts zu suchen haben sollte -
> bekomme ich beim Versenden von Mails nun:
>
>| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1

Was sagt denn das Maillog dazu?

	grep -i postdrop /var/log/maillog

> Bis gestern funktionierte es noch.
>
> Mir ist eben auch aufgefallen, dass ich eine /usr/sbin/sendmail vom
> 26. Februar diesen Jahres habe. IIRC hatte ich die nie vorher. In den

Unfug. Postfix enthaelt ein /usr/sbin/sendmail kompatibilitaets-Binary.

Guckst du:
	dpkg -S /usr/sbin/sendmail
oder
	rpm -qf /usr/sbin/sendmail
je nach Distribution

> Logs von aptitude (Paketmanager) steht, so weit ich zurück schauen kann
> (30. September 2015), nichts über die Installation oder Update von
> sendmail selbst.

Was sagt denn:
	dpkg -la | grep "mail transport"

> postdrop selbst hat das selbe Datum wie o.g. sendmail, und folgende
> Dateiattribute:
>
> -r-xr-sr-x 1 root postdrop 10280 Feb 26 23:05 /usr/sbin/postdrop

Ach.

> Og. /usr/sbin/sendmail ist kein Link etwa auf Postfix, sondern ein
> ELF 32-bit LSB executable.

Ja, weil schon die cmd-line args inkmpatibel zueinander ist es
einfacher ein eigenes binary zu machen als eine argv[0]-Weiche in den
Code zu pflanzen.

> Die habe die /usr/sbin/sendmail mal aus dem Weg geschoben, wo nach nicht

Damit machst du dein System kapott.

> mal mehr die Meldung oben kam, sonder etwas mit "child" (habe ich
> vergessen, sorry). Daraufhin Postfix neu installiert. Die
> /usr/sbin/sendmail wurde wieder angelegt, aber Postfix will trotz
> Neustartens nicht versenden.

Weil dein Problem woanders liegt.

> Ich habe im Web noch gefunden, zu schauen ob eine Gruppe postdrop
> existiert (tut sie), und eine Zeile setgid_group = postdrop in die
> /etc/postfix/main.cf einzufügen, was aber auch nicht hilft.
>
> Eine Websuche nach dem Betreff bringt mich auch nicht weiter.
>
> Wenn ich mal nach der richtigen Meldung gesucht hätte, hätte ich doch
> etwas gefunden. Die Meldung wäre
>
>| unable to execute /usr/sbin/postdrop -r

Sowas muss in den Maillogs stehen, ja.

> gewesen. Und dann findet man u.a, dass eine neu installierte Version von
> Selinux, wie das auch in meinem Fall ist, Schuld haben soll. Ich werde
> also abwarten, ob das bald gefixt wird.

Hast du SElinux denn ueberhaupt aktiviert und konfiguriert?

Was sagt
	check-selinux-installation
?

Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

[toc] | [prev] | [next] | [standalone]

#5254

Juergen P. Meier wrote on 04. March 2016:
>
> Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>> Ich nutze Postfix. Sendmail ist nicht installiert, zumindest nichts
>> wissentlich. Ohne mir einer Änderung bewusst zu sein - außer die in der
>> ~/.authinfo eines USERS, wo Postfix nichts zu suchen haben sollte -
>> bekomme ich beim Versenden von Mails nun:
>>
>>| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1
>
> Was sagt denn das Maillog dazu?
>
> 	grep -i postdrop /var/log/maillog

| grep: /var/log/maillog: No such file or directory

Vorher war es hier /var/log/mail.info. Aber seit systemd ist es in
journalctl aufgegangen. Was selbst nichts zu postdrop hat.

Der Versuch des Versendens bringt eben aber (gekürzt um Hostnamen und
Zeitstempel) einen neuen Eintrag im Journal:

| postfix/postdrop[17908]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
| postfix/sendmail[17907]: warning: command "/usr/sbin/postdrop -r" exited with status 1
| postfix/sendmail[17907]: fatal: ankman(1000): unable to execute /usr/sbin/postdrop -r: Success

Also das, was ich schon nannte.

>> Bis gestern funktionierte es noch.
>>
>> Mir ist eben auch aufgefallen, dass ich eine /usr/sbin/sendmail vom
>> 26. Februar diesen Jahres habe. IIRC hatte ich die nie vorher. In den
>
> Unfug. Postfix enthaelt ein /usr/sbin/sendmail kompatibilitaets-Binary.

Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
Mailclients sendmail erwarten?

> Guckst du:
> 	dpkg -S /usr/sbin/sendmail
> oder
> 	rpm -qf /usr/sbin/sendmail
> je nach Distribution

| postfix: /usr/sbin/sendmail

>> Logs von aptitude (Paketmanager) steht, so weit ich zurück schauen kann
>> (30. September 2015), nichts über die Installation oder Update von
>> sendmail selbst.
>
> Was sagt denn:
> 	dpkg -la | grep "mail transport"

| ii  postfix                                3.0.4-5   [...]

>> postdrop selbst hat das selbe Datum wie o.g. sendmail, und folgende
>> Dateiattribute:
>>
>> -r-xr-sr-x 1 root postdrop 10280 Feb 26 23:05 /usr/sbin/postdrop
>
> Ach.

Nur um auszuschließen, dass die Fehlermeldung wegen falscher Dateirechte kommt.

>> Og. /usr/sbin/sendmail ist kein Link etwa auf Postfix, sondern ein
>> ELF 32-bit LSB executable.
>
> Ja, weil schon die cmd-line args inkmpatibel zueinander ist es
> einfacher ein eigenes binary zu machen als eine argv[0]-Weiche in den
> Code zu pflanzen.
>
>> Die habe die /usr/sbin/sendmail mal aus dem Weg geschoben, wo nach nicht
>
> Damit machst du dein System kapott.

Das war nur ein Test, um zu sehen, ob folgende Neuinstallation die
/usr/sbin/sendmail neu erstellt. Was es auch tat. Aber wenn nicht, hätte
ich sie zurück schieben können.

[...]

>> Wenn ich mal nach der richtigen Meldung gesucht hätte, hätte ich doch
>> etwas gefunden. Die Meldung wäre
>>
>>| unable to execute /usr/sbin/postdrop -r
>
> Sowas muss in den Maillogs stehen, ja.
>
>> gewesen. Und dann findet man u.a, dass eine neu installierte Version von
>> Selinux, wie das auch in meinem Fall ist, Schuld haben soll. Ich werde
>> also abwarten, ob das bald gefixt wird.
>
> Hast du SElinux denn ueberhaupt aktiviert und konfiguriert?
>
> Was sagt
> 	check-selinux-installation
> ?

| -bash: check-selinux-installation: command not found

libselinux1:i386                       2.4-3+b1

und

selinux-utils                          2.4-3+b1

sind aber installiert. Und

/selinux/enforce

hat den Wert "1".

Ich denke aber, es muss mit Selinux zu tun haben. Weil genau den Tag
zuvor ein Update kam. Weil einige Suchergebnisse das auch sagen. Und
natürlich weil ich Debian Testing habe (und es so gar nicht anders
verdient ;-).

Also abwarten.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5255

Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> Juergen P. Meier wrote on 04. March 2016:
>> Andreas Kohlbach <march.10.ankman@spamgourmet.net>:

>>> Mir ist eben auch aufgefallen, dass ich eine /usr/sbin/sendmail vom
>>> 26. Februar diesen Jahres habe. IIRC hatte ich die nie vorher. In den
>>
>> Unfug. Postfix enthaelt ein /usr/sbin/sendmail kompatibilitaets-Binary.

> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
> Mailclients sendmail erwarten?

Weil /usr/(s)bin/sendmail (und ggfls. /usr/lib/sendmail) mehr oder
weniger zur "UNIX-API" gehört. 

Programme, nicht nut MUAs, die nicht SMTP sprechen, erwarten ein
sendmail-Programm irgendwo im Pfad oder unter den oben genannten Pfaden.
Warum? Weil sendmail eben seit Urzeite der Default-Mailer für alle
Unices war und daher hat sich das so eingebürgert.

Die Linux Standard Base schreibt vor, dass /usr/sbin/sendmail zu
existieren und bestimmte Optionen zu akzeptieren hat. Also
implementieren Postfix, Exim und natürlich sendmail selbst ein solches
Programm.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5256

Sven Hartge wrote on 04. March 2016:
>
> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>> Juergen P. Meier wrote on 04. March 2016:
>
>>> Unfug. Postfix enthaelt ein /usr/sbin/sendmail kompatibilitaets-Binary.
>
>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>> Mailclients sendmail erwarten?
>
> Weil /usr/(s)bin/sendmail (und ggfls. /usr/lib/sendmail) mehr oder
> weniger zur "UNIX-API" gehört. 

Deswegen ist wohl auch (BSD) mailx noch da.

> Programme, nicht nut MUAs, die nicht SMTP sprechen, erwarten ein
> sendmail-Programm irgendwo im Pfad oder unter den oben genannten Pfaden.
> Warum? Weil sendmail eben seit Urzeite der Default-Mailer für alle
> Unices war und daher hat sich das so eingebürgert.
>
> Die Linux Standard Base schreibt vor, dass /usr/sbin/sendmail zu
> existieren und bestimmte Optionen zu akzeptieren hat. Also
> implementieren Postfix, Exim und natürlich sendmail selbst ein solches
> Programm.

Könnten Postfix und Exim nicht einfach vermutlich aber ist es nicht "so
einfach") die Sendmail Kommandozeilen-Optionen simulieren? Wenn, könnte
man auf das Sendmail Binary ganz verzichten. Und bei der Installation von
Exim, Postfix bzw. anderen, wird einfach ein Link nach /usr/sbin/sendmail
mit angelegt, der auf ihr eigenes Binary zeigt. Was auch für
/usr/lib/sendmail gelten sollte.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5257

Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> Sven Hartge wrote on 04. March 2016:

>> Die Linux Standard Base schreibt vor, dass /usr/sbin/sendmail zu
>> existieren und bestimmte Optionen zu akzeptieren hat. Also
>> implementieren Postfix, Exim und natürlich sendmail selbst ein
>> solches Programm.

> Könnten Postfix und Exim nicht einfach vermutlich aber ist es nicht
> "so einfach") die Sendmail Kommandozeilen-Optionen simulieren? Wenn,
> könnte man auf das Sendmail Binary ganz verzichten. Und bei der
> Installation von Exim, Postfix bzw. anderen, wird einfach ein Link
> nach /usr/sbin/sendmail mit angelegt, der auf ihr eigenes Binary
> zeigt. Was auch für /usr/lib/sendmail gelten sollte.

Äh, genau das wird doch gemacht. Exakt genau so:

oweh@ds9:~$ ls -al /usr/sbin/sendmail 
lrwxrwxrwx 1 root root 5 Mär  2 23:48 /usr/sbin/sendmail -> exim4

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5258

Sven Hartge schrieb:

> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
[...]
>> Könnten Postfix und Exim nicht einfach vermutlich aber ist es nicht
>> "so einfach") die Sendmail Kommandozeilen-Optionen simulieren?

Tut Postfix eh. Wurde halt in ein eigenes Binary ausgelagert.

>> Wenn,
>> könnte man auf das Sendmail Binary ganz verzichten. Und bei der
>> Installation von Exim, Postfix bzw. anderen, wird einfach ein Link
>> nach /usr/sbin/sendmail mit angelegt, der auf ihr eigenes Binary
>> zeigt. Was auch für /usr/lib/sendmail gelten sollte.
> 
> Äh, genau das wird doch gemacht. Exakt genau so:
> 
> oweh@ds9:~$ ls -al /usr/sbin/sendmail 
> lrwxrwxrwx 1 root root 5 Mär  2 23:48 /usr/sbin/sendmail -> exim4

Bei Postfix wird das nicht gemacht, zumindest nicht bei Debian:

| david@vps:~$ ls -l $(which sendmail)
| -rwxr-xr-x 1 root root 25964 Nov  4  2014 /usr/sbin/sendmail
| david@vps:~$ ls -l $(which postfix)
| -rwxr-xr-x 1 root root 9524 Nov  4  2014 /usr/sbin/postfix

-- 
David Seppi
1220 Wien

[toc] | [prev] | [next] | [standalone]

#5259

David Seppi <dseppi@a1.net> wrote:
> Sven Hartge schrieb:

>> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> [...]
>>> Könnten Postfix und Exim nicht einfach vermutlich aber ist es nicht
>>> "so einfach") die Sendmail Kommandozeilen-Optionen simulieren?

> Tut Postfix eh. Wurde halt in ein eigenes Binary ausgelagert.

>>> Wenn,
>>> könnte man auf das Sendmail Binary ganz verzichten. Und bei der
>>> Installation von Exim, Postfix bzw. anderen, wird einfach ein Link
>>> nach /usr/sbin/sendmail mit angelegt, der auf ihr eigenes Binary
>>> zeigt. Was auch für /usr/lib/sendmail gelten sollte.
>> 
>> Äh, genau das wird doch gemacht. Exakt genau so:
>> 
>> oweh@ds9:~$ ls -al /usr/sbin/sendmail 
>> lrwxrwxrwx 1 root root 5 Mär  2 23:48 /usr/sbin/sendmail -> exim4

> Bei Postfix wird das nicht gemacht, zumindest nicht bei Debian:

> | david@vps:~$ ls -l $(which sendmail)
> | -rwxr-xr-x 1 root root 25964 Nov  4  2014 /usr/sbin/sendmail
> | david@vps:~$ ls -l $(which postfix)
> | -rwxr-xr-x 1 root root 9524 Nov  4  2014 /usr/sbin/postfix

Liegt vermutlich an der Aufspaltung von Postfix in diverse Programme mit
je einem sehr spezifischen Aufgabenbereich, während Exim ja ein
monolithischer Dienst ist, wie das originale Sendmail auch.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#5260

On 2016-03-04 22:20, Sven Hartge <sh-162@svenhartge.de> wrote:
> David Seppi <dseppi@a1.net> wrote:
>> Sven Hartge schrieb:
>>> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>>>> Könnten Postfix und Exim nicht einfach vermutlich aber ist es nicht
>>>> "so einfach") die Sendmail Kommandozeilen-Optionen simulieren?
>
>> Tut Postfix eh. Wurde halt in ein eigenes Binary ausgelagert.
>
>>>> Wenn, könnte man auf das Sendmail Binary ganz verzichten.

Welchen Vorteil sollte das bringen? Man hat dann halt ein größeres,
komplexeres Binary statt zwei (oder im Fall von Postfix: Ein Dutzend)
kleinerer, einfacherer Binarys.

>>>> Und bei der Installation von Exim, Postfix bzw. anderen, wird
>>>> einfach ein Link nach /usr/sbin/sendmail mit angelegt, der auf ihr
>>>> eigenes Binary zeigt. Was auch für /usr/lib/sendmail gelten sollte.
>>> 
>>> Äh, genau das wird doch gemacht. Exakt genau so:
>>> 
>>> oweh@ds9:~$ ls -al /usr/sbin/sendmail 
>>> lrwxrwxrwx 1 root root 5 Mär  2 23:48 /usr/sbin/sendmail -> exim4
>
>> Bei Postfix wird das nicht gemacht, zumindest nicht bei Debian:
>
>> | david@vps:~$ ls -l $(which sendmail)
>> | -rwxr-xr-x 1 root root 25964 Nov  4  2014 /usr/sbin/sendmail
>> | david@vps:~$ ls -l $(which postfix)
>> | -rwxr-xr-x 1 root root 9524 Nov  4  2014 /usr/sbin/postfix
>
> Liegt vermutlich an der Aufspaltung von Postfix in diverse Programme mit
> je einem sehr spezifischen Aufgabenbereich,

Genau. /usr/sbin/postfix tut ganz was anderes als /usr/sbin/sendmail.
Letzeres als Symlink auf ersteres zu implementieren, wäre wie Firefox
als Symlink auf Apache zu implementieren. (Ok, das ist übertrieben -
aber nur ein bisschen).

> während Exim ja ein monolithischer Dienst ist, wie das originale
> Sendmail auch.

ACK. Wobei Sendmail WIMRE bereits aus mindestens zwei Executables mit
unterschiedlichen Aufgaben bestand, als ich mich das letzte mal damit
beschäftigt habe (schon ein paar Jährchen her).

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5261

begin 1 followup to Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
> Juergen P. Meier wrote on 04. March 2016:
>>
>> Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>> Ich nutze Postfix. Sendmail ist nicht installiert, zumindest nichts
>>> wissentlich. Ohne mir einer Änderung bewusst zu sein - außer die in der
>>> ~/.authinfo eines USERS, wo Postfix nichts zu suchen haben sollte -
>>> bekomme ich beim Versenden von Mails nun:
>>>
>>>| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1
>>
>> Was sagt denn das Maillog dazu?
>>
>> 	grep -i postdrop /var/log/maillog
>
>| grep: /var/log/maillog: No such file or directory
>
> Vorher war es hier /var/log/mail.info. Aber seit systemd ist es in
> journalctl aufgegangen. Was selbst nichts zu postdrop hat.

*sigh*. Bist du sicher?

DAs *MUSS* im Maillog auftauchen. Wenn systemd's journalctl das nicht
findet, dann ist systemd's journalctl kaputt.

> Der Versuch des Versendens bringt eben aber (gekürzt um Hostnamen und
> Zeitstempel) einen neuen Eintrag im Journal:

Ahja. Sehr nuetzlich so ein Log ohne Log.

>| postfix/postdrop[17908]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied

Dein postdrop darf nicht auf /etc/postfix/dynamicmaps.cf lesend zugreifen.

>| postfix/sendmail[17907]: warning: command "/usr/sbin/postdrop -r" exited with status 1
>| postfix/sendmail[17907]: fatal: ankman(1000): unable to execute /usr/sbin/postdrop -r: Success
>
> Also das, was ich schon nannte.

Nein, zwei relevante zeilen mehr. (bzw. eine relevante und eine informative)

>>> Bis gestern funktionierte es noch.
>>>
>>> Mir ist eben auch aufgefallen, dass ich eine /usr/sbin/sendmail vom
>>> 26. Februar diesen Jahres habe. IIRC hatte ich die nie vorher. In den
>>
>> Unfug. Postfix enthaelt ein /usr/sbin/sendmail kompatibilitaets-Binary.
>
> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
> Mailclients sendmail erwarten?

Ja, und viele Scripte und viele Programme.

>>> -r-xr-sr-x 1 root postdrop 10280 Feb 26 23:05 /usr/sbin/postdrop
>>
>> Ach.
>
> Nur um auszuschließen, dass die Fehlermeldung wegen falscher Dateirechte kommt.

Sie kommt wegen falscher Dateirechte, allerdings nicht am Binary
sondern am Konfig-File.

	ls -l /etc/postfix/dynamicmaps.cf

sollte Klarheit bringen. Diese Datei muss Lesbar sein fuer einen
Userprozess mit UID=GID=postdrop.

>
> libselinux1:i386                       2.4-3+b1
>
> und
>
> selinux-utils                          2.4-3+b1
>
> sind aber installiert. Und
>
> /selinux/enforce
>
> hat den Wert "1".

Dann hast du auf jeden Fall auch eine Polixy geladen. Pruefe, ob deine
Policy deinem von Postfix master Prozess gestarteten postdrop Prozess,
der seine EUID auf "postdrop" aendert das Lesen der Config-Datei
erlaubt oder verbietet.

> Ich denke aber, es muss mit Selinux zu tun haben. Weil genau den Tag
> zuvor ein Update kam. Weil einige Suchergebnisse das auch sagen. Und
> natürlich weil ich Debian Testing habe (und es so gar nicht anders
> verdient ;-).

Wenn die Posix-ACLs an der Datei das Lesen erlauben weurden, dann kann
es nur noch an SELinux liegen.

[toc] | [prev] | [next] | [standalone]

#5262

Juergen P. Meier wrote on 05. March 2016:
>
> begin 1 followup to Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>> Juergen P. Meier wrote on 04. March 2016:
>>>
>>> Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>>>
>>>>| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1
>>>
>>> Was sagt denn das Maillog dazu?
>>>
>>> 	grep -i postdrop /var/log/maillog
>>
>>| grep: /var/log/maillog: No such file or directory
>>
>> Vorher war es hier /var/log/mail.info. Aber seit systemd ist es in
>> journalctl aufgegangen. Was selbst nichts zu postdrop hat.
>
> *sigh*. Bist du sicher?

Ja. Z.B. finde ich

root adm   4895 Dec  2 07:04 /var/log/mail.log
root adm   1281 Dec  2 07:04 /var/log/mail.info

Am 1 Dezember muss systemd erneuert worden sein, und hat sich das, auch
syslog und anderes, beim nächsten Booten unter den Nagel gerissen.

> DAs *MUSS* im Maillog auftauchen. Wenn systemd's journalctl das nicht
> findet, dann ist systemd's journalctl kaputt.

AFAIK "muss" das nicht mehr auftauchen. IIRC hatte systemd gleich mal
syslogd deinstallieren wollen. Ich hatte den danach wieder installiert,
nur damit systemd den bei seinem nächsten Update wieder deinstallieren
wollte. Also habe ich systemd gewähren lassen. :-/

>> Der Versuch des Versendens bringt eben aber (gekürzt um Hostnamen und
>> Zeitstempel) einen neuen Eintrag im Journal:
>
> Ahja. Sehr nuetzlich so ein Log ohne Log.

Anderes würde ich in mail.log (oder mail.info) auch nicht erwarten.

>>| postfix/postdrop[17908]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
>
> Dein postdrop darf nicht auf /etc/postfix/dynamicmaps.cf lesend zugreifen.
>
>>| postfix/sendmail[17907]: warning: command "/usr/sbin/postdrop -r" exited with status 1
>>| postfix/sendmail[17907]: fatal: ankman(1000): unable to execute /usr/sbin/postdrop -r: Success
>>
>> Also das, was ich schon nannte.
>
> Nein, zwei relevante zeilen mehr. (bzw. eine relevante und eine informative)
>
>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>> Mailclients sendmail erwarten?
>
> Ja, und viele Scripte und viele Programme.

In der Annahme, dass die Programme und Skripte noch gepflegt werden,
sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
"sendmail Muss" raus zu werfen.

>>>> -r-xr-sr-x 1 root postdrop 10280 Feb 26 23:05 /usr/sbin/postdrop
>>>
>>> Ach.
>>
>> Nur um auszuschließen, dass die Fehlermeldung wegen falscher Dateirechte kommt.
>
> Sie kommt wegen falscher Dateirechte, allerdings nicht am Binary
> sondern am Konfig-File.
>
> 	ls -l /etc/postfix/dynamicmaps.cf
>
> sollte Klarheit bringen. Diese Datei muss Lesbar sein fuer einen
> Userprozess mit UID=GID=postdrop.

| #ls -l /etc/postfix/dynamicmaps.cf
| -rw-r----- 1 root root 319 Mar  3 08:06 /etc/postfix/dynamicmaps.cf

Ich habe die GID mal auf "postdrop" geändert, und die UID auf "root"
gelassen - einen User "postdrop" habe ich nicht... Und es
funktioniert wieder. :-)

Was mich wundert, dass die Warnung schon immer wegen der falschen
Dateirechte kam. Es aber trotzdem keine Probleme mit dem Mailversand
gab. Und warum die Dateirechte falsch waren. IIRC habe ich die selbst nie
geändert. Warum auch.

[...]

> Wenn die Posix-ACLs an der Datei das Lesen erlauben weurden, dann kann
> es nur noch an SELinux liegen.

Ich kann nur vermuten, dass Selinux strenger geworden ist seit dem
letzten Update, und die falschen Dateirechte an
/etc/postfix/dynamicmaps.cf nicht mehr durchgehen lässt. Und hätte aus
der Warnung - die ich seit Jahren habe und ignorierte - einen Fehler
machen sollen.

Danke.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5263

On 2016-03-05 20:51, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> Juergen P. Meier wrote on 05. March 2016:
>> begin 1 followup to Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>> Juergen P. Meier wrote on 04. March 2016:
>>>>
>>>> Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>>>>
>>>>>| sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1
>>>>
>>>> Was sagt denn das Maillog dazu?
>>>>
>>>> 	grep -i postdrop /var/log/maillog
>>>
>>>| grep: /var/log/maillog: No such file or directory
>>>
>>> Vorher war es hier /var/log/mail.info. Aber seit systemd ist es in
>>> journalctl aufgegangen. Was selbst nichts zu postdrop hat.
>>
>> *sigh*. Bist du sicher?
>
> Ja. Z.B. finde ich
>
> root adm   4895 Dec  2 07:04 /var/log/mail.log
> root adm   1281 Dec  2 07:04 /var/log/mail.info

Ich nehme an, Juergens Frage bezog sich auf Deine Aussage, dass
"journalctl [...] nichts zu postdrop hat". Das halte ich für eher
unwahrscheinlich. Bei mir zumindest gibt 

    journalctl -u postfix

haufenweise Meldungen von diversen Postfix-Subsystemen aus.

Und du hast ja passende Fehlermeldungen gepostet. Wo hast Du die her,
wenn Du kein syslog mehr hast und journalctl auch nichts ausspuckt?

> Am 1 Dezember muss systemd erneuert worden sein, und hat sich das, auch
> syslog und anderes, beim nächsten Booten unter den Nagel gerissen.

Das ist auf Debian-Systemen nicht normal. Ich habe mittlerweile etliche
auf Debian 8 (mit Systemd) upgegradet und die haben alle noch einen
traditionellen syslog (rsyslog in meinem Fall).

Allerdings ist es mir früher (ich glaube, beim Upgrade auf Debian 7) bei
einigen Systemen passiert, dass ich auf Grund ungünstiger Abhängigkeiten
(und zweifellos auch Unaufmerksamkeit von meiner Seite) versehentlich
den Syslogd deinstalliert habe. 

Was sagt denn 

    dpkg -l '*syslog*'

bei Dir?

>> DAs *MUSS* im Maillog auftauchen. Wenn systemd's journalctl das nicht
>> findet, dann ist systemd's journalctl kaputt.
>
> AFAIK "muss" das nicht mehr auftauchen. IIRC hatte systemd gleich mal
> syslogd deinstallieren wollen. Ich hatte den danach wieder installiert,
> nur damit systemd den bei seinem nächsten Update wieder deinstallieren
> wollte. Also habe ich systemd gewähren lassen. :-/

Syslogd deinstalliert nichts. Das macht apt oder aptitude, oder welchen
Paketmanager Du auch verwendest. Schlimmstenfalls gibt es einen Konflikt
zwischen systemd und einem der diversen Pakete, die
syslog-Funktionalitäten zur Verfügung stellen. Das sollte Dir Dein
Paketmanager aber mitgeteilt haben.


>>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>>> Mailclients sendmail erwarten?
>>
>> Ja, und viele Scripte und viele Programme.
>
> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
> "sendmail Muss" raus zu werfen.

Wozu soll das gut sein? sendmail das Standard-Unix-Kommando zum
Versenden von Mail. Genausogut könntest Du fordern, dass die Entwickler
nach Jahrzehnten mal endlich davon abgehen sollten "ls" oder "find" oder
"grep" zu verwenden.


>> Wenn die Posix-ACLs an der Datei das Lesen erlauben weurden, dann kann
>> es nur noch an SELinux liegen.
>
> Ich kann nur vermuten, dass Selinux strenger geworden ist seit dem
> letzten Update,

Ich mag ja Leute nicht, die auf eine Aussage einfach mit "Unfug"
antworten, aber hier komme ich schwer in Versuchung, das selbst zu
machen.

Wie um alles in der Welt kommst Du auf die Idee, dass das irgendwas mit
SELinux zu tun haben könnte? Dass ein Prozess, der nicht mit
Root-Rechten läuft, ein File mit den Rechten "-rw-r----- root root"
nicht lesen kann, ist doch ganz normales Unixverhalten und seit den
70er-Jahren so.

> und die falschen Dateirechte an /etc/postfix/dynamicmaps.cf nicht mehr
> durchgehen lässt.

Das wird wohl eher eine Änderung in Postfix selbst sein. Wahrscheinlich
hat Postfix früher ein unlesbares dynamicmaps.cf genauso wie ein
fehlendes behandelt. Jetzt ist es ein Fehler, was mir sehr sinnvoll
erscheint (wenn Du ein dynamicmaps.cf hast, willst Du wahrscheinlich
auch, dass Postfix es verwendet). Da Debian dieses Feature
offensichtlich vor der offiziellen Version von Postfix hatte, ist es
leicht möglich, dass sich das jetzt anders verhält.

> Und hätte aus der Warnung - die ich seit Jahren habe und ignorierte -
> einen Fehler machen sollen.

Das haben sie ja jetzt offenbar gemacht.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5269

Peter J. Holzer wrote on 05. March 2016:
>
> On 2016-03-05 20:51, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>> Juergen P. Meier wrote on 05. March 2016:
>>> begin 1 followup to Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>>>
>>>> Vorher war es hier /var/log/mail.info. Aber seit systemd ist es in
>>>> journalctl aufgegangen. Was selbst nichts zu postdrop hat.
>>>
>>> *sigh*. Bist du sicher?
>>
>> Ja. Z.B. finde ich
>>
>> root adm   4895 Dec  2 07:04 /var/log/mail.log
>> root adm   1281 Dec  2 07:04 /var/log/mail.info
>
> Ich nehme an, Juergens Frage bezog sich auf Deine Aussage, dass
> "journalctl [...] nichts zu postdrop hat". Das halte ich für eher
> unwahrscheinlich. Bei mir zumindest gibt 
>
>     journalctl -u postfix
>
> haufenweise Meldungen von diversen Postfix-Subsystemen aus.
>
> Und du hast ja passende Fehlermeldungen gepostet. Wo hast Du die her,
> wenn Du kein syslog mehr hast und journalctl auch nichts ausspuckt?

"journalctl -u postfix" nichts zu "postdrop" oder "fatal". Obwohl ich, wenn
ich alles liste

Mar 05 12:18:10 andreas postfix/postdrop[27230]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
Mar 05 12:18:11 andreas postfix/sendmail[27229]: warning: command "/usr/sbin/postdrop -r" exited with status 1
Mar 05 12:18:11 andreas postfix/sendmail[27229]: fatal: andreas(1000): unable to execute /usr/sbin/postdrop -r: Success

bekomme.

>> Am 1 Dezember muss systemd erneuert worden sein, und hat sich das, auch
>> syslog und anderes, beim nächsten Booten unter den Nagel gerissen.
>
> Das ist auf Debian-Systemen nicht normal. Ich habe mittlerweile etliche
> auf Debian 8 (mit Systemd) upgegradet und die haben alle noch einen
> traditionellen syslog (rsyslog in meinem Fall).
>
> Allerdings ist es mir früher (ich glaube, beim Upgrade auf Debian 7) bei
> einigen Systemen passiert, dass ich auf Grund ungünstiger Abhängigkeiten
> (und zweifellos auch Unaufmerksamkeit von meiner Seite) versehentlich
> den Syslogd deinstalliert habe. 
>
> Was sagt denn 
>
>     dpkg -l '*syslog*'
>
> bei Dir?

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                 Architecture            Description
+++-====================================-=======================-=======================-===========
un  libsys-syslog-perl                   <none>                  <none> (no description available)
rc  rsyslog                              8.14.0-2                i386 reliable system and kernel logging daemon
un  rsyslog-doc                          <none>                  <none>
(no description available)
un  rsyslog-gnutls                       <none>                  <none>
(no description available)
un  rsyslog-gssapi                       <none>                  <none>
(no description available)
un  rsyslog-mongodb                      <none>                  <none>
(no description available)
un  rsyslog-mysql                        <none>                  <none>
(no description available)
un  rsyslog-pgsql                        <none>                  <none>
(no description available)
un  rsyslog-relp                         <none>                  <none>
(no description available)

>>> DAs *MUSS* im Maillog auftauchen. Wenn systemd's journalctl das nicht
>>> findet, dann ist systemd's journalctl kaputt.
>>
>> AFAIK "muss" das nicht mehr auftauchen. IIRC hatte systemd gleich mal
>> syslogd deinstallieren wollen. Ich hatte den danach wieder installiert,
>> nur damit systemd den bei seinem nächsten Update wieder deinstallieren
>> wollte. Also habe ich systemd gewähren lassen. :-/
>
> Syslogd deinstalliert nichts. Das macht apt oder aptitude, oder welchen
> Paketmanager Du auch verwendest. Schlimmstenfalls gibt es einen Konflikt
> zwischen systemd und einem der diversen Pakete, die
> syslog-Funktionalitäten zur Verfügung stellen. Das sollte Dir Dein
> Paketmanager aber mitgeteilt haben.

Ich meinte nicht, dass syslogs etwas deinstalliert. IIRC hatte systemd, 
als er ein Update erfuhr, syslogs entfernt.

>>>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>>>> Mailclients sendmail erwarten?
>>>
>>> Ja, und viele Scripte und viele Programme.
>>
>> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
>> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
>> "sendmail Muss" raus zu werfen.
>
> Wozu soll das gut sein? sendmail das Standard-Unix-Kommando zum
> Versenden von Mail. Genausogut könntest Du fordern, dass die Entwickler
> nach Jahrzehnten mal endlich davon abgehen sollten "ls" oder "find" oder
> "grep" zu verwenden.

ls, grep oder find sind arg verschieden. Postfix, Exim oder Sendmail
haben dann aber doch die selbe Aufgabe. Es erscheint mir unnötig,
Sendmail haben zu müssen, wenn man Exim oder Postfix vor zieht. So lange
diese die Aufgaben von Sendmail erfüllen können. Und auch alte Programme,
die Sendmail erwarten, von Exim oder Postfix bedient werden können.

>>> Wenn die Posix-ACLs an der Datei das Lesen erlauben weurden, dann kann
>>> es nur noch an SELinux liegen.
>>
>> Ich kann nur vermuten, dass Selinux strenger geworden ist seit dem
>> letzten Update,
>
> Ich mag ja Leute nicht, die auf eine Aussage einfach mit "Unfug"
> antworten, aber hier komme ich schwer in Versuchung, das selbst zu
> machen.
>
> Wie um alles in der Welt kommst Du auf die Idee, dass das irgendwas mit
> SELinux zu tun haben könnte? Dass ein Prozess, der nicht mit
> Root-Rechten läuft, ein File mit den Rechten "-rw-r----- root root"
> nicht lesen kann, ist doch ganz normales Unixverhalten und seit den
> 70er-Jahren so.

Schon immer kamen Meldungen, wie diese:

Feb 14 19:12:37 andreas postfix/sendmail[20429]: warning: dict_open_dlinfo: cannot open /etc/postfix/dynamicmaps.cf. No dynamic maps will be allowed.

Er hat dann sehr wohl Mail verschickt. Aber warum, wenn damals vermutlich
schon "rw--r---- root root" gesetzt war?

Und es ist nur "warning", kein "fatal". Weil es doch funktionierte, habe
ich die Warning in den Wind geschlagen.

Weiter hatte ich nach einer Lösung gegoogelt, bevor ich hier fragte. Einige
Antworten nannten Selinux als möglichen Auslöser. Als ich dann mein
Update-Log für Linux durch sah, fiel mir auf, dass Selinux den Tag davor
tatsächlich geupdatet wurde! So schien es mir klar, dass es an Selinux liegen
muss.

Aber siehe unten...

>> und die falschen Dateirechte an /etc/postfix/dynamicmaps.cf nicht mehr
>> durchgehen lässt.
>
> Das wird wohl eher eine Änderung in Postfix selbst sein. Wahrscheinlich
> hat Postfix früher ein unlesbares dynamicmaps.cf genauso wie ein
> fehlendes behandelt. Jetzt ist es ein Fehler, was mir sehr sinnvoll
> erscheint (wenn Du ein dynamicmaps.cf hast, willst Du wahrscheinlich
> auch, dass Postfix es verwendet). Da Debian dieses Feature
> offensichtlich vor der offiziellen Version von Postfix hatte, ist es
> leicht möglich, dass sich das jetzt anders verhält.

Mir fällt eben erst auf, dass Postfix auch ein großes Update hatte:

| [UPGRADE] postfix:i386 2.11.3-1+b1 -> 3.0.4-5

Und im Debian.changelog.gz finde ich u.a:

| * Add back creation of /etc/postfix/dynamicmaps.cf to postfix.postinst

| * convert intalled dynamicmaps.cf, deliver a correct one, move where
|   daemons live

| * Initial merge of 3.0.3 from upstream.  Still needs packaging and
|   whatnot for shlibs and dynamic maps, which are now upstream.

>> Und hätte aus der Warnung - die ich seit Jahren habe und ignorierte -
>> einen Fehler machen sollen.
>
> Das haben sie ja jetzt offenbar gemacht.

Nein, es stand bezüglich der Dynamic Maps weiterhin nur "warning". Das
"fatal" stand in anderem Zusammenhang.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5274

On 2016-03-06 23:33, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> Peter J. Holzer wrote on 05. March 2016:
>> On 2016-03-05 20:51, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>>> Juergen P. Meier wrote on 05. March 2016:
>>>> begin 1 followup to Andreas Kohlbach <march.10.ankman@spamgourmet.net>:
>>> Am 1 Dezember muss systemd erneuert worden sein, und hat sich das, auch
>>> syslog und anderes, beim nächsten Booten unter den Nagel gerissen.
>>
>> Das ist auf Debian-Systemen nicht normal. Ich habe mittlerweile etliche
>> auf Debian 8 (mit Systemd) upgegradet und die haben alle noch einen
>> traditionellen syslog (rsyslog in meinem Fall).
>>
>> Allerdings ist es mir früher (ich glaube, beim Upgrade auf Debian 7) bei
>> einigen Systemen passiert, dass ich auf Grund ungünstiger Abhängigkeiten
>> (und zweifellos auch Unaufmerksamkeit von meiner Seite) versehentlich
>> den Syslogd deinstalliert habe. 
>>
>> Was sagt denn 
>>
>>     dpkg -l '*syslog*'
>>
>> bei Dir?
>
> Desired=Unknown/Install/Remove/Purge/Hold
>|
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>||/ Name                                 Version                 Architecture            Description
> +++-====================================-=======================-=======================-===========
> un  libsys-syslog-perl                   <none>                  <none> (no description available)
> rc  rsyslog                              8.14.0-2                i386 reliable system and kernel logging daemon

8.14? Ist das Debian Testing?

Da solltest Du damit rechnen, dass manchmal etwas nicht richtig
funktioniert, und die notwendige Umsicht und Expertise aufbringen, das
dann wieder zu reparieren.

In Debian Stable kommen rsyslog und systemd jedenfalls miteinander aus.


>>>> DAs *MUSS* im Maillog auftauchen. Wenn systemd's journalctl das nicht
>>>> findet, dann ist systemd's journalctl kaputt.
>>>
>>> AFAIK "muss" das nicht mehr auftauchen. IIRC hatte systemd gleich mal
>>> syslogd deinstallieren wollen. Ich hatte den danach wieder installiert,
>>> nur damit systemd den bei seinem nächsten Update wieder deinstallieren
>>> wollte. Also habe ich systemd gewähren lassen. :-/
>>
>> Syslogd deinstalliert nichts. Das macht apt oder aptitude, oder welchen
   ^^^^^^^ Sorry, sollte "systemd" heißen.
>> Paketmanager Du auch verwendest. Schlimmstenfalls gibt es einen Konflikt
>> zwischen systemd und einem der diversen Pakete, die
>> syslog-Funktionalitäten zur Verfügung stellen. Das sollte Dir Dein
>> Paketmanager aber mitgeteilt haben.
>
> Ich meinte nicht, dass syslogs etwas deinstalliert. IIRC hatte systemd, 
> als er ein Update erfuhr, syslogs entfernt.

Nein, der systemd deinstalliert keine Pakete. Das macht apt. Mach Dich
bitte mit den Grundlagen der Paketverwaltung vertraut, vor allem, wenn
Du Debian Testing verwendest.



>>>>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>>>>> Mailclients sendmail erwarten?
>>>>
>>>> Ja, und viele Scripte und viele Programme.
>>>
>>> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
>>> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
>>> "sendmail Muss" raus zu werfen.
>>
>> Wozu soll das gut sein? sendmail das Standard-Unix-Kommando zum
>> Versenden von Mail. Genausogut könntest Du fordern, dass die Entwickler
>> nach Jahrzehnten mal endlich davon abgehen sollten "ls" oder "find" oder
>> "grep" zu verwenden.
>
> ls, grep oder find sind arg verschieden.

Ich meinte, nicht, dass man die drei zusammenfassen soll, sondern dass
man die offenbar Deiner Meinung nach alle wegschmeißen und durch
inkompatible Kommandos ersetzen soll. Also statt auf jedem System ein
Kommando namens "find" zu haben, gibt es auf einem ein "gnu-find", am
anderen ein "busybox-find", am dritten ein "search", etc.


> Postfix, Exim oder Sendmail
> haben dann aber doch die selbe Aufgabe. Es erscheint mir unnötig,
> Sendmail haben zu müssen, wenn man Exim oder Postfix vor zieht.

Niemand muss das Paket "Sendmail" haben, der Postfix vorzieht. Das Paket
Postfix enthält viele Programme, darunter auch eines, das "sendmail"
heißt. So wie das Paket "GNU Core Utilities" ein Programm namens "ls"
enthält.

Dieses Programm sendmail, das Teil von Postfix ist, hat nichts mit dem
Paket "Sendmail" zu tun. Es ist eine vollständig eigene Implementation
und hat auch nicht den gleichen Funktionsumfang wie das gleichnamige
Programm aus dem Paket "Sendmail", sondern nur ein Subset davon.
Natürlich könnte man dieses Programm auch "postsend" nennen und dann
einen Symlink sendmail -> postsend anlegen, aber wozu sollte das gut
sein? Wenn man ein Programm namens "sendmail" braucht, dann nennt man es
sinnvollerweise gleich "sendmail" und kaspert nicht mit Symlinks herum.

(Manchmal ist es sinnvoll, mehrere Alternativimplementationen parallel
installierbar zu machen, z.B. könnte es Gründe geben, warum jemand
sowohl vim als auch nvi installieren möchte. Dann ist ein Symlink vi
einen gute Sache. Aber z.B. Postfix und Exim am gleichen System
gleichzeitig installieren zu wollen, dürfte ein ziemliches
Minderheitenprogramm sein - darüber machen sich zurecht weder die
Autoren von Exim und Postfix, noch die Debian-Maintainer Gedanken)


>>>> Wenn die Posix-ACLs an der Datei das Lesen erlauben weurden, dann kann
>>>> es nur noch an SELinux liegen.
>>>
>>> Ich kann nur vermuten, dass Selinux strenger geworden ist seit dem
>>> letzten Update,
>>
>> Ich mag ja Leute nicht, die auf eine Aussage einfach mit "Unfug"
>> antworten, aber hier komme ich schwer in Versuchung, das selbst zu
>> machen.
>>
>> Wie um alles in der Welt kommst Du auf die Idee, dass das irgendwas mit
>> SELinux zu tun haben könnte? Dass ein Prozess, der nicht mit
>> Root-Rechten läuft, ein File mit den Rechten "-rw-r----- root root"
>> nicht lesen kann, ist doch ganz normales Unixverhalten und seit den
>> 70er-Jahren so.
>
> Schon immer kamen Meldungen, wie diese:
>
> Feb 14 19:12:37 andreas postfix/sendmail[20429]: warning: dict_open_dlinfo: cannot open /etc/postfix/dynamicmaps.cf. No dynamic maps will be allowed.
>
> Er hat dann sehr wohl Mail verschickt. Aber warum, wenn damals vermutlich
> schon "rw--r---- root root" gesetzt war?
>
> Und es ist nur "warning", kein "fatal". Weil es doch funktionierte, habe
> ich die Warning in den Wind geschlagen.

Willst Du Dir nicht wenigstens im gleichen Posting nicht widersprechen?
Weiter oben hast Du geschrieben:

> Mar 05 12:18:10 andreas postfix/postdrop[27230]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied

Da steht ziemlich eindeutig "fatal".


> Weiter hatte ich nach einer Lösung gegoogelt, bevor ich hier fragte. Einige
> Antworten nannten Selinux als möglichen Auslöser.

Klar kann das ein möglicher Auslöser sein. Aber wenn Du Dir jemals auch
nur die Grundlagen von Unix-Permissions angeeignet hast, dann muss Dir
klar sein, dass mit den Permissions "rw--r---- root root" das File für
einen unprivilegierten Prozess mit oder ohne SELinux nicht lesbar ist.
SELinux macht hier also genau gar keinen Unterschied (eine Permission,
die nicht da ist, kann es auch nicht mehr wegnehmen) und kann daher in
diesem Fall nicht schuld sein.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5277

Peter J. Holzer wrote on 07. March 2016:
>
> On 2016-03-06 23:33, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>> Peter J. Holzer wrote on 05. March 2016:
>>
>> Desired=Unknown/Install/Remove/Purge/Hold
>>|
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>>||/ Name                                 Version                 Architecture            Description
>> +++-====================================-=======================-=======================-===========
>> un  libsys-syslog-perl                   <none>                  <none> (no description available)
>> rc  rsyslog                              8.14.0-2                i386 reliable system and kernel logging daemon
>
> 8.14? Ist das Debian Testing?

Ja. Und ja, das ist bereits ein Fehler, es laufen zu haben. ;-)

> Da solltest Du damit rechnen, dass manchmal etwas nicht richtig
> funktioniert, und die notwendige Umsicht und Expertise aufbringen, das
> dann wieder zu reparieren.
>
> In Debian Stable kommen rsyslog und systemd jedenfalls miteinander aus.

Ich weiß. Lief ja. Aber bei zwei Updates von systemd wollte er syslog
deinstalliert haben. Das wird auf die Dauer langweilig, wenn ich es dann
jedes mal unterbinden oder neu installieren wollte.

>>> Syslogd deinstalliert nichts. Das macht apt oder aptitude, oder welchen
>    ^^^^^^^ Sorry, sollte "systemd" heißen.
>>> Paketmanager Du auch verwendest. Schlimmstenfalls gibt es einen Konflikt
>>> zwischen systemd und einem der diversen Pakete, die
>>> syslog-Funktionalitäten zur Verfügung stellen. Das sollte Dir Dein
>>> Paketmanager aber mitgeteilt haben.
>>
>> Ich meinte nicht, dass syslogs etwas deinstalliert. IIRC hatte systemd, 
>> als er ein Update erfuhr, syslogs entfernt.
>
> Nein, der systemd deinstalliert keine Pakete. Das macht apt. Mach Dich
> bitte mit den Grundlagen der Paketverwaltung vertraut, vor allem, wenn
> Du Debian Testing verwendest.

Ich weiss. Ich hätte sagen sollen "Die Maintainer von systemd wollen, dass
syslog deinstalliert wird". Und der Paketmanager schlägt das aus dem
Grund eben vor.

Muss man euch immer alles 100%ig genau schreiben?

>>>> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
>>>> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
>>>> "sendmail Muss" raus zu werfen.
>>>
>>> Wozu soll das gut sein? sendmail das Standard-Unix-Kommando zum
>>> Versenden von Mail. Genausogut könntest Du fordern, dass die Entwickler
>>> nach Jahrzehnten mal endlich davon abgehen sollten "ls" oder "find" oder
>>> "grep" zu verwenden.
>>
>> ls, grep oder find sind arg verschieden.
>
> Ich meinte, nicht, dass man die drei zusammenfassen soll, sondern dass
> man die offenbar Deiner Meinung nach alle wegschmeißen und durch
> inkompatible Kommandos ersetzen soll.

Wie kommst du da drauf?

> Also statt auf jedem System ein Kommando namens "find" zu haben, gibt
> es auf einem ein "gnu-find", am anderen ein "busybox-find", am dritten
> ein "search", etc.

Nein, so lange ein Programm nicht die Schnittstellen (Optionen, Kommandos
etc.) bietet, was Althergebrachtes erwartet, sollte man das *nicht* tun.

>> Postfix, Exim oder Sendmail
>> haben dann aber doch die selbe Aufgabe. Es erscheint mir unnötig,
>> Sendmail haben zu müssen, wenn man Exim oder Postfix vor zieht.
>
> Niemand muss das Paket "Sendmail" haben, der Postfix vorzieht. Das Paket
> Postfix enthält viele Programme, darunter auch eines, das "sendmail"
> heißt. So wie das Paket "GNU Core Utilities" ein Programm namens "ls"
> enthält.
>
> Dieses Programm sendmail, das Teil von Postfix ist, hat nichts mit dem
> Paket "Sendmail" zu tun. Es ist eine vollständig eigene Implementation
> und hat auch nicht den gleichen Funktionsumfang wie das gleichnamige
> Programm aus dem Paket "Sendmail", sondern nur ein Subset davon.

Ich sehe auch gerade, dass das Programm mit gut 20 KB auch recht klein
ist. Da hatte ich neulich gar nicht drauf geachtet - nur getestet, was
für eine Datei das ist.

Es scheint also nur ein "Wrapper" für Postfix zu sein? Dann soll es gut
sein.

> Natürlich könnte man dieses Programm auch "postsend" nennen und dann
> einen Symlink sendmail -> postsend anlegen, aber wozu sollte das gut
> sein? Wenn man ein Programm namens "sendmail" braucht, dann nennt man es
> sinnvollerweise gleich "sendmail" und kaspert nicht mit Symlinks herum.

Damit man Leute, wie mich,nicht durcheinander bringt, und das Usenet
voll schreiben. ;-)

[...]

>> Feb 14 19:12:37 andreas postfix/sendmail[20429]: warning: dict_open_dlinfo: cannot open /etc/postfix/dynamicmaps.cf. No dynamic maps will be allowed.
>>
>> Er hat dann sehr wohl Mail verschickt. Aber warum, wenn damals vermutlich
>> schon "rw--r---- root root" gesetzt war?
>>
>> Und es ist nur "warning", kein "fatal". Weil es doch funktionierte, habe
>> ich die Warning in den Wind geschlagen.
>
> Willst Du Dir nicht wenigstens im gleichen Posting nicht widersprechen?
> Weiter oben hast Du geschrieben:
>
>> Mar 05 12:18:10 andreas postfix/postdrop[27230]: fatal: /etc/postfix/dynamicmaps.cf: file open failed: Permission denied
>
> Da steht ziemlich eindeutig "fatal".

Stimmt. Vielleicht sollte ich lesen, was da steht, nicht vermuten dass
ich weiß, was da steht. :-(

[...]
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5278

Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>Peter J. Holzer wrote on 07. March 2016:
>>
>> On 2016-03-06 23:33, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>>> Peter J. Holzer wrote on 05. March 2016:
>>>
>>> Desired=Unknown/Install/Remove/Purge/Hold
>>>|
>>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>>>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>>>||/ Name                                 Version                 Architecture            Description
>>> +++-====================================-=======================-=======================-===========
>>> un  libsys-syslog-perl                   <none>                  <none> (no description available)
>>> rc  rsyslog                              8.14.0-2                i386 reliable system and kernel logging daemon
>>
>> 8.14? Ist das Debian Testing?
>
>Ja. Und ja, das ist bereits ein Fehler, es laufen zu haben. ;-)

Wenn man sich so anstellt wie Du, sollte man halt keine unreleaste
Entwicklerversion verwenden. Du bist doch nicht erst seit gestern
dabei, es ist mir zunehmend unklar, wie Du die ganzen Jahre
klargekommen bist.

>> Nein, der systemd deinstalliert keine Pakete. Das macht apt. Mach Dich
>> bitte mit den Grundlagen der Paketverwaltung vertraut, vor allem, wenn
>> Du Debian Testing verwendest.
>
>Ich weiss. Ich hätte sagen sollen "Die Maintainer von systemd wollen, dass
>syslog deinstalliert wird". Und der Paketmanager schlägt das aus dem
>Grund eben vor.

Wo steht, dass sie das wollen?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#5281

Marc Haber wrote on 08. March 2016:
>
> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>>Peter J. Holzer wrote on 07. March 2016:
>>>
>>> 8.14? Ist das Debian Testing?
>>
>>Ja. Und ja, das ist bereits ein Fehler, es laufen zu haben. ;-)
>
> Wenn man sich so anstellt wie Du, sollte man halt keine unreleaste
> Entwicklerversion verwenden. Du bist doch nicht erst seit gestern
> dabei, es ist mir zunehmend unklar, wie Du die ganzen Jahre
> klargekommen bist.

Ich habe wenig Probleme mit Testing, dass die Vorteile (bleeding edge
Software) für mich überwiegen.

>>> Nein, der systemd deinstalliert keine Pakete. Das macht apt. Mach Dich
>>> bitte mit den Grundlagen der Paketverwaltung vertraut, vor allem, wenn
>>> Du Debian Testing verwendest.
>>
>>Ich weiss. Ich hätte sagen sollen "Die Maintainer von systemd wollen, dass
>>syslog deinstalliert wird". Und der Paketmanager schlägt das aus dem
>>Grund eben vor.
>
> Wo steht, dass sie das wollen?

Wenn systemd ein Update hat, stand es zur Abwahl. Zwei Mal
schon. Irgendein dependency Problem, an das ich mich nicht mehr erinnere.

Ich habe rsyslog eben trotzdem noch einmal neu installiert. Wenn systemd
das bei einem seiner nächsten Updates wieder entfernen will, werde ich
Details hier wissen lassen.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5264

Mahlzeit!

Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:

>>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>>> Mailclients sendmail erwarten?
>>
>> Ja, und viele Scripte und viele Programme.
> 
> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
> "sendmail Muss" raus zu werfen.

Aber wie sollen die Programme und Skripte dann Mails verschicken?

Die können ja nicht für jeden installierten Mailserver umgeschrieben
werden (Mail über exim senden, Mail über postfix senden, Mail über
qmail senden, Mail über…).

Genau dafür hat man sich auf /usr/bin/sendmail bzw. /usr/lib/sendmail
geeinigt.

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
There's a new tool that MS has recently retroactively invented:
Kerberos. It came out last year, and I've used it since 1993 or so.
                -- Chuck Yerkes sage-member list

[toc] | [prev] | [next] | [standalone]

#5270

Christian Garbs wrote on 05. March 2016:
>
> Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
>
>>>> Wozu soll das gut sein, wenn Postfix sendmail mit bringt? Weil viele alte
>>>> Mailclients sendmail erwarten?
>>>
>>> Ja, und viele Scripte und viele Programme.
>> 
>> In der Annahme, dass die Programme und Skripte noch gepflegt werden,
>> sollten die Entwickler IMO nach nun Jahrzehnten dazu übergehen, das
>> "sendmail Muss" raus zu werfen.
>
> Aber wie sollen die Programme und Skripte dann Mails verschicken?
>
> Die können ja nicht für jeden installierten Mailserver umgeschrieben
> werden (Mail über exim senden, Mail über postfix senden, Mail über
> qmail senden, Mail über…).
>
> Genau dafür hat man sich auf /usr/bin/sendmail bzw. /usr/lib/sendmail
> geeinigt.

*Wenn* ein anderer MTA auch die Syntax von sendmail beherrscht - sonst
könnte man es dem in einem Update beibringen:

ln -s /usr/sbin/postfix /usr/sbin/sendmail
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often
as I have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#5275

On 2016-03-06 23:36, Andreas Kohlbach <march.10.ankman@spamgourmet.net> wrote:
> Christian Garbs wrote on 05. March 2016:
>> Aber wie sollen die Programme und Skripte dann Mails verschicken?
>>
>> Die können ja nicht für jeden installierten Mailserver umgeschrieben
>> werden (Mail über exim senden, Mail über postfix senden, Mail über
>> qmail senden, Mail über…).
>>
>> Genau dafür hat man sich auf /usr/bin/sendmail bzw. /usr/lib/sendmail
>> geeinigt.
>
> *Wenn* ein anderer MTA auch die Syntax von sendmail beherrscht

Tut es ja.

> - sonst könnte man es dem in einem Update beibringen:

Ich versuche jetzt nicht, in diesem Halbsatz einen Sinn zu entdecken.

> ln -s /usr/sbin/postfix /usr/sbin/sendmail

Magst Du nicht einmal ins Manual schauen, bevor Du solchen Unsinn
postest? /usr/sbin/postfix tut ganz was anderes als /usr/sbin/sendmail.
Du wurdest von mehreren Leuten mehrmals darauf hingewiesen, dass Postfix
ein modulares System ist, das aus mehreren Programmen besteht. Es gibt
kein einzelnes "postfix"-Binary, das alle Aufgaben eines Mailsystems
übernimmt.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comm.software.mailserver

csiph-web