At 04:05 AM 22/01/2007, you wrote:

>Sorry that this mail didn't go through. It only took 3 days for it to
>bounce back to me :-( .
>Thanks for all the help you have been giving me.
>
> From all the information that I have gotten from everyone, this seems
>more and more a FB problem.

FB doesn't like you? :-) Beg pardon, but this seems more and more a
system configuration problem. Firebird is not known for targeting people....

>Would it make sense at this point to reinstall? Do I need to unistall
>first and how would I do that.

If you have been fiddling about with the configuration files,
possibly. Considering how experimental your setup is, despite having
little understanding of either the server architecture or what you're
doing with Xen, then any fiddling you did with the Firebird files
would indicate a clean install being an excellent idea.

If you haven't fiddled with them, then a reinstall wouldn't change anything.

You seem not to have tried some of the more obvious things yet - like
establishing whether the local loopback server is supposed to be
accessible by a guest system in Xen.

>Should I just run the install over top the current installation?

Is that what you have done previously?

> > 1) If you used ISQL locally, i.e., not via the localhost server,
> > then you are not using xinetd OR the local loopback server. You are
> > connecting directly to the database via a Classic process that is
> > embedded in libfbembed.so, not an instance of the fb_inet_server
> > executable started by xinetd.
> >
>Yep, that's what I did.

Then direct local connection worked as expected.

> > 2) Do you know whether localhost is even available to a Xen virtual
> > server? If not, you'll need to use the virtual server's IP address
> > and the libfbclient.

You didn't answer this. It's crucial.

>so as your client library. The libfbembed.so
> > client allows a localhost connection is localhost is available but it
> > can't do a connection via a real remote connection...I'm kinda
> > envisaging some kind of parallel between your problem and the problem
> > that a local RTS client with localhost on Windows.
> >
> >
>Tried this, but think it is over my head. Any chance you can give me
>the "For Dummies" directions :-)

Sure. Or you could read the Quickstart Guide.

On Linux there are two client libraries available: libfbembed.so and
libfbclient.so.

libfbembed:
========
As its name suggests, libfbembed has the server code embedded in
it. This library has everything in it that fb_inet_server has. When
you use libfbembed.so to connect to a database directly (as you have
already succeeded in doing) the client literally creates its own
server process that is owned by the Linux user that invoked
libfbembed.so. That user opens the database file directly, provided
it has both the filesystem permissions to open the file AND the
database server permissions. You haven't reported any permissions
problem doing this so I guess you are logged in as the Linux root
user. This style of connection is not a network connection and it
does not access xinetd at all.

libfbembed does not provide a remote client interface. This means
that, if you try to use libfbembed as an xinetd client to this host,
you will get the "Connection was actively refused" error that you reported.

However, there is one exception to this limitation: libfbembed.so on
a normal Linux box *can* connect to a physically local database via
xinetd, through the local loopback server, localhost, if the LLS
service is available *to the client*. That is what you have been
trying unsuccessfully to do, which is why several people have been
trying to show you ways to find out why your guest Linux *client* in
this context is unable to access the guest *server* through the
parent machine's local loopback server.

I still suspect that it will turn out to be the case that Xen does
not provide this routing. For an xinetd connection, I think it is
likely that you will need to make the remote client interface
library, libfbclient.so, visible to the application programs and use
the hostname/IP address of the guest server in the connection string.

libfbclient.dll
=========
This is the library that clients on Linux machines need to access a
Firebird server remotely, i.e. via network connection. If you had
installed Superserver instead of Classic, libfbembed.so would not
even be in the picture, since Superserver does not support the direct
local connection at all. Access by a local client can *only* be via
the local loopback server.

If my theory about Xen and local loopback server access is right then
you would have the same problem with localhost access to Superserver
and you would still need to configure the *system* correctly to make it work.

And *that* seems to be your problem: localhost appears to be
unavailable to your guest system. Hence all the questions that Milan
and Steve have been trying to get you to answer.

So - if a client on your guest system wants to make a remote
connection to a database, it has to use libfbclient.so and it has to
use the network-visible hostname (or IP address) to access the server.

One important thing that you seem not to be taking note of is that a
remote connection *requires* a valid FIREBIRD user name and
password. Having root access doesn't do it, since root on a server
is not regarded as being the same as root on the client. In your
latest reply to Milan you appear to have ignored this:

linux1fb:/opt/firebird # bin/isql
143.0.0.86:/opt/firebird/examples/empbuild/employee.fdb
Statement failed, SQLCODE = -923
connection rejected by remote interface

Should have been

linux1fb:/opt/firebird # bin/isql
143.0.0.86:/opt/firebird/examples/empbuild/employee.fdb

should have included -user blah -password validpsw

"connection rejected by remote interface" is not a firebird error,
it's a network error. Omitting the login creds would normally cause
Firebird to return "Your username and password are not
defined...etc." to the client, but the Firebird server's rejection
is being passed back to the *network* client's request as a generic
*network* exception.

So you should at least try to connect to the guest server's hostname
using the *correct* parameters, to test whether the "client"
component of the installed libfbembed.so client can establish a
network routing to xinetd. If this fails then you can get hold of
libfbclient.so and begin another drama series changing the symbolic
links to point to it instead of libfbembed.so.

>
>Actually I am not to bad with vi. I didn't check the /etc/hosts file.
>What should be in there?
>
>There is a localhost , 127.0.0.1

That's a start. You'll need an entry for each of the IP addresses
that various things are interested in. You'll need to find out
(probably from the Xen docs, or their support lists) how localhost in
the guest system is resolved to localhost at machine level.

>Here is some info from tcpdump (suggested by the folks over in the XEN
>list server). 143.0.0.88 is my computer. linux1fb.webonedeveloper is
>the server.
>
>21:46:05.014922 IP (tos 0x0, ttl 128, id 16073, offset 0, flags [DF],
>proto: TCP (6), length: 48) 143.0.0.88.linx >
>linux1fb.webonedeveloper.gds_db: S, cksum 0x2f3f (correct),
>1811397902:1811397902(0) win 64240 <mss 1460,nop,nop,sackOK>
>21:46:05.015192 IP (tos 0x0, ttl 128, id 16074, offset 0, flags [DF],
>proto: TCP (6), length: 40) 143.0.0.88.linx >

...etc.

It looks like a useful tool, if one could just work out what the
output means...I've never used it...nor ever needed to. But
considering I have a licensed copy of VMware WS 5 here, that I've had
for several months, waiting for me to get time to install it on one
of my Linux boxes, it looks as though this tool could be handy to know about.

I suggest that you give this output to the Xen person who suggested
using tcpdump and tell him that gds_db is the symbol for tcp/ip port
3050. It's likely that someone familiar with troubleshooting Xen
configs will be able to put a finger right on the button.

./heLen