Zhiqiang::He: 有关Postfix 的虚拟用户支持的大讨论

« 对qmgr_message_active_limit 与 default_process_limit的高级分析 | Main | 为实现大容量邮件系统所设计LDAP ldif 的构思 »

版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。
本文网址：http://www.hzqbbc.com/blog/arch/2002/11/postfix_ceccee.html

November 11, 2002

有关Postfix 的虚拟用户支持的大讨论

--------------
Message 1 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 02:43:07 PST

I am trying to virtualize the users on a new mail server.
What I mean by that is that the user names will not be listed
in the /etc/passwd file. There is another file which looks
like the first 2 fields of /etc/passwd or /etc/shadow which
contains the list of valid users. The main question is how
might I get Postfix to check this file for known users?

I do have the option to make this be virtual or not virtual
since this mail server is serving only one space of usernames
(that is, xyzzy@foo and xyzzy@bar are the same mailbox and
same user). But I have been looking through the various ways
to configure either approach and I simply don't find a way to
do this. Mail is being delivered OK, and picked up OK using
vm-pop3d as the pop3 server (which reads the alternate file
to get user passwords). So once I can get Postfix to know
the users are existing (if they are in that file), then it
should all be working.

I definitely do not want to add these users to /etc/passwd or
/etc/shadow. There are conflicts between the user space for
mail and the user space for shell logins (which have no local
mail), so this isn't an option.

I also want to avoid (means if there is no other way, then this
can be done, but I definitely want to exhaust all other possible
approaches first) having a separate file to maintain just for
Postfix to do user lookups. Basically this means if there is
a way to use the shadow file format, that's preferred, but any
map format Postfix can handle will do as a last resort.

No single configuration description pops out at me and says this
will do what I want. And I can't see any combinations that
might create the same effect. Anyone have any ideas on this?

Note that there is no virtual translation. User "xyzzy" has a
mailbox named "xyzzy" in (via symlink) /var/spool/mail in the
traditional mailbox format.

