How to most efficiently set up private client blogs using multisite?

Events happening in the community are now at Drupal community events on www.drupal.org.
joeshirley's picture

I would like to set up private blogs for clients, each readable only by the client and myself. These blogs will be simple and identical, and far different from my main site installation. I'm running Drupal (6.3) on my top level domain (www.example.com). I've been reading for several hours, all kinds of solutions, and have settled on one which may work. I'd like to share my solution, and get your feedback and answers to a few points I'm not clear about. I'm not a Drupal noob, but I'm not exactly a programmer either, so simplest is best, as long as it gets the job done safely.

A. Will it work to set up a completely new installation of Drupal at clients.example.com, and set that up to run as a multisite without interfering with my main installation?

B. Do I have to create the actual physical directory "clients.example.com/client1" on the server?

C. My understanding is that when I set up the sites directory structure as above, and point my browser to clients.example.com/client1, as long as my settings.php is virgin, this will call the install.php from the main site. Do I need to be concerned about whether it calls install.php from the domain root, instead of the clients subdirectory installation?

D. During installation, can I specify the same database as I'm using for the multisite hub, (clients.example.com), and specify a prefix for that client sub-site? I see that Domain Access plus Domain Prefix might be another way to do this, but again, I'm trying to keep things simplest.

E. Is there a straightforward way to set up and duplicate a reference site, in order to easily copy common content, menus, vocabularies, etc.? I'm guessing this would require messing with the database. I'm somewhat comfortable using phpAdmin on my server and MySQL Administrator from my local computer to do simple operations. Would also be able/willing to do command line actions if that's required. Perhaps my desire to have this capability points to setting up separate databases for each client installation as the best solution? My preference is to have a single database to backup weekly, rather than one for every client, but maybe I could automate that.

F. Is there any way to set things up so a client could log into their private site (clients.example.com/client1) and also be automatically logged into the main site (example.com), but users could not go the other way around and gain access to private client sites just by logging into the main site? At this point, I'm thinking this setup will require two logins.

I know I may be asking for a lot here, but I figure I want to see what the boundaries are before I go ahead with this solution. I'm going in this multisite direction for three reasons: 1) OG seems a little tricky to set up potentially dozens or even hundreds of single-member groups and keep access to content private - maybe I'm wrong, but it seems too much could go wrong to expose someone's content to the public. 2) I'd like to not jeopardize my client setups while being free to push the envelope on my main site, so would prefer two separate databases. 3) I'd like a sure way to bar search engine and other robots; even though login would be required to access any content on the multisites, dropping the appropriate robots.txt in the root subdirectory seems just that little bit safer; plus, there won't be any access to posting or commenting on any of these sites without an administrator-created account, which is more strict control than I'd like to have on my main site.

I'd appreciate anyone shooting holes in my logic or cluing me in to things I've missed.

Thank you so much for your help.

Comments

one suggestion

thomas23's picture

Hi joeshirley.

I'm not an expert but I don't mind sharing what I know so far. If I got you correctly you are looking for a WPMu using drupal. And for your case you'll have to do a fresh install only that you use the same core directory tree on the server. This actually is what multisite is all about!

A. and B. As stated in drupals settings.php in the comments drupal will distinguish between a call with clients.example.com and *.example.com if you name your "physical" directories on the server clients.example.com and example.com respectivly for the main installation (or www.example...). Copy the default settings.php to your new directory clients.example.com, rename it and change permissions.

C., D., E. and F. As far as I know you will have to do a new setup. Especially as you said you want to keep this blogging site different from you main installation. After server preparations point your browser to clients.example.com/install.php and use a different data base or at least different table prefix. To be precise you'll only need one new installation for all blogs. The only thing I can think of that doesn't come with drupal core is managing access to the blogs individually but I'm not even sure of this. I haven't actually done anything with advanced access restrictions but as far as I know the new rules module should be a solution. Hopefully someone else knows more on this. I you want to "duplicate" (actually, share) content of your main site such as menus, nodes or even users (your clients?) this is a more advanced setup. To my knowledge editing settings.php is sufficient to say per table which one has which prefix: Same prefix with main site = share data with main installation. I think this can even be done with two seperate databases.

