Re: Testing Linux Client

To All, Success at long last. I have managed to connect using Jonathon's suggestion of CONNECT statement and sending the username and password. I also managed to connect using my original script by logging into my client machine as informix and informix. Thanks again for all your help Ian. Jonathan Leffler wrote: > 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 > >> >sqlho