Alternative Multisite Installation

developr · 2013-05-10 13:42:07

While experimenting, I probably discovered an alternative way for creating multisite installations. There are many posts about this thematic, but I found nothing about this particular method.

How it works

Like other methods, it needs a shared location for the textpattern source-code, a few symlinks and applying some patches to core files. Fortunately, there are only a few files that need relatively simple changes.

The patches

Basically, these things needs to be modified:

The definition of the *txpath*-constant in all index.php files and in css.php: using the server-variable SCRIPT_FILENAME instead of the __FILE__ constant.
The updateSitePath() function call in textpattern/index.php and textpattern/publish.php: again, using SCRIPT_FILENAME instead of the __FILE__ constant.
A new constant is required for the path to the config.php file: txpconfigpath.

We use the server-variable SCRIPT_FILENAME, because this points to a location within the webroot, while __FILE__ points to the physical storage location, which may be outside of the webroot. The constant txpconfigpath is required, because config.php must be taken out of the (shared!) textpattern directory.

Setup and Installation

To make things a bit simpler, I have prepared a zip-file containing all the changed files (for version 4.5.4) plus a tiny PHP setup-helper script. The zip-file also contains copies of the original files for comparsion.

Download ZIP

Unzip a Textpattern 4.5.4 distribution and delete the “sites” directory, because we don’t need it. Then copy the patched files over the original ones. Upload the modified source package to the server. The storage location can be outside of the webroot, but must be valid as target for symlinks.

After that, we need to customize the helper-script setup-4.5.4.php to make it usable. Right at the top of the script, is a constant txpsrcpath defined. Set this constant to the correct path of the textpattern source package. Upload the script to the site-root and run it using the browser (e.g. go to “www.yoursite.com/setup-4.5.4.php”). When done, you should remove the script, it’s not needed anymore.

The helper-script creates symlinks and copies some stuff from the source directory into the site-root. After running it you should have a site-structure like this:

/htdocs (webroot)
	/www.yoursite.com (siteroot)
		/files
		/images
		/js
		/private
		/rpc				-> symlink to src/txp-.../rpc
		/textpattern			-> symlink to src/txp-.../textpattern
		/tmp
		/css.php			-> symlink to src/txp-.../css.php
		/index.php			-> symlink to src/txp-.../index.php

As you might see, this is nearly the same structure as a standard single-site installation. The only differences are the directory private and the four symlinks.

To complete the installation, just go to “www.yoursite.com/textpattern/setup” and follow the instrutions. Remember to store the created config.php in the private directory, instead of the symlinked textpattern-folder.

Note:
The modified source-package can still be used to create single-site installations. Just upload it to the webroot and create the private-directory using your FTP-client. Then follow the standard installation steps (create the config.php in the private-dir).

Conclusion
I have tested this method on my local dev-env (win7, wampserver) and on a linux-based standard hosting, and detected no problems so far.

Now I am wondering what others think about it…

Gocom · 2013-05-10 16:02:41

The txpath constant itself supports overriding, mainly due to Sam’s multi-site script. This script and Sam’s are pretty similar, with slight structural difference. The option to pre-define the constant, allows you to do this without modifications, at least for the most part.

Since the basis is a helper script, this could be archived with one small difference. Instead of it symlinking directories, it would symlink individual files, and over load those that define the txpath. These overloader files would be the same as with Sam’s multi-site script, something along the lines of;

<?php
define('txpath', dirname(__FILE__));
include '../../src/textpattern/publish.php';

developr wrote:

We use the server-variable SCRIPT_FILENAME, because this points to a location within the webroot

I’ve seen these famous last words before. Correction; it points to the file (script) that was executed, opposed to the current file. In other words, to the application index.

Keep that mind when it comes to security. Unlike FILE, the $_SERVER['SCRIPT_FILENAME'] could be different from a request to a request, since its the file that started the execution.

My advice is that when you use $_SERVER['SCRIPT_FILENAME'], make sure you never ever include the files that extract the value and store it. Get it only in, what are strictly, index files, otherwise you get into a situation where malicious person can change the path the application thinks its in by accessing some other file than the index file.

Outside of that security con, using $_SERVER['SCRIPT_FILENAME'] also means, due to it pointing to the executed file, it will break anything where Textpattern’s source file is included/imported to somewhere else (external library, script or application).

Last edited by Gocom (2013-05-10 16:15:30)

developr · 2013-05-10 18:07:14

Gocom wrote:

Instead of it symlinking directories, it would symlink individual files, and over load those that define the txpath.

