Return info about PHP installation mySQL compatibility

[Robin S.]

I've used phpinfo() to confirm settings for mySQL on our host server,
and it's not returning accurate info.

phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

Is there any more thurough method of seeing php's settings for mySQL?
Obviously I don't have access to the installation as it's on a remote
server - megasqlservers.com

The reason I'm asking is that I've installed a shopping cart on our
host server which is currently returning:

**************************************
Warning: mysql_pconnect() [function.mysql-pconnect]: Can't connect to
local MySQL server through socket '/tmp/mysql.sock' (2)

Warning: mysql_select_db() [function.mysql-select-db]: Can't connect
to local MySQL server through socket '/tmp/mysql.sock' (2)

Warning: mysql_select_db() [function.mysql-select-db]: A link to the
server could not be established

Warning: session_start() [function.session-start]: Cannot send session
cache limiter - headers already sent

2002: Can't connect to local MySQL server through socket '/tmp/
mysql.sock' (2)
**************************************
(web addreses and directory structure has been removed for this
message)

I installed Apache, PHP and mySQL on my own box and installed the
shopping cart using the same installation files as on the remote
server, and everything works correctly.

I'm trying to diagnose the problem as our host doesn't seem to know
what's going on.

Any thoughts?

Regards,

Robin

[Robin S.]

On Jan 10, 11:03*am, "Robin S." <[e-mail]:

>
phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

Any thoughts?

Regards,

Robin

Small update:

I just installed the shopping cart software on my local box using the
remote SQL server (megasqlservers.com) and it worked. So I guess it's
not a mySQL problem.

What could be wrong with PHP?

Regards,

Robin

[Rik Wasmus]

On Thu, 10 Jan 2008 17:25:15 +0100, Robin S. <la*******@hotmail.comwrote:

On Jan 10, 11:03*am, "Robin S." <[e-mail]:

>>
phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

Any thoughts?

Regards,

Robin

Small update:

I just installed the shopping cart software on my local box using the
remote SQL server (megasqlservers.com) and it worked. So I guess it's
not a mySQL problem.

What could be wrong with PHP?

Hmm, what happens if you define it's hostname/ip instead of using
localhost?
--
Rik Wasmus

[Anonymous]

"Robin S." wrote:

>
I've used phpinfo() to confirm settings for mySQL on our host server,
and it's not returning accurate info.

phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

Does your provider still use PHP4? Then this API version should be
expected. IIRC that version was statically linked into PHP. At least in
the windows version of PHP, I don't know about Linux/Unix versions.

But that shouldn't be a big problem, even this stoneage API is still
compatible with the latest MySQL. You just have to remember to use the
old-passwords option on the server or you will get the 'Client does not
support authentication protocol' error when connecting to the database,
but that doesn't seem to be your problem.

And of course you can't use any of the new MySQL features (transactions,
prepared statements, etc.) but you couldn't use these with the mysql API
anyway, you would have to update to PHP5 and use the mysqli API instead
to use all the new and cool features. If your host hasn't updated to
PHP5 yet tell them to do so, PHP4 is considered deprecated and is
unsupported as of 1.1.2008. If they are already using PHP5 they must
have a stoneage extension or client library somewhere in their search
path that gets loaded instead of the up to date one.

It looks to me like a configuration problem on your hosts side.

P.S.: You can connect to the MySQL server of your host from your local
computer? That's a security nightmare! You should consider switching
hosts in any case.

Bye!

[Robin S.]

On Jan 10, 12:35*pm, "Rik Wasmus" <[e-mail]:

Hmm, what happens if you define it's hostname/ip instead of using *
localhost?

Rik,

I have defined the hostname (sql****.megasqlservers.com) throughout
this process. Localhost doesn't work (mySQL server is not on the same
server).

Should the errors refer to "remote" as opposed to "local"?

Regards,

Robin

[Robin S.]

On Jan 10, 1:14*pm, Anonymous <[e-mail]:

"Robin S." wrote:

I've used phpinfo() to confirm settings for mySQL on our host server,
and it's not returning accurate info.

phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

Does your provider still use PHP4? Then this API version should be
expected. IIRC that version was statically linked into PHP. At least in
the windows version of PHP, I don't know about Linux/Unix versions.

Currently, the WebsiteOS program (on the website host server) lists
PHP5 as being used. PHP4 is an option, but it's not currently used (I
tried to switch it about two hours ago. Same errors, but slightly
different error messages, but no further ahead. The shopping cart
should be compatible with PHP4 anyway, but I guess that's not too
important right now).

