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

[Axel Braun]

Hi Emilien,

> Gesendet: Samstag, 29. März 2014 um 09:16 Uhr
> Von: "Emilien Klein" <address@hidden>
> An: address@hidden
> Cc: "Tryton package maintenance in Debian" <address@hidden>, "Debian Med 
> Project List" <address@hidden>
> Betreff: Re: [Health-dev] [tryton-debian] gnuhealth packaging (was: Exception 
> when building the package in a cleanroom Debian environment)

[....]

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

Indeed, upgrading an existing installation is always risky and should have a 
dry-run on a backup system first of all. If that works, then you can take the 
learning and upgrade your production server (just for the records: In complex 
ERp systems like SAP this is a project for itself, not just an evening 
amusement).

>From that perspective, I would never recommend an automatic upgrade across 
>Tryton|gnuhealth versions. Even within the same main version, an upgrade has 
>to have manual interaction, see http://code.google.com/p/tryton/wiki/Update

[snip]

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

Server *should* run under their dedicated users!

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

Indeed. No point in having a separate gnuhealth-user.
 
> > 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.

looking at the scripts from gnuhealth, the gnuhealth user seems to be a 
login-user.
 
> > 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.

Will you then have different packages for tryton and gnuhealth?
IMHO, tryton is the foundation, and gnuhealth should use what tryton provides. 
So fiddeling around with another user is not best practice. It may be 
appropriate in small desktop installations, but at least for a production 
environment I personally would step away from it.

But as always in OpenSource: There's more than one way to do it.

Cheers/Axel