Re: move portmap(8) from /usr/sbin to /sbin
"Rodney W. Grimes" wrote: ... Independent of order of export/mounting the dead lock occurs. Cross mounting via NFS is a verbotten thing in the sysadmin world of production systems. :-) I have had to fix it at several sites admin'd by newbies... I'm not sure you are really understanding the problem. We don't want to read RFCs or such professional sysadmin red books... But a lot of us around here do just that, don't expect us to make changes just because it suites _your_ needs as that change may very well not suite the _other_ 95% of the users. Sometimes we just want to nfs-mount things on the same machine. Sick, poor in performance and the wrong tool for the job. See mount_null(8) for more details on how to do it right. One more example: I don't like /var/news so I mount locally /var/news to /archive/news on the same system instead of using symlinks. My rc.local manages it for me. Sick. See above. But, is it really so difficult to move portmap to /sbin. It is not difficult to move the binary. The difficulty is in changing the sequence of events that control when the binary is run. No one here has objected to moving the binary that I have seen, it has been changing when things occur. Why? portmap/mountd are heavy users of syslog, you _should_ have syslogd running before portmap/mountd. syslogd is started between network_pass1 and network_pass2. Linux have portmap in /sbin and it runs. That argument holds 0 ground here. And it's not the objection to your change we raised. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Date: Thu, 13 Jan 2000 16:54:21 +1100 (EST) From: Tony Maher [EMAIL PROTECTED] Sick, poor in performance and the wrong tool for the job. See mount_null(8) for more details on how to do it right. Yes its perfect for the job apart from: man mount_null THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) Another way to accomplish a similar result -- especially if you're already using amd -- is to make use of the ability (within an amd map) to specify a "type" of "link" (vs. "nfs"). This (type=link) simulates a symlink, as opposed to simulating an NFS mount. I've been using it for 1.5 years here to avoid loopback NFS mounts. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
: Sometimes we just want to nfs-mount things on the same
: machine.
:
:Sick, poor in performance and the wrong tool for the job.
:See mount_null(8) for more details on how to do it right.
:
:
: One more example: I don't like /var/news so I mount locally
: /var/news
: to /archive/news on the same system instead of using
: symlinks.
: My rc.local manages it for me.
:
:Sick. See above.
I gotta agree, this is sick. But to put the icing on the cake: LOCAL
NFS MOUNTS CAN LEAD TO LOW-MEMORY DEADLOCKS. Even with my recent fixes
to -current there is still a non-zero chance of this happening.
The best way to handle a mutual-export/import situation is to
physically mount your disks in this type of directory structure:
machine A: 'lander'
machine B: 'apollo'
/lander/u1
/lander/u2
/lander/u3
/apollo/u1
/apollo/u2
/apollo/u3
On lander the local partitions u1, u2, and u3's mount points are
hard mounted on /lander/u{1,2,3} and apollo's local disks are NFS
mounted on lander in /apollo/u{1,2,3}.
On apollo the /lander partition contains NFS mounts from lander's
u{1,2,3} and apollo's local drives are hard mounted directoy onto
/apollo/u{1,2,3}.
It couldn't be simpler. If you want standard system places to point
to some of these partitions, you simply make the standard system places
softlinks to the appropriate /host/partition directory.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
: Sometimes we just want to nfs-mount things on the same : machine. : :Sick, poor in performance and the wrong tool for the job. :See mount_null(8) for more details on how to do it right. : : : One more example: I don't like /var/news so I mount locally : /var/news : to /archive/news on the same system instead of using : symlinks. : My rc.local manages it for me. : :Sick. See above. I gotta agree, this is sick. But to put the icing on the cake: LOCAL NFS MOUNTS CAN LEAD TO LOW-MEMORY DEADLOCKS. Even with my recent fixes to -current there is still a non-zero chance of this happening. This use to be documented some place, but I can't find it :-(. [Good example of how to do things deleted] -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Hi,
I think we should move portmap(8) to /sbin for the following reason:
portmap(8) and therefore mountd(8) should be started before
the nfs filesystems get mounted. But because portmap(8) is in
/usr/sbin , users with a nfs mounted /usr filesystem or with
diskless filesystems will have big problems.
This will fix loopback and local mounts in fstab. Untill now
this has not been possible because of the above reasons. Btw:
Linux also has portmap(8) installed in /sbin.
I'm prepared for a big fight :) Can you give me any arguments
against this change ?
It makes no since...
Why would a machine that mounts /usr over nfs need to export
filesystems? If it's got enough disk space to make it worth
exporting stuff from the box it surely has enough space for
it's own copy of /usr.
You only need portmap and mountd to _export_ nfs, not to mount
them.
Orbit.hpc1.com:root{208}# ps ax | grep mount
Orbit.hpc1.com:root{209}# ps ax | grep port
Orbit.hpc1.com:root{210}# df
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/da0s1a 63503215193690437%/
/dev/da0s1d 63503 45857965 1%/tmp
/dev/da0s1e 63503 48357940 1%/var
/dev/da0s1f127023820303483270%/usr
/dev/da0s1g381103 2511709944572%/usr/src
/dev/da0s1h 1233503 208025 92679818%/A
procfs 440 100%/proc
198.145.92.8:/A 1309170 11274637697494%/mnt
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
portmap(8) and therefore mountd(8) should be started before the nfs filesystems get mounted. But because portmap(8) is in /usr/sbin , users with a nfs mounted /usr filesystem or with diskless filesystems will have big problems. I mean, that if I do the change of startup-order, diskless installations will be broken. This will fix loopback and local mounts in fstab. Untill now this has not been possible because of the above reasons. Btw: Linux also has portmap(8) installed in /sbin. You only need portmap and mountd to _export_ nfs, not to mount them. For a normal installation this is ok, but as I said, diskless installs ... Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
: portmap(8) and therefore mountd(8) should be started before : the nfs filesystems get mounted. But because portmap(8) is in : /usr/sbin , users with a nfs mounted /usr filesystem or with : diskless filesystems will have big problems. : :I mean, that if I do the change of startup-order, diskless :installations will be broken. : : This will fix loopback and local mounts in fstab. Untill now : this has not been possible because of the above reasons. Btw: : Linux also has portmap(8) installed in /sbin. : : You only need portmap and mountd to _export_ nfs, not to mount : them. : :For a normal installation this is ok, but as I said, diskless :installs ... : :Martin I do not like the idea of moving portmap or mountd. An NFS client should not have to run either, *even* for diskless boot. What's all this about loopback mounts in fstab about? What does that have to do with diskless startup? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Hi, should not have to run either, *even* for diskless boot. What's all this about loopback mounts in fstab about? What does that have to do with diskless startup? Ok. I just rethought everything. It seems that a move is unnecessary because: - Sharity light and cfs are started from /usr/loca/etc/rc.d - diskless stations do not have anything to export So are there any problems with the order change in /etc/rc.network (moving portmap and mountd to network pass_1) you can imagine ? Thanks for the fast response and your ideas. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Hi, should not have to run either, *even* for diskless boot. What's all this about loopback mounts in fstab about? What does that have to do with diskless startup? Ok. I just rethought everything. It seems that a move is unnecessary because: - Sharity light and cfs are started from /usr/loca/etc/rc.d - diskless stations do not have anything to export So are there any problems with the order change in /etc/rc.network (moving portmap and mountd to network pass_1) you can imagine ? They don't logically belong in pass1, which is for bringing up the network logical layer. These run above the logical layer. Also moving them to pass1 would bring up nfs exports before we brought up nfs mounts. syslogd would not be running to catch errors, etc. Moving things in /etc/rc is not to be taken lightly, it has taken 10 years to get what we have there in a shape that just DTRT for 99% of the folks. Perhaps if you can give us some specifics on exactly what it is that your having problems doing and/or what it is that you are trying to do we can come up with a correct solution. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
On Wed, Jan 12, 2000 at 01:23:14AM -0800, Rodney W. Grimes wrote: Also moving them to pass1 would bring up nfs exports before we brought up nfs mounts. syslogd would not be running to catch Shouldn't nfs exports happen before nfs mounts, so that machines which have nfs interdependencies don't sit there waiting for one another? (I think we've had to change this several times in the FreeBSD rc scripts, I guess the reason it might be the other way around is incase /usr is nfs mounted?) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
"Rodney W. Grimes" wrote: [..] So no disk, so just what is it that you are exporting??? Just a comment: I've seen scenarios where a local disk is attached holding a kernel, bootblocks loader etc, but otherwise booting from a server over NFS. And it exported the rest of it's disk for general use... It's easier than netbooting, allows each machine to contribute disk space to the cluster in addition to compute cycles, keyboard, screen etc. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
I've got a loopback mount in /var/db/mounttab that looks like this: 946789037 localhost /null which is there because I run cfs (a crypto file system; see /usr/ports/security/cfs). Part of the cfs startup script does this: /usr/local/sbin/cfsd mount -o port=3049,intr localhost:/null /crypt The problem is that when you boot, the invocation of 'rpc.umntall -k' hangs for a while trying to contact the mountd or portmapper on localhost. If it was smart enough to recognize an ICMP port unreachable error and move on, we wouldn't have this problem. It's not that I think moving mountd and portmap is necessarily a good idea; this is just one scenario which perhaps has prompted this line of That's because rpc.umntall has been called the wrong time. I have another patch which does fix this behaviour. Thanks anyway. BTW: you cannot have this line in /etc/fstab, right ? If you put localhost:/null /crypt in fstab, you will get a hang at boottime. Are there other cases for which we will have problems ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
On Wed, Jan 12, 2000 at 01:23:14AM -0800, Rodney W. Grimes wrote: Also moving them to pass1 would bring up nfs exports before we brought up nfs mounts. syslogd would not be running to catch Shouldn't nfs exports happen before nfs mounts, so that machines which have nfs interdependencies don't sit there waiting for one another? (I think we've had to change this several times in the FreeBSD rc scripts, I guess the reason it might be the other way around is incase /usr is nfs mounted?) If your talking about dead lock caused by mutual cross mounting between 2 systems via NFS the NFS rule book says ``don't do that, it hurts''. Independent of order of export/mounting the dead lock occurs. Cross mounting via NFS is a verbotten thing in the sysadmin world of production systems. :-) I have had to fix it at several sites admin'd by newbies... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
"Rodney W. Grimes" wrote: [..] So no disk, so just what is it that you are exporting??? Just a comment: I've seen scenarios where a local disk is attached holding a kernel, bootblocks loader etc, but otherwise booting from a server over NFS. And it exported the rest of it's disk for general use... It's easier than netbooting, allows each machine to contribute disk space to the cluster in addition to compute cycles, keyboard, screen etc. See other mail about the evilness of cross mounting NFS, this especially applies in a cluster! You can't bloody cold start the beast easily. One way I have seen it worked around is to flag the NFS mounts -background so that they don't hang the boot process. Still evil lurks in these corners of the world... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
If your talking about dead lock caused by mutual cross mounting between 2 systems via NFS the NFS rule book says ``don't do that, it hurts''. Independent of order of export/mounting the dead lock occurs. Cross mounting via NFS is a verbotten thing in the sysadmin world of production systems. :-) I have had to fix it at several sites admin'd by newbies... Strange - it's worked fine for years here, as long as you fix rc stuff ;-) Infact, it works OK if you don't fix rc stuff, as long as you make all the mounts backgroundable. (We've used NFS heavily for years, and never had enough cash to be able to group machines into NFS servers and NFS clients. If you want all your machines to be available to all your users, and you share home directories then to avoid cycles in your NFS graph you have to have one NFS server). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
"Rodney W. Grimes" wrote: "Rodney W. Grimes" wrote: [..] So no disk, so just what is it that you are exporting??? Just a comment: I've seen scenarios where a local disk is attached holding a kernel, bootblocks loader etc, but otherwise booting from a server over NFS. And it exported the rest of it's disk for general use... It's easier than netbooting, allows each machine to contribute disk space to the cluster in addition to compute cycles, keyboard, screen etc. See other mail about the evilness of cross mounting NFS, this especially applies in a cluster! You can't bloody cold start the beast easily. Yes you can.. I didn't say the boxes depended on each other to boot. They had a NFS server for the OS for /, /usr etc. They cross mounted the exported space between the boxes via 'amd' which happens much later (and is in /usr). The seperate server depended on nothing. One way I have seen it worked around is to flag the NFS mounts -background so that they don't hang the boot process. Still evil lurks in these corners of the world... Or don't mount it early in the boot. I'm not suggesting moving portmap BTW, I'm just saying that there are other ways of doing it. Yes, having cross mounting required to *boot* is evil, but when it's not active until somebody logs in it's mostly harmless. On an unrelated note, I remember the cold-start nightmare scenario well. One of the local universities had a cluster of SGI IRIS boxes, way back when they were new and had tiny disks. There was a power out and the cross mounting in order to preserve every scrap of space caused quite a lot of excitement. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
"Rodney W. Grimes" wrote: ... Independent of order of export/mounting the dead lock occurs. Cross mounting via NFS is a verbotten thing in the sysadmin world of production systems. :-) I have had to fix it at several sites admin'd by newbies... I'm not sure you are really understanding the problem. We don't want to read RFCs or such professional sysadmin red books... Sometimes we just want to nfs-mount things on the same machine. One more example: I don't like /var/news so I mount locally /var/news to /archive/news on the same system instead of using symlinks. My rc.local manages it for me. But, is it really so difficult to move portmap to /sbin. Why? Linux have portmap in /sbin and it runs. regards, -- Jean Louis Ntakpe Texas Instruments - Freising [EMAIL PROTECTED] Wafer Fab Automation Group [EMAIL PROTECTED] Haggerty Str. 1 85350 Freising Telefon +49 (8161) 80-3816 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: move portmap(8) from /usr/sbin to /sbin
Sick, poor in performance and the wrong tool for the job. See mount_null(8) for more details on how to do it right. Yes its perfect for the job apart from: man mount_null THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to [EMAIL PROTECTED] and announcing their intent to take it over. I actually tried it a few weeks ago and yes it did screw up files :-( (that was on stable - my current box is broken but checking CVS man page it looks like the warning still applies) But I'd be happy to hear it works on current! tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