>
But that shouldn't be a big problem, even this stoneage API is still
compatible with the latest MySQL. You just have to remember to use the
old-passwords option on the server or you will get the 'Client does not
support authentication protocol' error when connecting to the database,
but that doesn't seem to be your problem.

Actually, the first error listed in my origianl message is generated
on a password line of a mysql_pconnect in the session.inc script. See
code:

*************************
$mysql_connect = mysql_pconnect ($this->hostName,
$this->userName,
$this->password);
$mysql_db = mysql_select_db ($this->database);
**************************
*btw - the original programmer explicidly states that a mysql_pconnect
is required, just just mysql_connect...

The first error I listed is generated on the third line down:

($this->password);

and the second error is generated on the following line:

$mysql_db = mysql_select_db ($this->database);

>
It looks to me like a configuration problem on your hosts side.

Any thoughts spcifically? I'm sure there are a couple dozen things
that could be wrong, but if I can lead the tech support guys in the
right direction, perhaps they can solve it...

We started with one host who couldn't figure out the issue (they
basically insisted it was the shopping cart). We've just switched to a
new host, but they seem to be using a *very* similar configuration.

Both use sql****.megasqlservers.com for mysql, as well as an identical
site management software "websiteOS", and an identical host directory
structure). Just did a tracert - the old domain/host has a completely
different IP than the new host/domain (we're keeping the old host
until we can find a new one that works. We have our main domain name
pointing to the old host, and we used an outdated domain name we still
own to try out the new host).

>
P.S.: You can connect to the MySQL server of your host from your local
computer? That's a security nightmare! You should consider switching
hosts in any case.

Well, Apache/PHP installed on my computer seems to be able to perform
queries on the remove SQL server, although it requires the appropriate
user/pass. This shouldn't be the case?

Sorry, I'm not an admin. This cart software should have installed and
run without any admin/programming knoweldge on my part.. I'm just
trying to diagnose the problem.

Thanks for the assistance guys. Anything further would be most
appriciated. Tech support at the new host seems to be better than the
old, but I'd like to be able to guide them to fixing my problem if I
can.

Regards,

Robin

[Jerry Stuckle]

Robin S. wrote:

On Jan 10, 12:35 pm, "Rik Wasmus" <[e-mail]:

>Hmm, what happens if you define it's hostname/ip instead of using
localhost?

Rik,

I have defined the hostname (sql****.megasqlservers.com) throughout
this process. Localhost doesn't work (mySQL server is not on the same
server).

Should the errors refer to "remote" as opposed to "local"?

Regards,

Robin

Are you sure you defined the MySQL server correctly to your shopping
cart? As it is right now, it's trying to connect to MySQL on the same
machine.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Robin S.]

On Jan 10, 3:37*pm, Jerry Stuckle <[e-mail]:

>
Are you sure you defined the MySQL server correctly to your shopping
cart? *As it is right now, it's trying to connect to MySQL on the same
machine.

During the initial installation, the remote mySQL server was correctly
defined. This is required to perform the installation. I can tell
because all of the required tables were successfully created
(automatically by the cart software) on the remote server (confirmed
using phpMyAdmin).

The installation using my PC as the Apache/PHP server and the remote
mySQL server was also successful. I've added some products and changed
some settings, and it works.

Note that I did omit some path info in the error messages for security
purposes...

I certainly appriciate your consideration.

Regards,

Robin

[Jerry Stuckle]

Robin S. wrote:

On Jan 10, 3:37 pm, Jerry Stuckle <[e-mail]:

>Are you sure you defined the MySQL server correctly to your shopping
cart? As it is right now, it's trying to connect to MySQL on the same
machine.

During the initial installation, the remote mySQL server was correctly
defined. This is required to perform the installation. I can tell
because all of the required tables were successfully created
(automatically by the cart software) on the remote server (confirmed
using phpMyAdmin).

The installation using my PC as the Apache/PHP server and the remote
mySQL server was also successful. I've added some products and changed
some settings, and it works.

Note that I did omit some path info in the error messages for security
purposes...

I certainly appriciate your consideration.

Regards,

Robin

Well, the message indicates it's trying to connect to MySQL through the
local Unix socket, not via TCP/IP. So either your configuration is
incorrect, or the package isn't using the configuration correctly.

So if you're sure it's correct, it's time to ask for help from the
support forums for your package. They're much more familiar with it
than any of us are.

In fact, when you're looking at packages like this, that should be your
first place to go for help - not a language newsgroup.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Anonymous]