If sharing users via table prefix and see my link list below on how you might restrict clients.example.com access to only blog owners should be all you need to do. Of course there is og but I reccon it's far to much for what you are looking for as you said yourself.

One more thing about content access: You would create a new user role for all your clients. In permission settings you'll grant only this role acces to blogs and remove them from anonymous and authorized role. But this will give all clients access to all blogs, i.e. clientA can read your and clientB's blog. So restricting it even more is what I hope can be done with my pointers below.

Since my answers are more from a theoretical standpoint someone with actual experience should throw in some statements, I guess. Maybe you don't even need a new installation at all! But that's beyond me. Hence I'd be happy to read about your solution when you have it!

Cheers.

Small list of resources about access control that I've gathered but only partly read so far:

Spot on...

joeshirley's picture

Thank you Thomas,

You're absolutely right about what I'm after. I've installed WordPress MU, and it seems a possible solution, but would prefer to keep developing my knowledge of Drupal rather than split my limited tech self-education and tinkering time.

Seems like it's safe enough to start experimenting on clients.example.com, so I'm going to take your suggestions, and follow up on reading your links, and try some things out. I can always scrap it and start over. I'll keep you posted on what I learn.

Onward...

It also sounds like the

bonobo's picture

It also sounds like the Subdomain module might be exactly what you're looking for --

http://drupal.org/project/subdomain

Cheers,

Bill


FunnyMonkey
Tools for Teachers

Domain Access, too

thomas23's picture

And I guess this should be extended to Domain Access module which is linked to by subdomain.module.

Cheers.

Not necessarily

bonobo's picture

Domain access offers more granular access control, and the ability to selectively share content across subdomains -- from what the OP described, the Subdomain module might be all that's needed.

Cheers,

Bill


FunnyMonkey
Tools for Teachers

Might be getting in over my head

joeshirley's picture

Oh, man. Thank you so much for your help so far. Bill, a quick look at the Subdomain module tells me that installing and maintaining it is over my head, unfortunately, so I'm trimming my ambitions to the basics. Thomas, the links you provided were generally helpful, thanks, although I'm not sure where Rules fits in. Things aren't going so well yet. It may be that DomainAccess will be useful, but for now my goal is to simply get a multisite installation up and running. Don't know what I'm missing. Here's what I've done:

Drupal 6.3 installed and running at my.example.com. Subdomains set up through my host (Media Temple) at newclient.example.com and newclient.my.example.com. Sites folder with the following, each with a fresh settings.php file.

sites/newclient.example.com/settings.php
sites/newclient.my.example.com/settings.php
sites/my.example.com.newclient/settings.php

When I point my browser to these urls, I get the following results:

newclient.example.com -- result = 403 Forbidden
newclient.my.example.com -- result = 403 Forbidden
my.example.com/newclient -- result = Drupal (my.example.com) with "Page not found" error.

