Lars Bruun-Hansen wrote:
>
> The Apache2 method script, /lib/svc/method/http-apache2, adds - imho
> - absolutely no value. We might as well call apachectl
> directly. Let's take a closer look at it:
Hi,
Thanks for the comments..
(I'm moving the reply from sfwnv-discuss so I'll quote the entire
email instead of just the sections where I'm responding to give
other readers more context.)
> * It checks if the conf file exist and exits with error if not. Why
> not let apachectl (which will delegate this job to the httpd binary)
> report this ?
>
> * It checks the value of a manifest property ('ssl') and let this
> govern if apachectl is called with the "start" or the
> "startssl". Only problem is that my apachectl (and yours, I hope)
> does not support the "startssl" argument so if you try to use it it
> will fail.
Indeed, this is a bug (http://bugs.opensolaris.org/view_bug.do?bug_id=6591532)
that will be fixed as part of the 2.2.6 integration.
> * It removes the Pid file when the argument is "start". Why is this
> required? Surely if this was required the guys at apache.org would
> have put such functionality into apachectl.
>
> * It tries to create a Pid File directory if it does not already
> exist. I would rather have it fail cleanly in such a case. We should
> not try to silently fix configuration errors.
>
> Here is what I think:
>
> The manifest should simply call apachectl but with the user being
> able to customize it by using SMF property value. I'm not 100% sure
> how this is done but man page smf_method says it is possible to use
> the value of a property in a method.
The intent is to configure the startup options in smf as you mention.
There's been some prior discussion on the ordering of script calls
but the public interface will be smf (apachectl will work too).
(List archives at http://opensolaris.org/os/project/webstack/Mailing_LIsts/)
Seema, if you have a chance to summarize the smf/apachectl interaction
implementation details discussion, that might be useful.
> Let's assume that httpd_options is a property from the manifest,
> defaulting to an empty string. Then the start method would simply be
>
> "/usr/apache2/bin/apachectl ${httpd_options} -k start"
>
> An administrator could then set the httpd_options property in the
> manifest to say "-f /apps/apache2/conf/httpd.conf" to allow the web
> server to start with configuration from a non-default location.
The smf properties will be individually identified (not just an opaque
string). If you feel there should be a property for pointing to
alternate config files that can certainly be discussed..
> As I mentioned in the beginning I'm working with delegating Apache2
> service to a non-root user to allow him to start and stop it using
> his own configuration. The above would make it a lot simpler to do
> delegation.
Interesting use case and one that hasn't been discussed here.
> Another requirement for out-of-the-box-supported-delegation is that
> the manifest includes action_authorization and value_authorization
> tags in the appropriate parts of the manifest. Also these tags must
> be included by default in the /etc/security/auth_attrr file to make
> it simple for the sysadm.
>
> In summary for a service to support out-of-the-box-delegation it should:
>
> 1. allow location of config files, pid files, log files etc to be
> customized without having to write a new manifest or indeed without
> having to change anything but property values in the manifest that
> comes with the OS.
> 2. have authorization tags in all relevant places in the manifest
> 3. tags mentioned in requirement #2 should exist in auth_attrr
>
> Any support for such ideas?
> I'm on a quest to make sure all the nice SFW stuff that comes with
> Solaris can be delegated easily. Delegation is one area where
> Solaris really has an edge but we have to make it easier.
Have you attempted to modify the setup to support this? If you have
the opportunity to contribute proposed diffs that'll certainly make it
easier for others to try it out and see what they think.
(Unfortunately what's there in the source tree right now is not yet the
2.2.6 that's been the topic of discussion for the last few weeks. But
your proposals are sufficiently generic in nature that it shouldn't be
a problem.)
Also, for the details of behavior which are clear cut bugs, please do
file descriptive bugs in http://bugs.opensolaris.org/ as it'll help
track things (apache bugs go in solaris/utility, apache).
> Next: postgress, mysql, samba. :-)
MySQL discussion just started here today so good timing ;-)
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
