[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    Re: [freetds] PHP odbc_connect : sql error
From:       "Rowland, TJ (LVA)" <TJ.Rowland () lva ! virginia ! gov>
Date:       2008-12-17 20:53:41
Message-ID: DC72670C131EB245A9035168A3FB31DB5D02A4 () COVMSGCES-EMB05 ! cov ! virginia ! gov
[Download RAW message or body]

James - Many thanks.

It turns out that the problem was two fold. 

1) SELinux was blocking access, as you pointed out. I corrected this by
disabling SELinux entirely. 

2) Also, I had two odbc.ini and odbcinst.ini files in different
directories. So while I was updating one set (probably the leftovers
from the RHEL5 default install), PHP was looking at the other/empty
files. Ah well, live and learn. 

Hopefully my mistakes can help someone else out later on.

-----Original Message-----
From: freetds-bounces@lists.ibiblio.org
[mailto:freetds-bounces@lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Tuesday, December 16, 2008 1:21 AM
To: FreeTDS Development Group
Subject: Re: [freetds] PHP odbc_connect : sql error

Rowland, TJ (LVA) wrote:
> I can connect to SQL Server with both tsql and isql, and also from a
> shell using the php command. 
...
> I checked my freetds.log file and the following errors were noted:
> net.c:204:Connecting to 10.1.1.51 port 1214 (TDS version 5.0)
> net.c:258:tds_open_socket: connect(2) returned "Permission denied"

What we have here is a failure to communicate.  (Sorry, I couldn't help
myself.)  

It's the kernel: the account hosting your webserver lacks permission to
open an outbound TCP connection.  

Have another look at the man page for connect(2) on your system. ("man
errno" may also help).  You should find something like this:

 [EACCES]
    Search permission is denied for a component of the
    path prefix, or write access to the named socket is
    denied.

That's what happened: FreeTDS tried to connect to the server.  To do
that,
it invokes the socket API system call, connect(2).  That call failed
with
EACESS, meaning the process is not allowed to make that connection.  

> I thought it might be a firewall problem

No, it's not the firewall.  A firewall doesn't grant *permission*,
really.
 It passes or doesn't pass packets, but it's just a network gate.  To
the
sending application, a firewall that's dropping packets looks like a
faulty network, and the most likely error is a timeout.  

I don't know how a process can be so constrained; maybe your firewall is
part of your kernel and causes connect(2) to behave that way.  But in
any
case, look no further than your local box for the answer.  

HTH.  

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
[prev in list] [next in list] [prev in thread] [next in thread]