1) Create fresh virtual machine, install Ubuntu Server 9.04 Jaunty.
Choose all the defaults, set your own time zone and your own user
name and password. Pick no tasks, do a base system install only.
Note: virtualbox-ose 2.1.4-dfsg-1ubuntu3 was used for this VM, but
any other virtual machine setup (KVM, vmware server, etc) should
also work fine, as would installing to a spare physical machine.
2) Update System and reboot
sudo apt-get update && sudo apt-get dist-upgrade -y ## Update system
sudo shutdown -r now ## Reboot system to pick up new kernel etc.
3) Install LAMP Server packages
sudo tasksel install lamp-server ## Install LAMP server
Note: Provide a password for MySQL server when the installer
requests one. Remeber this password (I used "secret").
4) We need ODBC to reproduce issue, so set up for ODBC to MySQL.
Note: The only two config files changed from their defaults are
/etc/odbc.ini and /etc/odbcinst.ini which are zero length by default.
The cp commands above copy the supplied example files, no
changes to these examples are needed for this test setup.
5) Create a PHP test web page under /var/www/ and verify it runs
echo -e "<?php\nphpinfo();\n?>\n" |sudo tee /var/www/phpinfo.php
wget -O info.html http://localhost/phpinfo.php
w3m info.html ## Examine carefully, esp. Suhosin info
Note: info.html should show the full phpinfo output, and it should
include the information that "This server is protected with the
Suhosin patch". Keep the info.html file in case it is needed later
on during testing.
6) Create a test database and a testdb table in it, and 2 records
PW=secret ## Use the password you set for mysql root earlier
echo "create database test;" |mysql -uroot -p"$PW"
echo "create table testdb ( id int );" |mysql -uroot -p"$PW" test
echo "insert into testdb values (42);" |mysql -uroot -p"$PW" test
echo "insert into testdb values (2001);" |mysql -uroot -p"$PW" test
7) Create PHP page that uses odbc_connect() and odbc_exec()
cat >odbctest.php <<"EOF"
<?php
$pw="secret";
$connection = odbc_connect("myodbc", "root", $pw);
$sql = 'select id from testdb';
$result = odbc_exec($connection, $sql);
while (odbc_fetch_row($result)) {
$id = odbc_result($result, 'id');
echo "$id<br>\n";
}
An attempted set of steps to reproduce this issue follows. I failed to reproduce it!
Those who can reproduce it, please document, in a way similar to this,
exactly how you (and so others!) can also reproduce this issue.
Just in case the web display on LP messes up my PHP script, I am attaching the
odbctest.php test script I used, too.
Steps to Try to Reproduce LaunchPad Bug #315507
1) Create fresh virtual machine, install Ubuntu Server 9.04 Jaunty.
Choose all the defaults, set your own time zone and your own user
name and password. Pick no tasks, do a base system install only.
Install was done from from ISO image ubuntu- 9.04-server- i386.iso 80ad9094f406980 30 and the ISO was releases. ubuntu. com/jaunty/ ubuntu- 9.04-server- i386.iso ).
(md5sum is 20480057590ff8b
downloaded from
http://
Note: virtualbox-ose 2.1.4-dfsg-1ubuntu3 was used for this VM, but
any other virtual machine setup (KVM, vmware server, etc) should
also work fine, as would installing to a spare physical machine.
2) Update System and reboot
sudo apt-get update && sudo apt-get dist-upgrade -y ## Update system
sudo shutdown -r now ## Reboot system to pick up new kernel etc.
3) Install LAMP Server packages
sudo tasksel install lamp-server ## Install LAMP server
Note: Provide a password for MySQL server when the installer
requests one. Remeber this password (I used "secret").
4) We need ODBC to reproduce issue, so set up for ODBC to MySQL.
sudo apt-get install php5-odbc libmyodbc unixodbc -y libmyodbc/ odbcinst. ini /etc/ doc/libmyodbc/ examples/ odbc.ini /etc/
sudo cp -p /usr/share/
sudo cp -p /usr/share/
sudo service apache2 restart
Note: The only two config files changed from their defaults are
/etc/odbc.ini and /etc/odbcinst.ini which are zero length by default.
The cp commands above copy the supplied example files, no
changes to these examples are needed for this test setup.
5) Create a PHP test web page under /var/www/ and verify it runs
echo -e "<?php\ nphpinfo( );\n?>\ n" |sudo tee /var/www/ phpinfo. php localhost/ phpinfo. php
wget -O info.html http://
w3m info.html ## Examine carefully, esp. Suhosin info
Note: info.html should show the full phpinfo output, and it should
include the information that "This server is protected with the
Suhosin patch". Keep the info.html file in case it is needed later
on during testing.
6) Create a test database and a testdb table in it, and 2 records
PW=secret ## Use the password you set for mysql root earlier
echo "create database test;" |mysql -uroot -p"$PW"
echo "create table testdb ( id int );" |mysql -uroot -p"$PW" test
echo "insert into testdb values (42);" |mysql -uroot -p"$PW" test
echo "insert into testdb values (2001);" |mysql -uroot -p"$PW" test
7) Create PHP page that uses odbc_connect() and odbc_exec() "myodbc" , "root", $pw); $connection, $sql);
cat >odbctest.php <<"EOF"
<?php
$pw="secret";
$connection = odbc_connect(
$sql = 'select id from testdb';
$result = odbc_exec(
while (odbc_fetch_ row($result) ) { $result, 'id');
$id = odbc_result(
echo "$id<br>\n";
}
odbc_free_ result( $result) ; $connection) ;
odbc_close(
?>
EOF
sudo cp -p odbctest.php /var/www/
8) Browse the odbctest.php page
w3m http:// localhost/ odbctest. php
NOTE: w3m should display two lines, one with the number 42 and the
other with the number 2001.
9) Repeat this test a few thousand times, since issue is intermittent
ab -n 5000 http:// localhost/ odbctest. php
10) Repeat step 8 to check whether PHP and ODBC are still working fine
11) Document exact versions of packages involved:
dpkg-query -W apache2 libapache2-mod-php5 libmyodbc \
mysql-server php5-common php5-cli php5-odbc
apache2 2.2.11-2ubuntu2.2 1-3ubuntu4. 1 4ubuntu1 0.75-0ubuntu10. 2 1-3ubuntu4. 1 1-3ubuntu4. 1 1-3ubuntu4. 1
libapache2-mod-php5 5.2.6.dfsg.
libmyodbc 3.51.15r409-
mysql-server 5.1.30really5.
php5-cli 5.2.6.dfsg.
php5-common 5.2.6.dfsg.
php5-odbc 5.2.6.dfsg.
SUMMARY: All software involved behaved as expected.
Reported issue #315507 was not reproduced.