To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 2 in thread
寄件者：Jean-Pierre Schwickerath (lists@schwicky.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 03:03:54 PST

Phil Howard wrote:

> What I mean by that is that the user names will not be listed
> in the /etc/passwd file. There is another file which looks
> like the first 2 fields of /etc/passwd or /etc/shadow which
> contains the list of valid users. The main question is how
> might I get Postfix to check this file for known users?

There is a parameter called local_recipient_maps
cut
local_recipient_maps = $alias_maps unix:passwd.byname
cut

There you could add your file(s) in any format that postfix
understands...

Jean-Pierre

--
Powered by Linux From Scratch - http://schwicky.net
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 3 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 04:41:46 PST

On Mon, Jul 01, 2002 at 12:02:14PM +0200, Jean-Pierre Schwickerath wrote:

│ Phil Howard wrote:
│
│ > What I mean by that is that the user names will not be listed
│ > in the /etc/passwd file. There is another file which looks
│ > like the first 2 fields of /etc/passwd or /etc/shadow which
│ > contains the list of valid users. The main question is how
│ > might I get Postfix to check this file for known users?
│
│ There is a parameter called local_recipient_maps
│ cut
│ local_recipient_maps = $alias_maps unix:passwd.byname
│ cut
│
│ There you could add your file(s) in any format that postfix
│ understands...

So what do I put there to make it understand /etc/passwd format?
Is there a document or man page that lists all the formats?

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 4 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 07:57:36 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> I am trying to virtualize the users on a new mail server.
> What I mean by that is that the user names will not be listed
> in the /etc/passwd file. There is another file which looks
> like the first 2 fields of /etc/passwd or /etc/shadow which
> contains the list of valid users. The main question is how
> might I get Postfix to check this file for known users?

This is the wrong question. The right question is:

What delivery agent and POP/IMAP server combination should I use to
deliver mail to users without a shell account (not listed in /etc/passwd)?

For a specific choice of delivery agent and POP/IMAP server, what is the
best way to manage the virtual user account information?

Is it possible to enter the virtual user accounts into just one
database that will be used by all components ("smtpd" user validation,
delivery agent, POP/IMAP server)?

The most important factor is your choice of POP/IMAP server. Some can be
integrated tightly with Postfix and some cannot.

Your best bet is likely (I am not an expert on this topic, this is
my impression from recent posts to the list) Courier IMAP. There is a
patch for Postfix to enable it to use "userdb" as a Postfix map type.
Check some of the Courier HOWTO documents recently advertised on the list.
If none provide sufficient detail, perhaps someone can volunteer the
missing recipes.

Postfix has no support for "password-like" maps except /etc/passwd
accessed via getpwnam(3).

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users
View: Complete Thread (36 articles)
Original Format
新闻群组：mailing.postfix.users
日期：2002-07-01 08:55:35 PST

On Mon, Jul 01, 2002 at 10:56:21AM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Mon, 1 Jul 2002, Phil Howard wrote:
│
│ > I am trying to virtualize the users on a new mail server.
│ > What I mean by that is that the user names will not be listed
│ > in the /etc/passwd file. There is another file which looks
│ > like the first 2 fields of /etc/passwd or /etc/shadow which
│ > contains the list of valid users. The main question is how
│ > might I get Postfix to check this file for known users?
│
│ This is the wrong question. The right question is:
│
│ What delivery agent and POP/IMAP server combination should I use to
│ deliver mail to users without a shell account (not listed in /etc/passwd)?

The POP server is already chosen.

The answer to this question will be interesting for the next project.
But there is a different set of requirements for that one. I can post
them if you would like to offer advice on that.

│ For a specific choice of delivery agent and POP/IMAP server, what is the
│ best way to manage the virtual user account information?
│
│ Is it possible to enter the virtual user accounts into just one
│ database that will be used by all components ("smtpd" user validation,
│ delivery agent, POP/IMAP server)?
│
│
│ The most important factor is your choice of POP/IMAP server. Some can be
│ integrated tightly with Postfix and some cannot.
│
│ Your best bet is likely (I am not an expert on this topic, this is
│ my impression from recent posts to the list) Courier IMAP. There is a
│ patch for Postfix to enable it to use "userdb" as a Postfix map type.
│ Check some of the Courier HOWTO documents recently advertised on the list.
│ If none provide sufficient detail, perhaps someone can volunteer the
│ missing recipes.

Courier IMAP did not meet migration requirements for this server.
Mailbox format is required in this case so that user mail is not
lost. I will be using rsync to syncronize the mailboxes from the
old machine to the new one, then transfer IP addresses and restart.

The POP server used is vm-pop3d. It is past the time to allocate
the additional time to change the software used or to work out the
strategy to change from mailbox to maildir format. Physical move of
servers takes place 13 July. The migration must take place at the
maintenance window allocated for least user disruption.

For another project as mentioned above, Courier IMAP appears to be
a good choice. I don't know what you mean by "userdb", but then I
haven't gotten to the point of fully RTFM-ing Courier IMAP, yet.
Maybe this will all be obvious at that time.

│ Postfix has no support for "password-like" maps except /etc/passwd
│ accessed via getpwnam(3).

So the workaround is to have 2 maps, one for vm-pop3d to look up its
passwords, another for postfix to verify the existance of users. It's
something I wanted to avoid, but I have changed to another strategy
to manage accounts on this machine. It's quick and dirty. Each user
has a single file in a directory. The file contains their password.
These files are collected to construct the two needed files (and then
postmap is run to generate the hash db file Postfix will use).

At this point, Postfix is not recognizing users in the file even
though it is specified in local_recipient_maps. I just started
working on this so I haven't vetted all the possible errors, yet.
But it looks as though local_recipient_maps has no effect as it
still recognizes users that do happen to be in /etc/passwd.

寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 10:09:57 PST

On Mon, Jul 01, 2002 at 10:48:03AM -0500, Phil Howard wrote:

> Courier IMAP did not meet migration requirements for this server.
> Mailbox format is required in this case so that user mail is not
> lost. I will be using rsync to syncronize the mailboxes from the
> old machine to the new one, then transfer IP addresses and restart.

Hello? There are conversion scripts for mbox -> maildir

> The POP server used is vm-pop3d. It is past the time to allocate
> the additional time to change the software used or to work out the
> strategy to change from mailbox to maildir format. Physical move of
> servers takes place 13 July. The migration must take place at the
> maintenance window allocated for least user disruption.

You can even convert on the fly! New delivery to Maildir, then, while
new mail is coming in you can still convert the old mailboxes in the
background.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 7 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 11:09:25 PST

On Mon, Jul 01, 2002 at 07:09:32PM +0200, Ralf Hildebrandt wrote:

│ On Mon, Jul 01, 2002 at 10:48:03AM -0500, Phil Howard wrote:
│
│ > Courier IMAP did not meet migration requirements for this server.
│ > Mailbox format is required in this case so that user mail is not
│ > lost. I will be using rsync to syncronize the mailboxes from the
│ > old machine to the new one, then transfer IP addresses and restart.
│
│ Hello? There are conversion scripts for mbox -> maildir
│
│ > The POP server used is vm-pop3d. It is past the time to allocate
│ > the additional time to change the software used or to work out the
│ > strategy to change from mailbox to maildir format. Physical move of
│ > servers takes place 13 July. The migration must take place at the
│ > maintenance window allocated for least user disruption.
│
│ You can even convert on the fly! New delivery to Maildir, then, while
│ new mail is coming in you can still convert the old mailboxes in the
│ background.

It would be nice if there was the luxury of time to go study all that.
But when an old server starts to die, you don't generally think about
"Oh, let's change the file format so we can change the POP server".
Maybe these things could be done, but it would also be prudent to test
things first, too. Given the short amount of time in this case, it is
barely enough to test a machine, OS, MTA, and POP server. Perhaps I
shouldn't have even tried to virtualize the domain at all, but it will
deal with some issues this server has had.

I do prefer the maildir format. But this wasn't the time for it.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 8 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 11:38:42 PST

On Mon, Jul 01, 2002 at 12:02:14PM +0200, Jean-Pierre Schwickerath wrote:

I now have:

local_recipient_maps = hash:/etc/virtual/users

The file named "users" has each LHS with the username by itself and
the RHS with just "OK". But the names are not recognized. Names
that are in /etc/passwd are recognized even though I did not code
unix:passwd.byname on local_recipient_maps at all. It's like it
just doesn't see it at all and still uses the default.

What do I look for next?

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 9 in thread
寄件者：Jean-Pierre Schwickerath (lists@schwicky.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 12:12:46 PST

Phil Howard wrote:

> he file named "users" has each LHS with the username by itself and
> the RHS with just "OK". But the names are not recognized.

I had a look into the VIRTUAL_README file and saw you might want to try
this:

virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox

and fill your /etc/postfix/vmailbox file with records like

usernameusernameMailbox

so that mail for username is put into the
"/var/mail/vhosts/usernameMailbox" File

Jean-Pierre

--
Powered by Linux From Scratch - http://schwicky.net
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 10 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 12:26:50 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> local_recipient_maps = hash:/etc/virtual/users
>
> The file named "users" has each LHS with the username by itself and
> the RHS with just "OK". But the names are not recognized. Names
> that are in /etc/passwd are recognized even though I did not code
> unix:passwd.byname on local_recipient_maps at all. It's like it
> just doesn't see it at all and still uses the default.
>
> What do I look for next?
>

logs.

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

寄件者：Jean-Pierre Schwickerath (lists@schwicky.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 13:05:06 PST

Phil Howard wrote:

> This is not going in the right direction. I'm trying to find a way
> to have LESS data files hanging around.

I thought you were looking for a way not to list local users in your
/etc/passwd file but somewhere else so as to trully seperate login users
and mail users.

Jean-Pierre

--
Powered by Linux From Scratch - http://schwicky.net
PGP Key ID: 0xEE6F49B4 - AIM/Jabber: Schwicky - ICQ: 4690141

Nothing is impossible... Everything is relative!
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

Message 12 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 13:58:15 PST

On Mon, Jul 01, 2002 at 03:25:22PM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Mon, 1 Jul 2002, Phil Howard wrote:
│
│ > local_recipient_maps = hash:/etc/virtual/users
│ >
│ > The file named "users" has each LHS with the username by itself and
│ > the RHS with just "OK". But the names are not recognized. Names
│ > that are in /etc/passwd are recognized even though I did not code
│ > unix:passwd.byname on local_recipient_maps at all. It's like it
│ > just doesn't see it at all and still uses the default.
│ >
│ > What do I look for next?
│ >
│
│ logs.

It says bounced, unknown user. I would be looking for something like
maybe why it can't read the file? I checked and double checked the
file permissions, and it should be able to read it. Should I make it
owned by the postfix user?

Here's what I get:
=========================================================================
Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: connect from vega.ipal.net[209.102.192.64]
Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: 72025F5: client=vega.ipal.net[209.102.192.64]
Jul 1 15:55:12 rack4 postfix/cleanup⁶³⁶⁵: 72025F5: message-id=<20020701205511.85C28293@vega.ipal.net>
Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")
Jul 1 15:55:12 rack4 postfix/cleanup⁶³⁶⁵: 7E069125: message-id=<20020701205512.7E069125@rack4.intur.net>
Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 7E069125: from=<>, size=2025, nrcpt=1 (queue active)
Jul 1 15:55:14 rack4 postfix/smtp⁶³⁶⁹: 7E069125: to=, relay=vega.ipal.net[209.102.192.80], delay=2, status=sent (250 Ok: queued as 77E0F292)
=========================================================================

Message 13 in thread
寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:03:52 PST

On Mon, Jul 01, 2002 at 03:56:20PM -0500, Phil Howard wrote:

> Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
> Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
> Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")

At least we now know that "local" is involved.
Wasn't the whole idea NOT to use "local" but some other LDA, like
"virtual"?

--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
I wish you'd tell me what kind of systems they're using instead,
because HP can't be doing much worse than Sun "would you like the
compiler or internet options with that" Microsystems, or Silicon "hey
be glad the support-contract number isn't a 1-900" Graphics. Then
there's Digital "It sucks in 64 bits, you can't suck in 64 bits
anywhere else" Equipment Corp (Did we mention it's 64 bits?).

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 14 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:39:00 PST

On Mon, Jul 01, 2002 at 10:03:54PM +0200, Jean-Pierre Schwickerath wrote:

│ Phil Howard wrote:
│
│ > This is not going in the right direction. I'm trying to find a way
│ > to have LESS data files hanging around.
│
│ I thought you were looking for a way not to list local users in your
│ /etc/passwd file but somewhere else so as to trully seperate login users
│ and mail users.

There were two, and now three. But I don't see the point in having
a map that translates x -> x for every different user.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 15 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:40:39 PST

On Mon, Jul 01, 2002 at 10:59:28PM +0200, Ralf Hildebrandt wrote:

│ On Mon, Jul 01, 2002 at 03:56:20PM -0500, Phil Howard wrote:
│
│ > Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
│ > Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
│ > Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")
│
│ At least we now know that "local" is involved.
│ Wasn't the whole idea NOT to use "local" but some other LDA, like
│ "virtual"?

But it is local. Just not the same user base as the system.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 16 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:45:29 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> It says bounced, unknown user. I would be looking for something like
> maybe why it can't read the file? I checked and double checked the
> file permissions, and it should be able to read it. Should I make it
> owned by the postfix user?
>
> Here's what I get:
> =========================================================================
> Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: connect from vega.ipal.net[209.102.192.64]
> Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: 72025F5: client=vega.ipal.net[209.102.192.64]
> Jul 1 15:55:12 rack4 postfix/cleanup⁶³⁶⁵: 72025F5: message-id=<20020701205511.85C28293@vega.ipal.net>
> Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
> Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
> Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")
> Jul 1 15:55:12 rack4 postfix/cleanup⁶³⁶⁵: 7E069125: message-id=<20020701205512.7E069125@rack4.intur.net>
> Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 7E069125: from=<>, size=2025, nrcpt=1 (queue active)
> Jul 1 15:55:14 rack4 postfix/smtp⁶³⁶⁹: 7E069125: to=, relay=vega.ipal.net[209.102.192.80], delay=2, status=sent (250 Ok: queued as 77E0F292)
> =========================================================================
>

This is finally useful. Please examine your logs closely. The bounce is
from the "local" delivery agent, not from "smtpd". So local_recipient_maps
is not the issue. Delivery for the domain is being passed to the "local"
delivery agent. The local delivery agent does deliver to non-shell users
(what uid should the mailbox belong to? what user should pipes in .forward
files run as? ...)

What delivery agent are you expecting to use?

Your choices are:

virtual- Postfix virtual delivery agent
maildrop - Courier delivery agent
deliver - Cyrus delivery agent
whatever comes with your POP server?
...

Each of these delivery agents has its own database format. Set up the
appropriate transport table entries (or redefine local_transport) and
configure any necessary delivery agent tables.

As I said the first time, the answer depends on your choice of delivery
agent which ties into your choice of POP/IMAP server.

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 17 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:48:19 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> On Mon, Jul 01, 2002 at 10:59:28PM +0200, Ralf Hildebrandt wrote:
>
> │ On Mon, Jul 01, 2002 at 03:56:20PM -0500, Phil Howard wrote:
> │
> │ > Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
> │ > Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
> │ > Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")
> │
> │ At least we now know that "local" is involved.
> │ Wasn't the whole idea NOT to use "local" but some other LDA, like
> │ "virtual"?
>
> But it is local. Just not the same user base as the system.
>

Sadly you misundertood the "local" delivery agent. Its input namespace
is the set of local shell accounts + any aliases. Its output namespace
(mailboxes it delivers to) is just the space of shell acounts.

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 18 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 14:54:51 PST

On Mon, Jul 01, 2002 at 10:59:28PM +0200, Ralf Hildebrandt wrote:

Obviously I've picked the wrong concept here. If "local" and
"virtual" can't be the same thing, I'm not sure how to get this
done.

When a very basic simple one-host setup is done, I don't have to
use a map which translates a username to path (file for mailbox or
directory for maildir). So why should it be different for virtual?
Oh I know, because of the traditional kludge to fake virtual that
originated with sendmail, where user@domain was translated to a
local system user. But I don't need that. If local can deliver
to /var/spool/mail/${user} why not allow something to deliver to
/var/spool/vmail/${domain}/${user}. This would be such a simple
concept and not need a map file (but certain you can have one that
can override the default for the cases where you want something
different done).

It looks like what I need to do is abandon virtualizing on this
server, and address how I want to set up the NEXT project. It seems
figuring things out is going to take more time than I thought. The
next project does have more time, though not enough time to develop
a new MTA for it. Now would it be better for me to try to figure it
out and have others fix my mistakes, or explain it up front and let
you tell me what concept in Postfix matches up to it (if any)?

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 19 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 15:05:16 PST

On Mon, Jul 01, 2002 at 05:46:42PM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Mon, 1 Jul 2002, Phil Howard wrote:
│
│ > On Mon, Jul 01, 2002 at 10:59:28PM +0200, Ralf Hildebrandt wrote:
│ >
│ > │ On Mon, Jul 01, 2002 at 03:56:20PM -0500, Phil Howard wrote:
│ > │
│ > │ > Jul 1 15:55:12 rack4 postfix/qmgr⁶³³⁷: 72025F5: from=, size=508, nrcpt=1 (queue active)
│ > │ > Jul 1 15:55:12 rack4 postfix/smtpd⁶³⁶⁴: disconnect from vega.ipal.net[209.102.192.64]
│ > │ > Jul 1 15:55:12 rack4 postfix/local⁶³⁶⁷: 72025F5: to=, relay=local, delay=0, status=bounced (unknown user: "ka9wgn")
│ > │
│ > │ At least we now know that "local" is involved.
│ > │ Wasn't the whole idea NOT to use "local" but some other LDA, like
│ > │ "virtual"?
│ >
│ > But it is local. Just not the same user base as the system.
│ >
│
│ Sadly you misundertood the "local" delivery agent. Its input namespace
│ is the set of local shell accounts + any aliases. Its output namespace
│ (mailboxes it delivers to) is just the space of shell acounts.

So what should I be using to deliver the mail into mailboxes on the local
machine, where the mailbox is a name exactly the same as the user part
of the address, appended to a path (/var/spool/mail), where every mailbox
is owned by one specific system user. The mailed-to users do not have
home directories, so there is no .forward file. If there are any addresses
that need to be forwarded to some other, a map for that is good, but if
the address is not found in the map, it should just be delivered normally.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 20 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 15:05:29 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> Obviously I've picked the wrong concept here. If "local" and
> "virtual" can't be the same thing, I'm not sure how to get this
> done.

This is the first step, knowing what you don't know.

>
> When a very basic simple one-host setup is done, I don't have to
> use a map which translates a username to path (file for mailbox or
> directory for maildir). So why should it be different for virtual?
> Oh I know, because of the traditional kludge to fake virtual that
> originated with sendmail, where user@domain was translated to a
> local system user. But I don't need that. If local can deliver
> to /var/spool/mail/${user} why not allow something to deliver to
> /var/spool/vmail/${domain}/${user}. This would be such a simple
> concept and not need a map file (but certain you can have one that
> can override the default for the cases where you want something
> different done).
>

The "virtual" delivery agent is not very sophisticated. I believe that
this is in part because most sites don't use it! It is not very useful by
itself, and a complete POP/IMAP product (such as Cyrus or Courier) comes
with a dedicated delivery agent.

> It looks like what I need to do is abandon virtualizing on this
> server, and address how I want to set up the NEXT project. It seems
> figuring things out is going to take more time than I thought. The
> next project does have more time, though not enough time to develop
> a new MTA for it. Now would it be better for me to try to figure it
> out and have others fix my mistakes, or explain it up front and let
> you tell me what concept in Postfix matches up to it (if any)?
>

Yes, for now it may be simplest to deliver using "local" to shell accounts
listed in /etc/passwd. Some of us think that migrating to Courier is not
too difficult given the availability of decent HOWTO documents, but a
conservative step-by-step approach is wise. First get your server working,
then teach it new tricks.

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 15:21:44 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> So what should I be using to deliver the mail into mailboxes on the local
> machine, where the mailbox is a name exactly the same as the user part
> of the address, appended to a path (/var/spool/mail), where every mailbox
> is owned by one specific system user. The mailed-to users do not have
> home directories, so there is no .forward file. If there are any addresses
> that need to be forwarded to some other, a map for that is good, but if
> the address is not found in the map, it should just be delivered normally.
>

Use a better (than "virtual") delivery agent which comes with your virtual
user POP/IMAP server.

The simplest configuration with the bundled VDA is to use the "static" map
for virtual_uid_maps and virtual_gid_maps. Then use a suitable map type
(perhaps MySQL or "userdb" to share data with the POP/IMAP server) to
manage just virtual_mailbox_maps.

There is no support for a "/some/path/%d/%u" format template in the
virtual delivery agent which ships with Postfix.

--
Viktor.

On Mon, Jul 01, 2002 at 06:03:42PM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Mon, 1 Jul 2002, Phil Howard wrote:
│
│ > Obviously I've picked the wrong concept here. If "local" and
│ > "virtual" can't be the same thing, I'm not sure how to get this
│ > done.
│
│ This is the first step, knowing what you don't know.
│
│ >
│ > When a very basic simple one-host setup is done, I don't have to
│ > use a map which translates a username to path (file for mailbox or
│ > directory for maildir). So why should it be different for virtual?
│ > Oh I know, because of the traditional kludge to fake virtual that
│ > originated with sendmail, where user@domain was translated to a
│ > local system user. But I don't need that. If local can deliver
│ > to /var/spool/mail/${user} why not allow something to deliver to
│ > /var/spool/vmail/${domain}/${user}. This would be such a simple
│ > concept and not need a map file (but certain you can have one that
│ > can override the default for the cases where you want something
│ > different done).
│ >
│
│ The "virtual" delivery agent is not very sophisticated. I believe that
│ this is in part because most sites don't use it! It is not very useful by
│ itself, and a complete POP/IMAP product (such as Cyrus or Courier) comes
│ with a dedicated delivery agent.

How does a delivery agent "hook up" to Postfix? Is LMTP the only way,
or can it be a dynamic library?

What about local_recipient_maps and/or making smtpd reject unknown users
when the delivery is keeping separate users spaces for each domain (which
apparently is what is called virtual).

│ > It looks like what I need to do is abandon virtualizing on this
│ > server, and address how I want to set up the NEXT project. It seems
│ > figuring things out is going to take more time than I thought. The
│ > next project does have more time, though not enough time to develop
│ > a new MTA for it. Now would it be better for me to try to figure it
│ > out and have others fix my mistakes, or explain it up front and let
│ > you tell me what concept in Postfix matches up to it (if any)?
│ >
│
│ Yes, for now it may be simplest to deliver using "local" to shell accounts
│ listed in /etc/passwd. Some of us think that migrating to Courier is not
│ too difficult given the availability of decent HOWTO documents, but a
│ conservative step-by-step approach is wise. First get your server working,
│ then teach it new tricks.

Once the server is working, it won't be changed for a while.

But, there is the next project. This is what it needs:

1. Support for many domains.

2. Support for separate user name space for each domain (except where
a domain is linked/aliased to another, then they share the user
name space).

3. NOT one giant map with every user@domain. That will be too big to
maintain. A separate map for each domain is best.

4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format

5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
delivery. If it doesn't, then the address is non-existant.

6. If ${prefix}/${domain}/${user}/.forward exists, obey it.

7. One single system user owns everything from ${prefix}/ on down.

To carry out some of these things, the thought I had was to write a new
map type handler which does a lookup for an existing directory or file.
The "name" for the map will actually be a complex specification that
tells the path, what to return if the file object does not exist, what
to return if it is a directory, and what to return if it is a file with
a special code to indicate that the file should be read and its content
be returned. Then Postfix can think it is a map, but it's just a directory.

Users will be added/deleted/changed by web CGI programs. Rebuilding a
whole map is a bad idea in this case.

寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users
View: Complete Thread (36 articles)
Original Format
新闻群组：mailing.postfix.users
日期：2002-07-01 18:43:47 PST

On Mon, 1 Jul 2002, Phil Howard wrote:

> How does a delivery agent "hook up" to Postfix? Is LMTP the only way,
> or can it be a dynamic library?

Either LMTP, or a UNIX command line invocation via "pipe" (the
delivery agents that come with Postfix use the internal queue manager <->
delivery agent IPC, they also directly touch the queue file and bounce
logs). The internal interfaces are not documented and are subject to
change, so at this time only "LMTP" and "pipe" are suitable for
"third-party" delivery agents. In practice this is good enough.

>
> What about local_recipient_maps and/or making smtpd reject unknown users
> when the delivery is keeping separate users spaces for each domain (which
> apparently is what is called virtual).
>

If the VDA recipient tables are available via a suitable Postfix map type,
"smtpd" can validate recipients against these tables. The "userdb" format
used by Courier is available (via a patch) as a Postfix map type. One day
there may be an interface for dynamically loading new map types.

> 1. Support for many domains.
>
> 2. Support for separate user name space for each domain (except where
> a domain is linked/aliased to another, then they share the user
> name space).

Any VDA will do 1 & 2.

>
> 3. NOT one giant map with every user@domain. That will be too big to
> maintain. A separate map for each domain is best.

Your intuition is wrong here. Searching multiple (possible hundreds) of
maps for a single key scales poorly. In fact one single map is best.
Making a sensible front-end tool that provides per domain views is a
separate problem (can use say "select ... where ..."). A good IMAP server
comes with virtual user and virtual domain administration tools.

>
> 4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format

Any VDA will do this, but for some the mailboxes for each user may need to
be explicitly mapped to the appropriate path.

>
> 5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
> delivery. If it doesn't, then the address is non-existant.

This cannot be done from "smtpd", it needs to be able to run "chrooted"
and with low privileges. You need a map to validate the users. Surely
users need a password entry to read their mail, so a path entry for their
mailbox is not asking too much. Any multi-column database (MySQL, LDAP,
userdb, ...) will be able to all the necessary data in one row per user.

>
> 6. If ${prefix}/${domain}/${user}/.forward exists, obey it.

This is available with some VDAs (but not the "virtual" delivery
agent bundled with Postfix).

>
> 7. One single system user owns everything from ${prefix}/ on down.

$virtual_uid_maps = static:12345
$virtual_gid_maps = static:12345

> To carry out some of these things, the thought I had was to write a new
> map type handler which does a lookup for an existing directory or file.
> The "name" for the map will actually be a complex specification that
> tells the path, what to return if the file object does not exist, what
> to return if it is a directory, and what to return if it is a file with
> a special code to indicate that the file should be read and its content
> be returned. Then Postfix can think it is a map, but it's just a directory.
>

This will not work because of "chroot" and security issues. Just drive
both the VDA and Postfix from a shared "userdb", MySQL or LDAP database.

> Users will be added/deleted/changed by web CGI programs. Rebuilding a
> whole map is a bad idea in this case.
>

Berkeley DB maps support incremental insertion, but this is not
crashproof unless you turn on logging and transactions, doing Postfix
compatible locking may also be an issue, also Postfix may need to open
the map with logging and transactions turned on in order to do crash
recovery, this is not the case with the current Berkeley DB <-> Postfix
glue. For live incremental updates your best may be LDAP, MySQL or (via a
patch) PostSQL.

Note on the other hand that even large Berkeley DB maps can be rebuilt
from scratch very quickly (5s on my machine for ~16MB on disk .db file
with ~140000 records). If you build a copy of the map, open it, sync it,
and rename it, you have a light weight crash-proof (atomic) Berkeley DB
rebuild. If this happens infrequently (less than once every 5 minutes) you
will be better off with Berkeley DB than with any complex/slow DBMS than
supports incremental insertion of records.

Does anyone else have good experiences with other dynamic map types that
support efficient frequent incremental rebuilds and are robust against
crashes?

[ Michael Tokarev: how quickly does your tinycdb build large maps ~100000
rows ~16 MB image ].

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-01 22:52:06 PST

On Mon, Jul 01, 2002 at 05:21:15PM -0500, Phil Howard wrote:

> How does a delivery agent "hook up" to Postfix? Is LMTP the only way,
> or can it be a dynamic library?

You can always call it using "mailbox_command" or "local_transport" or
"mailbox_transport".

> What about local_recipient_maps and/or making smtpd reject unknown users
> when the delivery is keeping separate users spaces for each domain (which
> apparently is what is called virtual).

These are just syntactical sugar.
Merely maps that rell smtpd to reject the mail right away.

> 1. Support for many domains.
>
> 2. Support for separate user name space for each domain (except where
> a domain is linked/aliased to another, then they share the user
> name space).

virtual_maps

> 3. NOT one giant map with every user@domain. That will be too big to
> maintain. A separate map for each domain is best.

That's what you think.
It performs best wiuth one map (which can be constructed/merged from
many small map). OTOH, sql or LDAP come to mind.

> 4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format

procmail can do that. Dunno about "virtual"

> 5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
> delivery. If it doesn't, then the address is non-existant.

Interesting. That would be using the FS as map.
In that case, smtpd couldn't run chrooted.

> 6. If ${prefix}/${domain}/${user}/.forward exists, obey it.

So no "virtual" LDA then.

> 7. One single system user owns everything from ${prefix}/ on down.

OK.

> To carry out some of these things, the thought I had was to write a new
> map type handler which does a lookup for an existing directory or file.

It already exists (I thinK!) as a patch.

--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Eh? Linux is luserproof? What kind of "proper" set up is that, ripping
out all removable media devices and ethernet, freezing the hard drive
spindle, encasing it in concrete and dropping it off a pier?

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

Just to point out first, unlike the current project, the next mail based
project does have more time available to it and doesn't yet have a fixed
schedule. Thus there is time to write some C code and do things like
adding a new map type.

On Mon, Jul 01, 2002 at 09:42:53PM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Mon, 1 Jul 2002, Phil Howard wrote:
│
│ > 3. NOT one giant map with every user@domain. That will be too big to
│ > maintain. A separate map for each domain is best.
│
│ Your intuition is wrong here. Searching multiple (possible hundreds) of
│ maps for a single key scales poorly. In fact one single map is best.
│ Making a sensible front-end tool that provides per domain views is a
│ separate problem (can use say "select ... where ..."). A good IMAP server
│ comes with virtual user and virtual domain administration tools.

If each map is for a specific domain, why search them all? Why not just
search the one map for that domain, using only the username part as the
key, and stop there?

I want to be able to be able to link maps together so that example.com
and example.net are the same namespace, without there being duplicates
for every user in a big single giant map. But the biggest reason is
load balancing. I want to be able to easily and quickly move a group of
domains from one server to another one.

As a result of this, these maps would have only the user part as the
key, so even if you wanted to search all the maps for some user@domain,
you can't actually carry out a reasonable search. If you searching
for foo@example.com, and there exists an entry for "foo" in the map
for example.org, is that considered a match?

As for the administration tools in an IMAP server, this project won't
be able to use them, as the administration will be done by a separate
project. Manual administration is intended to be very rare, so any
manual oriented administration tools are not applicable.

│ > 4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format
│
│ Any VDA will do this, but for some the mailboxes for each user may need to
│ be explicitly mapped to the appropriate path.

If the regular expression map can do substitution, then maybe it can
be used to construct the path from the user@domain key. Otherwise a
new map type could easily solve the problem. One that did read a map
file but applied the substitution if the map file didn't have a match
would make sense to me. Then you could still have a mapping for the
rare cases of an unusual relationship, without having to build and
keep a giant identity map.

│ > 5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
│ > delivery. If it doesn't, then the address is non-existant.
│
│ This cannot be done from "smtpd", it needs to be able to run "chrooted"
│ and with low privileges. You need a map to validate the users. Surely
│ users need a password entry to read their mail, so a path entry for their
│ mailbox is not asking too much. Any multi-column database (MySQL, LDAP,
│ userdb, ...) will be able to all the necessary data in one row per user.

Obviously it needs to know in some way. Can the specific chroot path be
configured (even if at patch time)? That can be a path where all the maps
are located and it just reads them. In Linux I can also do bind mounting
to put one directory inside another, and that works fine in chroot (I know
because I have a script to do Slackware installs in chroot that uses this
capability to "pre-mount" the target directory into the chroot as "/mnt"
where the Slackware installer installs to, and it works).

│ > 6. If ${prefix}/${domain}/${user}/.forward exists, obey it.
│
│ This is available with some VDAs (but not the "virtual" delivery
│ agent bundled with Postfix).

Is Postfix's VDA considered useful?

│ > 7. One single system user owns everything from ${prefix}/ on down.
│
│ $virtual_uid_maps = static:12345
│ $virtual_gid_maps = static:12345
│
│ > To carry out some of these things, the thought I had was to write a new
│ > map type handler which does a lookup for an existing directory or file.
│ > The "name" for the map will actually be a complex specification that
│ > tells the path, what to return if the file object does not exist, what
│ > to return if it is a directory, and what to return if it is a file with
│ > a special code to indicate that the file should be read and its content
│ > be returned. Then Postfix can think it is a map, but it's just a directory.
│ >
│
│ This will not work because of "chroot" and security issues. Just drive
│ both the VDA and Postfix from a shared "userdb", MySQL or LDAP database.

What directory will it be chroot-ed into?

│ > Users will be added/deleted/changed by web CGI programs. Rebuilding a
│ > whole map is a bad idea in this case.
│ >
│
│ Berkeley DB maps support incremental insertion, but this is not
│ crashproof unless you turn on logging and transactions, doing Postfix
│ compatible locking may also be an issue, also Postfix may need to open
│ the map with logging and transactions turned on in order to do crash
│ recovery, this is not the case with the current Berkeley DB <-> Postfix
│ glue. For live incremental updates your best may be LDAP, MySQL or (via a
│ patch) PostSQL.
│
│ Note on the other hand that even large Berkeley DB maps can be rebuilt
│ from scratch very quickly (5s on my machine for ~16MB on disk .db file
│ with ~140000 records). If you build a copy of the map, open it, sync it,
│ and rename it, you have a light weight crash-proof (atomic) Berkeley DB
│ rebuild. If this happens infrequently (less than once every 5 minutes) you
│ will be better off with Berkeley DB than with any complex/slow DBMS than
│ supports incremental insertion of records.
│
│ Does anyone else have good experiences with other dynamic map types that
│ support efficient frequent incremental rebuilds and are robust against
│ crashes?
│
│ [ Michael Tokarev: how quickly does your tinycdb build large maps ~100000
│ rows ~16 MB image ].

With reiserfs, it is now more practical to use the filesystem as a database.
While it has journaling, the key factors here is that it uses hashing to
manage the directories, and has a feature called tail-packing for efficient
space utilization with small files. It's not quite as fast as ext2, but it
sure beats ext2 when you have 3.7 million files in a single directory (which
I have done).

With Linux bind mounts I can present the tree of such a filesystem based db
into any directory which is to serve as the chroot jail for some process.
The only risk is that bind mounts inherit the rw vs ro property of the whole
filesystem it is picked from. Making sure the process has no uid rights to
write on those directories or files should deal with it.

I haven't ruled out using a db file rebuilt periodically from other data.
But I probably would go for cdb in that case.

寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 02:11:06 PST

On Tue, Jul 02, 2002 at 04:03:07AM -0500, Phil Howard wrote:

> If each map is for a specific domain, why search them all? Why not just
> search the one map for that domain, using only the username part as the
> key, and stop there?

Because all data could be in all maps. What you want would probably an
LDAP server (search only in the ou=domain or something like that)

> load balancing. I want to be able to easily and quickly move a group of
> domains from one server to another one.

Simply change what user@domain1.com points to in your map.

> As a result of this, these maps would have only the user part as the
> key, so even if you wanted to search all the maps for some user@domain,
> you can't actually carry out a reasonable search. If you searching
> for foo@example.com, and there exists an entry for "foo" in the map
> for example.org, is that considered a match?

man 5 virtual
(yes)

> │ This will not work because of "chroot" and security issues. Just drive
> │ both the VDA and Postfix from a shared "userdb", MySQL or LDAP database.
>
> What directory will it be chroot-ed into?

$queue_directory

> With reiserfs, it is now more practical to use the filesystem as a database.

If you want to lose all data, yes. I get sick when I see the weekly
patches for various flaws. I don't let Reiser anywhere close to a
system which needs to be reliable.

> I haven't ruled out using a db file rebuilt periodically from other data.
> But I probably would go for cdb in that case.

Yup.

--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
"Internet is so big, so powerful and pointless that for some people it
is a complete substitute for life."-Andrew Brown

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 27 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 02:17:49 PST

On Tue, Jul 02, 2002 at 07:50:30AM +0200, Ralf Hildebrandt wrote:

│ > 3. NOT one giant map with every user@domain. That will be too big to
│ > maintain. A separate map for each domain is best.
│
│ That's what you think.
│ It performs best wiuth one map (which can be constructed/merged from
│ many small map). OTOH, sql or LDAP come to mind.

Accessing one large map is faster than accessing one smaller map? If
that's true, then I'll add a million dummy entries to make it faster.

Actually, the performance of accessing the map isn't the reason I want
to split by domain. It's a maintenance issue. Suppose there are 1000
domains with an average of 500 users each. The program that generates
the maps when there is a change would be exposed to 1000 times more
updates, and have 1000 times more work to do, each time a change is
made. That's O(N^2) for N = number of domains. Then there is the
issue of maintenance permission per domain. I need to leave open the
possibility that different domains will be managed by different user
access permissions. That might become part of the design.

│ > 5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
│ > delivery. If it doesn't, then the address is non-existant.
│
│ Interesting. That would be using the FS as map.
│ In that case, smtpd couldn't run chrooted.

Why not? I think it can be. Linux's bind mounts work fine across
chroot.

│ > To carry out some of these things, the thought I had was to write a new
│ > map type handler which does a lookup for an existing directory or file.
│
│ It already exists (I thinK!) as a patch.

I'll look around for it.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 28 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 02:24:39 PST

On Tue, Jul 02, 2002 at 11:08:57AM +0200, Ralf Hildebrandt wrote:

│ On Tue, Jul 02, 2002 at 04:03:07AM -0500, Phil Howard wrote:
│
│ > If each map is for a specific domain, why search them all? Why not just
│ > search the one map for that domain, using only the username part as the
│ > key, and stop there?
│
│ Because all data could be in all maps. What you want would probably an
│ LDAP server (search only in the ou=domain or something like that)

I have no plans to add an LDAP server, nor an SQL server.

│ > load balancing. I want to be able to easily and quickly move a group of
│ > domains from one server to another one.
│
│ Simply change what user@domain1.com points to in your map.

How will I transfer the file to the new machine? I want it to be a
separate file for a different domain

│ > As a result of this, these maps would have only the user part as the
│ > key, so even if you wanted to search all the maps for some user@domain,
│ > you can't actually carry out a reasonable search. If you searching
│ > for foo@example.com, and there exists an entry for "foo" in the map
│ > for example.org, is that considered a match?
│
│ man 5 virtual
│ (yes)

Is there a Postfix man page that lists all the other Postfix man pages?

│ > │ This will not work because of "chroot" and security issues. Just drive
│ > │ both the VDA and Postfix from a shared "userdb", MySQL or LDAP database.
│ >
│ > What directory will it be chroot-ed into?
│
│ $queue_directory
│
│ > With reiserfs, it is now more practical to use the filesystem as a database.
│
│ If you want to lose all data, yes. I get sick when I see the weekly
│ patches for various flaws. I don't let Reiser anywhere close to a
│ system which needs to be reliable.

Your experience and my experience aren't the same, apparently. Now I've
only been using it for half a year, but it has been rock solid reliable
and I have not lost a single thing. I have lost data occaisionally with
ext2.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 29 in thread
寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 02:29:13 PST

On Tue, Jul 02, 2002 at 04:15:48AM -0500, Phil Howard wrote:

> Accessing one large map is faster than accessing one smaller map? If
> that's true, then I'll add a million dummy entries to make it faster.

I was not talking about adding garbage to the map.

> Actually, the performance of accessing the map isn't the reason I want
> to split by domain. It's a maintenance issue. Suppose there are 1000
> domains with an average of 500 users each. The program that generates
> the maps when there is a change would be exposed to 1000 times more
> updates, and have 1000 times more work to do, each time a change is
> made. That's O(N^2) for N = number of domains. Then there is the
> issue of maintenance permission per domain. I need to leave open the
> possibility that different domains will be managed by different user
> access permissions. That might become part of the design.

Valid point. But why not use a map instead that does NOT require
rebuilding (like LDAP!)

Looking up something in one btree:
O(n) = ln(n) (well, sort of)

Looking up something in x btrees of size (n/x):

O(n) = x*ln(n/x)
which is bigger than ln(n)

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 30 in thread
寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 03:13:30 PST

On Tue, Jul 02, 2002 at 04:23:27AM -0500, Phil Howard wrote:

> │ Because all data could be in all maps. What you want would probably an
> │ LDAP server (search only in the ou=domain or something like that)
>
> I have no plans to add an LDAP server, nor an SQL server.

But it would be exactly what your requirements dictate.

> Is there a Postfix man page that lists all the other Postfix man pages?

Unfortunately no. maybe "man postfix" should do that!

> Your experience and my experience aren't the same, apparently. Now I've
> only been using it for half a year, but it has been rock solid reliable
> and I have not lost a single thing. I have lost data occaisionally with
> ext2.

We've been using ext3 for over a year now on our main server
(hauptpostamt.charite.de). During that time I've been following
ReiserFS development closely -- I think ReiserFS's complexity (too
much code) is just too high.

Although reliability has risen in the past (a recent test in the
German c't mag showed that ReiserFS, ext3 and XFS are probably the
most reliable choices).

--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
"The danger from computers is not that they will eventually get as smart
as men, but we will meanwhile agree to meet them halfway."-Bernard Avishai

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

Message 31 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 03:15:54 PST

On Tue, Jul 02, 2002 at 11:26:49AM +0200, Ralf Hildebrandt wrote:

│ On Tue, Jul 02, 2002 at 04:15:48AM -0500, Phil Howard wrote:
│
│ > Accessing one large map is faster than accessing one smaller map? If
│ > that's true, then I'll add a million dummy entries to make it faster.
│
│ I was not talking about adding garbage to the map.
│
│ > Actually, the performance of accessing the map isn't the reason I want
│ > to split by domain. It's a maintenance issue. Suppose there are 1000
│ > domains with an average of 500 users each. The program that generates
│ > the maps when there is a change would be exposed to 1000 times more
│ > updates, and have 1000 times more work to do, each time a change is
│ > made. That's O(N^2) for N = number of domains. Then there is the
│ > issue of maintenance permission per domain. I need to leave open the
│ > possibility that different domains will be managed by different user
│ > access permissions. That might become part of the design.
│
│ Valid point. But why not use a map instead that does NOT require
│ rebuilding (like LDAP!)

I don't want to add the administrative complexity of having yet another
server with all of its permissions and access schemes to make sure that
different administrators can only administer the subset of data they are
allowed to. While I am certain LDAP implementations can do that, it is
my experience that these things add a new complex layer of management
control to achieve it. I'm trying to keep it simple.

│ Looking up something in one btree:
│ O(n) = ln(n) (well, sort of)
│
│ Looking up something in x btrees of size (n/x):
│
│ O(n) = x*ln(n/x)
│ which is bigger than ln(n)

What is x? I think you are making the same mistake Victor did and are
trying to sequentially search each map separately. Such a search can't
even work since a map per-domain should have only the user part as the
key. So looking for foo@example.com by searching for foo in example.com
would be right, but what would you search for when searching the map for
example.org? foo? You might find foo in example.org, but it's the wrong
foo. And what if you are searching for foo@example.org but found it first
in the map for example.com?

Just search ONE map, the one for the appropriate domain. Then we're
doing 1*ln(n/x) ... times whatever it takes for the filesystem to
find that map ... which makes it ln(n/x)+ln(x) ... or ln(max(n/x,x))
as far as big-O is concerned.

Then you can also symlink one domain to another at the maps. With the
user part by itself as the key, this would work.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 32 in thread
寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 03:50:03 PST

On Tue, Jul 02, 2002 at 05:14:36AM -0500, Phil Howard wrote:

> │ Looking up something in one btree:
> │ O(n) = ln(n) (well, sort of)
> │
> │ Looking up something in x btrees of size (n/x):
> │
> │ O(n) = x*ln(n/x)
> │ which is bigger than ln(n)
>
> What is x? I think you are making the same mistake Victor did and are

x << n

(x is the number of maps)

> trying to sequentially search each map separately. Such a search can't
> even work since a map per-domain should have only the user part as the
> key.

All maps are searched. So if you key is in the last map, it has to
search each maps until a match is found.

> Just search ONE map, the one for the appropriate domain. Then we're

Postfix doesn't do that (yet)

--
Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de
Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155
Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
They've gone to find some more coffee. Sysadmin has left the building! -- Matt Haswell ccdmlh@zippy.dct.ac.uk

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 33 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 05:49:44 PST

On Tue, Jul 02, 2002 at 11:30:29AM +0200, Ralf Hildebrandt wrote:

│ On Tue, Jul 02, 2002 at 04:23:27AM -0500, Phil Howard wrote:
│
│ > │ Because all data could be in all maps. What you want would probably an
│ > │ LDAP server (search only in the ou=domain or something like that)
│ >
│ > I have no plans to add an LDAP server, nor an SQL server.
│
│ But it would be exactly what your requirements dictate.

I didn't list all the requirements. They aren't all written down
in one place, and they didn't all seem appropriate here, either.
Some of the requirements do include having a minimum of things to
administer, a minimum of things to debug, and a minimum of things
exposed to failing.

│ > Is there a Postfix man page that lists all the other Postfix man pages?
│
│ Unfortunately no. maybe "man postfix" should do that!

It would be a help, even if it just gives subtopics when then have
the list of other man pages.

│ > Your experience and my experience aren't the same, apparently. Now I've
│ > only been using it for half a year, but it has been rock solid reliable
│ > and I have not lost a single thing. I have lost data occaisionally with
│ > ext2.
│
│ We've been using ext3 for over a year now on our main server
│ (hauptpostamt.charite.de). During that time I've been following
│ ReiserFS development closely -- I think ReiserFS's complexity (too
│ much code) is just too high.
│
│ Although reliability has risen in the past (a recent test in the
│ German c't mag showed that ReiserFS, ext3 and XFS are probably the
│ most reliable choices).

How well does ext3 deal with 3000000 files in a single directory?
How well does ext3 deal with 3000000 files that have no more than
16 bytes each? These capabilities in ReiserFS have helped in a few
projects already. I am at 3.6 in Linux 2.4.18 and it has been good
to me so far. It's even dealt with messy issues like files that are
the executeable images of running processes being deleted, rebooting,
and cleaning up properly afterwards. Maybe some of that extra code
is what helps do things like tail packing. But I consider it a good
feature to have.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 34 in thread
寄件者：Phil Howard (phil-postfix-users@ipal.net)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 06:14:11 PST

On Tue, Jul 02, 2002 at 12:49:19PM +0200, Ralf Hildebrandt wrote:

│ On Tue, Jul 02, 2002 at 05:14:36AM -0500, Phil Howard wrote:
│
│ > │ Looking up something in one btree:
│ > │ O(n) = ln(n) (well, sort of)
│ > │
│ > │ Looking up something in x btrees of size (n/x):
│ > │
│ > │ O(n) = x*ln(n/x)
│ > │ which is bigger than ln(n)
│ >
│ > What is x? I think you are making the same mistake Victor did and are
│
│ x << n
│
│ (x is the number of maps)
│
│ > trying to sequentially search each map separately. Such a search can't
│ > even work since a map per-domain should have only the user part as the
│ > key.
│
│ All maps are searched. So if you key is in the last map, it has to
│ search each maps until a match is found.

That would produce the wrong results.

│ > Just search ONE map, the one for the appropriate domain. Then we're
│
│ Postfix doesn't do that (yet)

So it might be me who makes it do it.

--
-----------------------------------------------------------------
│ Phil Howard - KA9WGN │ Dallas │ http://linuxhomepage.com/ │
│ phil-nospam@ipal.net │ Texas, USA │ http://phil.ipal.org/ │
-----------------------------------------------------------------
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 35 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: virtualizing local users

View this article only
新闻群组：mailing.postfix.users
日期：2002-07-02 06:21:43 PST

On Tue, 2 Jul 2002, Phil Howard wrote:

> Just search ONE map, the one for the appropriate domain. Then we're
> doing 1*ln(n/x) ... times whatever it takes for the filesystem to
> find that map ... which makes it ln(n/x)+ln(x) ... or ln(max(n/x,x))
> as far as big-O is concerned.
>

To avoid running out of file descriptors this would need to be implemented
as a new (to Postfix) hierarchical map type. It will complicate chroot
setup, because the map hierarchy would need to be loopback (bind) mounted
into the chroot jain (always the Postfix queue directory). Additionally
the submaps for each domain would need to opened and closed on the fly,
with a suitable cache of open maps to avoid opening and closing maps for
every lookup. The underlying per domain map would need to be "cdb", not
Berkeleyu DB, since allocating and deallocating page pools and other map
open overhead in Berkeley DB potentially impacts lookup performance in a
negative way). What is the relative cost of map open vs. key lookup with
"cdb"?

