[Debian-med-packaging] Bug#707639: Bug#707639: gnuhealth: System user for the server

[Emilien Klein]

2014-03-27 13:50 GMT+01:00 Mathias Behrle <mathiasb at m9s.biz>:
> * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
>   user for the server" (Thu, 27 Mar 2014 13:06:53 +0100):
>> You are correct that having 2 running Tryton servers is not
>> helpful/wise. That is why having a service-less Tryton package would
>> be very helpful in this case (cf link in my previous post)
>
> Nice;) You claim, that you want to provide a package with minimal user
> interaction for gnuhealth, but ask the 'original' package providing the server
> to do the contrary...

Yes and no: I do want the user to have as less automatic steps to do
as possible. If that means us (technical maintainers) doing a little
bit of extra work, that is worth it. We do the hard work in Debian, so
that the user doesn't have to. That is the whole interest of the
package, otherwise let's just have the user unzip a tarball and do the
same configuration steps anyway on their own...


>> To me, if a user is going to install GNU Health, they do it for
>> medical reasons. They will also take care of the ERP side of running
>> the hospital using Tryton, but they won't be running a separate Tryton
>> server for that. They'll do it in the same Tryton server that is
>> running for GNU Health.
>
> You are doing heavy assumptions on users. This is exactly the way, you are
> narrowing the possible target audience of your package. I could describe a lot
> of scenarios where your assumptions will proove to be wrong.

Making assumptions is part of a Debian Maintainer's role. We are
setting the software up, to lift most of the burden off our user's
shoulder.
My target is supporting any hospital that wants to use GNU Health. The
only assumption that is relevant for this bug report is that they are
not yet using Tryton to do their ERP work:
- If they don't use Tryton already, then there is no issue at all.
- If they were to use Tryton:
  1. They would not install GNU Health directly onto their production
server, without first testing on a test machine
  2. If they decide to go on, they would have to decide whether to use
2 different Tryton servers, or to merge them both on one.
    A. If they keep 2 servers, it would be best to separate them
(virtualization, containerization, or just other physical hardware).
That is just standard security practice.
    B. If they want to have just one server, they'll have to either
create a new database on their existing instance and shut the GNU
Health startup deamon off, or move the existing Tryton database off to
the new GNU Health server

Regardless of what option they choose, they'll have to figure out what
works best for them.
In any case, having the GNU Health package create its own user, and
run under that (if they so choose to use the service provided by the
gnuhealth-server package, that is) doesn't have any impact on the
user. Regardless of whatever assumption you think is being made.

>> As mentioned, I consider the Tryton server package to be in a
>> "broken/unusable" state right after installation.
>
> To be precised. What is broken?

apt-get install tryton-server (with the other modules you want)
Open Tryton client on another machine
Connect to your server
Doesn't work

>> I want the GNU
>> Health package to be usable right out of the box, and be able to
>> assist the users in all steps related to upgrades (such as updating
>> the database models, possibly removing unused tables, etc.).
>
> I answered this point in #707632 [1] and don't want to repeat the arguments
> here.

Correct.
Having the system doing automatic backups (only at upgrade time)
doesn't prevent the user of making their own (hopefully much more
regularly). So this added benefit is not an issue, just an extra
safeguard should the user have upgraded it's system without first
backing it up (you don't think that ever happens?)
No need to further discuss this point here.

>> I can only do that if the database is managed by the Debian package.
>> To manage the database, it needs to be created by the gnuhealth
>> package. As I can't fiddle with files installed by the Tryton package
>> (e.g. /etc/trytond.conf) as that is obviously against Debian packaging
>> conventions. This ensues that I need to have the ability to have a
>> gnuhealth user that owns the database, and run a Tryton server under
>> that user so that it can access the database.
>
> You are mixing things. Why shouldn't you be able to manage a database owned by
> the tryton user? If you need a separate server configuration to be managed by
> your package this can most easily be done with the -c parameter of trytond
> (please have a look at the defaults file, that you are also using for the
> gnuhealth package).

Running GNU Health server on a database that is owned by it's
dedicated user is what is recommended by upstream. They have also
recently stated they really see a benefit in all the installation
being on the same base, to help with issues resolution or so that the
user can just follow the instructions on the wiki.

In an effort to make some progress on this issue and stop spending our
time on email ;) I'm pushing this discussion towards the GNU Health
developers directly on the health-dev at gnu.org mailing list and have
them clarify their recommendation. At that point I'll happily follow
whatever upstream recommends to install their software.

    +Emilien