Subject Re: [firebird-support] Firebird in readonly root environment
Author Helen Borrie
At 11:57 1/10/2008, you wrote:
>I am attempting to get Firebird 2.0.3.12981-1 running on a linux from
>scratch setup with a readonly root filesystem.
>I have set s symbolic link for security2.fdb to a writeable mount
>(/var/firebird) and also set the environment variable FIREBIRD_LOCK to
>/var/firebird.
>This enables firebird to run fine as long as I only try to connect to
>local databases - if I try to connect to a remote database (even using
>localhost) then firebird complains that it cannot attach to the
>security database - it seems that firebird always creates the
>isc_lock/init files in the firebird root folder if the attempted
>connection is to a remote database and ignores the FIREBIRD_LOCK variable.
>
>Is this the correct behaviour ?
>
>If so then is there a recommended way to set up firebird to run in a
>readonly root environment ?

None that I have ever heard of. As a database server, firebird has to be able to write to disk.

Lock files aren't the only things a working Firebird server has to write to disk. The firebird.log is written to Firebird's root dir. Sort files have to go to disk if they are too large to fit in available RAM and temp space must be configured for this if you don't have a local /temp or /tmp space defined.

>Any advice welcome ...

Well, here's a smorgasbord of related information. It's really not clear from your description exactly what you're doing here - this probably has much to do with terminology...your notions of read-only-ness and the mechanics of database access appear a bit confused.

-- A Firebird server cannot access remote databases at all. The one exception is that, on some POSIX systems, Linux included, a Firebird server can access a read-only database on a NFS mount. A read-only database is not the same thing as a read-only file or a read-write database on a read-only filesystem.

-- A database FILE can be on a read-only device, as long as the *database* is read-only - that is a MODE attribute of the *database*, set in the database header using gfix -m; not the file or other device that houses it.

-- A user (with the appropriate SQL privileges, of course) can access database objects in a read-only transaction.

-- A Firebird server expects the security database to be in its root. It's interesting, in an academic kind of way, that it is able to find it at some point via a symlink. I'd regard this as pretty experimental. ;-)

-- You haven't said whether you are working with Firebird Classic or Superserver. If it's Classic then it's pretty likely you have been doing at least some of your local access using libfbembed.so, which is a self-contained client-and-server module that opens the database *file* directly and with exclusive access.

-- The remote client is libfbclient.so. It is the only client you can use to access a database locally on a Superserver installation (via localhost, hostname or IP address, not a "hostless" path). A remote Linux client needs libfbclient.so to access databases on either Classic or Superserver.

-- The Firebird server does not use the client layers: applications do. So, while a client instance could access databases on multiple servers simultaneously, a server instance can access only databases on devices that are physically attached to the same host machine (the NFS case excepted).

./heLen