Postfix maps do not know whether the lookup key is a user name, address,
domain name, ..., this happens at a higher layer accross all the map
types. Postfix maps just look up strings. Your map needs to parse its
keys into a domain and a user part. This conflicts with the Postfix
keyed map abstraction. Like "regexp" maps your map might need to avoid
"partial" keys so as not to get confused by source routes. There may be
other semantic subleties.

Actually LDAP maps with ldapsource_domain set also violate the abstraction
when filtering the input keys by domain, perhaps such maps should also
avoid "partial" keys.

Your proposal is a non-trivial development effort. Are you sure that your
energy and enthusiasm will be best spent in this direction? It would be
much easier to deploy something existing of the shelf even if slightly
imperfect the solutions will have been tested by others and known to work.

Of course all real progress is made by people who are wisely or otherwise
unhappy with the status quo, I do not want to discourage creativity, just
be aware that innovation is a risky business... :-(

--
Viktor.

On Tue, Jul 02, 2002 at 09:20:44AM -0400, Victor.Duchovni@morganstanley.com wrote:

│ On Tue, 2 Jul 2002, Phil Howard wrote:
│
│ > Just search ONE map, the one for the appropriate domain. Then we're
│ > doing 1*ln(n/x) ... times whatever it takes for the filesystem to
│ > find that map ... which makes it ln(n/x)+ln(x) ... or ln(max(n/x,x))
│ > as far as big-O is concerned.
│ >
│
│ To avoid running out of file descriptors this would need to be implemented
│ as a new (to Postfix) hierarchical map type. It will complicate chroot
│ setup, because the map hierarchy would need to be loopback (bind) mounted
│ into the chroot jain (always the Postfix queue directory). Additionally
│ the submaps for each domain would need to opened and closed on the fly,
│ with a suitable cache of open maps to avoid opening and closing maps for
│ every lookup. The underlying per domain map would need to be "cdb", not
│ Berkeleyu DB, since allocating and deallocating page pools and other map
│ open overhead in Berkeley DB potentially impacts lookup performance in a
│ negative way). What is the relative cost of map open vs. key lookup with
│ "cdb"?

