multiple DBs and ACL checks

I have in mind a deployment where I would provision users in
a
particular MySQL instance until it gets to some capacity
level that
I'm comfortable with.  After that, I'd create a new MySQL
instance on
another server and start provisioning users into that. 
Lather, rinse,
repeat.

Assuming I use a single logical LDAP directory for
authentication,
groups, etc, would ACLs work correctly for sharing
mailboxes?  In
other words, user Alice has her mailstore in MySQL database
A.  User
Bob has his mailstore in MySQL database B.  Can Bob grant
access to a
folder to Alice and expect it to work?

(I know this *should* work.  I'm just wondering if there is
some
secret "gotcha" in dbmail that will sink the
idea.)

Thanks.

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

DBMail doesn't currently work in multiple databases at one
time. Thus 
you would end up with multiple instances of dbmail databases
and 
applications running. The LDAP authentication would allow
you to have 1 
central location for user/pass combos, however your users
would need to 
always log into the same instance of databases/apps to even
see the same 
content as before. Regular TCP Load balancing would be very
bad. Your 
users, once on a particular server, would only be able to
see other 
mailboxes in the same instance. There has been talk of
allowing one 
instance of the app to open multiple connections to
different database 
servers, but that is for database clustering where 1 server
is the write 
server, and server 2+ are read only servers.

I'm not sure if you will be having multiple companies on the
same server 
or not, but if so, keeping your users seperated by domain is
probably 
your best bet. You could then manually balance out your
users by putting 
3 small domains on one server and 2 medium size on another
and a huge 
one all by itself, etc.

Hope that helps
-Jon


WJCarpenter wrote:
> I have in mind a deployment where I would provision
users in a
> particular MySQL instance until it gets to some
capacity level that
> I'm comfortable with.  After that, I'd create a new
MySQL instance on
> another server and start provisioning users into that. 
Lather, rinse,
> repeat.
>
> Assuming I use a single logical LDAP directory for
authentication,
> groups, etc, would ACLs work correctly for sharing
mailboxes?  In
> other words, user Alice has her mailstore in MySQL
database A.  User
> Bob has his mailstore in MySQL database B.  Can Bob
grant access to a
> folder to Alice and expect it to work?
>
> (I know this *should* work.  I'm just wondering if
there is some
> secret "gotcha" in dbmail that will sink the
idea.)
>
> Thanks.
>
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
>
>
>   



_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

jf> DBMail doesn't currently work in multiple databases
at one
jf> time. Thus you would end up with multiple instances
of dbmail
jf> databases and applications running. The LDAP
authentication would
jf> allow you to have 1 central location for user/pass
combos, however
jf> your users would need to always log into the same
instance of
jf> databases/apps to even see the same content as
before. Regular TCP

Thanks.  I think you may have misunderstood what I'm
thinking of (not
least because I didn't go into detail on that part).  I
intend to do
load balancing with an IMAP proxy like perdition which will
transparently connect my users to the correct server. 
Incoming mail
will similarly be fanned out by my MTA's local delivery
mechanism.

So, I fully expect there to be one dbmail instance
controlling exactly
one MySQL instance, and I don't expect the dbmail instances
to know
anything about each other.  If my front end connects to a
dbmail
instance and tries to access a given folder (belonging to
someone
else), will the ACL system freak because the connecting user
doesn't
have a mailstore in that dbmail instance?

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Unless Perdition sits right in the protocol session and is
proxying on a
per-command basis so that it sends some commands to one
server and some
to another -- and I have no idea how that would work --
then, no, you
cannot connect to a shared mailbox on another partition. It
is a neat
idea, though! but the code would probably be absolutely
brutal.

Aaron

On Tue, 2007-07-31 at 22:07 -0700, Jonathan Fealy wrote:
> As a user logs into another instance, the user should
be created 
> automatically in the dbmail_users table. However, the
dbmail_acl table 
> is usually configured to be locked into a row being
existent in the 
> users table. Either the user needs to login to that
server to create the 
> record, or you the admin need to create a correct user
on that box 
> before adding the acl. This would make constant
changes/add to acl's 
> difficult and tedious. Once setup, I think it should
work ok provided 
> that your proxy is doing things correctly and that when
the user is 
> selecting a folder from a different instance that
connection is being 
> done with the connected user's credentials.
> 
> -Jon
> 
> WJCarpenter wrote:
> > jf> DBMail doesn't currently work in multiple
databases at one
> > jf> time. Thus you would end up with multiple
instances of dbmail
> > jf> databases and applications running. The
LDAP authentication would
> > jf> allow you to have 1 central location for
user/pass combos, however
> > jf> your users would need to always log into
the same instance of
> > jf> databases/apps to even see the same content
as before. Regular TCP
> >
> > Thanks.  I think you may have misunderstood what
I'm thinking of (not
> > least because I didn't go into detail on that
part).  I intend to do
> > load balancing with an IMAP proxy like perdition
which will
> > transparently connect my users to the correct
server.  Incoming mail
> > will similarly be fanned out by my MTA's local
delivery mechanism.
> >
> > So, I fully expect there to be one dbmail instance
controlling exactly
> > one MySQL instance, and I don't expect the dbmail
instances to know
> > anything about each other.  If my front end
connects to a dbmail
> > instance and tries to access a given folder
(belonging to someone
> > else), will the ACL system freak because the
connecting user doesn't
> > have a mailstore in that dbmail instance?
> >
> > _______________________________________________
> > DBmail mailing list
> > DBmaildbmail.org
> > htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
> >
> >   
> 
> 
> 
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

as> Unless Perdition sits right in the protocol session
and is
as> proxying on a per-command basis so that it sends some
commands to
as> one server and some to another -- and I have no idea
how that
as> would work -- then, no, you cannot connect to a
shared mailbox on
as> another partition. It is a neat idea, though! but the
code would
as> probably be absolutely brutal.

You're right.  The front-end proxy would have to be a lot
more
entangled with the conversation than something like
perdition
currently is.

(I don't know that it would be that complicated ... you'd
just have to
be watching for mailbox connection requests and
transparently
logon/logoff the right server.  Might not be *too* bad,
depending on
how much state you have to keep track of, but I doubt there
is a proxy
that does this currently.)

This is probably the death blow to my evil plan.  I'll have
to do the
usual thing of provisioning users in shared folder
clusters.
Pragmatically, that will work out for my use case.

Thanks to all for comments.

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail