New installer available: Testers wanted

Yeah, it is certainly possible, but this is not how the DHIS2 live app
is launched. It is not launched with a bat script.

So, if we want users to have a "double clickable" icon to start the
application and not a batch file, then it would need to occur from
within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob
has other comments.

Yes it can easily be part of the startup process but would require
some small tinkering. Something along the lines of "if there is a
startup.sh or startup.bat in ./scripts/ then exec that. Wait for that
to complete, capture status, and if all is well call the start method
on the webserver". Translated to java.

···

On 3 March 2010 09:49, Jason Pickering <jason.p.pickering@gmail.com> wrote:

The downside of this is that users may need the Postgres service
running anyway, for instance if they need to use the PivotTables
without having DHIS2 running.

I think a service is the best way to go at this point for the Desktop
install. It is not that much more complex to add a custom user and a
custom service. Comments welcome however.

On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring <knutst@gmail.com> wrote:

I'm pretty sure it is - and I think I did it (though I certainly also used
it as service). Looking through my bat scripts (attached) I see this line:
@@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data

On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering >> <jason.p.pickering@gmail.com> wrote:

Not installing postgres as a Windows service would remove a
significant amount of the complexity of the installation. If it could
be done, it would really be great. So, prior to launching jetty,
Postgres would need to be fired up manually. It is certainly worth
considering if this is possible.

