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
