hey jan,
On Friday 25 May 2007 08:35:28 Jan-Pascal van Best wrote:
> > On Thursday 24 May 2007 09:43, Jan-Pascal van Best wrote:
> >> /usr/share/dbconfig-common/data/<packagename>/install/mysql
> >> but now it is
> >> /usr/share/dbconfig-common/data/<WC_INSTANCE>/install/mysql
> >> where WC_INSTANCE is something like =global=/phpesp or whereever the
> >> user
> >
> > eek, that's actually an unintended sideeffect. i wonder why i didn't see
> > it in my testing... there's probably going to be a few more like this
> > too.
> >
> > for configuration-related stuff the layout should be something like
> > package/instance/configfile, but for the bootstrapping sql and other
> > instance-independant info, the instance shouldn't be appended at all.
>
> I think it is - maybe each instance needs its own admin
> password (like phpesp does). In general, you wouldn't want all
> instances to share the same (default) password. Maybe
> allow both ways?
i think that's a slightly different problem. my point was that you're
bootstrapping the same tables/data/etc into each instance, regardless of
other stuff.
as for setting default passwords, this is definitely a missing feature that
i'm open to suggestions on. there's two underlying sub-problems:
- how to know *how* to set the "admin" password, whatever that entails.
- how to convey the information at installation/configuration time.
the former could be done by providing another hook query of some kind
similar to the install/update code, wouldn't be too hard to implement at all
(the script could assume it would be passed the password, and leave the
choosing to something else)
the latter is the tricky part, and why we can't just generate a "random"
password. imagine being a normal admin/user, installing something like
otrs2, and then after finishing getting the login screen without knowing
what the password was. you could always point them at README.Debian or the
config file with the password in it, but that'd still cause a lot of
unnecessary confusion/bugs/support-queries.
i guess one way to get around this is to have a "default" default password
(which could be in the sql bootstrapping script like it probably is now), and
at configuration time ask for a new one. if one isn't provided by the admin,
the default stays, and if it is the password update is applied before the app
is activated.
> The instance should be some identifier, though, and not the
> web location where the instance is installed: if, later, the
> instance is moved using dpkg-reconfigure, and after that an
> update need additional sql, where should that sql be placed?
> In the old or in the new location? An identifier (a name, an
> auto-incrementing number, or even some random number)
> looks better to me.
i thought for a while about this at implementation time, like taking an
md5sum of the site/directory name, but that seemed really counter-intuitive
from an administrative point of view. we could still generate such an id for
other purposes if there was a good motivation for it.
but regarding where to find the additional sql, i think the sql should always
be in the same place, regardless of instance. if there are instance-specific
data in an update for some reason, you could use the dbc_sql_substitutions
variable to do some kind of template-based substitutions. but i'm not sure
when that might be needed, as the sql stuff doesn't need to know the
user/database/etc config choices, should just be updating/altering tables and
stuff.
> > currently there isn't an easy way, though i agree there ought to be.
> > it'd help to have a picture of some of the use cases for it, so i don't
> > go designing a tool that meets the wrong needs...
>
> Well, phpesp is one use case. Maybe advertise on debian-devel
> for more guinea pigs?
sure, and debconf is coming up too. i don't know if someone has organised
another webapps BoF, but i could at least find and informally ask some of the
folks who'd be interested in this in person as well.
> > i think we may need a webapps-common tool like the
> > dbconfig-generate-include tool from dbconfig-common...
>
> That sounds great - but how would that work in the multi-instance
> case? I think the include file name should also be a template, and
> that {db,wc}config-generate-include should fill in the instance ID
> for each of the configured instances. Enough to cause headaches...
yeah, that'd be the primary difference from dbconfig-generate-include... the
output file would need to be templated too.
sean
Attachment:
signature.asc
Description: This is a digitally signed message part.