MySQL Bugs: #26873: MNMAS Installation on OS X does not set correct permissions

Bug #26873	MNMAS Installation on OS X does not set correct permissions
Submitted:	6 Mar 2007 13:51	Modified:	20 Apr 2007 8:17
Reporter:	MC Brown	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Enterprise Monitor: Installing	Severity:	S3 (Non-critical)
Version:	1.1 r4876	OS:	MacOS (OS X 1.4.8 (Intel))
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
1) After initial installation and login, everything works fine initially, until you start to click around the various reports and dig a little deeper into the output, at which point the service will simply stop accepting requests, and attempts to click on any link just time out (eventually). I've tried OmniWeb, Firefox and Safari, all exhibit the same problem. Once the system stops responding, you can no longer connect with any browser.

The obvious solution here is to restart. 

2) I run mysqlnetworkctl.sh restart

3) mysqld fails to start. Checking the logs, it's because mysqld is configured to run as the 'mysql' user, but the mysql database files are owned by me (mcbrown), with no permissions for r/w by anybody else. 

chmod -R mysql:mysql /Applications/mysql/network/monitoring/mysql/data

4) I run mysqlnetworkctl.sh restart again

I can now get back into the login screen, but the login does work, I get:

'Cookies must be enabled' as an error in the browser. Cookies are enabled. 

Checking the Apache logs, first off, rotatelogs in that package is corrupted. There are lots of: 

[Tue Mar 06 13:20:21 2007] [error] (8)Exec format error: exec of '/Applications/mysql/network/monitoring/apache2/bin/rotatelogs' failed
piped log program '"/Applications/mysql/network/monitoring/apache2/bin/rotatelogs" "/Applications/mysql/network/monitoring/apache2/logs/access_log" 1209600' failed unexpectedly

Running file on apache2/bin/rotatelogs: 

$ file apache2/bin/rotatelogs
apache2/bin/rotatelogs: data

Uh-oh - obviously unrelated, but still a problem.

Ignoring those entries, you can see it is a file/permission problem on the tmp directory used to hold the PHP session data: 

[Tue Mar 06 13:23:53 2007] [error] [client 127.0.0.1] PHP Warning:  session_start() [<a href='function.session-start'>function.session-start</a>]: open(/Applications/mysql/network/monitoring/dashboard/tmp/sess_hh39hcthm9fs4aaigev22grnu3, O_RDWR) failed: Permission denied (13) in /Applications/mysql/network/monitoring/dashboard/merlinui-default.php on line 48, referer: http://localhost:10080/index.php/auth/
[Tue Mar 06 13:23:53 2007] [error] [client 127.0.0.1] PHP Fatal error:  Exception thrown without a stack frame in Unknown on line 0, referer: http://localhost:10080/index.php/auth/

If you set the permissions on dashboard/tmp to be wide open, you can now get past the cookie problem. Ideally, of course, they should be set to something more suitable. 

5) I run mysqlnetworkctl.sh restart again (just to be sure)

Yay, everything works :)

At least until the service crashes out again...

Essentially there are two main problems and one associated issue: 

1) Permissions/ownership on the mysql/data directory are not set correctly
2) Permissions/ownership on the dashboard/tmp directory are not set correctly
3) The Apache rotatelogs tool is corrupted

How to repeat:
Install the MNMAS, then shutdown and restart the service using the supplied script and follow the error clues as shown above. 

Suggested fix:
The mysql/data directory should simply be set to be owned by mysql:mysql during installation.

The dashboard/tmp directory should be set to a more appropriate ownership/permissions, either during installation (best) or within the PHP scripts that write the session cookie data

The rotatelogs command should be replaced with a working binary

It seems the permissions on the entire dashboard directory structure are incorrect. Checking the Apache logs again once running, you get a lot of errors while generating the graphs: 

[Tue Mar 06 14:30:59 2007] [error] [client 127.0.0.1] Exception: file_put_contents(/Applications/mysql/network/monitoring/dashboard/htdocs/cache/graph/5dc914722bb8e8946deddc2392b99f00.png) [<a href='function.file-put-contents'>function.file-put-contents</a>]: failed to open stream: Permission denied\n#0 [internal function]: __error_handler(2, 'file_put_conten...', '/Applications/m...', 215, Array)\n#1 /Applications/mysql/network/monitoring/dashboard/lib/Merlin/Model/Graph.php(215): file_put_contents('/Applications/m...', '?PNG????????IHD...')\n#2 /Applications/mysql/network/monitoring/dashboard/lib/Merlin/Model/Graph.php(240): Merlin_Model_Graph->getGraphByInterval('Database Activi...', Array, '01:00:00', false, false, false, 200, 100, true)\n#3 /Applications/mysql/network/monitoring/dashboard/lib/Merlin/Controller/Dashboard.php(153): Merlin_Model_Graph->getGraphByIntervalThumb('Database Activi...', Array, '01:00:00', 200, 100)\n#4 [internal function]: Merlin_Controller_Dashboard->getThumb('Database Activi...')\n#5 /Applications/mysql/network/monitoring/dashboard/lib/Merlin/Controller.php(225): call_user_func_array(Array, Array)\n#6 /Applications/mysql/network/monitoring/dashboard/htdocs/index.php(46): Merlin_Controller->dispatch()\n#7 {main}, referer: http://localhost:10080/index.php/dashboard/

Updating the permissions to allow writes fixes the problem, and enables the graphs in the display.

Thank you for the report.

Verified as described.

To repeat run mysqlnetworkctl.sh as root.

Patch sent to Keith.

The rotatelog's problem was caused by a substitution made to the
rotatelogs wrapper script, but as this script was missing in older
outputs, it was instead making the substitutions to the original binary
file.

About changing ownership for the mysql/data directory, the fix implements that request.

Finally, we have not been able to reproduce the php session problem with
the dashboard/tmp directory. The permissions are by default set as follows:

drwxr-xr-x    3 nobody  admin   102 Mar 19 23:32 tmp

Please give us any indication in case you need a different set of
permissions/ownership for this folder.

This has been reported as corrected in versions => 1.1.0.4973

This has been reported as corrected in versions => 1.1.0.4973

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Martin MC Brown writes: 
Confirmed as fixed