Re: Problems migrating CentOS 6

2011-07-25 Thread Wietse Venema
Jonathan Gazeley:
 I've been running a postfix server on CentOS 5 for a while with no 
 problem. I set up a new CentOS 6 box with postfix, and basically 
 transplanted my configs across to the new one. The service starts, but 
 doesn't work properly: it doesn't accept email on 25 or 587 (TLS), but 
 instead this appears in the maillog:
 
 Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database 
 /etc/postfix/virtual.db: No such file or directory
 Jul 25 17:12:44 helios postfix/master[14239]: warning: process 
 /usr/libexec/postfix/smtpd pid 14436 exit status 1
 Jul 25 17:12:44 helios postfix/master[14239]: warning: 
 /usr/libexec/postfix/smtpd: bad command startup -- throttling
 
 
 I do have a virtual.db, though. I deleted all my *.db and recreated them 
 with postmap to ensure they were OK. The ownership and perms seem OK:
 
 [root@helios postfix]# ls -la virtual.db
 -rw-r--r--. 1 root mail 12288 Jul 25 17:05 virtual.db
 
 SELinux is disabled on this system, so it's not an obscure issue with 
 security contexts and mislabelling.
 
 Am I missing something?

Try turning off chroot. It is a magic cure for mysterious errors.

http://www.postfix.org/DEBUG_README.html#no_chroot

Wietse


Re: Problems migrating CentOS 6

2011-07-25 Thread Jonathan Gazeley

On 07/25/2011 05:42 PM, Wietse Venema wrote:

Jonathan Gazeley:

I've been running a postfix server on CentOS 5 for a while with no
problem. I set up a new CentOS 6 box with postfix, and basically
transplanted my configs across to the new one. The service starts, but
doesn't work properly: it doesn't accept email on 25 or 587 (TLS), but
instead this appears in the maillog:

Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database
/etc/postfix/virtual.db: No such file or directory
Jul 25 17:12:44 helios postfix/master[14239]: warning: process
/usr/libexec/postfix/smtpd pid 14436 exit status 1
Jul 25 17:12:44 helios postfix/master[14239]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling


I do have a virtual.db, though. I deleted all my *.db and recreated them
with postmap to ensure they were OK. The ownership and perms seem OK:

[root@helios postfix]# ls -la virtual.db
-rw-r--r--. 1 root mail 12288 Jul 25 17:05 virtual.db

SELinux is disabled on this system, so it's not an obscure issue with
security contexts and mislabelling.

Am I missing something?


Try turning off chroot. It is a magic cure for mysterious errors.

http://www.postfix.org/DEBUG_README.html#no_chroot


Thanks for the tip. Chroot is already turned off for all components in 
master.cf, though.





Wietse




Re: Problems migrating CentOS 6

2011-07-25 Thread Wietse Venema
Jonathan Gazeley:
  Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database
  /etc/postfix/virtual.db: No such file or directory
 
  I do have a virtual.db, though. I deleted all my *.db and recreated them
  with postmap to ensure they were OK. The ownership and perms seem OK:
 
  [root@helios postfix]# ls -la virtual.db
  -rw-r--r--. 1 root mail 12288 Jul 25 17:05 virtual.db

Another possibility is that Berkeley DB returns an ENOENT error for
reasons other than that the file does not exist.

For example, I recall that an early version of ReiserFS returning
ENOENT errors on an open file handle because they could not find
something. In that case, the OS kernel returned an ENOENT even
though the file could be opened.

However, if postmap -s /etc/postfix/virtual can read the file
as root, but smtpd cannot open the file as root before it drops
privileges, then I suspect a security configuration error, like,
perhaps SeLinux is not turned off after all.

Look in your system/security logs.

Wietse


Re: Problems migrating CentOS 6

2011-07-25 Thread Jonathan Gazeley

On 07/25/2011 06:12 PM, Wietse Venema wrote:

Jonathan Gazeley:

Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database
/etc/postfix/virtual.db: No such file or directory

I do have a virtual.db, though. I deleted all my *.db and recreated them
with postmap to ensure they were OK. The ownership and perms seem OK:

[root@helios postfix]# ls -la virtual.db
-rw-r--r--. 1 root mail 12288 Jul 25 17:05 virtual.db


Another possibility is that Berkeley DB returns an ENOENT error for
reasons other than that the file does not exist.

For example, I recall that an early version of ReiserFS returning
ENOENT errors on an open file handle because they could not find
something. In that case, the OS kernel returned an ENOENT even
though the file could be opened.

However, if postmap -s /etc/postfix/virtual can read the file
as root, but smtpd cannot open the file as root before it drops
privileges, then I suspect a security configuration error, like,
perhaps SeLinux is not turned off after all.

Look in your system/security logs.


Odd. Until now I had been doing postmap /etc/postfix/virtual (without 
-s). Since I saw your email, I tried it with -s, it returned the same 
error message on the first occasion, but worked thereafter. The mail 
system seems to work now - thanks.


Cheers,
Jonathan



Re: Problems migrating CentOS 6

2011-07-25 Thread Bastian Blank
On Mon, Jul 25, 2011 at 05:20:07PM +0100, Jonathan Gazeley wrote:
 [root@helios postfix]# ls -la virtual.db
 -rw-r--r--. 1 root mail 12288 Jul 25 17:05 virtual.db

This file have security attributes assigned.

 SELinux is disabled on this system, so it's not an obscure issue
 with security contexts and mislabelling.

This does not match the output above. If selinux is disabled, a new file
would not get a tag.

