[Firebird-devel] Configuring Firebird to run multiple services under windows

[Paul Reeves]

Fb 2.1 will allow users to run multiple instances of Firebird as Windows
Services. This is a much needed improvement, but the feature needs some
more work. I'd like to get some feedback on what we need to do, and work
out when to implement it. (Because it may well be that we don't have
time to do it all for 2.1)


1/ 'instsvc install -name servicename' does not leave any trace of the
name used, other than in the registry for services. This means that
when we run 'instsvc query' it only returns the status of the default
instance.

If we know the service name we can query it. But we have no mechanism
to list the installed service names.


2/ Running a service under a user defined name more or less requires a
full installation of Firebird. We could probably specify a minimum
install, but instsvc takes its current directory as the instance
directory and the server looks for its config file in the root above.

I don't think we need to do anything about this for 2.1, but it would
be useful if we could configure multiple instances from a single
install. Each instance would require its own firebird root dir for
the conf files, message file, lock file and log file and any
required libraries.


3/ We have no mechanism to list all the installed instances. instreg is
not connected to instsvc. I'm not sure that it needs to be, but from
the POV of the installer it would be useful to get a list of
installed instances. Part of the problem here is that when multiple
services are configured they each run on a separate port. But we
don't know what those ports are, or which version are behind them.

Do we need to know? Can we complete 2.1 without knowing?


4/ The ControlPanel applet needs a major overhaul. Users need to see
- all installed instances
- configuration values such as port number
- ideally should allow adding/deleting installed service instances

The cpl applet should be using the instsvc/instreg api where
possible.


5/ If the %FIREBIRD% variable is set it confuses the non-default
installed services. Although I need to double-check whether placing
%FIREBIRD%\bin on the path is partly responsible. Either way, it
seems that multiple service instances don't appear to run reliably if
there is a FIREBIRD variable set.

I particularly noticed problems when mixing 32-bit and 64-bit
installs. The dll loading gets muddled.

I think a solution to this would be for the server to look for a
%FIREBIRD_servicename% variable, replacing servicename with the
parameter passed to the -s switch.

An alternative might be to _not_ look for a FIREBIRD variable if
the -s parameter is used.



Paul

[Alex Peshkov]

Post by Paul Reeves
1/ 'instsvc install -name servicename' does not leave any trace of the
name used, other than in the registry for services. This means that
when we run 'instsvc query' it only returns the status of the default
instance.

Would not it be reasonable to return all instances status? Can you distinguish
between firebird server instances and other services?

Post by Paul Reeves
If we know the service name we can query it. But we have no mechanism
to list the installed service names.

It seems standard windows tools let user list all services in very many ways?
Am I wrong?

Post by Paul Reeves
2/ Running a service under a user defined name more or less requires a
full installation of Firebird. We could probably specify a minimum
install, but instsvc takes its current directory as the instance
directory and the server looks for its config file in the root above.
I don't think we need to do anything about this for 2.1,

Yes.

Post by Paul Reeves
but it would
be useful if we could configure multiple instances from a single

// skipped

Post by Paul Reeves
4/ The ControlPanel applet needs a major overhaul. Users need to see
- all installed instances
- configuration values such as port number
- ideally should allow adding/deleting installed service instances
The cpl applet should be using the instsvc/instreg api where
possible.

We have disabled calls to list/modify configuration parameters in services API
after global review of config stuff in 1.5. May be it's time to re-enable at
least listing of them for SYSDBA only? Taken together with trusted
authentication this looks like a secure way to make applet do it's work well.

Post by Paul Reeves
5/ If the %FIREBIRD% variable is set it confuses the non-default
installed services. Although I need to double-check whether placing
%FIREBIRD%\bin on the path is partly responsible. Either way, it
seems that multiple service instances don't appear to run reliably if
there is a FIREBIRD variable set.
I particularly noticed problems when mixing 32-bit and 64-bit
installs. The dll loading gets muddled.
I think a solution to this would be for the server to look for a
%FIREBIRD_servicename% variable, replacing servicename with the
parameter passed to the -s switch.
An alternative might be to _not_ look for a FIREBIRD variable if
the -s parameter is used.

In linux setting environment for each service instance to different value is a
standard way to have multiple service instances. It will be not good, I
think, to have difefrent behaviour for different OS's concerning environment,
but if there is no other solution, I'd prefer ignoring FIREBIRD when -s is
used.

And related question - if we are going to have multi-instancing for windows,
looks like we should have them on posix platforms too. And here I would much
like to add/delete instances not from install, but with separate tool in
firebird's bin directory. First, silent rpm setup does not let us ask
questions to user - it just runs. Next, it will be better from logical POV
too - firebird is installed, now we add/delete instances. And I want to
know - is it hard to use same approach in windows?

[Dmitry Yemanov]

Post by Alex Peshkov
We have disabled calls to list/modify configuration parameters in services API
after global review of config stuff in 1.5. May be it's time to re-enable at
least listing of them for SYSDBA only?

1) The configuration classes are missing the in-place parameter
modification code.
2) The entire mechanism is about to change in v3

So I'd hate to introduce something new at this stage.

Post by Alex Peshkov
And related question - if we are going to have multi-instancing for windows,

See my other post -- this is not really a multi-instancing feature. So I
don't see an immediate need in the extra setup/configuration stuff.

Also, when we'll extend this feature to make it exactly what it sounds
like, many changes to the setup tools would be required and they could
conflict with the current "quick" solution.


Dmitry

[Alex Peshkov]

Post by Dmitry Yemanov

Post by Alex Peshkov
We have disabled calls to list/modify configuration parameters in
services API after global review of config stuff in 1.5. May be it's time
to re-enable at least listing of them for SYSDBA only?