Not sure if I got the idea. Should the helper-script create the full directory structure and symlink to all individual files in the source directories? Then replace the symlinks to the files that define the txpath-constant, by a mini-php file as in your code snippet above. Is that correct?

Gocom wrote:

Correction; it points to the file (script) that was executed, opposed to the current file. In other words, to the application index.

Yes, this is what I mean. My english isn’t best… Thanks for the correction!

Gocom wrote:

make sure you never ever include the files that extract the value and store it

Should the application index store the server-var in a global variable and use this afterwards or did you mean the updateSitePath() function-call in publish.php? This statement could be changed to updateSitePath(dirname(txpath));.

Gocom wrote:

due to it pointing to the executed file, it will break anything where Textpattern’s source file is included/imported to somewhere else (external library, script or application).

I’m not sure if I understand this correctly. Is Textpattern used as part of (or within) another application?

maniqui · 2013-05-10 19:12:34

Hi Andreas,

If I got your post right, the /htdocs (webroot) folder in your setup doesn’t necessarely need to be a publicly accessible folder, right? In other words, the DocumentRoot for each website’s vhost is pointed to folder /htdocs/www.example1.com/ and /htdocs/www.example2.com/ and so on, correct?.
So, /htdocs only holds the shared stuff, and that shared stuff could even be located even outside /htdocs.

I’ve also tinkered with multi-site installs and have my own approach (and I’d dare to say, improved approach). You can read more about it here (also, this monstrous pastebin explains some stuff related to my approach to multi-site). I’ve been more “respectful” of the original multi-site approach, simplifying (imo) the way stuff is symlinked, and enabling the possibility of moving the site folder (originally at /sites/site1/) to somewhere else on the filesystem, “reattaching” it via a single symlink.

Gocom · 2013-05-10 21:03:59

In general these multi-site setups in Textpattern are pretty useless, I have to tell the truth. Whether its mine straight-symlink solution, this, as some symlink galore or Sams. The only difference compared to normal installation is that you can share source files, with the expense of creating symlinks. Its not like it makes sites to share database, assets, or helps with updating the sites or their dependencies. You still manage sites entirely individually, and have to do updating one by one. All hell breaks loose if one of the sites can not be updated too.

My personal opinion is, that all these do is add confusion, maintenance pain and complicate things hell of lot. And for the fuck sake, textpattern directory should be strictly read-only. You do not put your shit in there. The directory is for Textpattern and Textpattern only. Committing dependencies and 3rd-party code to your project’s repository is dump enough as it is.

Some actually seem to use these to help with updating which is rather strange, say the least. The multi-site setup itself is Textpattern version dependent. If its because copying source files on the same server, then copy. You can like, well, copy the files to multiple locations once. That is why CLI and simple scripting languages exists. Copy config and themes, out, delete the directory, copy new one in, restore themes and config. You can use that to auto-update as may installation as needed.

If its because of resource usage, that depends. Resolving symlinks compared to caching n1 times same files, and even that happens only if you can’t resolve duplicates. As far as I’m aware, for instance XCache uses file checksums and resolve duplicates. Each file with same contents points to same cache body (and yes, resolving is done only on cache write, doesn’t add extra overhead).

Last edited by Gocom (2013-05-10 21:20:09)

Gocom · 2013-05-10 21:16:53

developr wrote:

Not sure if I got the idea. Should the helper-script create the full directory structure and symlink to all individual files in the source directories? Then replace the symlinks to the files that define the txpath-constant, by a mini-php file as in your code snippet above. Is that correct?

Pretty much, that is how it would work. You get a solution that doesn’t require mods, gives the same directory structure. Bonus is that like with other excellently complicated multi-site configurations, the the multi-site ‘sites’ break (or have the high possibility of breaking) when you update Textpattern. I mean, directory structures can change and need to be reflected in the fake multi-site directories too. Gotta have that daily hair pulling and fixing there, right?

In all seriousness, don’t do that. Think about it for a second. The more files you symlink, the larger is the risk all independent installation break when you update Textpattern. Some of those files could be removed, some may be added. If you did what I just said, for instance, when you install 4.6, you would have to run the generator script again for any site you have created.

Should the application index store the server-var in a global variable and use this afterwards or did you mean the updateSitePath() function-call in publish.php? This statement could be changed to updateSitePath(dirname(txpath));.

Shouldn’t matter. Just hypocritical considerations.

I’m not sure if I understand this correctly. Is Textpattern used as part of (or within) another application?

It can be. The libraries could be used elsewhere in a 3rd-party script, especially on a site that is already using Textpattern.

developr · 2013-05-13 08:06:45

