dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

>
> 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<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Cheers,
> Knut Staring
>



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