Re: func client library

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

 



On Thu, 21 Aug 2008 19:49:38 -0400
"Rob Crowell" <rcrowell@xxxxxxxxxxxx> wrote:

> 1.       I'm reading over the wiki and the source, and am running
> into a few sticking points which I don't understand.  First off, the
> minions and the overlord communicate using SSL.  What sort of
> authentication exists between a client and the overlord?  Is there
> any sort of access-control or encryption with this communication?
Minions are authenticated by their SSL certificate. It is generated
when minion daemon starts for the first time and it has to be signed by
overlord (by default, it has to be done manually by administrator).
Minion can only be controlled by the overlord with the proper SSL key
(by which it's local key was signed). There is also ACL mechanism that
can be used to define which methods can be called by which overlords,
too.


> The Overlord object relies on jobthing and forkbomb, both of which
> require unix-only modules (dbm, fnctl, os.fork).  
Indeed. You have to made Windows versions of this modules if you want
to use async or nforks.

> 
> 2.       To handle nforks/async calls, I'm thinking about writing a
> module that accomplishes the same but uses regular python threads for
> windows programs to use.  Any reason this wouldn't work, or things I
> should look out for?
Threads are evil, that's all.. Not all Python modules are thread-safe
even when they claim to be. We had quite a lot of problems with
PyOpenSSL which was deadlocking. As far as I know the problem is fixed
in the mainstream PyOpenSSL code but we still want to support old
distros. There was no good reason for us to use threads - performance is
not critical here, reliability is. 

> 
> 3.       Rather than using the UNIX-only dbm module and locking
> provided by fnctl.flock, I'll find some other cross-platform
> solution.  Seems like the strategy here is for all of the child
> threads to write into a shared file, each exclusively locking it in
> turn, until all of them finish and sys.exit(0).  The parent then
> reads the shared file to return all of the results.  (Please correct
> me if this analysis is incorrect!) This can be done using other
> methods, perhaps even using traditional python thread locks.
You are right here. Our solution is not ideal and we look forward for
some better ideas. I don't think we want to use threads exclusively
because of the reasons mentioned earlier. 

All that said, if you manage to do this all without deadlocks and
memleaks, that could be interesting to have.

_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux