Re: configuring sqlexecd for remote tcp connections.. problems :(

Jonathan Leffler wrote: > matthewlenz@gmail.com wrote: > > server: sco osr 5.0.6 > > db server: informix 7.24.UC10 (output from dbaccess -v) > > > > client: debian sarge 3.1 linux > > db client: informix clientsdk 2.90.UC3 > > > > database I wanna connect to is called 'local_se' when I use dbaccess > > from the command line on the server. > > That is on the SCO machine? yes.. as described above > Is the SCO box also running sqlexecd > listening to the correct port? yes.. after I started it, there was no remote connections enabled on this machine. > What is the name of the server (SCO) > machine? coca > > I'd like to verify my settings with you guys to see if you spot any > > issues: > > > > here are the contents of the $INFORMIXDIR/etc/sqlhosts on the SERVER > > after I added the last line: > > > > demo_on onipcshm on_hostname on_servername> > demo_se seipcpip se_hostname sqlexec > > tms_se sesoctcp coca sqlserv > > local_se seipcpip coca sqlexec > > localse_remote setlitcp coca 1526 > > OK - sorta. Usually, you use a service name, but the number should work > too. SCO might use setlitcp, but the previous entry - tms_se - suggests > that (a) it might use sesoctcp instead, and (b) there may already be a > service ready and waiting. I'll try 'soc' on both. > What happens when you run DB-Access on the SCO machine and connect to: > > yourdb@tms_se when I run dbaccess (without any parameters) I go in a select a database listed as dta@local_se .. I assumed that dta was a user and local_se was the database, was i correct? > What is the sqlserv service number? Is there an sqlexecd running and > monitoring that port? see below, yes I started it with the command below. > > I have no idea what the other entries before mine are about. 'coca' is > > the alias in /etc/hosts for the system ip of the server. and I started > > the sqlexecd with the following command in the $INFORMIXDIR/lib > > directory: > > > > ./sqlexecd localse_remote > > Given the sesoctcp entry, I'm dubious about this. > It might be an idea to run sqlexecd with logging (-l /log/file). thats a good idea, I'll try that again if the hosts config file doesn't work. > Is it still running. > > I've normally run $INFORMIXDIR/lib/sqlexecd, but what you did should > work as long as DBPATH for sqlexecd is set to locate the actual SE > database directory reliably. If dbaccess is able to find it using the same environment sqlexecd should be fine right? > > it started just fine and verified that it was running with a ps -Ae and > > I could: > > > > telnet coca 1526 > > > > and see that it was establishing a tcp connection. > > > > .... > > OK - that answers that - probably. Something was running on the port. yep.. sqlexecd is running on it cuz I started it as I mentioned. :) > > > here are the contents of my $INFORMIXDIR/etc/sqlhosts on the CLIENT > > after I added the last line: > > > > demo_on onipcshm on_hostname on_servername> > demo_se seipcpip se_hostname sqlexec > > Remove these two lines - they are the default (meaningless) entries from > sqlhosts.demo. They show the layout of sqlhosts entries, but that's > about all. will do > > localse_remote oltlitcp coca 1526> > A local remote? Interesting naming! lol.. well the database I want to connect to is called local_se I can change it to something else I guess. This is my first time trying to use informix. > > I'm using (perl) DBD::Informix (this problem doesn't seem DBD::Informix > > related) and according to the docs it uses the TLI connect method. > > It uses whatever your system uses - as configured by sqlhosts. It > better be what your system understands. Using oltiltcp on a machine > that expects olsoctcp leads to errors. > > You're on Linux? Use olsoctcp. However, the error you're getting isn't > the one I'd expect for using the wrong connection type. faq in the DBD::Informix sez to use oltlitcp .. maybe thats the problem right there. > So, step 1: reconfigure client to use sesoctcp (SE server, TCP > connections with Sockets library). Step 2: ensure coca is known on the > client (I'm sure it is...just checking!) > > > > Yes, I also added the coca alias to the /etc/hosts on the client as > > well. > > > > $dbh = DBI->connect("dbi:Informix:local_se@localse_remote", "", "") > > > > is the only code I added and I'm getting errors about: > > > > -25596: The INFORMIXSERVER value is not listed in the sqlhosts file or> > the Registry. > > > > so I set the INFORMIXSERVER value to 'localse_remote' and > > INFORMIXSQLHOSTS value to "$INFORMIX/etc/sqlhosts" for good measure and > > removed the @localse_remote from the connect command. Running the same > > perl code again I then received: > > > > -25507: <Failed to locate SQL error message>> > Now that's a familiar number - telling you that oltlitcp is not a good > connection method to use on Linux. ok > What's odd is that the SQL error message could not be found. What was > your INFORMIXDIR set to? Is it a working INFORMIXDIR? > > > my guess was this is just because i'm connecting to such an old version > > of informix with the newest clientsdk. I did some searching and it > > looks like its something along the same lines about not finding the > > correct information in the sqlhosts file. > > > > What did I do wrong guys? I'd really appreciate any help you can offer. > > Generally, CSDK is pretty good about connecting - both backwards and > forwards. It might be the version mismatch - but I think you need to > fix the configuration first. Worry about why Perl or ESQL/C couldn't > find the error message. Fix the sqlhosts file. hehe I'll try but you didn't really give me a straight answer as to what I'm supposed to do. My guess is on on the server use sesoctcp and on the client use olsoctcp. I only ever tried the tli stuff cuz thats what your faq sez to use. > (How did you test DBD::Informix on the Linux machine if you couldn't > access a database server?)> lol, I didnt :( Which is why I posted here instead of asking you directly cuz I knew you'd ask me the same question. This is a clients machine, we are doinga read-only integration with our software (only doing selects) and I feel _really_ uncomfortable having the DBD::Informix build process creating a database or whatever. So I disabled the part that tries to connect. I verified that esql test file was able to compile and run without any library errors and the rest of everything built beautiful with no warnings. I realize that you are trying to weed out these problems by attempting to force people to be able to create databases and perform queries but in a situation like mine I think my only recourse would be to attempt to setup my own informix server. I have no knowledge of informix beyond various documentation I've been re

matthewl...@gmail.com wrote: > Jonathan Leffler wrote: > > > I'd like to verify my settings with you guys to see if you spot any > > > issues: > > > > > > here are the contents of the $INFORMIXDIR/etc/sqlhosts on the SERVER > > > after I added the last line: > > > > > > demo_on onipcshm on_hostname on_servername> > > demo_se seipcpip se_hostname sqlexec > > > tms_se sesoctcp coca sqlserv > > > local_se seipcpip coca sqlexec > > > localse_remote setlitcp coca 1526 > > > > OK - sorta. Usually, you use a service name, but the number should work > > too. SCO might use setlitcp, but the previous entry - tms_se - suggests > > that (a) it might use sesoctcp instead, and (b) there may already be a > > service ready and waiting. > > I'll try 'soc' on both. ON THE SERVER i removed my localse_remote and created a new entry: remote_se sesoctcp coca sqlserv I added: sqlserv 1526/tcp to the /etc/services file running: $INFORMIXDIR/lib/sqlexecd remote_se resulted in: daemon err = 25507: The specified service name or protocol is unknown. But it did run before when I was using 'tli'. So the question is can the sqlexecd use 'tli' and the client use 'soc'? I modified the remote_se connection to setlitcp and reran the sqlexecd command above and it started just fine. Keep in mind that there was no sqlexecd running before I started all this stuff and NO services listening on 'sqlserv' because that service entry didn't even exist. i don't know why that tms_se entry was added. I even tried sqlexecd tms_se and it resulted in the same 25507 error. so basically it looks like sco sqlexecd doesn't like 'sesoctcp' but runs when I use 'setlitcp'. > > You're on Linux? Use olsoctcp. However, the error you're getting isn't > > the one I'd expect for using the wrong connection type. > > faq in the DBD::Informix sez to use oltlitcp .. maybe thats the problem > right there. > > > So, step 1: reconfigure client to use sesoctcp (SE server, TCP > > connections with Sockets library). Step 2: ensure coca is known on the > > client (I'm sure it is...just checking!) > > > > > > > Yes, I also added the coca alias to the /etc/hosts on the client as > > > well. > > > > > > $dbh = DBI->connect("dbi:Informix:local_se@localse_remote", "", "") > > > > > > is the only code I added and I'm getting errors about: > > > > > > -25596: The INFORMIXSERVER value is not listed in the sqlhosts file or> > > the Registry. > > > > > > so I set the INFORMIXSERVER value to 'localse_remote' and > > > INFORMIXSQLHOSTS value to "$INFORMIX/etc/sqlhosts" for good measure and > > > removed the @localse_remote from the connect command. Running the same > > > perl code again I then received: > > > > > > -25507: <Failed to locate SQL error message>> > > > Now that's a familiar number - telling you that oltlitcp is not a good > > connection method to use on Linux. ON THE CLIENT maybe I'm confused about the whole '@' thing. #!/usr/bin/perl use DBI; $dbh = DBI->connect("dbi:Informix:local_se\\@remote_se", "dta", "") or die "A horrible death!"; I modified my client's sqlhosts to contain an entry: remote_se olsoctcp coca 1526 and I receive: DBI connect('local_se@remote_se','dta',...) failed: SQL: -25596: The INFORMIXSERVER value is not listed in the sqlhosts file or the Registry. at t line 5 A horrible death! at t line 5. remember I mentioned that when I use dbaccess on the server I have to use dta@local_se to connect to the database. I have no idea what the dta part is I thought it was a username. I think this stuff probably works, but its me not having a clue about informix :(

getting further: set the following environment variables: INFORMIXDIR=/opt/informix INFORMIXSERVER=remote_se I always had INFORMIXDIR set but wasn't setting INFORMIXSERVER because I was using the @remote_se notation in the connect string. setting INFORMIXSERVER and removing @remote_se from the connect string: $dbh = DBI->connect('dbi:Informix:dta', "", "") or die "A horrible death!"; results in: DBI connect('dta','',...) failed: SQL: -956: Client host or user (<clientuser>@<clientmachinename>) is not trusted by the server. ISAM: 2: No such file or directory at t line 5 A horrible death! at t line 5. I removed the <clientuser>@<clientmachinename> cuz I don't want that kinda stuff on usenet. but basically they are the logged in user I'm running the script as and the machine I'm running it on. So I guess the next step is finding out how to allow that user access. Next thing I tried was: $dbh = DBI->connect('dbi:Informix:dta', '<serveraccount>', '<serverpassword>') or die "A horrible death!"; where <serveraccount> is my account name on the sco box and <serverpassword> is my system password on the machine. I then received: DBI connect('dta','<serveraccount>',...) failed: SQL: -329: Database not found or no system permission. ISAM: -2: No such file or directory at t line 5 btw, t is the name of the program I'm running. I'm going to try to enable the log like you mentioned.