1) The configuration classes are missing the in-place parameter
modification code.

I've talked about viewing, not changing.

Post by Dmitry Yemanov
2) The entire mechanism is about to change in v3
So I'd hate to introduce something new at this stage.

Post by Alex Peshkov
And related question - if we are going to have multi-instancing for windows,

See my other post -- this is not really a multi-instancing feature. So I
don't see an immediate need in the extra setup/configuration stuff.

Already seen.

Post by Dmitry Yemanov
Also, when we'll extend this feature to make it exactly what it sounds
like, many changes to the setup tools would be required and they could
conflict with the current "quick" solution.

OK, we leave it in peace for a while.

[Olivier Mascia]

Post by Alex Peshkov
And here I would much
like to add/delete instances not from install, but with separate tool in
firebird's bin directory. First, silent rpm setup does not let us ask
questions to user - it just runs. Next, it will be better from
logical POV
too - firebird is installed, now we add/delete instances. And I want to
know - is it hard to use same approach in windows?

This sounds like a nice way to go for people wanting to run an
installer and then configure multiple instances all running from a
single set of binaries. Much cleaner than having the setup program
deal with that. Think of a hosting business: they install *one*
distribution on a server using the setup program, then runs an
instance configuration program (either interactively or through
scripts or whatever) when time comes to initialize new instances for
different customers hosted on that same hardware. If they ever
decide to install an update, that will update all instances, as they
are just 'configurations' running out of a same set of binaries.

But there are also the needs of different kind of users. An
independent software vendor might want to make sure they
automatically install a known set of FB binaries and create services
using that to run their own instances. I do exactly so today with
2.0 and did it the same with 1.5 before. This is on Windows (2000/
XP/...) The application setup do ship and install a set of firebird
binaries in some directory of the application itself. It then
configures a service to run that FB binary. The service configured
is NOT the one the default FB installer would configure, it differs
in name, details, and so on. And that FB 'private' instance is pre-
configured to run on a unique non standard tcp/ip port and xnet IPC
names. It is not perfect but close to.

Now if I can give you my vision of all this, Firebird is lacking a
generic mean to pass all and any parameters on the command-line,
either directly or with a reference to a configuration file and have
FB strictly obey to that and to NO implicit location of any sort.

To make myself clear and forgetting any and all existing command-line
parameters, the current config file is based on the concept
var=value, let's introduce this at the command-line level:

fbserver +RemoteServiceName=my_fb +RemoteServicePort=31600
+TcpRemoteBufferSize=16384 +IpcName=Global\MY-FIREBIRD
+CreateInternalWindow=0

fbserver +/my/fb/firebird.conf

fbserver +/my/fb/special.conf +TcpRemoteBufferSize=16384 +/my/fb/
yetsomesettings.conf

Proposed order of evaluation:

1) first the "firebird.conf" file if there is a FIREBIRD variable in
the environment and such a file is found at that location,

2) values and files in the order they are given on the command-line

3) when a same setting is defined multiple times though this scheme,
the last one wins

I would also add a '-noenv' option to specifically request to ignore
the FIREBIRD environment variable.

It is only a rough idea, but it would give total flexibility and
allows to design any kind of multi-instancing tools on top of it, on
all platforms.

[Alex Peshkov]

Post by Olivier Mascia
To make myself clear and forgetting any and all existing command-line
parameters, the current config file is based on the concept
fbserver +RemoteServiceName=my_fb +RemoteServicePort=31600
+TcpRemoteBufferSize=16384 +IpcName=Global\MY-FIREBIRD
+CreateInternalWindow=0

Posix build of firebird always had a switch (-e) to set it's home directory. It was partially broken when adding fb1.5 config stuff, but now I've fixed - hope not added new bugs in it:) Adding such switch to windows seems not to be a problem.

Setting correct home directory is very important for firebird operation, cause here it keeps various lock files, and the fact that only one firebird instance works with same set of lock files at a time is absolutely required for it's successful operation. I repeat this well known fact here to emphasize that starting more then one instance from same working directory is a bug. (There is a switch to set path to lock files separately from home, but this is not a full-featured solution and requires more modifications in firebird be useful, cause code, working with security database ignores that switch, and opening database from more then one instance of firebird breaks it at once - and this is just the first sample which came to my mind.)

Therefore currently we should better follow the rule of thumb - separate home for each instance. But with that fact taken into an account, it becomes clear that adding any more switches to command line is senseless and is just duplication - separate home directory contains separate config file.

In the future it makes sense to have switches to set working directory (with security database, lock files, may be specific UDFs) and home directory (with bin, lib, standard UDFs, etc) separately. But this is anyway not a reason to duplicate config file parameters in command line - surely vulcan-style config will be used in that version, which let's us have multiple config files, and entries, specified in working directory, will override values from home directory.

[Vlad Horsun]

Post by Alex Peshkov
Setting correct home directory is very important for firebird operation, cause here it keeps
various lock files, and the fact that only one firebird instance works with same set of lock
files at a time is absolutely required for it's successful operation. I repeat this well known
fact here to emphasize that starting more then one instance from same working directory
is a bug.

Why ? It is dangerous to access same database by different engine instances using different
lock tables, yes. But we already discussed in fb-architect and agreed that we will add some
number (or uuid) at lock table header and database header to avoid such conflicts.

Post by Alex Peshkov
(There is a switch to set path to lock files separately from home, but this is not a full-featured
solution and requires more modifications in firebird be useful, cause code, working with security
database ignores that switch, and opening database from more then one instance of firebird
breaks it at once - and this is just the first sample which came to my mind.)

