Hi,

first of all, thank you for your lengthy explanations. The picture has
cleared up a bit, although I'm still struggling.

Helen Borrie writes:

> That style of connection won't work with Superserver. It's requesting a local connection, which is available ONLY to Classic using the embedded server client libfbembed.so.
>

Ok, I'll leave the super-server aside for later tests, as I can run
only one type of server at a time on Debian.

> Here you are connecting directly to the database *file* via libfbembed.so. The firebird user is not involved here: only root or a user with rw on the file and rwx on the directory will obtain this access.
>

This seems to be a key point of the whole story. Our firebird driver
has so far been linked against libfbclient.so, but isql uses
libfbembed.so (or so ldd says). This is why I keep seeing different
behaviours between the command line tool and our test app. Linking the
database driver of our test app against libfbembed.so changes the
picture entirely. Local connections now work without a hitch, with a
remaining (unrelated) problem on FreeBSD which I'll post separately.

However, this again leaves me wondering. The documentation is not very
explicite about the difference between these libraries (BTW none of
the PDF documents contains the strings "fbclient" or "fbembed"!). I've
found one reference
(http://www.firebirdsql.org/manual/qsg2-disk-locations.html) which
tells me libfbembed is a "local client with embedded engine, Classic
only". isql is linked against this library. However, e.g. OpGuide.pdf
uses isql to access remote databases as well, and it doesn't mention
anywhere that this is going to work only with one of the server
types. So which document is right? And if libfbembed can do both local
and network accesses, why and where would I use libfbclient then? Is
there one library which can access both classic-server and
super-server? As a database-abstraction project, do we have to
maintain separate drivers for local and network access? Or for
classic-server and super-server? Or will one driver, written in a
sufficiently ingenious fashion, meet all needs?

> ..which is correct. If you connect to the database as a network client, your server will be a fb_inet_server process instance created by the [x]inetd daemon. The process runs under the user credentials of the firebird user.
>

[...]

> >ocean:/home/markus# less /etc/inetd.conf |grep firebird
> >gds_db stream tcp nowait firebird /usr/sbin/tcpd /usr/lib/firebird2/bin/fb_inet_server
> >
> >That is, the server should use the firebird account, not root.
>
> As it does - when either the client you use is libfbclient.so, or you use the libfbembed.so client with a network connection (in which case only the client part of the library is active and it connects to an fb_inet_server process).
>

Ok, now lets try isql with a network connection. I still have the same
setup with fb_inet_server running as "firebird" (see above) and the
following directory permissions:

markus@ocean:~$ ls -ald /var/lib/firebird2
drwxrwx--- 6 firebird firebird 4096 2007-12-30 00:13 /var/lib/firebird2
markus@ocean:~$ ls -ald /var/lib/firebird2/data
drwxrwx--- 2 firebird firebird 4096 2007-12-30 13:59 /var/lib/firebird2/data

That is, by all I've learned so far isql should have no problem
connecting to fb_inet_server, which as user "firebird" is allowed to
enter and to alter the directory where it is supposed to create a
database. However:

SQL> create database 'localhost:/var/lib/firebird2/data/libdbitest';
Statement failed, SQLCODE = -902

operating system directive open failed
-Permission denied
SQL> create database 'ocean:/var/lib/firebird2/data/libdbitest';
Statement failed, SQLCODE = -902

operating system directive open failed
-Permission denied

That is, neither using localhost nor the real node name gets me any
further. Interestingly, the same appears to work on FreeBSD. I've got
these permissions:

markus@yeti:~# ls -ald /var/db/firebird
drwxrwxr-x 3 firebird firebird 512 Dec 30 18:20 /var/db/firebird

and the server permissions are set up like this:

markus@yeti:~# grep firebird < /etc/inetd.conf
# enable firebird database engine
gds_db stream tcp nowait firebird /usr/local/bin/fb_inet_server fb_inet_server

The only obvious difference is that I use Firebird 2.0.3 on FreeBSD,
whereas my Debian box runs 1.5.3. However, I'd expect both versions to
work. Or am I again missing something (not so) obvious?

> Yup. Well - it's not VERY obvious if you don't understand the differences between the three server models. So decide which model you want to work with and you should be able to proceed without further frustration.
>

As mentioned previously, your explanations have made this matter
somewhat more transparent to me (thanks for that!). However, as we're
looking at a database abstraction layer, it is not up to me to decide
which server model to use. Our driver(s) must support whatever the
end-users choose to run.

> -- if you install Superserver you can't connect locally at all (other than using the localhost server). The client for SS is libfbclient.so. SS runs under firebird credentials.
>
> -- if you install Classic, you can request fb_inet_server processes via xinetd using a proper network path. Either libfbembed.so or libfbclient.dll can be your client.
>
> -- if libfbembed.so is available, you can run an embedded Classic process that is not an instance of fb_inet_server. This is the only condition where "who you are" on the OS matters.
>

This partially answers my questions about which client library to
use. libfbclient.so appears to be out then?

If I'll now succeed in connecting through the network on Debian, I'd
be a happy camper again. I'll appreciate any hints that will get me
there.

regards,
Markus

--
Markus Hoenicka
markus.hoenicka@...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de