At 02:49 PM 22/01/2007, you wrote:

> > 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.
> >
>
>==================
> From the host file
>
># IP-Address Full-Qualified-Hostname Short-Hostname
>#
>
>127.0.0.1 localhost
>==================

That doesn't tell you anything except that, if localhost were
accessible, 127.0.0.1 would be its IP address.

>There is lots of stuff listening on 127 for it not to work and non of
>the Xen guys (or gals) mentioned anything about and issue with local
>host. Most of them recommended right off that I try telnet 127.0.0.1
>3050 to test if anything was listening on 3050.
>==================
>linux1fb:/etc # netstat -an | grep LIST
> tcp 0 0 0.0.0.0:3050 0.0.0.0:*
> LISTEN
>tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
>tcp 0 0 127.0.0.1:2544 0.0.0.0:* LISTEN
>tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
>tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
>tcp 0 0 :::22 :::* LISTEN
>tcp 0 0 ::1:631 :::* LISTEN
>tcp 0 0 ::1:25 :::* LISTEN

Those are all "standard" IANA port for stuff that is installed
automatically by most Linux installers, other than 2544, which seems
to be used by Novell ZEN, a desktop-based network management
tool. Maybe Xen uses it for something similar.

> > > > 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.
>
>Yes, see below.
>
>linux1fb:/etc # telnet localhost 25
>Trying 127.0.0.1...
>Connected to localhost.
>Escape character is '^]'.
>220 linux1fb.webonedeveloper ESMTP Postfix
>quit
>221 2.0.0 Bye
>Connection closed by foreign host.

Means that Sendmail is running and is waiting for a request from a
client to...well...send mail.

>As a comparison
>
>linux1fb:/etc # telnet localhost 3050
>Trying 127.0.0.1...
>Connected to localhost.
>Escape character is '^]'.
>Connection closed by foreign host.

OK, so, localhost is listening on port 3050 for a client
request. That means at least that it can *accept* a valid client
request...which brings us back to the client and what *it* is doing
that causes its connection request to be refused. Look at the privileges.

> > 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.
>
>This is where you are losing me. I know how to do this on the windows
>side by renaming the dll and over writing the standard client.

That's Windows, you're trying to attach as a Linux client.

>What do I need to do on Linux?

Minimally speaking, nothing. ISQL recognises libfbembed.so as a
client interface. For a localhost connection request, it will invoke
the remote client code and that code will ask xinetd for an instance
of the server process fb_inet_server.

>Do I need to set up a path or virtual path? I am not sure how to
>force it to use libfbembed.so vs the regular client.

Actually, if it became necessary, it would be the other way
around: forcing it to load libfbclient.so instead of
libfbembed.so. And it would be a question of changing the symbolic
link for libfbembed.so to point to libfbclient.so, thus disabling the
real libfbembed.so altogether. At this point, it should not be
necessary. It might *turn out* to be necessary if indeed Xen can't
allow the *guest server* to accept a localhost connection from a
*guest client*.

>tcpdump is a normal utility part of Linux. The Xen guys suggested I
>try it.

Actually, it's not part of Linux. It comes with several distros
(including SuSE, no doubt) and is optional during install. Other
similar utilities are also available on your typical distribution disks.

>I have given them the output, but no one has commented on it.

That would be useful - as long as you explain that gds_db is the
symbol for port 3050.

>I am getting close to giving up on Xen. I am doing this in part as a
>learning experience, as well as I am giving a talk on it at my local
>users group in two weeks.

I reckon I would give up on Xen, too, and grab VMWare instead, 'cause
my patience is even more easily challenged than yours (yes, this
thread REALLY IS making me throw the china!!). But then, on the
other hand, you might find the solution and be able to document both
the symptoms and the solution for the next people who come along and
want to give it a go. That's what is so beaut about open source
software: you get to see the warts.

> > 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.
> >
>
>The are telling me that this is not a Linux error as it would not
>refuse a connection.

Correct. Linux is the operating system. You are not seeing
operating system errors, you are seeing NETWORK errors. You don't
know the cause of the errors (yet) but you know it lies in at least
one of two places: access privileges and/or a routing blockage
between the Xen guest server, port 3050 and the Xen guest client.

>That another program, like a file wall or
>iptable, or even the Firebird fb_inet_server is refusing the
>connection. The question they have is *what* service is refusing the
>connection. No one seems to be able to give me a utility that I could
>use to step through exactly what services are handing the IP requests
>and in which order.

The service that is refusing the connection is xinetd. And it's
doing that because either it's getting an illegal attachment request
from the client or the attachment request is OK but the potential
owner of the served process (user 'firebird') does not have the
required permissions to open the database file in read/write mode.

>Should there be at least on fb_inet_server running at the beginning as
>the Listener?

No. xinetd is a daemon process whose job is to listen out for
requests on behalf of all the various jobs that it knows about (via
files in xinetd.d).

>I noticed in the Quick Start page 12 in the "Note" box,
> is this only for Windows?

Yes. Windows doesn't have daemons, so things are different
there. The running fb_inet_server on Windows listens and then
creates a clone of its main process code for each successful request.

>Is there a log on Linux I can check for this? I will ask the suse and
>Xen lists too.

Check for what?

./heLen