|
Replies:
11
-
Last Post:
Jun 13, 2008 4:19 PM
by: oshttpd
|
|
|
Posts:
62
From:
US
Registered:
12/5/07
|
|
|
|
DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 8:48 AM
|
|
Please find attached for review:
OnePager
ManPage appendix
FileList appendix
Let the games begin! :)
--
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
Template Version: @(#)onepager.txt 1.31 07/08/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Deliver Drupal6.x into OpenSolaris
1.2. Name of Document Author/Supplier:
Author: Eric Reid
1.3 Date of This Document:
18 March, 2008
1.4. Name of Major Document Customer(s)/Consumer(s):
1.4.1. The Community you expect to review your project:
Webstack
1.4.2. The ARC(s) you expect to review your project:
LSARC
1.5. Email Aliases:
1.5.2. Responsible Engineer: eric dot reid at sun dot com
1.5.4. Interest List: webstack-discuss at opensolaris dot org
2. Project Summary
2.1. Project Description:
Integate Drupal 6.x Open Source Content Management System into SFW
area of OpenSolaris. Initial delivery of Drupal 6.1 is targeted
into Build 90, but later Drupal 6.x instances will likely be
included into later builds.
2.2. Risks and Assumptions:
Primary risks have surrounded issues identified around installing
Drupal 6 onto Webstack [2]. We believe, however, this issues have
been addressed in b83 forward.
It is assumed the existance of MySQL, Postgres, Apache HTTP server
and PHP within any release of OpenSolaris which will include Drupal 6.
3. Business Summary
3.1. Problem Area:
Drupal is an Open Source Content Management System which has become
one of the most popular offerings of its kind, consistently ranking
in the top two Open Source Content Management Systems for the past
2-3 years. Developed in 2001, Drupal's popularity and 'buzz' has
skyrocketed in the past 12 months, in part to its reputation for
being powerful, robust, extensible and easily configurable.
For more information about Drupal see http://drupal.org.
Written in PHP, and available across many platforms, Drupal requires
a web server (usually Apache) and an RDBMS (usually MySQL or Postgres).
Drupal has already been demonstrated to perform and scale on Solaris
and OpenSolaris as well or better than other Operating Environments.
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.
3.2. Market/Requester:
Sun Microsystems' Open Solaris/Indiana 'Cabinet'.
3.3. Business Justification:
Drupal's popularity and excellent performance on Solaris make it
an excellent candidate for upcoming Indiana repository.
3.4. Competitive Analysis:
3.5. Opportunity Window/Exposure:
3.6. How will you know when you are done?:
Drupal 6.x release will be available as part of OpenSolaris, and
will install and behave identically to the Community-provided Drupal
6.x.
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
4.4. Versioning
See also [1].
The versioning model for Drupal releases is <major>.<minor>
The compatibility expectations for Drupal are as follows:
(1) Versions within the same Major Release are considered compatible -
that is, they have the same underlying structure, and all modules
for that Major Release are compatible.
(2) Versions with differing Major Release numbers are not considered
compatible
At the time of writing, the latest version of Drupal 6 is 6.1. The
Drupal community has been known to release new Minor Releases in as
little as two weeks (in the case of security releases), but usually
new Minor Releases happen in the span of a few months.
There are no plans at this point to integrate Drupal 4 or Drupal 5
into SFW. Additionally, there will be a separate ARC case at such time
that Drupal 7.X is to be added into SFW.
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
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
5) Point browser to webserver; administrator is guide through
series of configuration steps to associate with RDBMS, and
set basic installation settings
Note: currently, existing webserver DOCROOT content should be
moved before install, otherwise it may be lost or corrupted.
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
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.
4.7. Internationalization
While localized versions of Drupal 6 core files are available from
the Drupal Community, we do not feel it appropriate to include them,
and therefore open the "pandora's box" of which to include.
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.
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.
4.10. Drupal Documentation
As with most "Web 2.0" offerings, most of the documentation for
Drupal existing "within the network cloud", and therefore is not
included with the set of files commonly downloaded and installed.
We see no need to create or import significant amounts of
documentation into the SFW package, as this would only serve to
confuse the audience.
An overview man page for "drupal" will be created and added to
/usr/share/man/; as there is no "drupal" command, per se, the command
will be added to the 1M section in /usr/share/man/man1m.
4.11. Packaging and Delivery
We propose to package Drupal 6 into a single package, named
SUNWdrupal6. This naming scheme will allow for future coexistence
of multiple versions of Drupal within SFW.
4.12. Drupal 6 Interfaces
4.12.1. Interface Stability
Within Major Releases, Drupal is guaranteed to have compatible
interfaces, and therefore no interface instability is expected within
Drupal 6.x.
4.12.2. Imported Interfaces
NAME STABILITY NOTES
MySQL Server Committed LSARC/2007/608
/usr/php5/[version]/bin/php Uncommitted LSARC/2007/168
/usr/php5/[version]/php.ini Uncommitted LSARC/2007/168
Postgres Committed LSARC/2006/655
/usr/apache2/[version] Uncommitted LSARC/2007/586
/var/apache2/[version]/htdocs Uncommitted LSARC/2007/586
4.12.3. Exported Interfaces
NAME STABILITY NOTES
SUNWdrupal6 committed package
drupal6 umbrella Man Page committed man page
5. Reference Documents:
[1] http://drupal.org/handbook/version-info#contrib
[2] http://opensolaris.org/jive/thread.jspa?messageID=206153
6. Resources and Schedule:
6.1. Projected Availability:
6.2. Cost of Effort:
6.4. Product Approval Committee requested information:
6.4.1. Consolidation or Component Name: SFW
Build 90
6.4.8. Target Code Design Review Date:
In time for Build 90
6.5. ARC review type:
FastTrack
6.6. ARC Exposure: open
6.6.1. Rationale: Part of OpenSolaris
7. Prototype Availability:
7.1. Prototype Availability:
Before 28 March 2008
7.2. Prototype Cost:
Appendix: Drupal man page
User Commands DRUPAL(1M)
NAME
drupal - a robust and extensible content management system
DESCRIPTION
drupal consists of a collection of PHP scripts and configuration
files, intended to reside within the DOCROOT of an existing web
server (usually apache2). It assumes an installed web server, RDBMS
and PHP language.
FILES
Drupal 6 files are integrated with Solaris, and can be installed and
configured into the Solaris apache2 web server.
CHANGELOG.txt Standard Drupal doc and instruction files
COPYRIGHT.txt
INSTALL.mysql.txt
INSTALL.pgsql.txt
INSTALL.txt
LICENSE.txt
MAINTAINERS.txt
robots.txt
UPGRADE.txt
cron.php Standard Drupal PHP files for initial site
index.php configuration and deployment
install.php
update.php
xmlrpc.php
includes Standard Drupal directories
misc
modules
profiles
scripts
sites
themes
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWdrupal6 |
|_____________________________|_____________________________|
SEE ALSO
attributes(5)
http://www.drupal.org
http://www.sun.com/drupal
AUTHOR
Appendix 1: Drupal 6 Directory and File Structure.
1. The following files are included in the Drupal 6 integration:
<WEBSERVER DOCUMENT ROOT>
CHANGELOG.txt
COPYRIGHT.txt
cron.php
index.php
INSTALL.mysql.txt
INSTALL.pgsql.txt
install.php
INSTALL.txt
LICENSE.txt
MAINTAINERS.txt
robots.txt
update.php
UPGRADE.txt
xmlrpc.php
./includes:
actions.inc
batch.inc
bootstrap.inc
cache.inc
cache-install.inc
common.inc
database.inc
database.mysql-common.inc
database.mysqli.inc
database.mysql.inc
database.pgsql.inc
file.inc
form.inc
image.gd.inc
image.inc
install.inc
install.mysqli.inc
install.mysql.inc
install.pgsql.inc
language.inc
locale.inc
mail.inc
menu.inc
module.inc
pager.inc
path.inc
session.inc
tablesort.inc
theme.inc
theme.maintenance.inc
unicode.inc
xmlrpc.inc
xmlrpcs.inc
./misc:
ahah.js
arrow-asc.png
arrow-desc.png
autocomplete.js
batch.js
blog.png
collapse.js
draggable.png
drupal.js
druplicon.png
favicon.ico
feed.png
form.js
forum-closed.png
forum-default.png
forum-hot-new.png
forum-hot.png
forum-new.png
forum-sticky.png
grippie.png
jquery.form.js
jquery.js
menu-collapsed.png
menu-collapsed-rtl.png
menu-expanded.png
menu-leaf.png
powered-black-135x42.png
powered-black-80x15.png
powered-black-88x31.png
powered-blue-135x42.png
powered-blue-80x15.png
powered-blue-88x31.png
powered-gray-135x42.png
powered-gray-80x15.png
powered-gray-88x31.png
print.css
print-rtl.css
progress.gif
progress.js
tabledrag.js
tableheader.js
tableselect.js
teaser.js
textarea.js
throbber.gif
tree-bottom.png
tree.png
watchdog-error.png
watchdog-ok.png
watchdog-warning.png
xml.png
./misc/farbtastic:
farbtastic.css
farbtastic.js
marker.png
mask.png
wheel.png
./modules:
README.txt
./modules/aggregator:
aggregator.admin.inc
aggregator.css
aggregator-feed-source.tpl.php
aggregator.info
aggregator.install
aggregator-item.tpl.php
aggregator.module
aggregator.pages.inc
aggregator-rtl.css
aggregator-summary-items.tpl.php
aggregator-summary-item.tpl.php
aggregator-wrapper.tpl.php
./modules/block:
block-admin-display-form.tpl.php
block.admin.inc
block.css
block.info
block.install
block.js
block.module
./modules/blog:
blog.info
blog.module
blog.pages.inc
./modules/blogapi:
blogapi.info
blogapi.install
blogapi.module
./modules/book:
book.admin.inc
book-all-books-block.tpl.php
book.css
book-export-html.tpl.php
book.info
book.install
book.module
book-navigation.tpl.php
book-node-export-html.tpl.php
book.pages.inc
book-rtl.css
./modules/color:
color.css
color.info
color.install
color.js
color.module
color-rtl.css
./modules/color/images:
hook.png
hook-rtl.png
lock.png
./modules/comment:
comment.admin.inc
comment.css
comment-folded.tpl.php
comment.info
comment.install
comment.js
comment.module
comment.pages.inc
comment-rtl.css
comment.tpl.php
comment-wrapper.tpl.php
./modules/contact:
contact.admin.inc
contact.info
contact.install
contact.module
contact.pages.inc
./modules/dblog:
dblog.admin.inc
dblog.css
dblog.info
dblog.install
dblog.module
dblog-rtl.css
./modules/filter:
filter.admin.inc
filter.info
filter.install
filter.module
filter.pages.inc
./modules/forum:
forum.admin.inc
forum.css
forum-icon.tpl.php
forum.info
forum.install
forum-list.tpl.php
forum.module
forum.pages.inc
forum-rtl.css
forums.tpl.php
forum-submitted.tpl.php
forum-topic-list.tpl.php
forum-topic-navigation.tpl.php
./modules/help:
help.admin.inc
help.css
help.info
help.module
help-rtl.css
./modules/locale:
locale.css
locale.info
locale.install
locale.module
./modules/menu:
menu.admin.inc
menu.info
menu.install
menu.module
./modules/node:
content_types.inc
node.admin.inc
node.css
node.info
node.install
node.module
node.pages.inc
node-rtl.css
node.tpl.php
./modules/openid:
login-bg.png
openid.css
openid.inc
openid.info
openid.install
openid.js
openid.module
openid.pages.inc
xrds.inc
./modules/path:
path.admin.inc
path.info
path.module
./modules/php:
php.info
php.install
php.module
./modules/ping:
ping.info
ping.module
./modules/poll:
poll-bar-block.tpl.php
poll-bar.tpl.php
poll.css
poll.info
poll.install
poll.module
poll.pages.inc
poll-results-block.tpl.php
poll-results.tpl.php
poll-rtl.css
poll-vote.tpl.php
./modules/profile:
profile.admin.inc
profile-block.tpl.php
profile.css
profile.info
profile.install
profile.js
profile-listing.tpl.php
profile.module
profile.pages.inc
profile-wrapper.tpl.php
./modules/search:
search.admin.inc
search-block-form.tpl.php
search.css
search.info
search.install
search.module
search.pages.inc
search-results.tpl.php
search-result.tpl.php
search-rtl.css
search-theme-form.tpl.php
./modules/statistics:
statistics.admin.inc
statistics.info
statistics.install
statistics.module
statistics.pages.inc
./modules/syslog:
syslog.info
syslog.module
./modules/system:
admin.css
admin-rtl.css
block.tpl.php
box.tpl.php
defaults.css
defaults-rtl.css
maintenance.css
maintenance-page.tpl.php
page.tpl.php
system.admin.inc
system.css
system.info
system.install
system.js
system-menus.css
system-menus-rtl.css
system.module
system-rtl.css
./modules/taxonomy:
taxonomy.admin.inc
taxonomy.css
taxonomy.info
taxonomy.install
taxonomy.js
taxonomy.module
taxonomy.pages.inc
./modules/throttle:
throttle.admin.inc
throttle.info
throttle.module
./modules/tracker:
tracker.css
tracker.info
tracker.module
tracker.pages.inc
./modules/translation:
translation.info
translation.module
translation.pages.inc
./modules/trigger:
trigger.admin.inc
trigger.info
trigger.install
trigger.module
./modules/update:
update.compare.inc
update.css
update.fetch.inc
update.info
update.install
update.module
update.report.inc
update-rtl.css
update.settings.inc
./modules/upload:
upload.admin.inc
upload.info
upload.install
upload.module
./modules/user:
user.admin.inc
user.css
user.info
user.install
user.js
user.module
user.pages.inc
user-picture.tpl.php
user-profile-category.tpl.php
user-profile-item.tpl.php
user-profile.tpl.php
user-rtl.css
./profiles:
./profiles/default:
default.profile
./scripts:
code-clean.sh
code-style.pl
cron-curl.sh
cron-lynx.sh
drupal.sh
./sites:
./sites/all:
README.txt
./sites/default:
default.settings.php
./themes:
README.txt
./themes/bluemarine:
block.tpl.php
bluemarine.info
box.tpl.php
comment.tpl.php
logo.png
node.tpl.php
page.tpl.php
screenshot.png
style.css
style-rtl.css
./themes/chameleon:
background.png
chameleon.info
chameleon.theme
common.css
common-rtl.css
logo.png
screenshot.png
style.css
style-rtl.css
./themes/chameleon/marvin:
bullet.png
druplicon-watermark.png
druplicon-watermark-rtl.png
logo.png
marvin.info
screenshot.png
style.css
style-rtl.css
./themes/engines:
./themes/engines/phptemplate:
phptemplate.engine
./themes/garland:
block.tpl.php
comment.tpl.php
fix-ie.css
fix-ie-rtl.css
garland.info
logo.png
maintenance-page.tpl.php
node.tpl.php
page.tpl.php
print.css
screenshot.png
style.css
style-rtl.css
template.php
./themes/garland/color:
base.png
color.inc
preview.css
preview.png
./themes/garland/images:
bg-bar.png
bg-bar-white.png
bg-content-left.png
bg-content.png
bg-content-right.png
bg-navigation-item-hover.png
bg-navigation-item.png
bg-navigation.png
bg-tab.png
body.png
gradient-inner.png
menu-collapsed.gif
menu-collapsed-rtl.gif
menu-expanded.gif
menu-leaf.gif
task-list.png
./themes/garland/minnelli:
logo.png
minnelli.css
minnelli.info
screenshot.png
./themes/garland/minnelli/color:
base.png
color.inc
preview.png
./themes/pushbutton:
arrow-next-hover.png
arrow-next-hover-rtl.png
arrow-next.png
arrow-next-rtl.png
arrow-next-visited.png
arrow-next-visited-rtl.png
arrow-prev-hover.png
arrow-prev-hover-rtl.png
arrow-prev.png
arrow-prev-rtl.png
arrow-prev-visited.png
arrow-prev-visited-rtl.png
arrow-up-hover.png
arrow-up.png
arrow-up-visited.png
background.png
block.tpl.php
box.tpl.php
comment.tpl.php
forum-container.jpg
forum-container-rtl.jpg
forum-link.png
forum-link-rtl.png
header-a.jpg
header-b.jpg
header-b-rtl.jpg
header-c.png
icon-block.png
icon-block-rtl.png
icon-comment.png
icon-comment-rtl.png
logo-active.jpg
logo-active-rtl.jpg
logo-background.jpg
logo-background-rtl.jpg
logo-hover.jpg
logo-hover-rtl.jpg
logo.png
node.tpl.php
page.tpl.php
pushbutton.info
screenshot.png
style.css
style-rtl.css
tabs-off.png
tabs-off-rtl.png
tabs-on.png
tabs-on-rtl.png
tabs-option-hover.png
tabs-option-hover-rtl.png
tabs-option-off.png
tabs-option-off-rtl.png
tabs-option-on.png
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
Posts:
542
From:
US
Registered:
11/22/05
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 11:44 AM
in response to: erreid
|
|
If in case, you are going to bundle this within Open Solaris, would it
not make better sense to place it under /var/drupal/6.0 ? This way, it
is not very tied to web server's particular version and location
thanks
sriram
Eric Reid wrote:
> Please find attached for review:
> OnePager
> ManPage appendix
> FileList appendix
>
> Let the games begin! :)
>
> ------------------------------------------------------------------------
>
> _______________________________________________
>
>
> webstack-discuss mailing list
> webstack-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
62
From:
US
Registered:
12/5/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 6:30 PM
in response to: srinatar
|
|
S -
Look at what an 'install' means from Drupal here... all the files can
come out of package and be moved right into a default or a user-selected
webserver htdocs directory -- unlike most SFW packages, Drupal won't
"live" anywhere, except parasitically within a webserver's directory
structure.
Now, if we want to extract Drupal 6 files from the package and into a
'home' resting place, which could persist after the files are copied
into the htdocs directory, then the question makes sense -- problem is,
I don't see too much value in keeping a copy of the 'pre-deployed'
Drupal files around, separate from the 'installed' copy, do you?
ERR
Sriram Natarajan wrote:
> If in case, you are going to bundle this within Open Solaris, would it
> not make better sense to place it under /var/drupal/6.0 ? This way, it
> is not very tied to web server's particular version and location
>
> thanks
> sriram
>
> Eric Reid wrote:
>> Please find attached for review:
>> OnePager
>> ManPage appendix
>> FileList appendix
>>
>> Let the games begin! :)
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>>
>>
>> webstack-discuss mailing list
>> webstack-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
--
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
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
542
From:
US
Registered:
11/22/05
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 11:46 PM
in response to: erreid
|
|
Well, in a production environment, customer might choose to keep their
document directories in a more segregated fashion depending on their
virtual server setup. In this case, I am not sure, if you would very
much want to associate your installation to a particular location of web
server (read apache 2.2) content files.
Besides, tying the "installed" location too close to a particular
version of web server also makes it a maintenance headache for your
team . Other web servers like Sun Java System web server or Apache 2.4
will not be able to take advantage of this integration. However, if you
had a consistent "pre deployed" location (say /var/drupal/6.0) and an
associated /etc/apache2/2.2/conf.d/drupal.conf then you provide both a
seamless integration as well as support for re usability with other
versions of web server
just 2c
- sriram
Eric Reid wrote:
> S -
>
> Look at what an 'install' means from Drupal here... all the files can
> come out of package and be moved right into a default or a user-selected
> webserver htdocs directory -- unlike most SFW packages, Drupal won't
> "live" anywhere, except parasitically within a webserver's directory
> structure.
>
> Now, if we want to extract Drupal 6 files from the package and into a
> 'home' resting place, which could persist after the files are copied
> into the htdocs directory, then the question makes sense -- problem is,
> I don't see too much value in keeping a copy of the 'pre-deployed'
> Drupal files around, separate from the 'installed' copy, do you?
>
> ERR
>
>
> Sriram Natarajan wrote:
>
>> If in case, you are going to bundle this within Open Solaris, would it
>> not make better sense to place it under /var/drupal/6.0 ? This way, it
>> is not very tied to web server's particular version and location
>>
>> thanks
>> sriram
>>
>> Eric Reid wrote:
>>
>>> Please find attached for review:
>>> OnePager
>>> ManPage appendix
>>> FileList appendix
>>>
>>> Let the games begin! :)
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>>
>>>
>>> webstack-discuss mailing list
>>> webstack-discuss at opensolaris dot org
>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>>
>
>
>
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
304
From:
IN
Registered:
4/30/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 19, 2008 2:55 AM
in response to: srinatar
|
|
Sriram Natarajan wrote:
>Well, in a production environment, customer might choose to keep their
>document directories in a more segregated fashion depending on their
>virtual server setup. In this case, I am not sure, if you would very
>much want to associate your installation to a particular location of web
>server (read apache 2.2) content files.
>
>Besides, tying the "installed" location too close to a particular
>version of web server also makes it a maintenance headache for your
>team . Other web servers like Sun Java System web server or Apache 2.4
>will not be able to take advantage of this integration. However, if you
>had a consistent "pre deployed" location (say /var/drupal/6.0) and an
>associated /etc/apache2/2.2/conf.d/drupal.conf then you provide both a
>seamless integration as well as support for re usability with other
>versions of web server
>
>
>
+1
It is easier to upgrade, install multiple versions if Drupal is placed
in a separate location.
If this cannot be done for some reason (which I doubt), then it should
at least
be installed in a subdirectory under htdocs ... like
.../htdocs/drupal6/include
/misc
/modules
...
-- Seema.
>Eric Reid wrote:
>
>
>>S -
>>
>>Look at what an 'install' means from Drupal here... all the files can
>>come out of package and be moved right into a default or a user-selected
>>webserver htdocs directory -- unlike most SFW packages, Drupal won't
>>"live" anywhere, except parasitically within a webserver's directory
>>structure.
>>
>>Now, if we want to extract Drupal 6 files from the package and into a
>>'home' resting place, which could persist after the files are copied
>>into the htdocs directory, then the question makes sense -- problem is,
>>I don't see too much value in keeping a copy of the 'pre-deployed'
>>Drupal files around, separate from the 'installed' copy, do you?
>>
>>ERR
>>
>>
>>Sriram Natarajan wrote:
>>
>>
>>
>>>If in case, you are going to bundle this within Open Solaris, would it
>>>not make better sense to place it under /var/drupal/6.0 ? This way, it
>>>is not very tied to web server's particular version and location
>>>
>>>thanks
>>>sriram
>>>
>>>Eric Reid wrote:
>>>
>>>
>>>
>>>>Please find attached for review:
>>>> OnePager
>>>> ManPage appendix
>>>> FileList appendix
>>>>
>>>>Let the games begin! :)
>>>>
>>>>------------------------------------------------------------- -----------
>>>>
>>>>_______________________________________________
>>>>
>>>>
>>>>webstack-discuss mailing list
>>>>webstack-discuss at opensolaris dot org
>>>>http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>>>
>>>>
>>>>
>>
>>
>>
>_______________________________________________
>
>
>webstack-discuss mailing list
>webstack-discuss at opensolaris dot org
>http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>
>
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
36
From:
Registered:
4/10/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 11:54 AM
in response to: erreid
To: Projects » webstack » discuss
|
|
How about we put out a Drupal IPS pkg on the experimental web stack IPS repsository to start with? This way, we don't have to wait until after its integration to be complete. Jyri might have pointers on how to get started with that.
cvr
|
|
|
|
|
Posts:
62
From:
US
Registered:
12/5/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 6:31 PM
in response to: oshttpd
|
|
Absolutely open to that... any pointers appreciated!
ERR
Murthy Chintalapati wrote:
> How about we put out a Drupal IPS pkg on the experimental web stack IPS repsository to start with? This way, we don't have to wait until after its integration to be complete. Jyri might have pointers on how to get started with that.
>
> cvr
> This message posted from opensolaris.org
>
> _______________________________________________
>
>
> webstack-discuss mailing list
> webstack-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>
--
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
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
1,575
From:
GB
Registered:
4/27/05
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 12:22 PM
in response to: erreid
|
|
On Tue, Mar 18, 2008 at 3:48 PM, Eric Reid <Eric dot Reid at sun dot 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?
> 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?
> 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?
> 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?
> 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)?
> 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?
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 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.
> 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.
> 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.
> 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?
Thanks,
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
62
From:
US
Registered:
12/5/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 19, 2008 4:32 AM
in response to: ptribble
|
|
Great questions, Peter... responses inline...
Peter Tribble wrote:
> On Tue, Mar 18, 2008 at 3:48 PM, Eric Reid <Eric dot Reid at sun dot 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
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
716
From:
Registered:
7/13/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Mar 18, 2008 9:57 PM
in response to: erreid
|
|
Eric Reid wrote:
>
> Deliver Drupal6.x into OpenSolaris
We've been talking about how there's going to need to be some careful
analysis of the approach on integrating pure webapps like this one.
We're waiting for the first case to come through so the discussions
can be had in a concrete context. Looks like Drupal is the first one
so it gets to do the hard work to pave the way...
I see a number of editorial corrections to the ARC case, but I'll defer
those for now so we can cover the main issues first.
Peter had a lot of good questions, I'll try not to repeat too many of
the same.
> 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 presentati
> The intent here is to integrate only the Drupal 6.x 'core' into SFW.
How and where are users expected to install the modules? By adding
subdirs under 'modules'? Will that be supported? Where/how are they
configured?
> 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.
Please classify the delivered files into
a) those which are always read-only (i.e. the core "binaries" of the
implementation)
b) those which are may be edited by users to customize the system (if any)
c) those which are always written into, such as configuration and log files
This will help understand what's what and where should things go.
BTW does Drupal need/recommend any configuration in apache config files?
> MySQL 4.1 or 5.0: satisfied by SFW's /usr/mysql
BTW you'll want to depend on /usr/mysql/5.0 not MySQL4 (which is going away).
> /var/apache2/2.2/htdocs/index.php
The package can't install right onto top level htdocs. This isn't the
only web app content package (well, it is today, but presumably if it
goes in, many others will follow). It'll need to peacefully coexist
with other content. It might possibly install into a dedicated subdir
of htdocs.
Later in the spec there is this scary warning:
> Note: currently, existing webserver DOCROOT content should be
> moved before install, otherwise it may be lost or corrupted.
which suggest maybe it can't get along peacefully with other docroot content?
What's the issue there?
> Drupal, as explained above, does not require a new directory entry
> /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:
Can you expand on "(but not limited to)" given the context of the package?
The primary decision to make is the main install location. Viable
options I see are:
a) Somewhere under htdocs (but not at the top level) Main drawback
here is that OpenSolaris is still also distributed as DVD images
with all the packages. But not everyone wants drupal in their
docroot (really, most people don't). If OpenSolaris had already
transitioned to a IPS-only distribution model this would be a
non-issue since nobody would install SUNWdrupal6 unless they really
wanted it. But that world is still some ways away.
b) Somewhere under /usr and you provide a script a user can run to
hook it up into the final location (and the script can do
additional groundwork beyond just bits).
c) Nowhere - tell users to get it from drupal.org. This option needs to
be considered. If options a|b don't make life easier for the user
(or worse, make it harder by e.g. having very stale content) then
this might be a viable option. I don't know if it is, but I'll want to
see a section in the ARC case analyzing why it's not ;-)
As Peter said, SUNWdrupal6 needs to provide some value-add over simply
grabbing the bits from drupal.org. Preconfiguration, seamless integration,
"works out of the box", etc.. are all potential good reasons.
> 4.6. Installation/Configuration
[...]
> 4) Manually create Drupal database/schema
Manually by running some provided script, or literally "manually" by
telling the user to start typing in SQL?
> We also do not feel that enforcement of RDBMS/webserver/PHP
> dependencies are appropriate at package install time. The only
Clearly it'll need to depend on apache22 and php5 packages. The db
dependency is more complex, because either MySQL or Postgres can
fulfill the role, so you don't want to hardcode one or the other
(certainly not both ;-) so no good answer there.
> 4.7. Internationalization
>
> While localized versions of Drupal 6 core files are available from
> the Drupal Community, we do not feel it appropriate to include them,
> and therefore open the "pandora's box" of which to include.
How about all of them? If not, why not? (In general for an ARC case,
you'll want to document the reasoning of any given decision.)
> 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.
... and it should be the correct reason or it'll get nitpicked ;-)
The correct reason not to implement SMF is not because drupal is a
"lightweight mechanism". It's because (I'm assuming) one doesn't start
drupal, one starts apache, which is already hooked into smf.
> 4.11. Packaging and Delivery
>
> We propose to package Drupal 6 into a single package, named
> SUNWdrupal6.
IFF the install location ends up being tied to Apache 2.2 then you'll
want to name the package so it reflects that, as some of the other
apache22-dependent modules have done.
> This naming scheme will allow for future coexistence
> of multiple versions of Drupal within SFW.
The package name alone doesn't achieve that... if you need to support
versioning of the app, the install location needs some versioning as
well, or the future package will just stomp on this one.
> 4.12.3. Exported Interfaces
>
> NAME STABILITY NOTES
>
> SUNWdrupal6 committed package
> drupal6 umbrella Man Page committed man page
If modules (see earlier) are supported, that's an interface.
Are there config interfaces/files (other than the GUI itself)?
--
Jyri J. Virkki - jyri dot virkki at sun dot com - Sun Microsystems
_______________________________________________
webstack-discuss mailing list
webstack-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
|
|
|
|
|
Posts:
1
From:
CA
Registered:
4/17/08
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Apr 17, 2008 9:42 AM
in response to: jyri
To: Projects » webstack » discuss
|
|
Hi -- I'm a long time member of the Drupal community, and I thought I'd offer some perspective. Feel free to contact me directly if there is anything else I can do to help.
First of all, a base Drupal install supports "multisite" operations out of the box. The default website is at /sites/default -- additional sites / domains can be created by simply creating additional folders underneath /sites. e.g. /sites/example.com.
To start serving example.com from the Drupal install, simply configure httpd.conf to point to the top level drupal folder -- index.php detects and routes to the appropriate domain based on the contents of the /sites folder.
This multisite support is probably a good argument for putting drupal somewhere like /usr/drupal6
> How and where are users expected to install the
> modules? By adding
> subdirs under 'modules'? Will that be supported?
> Where/how are they
> configured?
Typically, they are installed in one of two locations per best practices.
/sites/all/modules -- available to all sites
/sites/example.com/modules -- installed on a per site / domain basis and available only to that site
> > 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.
>
> Please classify the delivered files into
>
> a) those which are always read-only (i.e. the core
> "binaries" of the
> implementation)
> those which are may be edited by users to customize
> the system (if any)
> c) those which are always written into, such as
> configuration and log files
>
> This will help understand what's what and where
> should things go.
The only files / directories which should be user editable / customizable all live inside the /sites folder. I'll skip locations for modules as described above, here are the other files in particular:
/sites/example.com/settings.php -- part of install sets this, this is where DB user / pass lives
/sites/example.com/files -- site specific files, permissions need to be set for webserver write
/sites/example.com/tmp -- site specific tmp folder
/sites/example.com/themes -- site specific themes, and this is likely the place where users will edit / update CSS, PHP template files, etc.
As mentioned under the modules section, things could also be placed under /sites/all -- but if you would like to support / encourage multisite, I would recommend doing it on a per site basis.
The only other spot that might have user downloadable files is the top level /profiles directory -- where Drupal install profiles can be downloaded.
> BTW does Drupal need/recommend any configuration in
> apache config files?
It's designed to run "out of the box" on random *** shared hosting (aka RASH), so it ships with an .htaccess file that attempts to do the right thing. AllowOverride will need to be set correctly, in particular mod rewrite support so that "clean urls" work.
>
> which suggest maybe it can't get along peacefully
> with other docroot content?
>
> What's the issue there?
The base .htaccess file for clean urls -- it will grab all paths underneath docroot unless you exclude some paths. Drupal does everything, why would it want to share docroot :P
> ) Somewhere under /usr and you provide a script a
> user can run to
> hook it up into the final location (and the script
> can do
> additional groundwork beyond just bits).
I would recommend this process. And leave it there (i.e. don't "move" it anywhere...), but configure httpd.conf / drupal.conf to support domains served from this location.
A useful addon would be a small script to add / create additional websites -- e.g. newdrupal example.com -- that set the correct conf settings plus created a new subfolder under /sites.
Bundling the drush.module and/or provisioning.module (http://drupal.org/project/drush and http://drupal.org/project/provisioning) to enable this might be an option.
> > 4.6. Installation/Configuration
> [...]
> > 4) Manually create Drupal database/schema
>
> Manually by running some provided script, or
> literally "manually" by
> telling the user to start typing in SQL?
This shouldn't be manual -- install.php takes care of this. HOWEVER ... there must exist a MySQL or PostgreSQL user and database to connect to.
---
My only other comment is that if you want to add more value, then shipping with correctly configured APC or eAccelerator PHP opcode cache -- this would provide excellent performance out of the box.
|
|
|
|
|
Posts:
36
From:
Registered:
4/10/07
|
|
|
|
Re: DRAFT ARC case for Drupal 6.x for review
Posted:
Jun 13, 2008 4:19 PM
in response to: erreid
To: Projects » webstack » discuss
|
|
so, how soon can we see Drupal on the webstack project repository?
|
|
|
|
|