(I've also tried editing to set $base_url = 'http://my.example.com'; in settings.php, from http://drupal.org/node/156720 about Multisite with different databases, with the same outcome.)

In looking around, I see mention of symlinks and .htaccess files, but honestly I don't know where to start. How do I get the first sub-site installed in the easiest way possible? I don't want to share anything but core Drupal for now. I'll get around to adding cross-site access for login, some content, etc. later. For now I just want the basics.

Have you pointed all your

thomas23's picture
  1. Have you pointed all your new subdomains just like your main domain to drupals base folder? That's where your web server is ought to look no matter what sites/... folder you're after. If your domain is set-up to disallow directory listing, e.g. 403 could mean just that your web server found a directory with no index document, i.e. no index.php or whatever, to show. This means drupal didn't even know about your attempt. Or is it drupal's 403 error page?
  2. I've bad experiences with "multi-level-subdomains" like your newclient.my.example.com. Since drupal has only dots as deviders I expact that drupal sees only for up to the first 3 "bits" of a sites/diretory-name as being a domain name. So if you have a folder named sub2.sub1.domain.com drupal misinterprets this and would only match it for an adress like http://sub2.sub2.domain/com, i.e. "domain" as top-level-domain and "com" as a folder. This explains the second 403 error in case it's a drupal and not web server error.
  3. The folder parts in a sites/directory name are indead confusing. Eventhough I'm not 100% sure I think they mean "web server folders" in oposed to "folders" within your drupal site, i.e. part of a web address. So if your web server root is at ../www a sites/directory-name domain.com.folder1.folder2 would match for drupal base beeing at www/folder1/folder2 for a server domain set-up example.com -> www. I haven't tried this out, though. This explains why you get drupals 404 page not found error.
  4. This all means for an adress like http://my.example.com you'll need
    • to set-up your web server, i.e. the sub domain, just like your main one to point to your drupal base folder. I assume it's www/drupal
    • have a directory named www/drupal/sites/my.example.com
    • Now you should see the install screen from drupal when entering http://my.example.com in your browser. I don't think you need to set $base_url but if you do it should be 'http://my.example.com'
    • This should really be all you need for multi-site set-up. Everything else you talk about should be handled by drupal core -- eg. blog module -- and additional contributer modules like subdomain and/or domainaccess.

Cheers.

Getting some clarity, but still no multisite

joeshirley's picture

Thanks for your help, Thomas,

The thing I'm most unclear about is, "to set-up your web server, i.e. the sub domain, just like your main one to point to your drupal base folder." What does that mean, exactly? Is this the symlink thing I've been reading about.

To test out whether part of my problem had to do with setting up my root installation in a subdomain itself, I've gone to my Drupal installation on www.example.com to give that a go, attempting to set up a second site at clients.example.com. Now, I've got an empty directory on my server at /domains/my2.example.com/html. I could install a whole new Drupal there. Instead, I've set up my root installation (example.com) with sites/my2.example.com/settings.php as the default file, no modifications. I have Drupal installed in the root directory of example.com.

Now this is where I get stuck. In the Drupal handbook, here: http://drupal.org/getting-started/5/install/multi-site, step three is "Edit the appropriate settings in your web server to point to the Drupal root directory." What do I need to do. Does this entail a new DNS record? The mysterious "symlink?" Or something else. Without this, I get the straight 403, which as you've identified is just the server saying there's nothing here for you. Drupal doesn't even get the call.

This is my weak point in all this, the server admin stuff. Can you or anyone point me to some explicit directions of what I need to do, up to (but preferably not including) running some godforsaken unix shell command (yikes!).

On a more positive note, I've been experimenting with OG. Turns out that if I use the included OG Access Configuration module, I can do pretty much what I need to do. Which leaves me wanting to just set up my client area site as a parallel but separate site to the main site. If I absolutely have to, I suppose I could maintain two different installations. But I'll want registered users to be able to pop back and forth between the sites and stay logged in. So I'll be looking for the best way to manage that. I've seen some posts here that seem to address that, so I'll dig back into those.

Drupal in root or elsewhere?

joeshirley's picture

One more thing... I've noticed several people mentioning having their Drupal installation in a /drupal directory. Is there a good reason not to run Drupal in the root of your domain? And what kind of jiggering needs to be done if you want to run www.example.com with Drupal, if you have Drupal installed in /drupal instead of the root?

Straight answer: This is no

thomas23's picture

Straight answer: This is no technical but rather a matter of comfort. If you have more than one domain on the same server space or run other stuff than drupal than it would get messy if you put everything in your webserver root directory. This would be just like installing programms in the good-ol DOS days ;) But actually it indeed is the same: You wouldn't drop every file of all your installed program on the Desktop without any folder structure, would you? If you know you'll allways use drupal on that server you don't need to worry about it.

About "Pointing your web server to /drupal":
Your provider will have some sort or another to let you configure domains or virtual hosts or subdomains or domain administration. To give you an idea I'll attach as an example from directadmin.com. Mind you this part doesn't have anything to do with drupal; it would be the same for wordpress, a forum software, or even a plain-old static html site.
What you need to look out for is a form field to set the subdomain which for you would be the my part in my.example.com. You will be given the option to select or edit a directory. This is where you put your drupal base directory but as a relative path from the web servers root. This usually means something like /drupal or if you don't have a extra subdirectory for drupal than it's just /.

