health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Update base packages : python2.7-cracklib


From: Luis Falcon
Subject: Re: [Health-dev] Update base packages : python2.7-cracklib
Date: Thu, 22 Jan 2015 12:03:34 +0000

Hi, Axel !
On Wed, 21 Jan 2015 12:08:27 +0100
"Axel Braun" <address@hidden> 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:address@hidden: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
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]