My understanding is that DJBDNS opens cdb for every request.

│ Postfix maps do not know whether the lookup key is a user name, address,
│ domain name, ..., this happens at a higher layer accross all the map
│ types. Postfix maps just look up strings. Your map needs to parse its
│ keys into a domain and a user part. This conflicts with the Postfix
│ keyed map abstraction. Like "regexp" maps your map might need to avoid
│ "partial" keys so as not to get confused by source routes. There may be
│ other semantic subleties.

I might create a map type that simply constructs strings from keys. Maybe
the regexp map can already do what I need.

│ Actually LDAP maps with ldapsource_domain set also violate the abstraction
│ when filtering the input keys by domain, perhaps such maps should also
│ avoid "partial" keys.
│
│ Your proposal is a non-trivial development effort. Are you sure that your
│ energy and enthusiasm will be best spent in this direction? It would be
│ much easier to deploy something existing of the shelf even if slightly
│ imperfect the solutions will have been tested by others and known to work.
│
│ Of course all real progress is made by people who are wisely or otherwise
│ unhappy with the status quo, I do not want to discourage creativity, just
│ be aware that innovation is a risky business... :-(

Another option on the table being explored is developing my own SMTP daemon.
But this would be a very specialized one, not for general use. For example
it would not do any relaying whatsoever, so if you want to be able to inject
mail and have it delivered on the internet, or run an MX other than the final
destination, run another MTA, e.g. Postfix. It could also do LMTP. It would
only do maildir so that it wouldn't face having to otherwise queue mail, so
it would be a deliver-during-receipt type daemon, too. Its primitiveness
and lack of intent to support various other sendmail-ish things means it
would be a smaller project, and potentially viable. I'm not sure if would
go this route, but it's still an option. I have ruled out other MTAs for
the most part.

Posted by hzqbbc at November 11, 2002 03:20 PM

Related Toptics | 相关文章

Mbox vs Maildir - 两者原理和区别(2005/06/27)

Comments

原始地址：
>virtualizing local users
I do not agree.For more info go to System.String[]

Posted by: krakow hotel at September 26, 2006 03:42 PM

Zhiqiang::He

Happy + Health = Life^2

November 11, 2002

有关Postfix 的虚拟用户支持的大讨论

Comments

Post a comment