--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> 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.
>

Haven't touched them.

> 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.
>

==================
From the host file

# IP-Address Full-Qualified-Hostname Short-Hostname
#

127.0.0.1 localhost
==================
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
====================
trying telnet 127.0.0.1 25 was successful
====================
linux1fb:/etc # telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 linux1fb.webonedeveloper ESMTP Postfix
exit
502 5.5.2 Error: command not recognized
quit
221 2.0.0 Bye
Connection closed by foreign host.

> >Should I just run the install over top the current installation?
>
> Is that what you have done previously?

No. I didn't do anything. Pure research so far to see if Linux could
tell me where the IP request was being refused.

>
> > > 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.

Yep.

>
> > > 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.

As a comparison

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

>
> >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.

Yes as root and not using xinetd. Just the lock manager shows up in
the process list.

>
> 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

My bad. Actually I did use the right parameters after I noticed I
forgot the user name and password the first two times :-). Still same
errors.

>
> "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.

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.

What do I need to do on Linux? 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 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.
>

tcpdump is a normal utility part of Linux. The Xen guys suggested I
try it. I have given them the output, but no one has commented on it.

> 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 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 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. 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.

Should there be at least on fb_inet_server running at the beginning as
the Listener? I noticed in the Quick Start page 12 in the "Note" box,
is this only for Windows?

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

> ./heLen
>