Automounter

Last updated

An automounter is any program or software facility which automatically mounts filesystems in response to access operations by user programs. An automounter system utility (daemon under Unix), when notified of file and directory access attempts under selectively monitored subdirectory trees, dynamically and transparently makes local or remote devices accessible.

Contents

The automounter has the purpose of conserving local system resources and of reducing the coupling between systems which share filesystems with a number of servers. For example, a large to mid-sized organization might have hundreds of file servers and thousands of workstations or other nodes accessing files from any number of those servers at any time. Usually, only a relatively small number of remote filesystems (exports) will be active on any given node at any given time. Deferring the mounting of such a filesystem until a process actually needs to access it reduces the need to track such mounts, increasing reliability, flexibility and performance.

Frequently, one or more fileservers will become inaccessible (down for maintenance, on a remote and temporarily disconnected network, or accessed via a congested link). Administrators also often find it necessary to relocate data from one file server to another - to resolve capacity issues and balance the load. Having data mount-points automated makes it easier to reconfigure client systems in such cases.

These factors combine to pose challenges to older "static" management methods of filesystem mount tables (the fstab files on Unix systems). Automounter utilities address these challenges and allow sysadmins to consolidate and centralize the associations of mountpoints (directory names) to the exports. When done properly, users can transparently access files and directories as if all of their workstations and other nodes attach to a single enterprise-wide filesystem.

One can also use automounters to define multiple repositories for read-only data; client systems can automatically choose which repository to mount based on availability, file-server load, or proximity on the network.

Home directories

Many establishments will have a number of file servers which host the home directories of various users. All workstations and other nodes internal to such organizations (typically all those behind a common firewall separating them from the Internet) will be configured with automounter services so that any user logging into any node implicitly triggers access to his or her own home directory which, consequently, is mounted at a common mountpoint, such as /home/user. This allows users to access their own files from anywhere in the enterprise, which is extremely useful in UNIX environments, where users may frequently invoke commands on many remote systems via various job-dispatching commands such as ssh , telnet , rsh or rlogin , or via the X11 or VNC protocols.

/net

A very common default automounter local path is of the form /net/hostname/nfspath where hostname is the host name of the remote machine and nfspath is the path that is exported over NFS on the remote machine. This notation generally frees the system manager from having to manage each exported path explicitly via a central automounter map.

Software shares and repositories

In some computing environments, user workstations and computing nodes do not host installations of the full range of software that users might want to access. Systems may be "imaged" with a minimal or typical cross-section of the most commonly used software. Also, in some environments, users might require specialized or occasional access to older versions of software (for instance, developers may need to perform bug fixes and regression testing, or some users may need access to archived data using outdated tools).

Commonly, organizations will provide repositories or "depots" of such software, ready for installation as required. These also may include full copies of the system images from which machines have their operating systems initially installed, or available for repair of any system files that may get corrupted during a machine's lifecycle.

Some software may require quite substantial storage space or might be undergoing rapid (perhaps internal) development. In those cases the software may be installed on, and configured to be run directly from, the file servers.

Dynamically variant automounts

In the simplest case, a fileserver houses data and perhaps scripts which can be accessed by any system in an environment. However, certain types of files (executable binaries and shared libraries, in particular) can only be used by specific types of hardware or specific versions of specific operating systems.

For situations like this, automounter utilities generally support some means of "mapping" or "interpolating" variable data into the mount arguments.

For example, an organization with a mixture of Linux and Solaris systems might arrange to host their software package repositories for each on a common file-server using export names like depot:/export/linux and depot:/export/solaris respectively. Thereunder they might have directories for each of the OS versions that they support. Using the dynamic variation features in their automounter, they might then configure all their systems so that any administrator on any machine in their enterprise could access available software updates under /software/updates. A user on a Solaris system would find the Solaris compiled packages under /software, while a Linux user would find RPMs, DEBs, or other packages for their particular OS version thereunder. Moreover, a Solaris user on a SPARC workstation would have his /software/updates mapped to an appropriate export for that system's architecture, while a Solaris user on an x86 PC would transparently find his /software/updates directory containing packages suited to his system. Some software (written in scripting languages such as Perl or Python) can be installed and/or run on any supported platform without porting, recompilation or re-packaging of any sort. A systems administrator might conceivably locate such software in a /software/common export.

