webroot for macports

[Scott Haneda]

On May 3, 2010, at 7:20 PM, Ryan Schmidt wrote:

> Well, sure, people might want to set up custom vhosts, and they could do that anywhere. Thus far MacPorts hasn't provided any specific guidance on that.

Is it also worth considering that the http ports and the database ports are both cases where the attached data to that binary can be large.  An Apache setup with a few hundred virtual hosts immediately becomes something that will more than likely no longer live at / at all, but will live somewhere like /Volumes/some-SAN-DAS-or-NAS

If I have hundreds of virtual hosts, I would like MacPorts to steer clear of them as well. Granted, I am free to store virtual hosts wherever I desire.  But it may not be a bad idea to adopt a layout that was conducive to virtual hosting.  I think most developers installing the MAMP stack are going to need to have a layout that does help them maintain a virtual host setup.  ie /opt/local/www/clients/lastname.firstname

Perhaps the location needs to be something that can be defined.  If we go with something like below, there is a ton you would have to unravel to get things working if you have any deviation from a single drive, single partition setup.  After you have it all working, using MacPorts to upgrade, uninstall, reinstall etc all become challenging enough, that for phpMyAdmin, RouncCube, Squirrel Mail, and a few others it is easier to install those by hand.

The reality of all these http based control panel / front ends for back end admin, is that they have become masters of the drop in and install method.  Even something more complicated like WordPress, is dead simple to install.  Though I would say, WordPress could strongly benefit from a well done MacPorts Portfile for the upgrade process.  

Thought at the same time, WordPress has an update mechanism built into it, that once it matures, means WordPress internally updated systems can not use MacPorts for WordPress updates, or Macports updated installations of WordPress must not use the WordPress internal update system.  How does MacPorts deal with window managed apps that have built in s-ware update mechanisms?  Say gimp for example, had an built in updater, or maybe it does already, what is the official stance on this, and what is the recommended procedure?

With Wordpress being at 2.8.4 and no maintainer in MacPorts, current stable is 2.9.2, and I have not seen a request for an update on the mailing list, I am not even sure how important it is to put a ton of time and energy into this.  Sure, define a layout that works and well work moving forward, that make sense, but I can not see MacPorts becoming widely used for installs of these type of web based systems.  For the install of AMP, MacPorts is great and the mailing list shows there is plenty of demand for it.  Web baed admins are a matter of moving a downloaded directory into somewhere apache can see it, editing a something.conf file and loading your machines local name.

Any user who wants to run these softwares differently, will fall into a category that is unlike any other, and will be impossible to crate apache .conf files to cover every users needs.  Some may want ssl, some my want to use a custom hostname, some of these softwares are dependent on their own .htaccess files filled with rewrites and other url mangling operations.  A lot of this is also customizable.  I just do not see how MacPorts can do anything other than put the directory in place.  Getting much of this to a point where the user can just enter in http://macbook.local/roundcube is a lot to ask.  Apache is too configurable.

Does MacPorts know the path locations to Apache's "extra" directory and the "vhosts" directory therein? If it does, or that is a rock solid reliable path that can be counted on, then I can see this somewhat working, but I still think self updating software like Wordpress will become more and more prevalent, making the post installation with regard to MacPorts non usable.

> I'm still a little worried about mixing the directories for vhosts with the directories for webapps with the cgi-bin directory.

I am glad you are, as that is a concern of mine as well.  Webapps can be re-downloaded, and worst case scenario, they can be reconfigured.  If I am working on custom projects set up as vhosts, and I am using the same directories MacPorts uses, that would scare me a little any time I did an uninstall.  I would probably elect to remove that fear and move my vhosts elsewhere, which destroys an solutions we come up with now.

> What would you think of being more deliberate in the separation, for example like this:
> 
> 
> ${prefix}/
> 	www/
> 		apps/
> 			ZendFramework/
> 			mediawiki/
> 			phpmyadmin/
> 		cgi-bin/
> 			printenv
> 		vhosts/
> 			default/
> 				index.html
> 				mediawiki -> ${prefix}/www/apps/mediawiki
> 				phpmyadmin -> ${prefix}/www/apps/phpmyadmin
> 
> 
> "apps" may not be the right word since ZendFramework is not an app; it's a framework.

I like the ${prefix}/
			www/
				/apps
				/cgi-bin
				/vhosts

layout a lot.  I don't care for the symblinking, or see what it is needed.  What are your thoughts on the gains for doing this?  Why not write out the config file to reference their doc root from prefix/www/apps ?

> It's also possible users would expect a cgi-bin directory per vhost, which would mean a different layout. I'm not sure what users expect from a cgi-bin directory these days, really; it's become an anachronism.

I have not used cgi-bin in a long time.  I cringe a little when some client wants counters.pl working, and will usually do the work it takes to drop in a php counter I made.  I know it is safer, and my 5 lines to the 200+ in counter.pl is justification enough :)

I do not think users would want a cgi-bin per vhost.  If they do need it, they could make it themselves, or it could be requested in the case of a shared server setup where the user may only have ftp access.  The only time I need the cgi-bin is when I am setting up MRTG, or other generally similar softwares.  Something that is doing heavy log parsing, SNTP watching, temperature probes, video camera surveillance, etc, all seem custom and higher end.  If there needs to be a cgi-bin, that would be part of the install process.  Wouldn't it make more sense to do this on an as needed basis, per software that needs a cgi-bin, and put that burden on the port creator.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *