But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
The deb package as it is currently is set up with dependencies on java and tomcat (so they will be triggered to install if necessary). By default it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also mysql users out there so it didn’t seem right to make it a dependency. So currently you would be required to:
install dhis2 from deb
install postgres (apt-get install )
configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a dhis2-postgres meta package which does the above three, though I’m not sure entirely how to handle dependencies where dhis2 is not yet available from ubuntu repositories. Basically this would just contain just the hibernate.properties and the dependency information. A dhis2-mysql package would look very similar.
One solution would be to host the debs in a repository on dhis2.org. Then it would just be a case of getting users to add http://dhis2.org
to their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an alternative version of dhis2 package with the exception that this has the webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into this? I didn’t get the sense that there was too much interest in the deb. It seems to be a useful little curiosity.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
I don’t know how many people are currently interested in running DHIS2 on Ubuntu, but I don’t think it is negligible, and I would like to see it increase. The reason this came up now, is that I have been trying to guide people in Malawi over IM, not an efficient process. Installation needs to be made as easy as possible - preferably also in “standalone” conditions, i.e. where you bring a USB stick or CD to a computer with no or sloooow internet connection. We should not require end users to have to touch the command line or know about config files.
There are several approaches, and we could offer more than one:
Write out the steps (including for Postgres and Mysql) in a clear and easy to follow manner, prominently displayed on dhis2.org
An installer that basically just unzips everything you need. This was done already 3-4 years ago in Kerala by Øystein, using BitRock (he also made a CD image that installed DHIS2 and Mysql on Windows, then created a partition for Linux, installed the very lightweight http://wolvix.org/ distro with Tomcat and pointed it to the same Mysql database on the Windows partition).
A more conventional installer using IzPack that does what is required
“meta-debs” as you suggest
Provide downloadable Ubuntu virtual machines images with everything nicely set up
My take is that I could do 0) right now, 3) could follow when you have some time, and 4) perhaps longer term.
The deb package as it is currently is set up with dependencies on java and tomcat (so they will be triggered to install if necessary). By default it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also mysql users out there so it didn’t seem right to make it a dependency. So currently you would be required to:
install dhis2 from deb
install postgres (apt-get install )
configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a dhis2-postgres meta package which does the above three, though I’m not sure entirely how to handle dependencies where dhis2 is not yet available from ubuntu repositories. Basically this would just contain just the hibernate.properties and the dependency information. A dhis2-mysql package would look very similar.
One solution would be to host the debs in a repository on dhis2.org. Then it would just be a case of getting users to add http://dhis2.org
to their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an alternative version of dhis2 package with the exception that this has the webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into this? I didn’t get the sense that there was too much interest in the deb. It seems to be a useful little curiosity.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
I don’t know how many people are currently interested in running DHIS2 on Ubuntu, but I don’t think it is negligible, and I would like to see it increase. The reason this came up now, is that I have been trying to guide people in Malawi over IM, not an efficient process. Installation needs to be made as easy as possible - preferably also in “standalone” conditions, i.e. where you bring a USB stick or CD to a computer with no or sloooow internet connection. We should not require end users to have to touch the command line or know about config files.
This is exactly what dhis2-live does using h2. Unpack and run. And its platform neutral.
There are several approaches, and we could offer more than one:
Write out the steps (including for Postgres and Mysql) in a clear and easy to follow manner, prominently displayed on dhis2.org
OK. I can do that.
An installer that basically just unzips everything you need. This was done already 3-4 years ago in Kerala by Øystein, using BitRock (he also made a CD image that installed DHIS2 and Mysql on Windows, then created a partition for Linux, installed the very lightweight http://wolvix.org/ distro with Tomcat and pointed it to the same Mysql database on the Windows partition).
A more conventional installer using IzPack that does what is required
“meta-debs” as you suggest
You can yourself just go into dhis2/tools/dhis2deb and modify the hibernate.properties to connect to a postgres database instead. And add postgres to dependencies. Then make to create a dhis2-postgres.deb version. Its still a bit complicated because you’d have to also create the dhis2 database in postgres as part of the installation. (That’s also what is nice about h2
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
The deb package as it is currently is set up with dependencies on java and tomcat (so they will be triggered to install if necessary). By default it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also mysql users out there so it didn’t seem right to make it a dependency. So currently you would be required to:
install dhis2 from deb
install postgres (apt-get install )
configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a dhis2-postgres meta package which does the above three, though I’m not sure entirely how to handle dependencies where dhis2 is not yet available from ubuntu repositories. Basically this would just contain just the hibernate.properties and the dependency information. A dhis2-mysql package would look very similar.
One solution would be to host the debs in a repository on dhis2.org. Then it would just be a case of getting users to add http://dhis2.org
to their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an alternative version of dhis2 package with the exception that this has the webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into this? I didn’t get the sense that there was too much interest in the deb. It seems to be a useful little curiosity.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I don’t know how many people are currently interested in running DHIS2 on Ubuntu, but I don’t think it is negligible, and I would like to see it increase. The reason this came up now, is that I have been trying to guide people in Malawi over IM, not an efficient process. Installation needs to be made as easy as possible - preferably also in “standalone” conditions, i.e. where you bring a USB stick or CD to a computer with no or sloooow internet connection. We should not require end users to have to touch the command line or know about config files.
This is exactly what dhis2-live does using h2. Unpack and run. And its platform neutral.
Yes, so we need something almost as simple for postgres and mysql. There are many standalone ubuntu installs with postgres in Sierra Leone, and more to come in other countries I am sure.
There are several approaches, and we could offer more than one:
Write out the steps (including for Postgres and Mysql) in a clear and easy to follow manner, prominently displayed on dhis2.org
OK. I can do that.
An installer that basically just unzips everything you need. This was done already 3-4 years ago in Kerala by Øystein, using BitRock (he also made a CD image that installed DHIS2 and Mysql on Windows, then created a partition for Linux, installed the very lightweight http://wolvix.org/ distro with Tomcat and pointed it to the same Mysql database on the Windows partition).
A more conventional installer using IzPack that does what is required
“meta-debs” as you suggest
You can yourself just go into dhis2/tools/dhis2deb and modify the hibernate.properties to connect to a postgres database instead. And add postgres to dependencies. Then make to create a dhis2-postgres.deb version. Its still a bit complicated because you’d have to also create the dhis2 database in postgres as part of the installation. (That’s also what is nice about h2
There are lots of config stuff that needs to be done after a default postgres/tomcat/java install on any platform, and the dhis installer should take care of these.
Here are some steps that I can think of now:
set the postgres password (for the postgres user)
open postgres to remote connections
configure the pg_hba.conf correctly (e.g. to allow all on local network to connect, or all IP)
create a dhis user in postgres
create an empty dhis database in postgres owned by dhis user
make tomcat user own all files in tomcat/ and make this user start the tomcat process
create a tomcat startup script that is run at reboot
create a dhis directory and an envir variable for this
increase memory allocation with JAVA_OPTS (with user input?)
…and I am sure there are more little steps that we could take care of to make it a better user/admin experience
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
I like the way openmrs is taking care of db stuff at webapp startup in web UI. The tool they use for this was mentioned here on the list some months back, can’t remember the name now.
The deb package as it is currently is set up with dependencies on java and tomcat (so they will be triggered to install if necessary). By default it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also mysql users out there so it didn’t seem right to make it a dependency. So currently you would be required to:
install dhis2 from deb
install postgres (apt-get install )
configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a dhis2-postgres meta package which does the above three, though I’m not sure entirely how to handle dependencies where dhis2 is not yet available from ubuntu repositories. Basically this would just contain just the hibernate.properties and the dependency information. A dhis2-mysql package would look very similar.
One solution would be to host the debs in a repository on dhis2.org. Then it would just be a case of getting users to add http://dhis2.org
to their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an alternative version of dhis2 package with the exception that this has the webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into this? I didn’t get the sense that there was too much interest in the deb. It seems to be a useful little curiosity.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
I don’t know how many people are currently interested in running DHIS2 on Ubuntu, but I don’t think it is negligible, and I would like to see it increase. The reason this came up now, is that I have been trying to guide people in Malawi over IM, not an efficient process. Installation needs to be made as easy as possible - preferably also in “standalone” conditions, i.e. where you bring a USB stick or CD to a computer with no or sloooow internet connection. We should not require end users to have to touch the command line or know about config files.
This is exactly what dhis2-live does using h2. Unpack and run. And its platform neutral.
I get that, but it is of little help when you have a Postgres .backup file with loads of data. Of course, if we did have complete import/export with DXF, we could suggest that most people use DHIS Lite. In fact, it may be that we should promote the use of H2 instead of Mysql/Postgres. This has been mentioned before, but we haven’t really committed to such a recommendation. If that’s what we think, we should state it clearly and prominently - and we should have clear instructions on backup etc.
Of course Pg and Mysql would still be fully available to more advanced users who don’t need pre-packaged stuff.
There are several approaches, and we could offer more than one:
Write out the steps (including for Postgres and Mysql) in a clear and easy to follow manner, prominently displayed on dhis2.org
OK. I can do that.
An installer that basically just unzips everything you need. This was done already 3-4 years ago in Kerala by Øystein, using BitRock (he also made a CD image that installed DHIS2 and Mysql on Windows, then created a partition for Linux, installed the very lightweight http://wolvix.org/ distro with Tomcat and pointed it to the same Mysql database on the Windows partition).
A more conventional installer using IzPack that does what is required
“meta-debs” as you suggest
You can yourself just go into dhis2/tools/dhis2deb and modify the hibernate.properties to connect to a postgres database instead. And add postgres to dependencies. Then make to create a dhis2-postgres.deb version. Its still a bit complicated because you’d have to also create the dhis2 database in postgres as part of the installation. (That’s also what is nice about h2
Yes. All of this should be taken care of behind the scenes if we want to continue to recommend Postgres to “non-expert” users.
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties.
That is interesting - and would potentially allow for “hot-swap” of databases, though we would need to re-run all the startup routines.
Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
Cheers
Bob
Provide downloadable Ubuntu virtual machines images with everything nicely set up
My take is that I could do 0) right now, 3) could follow when you have some time, and 4) perhaps longer term.
The deb package as it is currently is set up with dependencies on java and tomcat (so they will be triggered to install if necessary). By default it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also mysql users out there so it didn’t seem right to make it a dependency. So currently you would be required to:
install dhis2 from deb
install postgres (apt-get install )
configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a dhis2-postgres meta package which does the above three, though I’m not sure entirely how to handle dependencies where dhis2 is not yet available from ubuntu repositories. Basically this would just contain just the hibernate.properties and the dependency information. A dhis2-mysql package would look very similar.
One solution would be to host the debs in a repository on dhis2.org. Then it would just be a case of getting users to add http://dhis2.org
to their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an alternative version of dhis2 package with the exception that this has the webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into this? I didn’t get the sense that there was too much interest in the deb. It seems to be a useful little curiosity.
But it is hidden away in an obscure place and not complete enough to be truly helpful for an installation - unlike the DHIS2 Live or IzPack installers we have for Windows.
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
Anyone care to add this to the documentation or did I just volunteer
myself? there are some good tips here.
···
On Thu, Jan 28, 2010 at 3:47 PM, Ola Hodne Titlestad <olatitle@gmail.com> wrote:
On 28 January 2010 14:28, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
Hi
2010/1/28 Knut Staring <knutst@gmail.com>
Thanks Bob,
I don't know how many people are currently interested in running DHIS2 on
Ubuntu, but I don't think it is negligible, and I would like to see it
increase. The reason this came up now, is that I have been trying to guide
people in Malawi over IM, not an efficient process. Installation needs to be
made as easy as possible - preferably also in "standalone" conditions, i.e.
where you bring a USB stick or CD to a computer with no or sloooow internet
connection. We should not require end users to have to touch the command
line or know about config files.
This is exactly what dhis2-live does using h2. Unpack and run. And its
platform neutral.
Yes, so we need something almost as simple for postgres and mysql. There are
many standalone ubuntu installs with postgres in Sierra Leone, and more to
come in other countries I am sure.
There are several approaches, and we could offer more than one:
0) Write out the steps (including for Postgres and Mysql) in a clear and
easy to follow manner, prominently displayed on dhis2.org
OK. I can do that.
1) An installer that basically just unzips everything you need. This was
done already 3-4 years ago in Kerala by Øystein, using BitRock (he also made
a CD image that installed DHIS2 and Mysql on Windows, then created a
partition for Linux, installed the very
lightweight http://wolvix.org/ distro with Tomcat and pointed it to the same
Mysql database on the Windows partition).
2) A more conventional installer using IzPack that does what is required
3) "meta-debs" as you suggest
You can yourself just go into dhis2/tools/dhis2deb and modify the
hibernate.properties to connect to a postgres database instead. And add
postgres to dependencies. Then make to create a dhis2-postgres.deb
version. Its still a bit complicated because you'd have to also create the
dhis2 database in postgres as part of the installation. (That's also what
is nice about h2
There are lots of config stuff that needs to be done after a default
postgres/tomcat/java install on any platform, and the dhis installer should
take care of these.
Here are some steps that I can think of now:
- set the postgres password (for the postgres user)
- open postgres to remote connections
- configure the pg_hba.conf correctly (e.g. to allow all on local network to
connect, or all IP)
- create a dhis user in postgres
- create an empty dhis database in postgres owned by dhis user
- make tomcat user own all files in tomcat/ and make this user start the
tomcat process
- create a tomcat startup script that is run at reboot
- create a dhis directory and an envir variable for this
- increase memory allocation with JAVA_OPTS (with user input?)
....and I am sure there are more little steps that we could take care of to
make it a better user/admin experience
Ideally IMHO we might have a super-admin view of dhis without the database
connection with a set of simple web steps to setup the connection rather
than fiddling manually with hibernate.properties. Not unlike the openmrs
installer. A puzzle to solve is that we use the same database for user
authentication that we use for data. So without connection you can't log in
... and without login you can't set up connections ... etc. Would be nice
one day to separate these.
I like the way openmrs is taking care of db stuff at webapp startup in web
UI. The tool they use for this was mentioned here on the list some months
back, can't remember the name now.
Cheers
Bob
4) Provide downloadable Ubuntu virtual machines images with everything
nicely set up
My take is that I could do 0) right now, 3) could follow when you have
some time, and 4) perhaps longer term.
Knut
On Thu, Jan 28, 2010 at 12:08 PM, Bob Jolliffe <bobjolliffe@gmail.com> >>> wrote:
The deb package as it is currently is set up with dependencies on java
and tomcat (so they will be triggered to install if necessary). By default
it will just run out of the box using an h2 database in /opt/dhis2/database.
I held off on the postgres dependency because I know there are also
mysql users out there so it didn't seem right to make it a dependency. So
currently you would be required to:
1. install dhis2 from deb
2. install postgres (apt-get install )
3. configure hibernate.properties manually
I guess what would be useful hand-holding would be to have a
dhis2-postgres meta package which does the above three, though I'm not sure
entirely how to handle dependencies where dhis2 is not yet available from
ubuntu repositories. Basically this would just contain just the
hibernate.properties and the dependency information. A dhis2-mysql package
would look very similar.
One solution would be to host the debs in a repository on dhis2.org.
Then it would just be a case of getting users to add http://dhis2.org to
their software sources.
A simpler (and much uglier) solution is to create dhis2-postgres as an
alternative version of dhis2 package with the exception that this has the
webapp as well as the postgres dependency and hibernate.properties
Cheers
Bob
PS. How real is the use case. ie is it worth putting effort into
this? I didn't get the sense that there was too much interest in the deb.
It seems to be a useful little curiosity.
2010/1/28 Ola Hodne Titlestad <olatitle@gmail.com>
Hi,
I think it would be really useful to have a .deb package that is set up
to use postgres out of the box.
Ideally the DHIS deb install process should trigger installs of any
other needed packages, like java, tomcat, postgres. Would that be possible?
But it is hidden away in an obscure place and not complete enough to
be truly helpful for an installation - unlike the DHIS2 Live or IzPack
installers we have for Windows.
k
2010/1/28 Lars Helge Øverland <larshelge@gmail.com>
OK. A separate database seems doable and would not make things less secure than today at least.
Reason for asking is that here in SA people are really used to the notion of “switching datafiles” during runtime, and they keep asking how to do it with 2. I have googled for similar experiences but it doesn’t seem to be many. Will think some more too.
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
I discussed this with Ola and Bob once about how we can easily switch between databases… Is that what you are talking about here?? The better longterm approach would be to couple Spring-based API with the hibernate layer and provide access to the layer only through the API without any web/struts layers
Another easy solution is to use/create a TargetSource with different SessionFactories… We create or re-use the TargetSource and point those to the database that we want to use.
Hope you are asking what I’m answering
···
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
Cheers
Bob
OK. A separate database seems doable and would not make things less secure than today at least.
Reason for asking is that here in SA people are really used to the notion of “switching datafiles” during runtime, and they keep asking how to do it with 2. I have googled for similar experiences but it doesn’t seem to be many. Will think some more too.
Sorry don’t really know too much about DHIS1.4 authentication. How does it work? Is it that no authentication is required to run the application and the users require username and password to open different mdb files?
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
Cheers
Bob
OK. A separate database seems doable and would not make things less secure than today at least.
Reason for asking is that here in SA people are really used to the notion of “switching datafiles” during runtime, and they keep asking how to do it with 2. I have googled for similar experiences but it doesn’t seem to be many. Will think some more too.
DHIS 1.4 has a separate user database and authentication is needed to run the application (front end database).
No authentication on the back end databases (what we call database in DHIS 2), but swapping of database is done inside the front end which needs authentication.
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897
Sorry don’t really know too much about DHIS1.4 authentication. How does it work? Is it that no authentication is required to run the application and the users require username and password to open different mdb files?
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
Cheers
Bob
OK. A separate database seems doable and would not make things less secure than today at least.
Reason for asking is that here in SA people are really used to the notion of “switching datafiles” during runtime, and they keep asking how to do it with 2. I have googled for similar experiences but it doesn’t seem to be many. Will think some more too.
I discussed this with Ola and Bob once about how we can easily switch between databases… Is that what you are talking about here?? The better longterm approach would be to couple Spring-based API with the hibernate layer and provide access to the layer only through the API without any web/struts layers
Yes talking about switching databases runtime. What Spring-based API are you referring to here?
Another easy solution is to use/create a TargetSource with different SessionFactories… We create or re-use the TargetSource and point those to the database that we want to use.
I discussed this with Ola and Bob once about how we can easily switch between databases… Is that what you are talking about here?? The better longterm approach would be to couple Spring-based API with the hibernate layer and provide access to the layer only through the API without any web/struts layers
Yes talking about switching databases runtime. What Spring-based API are you referring to here?
Another easy solution is to use/create a TargetSource with different SessionFactories… We create or re-use the TargetSource and point those to the database that we want to use.
Theres kind of an assumption here that this must be a single user scenario. You wouldn’t want to be swapping databases with 3 users logged in!
Putting the web/struts layer to one side and thinking just about a single user accessing the database through the secured API it might make sense to imagine you were designing a fat client VB/QT/ Swing style application. I think you would have 2 approaches:
authenticate to the application somehow (many options all hidden behind spring security) , then depending on role, open one of a number of possible databases possibly without further authentication. This seems to be similar to what dhis 1.4 is doing.
OR
just open the application unsecured and get presented with basic UI and menu options, one of which is to open a database, which would require subsequent authentication.
This second way would probably have to go along the lines of what I think Saptarshi is saying ie. remove the link between authentication and the webapp. The service modules are “natively” secured . The web layer becomes just like a GUI toolkit which you don’t require authentication to use.
I discussed this with Ola and Bob once about how we can easily switch between databases… Is that what you are talking about here?? The better longterm approach would be to couple Spring-based API with the hibernate layer and provide access to the layer only through the API without any web/struts layers
Another easy solution is to use/create a TargetSource with different SessionFactories… We create or re-use the TargetSource and point those to the database that we want to use.
Hope you are asking what I’m answering
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme
Ideally IMHO we might have a super-admin view of dhis without the database connection with a set of simple web steps to setup the connection rather than fiddling manually with hibernate.properties. Not unlike the openmrs installer. A puzzle to solve is that we use the same database for user authentication that we use for data. So without connection you can’t log in … and without login you can’t set up connections … etc. Would be nice one day to separate these.
What would the alternatives be for storing user authentication?
I’m not sure exactly. As I say it’s a bit of a puzzle and the best authentication mechanism depends quite a bit on the installation context. DHIS2 running “in the cloud” and accessed over the internet as in India is a very different proposition to running browser, tomcat and db server on the shared pentium III machine in a dusty office.
But there could be a few. I guess the question is whether we want to separate access to the application from access to a particular database (from a developer perspective this is obviously useful because we flip databases all the time - might be less so for a real user whose only need to be authenticated is to access a particular database). But off the top of my head there might be:
(i) a separate user/password database perhaps using h2 or .htpasswd style files
(ii) a separate ldap service
(iii) the database native user/privilege system
(iv) some kind of hybrid separating authentication to the application from database authentication
I guess each of the above throws up little (and big) challenges regarding how and when to instantiate hibernate sessions. The idea of all the user authentication stuff being in the database seems to fit best when (i) the internet is in the way of physical access to hibernate.properties or (ii) when using databases like h2 or MSAccess where there is no database server between the user and the data.
A hybrid solution might be something like there being a single super-admin user who can login without the database connection and who can modify hibernate.properties. Or in a variation on this theme, a “pre-installed” mode where the first user is able to configure the system like the openmrs setup wizard.
I do think that using (iii) is the only reasonably secure option when considering standalone desktop systems. Each user having his/her own password to the database rather than all users effectively sharing the one which is plaintext in hibernate.properties. But this does present enormous challenges of creating hibernate.sessions on the fly, when to run startup routines etc. This would probably require to request an admin password through a dialog when dhis2 is started which might or might not be reasonable depending on context.
I guess there are different security profiles which depend a lot on context which are really hard to take into account with a simple automated installer. Hence my taking the easy way out with h2. Will think about this later.
Cheers
Bob
OK. A separate database seems doable and would not make things less secure than today at least.
Reason for asking is that here in SA people are really used to the notion of “switching datafiles” during runtime, and they keep asking how to do it with 2. I have googled for similar experiences but it doesn’t seem to be many. Will think some more too.