Hi Axel, 2014-03-28 12:09 GMT+01:00 Axel Braun <[email protected]>: > Hi all, > > Am Donnerstag, 27. März 2014, 01:05:21 schrieb Luis Falcon: > > [snip] > > I have been reading through this lengthy discussion , and was not sure if I > should add my 2c. > > As I'm more coming from the user perspective, I will.
That is great, very helpful. > 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. If on the other hand you want to upgrade and have your package continue to work without manual intervention, you can also choose to have the database created by the system (you still choose which GNU Health modules to activate, just as when the database is created manually), and the package will apply the upgrade scripts for you. It is sound to still perform your backups regularly, and as a safety net the package will make a backup just before upgrading (but only if the package knows about which database you use, i.e. the database was created by the package) > Unless a user is in the trial and error phase (Demo DB/CD...) , he has to dive > in a little deeper into the context (at least to determine which modules he > really needs) Correct. This is what the Debian package allows: regardless if the database is created with the package or not, you still have to indicate which packages to use the first time you open Tryton (I'm making a change to not initialize all the modules, that was a mistake I assume) > Technical setup of tryton is IHMO well described and possible for an average > user. > I would not try to 'oversimplify' and by this make it more complicated. Again, I don't see how it's oversimplified or made more complex. The only thing that is done, is create a Postgres database (so that the package knows how it's called, and can apply the upgrade scripts provided by GNU Health when new versions are released), and initialize the basis Tryton modules, so that the Tryton client recognizes that database as a Tryton database. You then log in and select which GNU Health modules you want to use. As mentioned, you jump straight to step 4 "Logging into the application" [2] of the GNU Health installation steps, you will then perform step 5 "Installing the default modules" and can also do step 6 "Installing Extra Modules" if you want to. [snip package code] > Sounds complicated to me :-) Axel, these are not steps the user would perform. this is what is performed by Tryton when you manually tell it to create a database, and would be performed by the Debian package code. >> NOW... that said, I prefer *not* creating a db instance as part >> of the package installation process, because >> >> - It's very easy to use the Tryton client to create the instance from >> scratch, including the database and admin user/password >> - You can choose your own DB name for each instance, for the sandbox, >> development, test and production instances you would need to specify >> different DB names >> - You avoid all those scripts/loops/variables that I put in previous >> paragraphs :) > > Agree No problem, you can absolutely do that with the Debian package, just answer No to the question if you want the package to create the database. But be informed that you will have to read each upgrade installation information. I am afraid some users might be at risk of forgetting that. > 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. 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. > 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. > I dont see the benefit that this approach takes. Let's move this discuss over to the [email protected] 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. +Emilien [2] http://en.wikibooks.org/wiki/GNU_Health/Installation#Logging_into_the_application -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/canqxmqe8tyag4kcrwkad_yajt5qx41mnj4xlqidoywoyss-...@mail.gmail.com
