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. 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. 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) 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. > This is some steps you could take to init a GNU Health instance called > "gnuhealth" > > 1) Create the DB with the UTF8 encoding. I believe that the DB encoding > might have been the cause of the encoding error you encounter at first. > > $ createdb gnuhealth --encoding=unicode > > 2) Init the Tryton instance and the core health module with its > dependencies (country, party, currency, company and product). This > little BASH loop would do the job. > > $ for health_core_mods in ir country party currency company product > health; do ./trytond --init=${health_core_mods} --database=gnuhealth; > done > > The server will ask you for the admin passwd at the terminal > window after installig the "ir" module. If you don't want to enter the > admin password at the termina, you can put the passwd on a temp file and > refer to it with the TRYTONPASSFILE environment variable before > executing the for loop. > > 3) Start the Tryton server > $ ./trytond > > 4) Start the Tryton client, you will be presented with the wizards to > create the users and company (the health institution). From there, you > can pick other modules or just work on the core GNU Health > functionality. > > You should be done. Sounds complicated to me :-) > 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 > This is of course my opinion, and there might be scenarios where a > non-interactive installation as just depicted can be very valid. > > In the case of upgrades, we send the instructions as per release (normally > just --update=all ). But you if the maintainer includes it on the > package, fantastic :) > > What I would take in consideration for to always include in the package, > independently of the GNU/Linux distribution are : > > - All the modules included on each release's tar.gz file > - Create the gnuhealth user at OS level and give the appropiate DB > permissions. > - GNU Health user bashrc file > - GNU Health user aliases, matching the directory and file locations of > the specific distro (cdexe, editconf, cdlogs, cdconf... ). They are in > the $HOME/.gnuhealthrc file when using the standard/generic installer > (gnuhealth_install.sh) > - Start and stop scripts. > > This is important, so, independently from the distro used, the user > will find the GNU HEalth book easy to follow (or at least that's our > goal :) ). They are also very handy to make go to the right place and > edit the right file. 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) I honestly cant imagine that the Jamaican infrastructue will run under a login-user....it is a high security risk. I dont see the benefit that this approach takes. I feel that [1] addresses the issue in a similar way Let me know your thoughts, Axel [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707639
Attachment:
signature.asc
Description: This is a digitally signed message part.