In another thread
(http://www.opensolaris.org/jive/thread.jspa?threadID=40302&tstart=0) I've
argued why I think the Apache specific method in /lib/svc/method should be
dropped. For example I've argued why the Pid file and Pid Dir operations of the
existing method wrapper for Apache 2.0 are irrelevant.
Let me add to that:
* It is not a rule that manifest needs a method wrapper in /lib/svc/method. If
the software application already can support common actions such as start, stop
, restart, etc, using its own script (apachectl) then why not use that?
* /lib is inherited read-only on sparse zones. There is a discussion on the SMF
mailing list about why /lib was chosen as the place for SMF methods in the
first place, and why not in /etc. Using the suggestion stated in the DRAFT
sites that want to do delegation will still need to either change directly in
the /lib/svc/method or change core parts of the manifest. Both are undesirable.
Let's drop the /lib/svc/method wrapper for our Apache distro and go directly to
apachectl. How? you ask, when we want to support multiple versions from the
same manifest.
Well, let's review what we want to accomplish:
1. We want to support multiple versions from a single manifest. (directory
structure as in the DRAFT, I think the directory structure is a good idea in
itself).
2. We (read: I) want the most important of Solaris' nice bundled packages,
such Apache, to support delegation out-of-the-box.
#2 is not accomplished with the current DRAFT as an instance will still be
forced to have config in /etc, logs in /var, and so on, without any possibility
for override.
Here is a possible solution:
Let us assume that our manifest has
<property_group name='httpd' ......>
.....
<!-- version: Set this to an Apache version no corresponding to one
the numbered directories your site has under
/usr/apache2 -->
<propval name='version' type='astring' value=''>
<!-- startup_options: These are pass-thru startup options for the apachectl
script. For example it could be set to "-f something".
-->
<propval name='startup_options' type='astring' value=''>
</property_group>
Then our start method would simply be
<exec_method
type='method'
name='start'
exec='/usr/apache2/%{httpd/version}/bin/apachectl %{httpd/startup_options}
-k start'
...
/>
A site wanting to use a specific version of Apache would set the httpd/version
property to e.g. "2.2.6" which would cause the manifest to start v2.2.6 of
Apache. Furthermore a site wanting to customize the location of conf files and
the like would set the httpd/startup_options property to e.g. "-f
/foo/apache/conf/httpd.conf".
There you go: both requirements from above supported within the same solution
... and we rely on apachectl for everything which is what we should do.
To really support out-of-the-box delegation we would need to add
action_authorization and value_authorization tags in the proper places in the
manifest, which is something the 2.0 manifest does not have as of today -
unlike other of the core Solaris manifests.
Later I'll post a full manifest to give the full picture.
Hope this makes sense.
Lars
This message posted from opensolaris.org
