This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: http://sourceware.org/bugzilla/show_bug.cgi?id=11441
Hi -
brolley wrote:
> [...]
> Something like --add-auth and --del-auth are ok with me. As for 'local'
> and 'global' being bad choices, how about 'user' and 'all'?
Sure.
> >Re. stap --server-status=trusted, how would stap determine the
> >trustedness of remote servers? Do they advertise their ssl/signing
> >keys?
>
> As a trusted peer, successfully establishing a ssl connection is
> sufficient. As a trusted signer, I was thinking that the server would
> sign some random chunk of data and that stap would verify the signature
> in the same way that staprun verifies a signed module.
So it would require an active search & trial connections. How about
'stap --server=search' or something like that, to produce a listing of
nearby peers? Filtering on trustedness etc. could be done by the user
via grep.
> I guess this also implies more specific option names for stap in order
> to distinguish what is being authorized:
>
> --add-server-auth=[current|all]
> --del-server-auth=[current|all]
> --add-signing-auth
> --del-signing-auth
Yup.
> >Some suggestions:
> >
> >The stap --daemon option should support invocation via inetd (i.e.,
> >with live sockets on stdin/stdout, with port numbers indirectly
> >assigned by sysadmin), as well as a self-serving mode where stap picks
> >a port number for itself, optionally advertises via avahi, and loops
> >in an accept(2) loop.
> >
> Ok. How about --daemon[=inetd] in order to distinguish the two modes?
OK.
> [...] Overall, I believe that the other issues are reason enough to
> consider merging components.
OK, probably so. I'm not quite sure yet about whether the entire
server-side stack belongs best into stap proper or single helper
program.
> >I wonder actually if it would make more sense to merge the *client*
> >side into stap first, then see if merging stap-server into stap is
> >still necessary. After all, it is the client side that a normal user
> >sees, and automation/transparency at that point would be ideal.
> >
> I don't have a strong opinion on which to merge first.
OK, let's please start with the client then.
Hm, how should the client decide whether to look for a server vs.
attempting local compilation of a script? 'stap --server=XXX' i.e.,
on user's demand? Or automatically (in case of a pass 2/4 error
indicating missing debuginfo/kernel-devel)?
> Assuming installation via the systemtap, systemtap-client and
> systemtap-server RPMs:
> [...]
Looks good.
> Notes:
> [...]
All good.
- FChE