[NTLUG:Discuss] Rebuilding (G)libc from an SRPM
Bryan J. Smith
b.j.smith at ieee.org
Fri Sep 24 13:22:51 CDT 2004
On Fri, 2004-09-24 at 10:09, George Lass wrote:
> The timeout stuff for NFS is in:
> /usr/src/redhat/BUILD/glibc-2.2.93/sunrpc/pm_getport.c
Cool. Thanx.
I've never really had a reason to change it.
With automounter with a background mount option seems to take care of
the problem for me.
> The system in question, once booted, will be writing several records each
> second to the server that it is trying to NFS mount.
With automounter and background mounts, if you run the background in the
process, it will write the file if and when the mount comes up. It will
_never_ hold up boot.
> I really don't know much about aoutomounter,
Anyone who deploys NFS should learn it. On select non-Linux platforms
(e.g., Solaris), it is even more capable.
Automounter makes mounting/umounting transparent. It solves the issue
of only privileged users being able to mount/umount. If a regular user
goes into a directory that automounts, it will mount at that time --
again -- completely transparently.
Using NIS-based** automounter files, you may _never_ have to modify the
NFS clients themselves.
> but I would *guess* that it uses the same timeout that NFS mount
> uses.
Correct. But the different is that you don't need to mount it at boot.
Automounter can mount and umount NFS (or any other filesystem mount,
local or remote) as necessary when it is accessed.
> If that is the case, I would just as soon get the waiting out of
> the way at startup time.
Automounter completely eliminates the startup time. You don't mount the
NFS mount at boot. You _only_ mount the NFS mount when it is accessed.
Automounter then umounts after a period of inactivity (typically 60-300
seconds, user-definable).
> But the bottom line is that this system has been in use since RedHat
> 4.2 which I think pre-dates automounter.
Probably. Red Hat Linux 6 is the first distro that shipped with kernel
2.2, and many such features built into the kernel.
> Even so, we'll give it a look and see if automounter has any
> advantages over the standard NFS mount at startup.
I _never_ used NFS mounts in /etc/fstab. I _always_ use automounter.
Thers the automounter "master" file: /etc/auto.master
Then there are the "automounter maps."
For example, on my home network "oviedo":
#
# /etc/auto.master
#
/net/oviedo /etc/auto.oviedo --timeout=300
#
# /etc/auto.oviedo
#
############################################################
# Dilbert
#===========================================================
apps -nfsvers=3,rsize=8192,wsize=8192,udp,bg dilbert:/home/apps
nisusers -nfsvers=3,rsize=8192,wsize=8192,udp,bg dilbert:/home/nisusers
static -nfsvers=3,rsize=8192,wsize=8192,udp,bg dilbert:/home/static
temp -nfsvers=3,rsize=8192,wsize=8192,udp,bg dilbert:/home/temp
If I either cd or access a file in /net/oviedo/apps, it mounts it.
After 5 minutes (300 seconds) of inactivity, it unmounts it.
It does not mount it until it is accessed.
I also symlink all subdirectories of /net/oviedo/* to /home.
Another cool thing is that you do _not_ need to create mountpoints for
each and every NFS mount -- only the "root" of the automounter map
(e.g., /net/oviedo). That way you can setup a NIS-based** automounter
master and maps, add/remove exports at will, and _never_ have to do
anything on your clients.
**NOTE: If you use LDAP instead of NIS, you can share out automounter
maps with additional utilities (most distros come with these nowdays).
--
Bryan J. Smith b.j.smith at ieee.org
------------------------------------------------------------------
"Communities don't have rights. Only individuals in the community
have rights. ... That idea of community rights is firmly rooted
in the 'Communist Manifesto.'" -- Michael Badnarik
More information about the Discuss
mailing list