* 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 <[email protected]>: > > * 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 [email protected] 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
Description: PGP signature
