Re: Testing Linux Client

On Thu, 28 Sep 2000, Ian Thurbon wrote: >Thanks again for all you help. Unfortunately I have still not managed a >connection. Here is what I have tried so far. First, well done for being persistent, and thank you for a clear explanation of what you've tried. Both of these help us help you solve the problem. >1. I added s=0 as the fifth parameter in each sqlhosts entry. This did not >have any effect, I still recieved the same error "Client (%s) or user is not >trusted by the database server". > >2. I executed the command GRANT dba to username, although i'm sure i >did not need to do this becuase I am using informix as my user and >password. The command executed correctly and said that permission was >granted but unfortunatley on reconnecting i recieved the same error. This isn't (yet) a database level privilege problem; it is an o/s level privilege problem. >3. I created a host.equiv file with a "+" in it and added it to >"winnt/system32/drivers/etc/" folder and I checked that I was able to >ping between both machines. When attempting connection I recieved a >new error "-349 Database not selected". I checked to ensure that the >database was running from another client (win) and it connected >successfully. So you can access the IDS on NT server from Windows clients? >4. As suggested by Jonathon I executed "rsh <servername> ls" and an >error occured saying permission denied. According to my MIS guy, this >is to be expected becuase he has disabled rsh on the server. Yes, that will cause problems. It invalidates the test I suggested. >In response to your question, Jonathon, I am using shadow passwords >with MD5 encryption. And therein, possibly, lies the problem. Since we don't know the exact version number of your server, I suspect that if you switched off either or both of shadow and MD5 passwords on your Linux server, you would probably be OK. I'm not sure whether it matters what you are using on the Linux client; I think not. However, don't change the setup until you've tried the CONNECT notation discussed further down this message. >The server versions are IDS2000 I'm sorry to be blunt, but that's a product name, not a version. A version is something like 9.20.UC8-2 or 9.21.UC1-1; the '-N' suffix might or might not be part of what you see. Some versions of IDS.2000 may not work with shadow passwords and MD5 encryption -- the 9.21 versions are supposed to. The *exact* version number *really* matters. >on Red Hat 6.2 and Dynamic Server 7.3 on NT. The CSDK is v2.4 for >Linux. Again, the full versions (7.30.TC2 and 2.40.UC1) might be helpful, though not as critical. >I added FQDN to the hostname parameters in sqlhosts but this too did >not make any difference. That matches what I found on my RH6.2 box, I think. >5. I checked to see whether I had a .rhosts file on my Linux server in >the Informix home directory but it did not exist. I added one and >entered the client hostname to the file, but it did not make any >difference. However I am not sure the format of the .rhosts file was >correct. It would only matter if you're connecting while logged in as user informix. You are doing that, are you? There is absolutely no call to be logged in as user informix once CSDK is installed. >My connect.ec file connects using "$database :xName;" where xName is >the database name.When compliling this using esql the connect.c file >has translated the command to "sqli_db_open(xName, 0);". This >connection does not take a username and password as a parameter, so how >does the server know my username and password? On windows the username >and password are set in the SETNET facility, what is the linux >equivalent for setting username and password? It doesn't know which password to use, so it relies on the current Unix user ID being able to connect to the remote system without having to specify a password. And you don't have the privileges to do that -- that's what the 'Client or user is not trusted by the database server' message means. Use the CONNECT variant I sent. >Ian. > > >Jonathan Leffler wrote: > >> On Wed, 27 Sep 2000, Ian Thurbon wrote: >> >Thanks Jonathan, Art and John for you help. I plan to port an existing >> >windows informix application to linux and before I start the port, I >> >wanted to ensure the client was correctly set-up. >> >> Wise; very wise. >> >> >I took your advice and quickly created an ESQL/C application that >> >connects to my server and hey presto! it failed. The errorcode is -956 >> >- "Client (%s) or user is not trusted by the database server". >> >> Oh dear. >> >> Did you use the simple 'DATABASE statement' programs I showed? You >> could consider trying the alternative 'CONNECT statement' instead: >> >> EXEC SQL CONNECT TO 'remotedbs@server' AS 'myconn' >> USER 'username' USING 'password'; >> >> It gives you more to edit which is why omitted it as an option first >> time around. >> >> >I have tried this against an NT server and a Linux server both with the >> >same error. >> >> That is, you tried connecting from your new Linux box to an alternative >> Linux server with a known-to-be-OK database server running on it, and >> also to an NT server with a known-to-be-OK database server running on >> it, and both connection attempts failed the same way. Is your Linux >> user able to do "rsh altlinux ls", where altlinux is the name of your >> alternative Linux server? Is that box running with MD5 passwords or >> shadow passwords? Both are known problem areas for early versions of >> Informix. Exactly which versions of the servers are you running on >> those remote machines? Exactly which version of CSDK are you using on >> your new machine? >> >> >These servers are working with my windows clients correctly. I checked >> >the Hosts.equiv file on the server and it contains "+ +", which i >> >understand means any client, any host. >> >> Assuming you are referring to /etc/hosts.equiv (lower case), you might >> want to review that! It may be safe enough to get you up and running, >> but in the medium term (let alone the long term and potential deployment >> of the system), you should not run a machine with that level of >> insecurity, not even within an intranet. Well, I wouldn't... >> >> >I have ensured that the INFORMIXSERVER variable contains the correct >> >name and also ensured that two correct entries are added to the >> >sqlhosts file on the client, one for each server. I have also added >> >the correct protocol and port number to the services file. Is there >> >anything I have missed or should check on the server or client that may >> >cause this problem? >> >> The hostname for the Linux server should be the FQDN (fully qualified >> domain name); whatever it is that "uname -n" says. [...but I just >> checked my RedHat 6.2 box which gives horus now, instead of >> horus.informix.com, but horus.informix.com seems to be OK in the >> sqlhosts file. >> >> >Jonathan Leffler wrote: >> >> On Tue