I don't think we need such switch. Lock table file can be created as now plus instance name.
I not sure we must create distinct lock table for every distinct engine instance. And i not sure we can
identify embedded instances used shared file (in vulcan's terminology). Note - all instances used same
lock table format can be served by only lock table. Ideally we may create shared memory regions not
mapped to physical file thus we avoid need to setup path for lock table file. Just name this regions,
say, 'FirebirdLockTable_' + <lock table format version number> (here we must also solve problem
with access from different Windows sessions for applications without SeCreateGlobalPrivilege, but i
leave it for now)

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb - separate home for each instance.

Why ? Why i need to copy full installation just to run new instance ? Or i wrong understand what
you said ? ;)

Post by Alex Peshkov
But with that fact taken into an account, it becomes clear that adding any more switches to
command line is senseless and is just duplication - separate home directory contains separate
config file.

Set config file name via cmdline switch is enough i think

Post by Alex Peshkov
In the future it makes sense to have switches to set working directory (with security database,
lock files, may be specific UDFs) and home directory (with bin, lib, standard UDFs, etc) separately.

Why we ever need working directory if we know config file name ? And when home directory will
differ from directory with running binary ?

Post by Alex Peshkov
But this is anyway not a reason to duplicate config file parameters in command line

Agreed

Regards,
Vlad

[Alex Peshkov]

Post by Vlad Horsun

Post by Alex Peshkov
Setting correct home directory is very important for firebird operation,
cause here it keeps various lock files, and the fact that only one
firebird instance works with same set of lock files at a time is
absolutely required for it's successful operation. I repeat this well
known fact here to emphasize that starting more then one instance from
same working directory is a bug.

Why ? It is dangerous to access same database by different engine
instances using different lock tables, yes. But we already discussed in
fb-architect and agreed that we will add some number (or uuid) at lock
table header and database header to avoid such conflicts.

First, it's not done yet. Next, this will lead to inability for all instances
except one started in this manner to access security database. Do we really
need it? :)

Post by Vlad Horsun

Post by Alex Peshkov
(There is a switch to set path to lock files separately from home, but
this is not a full-featured solution and requires more modifications in
firebird be useful, cause code, working with security database ignores
that switch, and opening database from more then one instance of firebird
breaks it at once - and this is just the first sample which came to my mind.)

I don't think we need such switch. Lock table file can be created as
now plus instance name. I not sure we must create distinct lock table for
every distinct engine instance. And i not sure we can identify embedded
instances used shared file (in vulcan's terminology). Note - all instances
used same lock table format can be served by only lock table.

Vlad, you suggest to partially mix resources used by different instances. This
may work, but agree - will require some more changes in engine.

What about embedded instance - to make it work correctly we must do in it that
same call that is made by server when it detects appropriate switch (before
any calls to config manager).

Post by Vlad Horsun
Ideally we
may create shared memory regions not mapped to physical file thus we avoid
need to setup path for lock table file. Just name this regions, say,
'FirebirdLockTable_' + <lock table format version number> (here we must
also solve problem with access from different Windows sessions for
applications without SeCreateGlobalPrivilege, but i leave it for now)

Are you sure other OS's also support such regions?

Post by Vlad Horsun

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb - separate
home for each instance.

Why ? Why i need to copy full installation just to run new instance ?
Or i wrong understand what you said ? ;)

To avoid it I suggest to have separate home and working directories later.

BTW, there is no need to copy full installation - it's enough to create root
and link bin, lib and other required directories's content to it. This does
not work only with windows on fat32, but if someone uses THAT filesystem on a
server, planned for multiple firebird instances, I have no more comments :)

Post by Vlad Horsun

Post by Alex Peshkov
But with that fact taken into an account, it becomes clear that adding
any more switches to command line is senseless and is just duplication -
separate home directory contains separate config file.

Set config file name via cmdline switch is enough i think

Post by Alex Peshkov
In the future it makes sense to have switches to set working directory
(with security database, lock files, may be specific UDFs) and home
directory (with bin, lib, standard UDFs, etc) separately.

Why we ever need working directory if we know config file name ?

I suppose the main thing we should decide - have switch to set working
directory or to set config file. I think that setting working directory
containing config file, security database and lock files using single switch
is easier to implement and more general in use. I agree that we may have
different names for different lock-files, different names for different
security databases - but may be different working directories is a bit easier
way to go?

Post by Vlad Horsun
And
when home directory will differ from directory with running binary ?

When it's set using command line switch:) Actually there is no big need in
changing directory, where binaries are located - let them stay where
installed. Changing working directory is what really needed to have many
instances with single installation.

[Mercea Paul]

Post by Alex Peshkov
When it's set using command line switch:) Actually there is no big need in
changing directory, where binaries are located - let them stay where
installed. Changing working directory is what really needed to have many
instances with single installation.

How about multiple instances and multiple versions of FB (FB2.1, 3.0,
etc)???How can be managed?

[Alex Peshkov]

Post by Mercea Paul
How about multiple instances and multiple versions of FB (FB2.1, 3.0,
etc)???How can be managed?

Certainly, they are to be installed separately. And this will require changes
in installation program.

[Vlad Horsun]

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Setting correct home directory is very important for firebird operation,
cause here it keeps various lock files, and the fact that only one
firebird instance works with same set of lock files at a time is
absolutely required for it's successful operation. I repeat this well
known fact here to emphasize that starting more then one instance from
same working directory is a bug.

Why ? It is dangerous to access same database by different engine
instances using different lock tables, yes. But we already discussed in
fb-architect and agreed that we will add some number (or uuid) at lock
table header and database header to avoid such conflicts.

