[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception whe

From: Axel Braun
Subject: Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment)
Date: Fri, 28 Mar 2014 12:09 +0100
User-agent: KMail/4.11.5 (Linux/3.11.10-7-desktop; KDE/4.11.5; x86_64; ; )

Hi all,

Am Donnerstag, 27. März 2014, 01:05:21 schrieb Luis Falcon:

I have been reading through this lengthy discussion , and was not sure if I 
should add my 2c.

As I'm more coming from the user perspective, I will.

First, I do  not really care if we have all GNU health modules in one packages 
or in multiple packages.
I'm happy with the current setup in that way, that I can install all gnu 
health objects with their dependencies with a single command.

BUT, I would not like to offer a preinstalled/initialized database, as this 
task is fairly simple to achieve from the Tryton-Frontend. It is then up to 
the user to decide which health modules he really wants to install. 
The uninstalled ones are some MB on the disk...who cares.

Unless a user is in the trial and error phase (Demo DB/CD...) , he has to dive 
in a little deeper into the context (at least to determine which modules he 
really needs)
Technical setup of tryton is IHMO well described and possible for an average 
I would not try to 'oversimplify' and by this make it more complicated.

> This is some steps you could take to init a GNU Health instance called
> "gnuhealth"
> 1) Create the DB with the UTF8 encoding. I believe that the DB encoding
> might have been the cause of the encoding error you encounter at first.
> $ createdb gnuhealth --encoding=unicode
> 2) Init the Tryton instance and the core health module with its
> dependencies (country, party, currency, company and product). This
> little BASH loop would do the job.
> $ for health_core_mods in ir country party currency company product
> health; do ./trytond --init=${health_core_mods} --database=gnuhealth;
> done
> The server will ask you for the admin passwd at the terminal
> window after installig the "ir" module. If you don't want to enter the
> admin password at the termina, you can put the passwd on a temp file and
> refer to it with the TRYTONPASSFILE environment variable before
> executing the for loop.
> 3) Start the Tryton server
> $ ./trytond
> 4) Start the Tryton client, you will be presented with the wizards to
> create the users and company (the health institution). From there, you
> can pick other modules or just work on the core GNU Health
> functionality.
> You should be done.

Sounds complicated to me :-)

> NOW... that said, I prefer *not* creating a db instance as part
> of the package installation process, because
> - It's very easy to use the Tryton client to create the instance from
>   scratch, including the database and admin user/password
> - You can choose your own DB name for each instance, for the sandbox,
>   development, test and production instances you would need to specify
>   different DB names
> - You avoid all those scripts/loops/variables that I put in previous
>   paragraphs :)


> This is of course my opinion, and there might be scenarios where a
> non-interactive installation as just depicted can be very valid.
> In the case of upgrades, we send the instructions as per release (normally
> just --update=all ). But you if the maintainer includes it on the
> package, fantastic :)
> What I would take in consideration for to always include in the package,
> independently of the GNU/Linux distribution are :
> - All the modules included on each release's tar.gz file
> - Create the gnuhealth user at OS level and give the appropiate DB
>   permissions.
> - GNU Health user bashrc file
> - GNU Health user aliases, matching the directory and file locations of
>   the specific distro (cdexe, editconf, cdlogs, cdconf... ). They are in
>   the $HOME/.gnuhealthrc file when using the standard/generic installer
>   (
> - Start and stop scripts.
> This is important, so, independently from the distro used, the user
> will find the GNU HEalth book easy to follow (or at least that's our
> goal :) ). They are also very handy to make go to the right place and
> edit the right file.

At this point I have a very different opinion.

First, I would not like to reinvent the wheel, so I would like to use what 
whatever system offers me in standard. This is a powerful package manager 
(zypper, apt, yum,..) as well as a system for starting, stopping and monitorig 
(systemd, mostl likely also the Debian-choice). 
Thats why we have build packages for each distro.
Having sideways in this makes running a server more complicated

Second, running a server under a user is not a good practice. 
GNU Health is an add-on to Tryton, so it should follow the Tryton-guidelines
Tryton Server runs under user tryton (no-login)
Postgres runs under user Postgres (no-login)

I honestly cant imagine that the Jamaican infrastructue will run under a is a high security risk. 
I dont see the benefit that this approach takes.

I feel that [1] addresses the issue in a similar way

Let me know your thoughts,


Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]