On Thu, 2004-12-16 at 15:34 +0100, Andreas Tille wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
>
> > Is that the majority or the minority of applications?
> > Take for example a web application like a forum. It requires the
> > password so it can connect to the database. It can't/won't as
On Fri, 17 Dec 2004, Karsten Hilbert wrote:
Well, see, the GnuMed bootstrapping does a lot more advanced
things regarding "the database user". There's users and groups
with varying levels of access to the database.
However, if dbconfig-common creates the admin account we just
use it. We can also de
> >but something to point out: dbconfig-common already performs the
> >administrative actions needed to set up the database and database user
Well, see, the GnuMed bootstrapping does a lot more advanced
things regarding "the database user". There's users and groups
with varying levels of access to
In article <[EMAIL PROTECTED]>,
Olaf van der Spek <[EMAIL PROTECTED]> wrote:
>On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland
><[EMAIL PROTECTED]> wrote:
>> On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote:
>> > Take for example a web application like a forum. It requires
On Thu, 16 Dec 2004, sean finney wrote:
but something to point out: dbconfig-common already performs the
administrative actions needed to set up the database and database user
in the first place, so does your package even need the admin password?
The applilcation I want to package comes with a qui
On Thu, Dec 16, 2004 at 04:17:11PM +0100, Olaf van der Spek wrote:
> Ah, k. It makes less/no sense to store that password.
> But I wonder, is there no way to use the 'power' of the root account
> to do such DB administration without password then?
in mysql, at least, there is. however, you have t
On Thu, Dec 16, 2004 at 08:27:20AM +0100, Andreas Tille wrote:
> Yes, but I do not want to store the password *anywhere* - it could even
> be removed from debconf database because it makes no sense to store it
> in case the local maintainer changes the database password the value
> is absolutely us
On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland
<[EMAIL PROTECTED]> wrote:
> On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > Take for example a web application like a forum. It requires the
> > password so it can connect to the database. It can't/won't ask the
> > pa
On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> Take for example a web application like a forum. It requires the
> password so it can connect to the database. It can't/won't ask the
> password from the user.
But there is (or at least, should be) a specific user for that
On Thu, 16 Dec 2004 15:34:35 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]>
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
>
> > Is that the majority or the minority of applications?
> > Take for example a web application like a forum. It requires the
> > password so it can connect to the
On Thu, 16 Dec 2004, Olaf van der Spek wrote:
Is that the majority or the minority of applications?
Take for example a web application like a forum. It requires the
password so it can connect to the database. It can't/won't ask the
password from the user.
Can you tell me any reason why I should sto
On Thu, 16 Dec 2004 14:55:29 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]>
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
>
> > Because system passwords aren't 'needed' by any applications to
> > authenticate themselves to the system, while database passwords are.
> No, they are not need
On Thu, 16 Dec 2004, Olaf van der Spek wrote:
Because system passwords aren't 'needed' by any applications to
authenticate themselves to the system, while database passwords are.
No, they are not needed in the file system. They are needed inside
the database and they are save there (assumed that t
On Thu, 16 Dec 2004 14:22:25 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]>
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
>
> >> Yes, but I do not want to store the password *anywhere* - it could even
> >> be removed from debconf database because it makes no sense to store it
> >> in cas
On Thu, 16 Dec 2004, Olaf van der Spek wrote:
Yes, but I do not want to store the password *anywhere* - it could even
be removed from debconf database because it makes no sense to store it
in case the local maintainer changes the database password the value
is absolutely useless in any config file
On Thu, 16 Dec 2004 08:27:20 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]>
wrote:
> On Wed, 15 Dec 2004, sean finney wrote:
> Yes, but I do not want to store the password *anywhere* - it could even
> be removed from debconf database because it makes no sense to store it
> in case the local mainta
On Wed, 15 Dec 2004, sean finney wrote:
On Mon, Dec 13, 2004 at 08:36:19PM +0100, Andreas Tille wrote:
Do you have any hint for me how to help here and according to my
previous mail on debian-devel how can I obtain debconf settings
for the specific package ( db_get gnumed/pgsql/admin-pass)
On Thu, 2 Dec 2004, sean finney wrote:
most of the script stuff could be shared in between the two, yeah. i
designed the system such that it could eventually handle supporting
multiple database types, as well as packages that support multiple
database types themselves. then, i proceeded to start
hi andreas,
On Thu, Dec 02, 2004 at 10:32:50PM +0100, Andreas Tille wrote:
> More questions on your version 0.7:
>
> - I asked in previous mail what to do for PostgreSQL support. While
>having a quick view on the code I wonder if just using a variable
>for the database server most of th
On Sat, 20 Nov 2004, sean finney wrote:
On Sat, Nov 20, 2004 at 06:23:46PM +0100, Andreas Tille wrote:
deb http://people.debian.org/~seanius/policy/examples/ ./
deb-src http://people.debian.org/~seanius/policy/examples/ ./
More questions on your version 0.7:
- I asked in previous mail what to do f
On Sat, 20 Nov 2004, sean finney wrote:
this sounds like a good plan, i'll upload this after i do the update
and some final testing of the last set of changes i've made.
I've found your stuff at
http://people.debian.org/~seanius/policy/examples/
from today and I'm really impressed. My question
First of all, this package would be a God-send for me (see below)
Note that 'wwwconfig-common' already contains most of the needed
infrastructure... but it is too php-oriented. Splitting it in purely
Apache/PHP-oriented scripts (which would remain as wwwconfig-common) and
a new 'dbconfig-common'
hi javier,
On Wed, Oct 20, 2004 at 05:05:18PM +0200, Javier Fernández-Sanguino Peña wrote:
> - leave data after purge? -> only ask during purge.
> - back up database before upgrade? -> only ask during upgrades. user should
> be notified where to find backups and possibly how to restore.
> and oth
> > - further amendments to the "best practices" document based on developer
> > feedback.
>
> still accepting input!
You probably want to change this:
- leave data after purge? -> only ask during purge.
- back up database before upgrade? -> only ask during upgrades. user should
be notified w
another update for those interested:
http://people.debian.org/~seanius/policy/dbapp-policy.html
deb http://people.debian.org/~seanius/policy/examples/ ./
deb-src http://people.debian.org/~seanius/policy/examples/ ./
i've incorporated many of the changes discussed in the related
d-d threads into
On Tue, Oct 19, 2004 at 05:19:47PM +0200, martin f krafft wrote:
> 1. I would set the default of the "leave data after purge" to true
>and give it priority high.
i guess i had forgotten to update the page on this one (someone
else had requested this too). it should be updated now.
> 2. I am
1. I would set the default of the "leave data after purge" to true
and give it priority high.
2. I am not sure what you mean by "maintainer script". prerm and
preinst should not ask questions. they are there to enact values
stored in the debconf cache. config, on the other hand, should
On Mon, Oct 18, 2004 at 09:19:28AM +0200, Javier Fernández-Sanguino Peña wrote:
> [That should be http://people.debian.org/~seanius/policy/dbapp-policy.html,
> BTW]
oops!
> I'm missing some "Best practice" on how to setup the database itself. That
> is, how to setup the tables (indexes, whateve
On Mon, 2004-10-18 at 08:19, Javier Fernández-Sanguino Peña wrote:
>
> I'm missing some "Best practice" on how to setup the database itself. That
> is, how to setup the tables (indexes, whatever...) that the application
> will use from the database and, maybe, even some initial data in some of
On Mon, 2004-10-18 at 03:23, sean finney wrote:
...
> > 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?
On Sat, Oct 16, 2004 at 07:26:10PM -0400, sean finney wrote:
> 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
[Tha
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 i
On Sun, 2004-10-17 at 21:41, Oliver Elphick wrote:
> I attach a diff on the templates file, including questions for a
> PostgreSQL installation..
Well, I do now.
--
Oliver Elphick olly@lfix.co.uk
Isle of Wight http://www.lfix.
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 dat
34 matches
Mail list logo
