Re: [gentoo-dev] [GLEP] Web Application Installation

[Max Kalika <max@gentoo.org>]

Uh oh.  I think we are talking about the same thing.  It seems to me that
we're going towards the same ends but by a different means.  I think we're
getting really close.  I know you're dying of anticipation so ... read on!

Quoting Stuart Herbert <stuart@gentoo.org>:

>> If not mod_alias, then symlink to the DocRoot, but then we're back to not
>> knowing where the user configured his/her/virtualhosts's DocRoot.
> 
> mod_alias provides aliases for URLs.  Why would you need to know what
> DocRoot  is?

Lets skip this...see below.

>> Local config files?  Where would these be stored?  How are these handled
>> for virtual hosts?
> 
> They would be stored under the virtual DocRoot, for example (using the
> paths  for my example) in
> /var/www/www.iammax.com/public_html/phpbb/config.php.
> 
> Putting the config file into the virtual DocRoot is where Robin's tools
> would  come in (Robin, are you following this thread at all?).  We could
> put a  master copy - a skeleton if you like - in
> /etc/webapps/<app-name>/.  It's the  skeleton that gets updated by
> portage.

Ok, I'm following now.

>> Ok, this is debatable, but I'm willing to change the eclass to take
>> -apache2 into effect.
> 
> [OT, but interesting] How is this debatable?

Seems to me that if the server is installed, it should be taken into
account.  But that's entirely personal opinion.  USE flags are more correct
for the general public.

>> We can still achieve flexibility along with smaller ebuilds.  If we break
>> down the eclass install function into smaller functions and optionally
>> call them from install, we've got ourself a nice tidy system.
> 
> Good idea - I'll sign up to that.

Right-o. I'll make a note to do this in the eclass.

> I must be missing something.  Why won't SLOTing help?  The behaviour
> you've  described is *exactly* the behaviour that I want.  Why can't
> phpBB-2.0.4 and  phpBB-2.0.5 run at the same time on the same box, but
> under different virtual  domains?

I think I missed something.  I thought you wanted to use SLOTs for somehow
maintaining the same version of the same package.  I think we are on the
same page, now.  In the eclass we can go ahead and do something similar to
the kernel ebuilds -- make SLOT="${PV}" or even SLOT="${PV}-${PR}".

> If the package management system provided a viable solution, don't you
> think  that people would use it?

Certainly.

>> Going along with your example, how can you do an 'emerge -u phpBB' _for a
>> particular domain_?  
> 
> Like this.
> 
> a) emerge -u 'webapp' installs the master copy of 'webapp' in
> /usr/webapps.   If the webapp is SLOT'ed, none of the domains are
> upgraded at this point. b) Then, run 'webapp-config --upgrade <webapp>
> /path/to/domain/directories' to  upgrade the specific domain.

This is where I misunderstood.  I thought you wanted portage to take care
of everything -- i.e. emerge -u 'webapp' would somehow magically upgrade
all the copies.  This is actually a more elegant version of the cp -a thing
that I mentioned in the previous post.  I think we have our answer.  Next
step would be to write up the necessary functionality for the webapp-config
utility.

> Two stage process.  Finally, once all domains are upgraded, you can
> simply do  an 'emerge -C webapp-old-version' to remove the old SLOT'ed
> version that is  no longer required.
> 
> What's wrong with this as a solution?

Nothing.  It just took 16 posts to get it through my dense skull. :-)

> Nope.  I'm telling Portage to maintain the master copy of a package, and
> to  upgrade that master copy only.

Ding Ding Ding!

>> I simply don't think portage will ever have
>> any way of handling multiple installs of a package in this manner.  
> 
> Why does Portage have to do *everything*?  We use portage to get the app
> +  dependencies onto the box, and we use additional tools to manage the
> virtual  domain upgrades.

It doesn't and can't.  The one instance/configure is definitely the way to
go.

>> AFAIK, no other distro has support for virtual hosting because of this
>> very issue.
> 
> I have no idea whether other distros support virtual hosting, and if they 
> don't, why they don't.  If you have any threads I can read on this,
> please  send them my way.  Otherwise, your statement is an assumption,
> and  assumptions are the mother of all screw-ups.

Well then, lets the the first.  :-)

>> The most robust solution would be to create a new group (web?) and make
>> all the webserver users be a part of that group and make these directory
>> group-owned by said group.  (Similar to the "mail" group for many
>> mail-related services)
> 
> Why is that robust?

Because we have the one group that we know all webservers are going to run
as (yes yes, the sysadmin can change what group the server runs as, and if
he/she does, then he/she can also change the ownership of the directory).
If we assume that all webservers will run as the same group, then
configuring those apps which need a writeable directory becomes easy indeed.

>> Which takes me back to
>> wanting to support a single instance install of an app that an admin has
>> to copy in place if the default location is unacceptable.
> 
> It's one solution, sure.  I think we can do better, and I'm willing to
> write  the code to do it if necessary.

Yup.  We were talking about the same thing.  Just a different way of doing
the post-install config.  I'd like to help with the design/code of the
webapp-config utility.

>> I'd say <app-name> should just be ${PF} for both and not worry about what
>> is SLOTed and what is not -- it works itself out.  
> 
> (thinks about this)  I'd want to test it to be sure, but I think ${PF}
> would  work out okay.  Depends whether having the -rX part of the package
> name is  really important or not.

I'd say it is important because -rX releases may have added
functionality/features that some may not want, etc.

>> Otherwise, this seems ok to me and is easy to implement in the eclass.
> 
> Good-o.  So the two of us (ominously quiet in here ;-) are in agreement
> then?   Oh, thought it was too good to be true ;-)

It could happen!

> Shrugs.  I just picked 'public_html' because it's a recognised convention 
> (although not the only one I'm sure).  'public' is too generic for my
> liking.   'cgi-bin' *is* a recognised convention, and one we shouldn't
> break.

I thought those were apache conventions.  It really doesn't matter one way
or another. :-)

>> Is the approach currently in the eclass unacceptable? (Check for the
>> existence of the directory/configfile)
> 
> I think so.  See how I determine which version of apache to use in 
> webapp-apache.eclass (as stolen/morphed from Robin's mod_php ebuild!)

checking...still checking...done!  It could probably be simplified to
something like the following: (I'm just the nitpick mongrel, aren't I?)

if [ "`has_version '=net-www/apache-2*'`" -a "`use apache2`" ] ; then
	APACHEVER=2
elif [ "`has_version '=net-www/apache-1*'`" ] ; then
	APACHEVER=1
else
	# no apache version detected
	return 1
fi

> Lol.  For now, just make your eclass rely on mine, seeing as mine's
> already in  Portage ;-) and re-use what's already coded.  No offence, but
> because of the  reasons in one of my earlier emails, I don't think your
> eclass should go into  Portage until the outcome of this GLEP is
> determined.

No offense taken of course.  Lets just evolve yours overtime to do
everything that's needed because, as you say, it is already in portage. :-)

--mk

--
gentoo-dev@gentoo.org mailing list