"Robin S." wrote:

Currently, the WebsiteOS program (on the website host server) lists
PHP5 as being used. PHP4 is an option, but it's not currently used (I
tried to switch it about two hours ago. Same errors, but slightly
different error messages, but no further ahead. The shopping cart
should be compatible with PHP4 anyway, but I guess that's not too
important right now).

If the cart works with PHP5 stick with that.

Actually, the first error listed in my origianl message is generated
on a password line of a mysql_pconnect in the session.inc script. See
code:

*************************
$mysql_connect = mysql_pconnect ($this->hostName,
$this->userName,
$this->password);

Let's try some error checking. Replace that line with:

---
$mysql_connect = mysql_pconnect ($this->hostName, $this->userName,
$this->password)
or die("MySQL Connect failed.\n
Hostname= $this->hostName\n
Username= $this->userName\n
Password= $this->password\n
Reason= " . mysql_error());
---

If the database connection fails the script should stop and give you the
reason. Is Hostname, Username and Password correct? What is the reason
for the failed connect?

$mysql_db = mysql_select_db ($this->database);
**************************
*btw - the original programmer explicidly states that a mysql_pconnect
is required, just just mysql_connect...

Can you rephrase that sentence?

>
The first error I listed is generated on the third line down:

($this->password);

This is a part of the mysql_pconnect function, not a line of its own. A
newline does not mean anything in PHP, you could just as well replace it
with a space.

>
and the second error is generated on the following line:

$mysql_db = mysql_select_db ($this->database);

Of course, if the connect to the database server fails you can't select
a database.

It looks to me like a configuration problem on your hosts side.

Any thoughts spcifically? I'm sure there are a couple dozen things
that could be wrong, but if I can lead the tech support guys in the
right direction, perhaps they can solve it...

I think Jerry has the right idea about that. PHP tries to connect
through a socket instead of the TCP/IP stack.

P.S.: You can connect to the MySQL server of your host from your local
computer? That's a security nightmare! You should consider switching
hosts in any case.

Well, Apache/PHP installed on my computer seems to be able to perform
queries on the remove SQL server, although it requires the appropriate
user/pass. This shouldn't be the case?

Some providers configure their MySQL servers that way, but as I already
said, that's a security nightmare. Someone who figures out the password
of the MySQL server's root account (or can hack the server through some
vulnerability) can download and change any customer's database. That's
far more difficult if the server is not accessible openly.

A configuration like that would make me wary about that provider because
they are not very network security aware.

[C. (http://symcbean.blogspot.com/)]

On Jan 10, 4:03 pm, "Robin S." <[e-mail]:

I've used phpinfo() to confirm settings for mySQL on our host server,
and it's not returning accurate info.

phpinfo() returns a mySQL client API version of 3.23.54 (uselss for
me), where as a SELECT VERSION() query on the mySQL database returns
version 5.0.27 (exactly what we need). I think there's something wrong
with the mySQL library in PHP.

That's a bit of a gap but it should still work (note this is not an
error - the client code is quite seperate from the server code).

Warning: mysql_pconnect() [function.mysql-pconnect]: Can't connect to
local MySQL server through socket '/tmp/mysql.sock' (2)

As Jerry said - it's trying to use a Unix socket. If you specify the
DBMS host as 'localhost' then the client automatically tries to use a
Unix socket (filesystem based) instead of a TCP/IP socket (network
based). The mysql client will try to read my.cnf to find where the
socket is - the location of my.cnf is defined at compile time. Of
course this only works if both server and client use the same my.cnf
(and the values aren't overridden in the MySQL startup script). On the
client side you can override the my.cnf setting with the
mysql.default_socket setting in php.ini.

If the mysqld is listening on a network port then you may be able to
use a network socket instead by specifying the FQDN of the box, an IP
adress for the box or '127.0.0.1' as the address - but then you have
the same problem of ensuring that both ends are using the same port,
and there is the additional complication of firewalls in between.

C.

[Jerry Stuckle]

Robin S. wrote:

On Jan 10, 1:14 pm, Anonymous <[e-mail]:

>"Robin S." wrote:

*btw - the original programmer explicidly states that a mysql_pconnect
is required, just just mysql_connect...

Also - I would get rid of that programmer in a second. Anyone who
thinks that mysql_pconnect() is necessary doesn't understand PHP or
MySQL. What is his explanation for it being necessary?

In the vast majority of websites, using mysql_pconnect() will hurt more
than it it will help.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================