In some cases, organizations may also use regional or location-based variable/dynamic mappings — so that users in one building or site are directed to a closer file server which hosts replications of the resources that are hosted at other locations.

In all of these cases, automounter utilities allow the users to access files and directories without regard for the actual physical location. Using an automounter, the users and systems administrators can usually access files where they are "supposed to be" and find that they appear to be there.

Software

Tom Lyon developed the original automount software at Sun Microsystems: SunOS 4.0 made automounting available in 1988. [1] Sun Microsystems eventually licensed this implementation to other commercial UNIX distributions. Solaris 2.0, first released in 1992, implemented its automounter with a pseudofilesystem called autofs, which communicates with a user-mode daemon that performs mounts. [2] [3] Other Unix-like systems have adopted that implementation of the automounter - including AIX, HP-UX, and Mac OS X 10.5 and later.

In December 1989 Jan-Simon Pendry released Amd, an automounter "based in spirit" on the SunOS automount program. [4] Amd has also become known as the Berkeley Automounter.

Linux has an independent implementation of an autofs-based automounter; version 5 of that automounter generally operates compatibly with the Solaris automounter.

FreeBSD used to provide Amd; starting with 10.1 it has a new automounter very similar to the Solaris one. [5] It has been subsequently ported to DragonFly BSD [6] and NetBSD. [7]

Some operating systems also support automatic mounting of external drives (such as disk drives or flash drives that use FireWire or USB connections) and removable media (such as CDs and DVDs). This technology differs from the automounting described here; it involves mounting local media when the user attaches them to or inserts them into the system, rather than mounting directories from remote file servers when a reference is made to them. Linux currently (as of Linux 2.6) uses the user-space program udev for this form of automounting. Some automounting functions have been implemented in the separate program HAL, but As of 2010 are being merged[ by whom? ] into udev. OpenBSD has hotplugd(8) which triggers special scripts on attach or detach of removable devices, so that user can easily add mounting of removable drives. In macOS, diskarbitrationd carries out this form of automatic mounting. In FreeBSD, the removable media can be handled by the automounter, just as network shares are. [8] [9]

Disadvantages and caveats

While automounter utilities (and remote filesystems in general) can provide centrally managed, consistent and largely transparent access to an organization's storage services, they also can have their downsides:

Related Research Articles

Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems (Sun) in 1984, allowing a user on a client computer to access files over a computer network much like local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call system. NFS is an open standard defined in a Request for Comments (RFC), allowing anyone to implement the protocol.

In computer security, an access-control list (ACL) is a list of permissions associated with a system resource (object). An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation. For instance, if a file object has an ACL that contains (Alice: read,write; Bob: read), this would give Alice permission to read and write the file and only give Bob permission to read it.

Beowulf cluster

A Beowulf cluster is a computer cluster of what are normally identical, commodity-grade computers networked into a small local area network with libraries and programs installed which allow processing to be shared among them. The result is a high-performance parallel computing cluster from inexpensive personal computer hardware.

Root directory

In a computer file system, and primarily used in the Unix and Unix-like operating systems, the root directory is the first or top-most directory in a hierarchy. It can be likened to the trunk of a tree, as the starting point where all branches originate from. The root file system is the file system contained on the same disk partition on which the root directory is located; it is the filesystem on top of which all other file systems are mounted as the system boots up.

Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.

A home directory is a file system directory on a multi-user operating system containing files for a given user of the system. The specifics of the home directory are defined by the operating system involved; for example, Linux / BSD (FHS) systems use /home/<username> and Windows systems between 2000 and Server 2003 keep home directories in a folder called Documents and Settings.

Virtual file system

A virtual file system (VFS) or virtual filesystem switch is an abstract layer on top of a more concrete file system. The purpose of a VFS is to allow client applications to access different types of concrete file systems in a uniform way. A VFS can, for example, be used to access local and network storage devices transparently without the client application noticing the difference. It can be used to bridge the differences in Windows, classic Mac OS/macOS and Unix filesystems, so that applications can access files on local file systems of those types without having to know what type of file system they are accessing.

