Lily Li writes:
> And I had thought we could just integrate the shmux "as is", ie. remain 
> 'fping' and '-p' option, two reasons:
> - ordinary users(who do not have permission to run fping) still can use 
> all other features of shmux except the optional '-p', moreover, even 
> with '-p', the output of shmux will still be expected.
> - after all, for root or those users who had been granted the 
> permission, they can run shmux with '-p' option as they will.

How does this compare with the use of shmux on other platforms?  Is it
expected that "-p" is an unusual option that will require extra
privileges to invoke?

How are you proposing that it will work on Solaris?  If I'm assigned
the 'Network Management' profile, will that be enough (i.e., will
'shmux' automatically do the 'pfexec' for me when it runs fping?), or
do I need something else to make it work?

Do I really need to be all-powerful root in order to use "-p"?

> > On Fri, Mar 06, 2009 at 10:38:38AM -0500, James Carlson wrote:
> >   
> > A tool like shmux that can't talk to its targets in parallel so that one
> > unreachable target need not slow everything down is not worthy of
> > integrating.  If shmux can do that then it doesn't need a -p option.
> >
> > Thus I'm for "removing the silly "-p" option."
> >
> >   
> I'd like to remove the '-p' option by adding a patch, if you all think 
> it is better for integrating shmux to solaris.

I didn't actually write the text quoted above (it's misattributed to
me, and was apparently written by Nico).

However, I do think it requires some thought.  I don't agree that
invoking the shmux "-p" option should require any special work on the
user's part, nor do I agree that it ought to require any elevated
privileges.

It appears to be an option intended for use by *ordinary* users.  If
it doesn't in fact work that way, then it's broken, and the porting
effort to OpenSolaris is necessarily incomplete.

Thus, there are a few possible solutions, and I'd like to hear from
the project team on how they'd like to go forward.  The solutions I
can imagine are:

  - The project team determines that the "-p" option doesn't actually
    do anything useful in real networks, and thus it's just removed.

  - The project team determines that there's something else that the
    implementation could do (such as timing out quickly on connect()
    and/or using non-blocking connections) to make implementation of
    "-p" worthless, and thus removes it and contributes bits upstream.

  - The project team determines that "-p" really is needed, and finds
    some alternate way to implement it on Solaris, such as invoking
    regular 'ping' or creating some "safe fping" wrapper that is in
    turn given setuid.

> > (shmux does need a connect timeout option, 
> Yes, it has! Current shmux has three types of timeout: timeout of ping, 
> timeout of test and timeout of execution, please refer to the shmux 
> manpage(http://web.taranis.org/shmux/man/shmux.1.html):

No, it doesn't.  None of the timeouts you cited relates to the
connect(3SOCKET) operation itself.  The utility is just missing this
basic feature.

The -C option specifies the timeout for the entire command.  This
timer continues running after connect() succeeds, and thus must be set
to a long time.  The -T timeout is for the "echo" test.  Again, it
continues running after connect() succeeds, and thus must be
relatively long, though it *might* be short enough to be useful with
regular connection failures.  The -P timeout relates to ping, which
has nothing to do with connect().

Nico's contention (and I happen to agree with it) is that it's
completely pointless to do a "ping" test if you can do a connect()
with a short time-out and if you otherwise design the utility "right."
(Where "right" means that you open all of your connections in
non-blocking mode, then wait for them to complete using poll/select
[poll on write] with some short timer.  That way, you won't get
blocked on any one failing connection.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to