At 05:52 PM 22/01/2007, you wrote:

>if I su to the firebird user, what does that get me? Different errors?

Filesystem errors, anyway, if the firebird user doesn't have read
access there...

>I guess my main problem here is knowing what I should be seeing vs.
>how the system is configured. For instance, looking through some
>permission postings in google, it seems that there should be a
>firebird group. No such group was created during my install. Should
>there be a firebird group?

Yes, it's recommended. Did you read the Installation notes in the
release notes document?

Actually, doing an su to the firebird user probably isn't going to be
ideal as you won't know what its password is. In the past, I've
thought about su-ing to root and changing the firebird password to
something I know about. I've never been that brave! Anyway, I
don't need to know it to add it to a group.

Here's what I do (with variations sometimes using different usernames
but the principle is the same):

as root,

1. groupadd firebird

2. mkdir /data

(at this point, root has exclusive rights over /data, which is now a
root for all databases and related stuff)

3. create a couple of useful subdirs (according to your needs)

mkdir databases
mkdir xfiles

4. if you have root-owned database files hanging around, move them here now:

mv /opt/firebird/strangeplace/employee.fdb /data/databases/employee.fdb

5. Make the firebird group owner of the /data tree:

chown -R :firebird /data

6. Add firebird to the firebird group (still as root):

usermod -G firebird firebird

7. Add yourself to the firebird group (for when you want to run the
command-line utilities, move files around, etc.). I just have an
account called sysdba for this but it can be any name if you prefer.

usermod -G firebird sysdba

I emphasise that there are many ways to do it and this is just what I
do. For example, you might not want to be so radical as to make the
group the owner. You might prefer to make the firebird user the
owner and apply group rwx perms R[ecursively] for the tree to the
firebird group (but not x perms for the files, of course).

Ideally you will restrict things so that databases are never written
or accessed anywhere but in the places you (as admin) want them to
be. So, with the current example, in firebird.conf you would set
DatabaseAccess to RESTRICT /data

The idea of /data/xfiles is to have a place where the firebird group
can read and write external files. You would configure this place in
firebird.conf ExternalFileAccess RESTRICT /data/xfiles

You don't have to call it /data. The server doesn't have any
preconceptions about the name of the tree where it will be told to
look, other than by the firebird.conf settings.

Btw, having databases and data files in the same tree as the software
isn't very cool. What's going to happen when you upgrade the software?

======
A more savvy approach, once you know what you're doing and IF your
Linux distro allows it, is to create the firebird user and group
ahead of installing; and then to install the Firebird package when
logged in as firebird. I don't uSE SuSE so I can't advise you
whether you could have done it like that...

./heLen