Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
2014-03-27 13:50 GMT+01:00 Mathias Behrle mathi...@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
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
* 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 mathi...@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
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
* 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 Description: PGP signature
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
2014-03-27 12:46 GMT+01:00 Mathias Behrle mathi...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
* 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 mathi...@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 Description: PGP signature
Bug#707639: [Debian-med-packaging] Bug#707639: gnuhealth: System user for the server
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
