Manage multiple domains for Drupal multi-site

I agree
I use a dedicated host to run many domains.
I want each site to have a list or two...

thanks!
ryan

From: Gerhard
1) There will be one database which holds all tables for all domains that regard incoming and outgoin mail (7 per og2list instance).

2) In addition to the tables for the og2list instances there will be one table which defines a connection from the domain to the database table prefix (we will need prefixing to avoid clashes).

3) Each Drupal instance's database user will only have permissions for the tables that are associated to his account. In this way we avoid the data snooping I was afraid of before.

The provisioning script will need to set up the og2list tables for new instances and to maintain the relation of domain to table prefix. it might be possible that a domain changes, but the database prefixes should not be allowed to change.

4) exim will have full access to all databases and will first look for the database table prefix derived from mail domain and then insert the data as appropriate. If the "first lookup table prefix" part should not be possible we could always hardcode that list into exim.conf.

From Hilko:

I have had a look at the exim configuration and found that exim can connect to more than one database.

http://exim.org/exim-html-4.62/doc/html/spec_html/ch09.html#id2546221

Correct, but my impression is that this feature is there mainly for redundant setups:

For each query, these parameter groups are tried in order until a connection and a query succeeds.

Which means that for a 50-domains setup, an average of 25 database connections would be opened. I would't consider this acceptable.

Another downside is that the operator who adds a new site would also need to touch the central MTA configuration which should be avoided if possible.

I think that for Exim we should provide _one_ router and _one_ transport. The router would then determine if the recipient address is valid from simple list that can be generated from the active Drupal databases on a regular basis -- or whenever a new ogroup is added or reconfigured.

Considering that nowadays one should avoid bounces wherever possible, this list could also be used at SMTP time at a low cost to determine whether to accept the message at all.

Posting this to get some discussion revived on the topic.

Moving this to 4.7

I'm posting a solution description is to glean insight and direction from greater minds. Please review and respond to the following.

Understanding the possible limitation of not having access to master.cf as well as the necessity that all incoming mail be routed through mail-in.pl, it seems logical to do the routing in mail-in.pl.

What I conceive is to have a configuration option in mail-in.pl which directs it to consider multiple domains.

The values of the configuration option (ie: routing_type) will be directives indicating behavior (ie: NONE, LOCAL, DATABASE).

NONE will be the default and will provide the present behavior of honoring the mail.conf to do the appropriate database inserts for the incoming mail.

LOCAL indicates that the localhost has multiple drupal instances on unique domains. The LOCAL directive will use the domainname of the incoming message to determine which version of mail.conf to employ for performing the necessary inserts (ie: example.com:mail.conf).

DATABASE indicates that the domains are not co-located and the message must be forwarded 'off host'. DATABASE will instruct mail-in.pl to query to discover the appropriate receiving host details. (Table definition to be determined)

Too, there is the complexity of validating user's by consulting the og2list_groups table for each of the configured domains. Presently, this is a function of the condition = tag in the .cf file. To achieve this, the validate-recipient.pl script could be required for multi-domain configurations wherein the script is modified to support the LOCAL and NONE routing_type directives.

In response to #4, I think that is a good approach. And I assume mail-out.pl would function in a similar manner though using the msgid of og2list_outgoing_content to pick what mail_domain to use?

Has any code been written so far? Unless anyone has any code to share (even in alpha state) I'm going to start trying to implement the LOCAL style galapas discusses.

I have og2list working with a multi-site setup of two drupal sites, so a bit of the LOCAL configuration as described above.

mail.conf now uses hashes to store the databases and their connection information. mail-in.pl pulls out the site name from msgid and uses it to get the database information before making the connection.

I realized an error in my logic in my previous post for how mail-out.pl will know which database to connect to, it obviously cannot look at the msgid without first connecting to the database. Instead it just checks all databases setup in mail.conf.

There really isn't much code, but I can make a patch if requested. This post is mainly to provide an idea of one to do a multi-site setup of og2list.

Attached you'll find a patch to provide multi-site functionality in the perl scripts for og2list. You will need to make the appropriate system and mail changes on your own.

The patch expects to be run in a directory containing a folder og2list which contains mail.conf, mail-in.pl and mail-out.pl -- the files edited by this patch. Sorry if this is not the best way to patch.

Edit mail.conf for the sites you want og2list working for, if the documentation is not clear feel free to request details.

I have only tested this with perl-5.8.8-12. Also, there may be an optimized or better way to do the hashes, please feel free to comment.

Thanks.

#8 patch re-rolled for HEAD.

This time it should actually apply to cvs rather than my own directory structure, sorry about that.

Amazing work being done under the radar...

Is HEAD the Drupal 5 compatible release (as mentioned here)?

@Benjamin,

HEAD is just the most current version in CVS. It is Drupal 5 compatible and the one mentioned in that other issue.

To download the HEAD release, go to the og2list download page and use the "view all releases" link, it will then let you then download the og2list HEAD version. Then, you can apply the patch and everything should work.

If you're not sure how to go about applying the patch, have a look at this page for help: http://drupal.org/patch/apply

Please remember to comment back to this issue on how things worked out with the patch. Good luck!