Page 1 of 1

How to offer hosted installs?

Posted: Tue Mar 11, 2008 4:12 am
by AlexC
Hey,

I'd like to offer hosted installs of my project, however I'm not quite sure how to set it up (I can set the server up no problem, in fact it's already setup and working), the problem I'm having is how to setup a project install for each client.

Do I just place a copy of the latest project files into the skeleton directory (/etc/skel) and so when a new account is created, all the needed files would be there and I'd just have to run a script to create the database, needed tables etc etc etc.

The other method I thought of was putting the project files in say /usr/local/foobar and having sub-directories for each version, and a special one that would contain the latest version (ie, /usr/locale/foobar/current /usr/locale/foobar/1.0.8). From there I could just have symlinks to some of the files in the users home directory, and then it would include and use all the files in /usr/local/foobar.

One of the main problems I have is that I'd like to be able to upgrade all clients (if they want the upgrade) kind of automagically, ie - I don't want to have to go around loads of home directories and apply a set of patch files.

I'm just not sure which way to go about this, I can see issues with both ways really. Would really appreciate your input on this (sorry if this is the wrong forum to put it in).

Regards,

Re: How to offer hosted installs?

Posted: Tue Mar 11, 2008 8:34 am
by Christopher
Sounds like centralized code and symlinks are what you want. The main reason to have individual copies is if they can modify the code.

Re: How to offer hosted installs?

Posted: Wed Mar 12, 2008 1:04 am
by Chris Corbyn
Another option than symlinks is a virtual mountpoint:

Code: Select all

mount --bind /path/to/project /home/user/project
This is completely transparent to an application compared to a symlink. It becomes unfeasible if you have lots of users however.

Re: How to offer hosted installs?

Posted: Wed Mar 12, 2008 2:51 am
by AlexC
Interesting idea, Chris - why do you say it would be unfeasible if there are lots of users, though?

arborint, yeah that's the way I'm leaning towards - however my only concern is the upgrade process to a major version (or even a minor version that requires some DB changes or other changes). Lets say I keep version of the project:

/usr/local/foobar/1.0.0
/usr/local/foobar/1.0.2
/usr/local/foobar/current

The 'current' sub-directory would be a symlink to 1.0.2 (in this example) and is what all of the home directories would be using. But lets say I then release /usr/local/1.0.4 which requires a simple change to the database tables, upgrading all of the clients at once would result in the installations being broke until the changes to the database have been done. Hum, I guess there will be downtime for them during an upgrade either way, would just be better sending them a notification that they will be upgrade on foobar-date and the length of the downtime, with the option of opting-out of the upgrade?

I'll go think some more :P