The Andrew File System (AFS) is a distributed file system which uses a set of trusted servers to present a homogeneous, location-transparent file name space to all the client workstations. It was developed by Carnegie Mellon University as part of the Andrew Project. Originally named "Vice", AFS is named after Andrew Carnegie and Andrew Mellon. Its primary use is in distributed computing.

A chroot on Unix operating systems is an operation that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name files outside the designated directory tree. The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail.

The Berkeley r-commands are a suite of computer programs designed to enable users of one Unix system to log in or issue commands to another Unix computer via TCP/IP computer network. The r-commands were developed in 1982 by the Computer Systems Research Group at the University of California, Berkeley, based on an early implementation of TCP/IP.

The fstab file is a system configuration file commonly found at /etc/fstab on Unix and Unix-like computer systems. In Linux, it is part of the util-linux package. The fstab file typically lists all available disk partitions and other types of file systems and data sources that may not necessarily be disk-based, and indicates how they are to be initialized or otherwise integrated into the larger file system structure.

These tables provide a comparison of operating systems, of computer devices, as listing general and technical information for a number of widely used and currently available PC or handheld operating systems. The article "Usage share of operating systems" provides a broader, and more general, comparison of operating systems that includes servers, mainframes and supercomputers.

File system Format or program for storing files and directories

In computing, a file system or filesystem controls how data is stored and retrieved. Without a file system, data placed in a storage medium would be one large body of data with no way to tell where one piece of data stops and the next begins. By separating the data into pieces and giving each piece a name, the data is easily isolated and identified. Taking its name from the way paper-based data management system is named, each group of data is called a "file." The structure and logic rules used to manage the groups of data and their names is called a "file system."

Filesystem in Userspace (FUSE) is a software interface for Unix and Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a "bridge" to the actual kernel interfaces.

Diskless node

A diskless node is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.

File locking is a mechanism that restricts access to a computer file, or to a region of a file, by allowing only one user or process to modify or delete it in a specific time and to prevent reading of the file while it's being modified or deleted.

In computing, Sharity is a program to allow a Unix system to mount SMB fileshares. It is developed by Christian Starkjohann of Objective Development Software GmbH and is proprietary software. As of 8 November 2010, the current version is 3.9.

Extended file attributes are file system features that enable users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem. Unlike forks, which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the character encoding of a plain-text document, or a checksum, cryptographic hash or digital certificate, and discretionary access control information.

The following tables compare general and technical information for a number of file systems.

References

  1. ↑ Callaghan, Brent (2000) [1999]. NFS Illustrated. Addison-Wesley. pp. 322–323. ISBN   0-201-32570-5 . Retrieved 2007-12-23.
  2. ↑ Callaghan, Brent; Singh, Satinder (June 21–25, 1993). The Autofs Automounter. USENIX Summer 1993 Technical Conference. Cincinnati, Ohio.
  3. ↑ Labiaga, Ricardo (November 7–12, 1999). Enhancements to the Autofs Automounter. 1999 LISA XIII. Seattle, Washington.
  4. ↑ Jan-Simon Pendry (1989-12-01). "''Amd'' - An Automounter". Newsgroup:  comp.unix.wizards . Retrieved 2007-12-23.
  5. ↑ Edward Tomasz Napierała (2014-07-30). "Autofs" (PDF). Archived (PDF) from the original on 7 June 2021.
  6. ↑ Tomohiro Kusumi (2016-06-02). "git: autofs: Port autofs from FreeBSD". commits@dragonflybsd.org (Mailing list). DragonFly BSD . Retrieved 2019-11-13.
  7. ↑ "New automounter". NetBSD Wiki. Archived from the original on 7 June 2021.
  8. ↑ "FreeBSD Handbook, section 17.4.2. Automounting Removable Media". Archived from the original on 7 June 2021.
  9. ↑ Dickison, Anne (2015-03-13). "FreeBSD From the Trenches: Using autofs(5) to Mount Removable Media". FreeBSD Foundation. Archived from the original on 7 June 2021. Retrieved 2019-11-13.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.