MAMP tutorial, second set of eyes

[Scott Haneda]

On Jan 4, 2010, at 4:00 PM, Ryan Schmidt <ryandesign at macports.org>  
wrote:

> On Jan 4, 2010, at 17:16, Scott Haneda wrote:
>
>> Since I updated to snow, that meant a new MAMP install, along with  
>> all my other ports.  I decided, no better time to document the  
>> process.
>>
>> http://dl.dropbox.com/u/340087/drops/01.04.10/mamp/mamp-tutorial.html
>
> Sorry, I haven't had time to read it yet, but just wanted to quickly  
> say...

I hope you get a chance to. It's close to being modular in writing. In  
that, as you desire, I could pull it apart into sections, one for each  
component.

For example, the MySql tutorial stands on it's own rather well. As  
does the Apache2 part of it.

>
>> I am doing things a little different than the MAMP page for MP  
>> state to do, though I explain my reasons.  For example, I am not  
>> sure why phpmyadmin is getting into /opt/local/www unless it is for  
>> preparation for htdocs going away one day when Apache 2's layout  
>> gets worked on.
>
> The htdocs directory might get moved and/or renamed but can't go  
> away because there needs to be a directory for the document root  
> and /opt/local/www is too general to be it;

Why? Why is this too generic? It is just a location. I run hundred of  
virtual hosts all pointed to /opt/local/www/clients/lastname.firstname

> the doc root needs to be a subdirectory of www.

Ok. I think I get what you are saying. You don't want localhost  
loading a dir listing of everything in www, as that would break any  
traditionally built apps that rely on docroot being defined in a  
virtual host container.

I work towards this in my tutorial.

> A properly-designed web app should not go directly into the doc  
> root; a properly-designed web app should contain a directory which  
> should be served directly by the web server and a bunch of other  
> directories for classes and libraries which the web server should  
> never ever be able to see directly. For such web apps, it would be  
> appropriate to install them elsewhere (/opt/local/www directly, like  
> phpmyadmin and some other ports now do, or better yet /opt/local/www/ 
> apps or something) and install a symlink to their docrootable  
> directory in the actual docroot. phpmyadmin and many other webapp  
> ports that we have *are* designed to go directly into the docroot so  
> for them it doesn't much matter, but I like the idea of all web apps  
> installing into the same place (e.g. /opt/local/www/apps). Months  
> ago I touched a couple web app ports to change the install directory  
> from /opt/local/www/htdocs to /opt/local/www but then I stopped  
> because I wasn't sure I liked that and there were so many ports and  
> each port had so many things wrong with it and hadn't been touched  
> in ages and I couldn't decide what directory I wanted them to go in  
> anyway.

Hmm. Well. I honestly would not touch it until the layout of Apache 2  
changes. Your creating 2 sets of work if you do.

I'm not sure I follow the significance of your position on the  
importance of the httpd.conf docroot.

What is wrong with http://localhost/phpmyadmin working. This would  
mean it lived in /opt/local/www/apps

Then in /opt/local/www I could put  /opt/local/www/clientname/stupid- 
site.com which would be set by a virtual host with it's own docroot.

So the only traversable installs that http://localhost could hit would  
be in that apps directory.

But that apps directory is not really needed. It's nice for  
organization, but we could move one up that tree and dump to www and I  
think it's fine.

I tried to use www as docroot. No matter what, I could not get php to  
write to any directory inside www.

Pre 10.6 I had a lot of virtual hosts that lived in /opt/local/apache2/ 
htdocs/ which all worked.

I had /opt/local/apache2/htdocs/wiki which was resolved with /etc/ 
hosts as http://wiki

I moved that to the new www location. Keep in mind, phpmyadmin created  
that www directory.

My wiki is all file based, so permissions are important. I opened my  
virtual hosts conf and replaced the htdocs path to www and no sites  
that did file reads or writes worked.

I even did:
sudo chmod -R 777 /opt/local/www
sudo chown -R www:www /opt/local/www

Still nothing.

sudo mv /opt/local/www /opt/local/www.bad

sudo mkdir /opt/local/www
sudo mv /opt/local/www.bad/* /opt/local/www

That fixed it. I then went back and set permissions a little more  
sanely than 777.

What does phpmyadmin do when making www that php does not seem to be  
able to write past it?  This may even break phpmyadmin if writes files.

>
>> I certainly ran into a few gotcha's here and there that I believe a  
>> new to MacPorts uses is going to hit.  I also think MAMP is one of  
>> the most attractive reasons a user is going to come along to  
>> MacPorts so it should be presented as good as possible.
>>
>> I do not know how well this will incorporate into the wiki, I just  
>> wrote it in html, and I also took some liberties to make it rather  
>> verbose.  The wiki may not be a good home for it.
>>
>> Looking for suggestions, pointers, and recommendations on what to  
>> do with it, aside from "shove it into a blog and let google have  
>> it's way with it".
>>
>> All in all, it took about 2 days two write up, and certainly could  
>> use a second set of eyes, and ideally, someone willing to move /opt/ 
>> local aside and make MP think it is a new install. They could then  
>> follow these steps and see how it all works out for them.
>>
>> Thanks for any comments.  Look forward to hearing any feedback.
>
> I would not recommend adding your document to the wiki as a new  
> page, since as you know we already have a MAMP howto in the wiki. I  
> would rather see the existing document improved or (if appropriate)  
> replaced than have two competing documents.

Me too. But what does the user need? The user need AMP installed and  
working as easily as possible. If these are really all UB, I may fire  
up that evil bastard package maker, load up php with every bit any  
local dev may need, and just put stuff where it needs to go.

If you read my tutorial, there were too many gotchas. MySql is  
certainly confusing. Php will not talk to MySql out of the box.

What can we do to fix this? The socket issue with MySql is one such  
problem. Is altering php.ini the right way even? Why can't we build  
php to find it and remove that entire step?

> Having multiple competing documents for a given topic is a recurring  
> problem in MacPorts documentation and I would like to avoid further  
> exacerbating it.

Ok. Me too. I don't think the fragmentation in the documentation can  
be solved until all involved ports are installing in a way that works  
for 99%.

Right now, I took liberties in my tutorial to work around that.  
Suggestions?

> Actually I would prefer separate documentation for each piece of  
> software. I have referred a number of MySQL users to the MAMP  
> document for setup information, who then expressed the opinion that  
> they would never have thought to look in a document titled "MAMP"  
> when all they wanted to know was how to set up MySQL. We can still  
> have a MAMP page, but it would simply become a set of pointers to  
> the Apache, MySQL and PHP setup pages. I would probably delete most  
> of the phpMyAdmin setup information and refer users instead to the  
> existing phpMyAdmin documentation on their web site.

I think my tutorial works as a starting point for just that. The Mamp  
pages just are not going to get a developer up and running. A  
developer with sysadmin experience it may. That's where we need to be  
working in my opinion.

Is there any reason we can not have port install mamp which just  
depends on each port?  I would take liberties to reinplace php.ini to  
fix it, edit httpd.conf, and run the commands needed to make it all  
work. Or is this just too prone to breakage?

Thanks for the comments. Most appreciated.
--  
Scott
(Sent from a mobile device)