Re: RH Taroon Beta Open Ports

[Steve Bonneville]

Dan Walsh wrote:
> I also think minimal ports should be the default.  Maybe adding some
> inteligence to the scripts or redhat-config-services to allow know that
> if you start NFS you also need to start portmapper.  Maybe
> by adding a requires flag to the NFS init script.
>
> Why do we have a bias towards the machine being a server machine?

Don't forget that the client side also needs to have portmap running 
in order to mount an NFS share.  So the mount command would have to 
start up or make sure portmap and nfslock are running, too.

-- Steve Bonneville

RH Taroon Beta Open Ports

[Daniel J Walsh]

Just tried it and it does a nice job of hanging my terminal.  :^(

Steven Bonneville wrote:
> Dan Walsh wrote:
> > I also think minimal ports should be the default.  Maybe adding some
> > inteligence to the scripts or redhat-config-services to allow know that
> > if you start NFS you also need to start portmapper.  Maybe
> > by adding a requires flag to the NFS init script.
> >
> > Why do we have a bias towards the machine being a server machine?
>
> Don't forget that the client side also needs to have portmap running 
> in order to mount an NFS share.  So the mount command would have to 
> start up or make sure portmap and nfslock are running, too.
>
> -- Steve Bonneville
>
> --
> Rhl-devel-list mailing list
> [e-mail]
> http://www.redhat.com/mailman/listinfo/rhl-devel-list

RH Taroon Beta Open Ports

[Daniel J Walsh]

Nope it eventually worked.  Not sure what the hang was.  I am mounting 
remote NFS machines
without portmap running.

Daniel J Walsh wrote:
> Just tried it and it does a nice job of hanging my terminal.  :^(
>
> Steven Bonneville wrote:
> > Dan Walsh wrote:
> > > I also think minimal ports should be the default.  Maybe adding some
> > > inteligence to the scripts or redhat-config-services to allow know that
> > > if you start NFS you also need to start portmapper.  Maybe
> > > by adding a requires flag to the NFS init script.
> > >
> > > Why do we have a bias towards the machine being a server machine?
> >
> > Don't forget that the client side also needs to have portmap running 
> > in order to mount an NFS share.  So the mount command would have to 
> > start up or make sure portmap and nfslock are running, too.
> >
> > -- Steve Bonneville
> >
> > --
> > Rhl-devel-list mailing list
> > [e-mail]
> > http://www.redhat.com/mailman/listinfo/rhl-devel-list

RH Taroon Beta Open Ports

[Dax Kelson]

On Wed, 2003-08-27 at 13:10, Daniel J Walsh wrote:
> Nope it eventually worked.  Not sure what the hang was.  I am mounting
> remote NFS machines
> without portmap running.

If you use the "nolock" option, then portmap need not be running and
there will be no hangs. For example:

mount -o nolock remotebox:/some/dir /local/mntpoint

Note: I'm not saying that this is what you should normally do.

I've done this within the %post section of Kickstart before or in the
rescue environment.

Dax Kelson
Guru Labs

RH Taroon Beta Open Ports

[Felipe Alfaro Solana]

On Wed, 2003-08-27 at 21:10, Daniel J Walsh wrote:
> Nope it eventually worked.  Not sure what the hang was.  I am mounting
> remote NFS machines without portmap running.

AFAIK, to mount a remote NFS share without relaying on a local portmap
daemon, you must use static port assignment for the remote rpc.nfsd and
rpc.mountd daemons. This can be achieved with:

# mount remote_machine:/share /mount_point -o
port=nfsd_port,mountport=mountd_port

However, I haven't found a way to specify the port for the local
nfs.lockd daemon. Thus, if I want to disable portmap locally, I must
append the nolock option to the previous mount command.