This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]