hey oliver,
On Sun, Oct 17, 2004 at 09:41:36PM +0100, Oliver Elphick wrote:
> I attach a diff on the templates file, including questions for a
> PostgreSQL installation..
thanks!
> Bear in mind that users seeing these questions may not understand their
> implications. Some of my additions are intended to help out such
> people.
okay. part of the plan is to use different priorities for the
information in the script. for example, database name and user can
be priority low and automatically set.
> 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?
ideally a common script could take care of this, and substitute the
choices in. the question database-type is for apps that support
multiple database backends (mysql, postgresql, etc). then there's
a question like:
Template: database-common/mysql/host
Type: select
(which should more appropriately be called "location" i guess) this
serves a default list and could also include a "new" option,
which would let someone input the next question:
Template: database-common/mysql/host_new
Type: string
the latter question could then contain a cache of the most recently
used responses from the defaults + the former.
> 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.
i think a common script could figure this out pretty easily, though
making sure that it runs at the right time (it's possible that it
may be configured before pgsql/mysql are unpacked) will be tricky.
> 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.
i think if the admin knows enough to be using a remote sql host, they're
probably okay to figure that out, but it would be nice. basically, we'd
need from each database-package maintainer a series of scripts to find
this information.
> 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.)
good point, i'll make a clarification on that.
> 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.
definitely. i'll do the same for the admin ones too.
> 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.
i think that we'd need to either ask the user if it's been flushed
from debconf, or a way to automatically grok it from whatever config
file it's stored in. or, use the admin user/pass for performing these
operations (though this could lead to more uncontained damage in a broken
script)
> 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 i explained this a bit earlier. this would effectively be a
list of cached URI's and a question to get a new one from the user.
not very clear outside of context, i guess.
> 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
i think it would make the most sense this way, but it would
be too much for debconf to input this all at once. however,
what if debconf stored a list of completed server resources
used by other packages (like you provided above), and prompted
the user with that *first*, and then otherwise input the
questions with the seperate questions?
> 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).
so then we'd need more questions, and need to take this into mind
with whatever interface was provided.
> 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.
i think most of this could be handled under the hood, if each database
resource provider gives methods for getting this information. they
could be simple shell scripts that print information and return 0 for
success or some set of non-zero information-providing error values.
> 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
what exactly do you mean by altering access policies? granting
privileges to a new user?
> 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.
my thought was to have it default to false, but have it be a high
priority question, but don't strongly believe in this stance, so
i'll change that.
> 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.
so then we don't need to ask that question for pgsql :)
>
> 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.
for the admin password, i agree. for the app_user password, i think
most apps are storing this password in a cleartext file for the
application to use (php web apps, for example). that's my opinion,
anyways.
thanks for all the input!
sean
--
Attachment:
signature.asc
Description: Digital signature