First, it's not done yet.

And i not propose to implement it before FB3 ;)

Post by Alex Peshkov
Next, this will lead to inability for all instances
except one started in this manner to access security database. Do we really
need it? :)

Why ? All instances will be able access any database simultaneously while
they understand common lock table format.

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
(There is a switch to set path to lock files separately from home, but
this is not a full-featured solution and requires more modifications in
firebird be useful, cause code, working with security database ignores
that switch, and opening database from more then one instance of firebird
breaks it at once - and this is just the first sample which came to my mind.)

I don't think we need such switch. Lock table file can be created as
now plus instance name. I not sure we must create distinct lock table for
every distinct engine instance. And i not sure we can identify embedded
instances used shared file (in vulcan's terminology). Note - all instances
used same lock table format can be served by only lock table.

Vlad, you suggest to partially mix resources used by different instances. This
may work, but agree - will require some more changes in engine.

This is key question - do we need to isolate resources between instances ?
We need to enumerate all such resources and carefully analyze them on this subject.
For now i not see why we need it. But i can be wrong of course.

Post by Alex Peshkov
What about embedded instance - to make it work correctly we must do in it that
same call that is made by server when it detects appropriate switch (before
any calls to config manager).

Post by Vlad Horsun
Ideally we
may create shared memory regions not mapped to physical file thus we avoid
need to setup path for lock table file. Just name this regions, say,
'FirebirdLockTable_' + <lock table format version number> (here we must
also solve problem with access from different Windows sessions for
applications without SeCreateGlobalPrivilege, but i leave it for now)

Are you sure other OS's also support such regions?

Some time ago someone told about it here, IIRC.

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb - separate
home for each instance.

Why ? Why i need to copy full installation just to run new instance ?
Or i wrong understand what you said ? ;)

To avoid it I suggest to have separate home and working directories later.

What is exact meaning of 'home', 'work' and 'root' directories ? Perhaps we
assign different meaning to thus words :)

Post by Alex Peshkov
BTW, there is no need to copy full installation - it's enough to create root
and link bin, lib and other required directories's content to it. This does
not work only with windows on fat32, but if someone uses THAT filesystem on a
server, planned for multiple firebird instances, I have no more comments :)

Nobody will do it on Windows, i think.

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
But with that fact taken into an account, it becomes clear that adding
any more switches to command line is senseless and is just duplication -
separate home directory contains separate config file.

Set config file name via cmdline switch is enough i think

Post by Alex Peshkov
In the future it makes sense to have switches to set working directory
(with security database, lock files, may be specific UDFs) and home
directory (with bin, lib, standard UDFs, etc) separately.

Why we ever need working directory if we know config file name ?

I suppose the main thing we should decide - have switch to set working
directory or to set config file. I think that setting working directory
containing config file, security database and lock files using single switch
is easier to implement and more general in use. I agree that we may have
different names for different lock-files, different names for different
security databases - but may be different working directories is a bit easier
way to go?

Post by Vlad Horsun
And
when home directory will differ from directory with running binary ?

When it's set using command line switch:) Actually there is no big need in
changing directory, where binaries are located - let them stay where
installed. Changing working directory is what really needed to have many
instances with single installation.

I meant - why we need to know special directories except (already known)
where our binaries reside ?

Regards,
Vlad

[Alex Peshkov]

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
(There is a switch to set path to lock files separately from home,
but this is not a full-featured solution and requires more
modifications in firebird be useful, cause code, working with
security database ignores that switch, and opening database from more
then one instance of firebird breaks it at once - and this is just
the first sample which came to my mind.)

I don't think we need such switch. Lock table file can be created
as now plus instance name. I not sure we must create distinct lock
table for every distinct engine instance. And i not sure we can
identify embedded instances used shared file (in vulcan's terminology).
Note - all instances used same lock table format can be served by only
lock table.

Vlad, you suggest to partially mix resources used by different instances.
This may work, but agree - will require some more changes in engine.

This is key question - do we need to isolate resources between
instances ? We need to enumerate all such resources and carefully analyze
them on this subject. For now i not see why we need it. But i can be wrong
of course.

Do you really suggest to have same security database for all instances? With
same list of users (and passwords)? Including sysdba?
I know it's possible to add instance name to RDB$USERS, but maintaining
instances will mean changing security database. Not good for me.

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
Ideally we
may create shared memory regions not mapped to physical file thus we
avoid need to setup path for lock table file. Just name this regions,
say, 'FirebirdLockTable_' + <lock table format version number> (here we
must also solve problem with access from different Windows sessions for
applications without SeCreateGlobalPrivilege, but i leave it for now)

Are you sure other OS's also support such regions?

Some time ago someone told about it here, IIRC.

mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)
Name of region is name of file. No problems creating anonymous mapping (in
that case fd is ignored), but it makes no sense for embedded access.

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb -
separate home for each instance.

Why ? Why i need to copy full installation just to run new instance
? Or i wrong understand what you said ? ;)

To avoid it I suggest to have separate home and working directories later.

What is exact meaning of 'home', 'work' and 'root' directories ?
Perhaps we assign different meaning to thus words :)

I've tried to explain a few roundtrips before. May be names are far from
ideal:)
Home directory - where shared components of server (bin, intl, lib, common
UDFs, firebird.msg, common config file for vulcan style config) are stored.
It may (or may not) also be a working directory for default instance, it is
such after default install to keep compatibility.
Working directory - where private components of the instance are stored. That
are personal config file, mapped (locks, events) files, firebird.log, private
intl and UDF if needed.

Post by Vlad Horsun