maniqui wrote

If I got your post right, the /htdocs (webroot) folder in your setup doesn’t necessarely need to be a publicly accessible folder, right? In other words, the DocumentRoot for each website’s vhost is pointed to folder /htdocs/www.example1.com/ and /htdocs/www.example2.com/ and so on, correct?.

I am not the server specialist, but I think when done this way, the webroot is /htdocs/www.example1.com not just /htdocs.

So, /htdocs only holds the shared stuff, and that shared stuff could even be located even outside /htdocs.

I have it outside of htdocs. But I must say, that I use this kind of setup only on my own dev system (localhost), and there only for my dev-sites. I want my dev-sites to be like normal single-site installs, not like the standard multisite-install (which I never use).

Gocom wrote

The only difference compared to normal installation is that you can share source files

That is the only reason why I use it on my localhost. I have consolidated my dev-sites using this method, it saves me some space and backup-time. However, I have no practical use for multisite installations on the web. So yes, it’s pretty useless there.

And for the fuck sake, textpattern directory should be strictly read-only. You do not put your shit in there. The directory is for Textpattern and Textpattern only.

Yes, it should be read-only. But why are the config.php and the /themes and /temp folders there?

Pretty much, that is how it would work.

I asked because I can’t believe that you really mean that. Crazy idea. LOL

Gocom · 2013-05-13 10:06:33

developr wrote:

Yes, it should be read-only. But why are the config.php and the /themes and /temp folders there?

Themes was pretty much a slip-off. One of those stupid decisions you can’t undo. As far as temp goes, that’s the default. But, you should always change that. If you leave your temporary directory to that, anyone can read your important temporary files (of course depending on how the HTTP server and PHP are configured — if they run as the same users).

For instance, rah_backup uses temporary files when writing backups. Well, if you leave your temporary directory to that default, and you do not even change its permissions, anyone can steal your database contents while the backup is being written. Ain’t that wonderful.

Even stupider shit is the find_temp_dir() Textpattern has. That shit defaults to hard-coded ./textpattern/tmp and ./your/web/root/img_dir instead of system defaults, making the function either totally useless, or you always have to go and delete directories.

In other words, the default temporary directory decisions is dump shit. The actual look-up function is totally useless too for anything other than some public image upload.

We truly should set the default to either undefined, or set it to a something like /tmp. The one that configures Textpattern, should then be able to change that to something more appropriate. The lookup function can just go to hell. We can not the temporary file be something. We could aswel hard-code it rather than search it. The result is as appropriate.

Last edited by Gocom (2013-05-13 10:09:52)

developr · 2013-05-13 11:15:56

Gocom wrote:

As far as temp goes, that’s the default. But, you should always change that.

Especially true when using such a multisite/shared source approach. Otherwise, at least users of these multisites have full access to all files within that (shared) temp.

Since Version 4.5.4, I personally use a custom update script to change the temp-dir preference for new installations.

Hope that some of these mistakes can be corrected in Version 5.

Bloke · 2013-05-13 12:40:12

Gocom wrote:

Even stupider shit is the find_temp_dir() Textpattern has

OT: Oh, man. I’ve never looked at that function before. Now I have: where’s the Brain Bleach?!

Seriously, that is awful. We gotta fix that somehow.

Last edited by Bloke (2013-05-13 12:40:29)

maverick · 2014-02-20 18:43:15

Continuing the OT

Bloke wrote #272694:

OT: Oh, man. I’ve never looked at that function before. Now I have: where’s the Brain Bleach?!

Seriously, that is awful. We gotta fix that somehow.

Out of curiosity, did this get fixed?

Textpattern CMS

Textpattern CMS support forum

#1 2013-05-10 13:42:07

Alternative Multisite Installation

#2 2013-05-10 16:02:41

Re: Alternative Multisite Installation

#3 2013-05-10 18:07:14

Re: Alternative Multisite Installation

#4 2013-05-10 19:12:34

Re: Alternative Multisite Installation

#5 2013-05-10 21:03:59

Re: Alternative Multisite Installation

#6 2013-05-10 21:16:53

Re: Alternative Multisite Installation

#7 2013-05-13 08:06:45

Re: Alternative Multisite Installation

#8 2013-05-13 10:06:33

Re: Alternative Multisite Installation

#9 2013-05-13 11:15:56

Re: Alternative Multisite Installation

#10 2013-05-13 12:40:12

Re: Alternative Multisite Installation

#11 2014-02-20 18:43:15

Re: Alternative Multisite Installation

Bloke wrote #272694:

Board footer