Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception when building the package in a cleanroom Debian environment)

[Emilien Klein]

Hi Axel,

2014-03-28 12:09 GMT+01:00 Axel Braun <address@hidden>:
> Hi all,
>
> Am Donnerstag, 27. März 2014, 01:05:21 schrieb Luis Falcon:
>
> [snip]
>
> 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.

That is great, very helpful.

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

Yes, you can just answer No to the question if you want the package to
create the database for you, problem solved.
You will then nonetheless take care of watching the list of packages
that gets upgraded. If gnuhealth is getting upgraded, you will
uncompress the /usr/share/doc/gnuhealth-server/README.Debian.gz file
and read it's content, to know which procedures to manually perform to
upgrade your database. Failure to perform these steps could mean an
unusable GNU Health instance.

If on the other hand you want to upgrade and have your package
continue to work without manual intervention, you can also choose to
have the database created by the system (you still choose which GNU
Health modules to activate, just as when the database is created
manually), and the package will apply the upgrade scripts for you.

It is sound to still perform your backups regularly, and as a safety
net the package will make a backup just before upgrading (but only if
the package knows about which database you use, i.e. the database was
created by the package)

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

Correct. This is what the Debian package allows: regardless if the
database is created with the package or not, you still have to
indicate which packages to use the first time you open Tryton (I'm
making a change to not initialize all the modules, that was a mistake
I assume)

> Technical setup of tryton is IHMO well described and possible for an average
> user.
> I would not try to 'oversimplify' and by this make it more complicated.

Again, I don't see how it's oversimplified or made more complex. The
only thing that is done, is create a Postgres database (so that the
package knows how it's called, and can apply the upgrade scripts
provided by GNU Health when new versions are released), and initialize
the basis Tryton modules, so that the Tryton client recognizes that
database as a Tryton database. You then log in and select which GNU
Health modules you want to use.

As mentioned, you jump straight to step 4 "Logging into the
application" [2] of the GNU Health installation steps, you will then
perform step 5 "Installing the default modules" and can also do step 6
"Installing Extra Modules" if you want to.

[snip package code]
> Sounds complicated to me :-)

Axel, these are not steps the user would perform. this is what is
performed by Tryton when you manually tell it to create a database,
and would be performed by the Debian package code.

>> 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 :)
>
> Agree

No problem, you can absolutely do that with the Debian package, just
answer No to the question if you want the package to create the
database.
But be informed that you will have to read each upgrade installation
information. I am afraid some users might be at risk of forgetting
that.

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

Are you saying servers should not be run under their dedicated user
account (note that it's not a login account)? That's what all servers
do, including Tryton and Postgres.
Or are you saying GNU Health should use the same dedicated user as
Tryton? As you link to #707639, I assume that's what your pointing to.

> I honestly cant imagine that the Jamaican infrastructue will run under a
> login-user....it is a high security risk.

In the current state, the gnuhealth user is exactly the same as the
tryton or postgres user: not used to log in, but you can "su" or
"sudo" as that user to change the configuration files.

> I dont see the benefit that this approach takes.

Let's move this discuss over to the address@hidden mailing list
only (I'll do that later today hopefully). Once a decision is made on
running the GNU Health under a dedicated user or under a user with a
different name, we'll apply the selected option to the Debian package.

    +Emilien
[2] 
http://en.wikibooks.org/wiki/GNU_Health/Installation#Logging_into_the_application