Great questions, Peter... responses inline...
Peter Tribble wrote:
> On Tue, Mar 18, 2008 at 3:48 PM, Eric Reid <Eric.Reid at sun.com> wrote:
>
>> Please find attached for review:
>> OnePager
>> ManPage appendix
>> FileList appendix
>>
>> Let the games begin! :)
>>
> ...
>
>> 3. Business Summary
>> 3.1. Problem Area:
>>
>> While the Drupal development community current drives three parallel
>> release trains, 4.x, 5.x and 6.x, with the latter the most recent. It
>> is recommended that only 6.x (currently 6.x at this writing) be
>> including into SFW at this time.
>>
>
> Shouldn't that last 6.x be 6.1?
>
Good catch.
>
>
>> 4. Technical Description:
>> 4.1. Details:
>> Drupal's basic architecture provide a basic 'core' of functionality
>> (including 'core' modules), optionally augmented by additional and
>> freely available modules for additional functionality and
>> presentation.
>> The intent here is to integrate only the Drupal 6.x 'core' into SFW.
>>
>> Drupal core itself consists of less than 4MB of PHP scripts and
>> configuration files, designed to be copied into and reside in the
>> Webserver's top-level document directory. As such, no new "/usr"
>> subdirectory needs necessarily be created for Drupal installation.
>>
>> 4.2. Dependencies
>>
>> Drupal 6.x requires the following packages for configuration and
>> startup (although only a webserver top-level document directory is
>> required for 'installation'):
>>
>> MySQL 4.1 or 5.0: satisfied by SFW's /usr/mysql
>> -or-
>> Postgres 7.4 or later: satisfied by SFW's /usr/postgres/8.2
>>
>> -and-
>>
>> Apache HTTP server 1.3 or 2.x: satisfied by SFW's
>> /usr/apache2
>>
>> -and-
>>
>> PHP 5.2 or later: satisfied by SFW's /usr/php5
>>
>> 4.3. Key objects
>>
>> /var/apache2/2.2/htdocs/index.php
>> /var/apache2/2.2/htdocs/install.php
>> /var/apache2/2.2/htdocs/update.php
>>
>> /var/apache2/2.2/htdocs/sites
>>
>> /var/apache2/2.2/htdocs/themes
>>
>
> Ouch. This is going to get dumped directly into one specific instance of
> apache? What happens when apache 2.2 goes away? What happens
> when you introduce a later version of Drupal?
>
Re: webserver dir
Option 1) /usr/apache points to /usr/apache/<current>, I believe
Option 2) Search for existing webserver (or just Apache) installs at
pkg install time, allow user to pick one
Re: later versions of Drupal
It's easy enough for later Drupal 6.x installs to detect the presence
of an existing Drupal 6.x install
(via querying the pkg database, I assume). But, really, Peter, you
raise in your question an interesting
meta-question:
The initially-installed Drupal files are not inviolate -- given
installation of Drupal copies a set of
files _in their initial pre-configured state_ into someone's htdocs
directory, and given these files
can thereafter be modified, renamed, deleted, added to, etc.:
1) What does it mean to 'remove the Drupal package'? What
files are removed?
2) What does it mean to 'upgrade the Drupal package'?
>
>
>> 4.5. Directory Naming and Structure
>>
>> Drupal, as explained above, does not require a new directory entry
>> in
>> /usr, but rather 'piggybacks' on an existing Apache HTTP server
>> 'htdocs' directory. As such, the proposed directory layout for
>> Drupal 6 is:
>>
>> Where <WEBSERVER> is nominally (but not limited to)
>> /var/apache2/2.2:
>>
>> <WEBSERVER>/htdocs
>> /includes
>> /misc
>> /modules
>> /profiles
>> /scripts
>> /sites
>> /themes
>>
>
> Wouldn't it make more sense to put it somewhere separate and simply use
> httpd.conf to make it get served up as expected?
>
Yes it does, if we assume that the existing site gets 'unplugged' as a
result.
The more I think on it, the more I think having a predefined place for
Drupal 6.x files (/var/drupal/6.0 was Driram's suggestion) makes sense -
don't glom on to someone's existing DOCROOT, but instead point to this
place - also addresses the removal and upgrade issues above to some extent.
Although - there would (in any scheme) be a big caveat to admins, due to
the fact that _Drupal package_ and _user content_ files co-mingle:
remove the Drupal 6 package at the risk of losing your other web content
that you also put into the Drupal DOCROOT.
We do _not_ envision removal of the Drupal 6 package to attempt to
remove or clean out the underlying database. One could argue this leaves
'cruft' from a Drupal instance. Is there any precedence of some other
package that requires and uses MySQL or Postgres for data storage? What
does it do at package removal?
>
>> 4.6. Installation/Configuration
>>
>> The current Drupal install model consists of the following steps:
>>
>> 0) Ensure required RDBMS, webserver and PHP are installed
>> 1) Download and unpack Drupal 6 files
>> 2) Copy contents of Drupal directory to webserver's DOCROOT
>> 3) Start webserver
>> 4) Manually create Drupal database/schema
>>
>
> Presumably there are database schema files? Are those installed? Where?
>
The MySQL or Postgres database is created manually before or at Drupal 6
install time. It is the responsibility of the admin to determine where
his schema files reside, but I don't envision requiring them
to reside in the same place as the other Drupal files.
>
>> 5) Point browser to webserver; administrator is guide through
>> series of configuration steps to associate with RDBMS, and
>> set basic installation settings
>>
>
> Where are the configuration details written to? Are they written to a file
> that's mixed in with the content (this is a pretty common model)?
>
Yep... into sites/default/default.settings.php
>
>> Note: currently, existing webserver DOCROOT content should be
>> moved before install, otherwise it may be lost or corrupted.
>>
>
> So, can drupal be added to an existing webserver or does it take it over?
>
Under the proposed model, it could take over or 'merge' with it -
clearly messy... I more and more like the idea of a well-defined place
for 'the Drupal instance' - it's clear what it means to instantiate it,
to remove it, and what it might mean for any existing webserver
installation.
> What's the upgrade path for someone who already has a system with a
> working web server and goes to a release with drupal?
>
We could ask for the path to the desired webserver, rather than select
from the (currently two) that Webstack provides. But, if the webserver
is running, someone will have to bounce the server at some point --
either the installation script automagically, or the admin manually.
>
>> We do not propose any enhancement of this model for Drupal6/SFW.
>> Instead, the extent of the SVR4 SUNWdrupal6 package installation
>> will be as follows:
>>
>> 1) Copy Drupal files into existing webserver document root
>> 2) Print 'next step' configuration instructions for
>> administrator
>>
>
> I'm not sure this is enough. If that's all that's provided, I would probably
> just grab the original and run the install script through normally. The one
> thing that would make me use a vendor-supplied version of a package like
> drupal rather than grabbing the original is if all the integration work was
> done for me.
>
Point taken -- intelligent integration would be a clear value-add here,
although would add much complexity to design, engineering and
integration of package.
In general, outside of run-time optimization and well-defined 'home' for
packages, is there an implicit goal when adding Webstack packages to
provide additional value-add, be it integration or otherwise?
>
>> We also do not feel that enforcement of RDBMS/webserver/PHP
>> dependencies are appropriate at package install time. The only
>> prerequisite condition to be enforced is the existance of the target
>> webserver document root directory.
>>
>
> Given that you're explicitly using one particular instance of apache, then
> that implies a hard requirement. And you need php as well. The database
> requirement is *much* harder to express, so I think that will have to be
> left to the user until packaging allows for a "one of the following"
> dependency.
>
Agreed, this is a contradiction we must resolve in our design.
>
>> 4.8. Integration With OpenSolaris Infrastructure
>>
>> As Drupal 6 is a very lightweight mechanism, depending upon existing
>> executable mechanisms (Apache, PHP, MySQL/Postgres), there is no
>> need
>> to consider integration with OpenSolaris mechanisms such as SMF.
>>
>
> Hm. If drupal is as invasive as some of the notes imply, the one might expect
> it
> to run as a separate apache instance, which would imply that it would have a
> separate manifest that would start up apache with drupal enabled.
>
We'd like _not_ to have to juggle a 'Drupal apache instance', with the
propect of seeking unused ports, etc. Would rather seek to strike a
balance between 'using existing instance' and 'always fork a new instance'.
>
>> 4.9 Target Operating Environments
>>
>> It is expected that SUNWdrupal6 will be designed to run against (and
>> hence tested against) OpenSolaris on all supported hardware
>> platforms.
>> In addition, Drupal 6 is expected to run within OpenSolaris
>> Containers, as well as within OpenSolaris xVM dom0s and domUs.
>>
>
> How does integration with zones work, if you're dumping the files into /var
> which isn't shared between zones?
>
Great point. Most webserver _mechanisms_ live in /usr or some other
shared directory... any webserver _content_ may live in /var or some
other unsharable directory.. all of Drupal 'lives' in the latter... new
ground, methinks...
Definitely an issue we have to address right now.
> Thanks,
>
>
Thank you, Peter!
--
Eric Reid
Staff Engineer, Software
Sun Microsystems, Inc.
Phone: +1 269.629.7238
Cell: +1 269.569.1042
Fax: +1 650.352.4428
Blog: http://blogs.sun.com/err
AIM: ereidsan
SL: EricReid SunMicrosystems
