Jyri Virkki wrote: > Matt Ingenthron wrote: > >> While we want Solaris features, such as SMF, to be available and >> advocated, one of the challenges with current Solaris for people who may >> consider migrating is the fact that things are so different than most >> other popular platforms. (more below...) >> > > At some level one needs to accept Solaris is in a few ways different > (and stronger for it, but still, different). >
Personally, I'm quite a fan of SMF. The only thing I ever have difficulty with is svcprop, and that's probably because i don't have to visit it very often. I may not have been clear why I wrote that first paragraph... more below... > (How did you like the old OpenOffice port on OSX using X? Sometimes > it's necessary to comform to the platform to fit in.) > > Most users are more comfortable with init.d scripts due to decades of > history (me too) but the decision has been made that smf is The Way in > Solaris. > An init.d script is something very different, since that's something that's defined by the OS. Here, we're talking specifically about something defined/documented by Apache and what the right way is to change/integrate with it. SMF is definitely flexible enough to be either part of the apachectl shell script or just wrap all of apachectl (with potentially less features, because one would not get svcprop properties). > > That said, Arvind sketched an approach (not a detailed implementation > plan) that allows both to work. I don't expect the non-smf way to be > supported in Solaris though, but it should work. > I understand this, but I guess what I was pointing out is the way I read Arvind's proposal, it doesn't allow both to work *completely*. It was to include something that called itself "apachectl", but would likely not have been fully compatible, while the real apachectl would have been converted to a 'private' interface (quoted): > I think the issue is what interface we support. The only *supported* > interface > for starting/stopping the Apache daemon on OpenSolaris should be SMF. > > We could probably do something like this: > * Rename the existing apachectl to apachectl.private (or something) > * Add our version of apachectl that simply invokes SMF's svcadm > * 'svcadm enable/disable apache2' would invoke apachectl.private to > start/stop > the server This would be taking a 'standard' interface from the Apache httpd project and either breaking or removing it in Solaris. This could cause significant amounts of breakage in other software that knows how to work with "apache", including other software (like webmin) we ship with Solaris. I understand Arvind was only sketching the outlines of an approach, and please understand I'm only sketching the problems I forsee with that approach. It was in that light that I wrote that first paragraph-- it wasn't me saying we had to have apachectl because users expect it-- it's more that if we do not have a complete apachectl and someone has a 3rd party monitoring/management tool that works with it (as a standard interface), they'd consider OpenSolaris broken if it's Apache httpd weren't compatible. An alternate approach is for apachectl to be modified to know how to retrieve properties from SMF, call the enable/disable (though there's not an exact equivalence of semantics here), etc. > >> modifications to the apachectl script to use SMF and push them upstream, >> > > Absolutely, all diffs are contributed upstream. Be aware we can't know > how long it might take for adoption; that'll vary. > > Yep, well aware of that. - Matt -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: matt.ingenthron at sun.com Phone: 310-242-6439