Post by Alex Peshkov
BTW, there is no need to copy full installation - it's enough to create
root and link bin, lib and other required directories's content to it.
This does not work only with windows on fat32, but if someone uses THAT
filesystem on a server, planned for multiple firebird instances, I have
no more comments :)

Nobody will do it on Windows, i think.

Will not do what - link files or use fat32?

Post by Vlad Horsun
I meant - why we need to know special directories except (already
known) where our binaries reside ?

To know where to look for mentioned above objects, used by firebird.
I still can't understand why do you dislike very simple approach - instance is
private working directory.

[Vlad Horsun]

Post by Alex Peshkov

Post by Vlad Horsun
This is key question - do we need to isolate resources between
instances ? We need to enumerate all such resources and carefully analyze
them on this subject. For now i not see why we need it. But i can be wrong
of course.

Do you really suggest to have same security database for all instances? With
same list of users (and passwords)? Including sysdba?
I know it's possible to add instance name to RDB$USERS, but maintaining
instances will mean changing security database. Not good for me.

It is defined in vulcan's config file for every database. Why some instances can't
share same security database if it needed ? I'd say that security mechanism more
related to database than to the engine instance...

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
Ideally we
may create shared memory regions not mapped to physical file thus we
avoid need to setup path for lock table file. Just name this regions,
say, 'FirebirdLockTable_' + <lock table format version number> (here we
must also solve problem with access from different Windows sessions for
applications without SeCreateGlobalPrivilege, but i leave it for now)

Are you sure other OS's also support such regions?

Some time ago someone told about it here, IIRC.

mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)
Name of region is name of file. No problems creating anonymous mapping (in
that case fd is ignored), but it makes no sense for embedded access.

Are posix have some special name space for 'files' which is not mapped to
real disk files ?

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb -
separate home for each instance.

Why ? Why i need to copy full installation just to run new instance
? Or i wrong understand what you said ? ;)

To avoid it I suggest to have separate home and working directories later.

What is exact meaning of 'home', 'work' and 'root' directories ?
Perhaps we assign different meaning to thus words :)

I've tried to explain a few roundtrips before. May be names are far from
ideal:)

Or i missed it in your messages ;)

Post by Alex Peshkov
Home directory - where shared components of server (bin, intl, lib, common
UDFs, firebird.msg, common config file for vulcan style config) are stored.

Ok. We also may name it install directory, right ?

Post by Alex Peshkov
It may (or may not) also be a working directory for default instance, it is
such after default install to keep compatibility.
Working directory - where private components of the instance are stored. That
are personal config file, mapped (locks, events) files, firebird.log, private
intl and UDF if needed.

All this stuff may reside in one home directory. Just create different config
files and let engine instance know what config file it must use. Set all private
stuff in this config file. Note - instance config file may reside anywhere on file
system.

Each installation (read - each FB version) must create its own home\install
directory. Every instance easily determine its home directory without environment
variables, command line switches etc

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
BTW, there is no need to copy full installation - it's enough to create
root and link bin, lib and other required directories's content to it.
This does not work only with windows on fat32, but if someone uses THAT
filesystem on a server, planned for multiple firebird instances, I have
no more comments :)

Nobody will do it on Windows, i think.

Will not do what - link files or use fat32?

Link files

Post by Alex Peshkov

Post by Vlad Horsun
I meant - why we need to know special directories except (already
known) where our binaries reside ?

To know where to look for mentioned above objects, used by firebird.

It can be set via config file. If config file name is not set (via cmdline or another
way) - current process is default instance.

To make installers happy we can create new file with list of instances in
format : instance_name = config_file. This file will reside in home directory
and have fixed known name. This approach allows to pass not config file path
to the engine instance but just instance name.

Post by Alex Peshkov
I still can't understand why do you dislike very simple approach - instance is
private working directory.

Because i still see no reason to have it mandatory ;)

Regards,
Vlad

[Alex Peshkov]

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
This is key question - do we need to isolate resources between
instances ? We need to enumerate all such resources and carefully
analyze them on this subject. For now i not see why we need it. But i
can be wrong of course.

Do you really suggest to have same security database for all instances?
With same list of users (and passwords)? Including sysdba?
I know it's possible to add instance name to RDB$USERS, but maintaining
instances will mean changing security database. Not good for me.

It is defined in vulcan's config file for every database. Why some
instances can't share same security database if it needed ? I'd say that
security mechanism more related to database than to the engine instance...

Vlad, can you tell - if they share same security database, same locking table,
same log file (i.e. all except config file and IP port), what's a reason for
them to be instances?

Post by Vlad Horsun
Are posix have some special name space for 'files' which is not mapped
to real disk files ?

Not familiar with this feature.

Post by Vlad Horsun

Post by Alex Peshkov
Home directory - where shared components of server (bin, intl, lib,
common UDFs, firebird.msg, common config file for vulcan style config)
are stored.

Ok. We also may name it install directory, right ?

Yes, even better!

Post by Vlad Horsun
Each installation (read - each FB version) must create its own
home\install directory. Every instance easily determine its home directory
without environment variables, command line switches etc

Agreed.

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
BTW, there is no need to copy full installation - it's enough to
create root and link bin, lib and other required directories's
content to it. This does not work only with windows on fat32, but if
someone uses THAT filesystem on a server, planned for multiple
firebird instances, I have no more comments :)

Nobody will do it on Windows, i think.

Will not do what - link files or use fat32?

Link files

Why not? On NTFS it works fine. Often used it myself when worked with windows.
If windows explorer does not support some feature, it does not mean feature
does not work, useless or bad :-))

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
I meant - why we need to know special directories except (already
known) where our binaries reside ?

