rsh ports... problems using them up - SGI

This is a discussion on rsh ports... problems using them up - SGI ; Just to bring up some history, this is from the posting I made on this back in 2001: > In article , > Christopher R. Jones wrote: > : > :Just for some added info... I've discovered that the sockets ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: rsh ports... problems using them up

  1. rsh ports... problems using them up


    Just to bring up some history, this is from the posting I made on this back in 2001:

    > In article <3A13DCF7.EAC692AD@larc.nasa.gov>,
    > Christopher R. Jones wrote:
    > :
    > :Just for some added info... I've discovered that the sockets that 'rsh'
    > :uses are privileged and limited to 512-1024. So now I've got to figure
    > ut if there's a tuneable kernel parameter to change this. There are
    > nly tons of kernel parameters here.... (btw - the system is running
    > :6.5.7m).
    >
    > How many near-simultaneous instances of rsh are you running? If
    > you're talking in the neighborhood of hundreds, it'd probably be a
    > better idea to use something like ssh. rsh has inherent limitations
    > in the privileged ports it can use. If it's a case of gobs of quick
    > rsh instances, you might be able to get away with tuning tcp_2msl
    > lower, but that'd be only a stop-gap measure.
    >
    > :Anybody know of a kernel parameter that would help me here?
    > :
    > :-chris
    > :
    > :"Christopher R. Jones" wrote:
    > :
    > :> I've got errors on one of our Origin's when some scripts run...
    > :> basically it dies at some point with:
    > :>
    > :> >rsh: connection failed
    > :> >socket: All ports in use
    > :>
    > :> Of course this always happens on 3rd shift when there are no system
    > :> admin.'s around so I don't know what the status of the system is. But
    > :> I'm thinking that the system has hit the limit of usable ports. I'm
    > :> that knowledgeable when it comes to ports, so I'm not sure where to
    > :> start here on getting this working.
    > :>
    > :> I searched the past postings and didn't see anything that seemed
    > :> helpful. So whatever anybody could pass on would be nice.
    > :>
    > :> Thanks!
    > :>
    > :> -chris
    > :
    >
    >
    > --
    > Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: mjo@dojo.mi.org
    > Royal Oak, Michigan | (has my PGP & Geek Code info) | Phone: +1 248-427-4481


    Now the system in question that this was referencing has been running 6.5.17 for close to two years, and yesterday it got upgraded to 6.5.25 (it's a high-level enough production machine that it took *forever* and the planets to align to finally get it upgraded).

    The problem documented above with running out of rsh sockets hasn't happened in a while, and for the times when it did folks actually put stuff in their code to check the status of open ports before running. But something has changed with the upgrade that I can't put my finger on. A user runs some script that opens up rsh's to another system doing commands and keeps doing it one by one until the task is complete. This used to work fine, and now their getting errors like this:

    "rsh: connection failed"
    "rcmd: socket: Address already in use"

    Back before, we had written a little perl script to tell us the number rsh ports (and the limit is 512 of them) in use that we'd use to quick check when a user had a problem ... then we'd go "see! you're using up all the available ports!" Well, using it now you can see the limit pretty much getting hit when before yesterday it didn't.

    So I had the user duplicated their work from a system running 6.5.18 (close enough to .17 I figured... ) and sure enough it works fine there, and the port count never gets above the high 300's for a count.

    I conclude minimally that there's some system configuration changes between 6.5.17 and 6.5.25 (I know... it's a big jump in operating system level) that's causing this to all of a sudden hit the count limit.

    Can anybody out there who understands all of this (possibly Mike O'Connor from SGI if you see it... ) give me some suggestion on where to look?

    Thanks!

    -chris

    --
    Chris Jones
    (to email me, just take out the NOSPAM)

    Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
    This email address may not be added to any commercial mail list with out
    my permission. Violation of my privacy with advertising or SPAM will
    result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

  2. Re: rsh ports... problems using them up

    Chris Jones writes:

    > Just to bring up some history, this is from the posting I made on this back in 2001:


    To which somebody already replied back then:

    > > How many near-simultaneous instances of rsh are you running? If
    > > you're talking in the neighborhood of hundreds, it'd probably be a
    > > better idea to use something like ssh. rsh has inherent limitations
    > > in the privileged ports it can use.


    Is ssh still not an option to you - even though it's now included in
    IRIX?

    --
    Atro Tossavainen (Mr.) / The Institute of Biotechnology at
    Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
    +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
    < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

  3. Re: rsh ports... problems using them up

    Atro Tossavainen wrote:
    > Chris Jones writes:
    >
    >
    >>Just to bring up some history, this is from the posting I made on this back in 2001:

    >
    >
    > To which somebody already replied back then:
    >
    >
    >>>How many near-simultaneous instances of rsh are you running? If
    >>>you're talking in the neighborhood of hundreds, it'd probably be a
    >>>better idea to use something like ssh. rsh has inherent limitations
    >>>in the privileged ports it can use.

    >
    >
    > Is ssh still not an option to you - even though it's now included in
    > IRIX?
    >


    Sure, ssh is an option, but it slows down the speed of the transactions that occur enough that it was deemed not a possibility here.

    -chris

    --
    Chris Jones
    (to email me, just take out the NOSPAM)

    Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
    This email address may not be added to any commercial mail list with out
    my permission. Violation of my privacy with advertising or SPAM will
    result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

  4. Re: rsh ports... problems using them up

    Chris Jones writes:

    > Sure, ssh is an option, but it slows down the speed of the transactions
    > that occur enough that it was deemed not a possibility here.


    How slow is slow? (How did you measure this?)

    SSH slowness can usually be improved.

    Is it the time it takes to log in, or the actual speed of data transfer
    while in session?

    How long are the login sessions? (I.e. is the time taken to log in
    significant to the length of the session itself? Do you really need
    to worry about it?)

    If the login itself is taking too long, do you have proper reverse DNS
    (ssh expects that!)? If not, just disable the rDNS lookups in ssh.

    If the speed of data transfer is an issue,

    * you can probably use a faster cipher instead of whatever is the default

    * you can use SSH1 instead of SSH2 (since this is an environment where
    you would normally use rsh, the security implications of using the
    older protocol version are not an issue)

    * you can recompile SSH with -O2 -OPT:Olimit=0 -INLINE:all and expect
    serious gains in performance

    --
    Atro Tossavainen (Mr.) / The Institute of Biotechnology at
    Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
    +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
    < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

  5. Re: rsh ports... problems using them up

    Atro Tossavainen wrote:
    > Chris Jones writes:
    >
    >
    >>Sure, ssh is an option, but it slows down the speed of the transactions
    >>that occur enough that it was deemed not a possibility here.

    >
    >
    > How slow is slow? (How did you measure this?)
    >
    > SSH slowness can usually be improved.
    >
    > Is it the time it takes to log in, or the actual speed of data transfer
    > while in session?
    >
    > How long are the login sessions? (I.e. is the time taken to log in
    > significant to the length of the session itself? Do you really need
    > to worry about it?)
    >
    > If the login itself is taking too long, do you have proper reverse DNS
    > (ssh expects that!)? If not, just disable the rDNS lookups in ssh.
    >
    > If the speed of data transfer is an issue,
    >
    > * you can probably use a faster cipher instead of whatever is the default
    >
    > * you can use SSH1 instead of SSH2 (since this is an environment where
    > you would normally use rsh, the security implications of using the
    > older protocol version are not an issue)
    >
    > * you can recompile SSH with -O2 -OPT:Olimit=0 -INLINE:all and expect
    > serious gains in performance
    >


    Unfortunately I don't have the details on how slow is slow, but I know it was slow enough for folks to not like that as a solution. I believe it's the time of data transfer that's slow... we have a lot of data that moves between systems here (sometimes terabytes weekly). I'll look into the cipher change, and as far as compiling goes, that's not an option. We have purchased ssh software and it's just installed binaries... no compiling.

    All of this is also nice and good discussion, but it takes away from the root question I had in my initial post. So I'm still looking for somebody to chime in on that.

    -chris

    --
    Chris Jones
    (to email me, just take out the NOSPAM)

    Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B)
    This email address may not be added to any commercial mail list with out
    my permission. Violation of my privacy with advertising or SPAM will
    result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

  6. Re: rsh ports... problems using them up

    Chris Jones writes:

    > we have a lot of data that moves between systems here (sometimes
    > terabytes weekly).


    I'm not sure I would be using {r,s}sh for that in the first place.
    Do you have other options? NFS or rsync perhaps?

    The ssh speed issue is probably different with gigabit networks and
    slow processors. We only have SGI systems in 100Mbit/s networks,
    so I don't really know.

    scp (SSH Comm Sec Corp. ssh1, blowfish, compiled with the flags I
    indicated) goes up to 8.3 MB/s on a 600 MHz R14000 Fuel on a large
    bz2 file. The receiving end was a significantly faster Linux machine
    on gigabit so it wasn't the bottleneck. If I had to settle for 80%
    of the theoretical maximum performance, I might consider that
    acceptable... On the other hand, the same test from a 180 MHz R10000
    Origin 200 only reached 2,7 MB/s (with the same ssh binaries), but
    the machine is easily capable of saturating the 100Mbps network if
    encryption is not involved. That would clearly not be acceptable at
    all.

    > and as far as compiling goes, that's not an option. We have purchased
    > ssh software and it's just installed binaries... no compiling.


    Perhaps you could ask the vendor to recompile. It wouldn't hurt to
    get that extra bit of performance from ssh even if it's not going to
    be The Way to replace rsh for this particular use of yours.

    --
    Atro Tossavainen (Mr.) / The Institute of Biotechnology at
    Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
    +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
    < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

  7. Re: rsh ports... problems using them up

    Atro Tossavainen writes:
    > Chris Jones writes:
    >
    > > we have a lot of data that moves between systems here (sometimes
    > > terabytes weekly).

    >
    > I'm not sure I would be using {r,s}sh for that in the first place.
    > Do you have other options? NFS or rsync perhaps?


    I find that using netcat to transport files after accessing the system
    with ssh does provide just the performance and level of security needed
    in many cases, sometimes 'gzip -1' adds to the performance (depends on
    the data). OTOH, it's not as easy to use as rcp or scp (although
    that can be improved with scripting).

    Thomas Jahns
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

+ Reply to Thread