On Sun, 2004-10-17 at 00:26, sean finney wrote:
> hey all,
>
> for those who weren't following the previous thread[1], i've come up with
> a rough draft of a "best practices" document for database based
> applications. i'd greatly appreciate input, especially from the current
> maintainers of database-using or database-server applications. the draft
> is available at:
>
> http://people.debian.org/seanius/policy/dbapp-policy.html
Thanks for this, Here's my first response.
I attach a diff on the templates file, including questions for a
PostgreSQL installation..
Bear in mind that users seeing these questions may not understand their
implications. Some of my additions are intended to help out such
people.
Template: database-common/database-type
Type: select
How will you determine what servers are available? A select list
implies that the config script has gathered the data from somewhere. If
database servers are on some other machine, how will you get them to be
represented on this list?
Maybe there needs to be some kind of advertising service, such as is
used by CUPS, that each database server will use to advertise its
existence and the services it can provide. Or maybe this field should
be free text, so that non-local servers can be specified.
(See below about combining this question with others.)
Choices: ${database_types}
_Description: What database type should ${pkg} use?
The data presented should say what version of the database server is
available (if more than one host is present), since some software will
require a particular release level. (For example, a package I am
developing at the moment will require PostgreSQL 8 as a minimum release
level.) Getting this data from a remote machine implies that there is
an enquiry service that can return it. Clearly, the config script
should be able to exclude servers that cannot offer the requried
facilities. If we are using remote services, we cannot depend on
package dependencies at this point, so this may be a time for error exit
with a recommendation for the installation of some particular server
package.
Template: database-common/mysql/app_user
_Description: What mysql username should ${pkg} use?
The description needs to make clear the distinction between database
users and system users. (They may be the same but they need not be.)
We also need to make it clear that the app-user is the user which will
own the new database and the objects in it and will have the ability to
alter any data in it.
Whatever its priority, this question would not appear if the database
has already been created, since the database owner would already be
determined.
Template: database-common/mysql/app_password
_Description: What mysql password should ${pkg} use?
This would need to be provided even if the package already exists and
has created a database, if the app_user user is needed to make any
changes to an existing database.
Template: database-common/mysql/host
Type: select
Choices: local socket
_Description: What mysql host should ${pkg} use?
Please provide the hostname of the database server for ${pkg}.
Template: database-common/mysql/host_new
Type: string
_Description: What mysql host should ${pkg} use?
Please provide the hostname of the database server for ${pkg}.
Why two of these questions? Does the choice of local or socket mean
localhost or UNIX socket? (Does MySQL offer that option?)
I think it would be better if the database discovery program presented
all this information and presented it together as the choices for
database-common/database-type. The question is really, which particular
database, at which release level and on which server, should hold the
data? Presenting all possible choices in one go seems easier to cope
with:
mysql 4.0 local
mysql 3.23 host2.local.net
postgresql 7.4 local
postgresql 8.0 devel.local.net
firebird 1.5 local
There may still be a choice of access method at this point. For
PostgreSQL, you may be able to use UNIX socket, clear TCP/IP or TCP/IP
with SSL, and these may have different authentication requirements
(password, ident, pam, kerberos).
Having once got all information necessary to connect to the selected
database server, the config script needs to attempt a connection to
discover if it will be able to complete the installation. This is by no
means guaranteed, since database access policies may preclude it and
need to be changed by the database administrator. As we have seen, the
server may not be on the local machine, so using root privilege to
override may not be possible.
Even if the server is on the local machine, I am opposed to having any
application package alter the database access policies. This is OK for
the installation of the server package itself, since it could not
otherwise be installed, but we should not assume that the system
administrator is the same as the database administrator; nor should we
allow an application package to make that assumption, since it might
then make changes to the access policies which would inadvertently open
other databases to unauthorised access. (This is already covered by
Debian policy, forbidding the alteration of conffiles, but I think it
should be stated explicitly.) I think it is appropriate for an access
failure at this stage to result in a message detailing what needs to be
done in the database server to permit installation to proceed.
Template: database-common/mysql/purge
Default: true
_Description: Do you want to purge your the mysql database for
${pkg}?
I think the default should be false. Destroying a database is a major
disaster if it is unintentional; we should never assist people to shoot
themselves in the foot.
Template: database-common/mysql/admin_user
_Description: What is the name of your database's administrative
user?
For PostgreSQL, this is "postgres"; the installation scripts have to do
su - postgres
in order to use it.
Template: database-common/mysql/admin_pw
_Description: What is the name^Wpassword of your database's
administrative user?
This and the app_user password questions need to be deregistered as soon
as a successful installation is completed; although the passwords.dat
part of the debconf database has 600 perms, cleartext passwords should
not be left lying around anywhere unless necessary.
--
Oliver Elphick olly@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"Trust in the LORD, and do good..." Psalms 37:3
