Geeklog Forums

I would like to know if someone started to work on multi sites with Geeklog 1.5.0 ?

::Ben

---

I'm available to customise your themes or plugins for your Geeklog CMS

you might ask over at gllabs.org. they might add support for it in glFusion.

---

glFusion - Technology Fused with Style - www.gllabs.org

The basic idea should still work, only that now you have to take care of two config files: db-config.php and siteconfig.php.

In fact, geeklog.info and spam.tinyweb.net are already running with such a hack in place, from the same set of files. I couldn't quite get it to work yet, though - they're currently using the same siteconfig.php. That could be an issue with my web hoster's setup, though. Just haven't had the time to look into it any further yet ...

bye, Dirk

Hi Dirk -

I guess it depends upon what is meant by 'multi-site'. I think you were referring to a configuration where you might use the same set of /private files (at least), and most of the /public_html files, with the only difference being different databases/layouts, etc. You're right - that should mostly work, and in fact I'm experimenting with that right now, however as you have said I have run into some (possibly not insurmountable) issues.

On the other hand, there may be a desire to implement 'site mirroring', eg. where you have an external load-balancer of some kind dispatching HTTP GET's to multiple identical server instances all of which share either a common database and/or session context. That last bit is the tricky part.

The crude way around this is through the implementation of 'stickiness' with the load-balancer, eg. the LB tracks which instance it gave the connection to based upon source IP or possibly even session state information in the payload (some LB's are smarter than others), but this does not really provide you with anything other than a load balancing decision based upon a single point in time (eg. some load balancing parameter/metric measured at the time of the first connection). This is only slightly better than a poke in the eye with a sharp stick. [Sorry - obscure US euphimism which is to say "not that exciting"]. In this scenario, it is probably not necessary to share realtime session information, although certainly you need to sync changes to the DB, etc.

What you really want is a methodology to share session context in a fairly real-time manner between two GL instances. This would require extensions at multiple levels to lib-sessions, MySQL, etc. which would require one GL instance to notify another of database changes and other statefully-significant information. It would also in general require a fairly bulletproof locking/collision resolution system - you obviously can't be creating (for instance) two different stories with the same sid on two different sites.

Anyway - I guess we need to develop a terminology to determine what folks are actually talking about. If you're talking about sharing a single code tree and using multiple databases on the same server to create multiple sites, the 'multiple site' term might be best, and this seems attainable, but the more scalable example I was referring to is more like a 'cluster site', and I'm thinking this is probably a bit further off.

It also may be attempting to address a niche that Geeklog in general is not trying to address, and some things are better left alone in terms of the possible complexity introduced weighed against what 90% of the folks that use Geeklog really need. This is a good example where a fork is really wanted/needed .. my two cents.

-m

Out of curiosity, how big is your site (story count, user count, hits per day) that you need load balancing? I'm wondering what your actual bottlenecks are that load balancing was the solution.

We actually toyed with the idea of deploying it on a large company's intranet (whose name is 3 capital letters), as a portal to support a PHP-based application which we wrote to describe security architectures as meta-descriptions. The idea was to provide a generic description of a compartmentalized network design which you could then compare the multiple firewall rulebases against that were deployed on the inspection points between the security zone to determine whether you were wandering outside the bounds of security policy.

The script was so darn handy and useful that it rapidly outgrew the capacity of the measly little AIX server it was sitting on. The script happened to use a DB2 backend, and that had a locking/mirroring/abstraction layer, the problem was the PHP/MySQL-based 'wrapper' we were trying to put it in.

Anyway - we ended up wrapping it in a ROR-based portal, but we did end up giving this a look to see how much work it was. It was much. Work, that is. ;^)

-m

Yes it's working. See some basic code.

::Ben

---

I'm available to customise your themes or plugins for your Geeklog CMS