On Jan 4, 2010, at 4:00 PM, Ryan Schmidt <[email protected]>
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)
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
