Status_network

Sometimes you want to run a whole bunch of StatusNet sites out of a single software installation... You might, for instance, be running status.net!

StatusNet has some built-in support for this, but it can be a little hairy to set up at the moment.

status_network table

In addition to all the regular database tables that StatusNet creates, there's an optional global table for multi-site routing: status_network.

A table definition is available in db/site.sql which creates status_network and its buddy, status_network_tags.

Each status_network row lists information about one of your StatusNet sites:

• site_id -- internal ID number, do not touch
• nickname -- immutable site 'nickname', used internally for routing queue events etc to the right sites
  • the default server hostname will be the nickname plus a "wildcard" suffix (eg ".status.net") unless the next field is filled out
• hostname -- an explicit hostname to use, must be unique
  • may be empty if using the default hostname
• pathname -- an explicit URL path to use, must be unique
  • (Probably avoid this, not well tested.)
• dbhost
• dbuser
• dbpass
• dbname
  • Database server, name, and credentials to access that site's database. Keep in mind that anything that has access to this database (like StatusNet code) could access all of those databases.
• sitename
• theme
• logo
  • Override settings that can fill out a few common entries in $config['site'].
• tags -- obsolete

The status_net_tags table can store additional text 'tags' attached to each site, which can be handy for conditional configuration.

config.php

This is one of the slightly hairy parts so far... you need to sprinkle a little pixie dust in your config.php file to set up access to the status_network table and fetch some initial data for it.

You can grab this commented-out snippet from config.php.sample and stick it in your config.php

 // If you wish to store lookup data in memcached, set some servers here.
 $memcache = array(); // array('server1:11211', 'server2:11211');
 
 // If you have a lot of status networks on the same server, you can
 // store the site data in a database and switch as follows
 Status_network::setupDB('localhost', 'statusnet', 'statuspass', 'statusnet', $memcache);
 $sn = Status_network::setupSite($_server, $_path, '.status.net');
 if (!$sn) {
     print "Error\n";
     exit(1);
 }

Put the actual database hostname, DB name, user, and password in there of course! $_server and $_path are pre-populated for you by StatusNet's setup code, and are what Status_network::setupSite() uses to look up your site configuration, in combination with the provided 'wildcard' domain suffix (used to build hostnames for sites that don't override the defaults).

Warning: status_network's innards may do some surprising things such as attempt an HTTP redirect if your hostname doesn't match the recognized one!

To do conditional configuration based on the presence of tags on sites, you can add things like this to config.php:

 if ($sn->hasTag('xmpp')) {
     $config['xmpp']['enabled'] = true;
     // ...
 }

Note that you can also do individual per-site configuration in files like /etc/statusnet/foo.status.net.php; these supplementary config files will be read in after config.php when running on the appropriate site.

Command line scripts

Command-line scripts don't have a hostname or URL path in their environment, so you need to let the scripts know which site they should run as. The -s ('server') parameter is usually handy for this; pass the hostname in like so:

 ./checkschema.php -sidenti.ca

The -s parameter sets that $_server variable you saw in your config.php above.

Daemons

Note that startdaemons.sh doesn't know about this stuff, so probably won't work as-is in a multisite setup. You'll need to launch daemons manually.

queuedaemon.php (and... possibly xmppdaemon.php) support an --all parameter, which launches them in a multi-site mode. This is very handy when using the STOMP queuing support, as you can run queues for a huge number of sites without launching separate daemons. As events come in over the network connections, these daemons will dynamically switch configurations so each event is processed in the correct context.

You may still need to pass a parameter with an initial hostname to get things started:

 ./queuedaemon.php -sidenti.ca --all

As of 0.9.5, xmppdaemon.php maintains a separate XMPP connection for each site.

The Twitter bridge import daemons also do not yet support multi-site mode, and must be run separately for each site needing to use the Twitter status or friends importers.

Warnings

Multi-site mode can be a little tricky in a few places. :)

Especially when using the daemons, keep in mind that your code -- including config.php -- may be run multiple times within the same process.

Things to avoid:

• defining classes/functions directly in config.php
  • This can esplode! You can use 'function_exists' etc as guards, but be VERY careful.
• creating your own global variables in plugins
  • if not managed carefully, you could pass data around incorrectly
• keeping state in function or class 'static' variables in plugins
  • The values you kept may no longer be valid after a configuration switch.
• infinitely-growing caches
  • be aware of problems with leaking memory as well as leaking data between site configs.