To know where to look for mentioned above objects, used by firebird.

It can be set via config file. If config file name is not set (via
cmdline or another way) - current process is default instance.

What simpler - to add multiple parameters to config file (security DB, lock
files, log) or add sligthly other form of switch to command line?

Post by Vlad Horsun
To make installers happy we can create new file with list of instances
in format : instance_name = config_file.

Or instance_name = working_directory :)

Post by Vlad Horsun
This file will reside in home
directory and have fixed known name. This approach allows to pass not
config file path to the engine instance but just instance name.

Post by Alex Peshkov
I still can't understand why do you dislike very simple approach -
instance is private working directory.

Because i still see no reason to have it mandatory ;)

Well, let's begin from the beginning - what's the reason to have multiple
instances of same version of firebird? I see only one - separate processes,
serving different databases and different groups of users as much as possible
(internet provider mode). Certainly, this also applies to cases when we want
to continue serving N-1 of N databases, even if 1 of N lead to serious
failure in engine. I say that having common lock table, security database,
etc. per different instances does not satisfy that requirements.

[Vlad Horsun]

Post by Alex Peshkov
Vlad, can you tell - if they share same security database, same locking table,
same log file (i.e. all except config file and IP port), what's a reason for
them to be instances?

To utilize full computer resources or dedicate some of them to some engine instance.
You can create instance1 and bind it to cpu1 and let it serve 1 database and create
instance2 and bind it to cpu2 and let it serve 10 databases.

Post by Alex Peshkov

Post by Vlad Horsun
Are posix have some special name space for 'files' which is not mapped
to real disk files ?

Not familiar with this feature.

Me too ;) It was just a guess

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Home directory - where shared components of server (bin, intl, lib,
common UDFs, firebird.msg, common config file for vulcan style config)
are stored.

Ok. We also may name it install directory, right ?

Yes, even better!

Post by Vlad Horsun
Each installation (read - each FB version) must create its own
home\install directory. Every instance easily determine its home directory
without environment variables, command line switches etc

Agreed.

Ok

...

Post by Alex Peshkov
Why not? On NTFS it works fine. Often used it myself when worked with windows.
If windows explorer does not support some feature, it does not mean feature
does not work, useless or bad :-))

I know zero 'windows' peoples who aware of this feature. May be its my bad luck ;)

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
I meant - why we need to know special directories except (already
known) where our binaries reside ?

To know where to look for mentioned above objects, used by firebird.

It can be set via config file. If config file name is not set (via
cmdline or another way) - current process is default instance.

What simpler - to add multiple parameters to config file (security DB, lock
files, log) or add sligthly other form of switch to command line?

I prefer to edit config file. And i see no reason to set lock table and log file
name manually. It can be easy constructed from install dir + instance name

Post by Alex Peshkov

Post by Vlad Horsun
To make installers happy we can create new file with list of instances
in format : instance_name = config_file.

Or instance_name = working_directory :)

Well known file with list of instances allow installer to enumerate instances
and to add\delete them

Post by Alex Peshkov

Post by Vlad Horsun
This file will reside in home
directory and have fixed known name. This approach allows to pass not
config file path to the engine instance but just instance name.

Post by Alex Peshkov
I still can't understand why do you dislike very simple approach -
instance is private working directory.

Because i still see no reason to have it mandatory ;)

Well, let's begin from the beginning - what's the reason to have multiple
instances of same version of firebird?

I want to know it too ;)

Post by Alex Peshkov
I see only one - separate processes,

yes

Post by Alex Peshkov
serving different databases

yes

Post by Alex Peshkov
and different groups of users as much as possible
(internet provider mode).

not necessary

Post by Alex Peshkov
Certainly, this also applies to cases when we want
to continue serving N-1 of N databases, even if 1 of N lead to serious
failure in engine. I say that having common lock table, security database,
etc. per different instances does not satisfy that requirements.

My approach not force different instances to use different resources.
Your does. We must identify list of resources which can't be shared between
instances (TCP\IP port number for example) and look at it to go further, imho

Regards,
Vlad

[Alex Peshkov]

Post by Vlad Horsun

Post by Alex Peshkov
Vlad, can you tell - if they share same security database, same locking
table, same log file (i.e. all except config file and IP port), what's a
reason for them to be instances?

To utilize full computer resources or dedicate some of them to some
engine instance. You can create instance1 and bind it to cpu1 and let it
serve 1 database and create instance2 and bind it to cpu2 and let it serve
10 databases.

The sample with full resources utilization is realistic for fb 2.x, but
artificial for fb3 with SMP support.
What about better serving dedicated database, it's much better to add
parameter in configuration file, making it possible to increase priority of
thread(s), serving that database.

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun
I meant - why we need to know special directories except
(already known) where our binaries reside ?

To know where to look for mentioned above objects, used by firebird.

It can be set via config file. If config file name is not set (via
cmdline or another way) - current process is default instance.

What simpler - to add multiple parameters to config file (security DB,
lock files, log) or add sligthly other form of switch to command line?

I prefer to edit config file.

Switch to select that file will be needed anyway.

Post by Vlad Horsun

Post by Alex Peshkov
Well, let's begin from the beginning - what's the reason to have multiple
instances of same version of firebird?

I want to know it too ;)

Post by Alex Peshkov
Certainly, this also applies to cases when we want
to continue serving N-1 of N databases, even if 1 of N lead to serious
failure in engine. I say that having common lock table, security
database, etc. per different instances does not satisfy that
requirements.

My approach not force different instances to use different resources.
Your does. We must identify list of resources which can't be shared between
instances (TCP\IP port number for example) and look at it to go further, imho

