Debian Bug report logs - #707639
gnuhealth: System user for the server

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: submit@bugs.debian.org

Subject: gnuhealth: System user for the server

Date: Thu, 9 May 2013 22:03:12 +0200

[Message part 1 (text/plain, inline)]

X-Debbugs-CC: <tryton-debian@lists.virtual-things.org>
Package: gnuhealth
Version: 1.8.1-1 (svn rev 13528)
Severity: important

   Please drop creation and usage of the gnuhealth user.

   While it is obviously preferable to run a tryton server under a user
   account, it is generally not a good idea to run different servers under
   different users.
   trytond uses unoconv for document conversion. unoconv can be run as a
   service, which is preferable for performance reasons. To connect a tryton
   server to an unoconv session it must be run under the same user.
   Running the server under a different user as the tryton user created from
   tryton-server package itself IMO is needless and counterproductive. Probably
   this idea is a relict from GNU Health wiki, which is inspired from the wiki
   on tryton.org, where we are descripting a setup, when running trytond from
   *sources*(!).

-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien+debian@klein.st>

To: 707639@bugs.debian.org

Cc: Mathias Behrle <mathiasb@m9s.biz>

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

Date: Wed, 26 Mar 2014 22:39:05 +0100

The GNU Health package runs its own dedicated Tryton server, under
that gnuhealth user, unoconv would thus run under the same user as the
Tryton server.

The rationale for using a separate user is explained at length at [0],
short version is that I believe a Debian package should (as much as
possible) be usable directly after installation, without forcing the
user to edit a config file (etc/trytond.conf in this case) to make the
package run. Of course, if the user has specific needs, editing the
config file is always possible, but in the state I consider the Tryton
package to be in a "broken/unusable" state right after installation.
Only advanced/expert users know they need to go and read the content
of the /usr/share/doc/tryton-server/README.Debian.gz (which they first
need to uncompress to access). This is not the way to make FLOSS
software reacheable to everyday-people.

As suggested in [0], I would encourage the creation of a service-less
tryton-server package providing the source code for the server
functionality (on which GNU Health would depend), and out-of-the-box
working package tryton-server-postgres and tryton-server-sqlite
packages that would come with ready-to-use databases and provide a
startup service.

That way GNU Health can be run using it's own user (best to separate
different applications using separate users, best would be to provide
full containerization...) and there is no separate Tryton server
running unused.

I will close this issue as the current situation is the best for the
Debian users of GNU Health.
You are obviously free to add more details and argument your position,
should you think this presents major issues for Debian or its users.
   +Emilien
[0] https://lists.debian.org/debian-med/2013/09/msg00077.html

Message #15 received at 707639-done@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien+debian@klein.st>

To: 707639-done@bugs.debian.org

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

Date: Wed, 26 Mar 2014 23:16:10 +0100

Closing the bug report.
   +Emilien

Message #20 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Emilien Klein <emilien+debian@klein.st>

Cc: 707639@bugs.debian.org

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

Date: Thu, 27 Mar 2014 12:46:45 +0100

[Message part 1 (text/plain, inline)]

* Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
  user for the server" (Wed, 26 Mar 2014 22:39:05 +0100):

> The GNU Health package runs its own dedicated Tryton server, under
> that gnuhealth user, unoconv would thus run under the same user as the
> Tryton server.

I think you are missing the point. Provided you are running a tryton-server and
a gnuhealth-server under different users on the same machine, it will be
painful (read: impossible AFAIK) to run a unoconv service for both of them or
for each of them.

> I will close this issue as the current situation is the best for the
> Debian users of GNU Health.
> You are obviously free to add more details and argument your position,
> should you think this presents major issues for Debian or its users.

Done. I don't think the current way is the best way to do it. I still can't see
the added value in using an additional system user compared to the
complications it can cause.

Mathias


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[signature.asc (application/pgp-signature, attachment)]

Message #25 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien@klein.st>

To: Mathias Behrle <mathiasb@m9s.biz>

Cc: 707639@bugs.debian.org

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

Date: Thu, 27 Mar 2014 13:06:53 +0100

2014-03-27 12:46 GMT+01:00 Mathias Behrle <mathiasb@m9s.biz>:
> * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
>   user for the server" (Wed, 26 Mar 2014 22:39:05 +0100):
>
>> The GNU Health package runs its own dedicated Tryton server, under
>> that gnuhealth user, unoconv would thus run under the same user as the
>> Tryton server.
>
> I think you are missing the point.

It's because I'm coming from a different angle than you. Read on ;)

> Provided you are running a tryton-server and
> a gnuhealth-server under different users on the same machine, it will be
> painful (read: impossible AFAIK) to run a unoconv service for both of them or
> for each of them.

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)

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.

As mentioned, I consider the Tryton server package to be in a
"broken/unusable" state right after installation. 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 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.

>> I will close this issue as the current situation is the best for the
>> Debian users of GNU Health.
>> You are obviously free to add more details and argument your position,
>> should you think this presents major issues for Debian or its users.
>
> Done. I don't think the current way is the best way to do it. I still can't see
> the added value in using an additional system user compared to the
> complications it can cause.

Does my explanation below help you understand my point of view?
The core of the issue is not so much the dedicated user. It's the fact
that in the current situation we have 2 running Tryton servers. The
GNU Health-generated one is a precondition for the ease-of-use that I
want to provide to my users.

If there was a service-less tryton-server package, this issue wouldn't
be one. Would you be willing to accept a patch from me to do that?

    +Emilien