Bastian

-- 
Get back to your stations!
We're beaming down to the planet, sir.
-- Kirk and Mr. Leslie, This Side of Paradise,
   stardate 3417.3


Re: Problems migrating CentOS 6

2011-07-25 Thread Victor Duchovni
On Mon, Jul 25, 2011 at 05:20:07PM +0100, Jonathan Gazeley wrote:

 I've been running a postfix server on CentOS 5 for a while with no problem. 
 I set up a new CentOS 6 box with postfix, and basically transplanted my 
 configs across to the new one. The service starts, but doesn't work 
 properly: it doesn't accept email on 25 or 587 (TLS), but instead this 
 appears in the maillog:

 Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database 
 /etc/postfix/virtual.db: No such file or directory
 Jul 25 17:12:44 helios postfix/master[14239]: warning: process 
 /usr/libexec/postfix/smtpd pid 14436 exit status 1
 Jul 25 17:12:44 helios postfix/master[14239]: warning: 
 /usr/libexec/postfix/smtpd: bad command startup -- throttling


 I do have a virtual.db, though. I deleted all my *.db and recreated them 
 with postmap to ensure they were OK. The ownership and perms seem OK:

My guess (you neither provide postconf -n output, nor specify what
postmap incantation was used to create the virtual.db file) is that
the .db files in question may not of the expected dictionary type.
Perhaps they're hash instead of btree, or btree instead of hash.

Another possibility is that the postmap(1) binary in question is linked
with a different Berkeley DB library than smtpd(8) (mixed Postfix install
with admin utilities in sbin from a different Postfix version than the
libexec daemons).

-- 
Viktor.


Re: Problems migrating CentOS 6

2011-07-25 Thread Wietse Venema
Victor Duchovni:
 On Mon, Jul 25, 2011 at 05:20:07PM +0100, Jonathan Gazeley wrote:
 
  I've been running a postfix server on CentOS 5 for a while with no problem. 
  I set up a new CentOS 6 box with postfix, and basically transplanted my 
  configs across to the new one. The service starts, but doesn't work 
  properly: it doesn't accept email on 25 or 587 (TLS), but instead this 
  appears in the maillog:
 
  Jul 25 17:12:43 helios postfix/smtpd[14436]: fatal: open database 
  /etc/postfix/virtual.db: No such file or directory
  Jul 25 17:12:44 helios postfix/master[14239]: warning: process 
  /usr/libexec/postfix/smtpd pid 14436 exit status 1
  Jul 25 17:12:44 helios postfix/master[14239]: warning: 
  /usr/libexec/postfix/smtpd: bad command startup -- throttling
 
 
  I do have a virtual.db, though. I deleted all my *.db and recreated them 
  with postmap to ensure they were OK. The ownership and perms seem OK:
 
 My guess (you neither provide postconf -n output, nor specify what
 postmap incantation was used to create the virtual.db file) is that
 the .db files in question may not of the expected dictionary type.
 Perhaps they're hash instead of btree, or btree instead of hash.
 
 Another possibility is that the postmap(1) binary in question is linked
 with a different Berkeley DB library than smtpd(8) (mixed Postfix install
 with admin utilities in sbin from a different Postfix version than the
 libexec daemons).

As of Postfix 2.4, all binaries are stamped with version information:

% strings /usr/libexec/postfix/* /usr/sbin/post* /usr/sbin/sendmail | 
grep mail_version= | sort | uniq -c
41 mail_version=2.9-20110706

All 41 program files have the same version.

Maybe we should also bury the compile-time options (the EXPORT
string in $config_directory/makedefs.out) information into the
executables and examine them with a similar query as above:

% strings [files] | egrep '(mail_version|build_info)=' | sort | uniq -c

The output should then be the same for all program files.

Another idea is to add a -F (fingerprint) command-line option to
every executable that dumps mail_version and build_info information.
Some people may not be comfortable with egrep and such.

Wietse


Re: Problems migrating CentOS 6

2011-07-25 Thread Wietse Venema
Victor Duchovni:
 On Mon, Jul 25, 2011 at 03:52:31PM -0400, Wietse Venema wrote:
 
  Another idea is to add a -F (fingerprint) command-line option to
  every executable that dumps mail_version and build_info information.
  Some people may not be comfortable with egrep and such.
 
 If we're to go to all the trouble, likely the -F approach seems to
 make more sense.
 
 On the other hand, with Debian builds where libglobal, ... are separate
 shared libraries, do we fingerprint libglobal, or the calling executable?
 (Do we call a function in the library or clone it into each executable).

Taking the example from SASL and Berkeley DB, the library should
have a version() function whose output can be checked against
compile-time #defines; if the compile time version does not match
the run-time linked version, the warranty is void.

This means that people can no longer safely do make upgrade on a
running Postfix system, even if it is just a patchlevel change,
because postfix-internal function interfaces sometimes change. This
makes internal interface changes much more visible.

 Ebedding static variables into each executable unasks the question,
 and we can also include similar statics in each library.
 
 All this said, I doubt it is worth the effort. The existing fingerprints
 are probably enough.

The odds of the same version installed with different build options
is quite small.

Wietse


Re: Problems migrating CentOS 6

2011-07-25 Thread Victor Duchovni
On Mon, Jul 25, 2011 at 04:44:25PM -0400, Wietse Venema wrote:

  All this said, I doubt it is worth the effort. The existing fingerprints
  are probably enough.
 
 The odds of the same version installed with different build options
 is quite small.

That's essentially my view.

-- 
Viktor.