Here's my directory structure

joeshirley's picture

My server root (server is virtual, on the Media Temple Grid System) looks like this:

/
/domains
/domains/example.com
/domains/example.com/html - This is where I have installed Drupal
/domains/my.example.com => example.com - This is my symlink file

When I set up an alternate domain through my host's proprietary control interface, it automatically sets up the subdomain, or any other domain I choose, to point to "the server," which is at myaccount.gridserver.com, and which is set to resolve primarily to example.com through a symlink in the /domains folder: myaccount.gridserver.com => example.com

So I do have other stuff on this server, working with no problems, including WordPress on example2.com, and WordPress MU at clients.example.com. I do want to funnel my efforts into Drupal as my primary solution, as I am tired of splitting my energy learning two different systems - my time is much better spent on developing my content.

So, a) Would you agree it seems fine for me to leave Drupal where it is? and b) Can you help me see what else I need to do, to be able to install the new Drupal site on my.example.com? Do I need to get more control over DNS/httpd.conf/symlinks/settings.php/etc. in order to make this work?

I am in the midst of talking myself into abandoning the multisite strategy and just installing a completely new solo instance of Drupal in my.example.com, and using OG to give me the appropriate separation of content and access control to set up private client blog spaces. In the long run this probably isn't the best solution, but I'm under the gun and need to get something up and running by early next week at the latest.

Cheers, and thanks for your thoughtful input.

funny provider interface

thomas23's picture

I haven't heard that one before, but never mind. In this case, though, forget what I said about not using symlinks :)

You'll need to bend my.example.com to /domains/example.com/html with ssh/putty

  1. cd /domains
  2. ln -sf example.com/html my.example.com

The f flag means force to overwrite the directory name my.example.com that is already there. If this however doesn't work because of permissions try chmod 777 my.example.com and repeat step 2. If this still doesn't work make sure to include the output from the following two commands ls -la /domains and id.

Nevertheless this should be something your provider should solve. Tell them you need to have subdomains point to the same hardrive directory as your (main) domain and ask them how you can achieve this reliably.

After this is done you need to find a way to control access rights with our suggestions above. I for now don't have experience in how this is done unfortunatelly. Good luck!

Cheers.

joeshirley's picture

OK, making progress. This thread helped me get clear about the need for a symlink and how it works: http://drupal.org/node/157697 Discovered SSH/Putty.exe, and with the help of some documentation at my hosting provider (Media Temple), was able to create a symlink. First, navigated to the "root" directory, above the directories of the various domains and subdomains on my server (cd). Then, deleted the folders for my2.example.com (rm -rf my2.example.com), and created the symlink file, (ln -s example.com my2.example.com).

This gave me some progress. Instead of a 403 error, I get a default Drupal theme with the following error:

Site off-line

The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.

If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider's database server is running. For more help, see the handbook, or contact your hosting provider.

The mysql error was: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2).

This is with the default settings.php in sites/my2.example.com/

What's the next thing I'm missing?

make sure to understand what symlinks are

thomas23's picture

if you use them. But you shouldn't need symlinks for your setup.

symlink is short for "symbolic link" and is very roughly something similar to Windows desktop icon shortcuts (at least soft links are). Anyway, for directories you can see it as just another name for the same directory. Get the difference to a copy of the directory where all content beneith it is copied, too. In oppose to a symlink that uses (allmost) no space on disc.

In Drupal the only usefull usage I'm aware of is when you want two or more domains end up in the same drupal installation. But you want the opposite; a diffenent drupal setup for each domain/subdomain.

So, again, all you need is one sites/ directory for you main installation and a second sites/ directory for your subdomain. The only places you should do any setting changes is a) via your providers administrative interface to add a subdomain "my.example.com" and b) in Drupal from http://my.example.com.

Hope this helps,
cheers.

Usefull link for db tables overview

Multisite

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: