I noticed the following in the most recent changelog:

In setup.services, rename rc.portmap to rc.rpc. This is no
longer started
by default. Instead you must turn it on (only if you plan on
mounting NFS
partitions manually). Otherwise, it will be run regardless of
exec perms if
NFS shares or mounts are detected at boot time.

Does this mean that we'll see a file called /etc/rc.d/rc.rpc instead of
/etc/rc.d/rc.portmap? If so, this will break dozens of HOWTOS, which
all talk about "starting rc.portmap," and make the initial setup of NFS
very difficult for anyone who's trying to find NFS setup information on
the net.

Or maybe I'm just being clueless, which is entirely possible. Can
someone explain this?

Thanks,

T.

On 21 Sep 2006 22:32:03 -0700, tungtung@pacbell.net wrote:

>Does this mean that we'll see a file called /etc/rc.d/rc.rpc instead of
>/etc/rc.d/rc.portmap?

root@pooh:/etc/rc.d# ls -l
total 208
lrwxrwxrwx 1 root root 4 2006-09-22 16:34 rc.0 -> rc.6*
-rwxr-xr-x 1 root root 1160 2006-09-12 21:28 rc.4*
-rwxr-xr-x 1 root root 6782 2006-09-12 21:28 rc.6*
-rwxr-xr-x 1 root root 2322 2006-09-12 21:28 rc.K*
-rwxr-xr-x 1 root root 9935 2006-09-12 21:28 rc.M*
-rwxr-xr-x 1 root root 14330 2006-09-12 21:28 rc.S*
-rw-r--r-- 1 root root 466 2004-11-05 19:20 rc.acpid
-rw-r--r-- 1 root root 4178 2006-05-04 09:31 rc.bind
-rw-r--r-- 1 root root 512 2006-08-08 14:02 rc.dnsmasq
-rw-r--r-- 1 root root 119 2004-05-30 14:19 rc.font.new
-rwxr-xr-x 1 root root 1148 2006-09-22 17:08 rc.gpm*
-rw-r--r-- 1 root root 2243 2006-09-21 09:50 rc.hotplug
-rw-r--r-- 1 root root 401 2003-03-06 08:28 rc.httpd
-rwxr-xr-x 1 root root 8325 2006-09-21 12:48 rc.inet1*
-rw-r--r-- 1 root root 3576 2006-09-22 17:09 rc.inet1.conf
-rwxr-xr-x 1 root root 4477 2006-09-21 12:44 rc.inet2*
-rw-r--r-- 1 root root 497 2003-09-12 13:27 rc.inetd
-rw-r--r-- 1 root root 1924 2003-09-14 09:10 rc.ip_forward
-rwxr-xr-x 1 root root 272 2006-09-12 21:28 rc.local*
lrwxrwxrwx 1 root root 19 2006-09-22 16:34 rc.modules -> rc.modules-2.4.33.3
-rw-r--r-- 1 root root 25553 2006-09-01 18:31 rc.modules-2.4.33.3
-rw-r--r-- 1 root root 122 2006-09-22 17:09 rc.netdevice
-rwxr-xr-x 1 root root 2444 2006-09-21 13:05 rc.nfsd*
-rwxr-xr-x 1 root root 2008 2006-09-21 13:17 rc.rpc* <<== new
-rw-r--r-- 1 root root 1169 2006-05-28 06:24 rc.saslauthd
-rw-r--r-- 1 root root 967 2006-09-12 21:28 rc.scanluns
-rw-r--r-- 1 root root 687 2002-06-05 07:09 rc.sendmail
-rw-r--r-- 1 root root 2895 2006-08-29 21:02 rc.serial
-rwxr-xr-x 1 root root 1222 2006-05-14 08:35 rc.sshd*
-rwxr-xr-x 1 root root 860 2004-05-03 08:07 rc.syslog*
-rw-r--r-- 1 root root 1740 2006-09-12 21:28 rc.sysvinit
-rw-r--r-- 1 root root 4711 2006-09-14 10:11 rc.udev
-rw-r--r-- 1 root root 9453 2006-08-17 06:20 rc.wireless
-rw------- 1 root root 7320 2006-08-17 06:20 rc.wireless.conf

Yup, no portmap

Grant.
--
http://bugsplatter.mine.nu/

Grant wrote:
> On 21 Sep 2006 22:32:03 -0700, tungtung@pacbell.net wrote:
>
> >Does this mean that we'll see a file called /etc/rc.d/rc.rpc instead of
> >/etc/rc.d/rc.portmap?
>
> root@pooh:/etc/rc.d# ls -l
> total 208
<snip>
> -rwxr-xr-x 1 root root 2444 2006-09-21 13:05 rc.nfsd*
> -rwxr-xr-x 1 root root 2008 2006-09-21 13:17 rc.rpc* <<== new
> -rw-r--r-- 1 root root 1169 2006-05-28 06:24 rc.saslauthd
<snip>
>
> Yup, no portmap
>
> Grant.
> --
> http://bugsplatter.mine.nu/

I just set up NFS for the first time in ages and had to go back to the
HOWTOS, most of which say things like, "rc.portmap must be started
before starting rc.nfsd." IMHO, this is going to drive people nuts, not
to mention that there might be a script or two out there that calls
rc.portmap...

I think it needs a link:
-rwxr-xr-x 1 root root 38 Sep 8 11:02 rc.portmap ->
/etc/rc.d/rc.rpc

Troutwaxer

<tungtung@pacbell.net> wrote:
>I just set up NFS for the first time in ages and had to go back to the
>HOWTOS, most of which say things like, "rc.portmap must be started
>before starting rc.nfsd." IMHO, this is going to drive people nuts, not
>to mention that there might be a script or two out there that calls
>rc.portmap...

Those dated HOWTOs need updating after 11.0 comes out. For NFS server, just
chmod +x rc.nfsd. No need to touch rc.rpc yourself.

On 2006-09-22, tungtung@pacbell.net <tungtung@pacbell.net> wrote:
> I noticed the following in the most recent changelog:
>
> In setup.services, rename rc.portmap to rc.rpc. This is no
> longer started
> by default. Instead you must turn it on (only if you plan on
> mounting NFS
> partitions manually). Otherwise, it will be run regardless of
> exec perms if
> NFS shares or mounts are detected at boot time.
>
> Does this mean that we'll see a file called /etc/rc.d/rc.rpc instead of
> /etc/rc.d/rc.portmap? If so, this will break dozens of HOWTOS, which
> all talk about "starting rc.portmap," and make the initial setup of NFS
> very difficult for anyone who's trying to find NFS setup information on
> the net.
>
> Or maybe I'm just being clueless, which is entirely possible. Can
> someone explain this?


If anything, this change will make it easier, because the needed RPC
daemons will be started automatically if any NFS mounts are present in
/etc/fstab or shares defined in /etc/exports.

So far as HOWTO documents go, I've just updated mine, and it was fairly
simple to differentiate among various linux distros as well as Slackware
versions.
http://howtos.rlworkman.net/NFS_Firewall_HOWTO

RW

--

http://rlworkman.net

On Mon, 25 Sep 2006 05:16:31 GMT, Robby Workman <newsgroups@rlworkman.net> wrote:

> http://howtos.rlworkman.net/NFS_Firewall_HOWTO

Rationale for firewall? Over here I allow unrestricted localnet traffic,
restrict connections from 'out there'... So no problem re: random ports.

Why or when would I make NFS firewall rules like in your document?


The only port I nail is DNS query port, a that causes iptables to see
them as a stream and hold open the fake 'connection' for 180 rather
than 30 seconds, for the slow reply nameservers my ISP uses.

Grant.
--
http://bugsplatter.mine.nu/

On 2006-09-25, Grant <g_r_a_n_t_@dodo.com.au> wrote:
> On Mon, 25 Sep 2006 05:16:31 GMT, Robby Workman <newsgroups@rlworkman.net> wrote:
>
>> http://howtos.rlworkman.net/NFS_Firewall_HOWTO
>
> Rationale for firewall? Over here I allow unrestricted localnet traffic,
> restrict connections from 'out there'... So no problem re: random ports.
>
> Why or when would I make NFS firewall rules like in your document?


I think I've had this discussion before, but I don't know if it was here or
elsewhere, and I'm too lazy to check the archives, so I'll do it again

My home network has ten drops plus a wireless connection. The ten drops are
from two separate five port switches, both of which are tied to eth0 on the
firewall box. The wireless access point is ath0 (SMC ? with madwifi) on the
firewall box. I occasionally have others over here, and depending on their
needs, they either use the wifi (open) connection or a wired drop. Preventing
NFS requests from the wireless network isn't a problem, as eth0 and ath0 on
the firewall are not bridged, but I initially planned to bridge them, so that
was the initial reason for wanting to restrict access at the NFS server via
iptables (on the server itself). Later on, I realized that allowing others
to use the wired network would present the same potential problems, so I
decided to continue with the original plan (minus bridging).

As it stands, the NFS server is also my primary desktop/development box, so
I run sshd and vsftpd on it as well. I realize that I could very easily
have selective filters for only ports 22 and 21, but I guess intellectual
curiosity won. Ultimately, the setup I have now allows me to have my
desktop fully firewalled (locally) to allow NFS connections only from
specified hosts, and I don't have to worry about scripting something to
see what ports were used by the RPC daemons after each boot.

Yes, I know I could have accomplished essentially the same thing with
/etc/hosts.{allow,deny}, but then, that would have eliminated the ability
to have a "deny by default" firewall policy on the NFS server.

Was that a good enough answer?

RW

--

http://rlworkman.net

On Tue, 26 Sep 2006 03:38:57 GMT, Robby Workman <newsgroups@rlworkman.net> wrote:

>On 2006-09-25, Grant <g_r_a_n_t_@dodo.com.au> wrote:
>> On Mon, 25 Sep 2006 05:16:31 GMT, Robby Workman <newsgroups@rlworkman.net> wrote:
>>
>>> http://howtos.rlworkman.net/NFS_Firewall_HOWTO
>>
>> Rationale for firewall? Over here I allow unrestricted localnet traffic,
>> restrict connections from 'out there'... So no problem re: random ports.
>>
>> Why or when would I make NFS firewall rules like in your document?
>
>
>I think I've had this discussion before, but I don't know if it was here or
>elsewhere, and I'm too lazy to check the archives, so I'll do it again
>
>My home network has ten drops plus a wireless connection.

The wireless opens it up some.

>Was that a good enough answer?

Sorry, left me confused, unless you see the friends' machines as a
threat? Me trying to work out your security threat model, apart
from the wireless I don't use hosts.allow, deny either.

NFS install stuff in exported read-only, and shared NFS is exported
r/w executable, dangerous? But restricted to localnet by firewall
which is also the main NFS server.

There's a machine specific export so 'stinkpad' )IBM 365X) could mount
/usr over the localnet -- another way to extend small HDD in lappy
while I played with CF and other options.

Maybe I'll write my setup up on web page, then you can compare, poke
holes at it?

Grant.
--
http://bugsplatter.mine.nu/