Krzysztof A. Adamski wrote:
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
You're using "client" here in the way we mean "overlord". That
terminology is used to disambiguate client/server. For instance, a
minion is a client of the overlord, but /usr/bin/func is a "client", yet
the minion is running a daemon which is a server. Complicated :) ... So
to be clear, this is about getting the overlord working on Windows :)
I'm very interested in seeing Func work on Windows -- but particularly
the minion for control of mixed networks -- I think Krzystof hit the
high points, but I think it would be best if we could get the entire
minion working -- there should be Windows versions of the associated
crypto libraries, and I am not sure the Func libraries are all that
interesting without a minion running. Making the async parts cross
platform would be fine.
Patches to get all of this going would be very cool to see.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
