Amanda waite wrote: > Hi Siriam, > > Thanks for the feedback. > > Sriram Natarajan wrote: > >> Hi >> - More appropriate SMF service name would be network/http:lighttpd. >> >> > Is the point being that I should just add lighttpd as an instance to > network/httpd or is the dropping of the '14' suffix also significant. > What I mean is that you may be saying that I should only have one > lighttpd service configured even if I have multiple versions of Lighttpd > installed or you may have just left off the '14' to make it easier to read. > Well, it includes both.
To me , it makes more sense to include lighhttpd as an instance so that we follow the same convention that we currently have with apache2 and squid. Please see /var/svc/manifest/network/http-apache22.xml and /var/svc/manifest/network/http:squid.xml for references. There are couple of reasons for not including the version information within lighttpd SMF name - Simple to use and remember. - If in case, we do have lighttpd 2.0 which is not backward compatible with 1.x, then we could very well introduce the version support (in the same way as we do for MySQL and PostgreSQL) at a later date. >> - You might want to provide a symbolic link so that users can access >> lighttpd from /usr/lighttpd/bin like the same way we have done for PHP >> and MySQL. >> >> > What's the logic behind that? Is it mainly to make it easier to get to? > What happens when you do have multiple versions installed? Is the link > always to the latest version with PHP and MySQL? > Yes. This is also the case with perl. >> - man page also need to reside under /usr/share/man/.. in the same way >> as is currently done for Apache >> >> > OK, I'll do that, do you also create links to these in /usr/man/man* > > yes, it would be under /usr/share/man thanks sriram > Cheers > > Amanda > >> thanks >> sriram >> >> Amanda Waite wrote: >> >> >>> Hi all, >>> >>> Attached is the 2nd rev of the Lighttpd Arc Case, I'll post this to >>> the Wiki tomorrow. There are a couple of holes in it, one is something >>> I'm investigating in the background and the other is a question on one >>> of the points raised by Jyri. >>> >>> The first hole is that I'm still looking at the loadable modules, some >>> actually exist even when libraries that they would appear to depend on >>> were not available at build time. This is explained in the Arc Case, I >>> just need to add the explanation and I'm investigating this. >>> >>> The second hole is RBAC. How do I add entries to prof_attr and >>> exec_attr in /etc/security via a package install without a script? I >>> assume that this is straightforward and that I just simply don't know >>> the answer. >>> >>> >>> >>> The last question concerns exported interfaces, Jyri made the >>> following point: >>> >>> "Also, be more specific. "/usr/sbin/lighttpd" is Uncommitted, what does >>> that mean? Is it the physical pathname that's Uncommitted? Or the >>> command line options of that CLI? Or its exit code? Or the module APIs >>> contained in it? Something else? All of it?" >>> >>> >>> I think I get this and have followed the example of the MySQL Arc >>> Case. The worry I have is that I'm not sure how best to document these >>> things in the available columns and how to determine what their >>> stability is. Can someone advise. >>> >>> Thanks >>> >>> Amanda >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> >>> >>> webstack-discuss mailing list >>> webstack-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >>> >>> >> _______________________________________________ >> >> >> webstack-discuss mailing list >> webstack-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >> >> > > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >
