LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/html_single/Autodir-HOWTO/index.html

2799 lines
51 KiB
HTML
Raw Permalink Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Autodir HOWTO</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
><BODY
CLASS="article"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="title"
><A
NAME="AEN2"
></A
>Autodir HOWTO</H1
><H3
CLASS="author"
><A
NAME="AEN4"
>Venkata Ramana Enaganti</A
></H3
><DIV
CLASS="affiliation"
><DIV
CLASS="address"
><P
CLASS="address"
><TT
CLASS="email"
>&#60;<A
HREF="mailto:ramana <> intraperson dot com"
>ramana &#60;&#62; intraperson dot com</A
>&#62;</TT
></P
></DIV
></DIV
><P
CLASS="pubdate"
>2004-09-23<BR></P
><DIV
CLASS="revhistory"
><TABLE
WIDTH="100%"
BORDER="0"
><TR
><TH
ALIGN="LEFT"
VALIGN="TOP"
COLSPAN="3"
><B
>Revision History</B
></TH
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 1.04</TD
><TD
ALIGN="LEFT"
>2007-5-25</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>Minor updates</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 1.03</TD
><TD
ALIGN="LEFT"
>2006-09-15</TD
><TD
ALIGN="LEFT"
>Revised by: GaMA</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>Review requested by author.</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 1.02</TD
><TD
ALIGN="LEFT"
>2004-12-25</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>Minor updates</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 1.00</TD
><TD
ALIGN="LEFT"
>2004-09-23</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>Initial release, reviewed by Rahul Sundaram at TLDP</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 0.32</TD
><TD
ALIGN="LEFT"
>2004-09-13</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>New sections like requirements and others.</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 0.10</TD
><TD
ALIGN="LEFT"
>2004-06-24</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>second draft</TD
></TR
><TR
><TD
ALIGN="LEFT"
>Revision 0.9</TD
><TD
ALIGN="LEFT"
>2004-06-11</TD
><TD
ALIGN="LEFT"
>Revised by: VRE</TD
></TR
><TR
><TD
ALIGN="LEFT"
COLSPAN="3"
>first draft</TD
></TR
></TABLE
></DIV
><DIV
><DIV
CLASS="abstract"
><A
NAME="AEN49"
></A
><P
></P
><P
>&#13; This HOWTO is about the <EM
>Autodir</EM
> installation, configuration and other issues related to <EM
>Autodir</EM
>. The <EM
>Autodir</EM
> system is often applied for making home directories available in an easy way.
</P
><P
></P
></DIV
></DIV
><HR></DIV
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>1. <A
HREF="#intro"
>Introduction</A
></DT
><DD
><DL
><DT
>1.1. <A
HREF="#copyright"
>Copyright and License</A
></DT
><DT
>1.2. <A
HREF="#disclaimer"
>Disclaimer</A
></DT
><DT
>1.3. <A
HREF="#feedback"
>Feedback</A
></DT
><DT
>1.4. <A
HREF="#AEN78"
>New Versions of this Document</A
></DT
><DT
>1.5. <A
HREF="#credits"
>Credits / Contributors</A
></DT
></DL
></DD
><DT
>2. <A
HREF="#AEN91"
>Before going into the details...</A
></DT
><DT
>3. <A
HREF="#AEN99"
>Why not pam_mkhomedir?</A
></DT
><DT
>4. <A
HREF="#AEN116"
>Where can Autodir be used?</A
></DT
><DT
>5. <A
HREF="#AEN126"
>What Autodir is not</A
></DT
><DT
>6. <A
HREF="#AEN130"
>Differences between Autodir and Autofs</A
></DT
><DT
>7. <A
HREF="#AEN170"
>How it works</A
></DT
><DT
>8. <A
HREF="#AEN235"
>Some definitions</A
></DT
><DT
>9. <A
HREF="#dirorg"
>Directory organization in the real base directory</A
></DT
><DT
>10. <A
HREF="#vdexp"
>Virtual directory expiration</A
></DT
><DT
>11. <A
HREF="#backup"
>Backup support</A
></DT
><DT
>12. <A
HREF="#backupreq"
>Backup program requirements</A
></DT
><DT
>13. <A
HREF="#AEN384"
>Module options</A
></DT
><DT
>14. <A
HREF="#AEN400"
>Autodir requirements</A
></DT
><DT
>15. <A
HREF="#autofs_kmod"
>Autofs kernel module</A
></DT
><DT
>16. <A
HREF="#AEN418"
>Importing user and group accounts</A
></DT
><DT
>17. <A
HREF="#AEN422"
>Getting Autodir</A
></DT
><DT
>18. <A
HREF="#homedir"
>Managing home directories</A
></DT
><DD
><DL
><DT
>18.1. <A
HREF="#AEN477"
>Base directories for autohome</A
></DT
><DT
>18.2. <A
HREF="#AEN514"
>Directory organization</A
></DT
><DT
>18.3. <A
HREF="#AEN522"
>Misc suboptions for autohome</A
></DT
><DT
>18.4. <A
HREF="#AEN531"
>Example</A
></DT
></DL
></DD
><DT
>19. <A
HREF="#AEN559"
>Managing group directories</A
></DT
><DT
>20. <A
HREF="#aoptions"
>Autodir options</A
></DT
><DT
>21. <A
HREF="#backupopts"
>Backup options</A
></DT
><DT
>22. <A
HREF="#AEN714"
>Examples</A
></DT
><DT
>23. <A
HREF="#AEN719"
>RPM specific</A
></DT
><DT
>24. <A
HREF="#moreinfo"
>Further Information</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="intro"
></A
>1. Introduction</H1
><P
><EM
>Autodir</EM
> offers a simple and effective means to create directories like home directories in a transparent manner. It relies on the <A
HREF="htp://www.autofs.org"
TARGET="_top"
>autofs</A
> protocol for its operation.</P
><P
>This document explains how to create directories on demand using <EM
>Autodir</EM
> in a transparent way to the applications. This document also explains using the transparent backup feature that is possible with <EM
>Autodir</EM
>, without system downtime for backup purpose; this applies for all directories managed by <EM
>Autodir</EM
>.</P
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="copyright"
></A
>1.1. Copyright and License</H2
><P
>&#13; This document, <EM
>Autodir HOWTO</EM
>,
is copyrighted (c) 2004 by <EM
>Venkata Ramana Enaganti</EM
>.
This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit <A
HREF="http://creativecommons.org/licenses/by/2.0"
TARGET="_top"
>http://creativecommons.org/licenses/by/2.0/</A
> or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
</P
><P
>&#13; Linux is a registered trademark of Linus Torvalds.
</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="disclaimer"
></A
>1.2. Disclaimer</H2
><P
>&#13; No liability for the contents of this document can be accepted.
Use the concepts, examples and information at your own risk.
There may be errors and inaccuracies, that could be damaging to
your system. Proceed with caution, and although this is highly
unlikely, the author(s) do not take any responsibility.
</P
><P
>&#13; All copyrights are held by their by their respective owners,
unless specifically noted otherwise. Use of a term in this
document should not be regarded as affecting the validity of any
trademark or service mark. Naming of particular products or
brands should not be seen as endorsements.
</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="feedback"
></A
>1.3. Feedback</H2
><P
>&#13; Feedback is most certainly welcome for this document. Send
your additions, comments and criticisms to the following
email address : <TT
CLASS="email"
>&#60;<A
HREF="mailto:ramana <> intraperson dot com"
>ramana &#60;&#62; intraperson dot com</A
>&#62;</TT
>.
</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="AEN78"
></A
>1.4. New Versions of this Document</H2
><P
>The latest version of this HOWTO will be made available from <A
HREF="http://www.intraperson.com/autodir/"
TARGET="_top"
>http://www.intraperson.com/autodir/</A
>.</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="credits"
></A
>1.5. Credits / Contributors</H2
><P
>&#13; In this document, I have the pleasure of acknowledging for language and technical review work:
</P
><P
></P
><UL
><LI
><P
>Rahul Sundaram<TT
CLASS="email"
>&#60;<A
HREF="mailto:rahulsundaram@yahoo.co.in"
>rahulsundaram@yahoo.co.in</A
>&#62;</TT
></P
></LI
><LI
><P
>Machtelt Garrels</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN91"
></A
>2. Before going into the details...</H1
><P
>After releasing intraperson beta, I started working on a administration guide that deals with the administration aspects of <EM
>intraPerson</EM
>. For more details check <A
HREF="http://www.intraperson.com"
TARGET="_top"
>http://www.intraperson.com</A
>. But I was stuck with one simple thing. It is easy to create users in LDAP - at least I think so - but how to create home directories for those users in LDAP wherever those LDAP accounts are imported?</P
><P
>I found some solutions, but I was not satisfied as every solution has serious drawbacks. After leafing through the Autofs documents and hacking a bit, I came to the conclusion that the Autofs protocol might offer a much better solution to this challenge.</P
><P
>The result is <EM
>Autodir</EM
>, based on the Autofs protocol.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN99"
></A
>3. Why not pam_mkhomedir?</H1
><P
>The PAM module <TT
CLASS="literal"
>pam_mkhomedir</TT
> uses Pluggable Authentication Module architecture for its operation. As such, there are some limitations associated with it. For instance:</P
><P
></P
><UL
><LI
><P
>Some servers may not authenticate users but they may expect user directories to exist. This means they do not use PAM, and in turn, <TT
CLASS="literal"
>pam_mkhomedir</TT
> does not get a chance to create home directories. The notorious example is on email servers.</P
></LI
><LI
><P
>PAM is always an optional component for authentication. Some services may not use PAM at all and use a different method to authenticate users. In this case <TT
CLASS="literal"
>pam_mkhomedir</TT
> is never going to be used.</P
></LI
><LI
><P
>Generally <TT
CLASS="filename"
>/home</TT
> is owned by root and only root users can create home directories in it. Therefore the service that wishes to create home directories through PAM must be run as root, or else the home directory must have the same permissions as, for instance, <TT
CLASS="filename"
>/tmp</TT
>.</P
></LI
></UL
><P
>Finally, <EM
>Autodir</EM
> is much wider in scope and supports many more interesting features.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN116"
></A
>4. Where can Autodir be used?</H1
><P
></P
><UL
><LI
><P
>Where user accounts reside in centralized database like LDAP, SQL, NIS, NIS+ or other databases, from which user and groups are imported to other systems. To create, for example home, group directories in those systems which import these accounts from centralized database, on demand.</P
></LI
><LI
><P
>To exploit its transparent backup feature for 24*7 online systems.</P
></LI
><LI
><P
>It can even be used when accounts are in a local system, to some extent hiding what accounts exist in the <TT
CLASS="filename"
>/home</TT
> directory, for example.</P
></LI
></UL
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN126"
></A
>5. What Autodir is not</H1
><P
><EM
>Autodir</EM
> can create directories but it does not remove them once user and/or group entries are removed from the system accounts database. Use custom made scripts from cron for this.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN130"
></A
>6. Differences between Autodir and Autofs</H1
><P
>Issue arises when you are already using the <SPAN
CLASS="application"
>Autofs</SPAN
> package, handling the mounts of (home) directories. Let's look at the differences between the two packages:</P
><P
></P
><UL
><LI
><P
>The main purpose of autofs is to deal with network mounts on demand instead of mounting all at the same time, which results in preserving system resources. Though there is some support in the autofs package to mount home directories on demand, the requirement is that <EM
>these home directories must exist already</EM
>.</P
><P
>On the other hand, <EM
>Autodir</EM
> specializes <EM
>only</EM
> in local directory creation and mounting them on demand.</P
><P
><EM
>Autodir</EM
> can also create real directories in disk file systems, which do not reside in one single flat base directory. This is how utilities like <B
CLASS="command"
>useradd</B
> create by default. In a standard file system setup, all home directories reside in the base <TT
CLASS="filename"
>/home</TT
> directory. For file systems like ext2 and ext3 performance will degrade if a large number of home directories exist in one single base directory.</P
><P
> For applications accessing these directories, <EM
>Autodir</EM
> presents all directories for them in a <EM
>single</EM
> autofs mounted virtual base directory <EM
>on demand</EM
>; actual directories are created in subdirectories of some other directory in hierarchical style.</P
><P
> For example, the real home for a user with username <TT
CLASS="literal"
>user1</TT
> will be created as <TT
CLASS="filename"
>/autohome/u/us/user1</TT
> if configured that way, but mounted in <TT
CLASS="filename"
>/home</TT
> on demand for applications accessing the home directory in <TT
CLASS="filename"
>/home/user1</TT
>.</P
><P
>Permissions for the real base directory, where the actual home directories are kept (<TT
CLASS="filename"
>/autohome</TT
> in the above example), are kept in such a way that <TT
CLASS="filename"
>/autohome</TT
> can not be accessed by anyone except by root.</P
><P
>This mounting of directories on demand and unmounting when not in use presents an interesting opportunity: the ability to tell whether a directory is in use or not. If a directory is not in use, a program like a backup application can be safely started when a directory is unmounted.</P
><P
><EM
>Autodir</EM
> exploits this capability by starting the command-line mentioned backup whenever a directory becomes unused.</P
></LI
><LI
><P
>There is one more important issue to be presented if you are an administrator reading this document. <EM
>Autodir</EM
> does not call the external programs <B
CLASS="command"
>mount</B
> and <B
CLASS="command"
>umount</B
>, as is the case with the autofs package; rather, it uses system calls directly. As a side effect, it is faster and more reliable, but the <TT
CLASS="filename"
>mtab</TT
> file is not updated. I felt this was not necessary as all mounts and unmounts are local directories.</P
></LI
><LI
><P
>Another minor difference is that <EM
>Autodir</EM
> is completely <EM
>multi-threaded</EM
>. Autofs is also expected to be multi-threaded in future versions.</P
></LI
></UL
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN170"
></A
>7. How it works</H1
><P
><EM
>Autodir</EM
> uses modules to get specific functionality. The core <EM
>Autodir</EM
> implements generic functionality that modules can exploit and add specific functionality to.</P
><P
>At any moment only one module can be added to <EM
>Autodir</EM
>. If there are two modules, for example <TT
CLASS="literal"
>autohome</TT
> and <TT
CLASS="literal"
>autogroup</TT
>, then two processes of <EM
>Autodir</EM
> should be created so that each process can have one of the required modules attached to it.</P
><P
>For further explanation I chose the <TT
CLASS="literal"
>autohome</TT
> module which handles transparent home directory creation.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Assumptions</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
></P
><UL
><LI
><P
>The <TT
CLASS="literal"
>autohome</TT
> module creates user home directories on demand if these do not exist already.</P
></LI
><LI
><P
>It is assumed that user accounts exists, but the accompanying home directories do not - either because these accounts were created with the <TT
CLASS="literal"
>-M</TT
> option with <B
CLASS="command"
>useradd</B
> or because these accounts were imported from LDAP, NIS or some other external database for which home directories are yet to be created.</P
></LI
><LI
><P
>It also assumed <EM
>for this explanation only</EM
> that all user home directories are expected to be in the <TT
CLASS="filename"
>/home</TT
> directory.</P
></LI
></UL
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>KISS</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Keep it Simple: Some fine details are intentionally kept aside to make the explanation easy to understand.</P
></TD
></TR
></TABLE
></DIV
><P
>First the autofs file system is mounted on the <TT
CLASS="filename"
>/home</TT
> directory by <EM
>Autodir</EM
>. The Linux kernel is informed that <TT
CLASS="filename"
>/home</TT
> is managed by a user space application, <EM
>Autodir</EM
>, from now on.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Autofs?</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Do not bother too much about the autofs file system if you do not understand about it. Just think of it as a special kind of file system, similar to memory based file systems but with some additional special properties.</P
></TD
></TR
></TABLE
></DIV
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;
+----------------+
| Linux Kernel |
+----------------+
/ \
/ \
/ \
/ \
+-------------+ +--------+ +------------+ +-----------------+
| Application |------&#62;| /home |&#60;-----&#62;| Autodir |&#60;------&#62;| autohome module |
+-------------+ +--------+ +------------+ +-----------------+
\ /
\ +----------------+ /
+-| /autohome |&#60;------------------+
+----------------+
</PRE
></FONT
></TD
></TR
></TABLE
><P
>Whenever an application or daemon needs access to a user's home directory, for example <TT
CLASS="filename"
>/home/userhome1</TT
>, they directly enter into <TT
CLASS="filename"
>/home/userhome1</TT
> to access it. The kernel, which notices this, informs <EM
>Autodir</EM
> if the <TT
CLASS="filename"
>userhome1</TT
> directory does not yet exist already in <TT
CLASS="filename"
>/home</TT
>.</P
><P
><EM
>Autodir</EM
>, in turn, passes this request to the <TT
CLASS="literal"
>autohome</TT
> module. The <TT
CLASS="literal"
>autohome</TT
> module does not touch the <TT
CLASS="filename"
>/home</TT
> directory. Instead it manages <EM
>real home directories</EM
> somewhere else, for example in <TT
CLASS="filename"
>/autohome</TT
> as shown in the above figure.</P
><P
>The <TT
CLASS="literal"
>autohome</TT
> module creates a real home directory if it does not exist in the <TT
CLASS="filename"
>/autohome</TT
> directory. After it is successfully created or failed to be created, whatever the outcome, <TT
CLASS="literal"
>autohome</TT
> reports back to <EM
>Autodir</EM
>. When the directory creation task has completed successfully, the path to real home directory is provided to <EM
>Autodir</EM
>.</P
><P
>If the <TT
CLASS="literal"
>autohome</TT
> module reports success, <EM
>Autodir</EM
> creates <TT
CLASS="filename"
>userhome1</TT
> directory under <TT
CLASS="filename"
>/home</TT
> and mounts the <EM
>real home directory</EM
> from <TT
CLASS="filename"
>/autohome</TT
> on it. At the end of the process, <EM
>Autodir</EM
> informs the kernel whether the whole operation was successful or not. Accordingly, the kernel allows applications to enter the directory, or, in case of failure, it reports that no such directory exists.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN235"
></A
>8. Some definitions</H1
><P
>Before going further it is better to understand the following terms to simplify explanation.</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><EM
>Virtual directories</EM
></DT
><DD
><P
> These directories do not exist on disk. Instead these are created and deleted on demand in memory. If the system reboots all these directories vanish. In the previous figure, all directories under <TT
CLASS="filename"
>/home</TT
> are <EM
>virtual directories</EM
>.</P
></DD
><DT
><EM
>Virtual base directory</EM
></DT
><DD
><P
> This is the directory that holds all <EM
>Virtual directories</EM
>. This directory <EM
>does</EM
> exist on disk and therefore it remains even after reboot. In the previous figure <TT
CLASS="filename"
>/home</TT
> is <EM
>virtual base directory</EM
>.</P
></DD
><DT
><EM
>Real directories</EM
></DT
><DD
><P
> These are the directories that actually reside on the disk. Even after reboot, these remain intact. In the previous figure all directories created under <TT
CLASS="filename"
>/autohome</TT
> are <EM
>real directories</EM
>.</P
></DD
><DT
><EM
>Real base directory</EM
></DT
><DD
><P
> This is the directory that holds all real directories. In the above figure <TT
CLASS="filename"
>/autohome</TT
> is <EM
>real base directory</EM
>.</P
></DD
></DL
></DIV
><P
>Each <EM
>virtual directory</EM
> is mapped to a <EM
>real directory</EM
>. This means that whatever is written to or modified in the <EM
>virtual directory</EM
> is actually sent to the <EM
>real directory</EM
>.</P
><P
>On reboot of the system <EM
>real directories</EM
> and their content remain intact. But <EM
>virtual directories</EM
> are again created on demand, exactly as they were before.</P
><P
><EM
>Virtual directories</EM
> are removed if these are not used for a specified period of time, and created again if necessary. When a <EM
>Virtual directory</EM
> is removed, the backup program is started on the corresponding <EM
>real directory</EM
> - if backup is configured.</P
><DIV
CLASS="important"
><P
></P
><TABLE
CLASS="important"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/important.gif"
HSPACE="5"
ALT="Important"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Applications should access only <EM
>virtual directories</EM
>. <EM
>Real directories</EM
> are hidden from applications. Only the root user can see them. There is one exception: backup programs always access the <EM
>real directories</EM
> only.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="dirorg"
></A
>9. Directory organization in the real base directory</H1
><P
>Why should there be any special organization in the <EM
>real base directory</EM
>? If we just create all <EM
>real directories</EM
> in one <EM
>real base directory</EM
> there could be a performance penalty when there are a large number of <EM
>real directories</EM
> to be created. File systems like ext2/ext3 are not optimized for this kind of flat directory structure.</P
><P
>It would be much better if the <EM
>real base directory</EM
> is divided into more subdirectories, or even to divide these subdirectories again into more subdirectories. And in the final subdirectories actual home directories are kept.</P
><P
>There are three types of directory organization:</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><EM
>level 0</EM
></DT
><DD
><P
>Actually no organization. All home directories are created directly under <EM
>real base directory</EM
>.</P
></DD
><DT
><EM
>level 1</EM
></DT
><DD
><P
>The <EM
>Real base directory</EM
> is divided into more subdirectories. The subdirectory names are derived from the first character of the final directory to be created. For example, if the <TT
CLASS="filename"
>user1</TT
> directory is to be created, first a directory named 'u' is created under <EM
>real base directory</EM
>. Then in that subdirectory the actual directory <TT
CLASS="filename"
>user1</TT
> is created as <TT
CLASS="filename"
>/&#60;real_base_directory&#62;/u/user1</TT
>.</P
></DD
><DT
><EM
>level 2</EM
></DT
><DD
><P
>Same as level 1 organization but after the first level of subdirectories, a second level of subdirectories is created. The names here are the first two characters of the final directory to be created. For example, for user <TT
CLASS="literal"
>user1</TT
>, as in the above example, the <TT
CLASS="filename"
>/&#60;real_base_directory&#62;/u/us/user1</TT
> directory is created.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="vdexp"
></A
>10. Virtual directory expiration</H1
><P
>When an application tries to access a <EM
>virtual directory</EM
> in a <EM
>virtual base directory</EM
>, <EM
>Autodir</EM
> creates the <EM
>virtual directory</EM
> in it if it does not exist already and mounts the <EM
>real directory</EM
> on it from the <EM
>real base directory</EM
>. Once this is done, a timer is started. If the <EM
>virtual directory</EM
> is not accessed from the <EM
>virtual base directory</EM
> by any application for the specified period of time, this directory is removed and the corresponding <EM
>real directory</EM
> in the <EM
>real base directory</EM
> is marked for backup.</P
><P
>The time period to wait for expiration can be given through a <A
HREF="#autodir_t_opt"
>command line option</A
> to <EM
>Autodir</EM
>.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="backup"
></A
>11. Backup support</H1
><P
> <EM
>Autodir</EM
> supports backup program launching when a <EM
>virtual directory</EM
> is removed after a period of inactivity. Removal of the <EM
>virtual directory</EM
> is itself an assurance that no other application can access the content and modify it.</P
><P
>Just like there is wait time for expiring a <EM
>virtual directory</EM
>, for backup <EM
>Autodir</EM
> also waits during some time after the expiry of the <EM
>virtual directory</EM
>, prior to starting the backup. This time period can be configured through a <A
HREF="#autodir_w_opt"
>command line option</A
> to <EM
>Autodir</EM
>.</P
><P
>By design, backup programs are expected to operate on <EM
>real directories</EM
> but not on <EM
>virtual directory</EM
>. If the backup program try to access a <EM
>virtual directory</EM
>, then <EM
>Autodir</EM
> assumes some regular application is in need of that directory and the backup program is killed, even if the <EM
>virtual directory</EM
> accessing process is the backup program itself.</P
><P
>A separate backup process for each <EM
>real directory</EM
> is used. The backup program can be given <A
HREF="#back_esc_str"
>arguments</A
> of <EM
>real directories</EM
> on which to operate.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Backup support is independent of any particular module being used. It is applicable to all modules with <EM
>Autodir</EM
>.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="important"
><P
></P
><TABLE
CLASS="important"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/important.gif"
HSPACE="5"
ALT="Important"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Backup = real!</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Backup programs should never access <EM
>virtual directory</EM
> or <EM
>virtual base directory</EM
>.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="caution"
><P
></P
><TABLE
CLASS="caution"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/caution.gif"
HSPACE="5"
ALT="Caution"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Time off</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The backup feature is not much use if the <EM
>virtual directories</EM
> are being accessed by applications all the time.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="backupreq"
></A
>12. Backup program requirements</H1
><P
><EM
>Autodir</EM
> demands some extra requirements from the backup program being used: when the backup is working on the <EM
>real directory</EM
>, with corresponding expired <EM
>virtual directory</EM
>, and that <EM
>virtual directory</EM
> is requested again by an application while the backup is running, the backup process is killed. First a <TT
CLASS="literal"
>SIGTERM</TT
> is sent to gracefully stop it. But if it does not shut down in time - and it has one second to do this - a <TT
CLASS="literal"
>SIGKILL</TT
> will be sent, which is guaranteed to stop the backup.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>Only when the backup has stopped the application is given access to the requested <EM
>virtual directory</EM
>.</TD
></TR
></TABLE
></DIV
><DIV
CLASS="important"
><P
></P
><TABLE
CLASS="important"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/important.gif"
HSPACE="5"
ALT="Important"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Whatever backup is used, it should be able to recover from this signal gracefully, not causing unrecoverable side effects.</P
></TD
></TR
></TABLE
></DIV
><P
>One more important issue is the environment in which the backup runs. All backup programs run as root. But at the same time all unnecessary root privileges are taken away using POSIX capabilities. In other words these backup programs can read any file or directory that belongs to any user on the system and nothing more than that. Other than that, the backup process behaves like an ordinary user level process.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN384"
></A
>13. Module options</H1
><P
>There are two kinds of options that can be passed to <EM
>Autodir</EM
>. In the first type, <A
HREF="#aoptions"
>options</A
> are for <B
CLASS="command"
>autodir</B
> itself and are common irrespective of which module is used. The other type of options are specific to the module being used. These options are called suboptions and are passed to the module being used; they are different from the main <TT
CLASS="literal"
>-o</TT
> option. This is similar to the suboptions used with the <B
CLASS="command"
>mount</B
> command.</P
><P
>For example, suboptions to the example module <TT
CLASS="literal"
>autohome</TT
> can be passed as follows:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;-o 'realpath=/tmp/autohome,level=2,noskel'
</PRE
></FONT
></TD
></TR
></TABLE
><P
>Here <TT
CLASS="literal"
>realpath</TT
>, <TT
CLASS="literal"
>level</TT
> and <TT
CLASS="literal"
>noskel</TT
> are suboptions for <TT
CLASS="literal"
>autohome</TT
> module.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN400"
></A
>14. Autodir requirements</H1
><P
></P
><UL
><LI
><P
>You will need a Linux kernel equal to or later than version 2.4. These kernel versions support mounting one directory on another directory. At this moment <EM
>Autodir</EM
> is not ported to other Unices but this may change in the future.</P
></LI
><LI
><P
><EM
>Autodir</EM
> requires the autofs kernel module based on protocol version 4. But it does not require the autofs user level package. The autofs kernel module is pretty standard and almost all distributions include it.</P
></LI
></UL
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="autofs_kmod"
></A
>15. Autofs kernel module</H1
><P
><EM
>Autodir</EM
> uses the autofs kernel module for its operation. The kernel module <TT
CLASS="literal"
>autofs</TT
> must be loaded before starting <B
CLASS="command"
>autodir</B
>.</P
><P
>This can be done as the root user, using the <B
CLASS="command"
>modprobe</B
> command as follows:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# modprobe autofs
</PRE
></FONT
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN418"
></A
>16. Importing user and group accounts</H1
><P
>If user and group accounts reside in a centralized database these must be imported before starting <EM
>Autodir</EM
>. How to do this is out of the scope of this HOWTO. There are a number of documents which explain in a clear way how to do this.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN422"
></A
>17. Getting Autodir</H1
><P
>At this moment <EM
>Autodir</EM
> is available in tar and rpm formats. More information can be found at <A
HREF="http://www.intraperson.com/autodir/"
TARGET="_top"
>http://www.intraperson.com/autodir/</A
>.</P
><P
>After downloading the source, follow these simple steps to install :</P
><P
></P
><UL
><LI
><P
>Unpack the source.</P
><P
><TT
CLASS="literal"
>$ tar zxvf &#60;tar file name&#62;</TT
></P
></LI
><LI
><P
>Move to the expanded directory and execute the following commands:</P
><P
><TT
CLASS="literal"
>$ ./configure</TT
></P
><P
><TT
CLASS="literal"
>$ make</TT
></P
><P
><TT
CLASS="literal"
># make install</TT
></P
></LI
></UL
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>No go?</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The <TT
CLASS="literal"
>configure</TT
> script checks for the required libraries. If these are not present it will stop.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="homedir"
></A
>18. Managing home directories</H1
><P
>This section will explain how to configure <EM
>Autodir</EM
> so that user home directories are created on demand. For this purpose the <TT
CLASS="literal"
>autohome</TT
> module, which deals with specifics of home directory creation, is used.</P
><P
>To load the <TT
CLASS="literal"
>autohome</TT
> module with <EM
>Autodir</EM
>, use the <TT
CLASS="literal"
>-m</TT
> option. For example, <TT
CLASS="literal"
>-m /usr/lib/autodir/autohome.so</TT
>.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>User/home matching</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>When an application tries to access a home directory, that home directory is used to check if there is any user with the same user name as the directory name being accessed. If a user name exists, then the home directory is created. Otherwise the message <SPAN
CLASS="QUOTE"
>"no such file or directory"</SPAN
> is reported back to the application.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>User accounts</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
><TT
CLASS="literal"
>Autohome</TT
> does not deal with the creation of user accounts on local systems, in LDAP or in any other database. It only deals with creating home directories once these accounts exist and are imported to the local system from databases like LDAP and NIS.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="important"
><P
></P
><TABLE
CLASS="important"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/important.gif"
HSPACE="5"
ALT="Important"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Limitations</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>It is worth mentioning one limitation of the <TT
CLASS="literal"
>autohome</TT
> module. It expects that user name and home directory are related to each other. For example, for user <TT
CLASS="literal"
>user1</TT
> the home directory should be <TT
CLASS="filename"
>/home/user1</TT
> or <TT
CLASS="filename"
>/some/directory/name/user1</TT
> but not <TT
CLASS="filename"
>/some/directory/name/userhome1</TT
>. This can be supported but it will be a burden on system resources as each password entry has to be examined from first to last.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Knowing when not to use autohome</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>If the existing user password database is such that user home directories are distributed under different base directories, for example <TT
CLASS="filename"
>/home/class1/user1</TT
>, <TT
CLASS="filename"
>/home/class2/user2332</TT
>, then <TT
CLASS="literal"
>autohome</TT
> configuration becomes complicated and is not recommended.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="AEN477"
></A
>18.1. Base directories for autohome</H2
><P
>The next step in the setup procedure is to decide where the <EM
>virtual base directory</EM
> and <EM
>real base directory</EM
> for home directory creation will be located.</P
><P
>What are the <EM
>virtual base directory</EM
> and the <EM
>real base directory</EM
> in the context of the <TT
CLASS="literal"
>autohome</TT
> module?</P
><P
>This all depends on how user accounts are created. If a user account created for user name user1 with home directory <TT
CLASS="filename"
>/home/user1</TT
> then <TT
CLASS="filename"
>/home</TT
> <EM
>will become the virtual base directory</EM
>.</P
><P
>Then what is the <EM
>real base directory</EM
>? This can be any directory. The only thing that you need to keep in mind is that there should be enough space, as all actual files are stored here instead of in the <EM
>virtual base directory</EM
>.</P
><P
>In most server configurations <TT
CLASS="filename"
>/home</TT
> is a separate partition. But if <TT
CLASS="filename"
>/home</TT
> is the <EM
>virtual base directory</EM
>, then files are not stored in that directory! The solution is not to mount a partition on <TT
CLASS="filename"
>/home</TT
> but instead mount it somewhere else and make it the <EM
>real base directory</EM
>.</P
><P
>The <EM
>Autodir</EM
> option <TT
CLASS="literal"
>-d</TT
> is used to specify the <EM
>virtual base directory</EM
>. For example: <TT
CLASS="literal"
>autodir -d /home</TT
> assumes that <TT
CLASS="filename"
>/home</TT
> is the <EM
>virtual base directory</EM
>.</P
><P
>It is somewhat tricky to specify the <EM
>real base directory</EM
>. The <EM
>real base directory</EM
> is managed by the <TT
CLASS="literal"
>autohome</TT
> module so this option must be passed to the module through module suboptions. If the <EM
>real base directory</EM
> is <TT
CLASS="filename"
>/var/autohome</TT
> then it is specified with the option <TT
CLASS="literal"
>-o</TT
> as <TT
CLASS="literal"
>-o realpath=/var/autohome</TT
>.</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="AEN514"
></A
>18.2. Directory organization</H2
><P
>Refer to <A
HREF="#dirorg"
>directory organization under the real base directory</A
> for a detailed explanation of this topic.</P
><P
><TT
CLASS="literal"
>autohome</TT
> does support this kind of organization. The suboption used to specify the desired directory organization the <TT
CLASS="literal"
>level</TT
> suboption, for instance: <TT
CLASS="literal"
>-o level=2</TT
>.</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="AEN522"
></A
>18.3. Misc suboptions for autohome</H2
><P
>The suboption <TT
CLASS="literal"
>skel</TT
> can be used if the skeleton path is not the default value <TT
CLASS="filename"
>/etc/skel</TT
>: <TT
CLASS="literal"
> -o skel=/some/other/dir</TT
>.</P
><P
>The suboption <TT
CLASS="literal"
>noskel</TT
> can be used with <TT
CLASS="literal"
>-o</TT
> to indicate not to copy any skeleton files to the home directories when these are created.</P
></DIV
><DIV
CLASS="sect2"
><HR><H2
CLASS="sect2"
><A
NAME="AEN531"
></A
>18.4. Example</H2
><P
>First, import your user accounts from a centralized database, for instance from LDAP.</P
><P
>Next, the <TT
CLASS="literal"
>autofs</TT
> kernel module must be loaded into the Linux kernel. This can be done as described in <A
HREF="#autofs_kmod"
>autofs kernel module section</A
>.</P
><P
>If <TT
CLASS="filename"
>/home</TT
> is to be used for home directories then <TT
CLASS="filename"
>/home</TT
> will become the <EM
>virtual directory</EM
>; this is specified to <B
CLASS="command"
>autodir</B
> with the <TT
CLASS="literal"
>-d /home</TT
> option.</P
><P
>Assuming that the <TT
CLASS="literal"
>autohome</TT
> module is located in <TT
CLASS="filename"
>/usr/lib/autodir/autohome.so</TT
>, this module can be loaded with <B
CLASS="command"
>autodir</B
> as <TT
CLASS="literal"
>-m /usr/lib/autodir/autohome.so</TT
>. Note that the full path for the module is given.</P
><P
>The actual location of the real home directories is given with the <TT
CLASS="literal"
>realpath</TT
> suboption. If it is <TT
CLASS="filename"
>/autohome</TT
>, the location can be specified as <TT
CLASS="literal"
>realpath=/autohome</TT
>.</P
><P
>With all these options <B
CLASS="command"
>autodir</B
> can be started as:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# autodir -d /home \
-m /usr/lib/autodir/autohome.so \
-o 'realpath=/autohome' \
</PRE
></FONT
></TD
></TR
></TABLE
><P
>Once <EM
>Autodir</EM
> is started, initially the <TT
CLASS="filename"
>/home</TT
> directory will be empty. Whether <EM
>Autodir</EM
> is working properly can be tested by changing directories to one of the home directories, as the root user or as the owner of the home directory.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN559"
></A
>19. Managing group directories</H1
><P
>The <TT
CLASS="literal"
>autogroup</TT
> module is used for creating group directories on demand for common group access. It can be used with Samba, for example, to dynamically create shared directories for a group of people.</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Check</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The <TT
CLASS="literal"
>autogroup</TT
> module checks for the requested directory in valid groups from the system group database.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="tip"
><P
></P
><TABLE
CLASS="tip"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Using autogroup for the creation of home directories</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The <TT
CLASS="literal"
>autogroup</TT
> module can be used to create home directories as well, provided that user private groups exist for each user. This way all group and home directories can be created in one place with one module. However, no skeleton files will be copied and the <TT
CLASS="literal"
>autogroup</TT
> suboption <TT
CLASS="literal"
>nopriv</TT
> should not be used.</P
></TD
></TR
></TABLE
></DIV
><P
>The <TT
CLASS="literal"
>autogroup</TT
> configuration is the same as the <TT
CLASS="literal"
>autohome</TT
> module, but unlike <TT
CLASS="literal"
>autohome</TT
>, the <EM
>virtual base directory</EM
> can be placed anywhere and any name can be given to it. It is not dictated by system accounts.</P
><P
>The module <TT
CLASS="literal"
>autogroup</TT
> can be used with <EM
>Autodir</EM
> using the <TT
CLASS="literal"
>-m</TT
> option. For example, <TT
CLASS="literal"
>-m /usr/lib/autodir/autogroup.so</TT
>.</P
><P
>All suboptions explained in <A
HREF="#homedir"
>managing home directories</A
> are the same for <TT
CLASS="literal"
>autogroup</TT
>, except <TT
CLASS="literal"
>skel</TT
> and <TT
CLASS="literal"
>noskel</TT
>, as these are meaningless for the <TT
CLASS="literal"
>autogroup</TT
> module. Additionally, there are other suboptions specific to <TT
CLASS="literal"
>autogroup</TT
>. These are given below.</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><TT
CLASS="literal"
>nopriv</TT
></DT
><DD
><P
>Some Linux installations use user private groups. If directories for these groups are not to be created, then use this suboption.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="aoptions"
></A
>20. Autodir options</H1
><P
>In this section some of the options to <EM
>Autodir</EM
> are explained. Backup options are explained in the <A
HREF="#backupopts"
>backup section</A
>.</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><TT
CLASS="literal"
>-d</TT
></DT
><DD
><P
>Specifies the <EM
>virtual base directory</EM
>. If this path does not exist, it will be created. An absolute path is expected for this option.</P
></DD
><DT
><TT
CLASS="literal"
>-t</TT
></DT
><DD
><P
>Expiration timeout for <EM
>virtual directories</EM
>. For more details refer to <A
HREF="#vdexp"
>virtual directory expiration</A
>.</P
></DD
><DT
><TT
CLASS="literal"
>-m</TT
></DT
><DD
><P
>Module to be used with <EM
>Autodir</EM
>. Currently <TT
CLASS="literal"
>autohome</TT
> and <TT
CLASS="literal"
>autogroup</TT
> are available. The full path to the module is expected.</P
></DD
><DT
><TT
CLASS="literal"
>-o</TT
></DT
><DD
><P
>All suboptions that are to be passed to module are given here. This option passing syntax is similar to that of the <B
CLASS="command"
>mount</B
> command with its <TT
CLASS="literal"
>-o</TT
> option. See specific module sections for more info.</P
></DD
><DT
><TT
CLASS="literal"
>-f</TT
></DT
><DD
><P
>Run in the foreground and log all messages to the console. For debugging purpose and to see how <EM
>Autodir</EM
> works.</P
></DD
><DT
><TT
CLASS="literal"
>-l</TT
></DT
><DD
><P
>This option expects a path name to a file in which <EM
>Autodir</EM
> will write its process id.</P
></DD
><DT
><TT
CLASS="literal"
>-h</TT
></DT
><DD
><P
>Help about all options supported by <EM
>Autodir</EM
>.</P
></DD
><DT
><TT
CLASS="literal"
>-v</TT
></DT
><DD
><P
>Version information about <EM
>Autodir</EM
>.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="backupopts"
></A
>21. Backup options</H1
><P
>These options are passed to <EM
>Autodir</EM
> to request backup support.</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><TT
CLASS="literal"
>-b</TT
></DT
><DD
><P
>This is the main option to specify the backup program path and arguments to it. The path given should be an absolute path, otherwise <EM
>Autodir</EM
> does not accept it.</P
></DD
><DT
><TT
CLASS="literal"
>-w</TT
></DT
><DD
><P
>Whenever a <EM
>virtual directory</EM
> is not used for a period of time, it is assumed inactive and it is unmounted. After unmounting the directory, whether to launch the backup immediately or to wait some more time is decided with this option. It takes arguments in seconds. It is the <EM
>minimum</EM
> time to wait before starting backup after <EM
>virtual directory</EM
> expiration. It should not exceed one day.</P
></DD
><DT
><TT
CLASS="literal"
>-p</TT
></DT
><DD
><P
>This is the priority to be given to the backup process. <EM
>This is in the range of 1 to 40 inclusive</EM
>. Lower value means higher priority and vice versa. The default value is 30.</P
></DD
><DT
><TT
CLASS="literal"
>-c</TT
></DT
><DD
><P
>This restricts the maximum number of backup processes at any given time. The default is 150.</P
></DD
></DL
></DIV
><DIV
CLASS="caution"
><P
></P
><TABLE
CLASS="caution"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/caution.gif"
HSPACE="5"
ALT="Caution"></TD
><TH
ALIGN="LEFT"
VALIGN="CENTER"
><B
>Using quotes</B
></TH
></TR
><TR
><TD
>&nbsp;</TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The argument for the <TT
CLASS="literal"
>-b</TT
> option is includes the absolute backup program path as well as its own arguments. Therefore it is recommended to use single quotes around this argument.</P
></TD
></TR
></TABLE
></DIV
><P
>The <TT
CLASS="literal"
>-b</TT
> option takes a path to executable file as well as arguments to it. However, the arguments are interpreted for a sequence of %x characters and replaced with predefined strings as follows:</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><TT
CLASS="literal"
>%N</TT
></DT
><DD
><P
>Replaced with the <EM
>virtual directory</EM
> name.</P
></DD
><DT
><A
NAME="back_esc_str"
></A
><TT
CLASS="literal"
>%L</TT
></DT
><DD
><P
>Replaced with an absolute path to the <EM
>real directory</EM
>.</P
></DD
><DT
><TT
CLASS="literal"
>%K</TT
></DT
><DD
><P
>Replaced with host name.</P
></DD
><DT
>Others</DT
><DD
><P
>Others are fed to <TT
CLASS="literal"
>strftime</TT
>. See the man page for <TT
CLASS="literal"
>strftime</TT
> for more information.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN714"
></A
>22. Examples</H1
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# autodir -d /home \
-m /usr/lib/autodir/autohome.so \
-t 1000 \
-f \
-o 'realpath=/autohome,level=1,skel=/etc/skel' \
-l /var/run/autodir.pid
</PRE
></FONT
></TD
></TR
></TABLE
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# autodir -d /home \
-m /usr/lib/autodir/autohome.so \
-t 300 \
-b '/bin/tar cf /tmp/%N%F.tar %L' \
-w 600 \
-o 'realpath=/tmp/autohome,level=2,noskel' \
-l /var/run/autodir.pid
</PRE
></FONT
></TD
></TR
></TABLE
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# autodir -d /var/abase/ \
-m /usr/lib/autodir/autogroup.so \
-t 300 \
-b '/bin/tar cf /tmp/%N%F.tar %L' \
-w 86400 \
-o 'nopriv,nosetgid,realpath=/var/realbase,level=0'
</PRE
></FONT
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="AEN719"
></A
>23. RPM specific</H1
><P
><EM
>Autodir</EM
> can be installed from rpms as follows:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
>&#13;# rpm -ivh autodir-0.28-4.i386.rpm
</PRE
></FONT
></TD
></TR
></TABLE
><P
>When installed from rpms, two startup scripts are provided: <TT
CLASS="filename"
>/etc/rc.d/init.d/autohome</TT
> and <TT
CLASS="filename"
>/etc/rc.d/init.d/autogroup</TT
>. The first one is for starting <EM
>Autodir</EM
> with the <TT
CLASS="literal"
>autohome</TT
> module, the second for starting with the <TT
CLASS="literal"
>autogroup</TT
> module.</P
><P
>The script configuration files <TT
CLASS="filename"
>/etc/sysconfig/autohome</TT
> and <TT
CLASS="filename"
>/etc/sysconfig/autogroup</TT
> can be used to specify what options can be passed to <EM
>Autodir</EM
>.</P
></DIV
><DIV
CLASS="sect1"
><HR><H1
CLASS="sect1"
><A
NAME="moreinfo"
></A
>24. Further Information</H1
><P
></P
><UL
><LI
><P
><EM
>Mailing list for autodir </EM
><A
HREF="http://lists.sourceforge.net/mailman/listinfo/intraperson-autodir"
TARGET="_top"
>http://lists.sourceforge.net/mailman/listinfo/intraperson-autodir</A
>.</P
></LI
><LI
><P
>Official website is at <A
HREF="http://www.intraperson.com/autodir/"
TARGET="_top"
>http://www.intraperson.com/autodir/</A
>.</P
></LI
><LI
><P
>Autofs mailing list <A
HREF="http://linux.kernel.org/mailman/listinfo/autofs"
TARGET="_top"
>http://linux.kernel.org/mailman/listinfo/autofs</A
>.</P
></LI
><LI
><P
>The Automount HOWTO can be found at <A
HREF="http://www.tldp.org"
TARGET="_top"
>http://www.tldp.org</A
></P
></LI
><LI
><P
>Autofs Hacking <A
HREF="http://www.goop.org/~jeremy/autofs/"
TARGET="_top"
>http://www.goop.org/~jeremy/autofs</A
>.</P
></LI
></UL
></DIV
></DIV
></BODY
></HTML
>
Reference in New Issue View Git Blame Copy Permalink