Sorry, I missed this. Ignore my earlier email repeating the RBAC question.
Amanda
Jyri Virkki wrote:
> Amanda Waite wrote:
>
>> 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 strai
David.Comay at Sun.COM wrote:
>> Definitely there's value in having 'man lighttpd' come up with
>> something useful without having to customize MANPATH, otherwise it is
>> easy to mistakenly think it's not available.
>>
>
> Agreed. I think a best practice here is to supply an umbrella page
>
Thanks.
The one thing I'm still stuck on is RBAC. How do I add RBAC entries to
the various *_attr files without using scripts?
Cheers
Amanda
Jyri Virkki wrote:
> Amanda waite wrote:
>
>> I propose that we build with support for as many modules as possible,
>> but leave any "stub" libraries
> reasonably convinced that the correct approach is to treat it like
> Apache httpd. That leaves us with /usr/lighttpd/14/sbin/lighttpd and
> /usr/lighttpd/bin/spawn-fcgi as the path to the executables. Are links
> necessary? I personally would prefer to type /usr/lighttpd/sbin/lighttpd
> than /usr
> Definitely there's value in having 'man lighttpd' come up with
> something useful without having to customize MANPATH, otherwise it is
> easy to mistakenly think it's not available.
Agreed. I think a best practice here is to supply an umbrella page
which can point at where in the rest of the hi
Amanda Waite wrote:
>
> 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.
Unfortunately no, turns out there isn't any way of doi
Amanda Waite wrote:
>
> Looking at the Apache 2.2.6 Arc case and also on my snv_b82 systems, the
> man pages are in /usr/apache2/2.2/man (and for the older version in
> /usr/apache2/man). Am I missing something?
>
> Also in order to access the Apache man pages you have to add
> /usr/apache2/2.
Amanda waite wrote:
>
> I propose that we build with support for as many modules as possible,
> but leave any "stub" libraries in the distribution so that when trying
> to use a module that we don't have support for, users get back an error
> message that they can google for and get meaningful r
Hi Siriam,
Sriram Natarajan wrote:
> Hi
> - More appropriate SMF service name would be network/http:lighttpd.
> - 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.
> - man page also need to r
Thanks Jyri,
All,
Creating a Lighttpd admin profile requires adding auths and creating a
Profile entry. How do I add entries to the likes of prof_attr and
auth_attr without using scripts? Maybe it's a discussion for another
forum and I can just state the intent to create the Lighttpd Admin
P
Jyri Virkki wrote:
>>> - 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?
>>
>
> Yes but l
Amanda waite wrote:
>
> I asked the Lighttpd forum and had a couple of replies, both came people
> who had a high level of involvement in the Lighttpd community. One said
> that they rarely run the lighttpd executable directly, only when looking
> at issues.
Sounds good, so I'd skip adding the
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
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 th
> > - 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?
Yes but let's also consider the distinction between
Prashant
Good question. Frankly, I don't know the right answer. Hope, there is a
mechanism within Open Solaris to provide a install order. Hope, some one
more knowledgeable will be able to add valuable insight on this issue
thanks
sriram
Prashant Srinivasan wrote:
>> t a later date.
>>
>>
>
> t 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?
>> W
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
Hi
- More appropriate SMF service name would be network/http:lighttpd.
- 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.
- man page also need to reside under /usr/share/man/.. in the same way
Thanks for the input Jyri, I'll take everyones comments, suggestions and
instructions offline, do some research and come back with an updated Arc
Case in a couple of days.
Thanks all
Amanda
Jyri Virkki wrote:
> Amanda Waite wrote:
>
>> Attached is a draft Arc Case for Lighttpd integration
Amanda Waite wrote:
>
> Attached is a draft Arc Case for Lighttpd integration into Solaris. I
> notice that many Arc cases say "into Solaris" and not "into OpenSolaris"
> or "into Nevada" or "into SXCE" and I'm not sure what the correct choice
> of words is.
I doubt anyone will nitpick that lev
David.Comay at Sun.COM wrote:
>> - Should we need to integrate .la files ?
>>
>
> The current consensus is to not deliver .la files.
>
Thanks, I'll drop them
>
>> - Shouldnt lighttpd be under /usr/bin instead of /usr/sbin ?
>>
>
> Actually, it probably should be under /usr/lib as it
Sriram Natarajan wrote:
> - Should we need to integrate .la files ?
>
We don't need to, but they seem to have some use and they don't get in
the way.
> - Shouldnt lighttpd be under /usr/bin instead of /usr/sbin ?
>
By default Lighttpd always installs to $PREFIX/sbin, on Ubuntu that's
/usr/s
Thanks for the comments. Replies inline.
Prashant Srinivasan wrote:
> Amanda,
>
> > Lighttpd is delivered as the SUNWlhttpd package
>
> We will need a SUNWlhttpdusr and a SUNWlhttpdroot package at least, to
> cover the files that go into /usr and /var. I'm not sure if the /etc
> artifacts ne
Attached is a draft Arc Case for Lighttpd integration into Solaris. I
notice that many Arc cases say "into Solaris" and not "into OpenSolaris"
or "into Nevada" or "into SXCE" and I'm not sure what the correct choice
of words is.
This is my first Arc Case so please feel free to tear it to shreds
> - Should we need to integrate .la files ?
The current consensus is to not deliver .la files.
> - Shouldnt lighttpd be under /usr/bin instead of /usr/sbin ?
Actually, it probably should be under /usr/lib as it's not an
executable a user would typically type the name of (or is it?)
dsc
> Do you happen to know as what is the convention here - SUNWlhttpdroot or
> SUNWlhttpdr ? Though, this is very cosmetic - I always have this
> confusion as to what is the standard ?
The old convention was to just tack 'r' at the end but starting with
Solaris 9, package names could be up to 32 cha
- Should we need to integrate .la files ?
- Shouldnt lighttpd be under /usr/bin instead of /usr/sbin ?
- what is the backward compatibility issues with lighttpd ? If newer
releases are not compatible with previous releases, then the convention
to put these components under /usr/lighthttpd/
- sr
Amanda Waite wrote:
> Thanks for the comments. Replies inline.
>
> Prashant Srinivasan wrote:
>
>> Amanda,
>>
>> > Lighttpd is delivered as the SUNWlhttpd package
>>
>> We will need a SUNWlhttpdusr and a SUNWlhttpdroot package at least, to
>> cover the files that go into /usr and /var. I'
Amanda,
> Lighttpd is delivered as the SUNWlhttpd package
We will need a SUNWlhttpdusr and a SUNWlhttpdroot package at least, to
cover the files that go into /usr and /var. I'm not sure if the /etc
artifacts need another package for them - I'm guessing not. Since the
/usr and /var separat
30 matches
Mail list logo