Hi, Axel ! On Wed, 21 Jan 2015 12:08:27 +0100 "Axel Braun" <axel.br...@gmx.de> wrote:
> Hi Luis, > > > > > I will be releasing tonight or tomorrow RC2 tarball, so you can > > > > download and test the installation process. > > > > > > looking forward to this! > > > > > The tarball should be up today :) I just uploaded the latest rc2 > > to the community server. > > as already noted, that was unfortunately the 2.6rc2.... Fixed :) Thanks ! > > ... > > > > > At this point, and to save time, please make sure your > > > > distribution has the cracklib and python2.7-cracklib bindings. > > > > The one on pypi is not up-to-date, so best it to install the > > > > package from your specific OS or distro. The latest stable > > > > version is 2.9.2 . > > > > > > Is this a hard requirement to use 2.9.2? > > > > It's called by the standard installation program. Take a look at the > > security chapter on GNU Health[1] (work in progress). There is a > > section on serverpass. > > Understand. It seems that just the python-cracklib is in release > 2.8.xx while cracklib in most distros is between 2.9.0 and 2.9.2 > > > > One more question on the sync module: The tryton_synchronisation > > > is not (yet) released as module on tryton, is it planned to do so? > > > > > For what I've been talking to Cedric, the synchro engine is not > > part of the main package at this point. > > Hm, too bad. > I understand it as a Tryton feature, not a GNU Health feature, so > Tryton should be the place to publish this as module. Or maybe > tryton-es can help out... The Tryton synchro engine has been initially developed in the context of GNU Health, but I do agree with you, that it would be great if it is part of the main Tryton release, as many other scenarios will find this functionality *very* useful. If the Tryton community finds it useful, then it should be part of the standard Tryton modules / code. At any rate, GNU Health will be using the synchronization / distributed environment functionality it since the upcoming 2.8 and next versions. > > > > As you wrote in task #13407 (project health): > > > On Sunday 11th ( 2.8 Release Candidate 1), the community server > > > should be configured as the central instance, and will accept > > > synchronizations from satellites. > > > > > > Will this be the 'frozen' version of the Demo -DB? Otherwise each > > > client will sync all changes that users make to the demo-db as > > > well. Where can the ID for the server been looked up? > > The central instance ID is always 0. But that happens behind the > > scenes. The id that you have to set is in your satellite instance. > > > > The server database will be the same as the one we use. It will > > bounce/reset everyday. > > So for an end user who wants to keep in sync with the latest master > of the GNU Health Demo database it would make sense to sync the > master copy. It's a bit more involved than that. You sync only models that you want to be part of the synchronization model. That give you the flexibility of keeping some data / information local (eg, local stock, staff, ..), and share other info that is part of the global environment (eg, epidemological info). > > > I'm also documenting on Wikibook the Synchronization engine for GNU > > Health[2] . > > Yep, had a look at that as well. The URL from the documentation: > > synchronisation_url = > http://user:passw...@health.gnu.org:7500/name_of_the_central_instance_database > > would send unencrypted user:password through the net. Should it not > be by default https with forward secrecy enabled? What URL can be > used by an end-user to pull the demo-DB? > > > > > 1.- https://en.wikibooks.org/wiki/GNU_Health/Security > > 2.- https://en.wikibooks.org/wiki/GNU_Health/Synchronization_Guide > > > > PS: This version should have been called "time to document :)", but > > I feel that documentation has been one of our pending jobs, and > > it's about time to really work on this. > > Documentation is always the thing that developers like most, isn't it > so since soem 100 years? ;-) :-) I'm starting to like it, maybe some sort of defense mechanism :) Best, Luis > > Cheers > Axel > >