BTW, instances of MS SQL server share TCP port, if I'm not missing something.

I'm completely agree with you that suggested by you approach is more generic
(though do not see a reason to use that generic capabilities). What I suggest
has only one superiority - it requires very small changes in source code and
has minimum risk of destabilizing engine (on contrary with learning instances
to share common lock/event files), that may be easily implemented in merge
version 3.0.

Or may be I misunderstood you? I've seen suggestion to construct lock file
name / security DB name from instance name. In that case, they certainly may
stay in install directory. This is just question of personal preferences. I
prefer to see the following listing of install directory:

UDF/
aliases.conf
bin/
firebird.conf
firebird.log
firebird.msg
help/
include/
inst1/ \
inst2/ +-- This three are instances
inst3/ /
intl/
isc_event1.fbs
isc_guard1.fbs
isc_init1.fbs
isc_lock1.fbs
lib/
security2.fdb

Rather than:

UDF/
aliases.conf
bin/
firebird.conf
firebird.log
firebird.msg
help/
include/
inst1.UDF/
inst1.conf
inst1.log
inst1_event1.fbs
inst1_guard1.fbs
inst1_init1.fbs
inst1_lock1.fbs
inst1_security2.fdb
inst2.UDF/
inst2.conf
inst2.log
inst2_event1.fbs
inst2_guard1.fbs
inst2_init1.fbs
inst2_lock1.fbs
inst2_security2.fdb
inst3.UDF/
inst3.conf
inst3.log
inst3_event1.fbs
inst3_guard1.fbs
inst3_init1.fbs
inst3_lock1.fbs
inst3_security2.fdb
intl/
isc_event1.fbs
isc_guard1.fbs
isc_init1.fbs
isc_lock1.fbs
lib/
security2.fdb

Imagine we have 100 instances, not 3. But this is certainly a question of
personal taste.

What about list of shareable resources - in theory they may share everything
(we may even add instance name to attachment string and share same TCP port).
The questions for me are (a) how useful is to be able to share that resource
and (b) what ressources do we need to implement that sharing? With that taken
into account I see the following list of shared resources in FB3:

1. UDF/ (with may be personal in addition)
2. bin/
3. firebird.conf (with personal in addition)
4. firebird.msg
5. help/
6. include/
7. intl/ (with may be personal in addition)
8. lib/

Later if required we may add more shared between instances resources.

[Fred Polizo]

Post by Vlad Horsun

Post by Alex Peshkov

Post by Vlad Horsun

Post by Alex Peshkov
Are you sure other OS's also support such regions?

Some time ago someone told about it here, IIRC.

mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)
Name of region is name of file. No problems creating anonymous mapping (in
that case fd is ignored), but it makes no sense for embedded access.

Are posix have some special name space for 'files' which is not mapped to
real disk files ?

Have a look at the shm_open() and shm_unlink() POSIX functions.

Put simply, shm_open() opens/creates a named "Shared Memory Object"
and returns a file descriptor for that object. You can call ftruncate()
on the resulting fd to size the memory object as needed. You can pass
the fd to mmap() to map the object into your address space. Function
shm_unlink() unlinks the object's name from system.

These functions were added as part of the POSIX Realtime Extension
back in the '90s. Like a lot of POSIX functionality (e.g., mmap),
these are "optional" on a given implementation. However, these days,
many systems support these functions (e.g., GNU/Linux, Sun, HP, BSD,
Darwin, etc.). Note: some systems require that another library
be linked with apps calling these functions (e.g. "librt" on
Sun and GNU/Linux).

Try this URL for more details and an example of shm_open() usage:
http://www.opengroup.org/onlinepubs/000095399/functions/shm_open.html

Hope this helps,
Fred P.

[Alex Peshkov]

Post by Fred Polizo

Post by Vlad Horsun
Are posix have some special name space for 'files' which is not
mapped to real disk files ?

Have a look at the shm_open() and shm_unlink() POSIX functions.
Put simply, shm_open() opens/creates a named "Shared Memory Object"
and returns a file descriptor for that object. You can call ftruncate()
on the resulting fd to size the memory object as needed. You can pass
the fd to mmap() to map the object into your address space. Function
shm_unlink() unlinks the object's name from system.
These functions were added as part of the POSIX Realtime Extension
back in the '90s. Like a lot of POSIX functionality (e.g., mmap),
these are "optional" on a given implementation. However, these days,
many systems support these functions (e.g., GNU/Linux, Sun, HP, BSD,
Darwin, etc.). Note: some systems require that another library
be linked with apps calling these functions (e.g. "librt" on
Sun and GNU/Linux).
http://www.opengroup.org/onlinepubs/000095399/functions/shm_open.html

Thanks, that may be really useful in the future.

[Olivier Mascia]

Post by Alex Peshkov
Actually there is no big need in
changing directory, where binaries are located - let them stay where
installed. Changing working directory is what really needed to have many
instances with single installation.

There I agree completely.

If at least installed stuff (binaries and additional files) can be
shared by all and any instances set to run, then it is probably not a
problem to require each of these instances to have a distinct working
directory. It could probably be done with more effort and time
without this requirement, but it is a very minor requirement and for
the kind of needs I look forward, it surely wouldn't be any problem.

[Olivier Mascia]

Post by Alex Peshkov
Setting correct home directory is very important for firebird
operation, cause here it keeps various lock files, and the fact
that only one firebird instance works with same set of lock files
at a time is absolutely required for it's successful operation. I
repeat this well known fact here to emphasize that starting more
then one instance from same working directory is a bug. (There is a
switch to set path to lock files separately from home, but this is
not a full-featured solution and requires more modifications in
firebird be useful, cause code, working with security database
ignores that switch, and opening database from more then one
instance of firebird breaks it at once - and this is just the first
sample which came to my mind.)

