[development] Install profiles tutorial for Drupal 4.7, Friday 8AM PST

Bèr Kessels ber at webschuur.com
Sun Jun 11 16:13:10 UTC 2006

Op zondag 11 juni 2006 17:06, schreef Jenny Hsueh:
> I wonder, Ber - is your sympal script a starting point to
> focus on the "deployment" aspect that we can combine the energy with
> civicspace install

You state it correct: I beleive we should focus on the underlying part first. 
The underlying part being a set of Apis and scripts to install a site, or 
more then one site. You call that deployment. 

If you want more detail on why and how read on. Else: exit; :)

And my scripts are indeed focused on deployment of Dupal site. They are a 
formalised, centralised, and reniced first version of all the "stuff" I had 
lying all over the place that I used to manage my growing flock of Drupal 
sites. I generalised these, rewrote them all in PHP (I used a lot of Ruby all 
over the place) and bound them in a single contrib. 
I use them with success to manage my host, now running 35 sites. It costs me 
no time to instal sites anymore, since I call the scripts from a webhosting 
environment (like Cpanel) called dischosting. 
Because I use them this way, they are still ery much focused on managing a 
multisite Drupal. But that is not the end-goal. The goal is, to get a solid 
installation system worked out. One that can be tied to any other system.

Example to explain my point why a route bottom up is better: Firefox: Linux, 
OSX and the likes have perfect installation and software managers, in a whole 
range of flavours. Yet even 1.5 does not manage to hook into that properly. 
The upgrade system is still a private firefox thing.  

Now: Had FF designed a solid deployment system, instead of focussing on an 
interface for upgrading, all the linux and the OSX systems would have had a 
proper integration in their native software manager. And Then they could have 
built a standalone installer and upgrade system for the folks using MS. 
(MSwindows has no proper software manageing system). ut because it was chosen 
to be done the other way around, firefox has been in  a broken state on 
Kubuntu, has not been going with the osX auto-updates, nor could Novell etc 
provide security updates for it.

If Drupal goes the same way: design and develop a Drupal-only installer, then 
we will only serve a subset of people. While, when we develop a good 
deployment system, one cuold easily keep Drupal up-to-date with e.g. apt-get 
(on debian servers) or install it using native Plesk installers. While we 
could hook a Civicspace alike web-installer to it very well, for all those 
deprived of plesk, a linux installer, or some other webhosting environment.

It should be *really* easy to tie my scripts to a CS instaler alike webform, 
or even to a single Drupal module (multisite_manager.module?). I did a proof 
of concept with a singel drupal site running of a special server on a special 
port, that had write permissions. I managed to install sites from within this 
one-ring-to-rule-all Drupal site. So you could even replace Cpanel or plesk 
with a special Drupal site! How cool is that!

-- -- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]
 Drupal repareert wederom een kritiek veiligheidslek:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060611/d2d4a188/attachment.pgp

More information about the development mailing list