Re: [Fwd: [Bug translator/6565] network compile server, stage 1]

[fche at redhat dot com (Frank Ch. Eigler)]

Dave Brolley <brolley@redhat.com> writes:

> [...]
> My current issues with the implementation are:

Re. the hard-coded port number, you could just as easily make it
automatic and random, as soon as the client can discover a suitable
server "by content" rather than by address.


> o I still need to finish defining what the client should be looking
> for when looking for a compatible server. There has been some loose
> discussion, but I need to nail this down.  Currently only `uname -r`
> is checked.

Over time, this will need to consist of several blobs.  For the
immediate future, as Josh said, "uname -rvm" or something should do.

Once we have signatures, the client will want to only talk to servers
who can sign modules authorized to run locally.  So the server will
need to advertise what signing keys it has (by fingerprint), and the
client will need to search for a match.

Once we probe userspace, we're into a heap of trouble :-), since the
"uname -rvm" only identifies the kernel version and not the
(rpm/buildid) versions of the libraries/binaries being probed.  The
server would have to have the same version for all the probed software
that is running on the client.  It is unlikely to be practical for the
server to publish versions/hashes of each individual program it is
willing to instrument, so ...

One way to do this would be for the server to publish a digest code
(look up "bloom filters" and "squid cache digest") that includes a
sparse hash/bitmap of all the software it has symbol and/or dwarf data
for.  The client could compute what it needs (probably based upon a
thin parse of the systemtap script -- a change from today -- probably
suggesting that stap-client will need to grow into stap proper; see
bug #3498 for a proposed partition of pass 2 that could ease this) and
look for a (probabilistic) intersection between the published blob and
its locally computed "needs" blob.

In case of multiple servers all appearing to be suitable, a client
could opt to chat with each of them (in parallel or series), and
choose the first successfully built/returned kernel module.


> o How does the client establish that a given server is trusted.  I've
> read Roland's remarks on the subject of client/server security and
> will be reading them again to see if any of it will sink in.

(See the "server publishes signing keys" item above.)


> o In order to get around the problem of tcp connections being closed
> after a file is sent, the current implementation uses one port for
> synchronization (which remains connected during the entire
> transaction) and another for file transfer (which is opened and
> closed as each file is transferred). [...]

Right, this is indeed undesirable.


- FChE