On Fri, 23 Mar 2007, UNIX admin wrote:
> That works too, although over time, you'll have lots of config dirs in
> /etc/opt/.
True...
> I deliver all my config stuff in /etc/opt/my-stock-symbol/ and then,
> if the app has more than two config files, in
> /etc/opt/my-stock-symbol/app, for example
UNIX admin wrote:
These ARC cases are for integration to Solaris, so
/opt is inappropriate,
and /usr is correct.
I missed that, ouch. In that case, apologies for the /opt questions. I was
under the *wrong* impression that CoolStack (NG) was delivered separately of
Solaris. Live and learn...
UNIX admin writes:
> > I never liked the /etc/opt/apache2, and so on that
> > some distributions
> > did as sometimes it wasn't clear which apache2 read
> > what configuration
> > from where, it also made greps by lazy admins (like
> > me) painful ;)
>
> /etc/opt//apache2/ is the clean and correct
> Agreed, which is why the docs actually suggest
> /{etc,var}/opt/packagename,
> for example, /etc/opt/RICHTapache2 and
> /var/opt/RICHTapache2. Although
> the pathname is a bit longer, there can be no
> confusion as to what package
> it's associated with!
That works too, although over time, you'
> I never liked the /etc/opt/apache2, and so on that
> some distributions
> did as sometimes it wasn't clear which apache2 read
> what configuration
> from where, it also made greps by lazy admins (like
> me) painful ;)
/etc/opt//apache2/ is the clean and correct way to
deliver 3rd party configur
> These ARC cases are for integration to Solaris, so
> /opt is inappropriate,
> and /usr is correct.
I missed that, ouch. In that case, apologies for the /opt questions. I was
under the *wrong* impression that CoolStack (NG) was delivered separately of
Solaris. Live and learn...
This messa
> The user could easily change the apache2 symlink if
> it bothers them, and that
> would point to the new version, but would allow your
> entire stack to use the
> runpath you compiler for.
That won't work. It's ad-hoc, and ad-hoc doesn't work if you have several tens
of thousands (yes, you r
> 2. The currently proposed Apache 2.2.4 integration
> installs Apache in
> /usr/apache2, thereby _overwriting_ the existing
> Apache 2.0.x. Valid arguments
> have been made pro, and against this approach, with
> the suggestion that Apache
> 2.2.4 installs in /usr/apache2.2, thereby preserving
>
> Overwriting the /usr/apache2 that comes on the
> Solaris media is a no-no,
> in my opinion, and /usr/apache2.2 just pollutes the
> /usr namespace even
> more than it is already. IMHO, the correct place for
> this is under /opt.
Agreed.
> I have no strong feelings either way, but I would
> pref
> Hi.
>
> The ARC Cases for the WebStack NG Project have been
> submitted for review (and
> hopefully approval), and i would like to ask our
> community's input regarding two
> important questions which have come up during our
> discussions:
>
> 1. Should the initial components released for thi
On Thursday 22 March 2007 12:57 am, Bob Palowoda wrote:
> You might have to have sym links for /etc/apache and /var/apache also.
> The runtime environment is controlled by apache APR utilities.
This is about the time zones start lookin' good...in fact, that should be the
reccomended way to run P
> On Wednesday 21 March 2007 01:23 pm, Stefan Teleman
> wrote:
> > This was one of the other suggestions made on the
> ARC discuss list. My
> > primary concern about keeping both 2.0.x and 2.2.4
> around (albeit
> > temporarily) is that it creates the possibility of
> a huge disaster:
> >
> > appli
Hi Everyone,
This of course brings us back to the idea of maybe collapsing the
apache directories the way we do with Java, Perl, etc.
As such something like this would work:
/usr/apache//
So we would have:
/usr/apache/1.3.x/
/usr/apache/2.0.x/
/usr/apache/2.2.4/
Have a symlink called "latest"
> Correct. Existing configuration files will *not* be
> overwritten.
How do you propose handling Apache modules? The module API changed between 2.0
and 2.2, and it is not possible to load 2.0 modules under 2.2 .
Cheers
Andrew.
This message posted from opensolaris.org
___
> The ARC Cases for the WebStack NG Project have been
> submitted for review (and hopefully approval), and i would
> like to ask our community's input regarding two important
> questions which have come up during our discussions:
>
> 1. Should the initial components released for this projec
15 matches
Mail list logo
