Re: [Gnumed-devel] Re: bootstrap*

[Karsten Hilbert]

> Suggestion:
> - the "bootstrap" sets up a blank monolithic database structure and fills it 
> with basic data (postcodes, drug reference, etc.)
That is *exactly* what

 bootstrap-gm_db_system.py --conf-file=localhost-monolithic.sample.conf

does (is supposed to do barring any pending bugs).

> - the package installation for the server just does the bootstrap. No need 
> for 
> password storage: whoever wants to configure the backend, needs to be good 
> old root (in order to su to postgres, that is).
Not that easy. All GnuMed databases/database objects are to be
owned by user "gm-dbowner". One needs to get a password for
this user from somewhere. Also - except for the admittedly
most common case of connecting to localhost - we would also
need the password for the user "postgres".

> - the package installation for the client installs - well, the client
Yes.

> The first time a client is started, you have to enter backend information. 
> The 
> client then checks whether the backend has already been configured. If not, 
> configuration dialog is presented.
Yes.

> The configuration dialog then offers to
> - set up new users, groups, and related permissions
Permissions ought to be handled via groups to which users are
assigned. This can, of course, be circumvented for special
requirements but that would require more db skills anyways.

> - optionally distribute databases
Yes. But: How do you detect whether the user wants to run all
services from the database hosting the service "default" or
from some other database ? I guess one will have to postpone
this decision until gmPG tries to open a connection to some
other service on behalf of the client and detects that this
service does not live in the default database (ha,
gmServices.sql starts to sound like being useful after all).
At that point you can open up the configuration dialog. The
locations of the installed services are to be found in the
default service. The user just needs to select which one to
use - that decision will, of course, be cached for the next
time around.

> - configure all other options
Yes.

> - download & configure updates
You'd need to locally be root to do that.

> In short, configuration and password trouble is postponed until the client 
> tries to connect to the backend for the first time
Yes.

What you describe is amazingly similar to my intentions.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346