Subject | Re: [firebird-support] Re: Classic Server database file ownership |
---|---|
Author | Helen Borrie |
Post date | 2007-04-04T08:02:55Z |
At 04:50 AM 4/04/2007, you wrote:
run things in a user's application, just make sure that you *have*
such a user properly set up. It's not a question of "convenience"
but of appropriate management.
going to do is potter around on your laptop. For each database (or
database group) there should be a dbadmin user whose responsibility
it is to create (and thus own) a database and create (and thus own
and have the right to modify) metadata. If SYSDBA always creates
databases and objects then you need SYSDBA to run backups, assign
privileges, etc.
SYSDBA belongs at the server level. The database owner belongs at
database level. SYSDBA's activity should be restricted to
server-level things, most specifically creating user accounts.
through the service - in this case, the [x]inetd daemon. After all,
isn't that what a network service is for?
But, with Classic, you *can* do local access, running an instance of
libfbembed.so, as long as the logged-in user is a member of the
firebird group. Some web applications or other server-based data
access tiers, for example, written in EmbedSQL, could be designed to
connect locally.
But I emphasise here that this direct, local access is only via
libfbembed.so, which is a merged library comprising the client and an
embedded instance of fb_inet_server. Using libfbclient.so as your
client library, you cannot do the direct-connect thing.
With Superserver, local access simply isn't available.
./heLen
>Helen,It all gets down to how you set up your server. If you *do* want to
>
> Thanks for your good advices. I was running everything as root, and
>that was wrong. But while trying to do the things the right way I have
>the following questions:
>
>1) If the right way to run gbak is using -se option in order to invoke
>the service, which is the usefulness of not using it (i.e. why this is
>an option or when it is convenient to not use it ? )
run things in a user's application, just make sure that you *have*
such a user properly set up. It's not a question of "convenience"
but of appropriate management.
>2) I noticed that you advised me to create databases as an ordinaryYes, if you intend to do real-world stuff. No, if all you are ever
>firebird user instead of using sysdba (gbak -c -user dbadmin ..). Is
>there any harm or risk in making a sysdba owner of a database (gbak -c
>user sydba ... ) ?
going to do is potter around on your laptop. For each database (or
database group) there should be a dbadmin user whose responsibility
it is to create (and thus own) a database and create (and thus own
and have the right to modify) metadata. If SYSDBA always creates
databases and objects then you need SYSDBA to run backups, assign
privileges, etc.
SYSDBA belongs at the server level. The database owner belongs at
database level. SYSDBA's activity should be restricted to
server-level things, most specifically creating user accounts.
>3) The only way I found of running the other tools ( isql-fb, gfix andIt *is* right, as a rule, to insist that all access to databases be
>gsec ) as a non root linux user was appending localhost: before the
>path to the database file or its alias, which indeed serves to invoke
>the loop back connection to the server instead of using a direct
>connection. Is that right ?
through the service - in this case, the [x]inetd daemon. After all,
isn't that what a network service is for?
But, with Classic, you *can* do local access, running an instance of
libfbembed.so, as long as the logged-in user is a member of the
firebird group. Some web applications or other server-based data
access tiers, for example, written in EmbedSQL, could be designed to
connect locally.
But I emphasise here that this direct, local access is only via
libfbembed.so, which is a merged library comprising the client and an
embedded instance of fb_inet_server. Using libfbclient.so as your
client library, you cannot do the direct-connect thing.
With Superserver, local access simply isn't available.
./heLen