Placing mysql install script (webapps-common with dbconfig-common)

[Jan-Pascal van Best]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sean and others,

I'm using webapps-common to package phpesp (a set of php scripts for
online surveys). Since updating to webapps-common 0.8 (rev. 111), I've
noticed that the mysql install script location has changed. It used to be
/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
has configured the webapp to be living. I understand something like this
is necessary in order to support multiple instances of the same app
running on a server. My question is, how do I (in the postinst script)
find out WC_INSTANCE?
I currently use
db_get phpesp/httpd/instances || {
echo "Website directory not found" >&2
}
WC_INSTANCE="$RET"
but this only works if there is only one instance (well, I could loop over
all configured instances, no problem). It would be nice if there would be
a
documented 'wc_instances' environment variable I could use for this.

Another reason this is needed is that phpesp needs to know its base URL,
or actually, the 'website_subdirectory' question asked during package
configuration. There are several scripts in several locations that link to
each other with <a href=...> tags in the generated html. The protocol and
hostname parts can be determined dynamically, but the base directory
cannot (without storing the location of each script in the scripts
themselves). So now I use
WC_DIRECTORY="`echo $WC_INSTANCE | cut -sd/ -f2- | sed -e 's,^/,,'`"
to strip off the host part and get to the website subdirectory. Maybe
that's not the nicest way to get to the subdirectory either - is there a
better way?

Thanks for your work on webapps-common up to now!

Cheers

Jan-Pascal

PS: Subversion repository of the phpesp package is at
http://svn.vanbest.org/svn/phpesp/trunk/ ; websvn at
http://www.vanbest.org/websvn/listing.php?repname=phpesp&path=%2Ftrunk%2Fdebian%2F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGVUIOOkyycBqJzCMRAo3MAKCdT7hN6Vib8qU+E12yMIzgcrEHcACcDplU
kx96xGZ//yyDMseG+aN1ofs=
=Bkl6
-----END PGP SIGNATURE-----

[sean finney]

hi jan,

Post by Jan-Pascal van Best
/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.

Post by Jan-Pascal van Best
has configured the webapp to be living. I understand something like this
is necessary in order to support multiple instances of the same app
running on a server. My question is, how do I (in the postinst script)
find out WC_INSTANCE?

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...

Post by Jan-Pascal van Best
Another reason this is needed is that phpesp needs to know its base URL,
or actually, the 'website_subdirectory' question asked during package
configuration. There are several scripts in several locations that link to
each other with <a href=...> tags in the generated html. The protocol and
hostname parts can be determined dynamically, but the base directory
cannot (without storing the location of each script in the scripts
themselves). So now I use
WC_DIRECTORY="`echo $WC_INSTANCE | cut -sd/ -f2- | sed -e 's,^/,,'`"
to strip off the host part and get to the website subdirectory. Maybe
that's not the nicest way to get to the subdirectory either - is there a
better way?

i think we may need a webapps-common tool like the dbconfig-generate-include
tool from dbconfig-common...


sean

[Jan-Pascal van Best]

Hi Sean,

Post by sean finney
hi jan,

Post by Jan-Pascal van Best
/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?

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.

Post by sean finney

Post by Jan-Pascal van Best
has configured the webapp to be living. I understand something like this
is necessary in order to support multiple instances of the same app
running on a server. My question is, how do I (in the postinst script)
find out WC_INSTANCE?

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?

Post by sean finney

Post by Jan-Pascal van Best
Another reason this is needed is that phpesp needs to know its base URL,
or actually, the 'website_subdirectory' question asked during package
configuration. There are several scripts in several locations that link to
each other with <a href=...> tags in the generated html. The protocol and
hostname parts can be determined dynamically, but the base directory
cannot (without storing the location of each script in the scripts
themselves). So now I use
WC_DIRECTORY="`echo $WC_INSTANCE | cut -sd/ -f2- | sed -e 's,^/,,'`"
to strip off the host part and get to the website subdirectory. Maybe
that's not the nicest way to get to the subdirectory either - is there a
better way?

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...

Cheers

Jan-Pascal

Post by sean finney
sean

[sean finney]

hey jan,

Post by Jan-Pascal van Best

Post by sean finney

Post by Jan-Pascal van Best
/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.

Post by Jan-Pascal van Best
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.

Post by Jan-Pascal van Best

Post by sean finney
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.

Post by Jan-Pascal van Best

Post by sean finney
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