Message #30 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Emilien Klein <emilien@klein.st>

Cc: 707639@bugs.debian.org

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

Date: Thu, 27 Mar 2014 13:50:24 +0100

[Message part 1 (text/plain, inline)]

* Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
  user for the server" (Thu, 27 Mar 2014 13:06:53 +0100):

> 2014-03-27 12:46 GMT+01:00 Mathias Behrle <mathiasb@m9s.biz>:
> > * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
> >   user for the server" (Wed, 26 Mar 2014 22:39:05 +0100):
> >
> >> The GNU Health package runs its own dedicated Tryton server, under
> >> that gnuhealth user, unoconv would thus run under the same user as the
> >> Tryton server.
> >
> > I think you are missing the point.
> 
> It's because I'm coming from a different angle than you. Read on ;)

Seems so, yes;)
 
> > Provided you are running a tryton-server and
> > a gnuhealth-server under different users on the same machine, it will be
> > painful (read: impossible AFAIK) to run a unoconv service for both of them
> > or for each of them.
> 
> 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...

> 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.
 
> As mentioned, I consider the Tryton server package to be in a
> "broken/unusable" state right after installation.

To be precised. What is broken?

> 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.
 
> 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).
 
> >> I will close this issue as the current situation is the best for the
> >> Debian users of GNU Health.
> >> You are obviously free to add more details and argument your position,
> >> should you think this presents major issues for Debian or its users.
> >
> > Done. I don't think the current way is the best way to do it. I still can't
> > see the added value in using an additional system user compared to the
> > complications it can cause.
> 
> Does my explanation below help you understand my point of view?
> The core of the issue is not so much the dedicated user. It's the fact
> that in the current situation we have 2 running Tryton servers. The
> GNU Health-generated one is a precondition for the ease-of-use that I
> want to provide to my users.

You can run as many dedicated trytond's as you want (see above). No
separate system user required for that.

> If there was a service-less tryton-server package, this issue wouldn't
> be one. Would you be willing to accept a patch from me to do that?

No, I see no point in doing that. I think, the gnuhealth package should make
direct use of the tryton-server package.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707632

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Emilien Klein <emilien@klein.st>

To: Mathias Behrle <mathiasb@m9s.biz>

Cc: 707639@bugs.debian.org

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

Date: Sat, 29 Mar 2014 08:18:22 +0100

2014-03-27 13:50 GMT+01:00 Mathias Behrle <mathiasb@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@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

Message #40 received at 707639@bugs.debian.org (full text, mbox, reply):

From: Mathias Behrle <mathiasb@m9s.biz>

To: Emilien Klein <emilien@klein.st>

Cc: 707639@bugs.debian.org

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

Date: Sat, 29 Mar 2014 15:58:42 +0100

[Message part 1 (text/plain, inline)]

* Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
  user for the server" (Sat, 29 Mar 2014 08:18:22 +0100):

> 2014-03-27 13:50 GMT+01:00 Mathias Behrle <mathiasb@m9s.biz>:
> > * Emilien Klein: " Re: [Debian-med-packaging] Bug#707639: gnuhealth: System
> >   user for the server" (Thu, 27 Mar 2014 13:06:53 +0100):

<snip>

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

Ok, so let do some nitpicking. If you want to make assumptions, the please make
the correct ones. For Debian as the Universal Operating System, it wants to be,
it is most adequate to not restrict any use of a software while respecting
common security standards.

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

This assumption seems to be caused by a (constant) misunderstanding on your
side. If they are using GNU Health, they *are* using Tryton. Tryton is a
framework, and the gnuhealth modules are just another module set using the
framework. Duplicating tryton-server into gnuhealth-server is a conceptional
error (I know I am repeating mayself, but there is no other answer to this
issue.). 

So again:
You are completely free to use any postgres role together with any postgres
database you wish. That's perfect and such is the design.
Creating a further system user to run a separate additional trytond instance
for gnuhealth doesn't provide any additional gain securitywise, it just causes
problems.

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

You are confirming, that the gnuhaelth package design is broken.

All problems you are depicting are raising from the fact, that you are running
a second trytond under a different user. 

This *is* useless, as you are confirming yourself. If a user installs
gnuhealth, there is a probability, he mostly will want to use those modules. He
wants to run a trytond under a system user account using the gnuhealth modules.
This is exactly provided by the tryton-server package running under its system
user. No matter if the system user is called 'tryton', 'gnuhealth' or
'emiliend'. 

> 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

This correlates with the common Debian security standards to listen and
restrict access to localhost. Please see other servers like postgresql, etc.
for their well choosen defaults. Finally you are documenting, that gnuhealth is
broken, if it chooses by default to expose a fresh installation on an external
interface.
 
> >> 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.

You were pointed in other threads to the fact, that over-optimization tends to
complicate things. I am absolutely respecting your good will to ease things
as much as possible. But there is a clear conflict of aims between simplified
handling and responsible handling of software managing sensible data. Servers
managing data of such kind should be managed by persons who know what they are
doing.

Ready to use installations can (and should) much better be performed by
providing virtual appliances.

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

Perfect, This is the concept of Tryton as depicted above.

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

Which base are you talking of?
 
> 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@gnu.org mailing list and have
> them clarify their recommendation. At that point I'll happily follow
> whatever upstream recommends to install their software.

Your choice to push the mails just to another channel I am not following and
that is outside Debian . BTW for questions relating to server setup the correct
upstream would be tryton.org.

Cheers,
Mathias

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.