Cannot set mysql 5.1.39_0 root password

[Ryan Schmidt]

Tons of questions. :) Let me see if I can answer them all.


On Sep 26, 2009, at 14:35, Scott Haneda wrote:

> I seem to recall at some point, being told by a ui message to run:
> /opt/local/lib/mysql5/bin/mysql_secure_installation
>
> This was really nice, and I looked at all it did, to learn I had  
> been running all those steps by hand in the past.  Running the above  
> command, interactively walked me through the securing of MySql, even  
> dropping the test database if I wanted.
>
> I can not seem to find ui message reference to that script in either  
> the normal or devel ports.

I don't think the port ever printed any such messages. I think the  
MySQL installation process itself might've printed some messages  
before but I don't see them with 5.1.39. I didn't go back to check  
previous versions.


> I was just reading about chrooting MySql.  What are your thoughts on  
> this, would there be any interested in chrooted ports of mysql5?

> I suppose chrooting anything in MacPorts will defy many of the  
> directory location conventions that have been set forth.

My instinct is to say MacPorts should not be installing any chroots  
for anything. I understand it is quite complicated. The chroot needs  
to contain copies of all the libraries used by the port, whether  
provided by MacPorts or Mac OS X. If the user upgrades one of those  
ports, or Mac OS X, those copies would need to be refreshed, but  
there's no mechanism in MacPorts for that to happen automatically. We  
have a script for setting up a chroot for a MacPorts automated build  
system. As I understand it, the chroot ends up being several gigabytes  
in size due to all the stuff that has to be copied in, and the list of  
required files differs by OS version. With all this going on, I don't  
see creating chroots for port installations being something MacPorts  
should be doing a this time.


> I suppose it would only be needed on the mysql5-server one, and I  
> would probably not do so on the devel version either.

The -devel version of a port should be kept as similar as possible to  
its non-devel counterpart. For example, if I look at "diff -u $(port  
file mysql5{,-devel})" the only differences should be those to update  
to the new version of mysql5. In the case of mysql5 5.0.x vs mysql5- 
devel 5.1.x there will also be some differences for renamed configure  
arguments and the new innodb_plugin variant (which requires 5.1).

http://trac.macports.org/ticket/14142


> Maybe we could chroot apache2 as well, which would start it new in  
> some regards, and deal with the incorrectly places location it is in  
> now.

Your apache2 location concerns are filed separately as

http://trac.macports.org/ticket/21315

and can be resolved separately from any of your chroot ideas.


> * What is the suggested MacPorts location for what most other OS's  
> call "www".  Apple is out there with the /Library/WebServer/ 
> Documents location, but I have seen /www and /var/www and /opt/local/ 
> www and /opt/local/var/www.


${prefix}/www is where web stuff lives now and that seems fine. I had  
not heard of using ${prefix}/var/www. Looks like the only ports that  
install there are lurker, apan, netmrg, pserv. Those ports should be  
fixed. I have been updating a few old web app ports to install in $ 
{prefix}/www which had been installing in ${prefix}/www/data. I'm not  
sure this is great either. Installing directly into the document root  
(whatever we decide that should be -- ${prefix}/www/htdocs (apache  
standard)? ${prefix}/www/public (zend framework standard)?) is not  
appropriate for some software (whose distribution includes a  
subdirectory which should be in the document root and libraries and  
other stuff which should not be), but not installing in the document  
root means users have to configure their httpd.conf or create a  
symlink. I would like there to be a webapp portgroup that handles some  
of this automatically, and in the future also automatically creates  
apache and lighttpd config files for that web app (maybe).

Maybe the layout should be:

${prefix}/www/cgi-bin -- cgi directory
${prefix}/www/data -- where each web app installs its directory
${prefix}/www/htdocs -- document root; maybe this contains symlinks to  
webapps' web root directories

I don't know where the name "data" comes from; that's just where a lot  
of ports install to right now. Maybe using "public" instead of  
"htdocs" and "private" instead of "data" would be clearer?