It is possible to execute a remote command that causes the xmlrpc
communication in func to bomb. I have had this happen in several
ways, but the most common one I see is from init scripts that don't
function properly when running non-interactively (or maybe this is
just due to the way func executes things in a shell on the remote
end...). The output will attempt to be colorized and the control
characters cause the XML to go invalid. Another common example is
puppet; when run without the --color=false flag it breaks.
I can run the following command to reproduce this behavior (it's just
trying to print "test" in red):
$ sudo func '127.0.0.1' call command run 'echo -e "\033[0;31;40mtest\033[0m"'
('127.0.0.1',
['REMOTE_ERROR',
'xml.parsers.expat.ExpatError',
'not well-formed (invalid token): line 9, column 15'])
The client (overlord) side xmlrpclib.ServerProxy allows an optional
encoding to be set. However, although present in xmlrpclib,
SimpleXMLRPCServer (or more specifically, SimpleXMLRPCDispatcher) does
not support encoding until python >= 2.5, which is a no-go in order to
maintain el4/5 support for func.
I propose the following, assmuming it will be reasonably
straightforward and not pull in a ton of unexpected deps:
- Ship the python 2.5 version of SimpleXMLRPCServer bundled with func
- Update the server (minion) code to use this bundled version on
python < 2.5, otherwise use the standard library version
- Update the minion and overlord to base64 encode xmlrpc traffic
I will throw together a proof of concept for this hopefully sometime
Monday. If anybody has thoughts / opinions / suggestions by all means
let's hear them!
- John
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