On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe <bobjolliffe@gmail.com> >>> wrote:
> If we are committed to using the dhis2-live model for the desktop
> installs - with the tray icon+jetty+hibernate-points-to-whatever -
> then it makes sense to expand on our current lonely "exit" option to
> include others such as upgrading the war, updating the database and
> what have you. This is also a direction it seems the openmrs guys are
> considering taking with our approach. We can then build in as much or
> as little flexibility is desired. There are many rich maintenance use
> cases which we can deal with here rather than with an uber-smart
> installer. The important thing with the trayicon app is that it has
> full control over the webserver - so it could pause it, run psql or
> mysql scripts - unpause etc. Also manage hibernate connections
> through a nicer gui dialog than hand editing hibernate.properties.
> There's a list of maintenance tasks which we should consider. Given
> that it is easy for the app to read the hibernate.properties (and
> manage the webserver) it could also be possible to intelligently
> select between running pgdumps vs mysqldumps and restores and the
> like. My two cents. Anyone interested in doing a little bit of
> swing?
>
> Cheers
> Bob
>
> On 3 March 2010 08:27, Knut Staring <knutst@gmail.com> wrote:
>> A couple of comments:
>> While it maybe somewhat instructive to have a look at the Netbeans
>> installer, it was not targeted at Postgres and I doubt much of it would
>> be
>> transferable to BitRock.
>> Also, I really think we shouldn't waste our time trying to detect all
>> sorts
>> of things. Rather, there are two options:
>> 1) Create a nonstandard username for Postgres (i.e. not "postgres") and
>> run
>> it on a nonstandard port (i.e. not 5432). This should avoid 99% of
>> conflicts
>> 2) State very clearly in the docs and on dhis2.org that the FULL
>> installer
>> is for people who don't already have a database engine installed. If
>> you
>> already have Postgres, it would be much better to go with the minimal
>> installer, which is just DHIS2 Live and a few links in the menu. THEN
>> we add
>> clear instructions as to how to modify hibernate.properties, and all is
>> well.
>> Similar clear instructions for server installation, where the full
>> installer
>> would not be used would do the trick. I see very little value in
>> putting
>> more work into the installer at this point (beyond making Postgres an
>> option).
>> I agree with Lars that we should strongly promote Postgres over Mysql
>> (even
>> more so after Oracle's takeover). However, I think we should promote
>> the use
>> of H2 unless it is a server-type installation.
>> Knut
>>
>> On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering >>> >> <jason.p.pickering@gmail.com> wrote:
>>>
>>> Hi Saptarshi,
>>>
>>> It will certainly be a lot of effort, but nothing compared to the
>>> number of man hours devoted to DHIS2. If we cannot get this product
>>> installed on more peoples machine's, all of that development effort is
>>> just wasted. So, it is absolutely critical we get a good installer
>>> together, regardless of the effort that is required.
>>>
>>>
>>> Could you release what you did in NetBeans, and let others, like
>>> myself that are in need of a proper installer, learn from what has
>>> been done previously. Knut has provided valuable information to me
>>> with a previous BitRock installer that he was working on.
>>>
>>> I think there are ways to do this, but we will need to try and be a
>>> bit more clever. :slight_smile:
>>>
>>> Let me know what you think.
>>>
>>> Regards,
>>> Jason
>>>
>>>
>>> On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha >>> >>> <sunbiz@gmail.com> >>> >>> wrote:
>>> > This is what the Netbeans-based installer is doing... Infact it is
>>> > able
>>> > to
>>> > do that for Linux, Windows, Mac and Solaris from the beginning. It
>>> > was
>>> > able
>>> > to detect mysql and jre's installations on the system, tomcat was
>>> > not
>>> > detectable, which could have been detected from the registry or
>>> > services
>>> > like MySQL... but it was too much effort and I lost interest in
>>> > developing
>>> > that further...
>>> > Anyways, what happens when postgres/mysql/tomcat is already
>>> > installed
>>> > and
>>> > running?? The bitrock installer screwed a few things and I know ppl
>>> > just
>>> > uninstall it and all the data entered just goes... Possibly most
>>> > important
>>> > for an installer is to understand what's installed and not overwrite
>>> > anything, which is why msi is so good for Windows.
>>> >
>>> > ---
>>> > Regards,
>>> > Saptarshi PURKAYASTHA
>>> > Director R & D, HISP India
>>> > Health Information Systems Programme
>>> >
>>> > My Tech Blog: http://sunnytalkstech.blogspot.com
>>> > You Live by CHOICE, Not by CHANCE
>>> >
>>> >
>>> > 2010/3/2 Jason Pickering <jason.p.pickering@gmail.com>
>>> >>
>>> >> OK. A quick update.
>>> >>
>>> >> I managed to get DHIS+Postgres installed on a "clean" system,
>>> >> meaning
>>> >> one without a Postgres user or previous install Postgres instance.
>>> >> This is good, as this may be 90% of the cases we will encounter for
>>> >> a
>>> >> first time install, but it is only part of the problem.
>>> >>
>>> >> On a system with the postgres user already there, I do not know how
>>> >> to
>>> >> get the password in order to start the windows service, where the
>>> >> password needs to be set when the service is installed.
>>> >>
>>> >> This is not a big deal if you can start the postgres DB from the
>>> >> command line, but will users know to do this and-or can DHIS start
>>> >> it
>>> >> if it is not started. So, it will install a new instance of
>>> >> postgres,
>>> >> but, the service cannot be started, as the password is not correct.
>>> >> Hmm..maybe there are some bright ideas out there. Perhaps we can
>>> >> set
>>> >> it to the system account?
>>> >>
>>> >> So basically, I can release tomorrow for testing an installer that
>>> >> will install on system without a postgres user. I tried to install
>>> >> Postgres as a different user by creating a different user account,
>>> >> but
>>> >> the installer did not manage to create it. Will need some more work
>>> >> here.
>>> >>
>>> >> Let me know what you think.
>>> >>
>>> >> Regards,
>>> >> Jason
>>> >>
>>> >> _______________________________________________
>>> >> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> Post to : dhis2-devs@lists.launchpad.net
>>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> More help : https://help.launchpad.net/ListHelp
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> --
>>> Jason P. Pickering
>>> email: jason.p.pickering@gmail.com
>>> tel:+260968395190
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to : dhis2-devs@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

--
Cheers,
Knut Staring

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Yeah, it is certainly possible, but this is not how the DHIS2 live app
is launched. It is not launched with a bat script.

So, if we want users to have a "double clickable" icon to start the
application and not a batch file, then it would need to occur from
within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob
has other comments.

The downside of this is that users may need the Postgres service
running anyway, for instance if they need to use the PivotTables
without having DHIS2 running.

Well, could be a resource issue, of course - you'd rather not have Jetty eat
resources when not needed. On the other hand, the Postgres service would
always be running (assuming you set it to automatic). I don't think it would
be to onerous to ask a user to start DHIS2 before refreshing the Pivot
table, but the resource issue could be real.

One can easily enough implement stop the database, start the database,
stop the webserver, start the webserver as menu options from the tray.
But I can imagine this could be very confusing for users.

I think a service is the best way to go at this point for the Desktop
install. It is not that much more complex to add a custom user and a
custom service. Comments welcome however.

By far the best way to go longer term with the desktop install would
be to get first class citizenship for the h2 database. Which I
suspect largely means making the dxf dumps more complete.

···

On 3 March 2010 09:58, Knut Staring <knutst@gmail.com> wrote:

On Wed, Mar 3, 2010 at 10:49 AM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:

I say go with what is easiest for you. But I in general like the use of the
tray application, especially if we can get developers from OpenMRS working
on it. We could perhaps also use it for the Public Health Information
Toolkit (PHIT)
http://www.openhealthconsortium.org/wiki/doku.php?id=phit
The needs of many tools are very similar - even PHP apps like iHRIS perhaps,
if ran on Quercus http://quercus.caucho.com/ as Saptarshi has suggested. So
the Launcher/installer/updater could be factored out as a separate project,
perhaps (though I know you just merged the installer it with trunk....)
Knut

On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring <knutst@gmail.com> wrote:
> I'm pretty sure it is - and I think I did it (though I certainly also
> used
> it as service). Looking through my bat scripts (attached) I see this
> line:
> @@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data
>
>
> On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering >> > <jason.p.pickering@gmail.com> wrote:
>>
>> Not installing postgres as a Windows service would remove a
>> significant amount of the complexity of the installation. If it could
>> be done, it would really be great. So, prior to launching jetty,
>> Postgres would need to be fired up manually. It is certainly worth
>> considering if this is possible.
>>
>>
>>
>> On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe <bobjolliffe@gmail.com> >> >> wrote:
>> > If we are committed to using the dhis2-live model for the desktop
>> > installs - with the tray icon+jetty+hibernate-points-to-whatever -
>> > then it makes sense to expand on our current lonely "exit" option to
>> > include others such as upgrading the war, updating the database and
>> > what have you. This is also a direction it seems the openmrs guys
>> > are
>> > considering taking with our approach. We can then build in as much
>> > or
>> > as little flexibility is desired. There are many rich maintenance
>> > use
>> > cases which we can deal with here rather than with an uber-smart
>> > installer. The important thing with the trayicon app is that it has
>> > full control over the webserver - so it could pause it, run psql or
>> > mysql scripts - unpause etc. Also manage hibernate connections
>> > through a nicer gui dialog than hand editing hibernate.properties.
>> > There's a list of maintenance tasks which we should consider. Given
>> > that it is easy for the app to read the hibernate.properties (and
>> > manage the webserver) it could also be possible to intelligently
>> > select between running pgdumps vs mysqldumps and restores and the
>> > like. My two cents. Anyone interested in doing a little bit of
>> > swing?
>> >
>> > Cheers
>> > Bob
>> >
>> > On 3 March 2010 08:27, Knut Staring <knutst@gmail.com> wrote:
>> >> A couple of comments:
>> >> While it maybe somewhat instructive to have a look at the Netbeans
>> >> installer, it was not targeted at Postgres and I doubt much of it
>> >> would
>> >> be
>> >> transferable to BitRock.
>> >> Also, I really think we shouldn't waste our time trying to detect
>> >> all
>> >> sorts
>> >> of things. Rather, there are two options:
>> >> 1) Create a nonstandard username for Postgres (i.e. not "postgres")
>> >> and
>> >> run
>> >> it on a nonstandard port (i.e. not 5432). This should avoid 99% of
>> >> conflicts
>> >> 2) State very clearly in the docs and on dhis2.org that the FULL
>> >> installer
>> >> is for people who don't already have a database engine installed. If
>> >> you
>> >> already have Postgres, it would be much better to go with the
>> >> minimal
>> >> installer, which is just DHIS2 Live and a few links in the menu.
>> >> THEN
>> >> we add
>> >> clear instructions as to how to modify hibernate.properties, and all
>> >> is
>> >> well.
>> >> Similar clear instructions for server installation, where the full
>> >> installer
>> >> would not be used would do the trick. I see very little value in
>> >> putting
>> >> more work into the installer at this point (beyond making Postgres
>> >> an
>> >> option).
>> >> I agree with Lars that we should strongly promote Postgres over
>> >> Mysql
>> >> (even
>> >> more so after Oracle's takeover). However, I think we should promote
>> >> the use
>> >> of H2 unless it is a server-type installation.
>> >> Knut
>> >>
>> >> On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering >> >> >> <jason.p.pickering@gmail.com> wrote:
>> >>>
>> >>> Hi Saptarshi,
>> >>>
>> >>> It will certainly be a lot of effort, but nothing compared to the
>> >>> number of man hours devoted to DHIS2. If we cannot get this
>> >>> product
>> >>> installed on more peoples machine's, all of that development effort
>> >>> is
>> >>> just wasted. So, it is absolutely critical we get a good installer
>> >>> together, regardless of the effort that is required.
>> >>>
>> >>>
>> >>> Could you release what you did in NetBeans, and let others, like
>> >>> myself that are in need of a proper installer, learn from what has
>> >>> been done previously. Knut has provided valuable information to me
>> >>> with a previous BitRock installer that he was working on.
>> >>>
>> >>> I think there are ways to do this, but we will need to try and be a
>> >>> bit more clever. :slight_smile:
>> >>>
>> >>> Let me know what you think.
>> >>>
>> >>> Regards,
>> >>> Jason
>> >>>
>> >>>
>> >>> On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha >> >> >>> <sunbiz@gmail.com> >> >> >>> wrote:
>> >>> > This is what the Netbeans-based installer is doing... Infact it
>> >>> > is
>> >>> > able
>> >>> > to
>> >>> > do that for Linux, Windows, Mac and Solaris from the beginning.
>> >>> > It
>> >>> > was
>> >>> > able
>> >>> > to detect mysql and jre's installations on the system, tomcat was
>> >>> > not
>> >>> > detectable, which could have been detected from the registry or
>> >>> > services
>> >>> > like MySQL... but it was too much effort and I lost interest in
>> >>> > developing
>> >>> > that further...
>> >>> > Anyways, what happens when postgres/mysql/tomcat is already
>> >>> > installed
>> >>> > and
>> >>> > running?? The bitrock installer screwed a few things and I know
>> >>> > ppl
>> >>> > just
>> >>> > uninstall it and all the data entered just goes... Possibly most
>> >>> > important
>> >>> > for an installer is to understand what's installed and not
>> >>> > overwrite
>> >>> > anything, which is why msi is so good for Windows.
>> >>> >
>> >>> > ---
>> >>> > Regards,
>> >>> > Saptarshi PURKAYASTHA
>> >>> > Director R & D, HISP India
>> >>> > Health Information Systems Programme
>> >>> >
>> >>> > My Tech Blog: http://sunnytalkstech.blogspot.com
>> >>> > You Live by CHOICE, Not by CHANCE
>> >>> >
>> >>> >
>> >>> > 2010/3/2 Jason Pickering <jason.p.pickering@gmail.com>
>> >>> >>
>> >>> >> OK. A quick update.
>> >>> >>
>> >>> >> I managed to get DHIS+Postgres installed on a "clean" system,
>> >>> >> meaning
>> >>> >> one without a Postgres user or previous install Postgres
>> >>> >> instance.
>> >>> >> This is good, as this may be 90% of the cases we will encounter
>> >>> >> for
>> >>> >> a
>> >>> >> first time install, but it is only part of the problem.
>> >>> >>
>> >>> >> On a system with the postgres user already there, I do not know
>> >>> >> how
>> >>> >> to
>> >>> >> get the password in order to start the windows service, where
>> >>> >> the
>> >>> >> password needs to be set when the service is installed.
>> >>> >>
>> >>> >> This is not a big deal if you can start the postgres DB from
>> >>> >> the
>> >>> >> command line, but will users know to do this and-or can DHIS
>> >>> >> start
>> >>> >> it
>> >>> >> if it is not started. So, it will install a new instance of
>> >>> >> postgres,
>> >>> >> but, the service cannot be started, as the password is not
>> >>> >> correct.
>> >>> >> Hmm..maybe there are some bright ideas out there. Perhaps we can
>> >>> >> set
>> >>> >> it to the system account?
>> >>> >>
>> >>> >> So basically, I can release tomorrow for testing an installer
>> >>> >> that
>> >>> >> will install on system without a postgres user. I tried to
>> >>> >> install
>> >>> >> Postgres as a different user by creating a different user
>> >>> >> account,
>> >>> >> but
>> >>> >> the installer did not manage to create it. Will need some more
>> >>> >> work
>> >>> >> here.
>> >>> >>
>> >>> >> Let me know what you think.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Jason
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >>> >> Post to : dhis2-devs@lists.launchpad.net
>> >>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >>> >> More help : https://help.launchpad.net/ListHelp
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> --
>> >>> Jason P. Pickering
>> >>> email: jason.p.pickering@gmail.com
>> >>> tel:+260968395190
>> >>>
>> >>> _______________________________________________
>> >>> Mailing list: https://launchpad.net/~dhis2-devs
>> >>> Post to : dhis2-devs@lists.launchpad.net
>> >>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >>> More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Knut Staring
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to : dhis2-devs@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@gmail.com
>> tel:+260968395190
>
>
>
> --
> Cheers,
> Knut Staring
>

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

--
Cheers,
Knut Staring

I agree as well. It is confusing and might not work. There should
actually be a probably be config file, that the installer would write
to depending on the installation (or as you mention, read from the
hibernate.properties file to know if Postgres/MySQL) needs to be
started and then execute appropriate action to ensure they are. Right
now, I have constructed the installer to cater to either H2 or
Postgres installs, which then (not done yet) make changes to the
hibernate.properties files during the installation.

I agree about H2. I would be willing to trash Postgres completely for
desktop installs. It really is a lot of effort to get it running, and
the installation process is filled with pitfalls due to the security
requirements of Postgres. But, it is a good system, and there are
reasons for using it, so I do not think it should not be an option.

Regards,
JPP

···

On Wed, Mar 3, 2010 at 12:04 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 3 March 2010 09:58, Knut Staring <knutst@gmail.com> wrote:

On Wed, Mar 3, 2010 at 10:49 AM, Jason Pickering >> <jason.p.pickering@gmail.com> wrote:

Yeah, it is certainly possible, but this is not how the DHIS2 live app
is launched. It is not launched with a bat script.

So, if we want users to have a "double clickable" icon to start the
application and not a batch file, then it would need to occur from
within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob
has other comments.

The downside of this is that users may need the Postgres service
running anyway, for instance if they need to use the PivotTables
without having DHIS2 running.

Well, could be a resource issue, of course - you'd rather not have Jetty eat
resources when not needed. On the other hand, the Postgres service would
always be running (assuming you set it to automatic). I don't think it would
be to onerous to ask a user to start DHIS2 before refreshing the Pivot
table, but the resource issue could be real.

One can easily enough implement stop the database, start the database,
stop the webserver, start the webserver as menu options from the tray.
But I can imagine this could be very confusing for users.

I think a service is the best way to go at this point for the Desktop
install. It is not that much more complex to add a custom user and a
custom service. Comments welcome however.

By far the best way to go longer term with the desktop install would
be to get first class citizenship for the h2 database. Which I
suspect largely means making the dxf dumps more complete.

I say go with what is easiest for you. But I in general like the use of the
tray application, especially if we can get developers from OpenMRS working
on it. We could perhaps also use it for the Public Health Information
Toolkit (PHIT)
http://www.openhealthconsortium.org/wiki/doku.php?id=phit
The needs of many tools are very similar - even PHP apps like iHRIS perhaps,
if ran on Quercus http://quercus.caucho.com/ as Saptarshi has suggested. So
the Launcher/installer/updater could be factored out as a separate project,
perhaps (though I know you just merged the installer it with trunk....)
Knut

On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring <knutst@gmail.com> wrote:
> I'm pretty sure it is - and I think I did it (though I certainly also
> used
> it as service). Looking through my bat scripts (attached) I see this
> line:
> @@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data
>
>
> On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering >>> > <jason.p.pickering@gmail.com> wrote:
>>
>> Not installing postgres as a Windows service would remove a
>> significant amount of the complexity of the installation. If it could
>> be done, it would really be great. So, prior to launching jetty,
>> Postgres would need to be fired up manually. It is certainly worth
>> considering if this is possible.
>>
>>
>>
>> On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe <bobjolliffe@gmail.com> >>> >> wrote:
>> > If we are committed to using the dhis2-live model for the desktop
>> > installs - with the tray icon+jetty+hibernate-points-to-whatever -
>> > then it makes sense to expand on our current lonely "exit" option to
>> > include others such as upgrading the war, updating the database and
>> > what have you. This is also a direction it seems the openmrs guys
>> > are
>> > considering taking with our approach. We can then build in as much
>> > or
>> > as little flexibility is desired. There are many rich maintenance
>> > use
>> > cases which we can deal with here rather than with an uber-smart
>> > installer. The important thing with the trayicon app is that it has
>> > full control over the webserver - so it could pause it, run psql or
>> > mysql scripts - unpause etc. Also manage hibernate connections
>> > through a nicer gui dialog than hand editing hibernate.properties.
>> > There's a list of maintenance tasks which we should consider. Given
>> > that it is easy for the app to read the hibernate.properties (and
>> > manage the webserver) it could also be possible to intelligently
>> > select between running pgdumps vs mysqldumps and restores and the
>> > like. My two cents. Anyone interested in doing a little bit of
>> > swing?
>> >
>> > Cheers
>> > Bob
>> >
>> > On 3 March 2010 08:27, Knut Staring <knutst@gmail.com> wrote:
>> >> A couple of comments:
>> >> While it maybe somewhat instructive to have a look at the Netbeans
>> >> installer, it was not targeted at Postgres and I doubt much of it
>> >> would
>> >> be
>> >> transferable to BitRock.
>> >> Also, I really think we shouldn't waste our time trying to detect
>> >> all
>> >> sorts
>> >> of things. Rather, there are two options:
>> >> 1) Create a nonstandard username for Postgres (i.e. not "postgres")
>> >> and
>> >> run
>> >> it on a nonstandard port (i.e. not 5432). This should avoid 99% of
>> >> conflicts
>> >> 2) State very clearly in the docs and on dhis2.org that the FULL
>> >> installer
>> >> is for people who don't already have a database engine installed. If
>> >> you
>> >> already have Postgres, it would be much better to go with the
>> >> minimal
>> >> installer, which is just DHIS2 Live and a few links in the menu.
>> >> THEN
>> >> we add
>> >> clear instructions as to how to modify hibernate.properties, and all
>> >> is
>> >> well.
>> >> Similar clear instructions for server installation, where the full
>> >> installer
>> >> would not be used would do the trick. I see very little value in
>> >> putting
>> >> more work into the installer at this point (beyond making Postgres
>> >> an
>> >> option).
>> >> I agree with Lars that we should strongly promote Postgres over
>> >> Mysql
>> >> (even
>> >> more so after Oracle's takeover). However, I think we should promote
>> >> the use
>> >> of H2 unless it is a server-type installation.
>> >> Knut
>> >>
>> >> On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering >>> >> >> <jason.p.pickering@gmail.com> wrote:
>> >>>
>> >>> Hi Saptarshi,
>> >>>
>> >>> It will certainly be a lot of effort, but nothing compared to the
>> >>> number of man hours devoted to DHIS2. If we cannot get this
>> >>> product
>> >>> installed on more peoples machine's, all of that development effort
>> >>> is
>> >>> just wasted. So, it is absolutely critical we get a good installer
>> >>> together, regardless of the effort that is required.
>> >>>
>> >>>
>> >>> Could you release what you did in NetBeans, and let others, like
>> >>> myself that are in need of a proper installer, learn from what has
>> >>> been done previously. Knut has provided valuable information to me
>> >>> with a previous BitRock installer that he was working on.
>> >>>
>> >>> I think there are ways to do this, but we will need to try and be a
>> >>> bit more clever. :slight_smile:
>> >>>
>> >>> Let me know what you think.
>> >>>
>> >>> Regards,
>> >>> Jason
>> >>>
>> >>>
>> >>> On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha >>> >> >>> <sunbiz@gmail.com> >>> >> >>> wrote:
>> >>> > This is what the Netbeans-based installer is doing... Infact it
>> >>> > is
>> >>> > able
>> >>> > to
>> >>> > do that for Linux, Windows, Mac and Solaris from the beginning.
>> >>> > It
>> >>> > was
>> >>> > able
>> >>> > to detect mysql and jre's installations on the system, tomcat was
>> >>> > not
>> >>> > detectable, which could have been detected from the registry or
>> >>> > services
>> >>> > like MySQL... but it was too much effort and I lost interest in
>> >>> > developing
>> >>> > that further...
>> >>> > Anyways, what happens when postgres/mysql/tomcat is already
>> >>> > installed
>> >>> > and
>> >>> > running?? The bitrock installer screwed a few things and I know
>> >>> > ppl
>> >>> > just
>> >>> > uninstall it and all the data entered just goes... Possibly most
>> >>> > important
>> >>> > for an installer is to understand what's installed and not
>> >>> > overwrite
>> >>> > anything, which is why msi is so good for Windows.
>> >>> >
>> >>> > ---
>> >>> > Regards,
>> >>> > Saptarshi PURKAYASTHA
>> >>> > Director R & D, HISP India
>> >>> > Health Information Systems Programme
>> >>> >
>> >>> > My Tech Blog: http://sunnytalkstech.blogspot.com
>> >>> > You Live by CHOICE, Not by CHANCE
>> >>> >
>> >>> >
>> >>> > 2010/3/2 Jason Pickering <jason.p.pickering@gmail.com>
>> >>> >>
>> >>> >> OK. A quick update.
>> >>> >>
>> >>> >> I managed to get DHIS+Postgres installed on a "clean" system,
>> >>> >> meaning
>> >>> >> one without a Postgres user or previous install Postgres
>> >>> >> instance.
>> >>> >> This is good, as this may be 90% of the cases we will encounter
>> >>> >> for
>> >>> >> a
>> >>> >> first time install, but it is only part of the problem.
>> >>> >>
>> >>> >> On a system with the postgres user already there, I do not know
>> >>> >> how
>> >>> >> to
>> >>> >> get the password in order to start the windows service, where
>> >>> >> the
>> >>> >> password needs to be set when the service is installed.
>> >>> >>
>> >>> >> This is not a big deal if you can start the postgres DB from
>> >>> >> the
>> >>> >> command line, but will users know to do this and-or can DHIS
>> >>> >> start
>> >>> >> it
>> >>> >> if it is not started. So, it will install a new instance of
>> >>> >> postgres,
>> >>> >> but, the service cannot be started, as the password is not
>> >>> >> correct.
>> >>> >> Hmm..maybe there are some bright ideas out there. Perhaps we can
>> >>> >> set
>> >>> >> it to the system account?
>> >>> >>
>> >>> >> So basically, I can release tomorrow for testing an installer
>> >>> >> that
>> >>> >> will install on system without a postgres user. I tried to
>> >>> >> install
>> >>> >> Postgres as a different user by creating a different user
>> >>> >> account,
>> >>> >> but
>> >>> >> the installer did not manage to create it. Will need some more
>> >>> >> work
>> >>> >> here.
>> >>> >>
>> >>> >> Let me know what you think.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Jason
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >>> >> Post to : dhis2-devs@lists.launchpad.net
>> >>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >>> >> More help : https://help.launchpad.net/ListHelp
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> --
>> >>> Jason P. Pickering
>> >>> email: jason.p.pickering@gmail.com
>> >>> tel:+260968395190
>> >>>
>> >>> _______________________________________________
>> >>> Mailing list: https://launchpad.net/~dhis2-devs
>> >>> Post to : dhis2-devs@lists.launchpad.net
>> >>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >>> More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Knut Staring
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to : dhis2-devs@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@gmail.com
>> tel:+260968395190
>
>
>
> --
> Cheers,
> Knut Staring
>

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

--
Cheers,
Knut Staring

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

ok… since we are talking about Postgres and removing mysql support… has anyone seen that postgres on Windows is not actually a service and is started/stopped through a cygwin.

There are other things to consider about MySQL is the separation of storage engines and SQL. If MySQL with oracle is question then we could always use MariaDB (the full suite) or XtraDB as the engine.

···

Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

On 3 March 2010 11:20, Jason Pickering jason.p.pickering@gmail.com wrote:

I agree as well. It is confusing and might not work. There should

actually be a probably be config file, that the installer would write

to depending on the installation (or as you mention, read from the

hibernate.properties file to know if Postgres/MySQL) needs to be

started and then execute appropriate action to ensure they are. Right

now, I have constructed the installer to cater to either H2 or

Postgres installs, which then (not done yet) make changes to the

hibernate.properties files during the installation.

I agree about H2. I would be willing to trash Postgres completely for

desktop installs. It really is a lot of effort to get it running, and

the installation process is filled with pitfalls due to the security

requirements of Postgres. But, it is a good system, and there are

reasons for using it, so I do not think it should not be an option.

Regards,

JPP

On Wed, Mar 3, 2010 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

On 3 March 2010 09:58, Knut Staring knutst@gmail.com wrote:

On Wed, Mar 3, 2010 at 10:49 AM, Jason Pickering > > >> jason.p.pickering@gmail.com wrote:

Yeah, it is certainly possible, but this is not how the DHIS2 live app

is launched. It is not launched with a bat script.

So, if we want users to have a “double clickable” icon to start the

application and not a batch file, then it would need to occur from

within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob

has other comments.

The downside of this is that users may need the Postgres service

running anyway, for instance if they need to use the PivotTables

without having DHIS2 running.

Well, could be a resource issue, of course - you’d rather not have Jetty eat

resources when not needed. On the other hand, the Postgres service would

always be running (assuming you set it to automatic). I don’t think it would

be to onerous to ask a user to start DHIS2 before refreshing the Pivot

table, but the resource issue could be real.

One can easily enough implement stop the database, start the database,

stop the webserver, start the webserver as menu options from the tray.

But I can imagine this could be very confusing for users.

I think a service is the best way to go at this point for the Desktop

install. It is not that much more complex to add a custom user and a

custom service. Comments welcome however.

By far the best way to go longer term with the desktop install would

be to get first class citizenship for the h2 database. Which I

suspect largely means making the dxf dumps more complete.

I say go with what is easiest for you. But I in general like the use of the

tray application, especially if we can get developers from OpenMRS working

on it. We could perhaps also use it for the Public Health Information

Toolkit (PHIT)

http://www.openhealthconsortium.org/wiki/doku.php?id=phit

The needs of many tools are very similar - even PHP apps like iHRIS perhaps,

if ran on Quercus http://quercus.caucho.com/ as Saptarshi has suggested. So

the Launcher/installer/updater could be factored out as a separate project,

perhaps (though I know you just merged the installer it with trunk…)

Knut

On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring knutst@gmail.com wrote:

I’m pretty sure it is - and I think I did it (though I certainly also

used

it as service). Looking through my bat scripts (attached) I see this

line:

@@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data

On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering > > >>> > jason.p.pickering@gmail.com wrote:

Not installing postgres as a Windows service would remove a

significant amount of the complexity of the installation. If it could

be done, it would really be great. So, prior to launching jetty,

Postgres would need to be fired up manually. It is certainly worth

considering if this is possible.

On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe bobjolliffe@gmail.com > > >>> >> wrote:

If we are committed to using the dhis2-live model for the desktop

installs - with the tray icon+jetty+hibernate-points-to-whatever -

then it makes sense to expand on our current lonely “exit” option to

include others such as upgrading the war, updating the database and

what have you. This is also a direction it seems the openmrs guys

are

considering taking with our approach. We can then build in as much

or

as little flexibility is desired. There are many rich maintenance

use

cases which we can deal with here rather than with an uber-smart

installer. The important thing with the trayicon app is that it has

full control over the webserver - so it could pause it, run psql or

mysql scripts - unpause etc. Also manage hibernate connections

through a nicer gui dialog than hand editing hibernate.properties.

There’s a list of maintenance tasks which we should consider. Given

that it is easy for the app to read the hibernate.properties (and

manage the webserver) it could also be possible to intelligently

select between running pgdumps vs mysqldumps and restores and the

like. My two cents. Anyone interested in doing a little bit of

swing?

Cheers

Bob

On 3 March 2010 08:27, Knut Staring knutst@gmail.com wrote:

A couple of comments:

While it maybe somewhat instructive to have a look at the Netbeans

installer, it was not targeted at Postgres and I doubt much of it

would

be

transferable to BitRock.

Also, I really think we shouldn’t waste our time trying to detect

all

sorts

of things. Rather, there are two options:

  1. Create a nonstandard username for Postgres (i.e. not “postgres”)

and

run

it on a nonstandard port (i.e. not 5432). This should avoid 99% of

conflicts

  1. State very clearly in the docs and on dhis2.org that the FULL

installer

is for people who don’t already have a database engine installed. If

you

already have Postgres, it would be much better to go with the

minimal

installer, which is just DHIS2 Live and a few links in the menu.

THEN

we add

clear instructions as to how to modify hibernate.properties, and all

is

well.

Similar clear instructions for server installation, where the full

installer

would not be used would do the trick. I see very little value in

putting

more work into the installer at this point (beyond making Postgres

an

option).

I agree with Lars that we should strongly promote Postgres over

Mysql

(even

more so after Oracle’s takeover). However, I think we should promote

the use

of H2 unless it is a server-type installation.

Knut

On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering > > >>> >> >> jason.p.pickering@gmail.com wrote:

Hi Saptarshi,

It will certainly be a lot of effort, but nothing compared to the

number of man hours devoted to DHIS2. If we cannot get this

product

installed on more peoples machine’s, all of that development effort

is

just wasted. So, it is absolutely critical we get a good installer

together, regardless of the effort that is required.

Could you release what you did in NetBeans, and let others, like

myself that are in need of a proper installer, learn from what has

been done previously. Knut has provided valuable information to me

with a previous BitRock installer that he was working on.

I think there are ways to do this, but we will need to try and be a

bit more clever. :slight_smile:

Let me know what you think.

Regards,

Jason

On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha > > >>> >> >>> sunbiz@gmail.com > > >>> >> >>> wrote:

This is what the Netbeans-based installer is doing… Infact it

is

able

to

do that for Linux, Windows, Mac and Solaris from the beginning.

It

was

able

to detect mysql and jre’s installations on the system, tomcat was

not

detectable, which could have been detected from the registry or

services

like MySQL… but it was too much effort and I lost interest in

developing

that further…

Anyways, what happens when postgres/mysql/tomcat is already

installed

and

running?? The bitrock installer screwed a few things and I know

ppl

just

uninstall it and all the data entered just goes… Possibly most

important

for an installer is to understand what’s installed and not

overwrite

anything, which is why msi is so good for Windows.


Regards,

Saptarshi PURKAYASTHA

Director R & D, HISP India

Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

2010/3/2 Jason Pickering jason.p.pickering@gmail.com

OK. A quick update.

I managed to get DHIS+Postgres installed on a “clean” system,

meaning

one without a Postgres user or previous install Postgres

instance.

This is good, as this may be 90% of the cases we will encounter

for

a

first time install, but it is only part of the problem.

On a system with the postgres user already there, I do not know

how

to

get the password in order to start the windows service, where

the

password needs to be set when the service is installed.

This is not a big deal if you can start the postgres DB from

the

command line, but will users know to do this and-or can DHIS

start

it

if it is not started. So, it will install a new instance of

postgres,

but, the service cannot be started, as the password is not

correct.

Hmm…maybe there are some bright ideas out there. Perhaps we can

set

it to the system account?

So basically, I can release tomorrow for testing an installer

that

will install on system without a postgres user. I tried to

install

Postgres as a different user by creating a different user

account,

but

the installer did not manage to create it. Will need some more

work

here.

Let me know what you think.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Cheers,

Knut Staring


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190

Cheers,

Knut Staring

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190

Cheers,

Knut Staring

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

ok... since we are talking about Postgres and removing mysql support... has
anyone seen that postgres on Windows is not actually a service and is
started/stopped through a cygwin.
There are other things to consider about MySQL is the separation of storage
engines and SQL. If MySQL with oracle is question then we could always use
MariaDB (the full suite) or XtraDB as the engine.

nice to see the safety net - just in case :slight_smile: I don't think I have I
have heard anyone talk of dropping mysql support. I think that would
be grossly premature. Jason is trying to build an installer with
which bundle postgres. I am sure the same could be done with mysql.
As far as dhis2-live is concerned it is (so far) not dependent on any
of the three and I think it should remain that way.

···

On 3 March 2010 11:34, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

On 3 March 2010 11:20, Jason Pickering <jason.p.pickering@gmail.com> wrote:

I agree as well. It is confusing and might not work. There should
actually be a probably be config file, that the installer would write
to depending on the installation (or as you mention, read from the
hibernate.properties file to know if Postgres/MySQL) needs to be
started and then execute appropriate action to ensure they are. Right
now, I have constructed the installer to cater to either H2 or
Postgres installs, which then (not done yet) make changes to the
hibernate.properties files during the installation.

I agree about H2. I would be willing to trash Postgres completely for
desktop installs. It really is a lot of effort to get it running, and
the installation process is filled with pitfalls due to the security
requirements of Postgres. But, it is a good system, and there are
reasons for using it, so I do not think it should not be an option.

Regards,
JPP

On Wed, Mar 3, 2010 at 12:04 PM, Bob Jolliffe <bobjolliffe@gmail.com> >> wrote:
> On 3 March 2010 09:58, Knut Staring <knutst@gmail.com> wrote:
>> On Wed, Mar 3, 2010 at 10:49 AM, Jason Pickering >> >> <jason.p.pickering@gmail.com> wrote:
>>>
>>> Yeah, it is certainly possible, but this is not how the DHIS2 live app
>>> is launched. It is not launched with a bat script.
>>>
>>> So, if we want users to have a "double clickable" icon to start the
>>> application and not a batch file, then it would need to occur from
>>> within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob
>>> has other comments.
>>>
>>> The downside of this is that users may need the Postgres service
>>> running anyway, for instance if they need to use the PivotTables
>>> without having DHIS2 running.
>>>
>>
>> Well, could be a resource issue, of course - you'd rather not have
>> Jetty eat
>> resources when not needed. On the other hand, the Postgres service
>> would
>> always be running (assuming you set it to automatic). I don't think it
>> would
>> be to onerous to ask a user to start DHIS2 before refreshing the Pivot
>> table, but the resource issue could be real.
>>
>
> One can easily enough implement stop the database, start the database,
> stop the webserver, start the webserver as menu options from the tray.
> But I can imagine this could be very confusing for users.
>
>>>
>>> I think a service is the best way to go at this point for the Desktop
>>> install. It is not that much more complex to add a custom user and a
>>> custom service. Comments welcome however.
>
> By far the best way to go longer term with the desktop install would
> be to get first class citizenship for the h2 database. Which I
> suspect largely means making the dxf dumps more complete.
>
>>
>> I say go with what is easiest for you. But I in general like the use of
>> the
>> tray application, especially if we can get developers from OpenMRS
>> working
>> on it. We could perhaps also use it for the Public Health Information
>> Toolkit (PHIT)
>> http://www.openhealthconsortium.org/wiki/doku.php?id=phit
>> The needs of many tools are very similar - even PHP apps like iHRIS
>> perhaps,
>> if ran on Quercus http://quercus.caucho.com/ as Saptarshi has
>> suggested. So
>> the Launcher/installer/updater could be factored out as a separate
>> project,
>> perhaps (though I know you just merged the installer it with trunk....)
>> Knut
>>>
>>> On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring <knutst@gmail.com> >> >>> wrote:
>>> > I'm pretty sure it is - and I think I did it (though I certainly
>>> > also
>>> > used
>>> > it as service). Looking through my bat scripts (attached) I see this
>>> > line:
>>> > @@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data
>>> >
>>> >
>>> > On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering >> >>> > <jason.p.pickering@gmail.com> wrote:
>>> >>
>>> >> Not installing postgres as a Windows service would remove a
>>> >> significant amount of the complexity of the installation. If it
>>> >> could
>>> >> be done, it would really be great. So, prior to launching jetty,
>>> >> Postgres would need to be fired up manually. It is certainly worth
>>> >> considering if this is possible.
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe >> >>> >> <bobjolliffe@gmail.com> >> >>> >> wrote:
>>> >> > If we are committed to using the dhis2-live model for the desktop
>>> >> > installs - with the tray icon+jetty+hibernate-points-to-whatever
>>> >> > -
>>> >> > then it makes sense to expand on our current lonely "exit" option
>>> >> > to
>>> >> > include others such as upgrading the war, updating the database
>>> >> > and
>>> >> > what have you. This is also a direction it seems the openmrs
>>> >> > guys
>>> >> > are
>>> >> > considering taking with our approach. We can then build in as
>>> >> > much
>>> >> > or
>>> >> > as little flexibility is desired. There are many rich
>>> >> > maintenance
>>> >> > use
>>> >> > cases which we can deal with here rather than with an uber-smart
>>> >> > installer. The important thing with the trayicon app is that it
>>> >> > has
>>> >> > full control over the webserver - so it could pause it, run psql
>>> >> > or
>>> >> > mysql scripts - unpause etc. Also manage hibernate connections
>>> >> > through a nicer gui dialog than hand editing
>>> >> > hibernate.properties.
>>> >> > There's a list of maintenance tasks which we should consider.
>>> >> > Given
>>> >> > that it is easy for the app to read the hibernate.properties (and
>>> >> > manage the webserver) it could also be possible to intelligently
>>> >> > select between running pgdumps vs mysqldumps and restores and the
>>> >> > like. My two cents. Anyone interested in doing a little bit of
>>> >> > swing?
>>> >> >
>>> >> > Cheers
>>> >> > Bob
>>> >> >
>>> >> > On 3 March 2010 08:27, Knut Staring <knutst@gmail.com> wrote:
>>> >> >> A couple of comments:
>>> >> >> While it maybe somewhat instructive to have a look at the
>>> >> >> Netbeans
>>> >> >> installer, it was not targeted at Postgres and I doubt much of
>>> >> >> it
>>> >> >> would
>>> >> >> be
>>> >> >> transferable to BitRock.
>>> >> >> Also, I really think we shouldn't waste our time trying to
>>> >> >> detect
>>> >> >> all
>>> >> >> sorts
>>> >> >> of things. Rather, there are two options:
>>> >> >> 1) Create a nonstandard username for Postgres (i.e. not
>>> >> >> "postgres")
>>> >> >> and
>>> >> >> run
>>> >> >> it on a nonstandard port (i.e. not 5432). This should avoid 99%
>>> >> >> of
>>> >> >> conflicts
>>> >> >> 2) State very clearly in the docs and on dhis2.org that the FULL
>>> >> >> installer
>>> >> >> is for people who don't already have a database engine
>>> >> >> installed. If
>>> >> >> you
>>> >> >> already have Postgres, it would be much better to go with the
>>> >> >> minimal
>>> >> >> installer, which is just DHIS2 Live and a few links in the menu.
>>> >> >> THEN
>>> >> >> we add
>>> >> >> clear instructions as to how to modify hibernate.properties, and
>>> >> >> all
>>> >> >> is
>>> >> >> well.
>>> >> >> Similar clear instructions for server installation, where the
>>> >> >> full
>>> >> >> installer
>>> >> >> would not be used would do the trick. I see very little value in
>>> >> >> putting
>>> >> >> more work into the installer at this point (beyond making
>>> >> >> Postgres
>>> >> >> an
>>> >> >> option).
>>> >> >> I agree with Lars that we should strongly promote Postgres over
>>> >> >> Mysql
>>> >> >> (even
>>> >> >> more so after Oracle's takeover). However, I think we should
>>> >> >> promote
>>> >> >> the use
>>> >> >> of H2 unless it is a server-type installation.
>>> >> >> Knut
>>> >> >>
>>> >> >> On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering >> >>> >> >> <jason.p.pickering@gmail.com> wrote:
>>> >> >>>
>>> >> >>> Hi Saptarshi,
>>> >> >>>
>>> >> >>> It will certainly be a lot of effort, but nothing compared to
>>> >> >>> the
>>> >> >>> number of man hours devoted to DHIS2. If we cannot get this
>>> >> >>> product
>>> >> >>> installed on more peoples machine's, all of that development
>>> >> >>> effort
>>> >> >>> is
>>> >> >>> just wasted. So, it is absolutely critical we get a good
>>> >> >>> installer
>>> >> >>> together, regardless of the effort that is required.
>>> >> >>>
>>> >> >>>
>>> >> >>> Could you release what you did in NetBeans, and let others,
>>> >> >>> like
>>> >> >>> myself that are in need of a proper installer, learn from what
>>> >> >>> has
>>> >> >>> been done previously. Knut has provided valuable information to
>>> >> >>> me
>>> >> >>> with a previous BitRock installer that he was working on.
>>> >> >>>
>>> >> >>> I think there are ways to do this, but we will need to try and
>>> >> >>> be a
>>> >> >>> bit more clever. :slight_smile:
>>> >> >>>
>>> >> >>> Let me know what you think.
>>> >> >>>
>>> >> >>> Regards,
>>> >> >>> Jason
>>> >> >>>
>>> >> >>>
>>> >> >>> On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha >> >>> >> >>> <sunbiz@gmail.com> >> >>> >> >>> wrote:
>>> >> >>> > This is what the Netbeans-based installer is doing... Infact
>>> >> >>> > it
>>> >> >>> > is
>>> >> >>> > able
>>> >> >>> > to
>>> >> >>> > do that for Linux, Windows, Mac and Solaris from
>>> >> >>> > the beginning.
>>> >> >>> > It
>>> >> >>> > was
>>> >> >>> > able
>>> >> >>> > to detect mysql and jre's installations on the system, tomcat
>>> >> >>> > was
>>> >> >>> > not
>>> >> >>> > detectable, which could have been detected from the registry
>>> >> >>> > or
>>> >> >>> > services
>>> >> >>> > like MySQL... but it was too much effort and I lost interest
>>> >> >>> > in
>>> >> >>> > developing
>>> >> >>> > that further...
>>> >> >>> > Anyways, what happens when postgres/mysql/tomcat is already
>>> >> >>> > installed
>>> >> >>> > and
>>> >> >>> > running?? The bitrock installer screwed a few things and I
>>> >> >>> > know
>>> >> >>> > ppl
>>> >> >>> > just
>>> >> >>> > uninstall it and all the data entered just goes... Possibly
>>> >> >>> > most
>>> >> >>> > important
>>> >> >>> > for an installer is to understand what's installed and not
>>> >> >>> > overwrite
>>> >> >>> > anything, which is why msi is so good for Windows.
>>> >> >>> >
>>> >> >>> > ---
>>> >> >>> > Regards,
>>> >> >>> > Saptarshi PURKAYASTHA
>>> >> >>> > Director R & D, HISP India
>>> >> >>> > Health Information Systems Programme
>>> >> >>> >
>>> >> >>> > My Tech Blog: http://sunnytalkstech.blogspot.com
>>> >> >>> > You Live by CHOICE, Not by CHANCE
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > 2010/3/2 Jason Pickering <jason.p.pickering@gmail.com>
>>> >> >>> >>
>>> >> >>> >> OK. A quick update.
>>> >> >>> >>
>>> >> >>> >> I managed to get DHIS+Postgres installed on a "clean"
>>> >> >>> >> system,
>>> >> >>> >> meaning
>>> >> >>> >> one without a Postgres user or previous install Postgres
>>> >> >>> >> instance.
>>> >> >>> >> This is good, as this may be 90% of the cases we will
>>> >> >>> >> encounter
>>> >> >>> >> for
>>> >> >>> >> a
>>> >> >>> >> first time install, but it is only part of the problem.
>>> >> >>> >>
>>> >> >>> >> On a system with the postgres user already there, I do not
>>> >> >>> >> know
>>> >> >>> >> how
>>> >> >>> >> to
>>> >> >>> >> get the password in order to start the windows service,
>>> >> >>> >> where
>>> >> >>> >> the
>>> >> >>> >> password needs to be set when the service is installed.
>>> >> >>> >>
>>> >> >>> >> This is not a big deal if you can start the postgres DB
>>> >> >>> >> from
>>> >> >>> >> the
>>> >> >>> >> command line, but will users know to do this and-or can DHIS
>>> >> >>> >> start
>>> >> >>> >> it
>>> >> >>> >> if it is not started. So, it will install a new instance of
>>> >> >>> >> postgres,
>>> >> >>> >> but, the service cannot be started, as the password is not
>>> >> >>> >> correct.
>>> >> >>> >> Hmm..maybe there are some bright ideas out there. Perhaps we
>>> >> >>> >> can
>>> >> >>> >> set
>>> >> >>> >> it to the system account?
>>> >> >>> >>
>>> >> >>> >> So basically, I can release tomorrow for testing an
>>> >> >>> >> installer
>>> >> >>> >> that
>>> >> >>> >> will install on system without a postgres user. I tried to
>>> >> >>> >> install
>>> >> >>> >> Postgres as a different user by creating a different user
>>> >> >>> >> account,
>>> >> >>> >> but
>>> >> >>> >> the installer did not manage to create it. Will need some
>>> >> >>> >> more
>>> >> >>> >> work
>>> >> >>> >> here.
>>> >> >>> >>
>>> >> >>> >> Let me know what you think.
>>> >> >>> >>
>>> >> >>> >> Regards,
>>> >> >>> >> Jason
>>> >> >>> >>
>>> >> >>> >> _______________________________________________
>>> >> >>> >> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >>> >> Post to : dhis2-devs@lists.launchpad.net
>>> >> >>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >>> >> More help : https://help.launchpad.net/ListHelp
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> --
>>> >> >>> Jason P. Pickering
>>> >> >>> email: jason.p.pickering@gmail.com
>>> >> >>> tel:+260968395190
>>> >> >>>
>>> >> >>> _______________________________________________
>>> >> >>> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >>> Post to : dhis2-devs@lists.launchpad.net
>>> >> >>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >>> More help : https://help.launchpad.net/ListHelp
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cheers,
>>> >> >> Knut Staring
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >> Post to : dhis2-devs@lists.launchpad.net
>>> >> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >> More help : https://help.launchpad.net/ListHelp
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> --
>>> >> Jason P. Pickering
>>> >> email: jason.p.pickering@gmail.com
>>> >> tel:+260968395190
>>> >
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> > Knut Staring
>>> >
>>>
>>>
>>>
>>> --
>>> --
>>> Jason P. Pickering
>>> email: jason.p.pickering@gmail.com
>>> tel:+260968395190
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>>
>

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Hi there.

First of all, Postgres is installed as a native windows service.
Cygwin is not involved. Postgres does not NEED to be run as a service,
but there are some pros/cons about doing this way. A big con is that
you need administrative access to the machine (which the Postgres
installer will require). However, there are different ways of doing
it.

Second, we would love to add MySQL support. I certainly do not think
there is any talk of removing MySQL support from DHIS2. We are only
discussing the installer itself. If you want to include MySQL, then
check out the main branch, and start editing the installer to include
it. This is why I have committed the installer source itself to the
main branch, so we can collaborate together on a common installer.

Lastly, I suspect that we may have a range of installers, and many of
them suited to particular implementations. BitRock is an ideal tool
for this, and we have been granted a license (which I can provide to
any one that wants it) for their own installer builds for DHIS2. I
have constructed the installer as a maven project in such a way that
it will gather up the required resources during the build (dhis.war,
dhis2-live.exe) which in turn themselves are dynamically generated
during the build process. The idea being that when 2.0.4 is released,
we will have an installer instead of a WAR file. All that is required
is a few modifications to the pom.xml in the installer source.

Hope this clarifies this a bit..

Regards,
Jason

···

On Wed, Mar 3, 2010 at 1:43 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 3 March 2010 11:34, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:

ok... since we are talking about Postgres and removing mysql support... has
anyone seen that postgres on Windows is not actually a service and is
started/stopped through a cygwin.
There are other things to consider about MySQL is the separation of storage
engines and SQL. If MySQL with oracle is question then we could always use
MariaDB (the full suite) or XtraDB as the engine.

nice to see the safety net - just in case :slight_smile: I don't think I have I
have heard anyone talk of dropping mysql support. I think that would
be grossly premature. Jason is trying to build an installer with
which bundle postgres. I am sure the same could be done with mysql.
As far as dhis2-live is concerned it is (so far) not dependent on any
of the three and I think it should remain that way.

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

On 3 March 2010 11:20, Jason Pickering <jason.p.pickering@gmail.com> wrote:

I agree as well. It is confusing and might not work. There should
actually be a probably be config file, that the installer would write
to depending on the installation (or as you mention, read from the
hibernate.properties file to know if Postgres/MySQL) needs to be
started and then execute appropriate action to ensure they are. Right
now, I have constructed the installer to cater to either H2 or
Postgres installs, which then (not done yet) make changes to the
hibernate.properties files during the installation.

I agree about H2. I would be willing to trash Postgres completely for
desktop installs. It really is a lot of effort to get it running, and
the installation process is filled with pitfalls due to the security
requirements of Postgres. But, it is a good system, and there are
reasons for using it, so I do not think it should not be an option.

Regards,
JPP

On Wed, Mar 3, 2010 at 12:04 PM, Bob Jolliffe <bobjolliffe@gmail.com> >>> wrote:
> On 3 March 2010 09:58, Knut Staring <knutst@gmail.com> wrote:
>> On Wed, Mar 3, 2010 at 10:49 AM, Jason Pickering >>> >> <jason.p.pickering@gmail.com> wrote:
>>>
>>> Yeah, it is certainly possible, but this is not how the DHIS2 live app
>>> is launched. It is not launched with a bat script.
>>>
>>> So, if we want users to have a "double clickable" icon to start the
>>> application and not a batch file, then it would need to occur from
>>> within the DHIS2 Live EXE itself. That is how I see it, but maybe Bob
>>> has other comments.
>>>
>>> The downside of this is that users may need the Postgres service
>>> running anyway, for instance if they need to use the PivotTables
>>> without having DHIS2 running.
>>>
>>
>> Well, could be a resource issue, of course - you'd rather not have
>> Jetty eat
>> resources when not needed. On the other hand, the Postgres service
>> would
>> always be running (assuming you set it to automatic). I don't think it
>> would
>> be to onerous to ask a user to start DHIS2 before refreshing the Pivot
>> table, but the resource issue could be real.
>>
>
> One can easily enough implement stop the database, start the database,
> stop the webserver, start the webserver as menu options from the tray.
> But I can imagine this could be very confusing for users.
>
>>>
>>> I think a service is the best way to go at this point for the Desktop
>>> install. It is not that much more complex to add a custom user and a
>>> custom service. Comments welcome however.
>
> By far the best way to go longer term with the desktop install would
> be to get first class citizenship for the h2 database. Which I
> suspect largely means making the dxf dumps more complete.
>
>>
>> I say go with what is easiest for you. But I in general like the use of
>> the
>> tray application, especially if we can get developers from OpenMRS
>> working
>> on it. We could perhaps also use it for the Public Health Information
>> Toolkit (PHIT)
>> http://www.openhealthconsortium.org/wiki/doku.php?id=phit
>> The needs of many tools are very similar - even PHP apps like iHRIS
>> perhaps,
>> if ran on Quercus http://quercus.caucho.com/ as Saptarshi has
>> suggested. So
>> the Launcher/installer/updater could be factored out as a separate
>> project,
>> perhaps (though I know you just merged the installer it with trunk....)
>> Knut
>>>
>>> On Wed, Mar 3, 2010 at 11:45 AM, Knut Staring <knutst@gmail.com> >>> >>> wrote:
>>> > I'm pretty sure it is - and I think I did it (though I certainly
>>> > also
>>> > used
>>> > it as service). Looking through my bat scripts (attached) I see this
>>> > line:
>>> > @@DHIS2DIR@@\pgsql\bin\pg_ctl start -D @@DHIS2DIR@@\pgsql\data
>>> >
>>> >
>>> > On Wed, Mar 3, 2010 at 10:35 AM, Jason Pickering >>> >>> > <jason.p.pickering@gmail.com> wrote:
>>> >>
>>> >> Not installing postgres as a Windows service would remove a
>>> >> significant amount of the complexity of the installation. If it
>>> >> could
>>> >> be done, it would really be great. So, prior to launching jetty,
>>> >> Postgres would need to be fired up manually. It is certainly worth
>>> >> considering if this is possible.
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Mar 3, 2010 at 11:31 AM, Bob Jolliffe >>> >>> >> <bobjolliffe@gmail.com> >>> >>> >> wrote:
>>> >> > If we are committed to using the dhis2-live model for the desktop
>>> >> > installs - with the tray icon+jetty+hibernate-points-to-whatever
>>> >> > -
>>> >> > then it makes sense to expand on our current lonely "exit" option
>>> >> > to
>>> >> > include others such as upgrading the war, updating the database
>>> >> > and
>>> >> > what have you. This is also a direction it seems the openmrs
>>> >> > guys
>>> >> > are
>>> >> > considering taking with our approach. We can then build in as
>>> >> > much
>>> >> > or
>>> >> > as little flexibility is desired. There are many rich
>>> >> > maintenance
>>> >> > use
>>> >> > cases which we can deal with here rather than with an uber-smart
>>> >> > installer. The important thing with the trayicon app is that it
>>> >> > has
>>> >> > full control over the webserver - so it could pause it, run psql
>>> >> > or
>>> >> > mysql scripts - unpause etc. Also manage hibernate connections
>>> >> > through a nicer gui dialog than hand editing
>>> >> > hibernate.properties.
>>> >> > There's a list of maintenance tasks which we should consider.
>>> >> > Given
>>> >> > that it is easy for the app to read the hibernate.properties (and
>>> >> > manage the webserver) it could also be possible to intelligently
>>> >> > select between running pgdumps vs mysqldumps and restores and the
>>> >> > like. My two cents. Anyone interested in doing a little bit of
>>> >> > swing?
>>> >> >
>>> >> > Cheers
>>> >> > Bob
>>> >> >
>>> >> > On 3 March 2010 08:27, Knut Staring <knutst@gmail.com> wrote:
>>> >> >> A couple of comments:
>>> >> >> While it maybe somewhat instructive to have a look at the
>>> >> >> Netbeans
>>> >> >> installer, it was not targeted at Postgres and I doubt much of
>>> >> >> it
>>> >> >> would
>>> >> >> be
>>> >> >> transferable to BitRock.
>>> >> >> Also, I really think we shouldn't waste our time trying to
>>> >> >> detect
>>> >> >> all
>>> >> >> sorts
>>> >> >> of things. Rather, there are two options:
>>> >> >> 1) Create a nonstandard username for Postgres (i.e. not
>>> >> >> "postgres")
>>> >> >> and
>>> >> >> run
>>> >> >> it on a nonstandard port (i.e. not 5432). This should avoid 99%
>>> >> >> of
>>> >> >> conflicts
>>> >> >> 2) State very clearly in the docs and on dhis2.org that the FULL
>>> >> >> installer
>>> >> >> is for people who don't already have a database engine
>>> >> >> installed. If
>>> >> >> you
>>> >> >> already have Postgres, it would be much better to go with the
>>> >> >> minimal
>>> >> >> installer, which is just DHIS2 Live and a few links in the menu.
>>> >> >> THEN
>>> >> >> we add
>>> >> >> clear instructions as to how to modify hibernate.properties, and
>>> >> >> all
>>> >> >> is
>>> >> >> well.
>>> >> >> Similar clear instructions for server installation, where the
>>> >> >> full
>>> >> >> installer
>>> >> >> would not be used would do the trick. I see very little value in
>>> >> >> putting
>>> >> >> more work into the installer at this point (beyond making
>>> >> >> Postgres
>>> >> >> an
>>> >> >> option).
>>> >> >> I agree with Lars that we should strongly promote Postgres over
>>> >> >> Mysql
>>> >> >> (even
>>> >> >> more so after Oracle's takeover). However, I think we should
>>> >> >> promote
>>> >> >> the use
>>> >> >> of H2 unless it is a server-type installation.
>>> >> >> Knut
>>> >> >>
>>> >> >> On Wed, Mar 3, 2010 at 6:01 AM, Jason Pickering >>> >>> >> >> <jason.p.pickering@gmail.com> wrote:
>>> >> >>>
>>> >> >>> Hi Saptarshi,
>>> >> >>>
>>> >> >>> It will certainly be a lot of effort, but nothing compared to
>>> >> >>> the
>>> >> >>> number of man hours devoted to DHIS2. If we cannot get this
>>> >> >>> product
>>> >> >>> installed on more peoples machine's, all of that development
>>> >> >>> effort
>>> >> >>> is
>>> >> >>> just wasted. So, it is absolutely critical we get a good
>>> >> >>> installer
>>> >> >>> together, regardless of the effort that is required.
>>> >> >>>
>>> >> >>>
>>> >> >>> Could you release what you did in NetBeans, and let others,
>>> >> >>> like
>>> >> >>> myself that are in need of a proper installer, learn from what
>>> >> >>> has
>>> >> >>> been done previously. Knut has provided valuable information to
>>> >> >>> me
>>> >> >>> with a previous BitRock installer that he was working on.
>>> >> >>>
>>> >> >>> I think there are ways to do this, but we will need to try and
>>> >> >>> be a
>>> >> >>> bit more clever. :slight_smile:
>>> >> >>>
>>> >> >>> Let me know what you think.
>>> >> >>>
>>> >> >>> Regards,
>>> >> >>> Jason
>>> >> >>>
>>> >> >>>
>>> >> >>> On Tue, Mar 2, 2010 at 8:29 PM, Saptarshi Purkayastha >>> >>> >> >>> <sunbiz@gmail.com> >>> >>> >> >>> wrote:
>>> >> >>> > This is what the Netbeans-based installer is doing... Infact
>>> >> >>> > it
>>> >> >>> > is
>>> >> >>> > able
>>> >> >>> > to
>>> >> >>> > do that for Linux, Windows, Mac and Solaris from
>>> >> >>> > the beginning.
>>> >> >>> > It
>>> >> >>> > was
>>> >> >>> > able
>>> >> >>> > to detect mysql and jre's installations on the system, tomcat
>>> >> >>> > was
>>> >> >>> > not
>>> >> >>> > detectable, which could have been detected from the registry
>>> >> >>> > or
>>> >> >>> > services
>>> >> >>> > like MySQL... but it was too much effort and I lost interest
>>> >> >>> > in
>>> >> >>> > developing
>>> >> >>> > that further...
>>> >> >>> > Anyways, what happens when postgres/mysql/tomcat is already
>>> >> >>> > installed
>>> >> >>> > and
>>> >> >>> > running?? The bitrock installer screwed a few things and I
>>> >> >>> > know
>>> >> >>> > ppl
>>> >> >>> > just
>>> >> >>> > uninstall it and all the data entered just goes... Possibly
>>> >> >>> > most
>>> >> >>> > important
>>> >> >>> > for an installer is to understand what's installed and not
>>> >> >>> > overwrite
>>> >> >>> > anything, which is why msi is so good for Windows.
>>> >> >>> >
>>> >> >>> > ---
>>> >> >>> > Regards,
>>> >> >>> > Saptarshi PURKAYASTHA
>>> >> >>> > Director R & D, HISP India
>>> >> >>> > Health Information Systems Programme
>>> >> >>> >
>>> >> >>> > My Tech Blog: http://sunnytalkstech.blogspot.com
>>> >> >>> > You Live by CHOICE, Not by CHANCE
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > 2010/3/2 Jason Pickering <jason.p.pickering@gmail.com>
>>> >> >>> >>
>>> >> >>> >> OK. A quick update.
>>> >> >>> >>
>>> >> >>> >> I managed to get DHIS+Postgres installed on a "clean"
>>> >> >>> >> system,
>>> >> >>> >> meaning
>>> >> >>> >> one without a Postgres user or previous install Postgres
>>> >> >>> >> instance.
>>> >> >>> >> This is good, as this may be 90% of the cases we will
>>> >> >>> >> encounter
>>> >> >>> >> for
>>> >> >>> >> a
>>> >> >>> >> first time install, but it is only part of the problem.
>>> >> >>> >>
>>> >> >>> >> On a system with the postgres user already there, I do not
>>> >> >>> >> know
>>> >> >>> >> how
>>> >> >>> >> to
>>> >> >>> >> get the password in order to start the windows service,
>>> >> >>> >> where
>>> >> >>> >> the
>>> >> >>> >> password needs to be set when the service is installed.
>>> >> >>> >>
>>> >> >>> >> This is not a big deal if you can start the postgres DB
>>> >> >>> >> from
>>> >> >>> >> the
>>> >> >>> >> command line, but will users know to do this and-or can DHIS
>>> >> >>> >> start
>>> >> >>> >> it
>>> >> >>> >> if it is not started. So, it will install a new instance of
>>> >> >>> >> postgres,
>>> >> >>> >> but, the service cannot be started, as the password is not
>>> >> >>> >> correct.
>>> >> >>> >> Hmm..maybe there are some bright ideas out there. Perhaps we
>>> >> >>> >> can
>>> >> >>> >> set
>>> >> >>> >> it to the system account?
>>> >> >>> >>
>>> >> >>> >> So basically, I can release tomorrow for testing an
>>> >> >>> >> installer
>>> >> >>> >> that
>>> >> >>> >> will install on system without a postgres user. I tried to
>>> >> >>> >> install
>>> >> >>> >> Postgres as a different user by creating a different user
>>> >> >>> >> account,
>>> >> >>> >> but
>>> >> >>> >> the installer did not manage to create it. Will need some
>>> >> >>> >> more
>>> >> >>> >> work
>>> >> >>> >> here.
>>> >> >>> >>
>>> >> >>> >> Let me know what you think.
>>> >> >>> >>
>>> >> >>> >> Regards,
>>> >> >>> >> Jason
>>> >> >>> >>
>>> >> >>> >> _______________________________________________
>>> >> >>> >> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >>> >> Post to : dhis2-devs@lists.launchpad.net
>>> >> >>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >>> >> More help : https://help.launchpad.net/ListHelp
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> --
>>> >> >>> Jason P. Pickering
>>> >> >>> email: jason.p.pickering@gmail.com
>>> >> >>> tel:+260968395190
>>> >> >>>
>>> >> >>> _______________________________________________
>>> >> >>> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >>> Post to : dhis2-devs@lists.launchpad.net
>>> >> >>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >>> More help : https://help.launchpad.net/ListHelp
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cheers,
>>> >> >> Knut Staring
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Mailing list: https://launchpad.net/~dhis2-devs
>>> >> >> Post to : dhis2-devs@lists.launchpad.net
>>> >> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> >> >> More help : https://help.launchpad.net/ListHelp
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> --
>>> >> Jason P. Pickering
>>> >> email: jason.p.pickering@gmail.com
>>> >> tel:+260968395190
>>> >
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> > Knut Staring
>>> >
>>>
>>>
>>>
>>> --
>>> --
>>> Jason P. Pickering
>>> email: jason.p.pickering@gmail.com
>>> tel:+260968395190
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>>
>

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Is the service part of EnterpriseDB?? Because the windows installation of postgres 8.3 that I have uses cygwin script to start/stop…

···

On 3 March 2010 12:55, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi there.

First of all, Postgres is installed as a native windows service.

Cygwin is not involved. Postgres does not NEED to be run as a service,

but there are some pros/cons about doing this way. A big con is that

you need administrative access to the machine (which the Postgres

installer will require). However, there are different ways of doing

it.

I have used the enterprise DB installer to do this, but the 8.4 series
(even 8.3) there are native postgres binaries. This was why previously
you needed to use Cygwin. This is no longer the ace. You do not need
to use the Enterprise DB installer to do this. I am contemplating
using the binary distributions, and combined with some of the scripts
that Knut wrote a few years back, we would not necessarily need to use
the Enterprise DB installer. However, there are some advantages to
using it, namely that it comes prepackaged with PgAdmin, and
StackBuilder,which will be quite useful for some folks.

Regards,
JPP

···

On Wed, Mar 3, 2010 at 2:25 PM, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:

On 3 March 2010 12:55, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Hi there.

First of all, Postgres is installed as a native windows service.
Cygwin is not involved. Postgres does not NEED to be run as a service,
but there are some pros/cons about doing this way. A big con is that
you need administrative access to the machine (which the Postgres
installer will require). However, there are different ways of doing
it.

Is the service part of EnterpriseDB?? Because the windows installation of
postgres 8.3 that I have uses cygwin script to start/stop...

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

I say go with what is easiest for you. But I in general like the use of the
tray application, especially if we can get developers from OpenMRS working
on it. We could perhaps also use it for the Public Health Information
Toolkit (PHIT)
http://www.openhealthconsortium.org/wiki/doku.php?id=phit
The needs of many tools are very similar - even PHP apps like iHRIS perhaps,
if ran on Quercus http://quercus.caucho.com/ as Saptarshi has suggested. So
the Launcher/installer/updater could be factored out as a separate project,
perhaps (though I know you just merged the installer it with trunk....)
Knut

There is no real reason it needs to be in trunk, but it is better than
in my junk branch, so if we need to move it to a seperate project,
this is fine with me.

Regards,
Jason

Hi,

I think Bob hits the needle on the head here. We can provide a generic hook into the Live app by making it look for a set of scripts during certain phases. E.g. database_start.bat at startup time, database_stop.bat at shutdown, and more. In these scripts we start the database or what we prefer.

I am in favour of the binary/non-installer postgres approach. Simple is good. Being independent of admin rights and existing installations weighs more than pgadmin (which can be installed separately) in my opinion.

Work flow for the Live package could be simple: When clicked it starts postgres, then jetty/dhis2. At system tray “exit” it stops jetty/dhis2, then postgres.

If I read Jason correctly the database part of this is doable. I suggest we go for this. Objections?

Lars

PS using Live for modifying hibernate.properties (and thus a low-key change-of-database as required in SA) and update war file are great ideas, lets start a new thread for these.

Hi,
I think Bob hits the needle on the head here.

Ouch. That can be painful ..

We can provide a generic hook
into the Live app by making it look for a set of scripts during certain
phases. E.g. database_start.bat at startup time, database_stop.bat at
shutdown, and more. In these scripts we start the database or what we
prefer.
I am in favour of the binary/non-installer postgres approach. Simple is
good. Being independent of admin rights and existing installations weighs
more than pgadmin (which can be installed separately) in my opinion.
Work flow for the Live package could be simple: When clicked it starts
postgres, then jetty/dhis2. At system tray "exit" it stops jetty/dhis2, then
postgres.
If I read Jason correctly the database part of this is doable. I suggest we
go for this. Objections?

I think it is all doable. There are a few synchronisation type issues
to consider which would be beyond my windoze scripting ability.
Specifically we need to
(i) make sure we don't start postgres if its already started; and
(ii) don't start jetty till we know postgres has started - I guess
this can be a little more fine grained. We can start jetty in
parallel but not start the dhis context till we know we have database
(this will save a second or two). I guess a rough solution might be
to fire off the startup scripts then start pinging for database from
the tray app, though this would have to be done through hibernate to
keep database dependencies at bay. A better solution is for the shell
script to poll for a connection using pg_xxx. After it gets it, it
can release the connection and exit. The java in the dhis2-live picks
up on when the exec finishes through java.lang.Process before going
about its business. I guess we should also capture stdout and stderr
for logging and/or UI display.

For all of the above you can also substitute mysql for postgres.

Is anybody volunteering to have a go at writing the above with pg
and/or mysql commands?

If we have some strong scripts I can help with dhis-live integration
and execution control.

Cheers
Bob

···

2010/3/4 Lars Helge Øverland <larshelge@gmail.com>:

Lars
PS using Live for modifying hibernate.properties (and thus a low-key
change-of-database as required in SA) and update war file are great ideas,
lets start a new thread for these.

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

It is possible to install postgres from binary package. However still need administrative rights, we need to create a new windows account for postgres. Previous Vietnamese team did these stuffs more than 3 years ago for the very first installation of DHIS-2. I don’t know if VN HISP Office still keep a copy of this installation or not.

Cheers,
Quang

···

2010/3/4 Lars Helge Øverland larshelge@gmail.com

Hi,

I think Bob hits the needle on the head here. We can provide a generic hook into the Live app by making it look for a set of scripts during certain phases. E.g. database_start.bat at startup time, database_stop.bat at shutdown, and more. In these scripts we start the database or what we prefer.

I am in favour of the binary/non-installer postgres approach. Simple is good. Being independent of admin rights and existing installations weighs more than pgadmin (which can be installed separately) in my opinion.

That work was done with Installer2go, I think. Perhaps Øyvind has a copy of the scripts involved somewhere…

Knut

···

2010/3/4 Quang Nguyen quangnguyen111@gmail.com

2010/3/4 Lars Helge Øverland larshelge@gmail.com

Hi,

I think Bob hits the needle on the head here. We can provide a generic hook into the Live app by making it look for a set of scripts during certain phases. E.g. database_start.bat at startup time, database_stop.bat at shutdown, and more. In these scripts we start the database or what we prefer.

I am in favour of the binary/non-installer postgres approach. Simple is good. Being independent of admin rights and existing installations weighs more than pgadmin (which can be installed separately) in my opinion.

It is possible to install postgres from binary package. However still need administrative rights, we need to create a new windows account for postgres. Previous Vietnamese team did these stuffs more than 3 years ago for the very first installation of DHIS-2. I don’t know if VN HISP Office still keep a copy of this installation or not.

Cheers,
Quang


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring

That work was done with Installer2go, I think. Perhaps Øyvind has a copy of the scripts involved somewhere…

Yup, that’s right. I don’t have full stuffs of that installation, but at least bat files are stored somewhere in my backup DVDs (others were in my stolen laptop :slight_smile: ). Will tell you if I found them.

Quang

···

On Fri, Mar 5, 2010 at 12:32 AM, Knut Staring knutst@gmail.com wrote:

Knut

2010/3/4 Quang Nguyen quangnguyen111@gmail.com

2010/3/4 Lars Helge Øverland larshelge@gmail.com

Hi,

I think Bob hits the needle on the head here. We can provide a generic hook into the Live app by making it look for a set of scripts during certain phases. E.g. database_start.bat at startup time, database_stop.bat at shutdown, and more. In these scripts we start the database or what we prefer.

I am in favour of the binary/non-installer postgres approach. Simple is good. Being independent of admin rights and existing installations weighs more than pgadmin (which can be installed separately) in my opinion.

It is possible to install postgres from binary package. However still need administrative rights, we need to create a new windows account for postgres. Previous Vietnamese team did these stuffs more than 3 years ago for the very first installation of DHIS-2. I don’t know if VN HISP Office still keep a copy of this installation or not.

Cheers,
Quang


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring

Hi there. All these sound like great suggestions, but I think we need to make a decision soon about what to do. I have some suggestions.

  1. We should perhaps consider forking the installer off the main branch, as Knut has suggested. This could have the advantage of bringing in a larger crowd that wants to work on installers for OpenXData, OpenMRS, DHIS, etc packaged together. The installer itself, in its current incarnation, has no direct dependencies on the trunk code, so it would be simple enough to do this. However, I feel we are losing focus somewhat. It may not help to try and worry about every single type of installation that is necessary .We have identified a key requirement, which is a basic installer for DHIS2 with either H2 or Postgres. This is what I have been continuing to work on based on this requirement.

  2. More techie stuff now. Installation of Postgres without administrative rights, AFAIK, is simply not possible. As Quanq points out, this is required in order to create a non-administrative user, which Postgres requires. I am making the assumption that users are going to have this, otherwise a Postgres install will simply not be possible unless people know a way around this. The scripts would be useful, but Knut has already supplied some that will do the trick. It is simple not to install Postgres as a service if needed, and launch it at runtime. I see pros and cons for this, mostly related to the use of PivotTables, which would require Postgres to be running. It may not be intuitive to users to launch the database prior to using Excel. I have a rather modest little laptop, and have noticed no resource issues really, with Postgres running in the background. I think we should go that route, and that is how I have been testing the BitRock installer thus far.

I must say though, I am still a bit confused why we are not considering the H2 approach more? I have an installer already for this, and it works like a charm, at least on a stock XP machine.

I have taken a look at .embedding the JRE which is simple, but it would require a change to the DHIS2 Live app, which of course would break other DHIS2 live installs that may not use the embedded JRE that we would package with the installer. We could alter the Live app source code at the builder compile time, to suit the needs of the installer. Better yet, would be a config file for the app that we could write during the installation, which could read the JRE location. Maybe we could use this for other properties, like memory settings as well.

So, if you can dig up those scripts, it would be good. But, I still think that since users will need admin rights for a postgres install, it is better to install it as a service.

Regards,
Jason

···

On Thu, Mar 4, 2010 at 9:38 PM, Quang Nguyen quangnguyen111@gmail.com wrote:

On Fri, Mar 5, 2010 at 12:32 AM, Knut Staring knutst@gmail.com wrote:

That work was done with Installer2go, I think. Perhaps Øyvind has a copy of the scripts involved somewhere…

Yup, that’s right. I don’t have full stuffs of that installation, but at least bat files are stored somewhere in my backup DVDs (others were in my stolen laptop :slight_smile: ). Will tell you if I found them.

Quang

Knut

2010/3/4 Quang Nguyen quangnguyen111@gmail.com

2010/3/4 Lars Helge Øverland larshelge@gmail.com

Hi,

I think Bob hits the needle on the head here. We can provide a generic hook into the Live app by making it look for a set of scripts during certain phases. E.g. database_start.bat at startup time, database_stop.bat at shutdown, and more. In these scripts we start the database or what we prefer.

I am in favour of the binary/non-installer postgres approach. Simple is good. Being independent of admin rights and existing installations weighs more than pgadmin (which can be installed separately) in my opinion.

It is possible to install postgres from binary package. However still need administrative rights, we need to create a new windows account for postgres. Previous Vietnamese team did these stuffs more than 3 years ago for the very first installation of DHIS-2. I don’t know if VN HISP Office still keep a copy of this installation or not.

Cheers,
Quang


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Hi there. All these sound like great suggestions, but I think we need to make a decision soon about what to do. I have some suggestions.

  1. We should perhaps consider forking the installer off the main branch, as Knut has suggested. This could have the advantage of bringing in a larger crowd that wants to work on installers for OpenXData, OpenMRS, DHIS, etc packaged together. The installer itself, in its current incarnation, has no direct dependencies on the trunk code, so it would be simple enough to do this. However, I feel we are losing focus somewhat. It may not help to try and worry about every single type of installation that is necessary .We have identified a key requirement, which is a basic installer for DHIS2 with either H2 or Postgres. This is what I have been continuing to work on based on this requirement.

I would say we keep it in trunk. At least until we have somewhat of a product to show.

  1. More techie stuff now. Installation of Postgres without administrative rights, AFAIK, is simply not possible. As Quanq points out, this is required in order to create a non-administrative user, which Postgres requires. I am making the assumption that users are going to have this, otherwise a Postgres install will simply not be possible unless people know a way around this. The scripts would be useful, but Knut has already supplied some that will do the trick. It is simple not to install Postgres as a service if needed, and launch it at runtime. I see pros and cons for this, mostly related to the use of PivotTables, which would require Postgres to be running. It may not be intuitive to users to launch the database prior to using Excel. I have a rather modest little laptop, and have noticed no resource issues really, with Postgres running in the background. I think we should go that route, and that is how I have been testing the BitRock installer thus far.

Installing as a service seems fine to me if admin rights are required anyway. I think the real problem is the conflict-with-existing-installations one. Can we install it with a specific service name and on a specific port? And could it then co-exist with other postgres services?

I must say though, I am still a bit confused why we are not considering the H2 approach more? I have an installer already for this, and it works like a charm, at least on a stock XP machine.

Well its a good point. I can only say that postgres is more proven, more people have knowledge about it, it provides better supportive applications (pgadmin), and I have experienced problems with importing large amounts of data with H2. But H2 is improving and we will definitely have “full H2 compliance” as a goal.

I have taken a look at .embedding the JRE which is simple, but it would require a change to the DHIS2 Live app, which of course would break other DHIS2 live installs that may not use the embedded JRE that we would package with the installer. We could alter the Live app source code at the builder compile time, to suit the needs of the installer. Better yet, would be a config file for the app that we could write during the installation, which could read the JRE location. Maybe we could use this for other properties, like memory settings as well.

Yeah I’m sure we (Bob?) could do some magic here and the JRE is only 15 mb. So I’ll say we go for it.

Lars

···

On Fri, Mar 5, 2010 at 8:48 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi there. All these sound like great suggestions, but I think we need to make a decision soon about what to do. I have some suggestions.

  1. We should perhaps consider forking the installer off the main branch, as Knut has suggested. This could have the advantage of bringing in a larger crowd that wants to work on installers for OpenXData, OpenMRS, DHIS, etc packaged together. The installer itself, in its current incarnation, has no direct dependencies on the trunk code, so it would be simple enough to do this. However, I feel we are losing focus somewhat. It may not help to try and worry about every single type of installation that is necessary .We have identified a key requirement, which is a basic installer for DHIS2 with either H2 or Postgres. This is what I have been continuing to work on based on this requirement.

I would say we keep it in trunk. At least until we have somewhat of a product to show.

  1. More techie stuff now. Installation of Postgres without administrative rights, AFAIK, is simply not possible. As Quanq points out, this is required in order to create a non-administrative user, which Postgres requires. I am making the assumption that users are going to have this, otherwise a Postgres install will simply not be possible unless people know a way around this. The scripts would be useful, but Knut has already supplied some that will do the trick. It is simple not to install Postgres as a service if needed, and launch it at runtime. I see pros and cons for this, mostly related to the use of PivotTables, which would require Postgres to be running. It may not be intuitive to users to launch the database prior to using Excel. I have a rather modest little laptop, and have noticed no resource issues really, with Postgres running in the background. I think we should go that route, and that is how I have been testing the BitRock installer thus far.

Installing as a service seems fine to me if admin rights are required anyway.

It may be that PG does not need a specific account if we just copy the files and don’t make it a service (don’t remember).

I think the real problem is the conflict-with-existing-installations one. Can we install it with a specific service name and on a specific port? And could it then co-exist with other postgres services?

Yes - we have actually had this for years - in a long series of installers…e.g. Ola has experience using the previous BitRock installer without problems in Tanzania.

Knut

···

2010/3/5 Lars Helge Øverland larshelge@gmail.com

On Fri, Mar 5, 2010 at 8:48 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

I must say though, I am still a bit confused why we are not considering the H2 approach more? I have an installer already for this, and it works like a charm, at least on a stock XP machine.

Well its a good point. I can only say that postgres is more proven, more people have knowledge about it, it provides better supportive applications (pgadmin), and I have experienced problems with importing large amounts of data with H2. But H2 is improving and we will definitely have “full H2 compliance” as a goal.

I have taken a look at .embedding the JRE which is simple, but it would require a change to the DHIS2 Live app, which of course would break other DHIS2 live installs that may not use the embedded JRE that we would package with the installer. We could alter the Live app source code at the builder compile time, to suit the needs of the installer. Better yet, would be a config file for the app that we could write during the installation, which could read the JRE location. Maybe we could use this for other properties, like memory settings as well.

Yeah I’m sure we (Bob?) could do some magic here and the JRE is only 15 mb. So I’ll say we go for it.

Lars


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring

It may be that PG does not need a specific account if we just copy the files and don’t make it a service (don’t remember).

Postgres must be run as a user that does not have administrative privileges. This does not have to be the user that is logged in, but it does need to be a user.

I think the real problem is the conflict-with-existing-installations one. Can we install it with a specific service name and on a specific port? And could it then co-exist with other postgres services?

Yes - we have actually had this for years - in a long series of installers…e.g. Ola has experience using the previous BitRock installer without problems in Tanzania.

This should not a big deal. It is easy to create either a random user name or one that is unlikely to conflict with an existing one.
As i mentioned, the postgres installer that is packaged within the installer that I have been working on, is intelligent enough not to choose a port that is already in use. I already had postgres installed, and it changed the port automatically to 5433. What I have not had time to do yet, is write this to the hibernate.properties file, but I am saving that for the next flight to Dushanbe in a few hours.

Bob, what do you think about that configuration file that the installer could write, to let the Live app know which JRE to use?

Regards,
Jason

Knut

I must say though, I am still a bit confused why we are not considering the H2 approach more? I have an installer already for this, and it works like a charm, at least on a stock XP machine.

I still think that for a typical district install, H2 should suffice. I hope. We need to test it, as there are some definite advantages.

···

Well its a good point. I can only say that postgres is more proven, more people have knowledge about it, it provides better supportive applications (pgadmin), and I have experienced problems with importing large amounts of data with H2. But H2 is improving and we will definitely have “full H2 compliance” as a goal.

I have taken a look at .embedding the JRE which is simple, but it would require a change to the DHIS2 Live app, which of course would break other DHIS2 live installs that may not use the embedded JRE that we would package with the installer. We could alter the Live app source code at the builder compile time, to suit the needs of the installer. Better yet, would be a config file for the app that we could write during the installation, which could read the JRE location. Maybe we could use this for other properties, like memory settings as well.

Yeah I’m sure we (Bob?) could do some magic here and the JRE is only 15 mb. So I’ll say we go for it.

Lars


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

It may be that PG does not need a specific account if we just copy the files and don’t make it a service (don’t remember).

Postgres must be run as a user that does not have administrative privileges. This does not have to be the user that is logged in, but it does need to be a user.

I think the real problem is the conflict-with-existing-installations one. Can we install it with a specific service name and on a specific port? And could it then co-exist with other postgres services?

Yes - we have actually had this for years - in a long series of installers…e.g. Ola has experience using the previous BitRock installer without problems in Tanzania.

This should not a big deal. It is easy to create either a random user name or one that is unlikely to conflict with an existing one.
As i mentioned, the postgres installer that is packaged within the installer that I have been working on, is intelligent enough not to choose a port that is already in use. I already had postgres installed, and it changed the port automatically to 5433. What I have not had time to do yet, is write this to the hibernate.properties file, but I am saving that for the next flight to Dushanbe in a few hours.

Okay, could it be an option to assign it a non-standard port number right away and use that in hibernate.properties?

···

2010/3/5 Jason Pickering jason.p.pickering@gmail.com

Bob, what do you think about that configuration file that the installer could write, to let the Live app know which JRE to use?

Regards,
Jason

Knut

I must say though, I am still a bit confused why we are not considering the H2 approach more? I have an installer already for this, and it works like a charm, at least on a stock XP machine.

I still think that for a typical district install, H2 should suffice. I hope. We need to test it, as there are some definite advantages.

Well its a good point. I can only say that postgres is more proven, more people have knowledge about it, it provides better supportive applications (pgadmin), and I have experienced problems with importing large amounts of data with H2. But H2 is improving and we will definitely have “full H2 compliance” as a goal.

I have taken a look at .embedding the JRE which is simple, but it would require a change to the DHIS2 Live app, which of course would break other DHIS2 live installs that may not use the embedded JRE that we would package with the installer. We could alter the Live app source code at the builder compile time, to suit the needs of the installer. Better yet, would be a config file for the app that we could write during the installation, which could read the JRE location. Maybe we could use this for other properties, like memory settings as well.

Yeah I’m sure we (Bob?) could do some magic here and the JRE is only 15 mb. So I’ll say we go for it.

Lars


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

It may be that PG does not need a specific account if we just copy the
files and don't make it a service (don't remember).

