Cannot set mysql 5.1.39_0 root password

[Scott Haneda]

>> 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.

Ahh, right you are. Perhaps a candidate for a ui message?  It is very  
useful.  Saves about 3 solid steps that I am used to performing to  
getting MySql where I want it to be.  The interactive script is y/n,  
so the user can decide what to do at that time.

I think the most value is in that it will get the root password set,  
and further lock it down so that root can only login from localhost.   
All these are good things to me, and are still optional to select "no".

>> 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.

Fair enough.  I guess that if one wants to chroot, one probably would  
not need MacPorts as they are going into areas for reasons that they  
should explicitly understand, making a manager of less value.

>> 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.

Understood

>> * 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.

Sorry, to clarify, I did not mean {prefix}/var/www but that I have  
seen /var/www used on other systems.  Since I mentally change {prefix}  
to / in my head, that is where that comes from.

I generally map out in my head that if in OS X something lives at /etc/ 
named.conf then in ports it should love in {prefix}/etc/named.conf

Probably not always true, but I find it works well for most things.

> 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).

I am leaning strongly on {prefix}/www

> 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

Consider those that will end up hosting other sites, that are not  
managed by ports, either for personal development, or larger scale  
hosting.

There are a few conventions I have seen:
./smith.tom/a.example.com
./smith.tom/b.example.com
./smith.tom/c.example.com
./smith.tom/logs
./smith.tom/cgi-bin

In that case, all that users domains end up in their  
lastname.firstname directory. Of course, this is up to the admin to  
set up after ports has come in and done its installs.

So each of those would end up in {prefix}/www/htdocs
I like that so far, that works well and translates well.

So where would phpMyAdmin end up?
{prefix}/www/htdocs/phpMyAdmin ?

I think it is workable, with using {prefix}/www/htdocs and {prefix}/ 
www/cgi-bin is fine as well.  Not sure I like this data directory.

> 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?

What are these ports doing that would need delineation of public and  
private?  Why would it be terrible for them to all go to htdocs?

If that is the case, I myself would change the above  
lastname.firstname to be
{prefix}/www/clients/lastname.firstname and let ports manage and  
maintain htdocs and cgi-bin on it's own.  I see no need for "data",  
and unless there is some real need for public and private, I see no  
need to add an extra set of paths.

Shouldn't all these ports be making a portname.conf file and writing  
it to the apache confs area?  I believe the httpd.conf includes  
*.conf, this would allow the port creator to set up the host how they  
think it needs to be set.  They can all still reside in htdocs. Or a  
ui messages that says to cp the .conf file to the correct spot in  
apache.

I lean on the auto install of the conf though.  If Document Root is  
htdocs, and a port installs to htdocs/well-known-name without  
restrictions defined in a directory and/or virtual host directive in  
apache, it is not hard to hit up http://example.com/well-known-name  
and do harm.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *