Is anyone still putting this in /etc/system?

set nfssrv:nfs_portmon = 1


I have always thought is was a good idea.  However, when the network
goes away for a short time (10 or 15 minutes) Solaris clients will
begin to use unprivileged ports for their tcp nfs mounts.  The server
will then refuse the mounts and the clients, most of the time, need to
be rebooted, which is a definite knock against Sun when hundreds of
hosts need to be rebooted.

B

Sorry, but NFS clients switching over to using ports over 1024 is just
wrong.
Must be time to move to Linux.

B

unixrules2003@removethis.yahoo.com.nospam wrote:
> Is anyone still putting this in /etc/system?
>
> set nfssrv:nfs_portmon = 1
>
>
> I have always thought is was a good idea.  However, when the network
> goes away for a short time (10 or 15 minutes) Solaris clients will
> begin to use unprivileged ports for their tcp nfs mounts.  The server
> will then refuse the mounts and the clients, most of the time, need
to
> be rebooted, which is a definite knock against Sun when hundreds of
> hosts need to be rebooted.
> 
> B

"unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> writes:

>Is anyone still putting this in /etc/system?

>set nfssrv:nfs_portmon = 1


>I have always thought is was a good idea.  However, when the network
>goes away for a short time (10 or 15 minutes) Solaris clients will
>begin to use unprivileged ports for their tcp nfs mounts.  The server
>will then refuse the mounts and the clients, most of the time, need to
>be rebooted, which is a definite knock against Sun when hundreds of
>hosts need to be rebooted.


It's obviously a bug (thorugh I would characterize 10minutes as
long).

You should not overestimate the protection that "reserved ports"
offer; any old system with superuser access has complete access
to all NFS files.

If you are serious about NFS security, then you should use one
of the more advanced security options.

Which exact release of Solaris does this occur with?

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H. S. Dik wrote:
> "unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com>
writes:
>
> >Is anyone still putting this in /etc/system?
>
> >set nfssrv:nfs_portmon = 1
>
>
> >I have always thought is was a good idea.  However, when the network
> >goes away for a short time (10 or 15 minutes) Solaris clients will
> >begin to use unprivileged ports for their tcp nfs mounts.  The
server
> >will then refuse the mounts and the clients, most of the time, need
to
> >be rebooted, which is a definite knock against Sun when hundreds of
> >hosts need to be rebooted.
>
>
> It's obviously a bug (thorugh I would characterize 10minutes as
> long).
>
    In a large distributed network it is not uncommon for a building
that supplies network for another building to lose power for longer
than what the switch's UPS can handle.  It seems like a very strange
thing for the clients to do.

> You should not overestimate the protection that "reserved ports"
> offer; any old system with superuser access has complete access
> to all NFS files.
>
     I realize, but I'd like to leave that set on the server.

> If you are serious about NFS security, then you should use one
> of the more advanced security options.
>
> Which exact release of Solaris does this occur with?
>

      I've seen it happen in 8, 9 and now 10.

thanks,
B

> Casper
> --
> Expressed in this posting are my opinions.  They are in no way
related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

On Wed, 23 Mar 2005, unixrules2003@removethis.yahoo.com.nospam wrote:

> Must be time to move to Linux.

Go right ahead.  Linux's NFS implementation is *really* broken...
You'll be back.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Rich Teer wrote:
> On Wed, 23 Mar 2005, unixrules2003@removethis.yahoo.com.nospam wrote:
>
> > Must be time to move to Linux.
>
> Go right ahead.  Linux's NFS implementation is *really* broken...
> You'll be back.
>
  Ironic how my sarcasm gets responses, but my real questions weren't
getting any response.

B

> --
> Rich Teer, SCNA, SCSA
>
> President,
> Rite Online Inc.
> 
> Voice: +1 (250) 979-1638
> URL: http://www.rite-group.com/rich

"unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> writes:

>    In a large distributed network it is not uncommon for a building
>that supplies network for another building to lose power for longer
>than what the switch's UPS can handle.  It seems like a very strange
>thing for the clients to do.

They probably retry for a long time and then they run out of
reserved ports to try this with.


>      I've seen it happen in 8, 9 and now 10.


I'll investigate and see what happens.  Are the mounts
active (i.e., are processes actively stuck in the mounts
when the outage occurs?)

Casper

in article 1111593038.907114.164150@z14g2000cwz.googlegroups.com,
unixrules2003@removethis.yahoo.com.nospam at unixrules2003@yahoo.com wrote
on 3/23/05 7:50 AM:

> 
> Rich Teer wrote:
>> On Wed, 23 Mar 2005, unixrules2003@removethis.yahoo.com.nospam wrote:
>> 
>>> Must be time to move to Linux.
>> 
>> Go right ahead.  Linux's NFS implementation is *really* broken...
>> You'll be back.
>> 
>   Ironic how my sarcasm gets responses, but my real questions weren't
> getting any response.
> 
> B
> 

That's not really irony is it.

Casper H. S. Dik wrote:
> They probably retry for a long time and then they run out of
> reserved ports to try this with.
>
> >      I've seen it happen in 8, 9 and now 10.
>
> I'll investigate and see what happens.  Are the mounts
> active (i.e., are processes actively stuck in the mounts
> when the outage occurs?)
>
   Yes.  There are daemons always running and some cases login shells
to home dirs.

thanks,
B

> Casper

In article <4241957b$0$136$e4fe514c@news.xs4all.nl>,
	Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> "unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> writes:
> 
>>    In a large distributed network it is not uncommon for a building
>>that supplies network for another building to lose power for longer
>>than what the switch's UPS can handle.  It seems like a very strange
>>thing for the clients to do.
> 
> They probably retry for a long time and then they run out of
> reserved ports to try this with.
> 

If that's the case, wouldn't forcing udp stop it, or setting
tcp_time_wait_interval to a lower value (like 60000) reduce it?

>>      I've seen it happen in 8, 9 and now 10.
> 
> 
> I'll investigate and see what happens.  Are the mounts
> active (i.e., are processes actively stuck in the mounts
> when the outage occurs?)
> 
> Casper

-- 
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

"unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> writes:

> Rich Teer wrote:
>> On Wed, 23 Mar 2005, unixrules2003@removethis.yahoo.com.nospam wrote:
>>
>> > Must be time to move to Linux.
>>
>> Go right ahead.  Linux's NFS implementation is *really* broken...
>> You'll be back.
>>
>   Ironic how my sarcasm gets responses, but my real questions weren't
> getting any response.

If all you want is responses and not answers,
there are lots of people here that can help.
You should have said so.

:)

Richard L. Hamilton wrote:
> In article <4241957b$0$136$e4fe514c@news.xs4all.nl>,
> 	Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> > "unixrules2003@removethis.yahoo.com.nospam"
<unixrules2003@yahoo.com> writes:
> >
> >>    In a large distributed network it is not uncommon for a
building
> >>that supplies network for another building to lose power for longer
> >>than what the switch's UPS can handle.  It seems like a very
strange
> >>thing for the clients to do.
> >
> > They probably retry for a long time and then they run out of
> > reserved ports to try this with.
> >
>
> If that's the case, wouldn't forcing udp stop it, or setting
> tcp_time_wait_interval to a lower value (like 60000) reduce it?
>

   UDP isn't an option since flow control is needed.  With a fast
server with a gigabit connection, slow clients can be overwhelmed...
Not sure if changing tcp_time_wait_interval is a good solution or not.
Any thoughts before I try that?

B

> >>      I've seen it happen in 8, 9 and now 10.
> >
> >
> > I'll investigate and see what happens.  Are the mounts
> > active (i.e., are processes actively stuck in the mounts
> > when the outage occurs?)
> >
> > Casper
>
> --
> mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil
>
> Lasik/PRK theme music:
>     "In the Hall of the Mountain King", from "Peer Gynt"

In article <1111605460.972120.262490@o13g2000cwo.googlegroups.com>,
	"unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> writes:
> 
> Richard L. Hamilton wrote:
>> In article <4241957b$0$136$e4fe514c@news.xs4all.nl>,
>> 	Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
>> > "unixrules2003@removethis.yahoo.com.nospam"
> <unixrules2003@yahoo.com> writes:
>> >
>> >>    In a large distributed network it is not uncommon for a
> building
>> >>that supplies network for another building to lose power for longer
>> >>than what the switch's UPS can handle.  It seems like a very
> strange
>> >>thing for the clients to do.
>> >
>> > They probably retry for a long time and then they run out of
>> > reserved ports to try this with.
>> >
>>
>> If that's the case, wouldn't forcing udp stop it, or setting
>> tcp_time_wait_interval to a lower value (like 60000) reduce it?
>>
> 
>    UDP isn't an option since flow control is needed.  With a fast
> server with a gigabit connection, slow clients can be overwhelmed...
> Not sure if changing tcp_time_wait_interval is a good solution or not.
> Any thoughts before I try that?
> 

Now that I think about it, the default in Solaris 9 and later has already
been lowered to 60000 (from 240000 in Solaris 8 and earlier).  AFAIK,
values lowre than 60000 are not generally recommended.  So unless the
problem is typically much lower with Solaris 9 and 10 than with Solaris 8,
I wouldn't bother doing it for that reason alone (although lowering it
to 60000 on Solaris 8 and earlier would probably almost never hurt).


>> >>      I've seen it happen in 8, 9 and now 10.
>> >
>> >
>> > I'll investigate and see what happens.  Are the mounts
>> > active (i.e., are processes actively stuck in the mounts
>> > when the outage occurs?)
>> >
>> > Casper
>>
>> --
>> mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil
>>
>> Lasik/PRK theme music:
>>     "In the Hall of the Mountain King", from "Peer Gynt"
> 

-- 
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

> Sorry, but NFS clients switching over to using ports over 1024 is just
> wrong.
> Must be time to move to Linux.

You mean the POS excuse for a wanna-be UNIX called "Linux"?

BTW, I hate to bring you up to speed so suddenly, but one of the main 
weaknesess of Linux is that it doesn't do NFS correctly in any shape, way, 
or form.

Now go eat rocks you troll, and hop away from here in three (3) 
as-high-as-you-can-do-it hops.

May all your servers run Linux some day.

>  Ironic how my sarcasm gets responses, but my real questions weren't
> getting any response.

It appears that you can read, so go read documentation like the rest of us.

On 23 Mar 2005 11:17:41 -0800 "unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com> wrote:
> Richard L. Hamilton wrote:
>> In article <4241957b$0$136$e4fe514c@news.xs4all.nl>,
>> 	Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
>> > "unixrules2003@removethis.yahoo.com.nospam"
> <unixrules2003@yahoo.com> writes:
>> >
>> >>    In a large distributed network it is not uncommon for a
> building
>> >>that supplies network for another building to lose power for longer
>> >>than what the switch's UPS can handle.  It seems like a very
> strange
>> >>thing for the clients to do.
>> >
>> > They probably retry for a long time and then they run out of
>> > reserved ports to try this with.
>> >
>>
>> If that's the case, wouldn't forcing udp stop it, or setting
>> tcp_time_wait_interval to a lower value (like 60000) reduce it?
>>
>
>    UDP isn't an option since flow control is needed.  With a fast
> server with a gigabit connection, slow clients can be overwhelmed...

I don't follow that logic.  Slow clients cannot be overwhelmed; the
server can only return data to them as fast as they can request it.
They can be shut out by [very] fast clients, but this has nothing to
do with the server's capabilities wrt the slow clients.

> Not sure if changing tcp_time_wait_interval is a good solution or not.
> Any thoughts before I try that?

I'd avoid this, because the effect is global.

You should just remove the reserved ports setting on the server. It's
utterly pointless.

/fc

Frank Cusack wrote:
> On 23 Mar 2005 11:17:41 -0800
"unixrules2003@removethis.yahoo.com.nospam" <unixrules2003@yahoo.com>
wrote:
> >
> >    UDP isn't an option since flow control is needed.  With a fast
> > server with a gigabit connection, slow clients can be
overwhelmed...
>
> I don't follow that logic.  Slow clients cannot be overwhelmed; the
> server can only return data to them as fast as they can request it.
> They can be shut out by [very] fast clients, but this has nothing to
> do with the server's capabilities wrt the slow clients.
>
     I've seen the problem in practice.  Some clients were very slow
when the server went to gigabit and changing mounts from udp to tcp
fixed it...

B

unixrules2003@removethis.yahoo.com.nospam wrote:
> Casper H. S. Dik wrote:
> > They probably retry for a long time and then they run out of
> > reserved ports to try this with.
> >
> > >      I've seen it happen in 8, 9 and now 10.
> >
> > I'll investigate and see what happens.  Are the mounts
> > active (i.e., are processes actively stuck in the mounts
> > when the outage occurs?)
> >
>    Yes.  There are daemons always running and some cases login shells
> to home dirs.
> 
Casper,
   Have you been able to find anything with this?

thanks,
B