[consulting] managing many sites

[John Sechrest]

I assume that what you are meaning is perhaps there could be an rpm like
or dpkg like module system, so that it would be possible to have the 
same configuration repeated....

That certainly would be a step forward.

It would be nice to be able to say that A + B + C + X(config) = package-1

And then to be able to redeploy package-1 again.

How does this help me upgrade? 


In addition, given that I have a specific configuration on drupal with
specific features selected, how do I extract that into a package, without
carrying any of the content, so that I can move a config to another site,
but not take any of the users or data?


I certainly would like to be able to do module installs completely from
the inside of drupal. This would make explinations to clients easier.

However, for mass deployment, this is slow. It is much faster
to do either the tarball approach or the cvs approach. 

But this is basically the problem that you have with Civic Space.
They have a configuration and they give you are tarball, which you install
and then have to spend 20 hours tweaking.

I would like to see a way to dump a configuration (small file) which is the
abstract list of the things I need to be set. That I can apply to a different
set of versions of the same modules, and have it come up functioning nearly the same.


In addition, I would like to be able to have configuration states.
For example, I have used drupal in a class. Before the class, I wanted students
to register, but not really be able to do much. At the beginning of the class,
the number of options and modules needed to be low, in the middle of the class,
I have more features turned on. And now that the class is over, I have given
access, but not write permission to the site. 

I would like to be able to name these states and automate them, and manage them,
so that I can replicate the abstract behavior across many different drupal 
instances (classes)

Right now, it feels like this is a development issue at some level. But 
it would be useful to understand how you as consultants are managing this task
by hand.



puregin <puregin at puregin.org> writes:

 % This is a totally different approach, but for those of us living in  
 % the Linux
 % world, perhaps packaging Drupal builds as RPMs (or Debian packages)
 % would be an option.
 % 
 % This would allow periodic updates on modern systems via yum or
 % equivalent.   This would handle packaging, signing, pre-install
 % and post-install actions, etc. asynchronously.  There's still the
 % problem of outdated modules, but that's going to be an issue with
 % any approach.  One could specify not to upgrade if a specific
 % module is too old...
 % 
 % This might also make initial installation easier for people...
 % 
 % Cheers, Djun
 % 
 % On 12-Dec-2005, at 11:18 PM, Karoly Negyesi wrote:
 % 
 % >> Generally, I would say that this is not terribly easy.  One thing  
 % >> that
 % >> I am really impressed with in the world of updates is the way that
 % >> Firefox periodically checks for updates and then downloads the
 % >> necessary files and patches itself.  The same system works for
 % >
 % > Sure thing. We could RSS the core updates, maybe sprinkle with  
 % > crypo, that's something the horde of Drupal developers could easily  
 % > tackle. There is a minor glitch though: Apache is rarely configured  
 % > in a way so that in can write the PHP scripts it runs...
 % >
 % > Regards
 % >
 % > NK
 % > _______________________________________________
 % > consulting mailing list
 % > consulting at drupal.org
 % > http://lists.drupal.org/mailman/listinfo/consulting
 % 
 % _______________________________________________
 % consulting mailing list
 % consulting at drupal.org
 % http://lists.drupal.org/mailman/listinfo/consulting
 % 

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest at peak.org
                                      .   
                                              . http://www.peak.org/~sechrest