Postgres must be run as a user that does not have administrative privileges.
This does not have to be the user that is logged in, but it does need to be
a user.

I think the real problem is the conflict-with-existing-installations one.
Can we install it with a specific service name and on a specific port? And
could it then co-exist with other postgres services?

Yes - we have actually had this for years - in a long series of
installers...e.g. Ola has experience using the previous BitRock installer
without problems in Tanzania.

This should not a big deal. It is easy to create either a random user name
or one that is unlikely to conflict with an existing one.
As i mentioned, the postgres installer that is packaged within the installer
that I have been working on, is intelligent enough not to choose a port that
is already in use. I already had postgres installed, and it changed the port
automatically to 5433. What I have not had time to do yet, is write this to
the hibernate.properties file, but I am saving that for the next flight to
Dushanbe in a few hours.

Bob, what do you think about that configuration file that the installer
could write, to let the Live app know which JRE to use?

Hi Jason - sorry I'm half following this discussion while working on
something else. Trying to pay attention :slight_smile:

I'll have to look at this, but as far as I can tell (and I'm not
really the world's java expert) you can't really tell the java source
code to pick which jre it wants to use. Kind of like the adage about
children not being able to pick their parents. By the time that code
is running its kind of too late. I guess the only thing which can be
done (and maybe this is what you mean) is to change settings in the
launch4j config file. But again this can't really be done at install
time ..... unless of course the launch4j packaging of the "exe" is
actually done as an install step. I guess this might be possible but
it starts to get hairy. Off the top of my head:
1. launch4j would need to be bundled in the installer package by bitrock
2. bitrock would need to be clever enough to modify launch4j config file
3. bitrock would need to install launch4j and jre
4. bitrock would need to run launch4j (with which jre? ca't remember
offhand but I think you need a jre) to generate the dhis2-live.exe as
a post-install step
5. bitrock can now remove launch4j as a subsequent postinstall step.