Known and agreed. That's why this feature (ability to run multiple
'instances' from a same set of binaries - let's call this from a
'same home') would be welcomed by hosting providers.

Post by Alex Peshkov
Therefore currently we should better follow the rule of thumb -
separate home for each instance. But with that fact taken into an
account, it becomes clear that adding any more switches to command
line is senseless and is just duplication - separate home directory
contains separate config file.

** If ** the -e switch is made available on Win builds too, then at
least playing at separating full copies in different directory trees
would be appreciated, indeed.

Side question, just for my education: why can't FB get rid of file-
system based lock files? Why not only rely on named IPC objects?

[Mercea Paul]

-----Original Message-----
Would not it be reasonable to return all instances status? Can you distinguish
between firebird server instances and other services?

If all firebird services are grouped it can be use function like sc
sc query group=FIREBIRD

Regards,
Paul

[Dmitry Yemanov]

Post by Paul Reeves
1/ 'instsvc install -name servicename' does not leave any trace of the
name used, other than in the registry for services. This means that
when we run 'instsvc query' it only returns the status of the default
instance.
If we know the service name we can query it. But we have no mechanism
to list the installed service names.

EnumServicesStatusEx() and then search for the 'FirebirdServer' prefix.

Post by Paul Reeves
2/ Running a service under a user defined name more or less requires a
full installation of Firebird. We could probably specify a minimum
install, but instsvc takes its current directory as the instance
directory and the server looks for its config file in the root above.
I don't think we need to do anything about this for 2.1, but it would
be useful if we could configure multiple instances from a single
install. Each instance would require its own firebird root dir for
the conf files, message file, lock file and log file and any
required libraries.

Such an advanced setup would be welcome (after yet another longish
discussion), but it wasn't intended for v2.1.

What we offer now is mostly an ability for different *versions* to
co-exist. It was always possible on Linux, but not on Windows (at least
not in the service mode). Now it becomes possible without manual
registry changes. I wouldn't claim that as a full-featured
multi-instance stuff...

Post by Paul Reeves
3/ We have no mechanism to list all the installed instances. instreg is
not connected to instsvc. I'm not sure that it needs to be, but from
the POV of the installer it would be useful to get a list of
installed instances.

See above.

Post by Paul Reeves
Part of the problem here is that when multiple
services are configured they each run on a separate port. But we
don't know what those ports are, or which version are behind them.
Do we need to know? Can we complete 2.1 without knowing?

We can live without that knowledge.

Post by Paul Reeves
4/ The ControlPanel applet needs a major overhaul. Users need to see
- all installed instances
- configuration values such as port number
- ideally should allow adding/deleting installed service instances

The first item is enough for v2.1, IMO.

Post by Paul Reeves
5/ If the %FIREBIRD% variable is set it confuses the non-default
installed services.

It confuses all the extra FB versions installed on the machine, starting
with v1.5. In fact, it has very little to do with multi-instancing in
v2.1 per se. And AFAIK we provide no official ability to set this
envvar, so all the default installations cannot be affected. But I see
no problems with ignoring FIREBIRD (and all its friends and relations)
for the -s mode.


Dmitry

[Paul Reeves]

Post by Dmitry Yemanov

Post by Paul Reeves
1/ 'instsvc install -name servicename' does not leave any trace of the
name used, other than in the registry for services. This means that
when we run 'instsvc query' it only returns the status of the default
instance.
If we know the service name we can query it. But we have no mechanism
to list the installed service names.

EnumServicesStatusEx() and then search for the 'FirebirdServer' prefix.

Oh, yes, I'm familiar with the MS Services api :-)

I take it that you don't mind if I add this to instsvc sometime during
the beta test period? (Or you can add it? )

Post by Dmitry Yemanov
What we offer now is mostly an ability for different *versions* to
co-exist. It was always possible on Linux, but not on Windows (at least
not in the service mode). Now it becomes possible without manual
registry changes. I wouldn't claim that as a full-featured
multi-instance stuff...

This is fine for me. I'm really trying to establish what is the minimum
we need to do for 2.1. As I more or less mentioned elsewhere, a
combination of 32-bit and 64-bit versions, combined with the FIREBIRD
variable leads immediately to a mess. Things like the fbintl.dll won't
load, for example. Add to that the inablility to use instsvc to see just
what services are installed and you can see we will have some support
problems.

Post by Dmitry Yemanov

Post by Paul Reeves
4/ The ControlPanel applet needs a major overhaul. Users need to see
- all installed instances
- configuration values such as port number
- ideally should allow adding/deleting installed service instances

The first item is enough for v2.1, IMO.

OK.

Post by Dmitry Yemanov

Post by Paul Reeves
5/ If the %FIREBIRD% variable is set it confuses the non-default
installed services.

And AFAIK we provide no official ability to set this
envvar, so all the default installations cannot be affected.

Yes, this is true. On the other hand, setting it is sort of standard
practice, along with ISC_USER and ISC_PASSWORD.

Post by Dmitry Yemanov
But I see
no problems with ignoring FIREBIRD (and all its friends and relations)
for the -s mode.

OK.


Paul

[Dmitry Yemanov]

Post by Paul Reeves
Oh, yes, I'm familiar with the MS Services api :-)

;-)

Post by Paul Reeves
I take it that you don't mind if I add this to instsvc sometime during
the beta test period? (Or you can add it? )

I don't mind. I'll extend services.cpp to enumerate the instances so
that both instsvc and the CPL applet could benefit from that code.


Dmitry