I'm trying to understand again why we want to do this. If we are
indeed bundling a jre then can't we set that jre as the one to be used
as part of the build process of dhis2-live.exe? Someone remind me why
we want to do this at install time?

Regards
Bob

···

On 5 March 2010 16:17, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Regards,
Jason

Knut

I must say though, I am still a bit confused why we are not considering
the H2 approach more? I have an installer already for this, and it works
like a charm, at least on a stock XP machine.

I still think that for a typical district install, H2 should suffice. I
hope. We need to test it, as there are some definite advantages.

Well its a good point. I can only say that postgres is more proven, more
people have knowledge about it, it provides better supportive applications
(pgadmin), and I have experienced problems with importing large amounts of
data with H2. But H2 is improving and we will definitely have "full H2
compliance" as a goal.

I have taken a look at .embedding the JRE which is simple, but it would
require a change to the DHIS2 Live app, which of course would break other
DHIS2 live installs that may not use the embedded JRE that we would package
with the installer. We could alter the Live app source code at the builder
compile time, to suit the needs of the installer. Better yet, would be a
config file for the app that we could write during the installation, which
could read the JRE location. Maybe we could use this for other properties,
like memory settings as well.

Yeah I'm sure we (Bob?) could do some magic here and the JRE is only 15
mb. So I'll say we go for it.
Lars

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

--
Cheers,
Knut Staring

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp