Thanks to Dave Carrigan, Charles, Tim Desjarins, Shane Sigler,Mark Peters,
Steve Tylock,Stuart McDow,Brent from Sun , and Rick Pluta.
My original post was:
> We are debating within our group how the automount maps should be
> setup for home and applications. Currently /home and /apps are indirect
> automount points, but each user will mount the whole directory.
> For example the auto.master will look like this:
> /stage auto.indirect
> and auto.indirect will look like this:
> home server1:/home
> apps server1:/apps
> The arguments for this are it is simple and has always worked.
> Some of us (myself included) are saying each application and home directory
>should be a separate automount point. For example the auto.master should be:
>/home auto.home
>/apps auto.apps
>The auto.home would look like:
>joe server1:/home/joe
>sue server1:/home/sue
>Those in favor of this way are saying it would decrease network traffic because
>you would not mount a whole directory and it would give us more flexibility
>in configuration of users home. Can anyone add to this arguments and tell
>us what way they think would be better.
The general consensus was that it was a big win in flexability, however it addedsome complexity to the maps and did not save you anything on network bandwidth.
We are going to implement it because it will give us the flexability we need.
There was also a great paper called The Art of Automounting(TheArtofAutomounting) available via ftp. It really layed out the details quite well.
For those of you who like to read alot here are the replies:
>From dcarrigan@nofc.forestry.ca Sat Nov 5 20:34:52 1994
From: dcarrigan@nofc.forestry.ca
Date: Sat, 05 Nov 1994 18:34:06 -0700
Subject: NIS Automount Debate
To: phoff@panix.com (Phil Hoff)
Content-Transfer-Encoding: 7BIT
Content-Length: 3272
Status: RO
X-Lines: 69
>>>>> "Phil" == Phil Hoff <phoff@panix.com> writes:
Phil> We are debating within our group how the automount maps should be
Phil> setup for home and applications. Currently /home and /apps are indirect
Phil> automount points, but each user will mount the whole directory.
Phil> For example the auto.master will look like this:
Phil> /stage auto.indirect
Phil> and auto.indirect will look like this:
Phil> home server1:/home
Phil> apps server1:/apps
Phil> The arguments for this are it is simple and has always worked.
Phil> Some of us (myself included) are saying each application and home directory
Phil> should be a separate automount point. For example the auto.master should be:
Phil> /home auto.home
Phil> /apps auto.apps
Phil> The auto.home would look like:
Phil> joe server1:/home/joe
Phil> sue server1:/home/sue
Phil> Those in favor of this way are saying it would decrease network
Phil> traffic because you would not mount a whole directory and it
Phil> would give us more flexibility in configuration of users
Phil> home. Can anyone add to this arguments and tell us what way
Phil> they think would be better.
This is the way that I do it. The big win here is definitely the
flexibility. By doing it the other way, you aren't gaining
anything. In fact, the functionality would be the same as if you just
put static mounts into your fstab file, and that would be even less
complex. The whole purpose of the automounter is to give you the
freedom to split up mount points across servers. You can also use the
automounter to load balance servers, which gives you redundancy and
faster service.
The big disadvantage to this is that you could end up with a lot of
mount points---one for each home directory. I.e., when joe signs on,
automount mounts server:/home/joe onto /tmp_mnt/home/joe. Then when
sue signs on, automount mounts server:/home/sue onto
/tmp_mnt/home/sue. You can configure Sun's automounter to only make
one mount instead of multiple mounts; it's listed in the advanced
features section. The problem with this is that the mount points get to be
confusing. This is because the first time automount is required to
mount somebody's home directory from a particular server, it mounts
the entire home directory onto that mount point and then twiddles the
symlinks. So, if joe were to sign on, automount would mount
server:/home onto /tmp_mnt/home/joe. Then, it would symlink /home/joe
to /tmp_mnt/home/joe/joe. When sue signs on, server:/home is already
mounted, so automount symlinks /home/sue to /tmp_mnt/home/joe/sue.
If sue does a getcwd, her working directory appears to be under joe's,
which can be confusing.
The AMD automounter, which I use and prefer, solves this problem.
server:/home gets mounted onto /a/server/home, and the getcwd command
would return something like /a/server/home/joe or /a/server/home/sue.
AMD is much more complicated than Sun's automounter to set up---mostly
because Sun has much better documentation.
Hope this helps some!
--^ dcarrigan@nofc.forestry.ca /|\ Canadian Forest Service, NW Region Dave Carrigan /|\ Northern Forestry Centre Systems/Network Administrator | Unix/VMS/TCP-IP/DECnet/Pathworks
>From charles@vampire.backfire.mn.org Sat Nov 5 15:43:52 1994 Date: Sat, 5 Nov 94 08:51:39 CST From: charles@vampire.backfire.mn.org (Charles) To: phoff@panix.com (Phil Hoff) Subject: Re: NIS Automount Debate Newsgroups: comp.sys.sun.admin Content-Length: 3458 Status: RO X-Lines: 75
In article <39bmdq$6i4@panix2.panix.com> you wrote: : We are debating within our group how the automount maps should be : setup for home and applications. Currently /home and /apps are indirect : automount points, but each user will mount the whole directory.
Not quite. If you do a cd /stage, nothing is mounted. If you do a cd /stage/home, then home is mounted, but not apps. What do you mean about each user mounting the whole directory? You mean as in all of home for example? Each user will not mount a copy of "home". Only the first user will, each subsequent access of "home" will simply use the current mount point of the previous user. If you think mounting the entire home is bad, it isn't. Its no less efficient mounting a whole tree rather than just a single directory, in fact, its more efficient. Now only one mount has to be made. If you set it up as individual home directories as you want to below, then you will be forcing a mount for each user's home dir.
: For example the auto.master will look like this: : /stage auto.indirect : and auto.indirect will look like this: : home server1:/home : apps server1:/apps : The arguments for this are it is simple and has always worked.
Simple, but not very flexible.
: Some of us (myself included) are saying each application and home directory : should be a separate automount point. For example the auto.master should be: : /home auto.home : /apps auto.apps : The auto.home would look like: : joe server1:/home/joe : sue server1:/home/sue
This is a much better solution. In fact, if you read the automounter chapter in the Sun System and Network Administration guide, this is what Sun recommends doing. This is exactly what we do where I work and its great. The one bad thing about it is, that each user does cause a seperate mount for their home directory. But we have about 1500 users in our NIS maps and its never caused us a problem. A better way to do it is described in the Sun manuals, where only one mount is forced for each home file system. Ie, the way we do it, and the way you want to do it, if both joe and sue logged into the same machine, they would force two seperate mounts. If joe and sue where on the same physical partition on the NFS server, Sun has an example that would only cause one mount to occur.
: Those in favor of this way are saying it would decrease network traffic because : you would not mount a whole directory and it would give us more flexibility : in configuration of users home. Can anyone add to this arguments and tell : us what way they think would be better.
You're wrong. It won't decrease network traffic. As I said above, it is MORE efficient to mount the whole directory. However, unless you have 10000 people in your NIS domain, the increased traffic won't be noticed at all. But yes, you are correct that it is more flexible. Your current way is wrong and should be changed if possible. One REAL benefit with the seperate in direct maps is doing things like:
joe server1:/home/joe sue server2:/home/sue
Now you can easily divide up your server load and put home directories wherever you want them. You can also move the home directories at any time you may need to, and the user will never notice.
I think you guys need to go reread the automounter chapter again. If you need more help, I would pick up NFS and NIS from O'Reilly, they explain the automounter in great detail.
Charles
>From timd@bmo.com Mon Nov 7 11:38:50 1994 Date: Mon, 7 Nov 1994 11:34:12 -0500 From: timd@bmo.com (Tim Desjardins) To: phoff@panix.com Subject: RE: NIS Automount Debate Content-Length: 1889 X-Lines: 43 Status: RO
Phil,
>We are debating within our group how the automount maps should be >setup for home and applications. Currently /home and /apps are indirect >automount points, but each user will mount the whole directory. >For example the auto.master will look like this: >/stage auto.indirect >and auto.indirect will look like this: >home server1:/home >apps server1:/apps
>The arguments for this are it is simple and has always worked. >Some of us (myself included) are saying each application and home directory >should be a separate automount point. For example the auto.master should be: >/home auto.home >/apps auto.apps >The auto.home would look like: >joe server1:/home/joe >sue server1:/home/sue >Those in favor of this way are saying it would decrease network traffic because >you would not mount a whole directory and it would give us more flexibility >in configuration of users home. Can anyone add to this arguments and tell >us what way they think would be better.
We use the latter method for useres and it works well, but I'd like to address your arguments. Yes, the direct maps for users is a great idea and adds some flexibility, but with flexibility comes complexity, something your sysadmin may not want.
Secondly there is more nfs traffic with the direct maps since users connecting to a new machine must use their direct map to mount their directory, regardless of who is on the machine already. Or if you wish to cd into anothers directory you have to mount their directory using the direct map.
I believe apps should be mounted using indirect maps, since you can use local maps to override the NIS provided maps. We do this for special situations or testing or savy groups who don't mind managing their own machines but in general we have such a vanilla user base the direct user maps with indeirect apps maps works well.
Hope this helps,
Tim Desjarins
>From Shane.Sigler@corp.sun.com Mon Nov 7 12:52:00 1994 Date: Mon, 7 Nov 1994 09:49:56 -0800 From: Shane.Sigler@corp.sun.com (Shane Sigler) To: phoff@panix.com Subject: Re: NIS Automount Debate Cc: Content-Length: 1455 Status: RO X-Lines: 38
In article 6i4@panix2.panix.com, phoff@panix.com (Phil Hoff) writes: >We are debating within our group how the automount maps should be >setup for home and applications. Currently /home and /apps are indirect >automount points, but each user will mount the whole directory. >For example the auto.master will look like this: >/stage auto.indirect >and auto.indirect will look like this: >home server1:/home >apps server1:/apps
Doesn't having this setup assume that all of your home directories are on one machine? What if you expand or decide to add a second machine? The second solution allows you to do this much easier.
>The arguments for this are it is simple and has always worked. >Some of us (myself included) are saying each application and home directory >should be a separate automount point. For example the auto.master should be: >/home auto.home >/apps auto.apps >The auto.home would look like: >joe server1:/home/joe >sue server1:/home/sue
Again, I have always set my environments up this way because there have always been more than one machine that people are getting their home directories and even applications from.
> >Those in favor of this way are saying it would decrease network traffic because >you would not mount a whole directory and it would give us more flexibility >in configuration of users home. Can anyone add to this arguments and tell >us what way they think would be better. > >Regards, >Phil
Shane
>From hoffp Mon Nov 7 16:06:53 1994 Date: Mon, 7 Nov 1994 16:06:53 -0500 From: hoffp (Phil Hoff) To: hoffp Subject: org post Content-Length: 3783 X-Lines: 104 Status: RO
>From comp.sys.sun.admin Fri Nov 4 14:16:23 1994 Path: panix!not-for-mail From: phoff@panix.com (Phil Hoff) Newsgroups: comp.sys.sun.admin Subject: NIS Automount Debate Date: 3 Nov 1994 16:58:18 -0500 Organization: PANIX Public Access Internet and Unix, NYC Lines: 24 Message-ID: <39bmdq$6i4@panix2.panix.com> NNTP-Posting-Host: panix2.panix.com Summary: NIS Keywords: NIS
We are debating within our group how the automount maps should be setup for home and applications. Currently /home and /apps are indirect automount points, but each user will mount the whole directory. For example the auto.master will look like this: /stage auto.indirect and auto.indirect will look like this: home server1:/home apps server1:/apps The arguments for this are it is simple and has always worked. Some of us (myself included) are saying each application and home directory should be a separate automount point. For example the auto.master should be: /home auto.home /apps auto.apps The auto.home would look like: joe server1:/home/joe sue server1:/home/sue Those in favor of this way are saying it would decrease network traffic because you would not mount a whole directory and it would give us more flexibility in configuration of users home. Can anyone add to this arguments and tell us what way they think would be better. Regards, Phil
>From comp.sys.sun.admin Fri Nov 4 14:17:54 1994 Path: panix!news.mathworks.com!hookup!relay.tor.hookup.net!nnrp.tor.hookup.net!peters From: peters@swisrv1.swi.com (Mark Peters) Newsgroups: comp.sys.sun.admin Subject: Re: NIS Automount Debate Date: 04 Nov 1994 17:27:57 GMT Organization: HookUp Communication Corporation, Oakville, Ontario, CANADA Lines: 52 Message-ID: <PETERS.94Nov4122757@swisrv1.swi.com> References: <39bmdq$6i4@panix2.panix.com> NNTP-Posting-Host: swi.tor.hookup.net In-reply-to: phoff@panix.com's message of 3 Nov 1994 16:58:18 -0500
In article <39bmdq$6i4@panix2.panix.com> phoff@panix.com (Phil Hoff) writes:
> We are debating within our group how the automount maps should be > setup for home and applications. Currently /home and /apps are indirect > automount points, but each user will mount the whole directory. < stuff deleted > > Some of us (myself included) are saying each application and home directory > should be a separate automount point. For example the auto.master should be: > /home auto.home > /apps auto.apps > The auto.home would look like: > joe server1:/home/joe > sue server1:/home/sue > > Those in favor of this way are saying it would decrease network traffic because > you would not mount a whole directory and it would give us more flexibility > in configuration of users home. Can anyone add to this arguments and tell > us what way they think would be better.
You are right about the reduced traffic and flexibility. We use an auto.home map that looks like this:
andrew server1:/data/& mary server1:/data/&
* server1:/users/&
Note the wildcards. This says that /home/andrew will actually reside under server1:/data/andrew. Likewise for mary. All other users have their home directories under server1:/users/<username>.
The main disadvantage? If you:
cd /home ls
you will not see everyones directory. (That doesn't mean that they are not there. You simply need to reference it by name -- not such a bad "security" feature actually.) Also, you need to fake 'pwd' so that it displays /home/<username>.
A really good discussion of this can be found in the article
The Art of Automounting (TheArtofAutomounting) by Martien van Steenbergen of Sun Microsystems Nederland B.V., found at an Internet site near you.
-- Mark Peters (peters@swi.com) SWI Systemware Inc. Toronto, CANADA
>From tylock@Kodak.COM Tue Nov 8 14:48:31 1994 Reply-To: tylock@Kodak.COM Date: Tue, 8 Nov 94 12:52:31 EST From: tylock@Kodak.COM (Steven Tylock (726-5625)) To: phoff@panix.com Subject: Re: NIS Automount Debate Newsgroups: comp.sys.sun.admin Organization: Eastman Kodak Content-Length: 5502 Status: RO X-Lines: 119
Phil,
It depends on what you want your df to look like;-) I personally prefer the approach that shows up like this:
maple:df Filesystem kbytes used avail capacity Mounted on /dev/sd0a 7735 3327 3635 48% / /dev/sd0g 106639 67529 28447 70% /usr /dev/sd0d 14527 196 12879 1% /tmp /dev/sd0e 7255 182 6348 3% /var /dev/sd0f 14527 10 13065 0% /var/tmp alphred:/usr/local 1150285 1024552 10704 99% /usr/local monolith:/usr/licensed 1835996 1579942 72454 96% /tmp_mnt/auto/licensed4 monolith:/u/users1 1835996 1585362 67034 96% /tmp_mnt/auto/users1 monolith:/u/users2 1835996 1585362 67034 96% /tmp_mnt/auto/users2 monolith:/usr/spool/mail 95935 32601 53740 38% /tmp_mnt/auto/mail
This is with an auto.map that looks like: users1 monolith:/u/users1 users2 monolith:/u/users2
(Your current setup)
This is a real-life example of a larger machine with your proposed setup where each entry is specific to a user's home:
magpie:df Filesystem kbytes used avail capacity Mounted on /dev/xy0a 14082 10270 2404 81% / /dev/xy0d 341847 170111 137552 55% /usr /dev/xy0f 49329 4736 39661 11% /var /dev/xy0e 316162 263670 20876 93% /export /dev/xy1c 818627 546431 190334 74% /export/home /dev/xy2c 818627 580178 156587 79% /export/local redwing:/export/home4/seibert 559818 304546 199290 60% /tmp_mnt/home/seibert redwing:/export/home4/dcox 559818 304546 199290 60% /tmp_mnt/home/dcox redwing:/export/home4/roman 559818 304546 199290 60% /tmp_mnt/home/roman redwing:/export/home/denber 818627 651044 85720 88% /tmp_mnt/home/denber redwing:/export/home/liberty 818627 651044 85720 88% /tmp_mnt/home/liberty redwing:/export/home2/mitch 559818 389729 114107 77% /tmp_mnt/home/mitch redwing:/export/home3/rhoda 917870 113507 712576 14% /tmp_mnt/home/rhoda redwing:/export/home/cortese 818627 651044 85720 88% /tmp_mnt/home/cortese redwing:/export/home/wright 818627 651044 85720 88% /tmp_mnt/home/wright redwing:/export/home/shossain 818627 651044 85720 88% /tmp_mnt/home/shossain redwing:/export/home1/neumann 916334 511838 312862 62% /tmp_mnt/home/neumann redwing:/export/home1/manners 916334 511838 312862 62% /tmp_mnt/home/manners redwing:/export/home/ciejek 818627 651044 85720 88% /tmp_mnt/home/ciejek redwing:/export/home2/tbrown 559818 389729 114107 77% /tmp_mnt/home/tbrown redwing:/export/home4/abbott 559818 304546 199290 60% /tmp_mnt/home/abbott redwing:/export/home4/peggy 559818 304546 199290 60% /tmp_mnt/home/peggy redwing:/export/home/deturck 818627 651044 85720 88% /tmp_mnt/home/deturck redwing:/export/home/fgarcia 818627 651044 85720 88% /tmp_mnt/home/fgarcia redwing:/export/home2/howland 559818 389729 114107 77% /tmp_mnt/home/howland redwing:/export/home2/tylock 559818 389729 114107 77% /tmp_mnt/home/tylock redwing:/export/home/brigham 818627 651044 85720 88% /tmp_mnt/home/brigham
So, 21 people logged in, 21 mounts, and they only come from 5 different places. So, yes, you have "smaller" mounts, but you mount the "same" disk 4-5 times!-) (so, what is worse overhead, mounting once, or 5 times?) You also say: >it would decrease network traffic because you would not mount a whole dir >and it would give us more flexibility in configuration of users home.
On what basis is the net traffic decreased? One call to store the contents of the top level dir once every 5 minutes? How about the greater net traffic to send the auto.home map across the network every few minutes?-)
The second part I agree with: It is easier to change someone's home. I avoid that, and have done so infrequently, so it is not an overriding concern.
Other arguments:
Smart users can't tell who they share disks with. If all you have to do is cd; cd ..; ls; to see who is on your partition, you can find your neighbors. My users are generally unix types and they like seeing who is on their section of disk.
The complexity of any system is the same, the only difference is where it is. We use user homes of: /u/users1/username and fix it in the passwd file. /u/users1 is a link to /auto/users1.
Equivalent systems have /home/username and fix username -> /u/users1/username in the auto.home file.
Others systems have /home/username, and make /home/username a symbolic link to the real home.
Each has advantages, but the indirection to homes add complexity in my view.
I like "Keep It Simple, Stupid" - if there is no big reason to add the complexity, don't bother.
steve Of course these views are just mine, heck even withing Kodak we have systems set up one way or the other.
>From comp.sys.sun.admin Mon Nov 7 16:41:30 1994 Path: panix!news.mathworks.com!hookup!olivea!koriel!news2me.EBay.Sun.COM!engnews2.Eng.Sun.COM!usenet From: Brent <brent@eng.sun.com> Newsgroups: comp.sys.sun.admin Subject: Re: NIS Automount Debate Date: 7 Nov 1994 18:45:59 GMT Organization: Sun Microsystems Inc., Mountain View, CA Lines: 37 Message-ID: <39lsl7$s6b@engnews2.Eng.Sun.COM> References: <39bmdq$6i4@panix2.panix.com> NNTP-Posting-Host: terra.eng.sun.com
> We are debating within our group how the automount maps should be > setup for home and applications. Currently /home and /apps are indirect > automount points, but each user will mount the whole directory. > For example the auto.master will look like this: > /stage auto.indirect > and auto.indirect will look like this: > home server1:/home > apps server1:/apps > The arguments for this are it is simple and has always worked. > Some of us (myself included) are saying each application and home directory > should be a separate automount point. For example the auto.master should be: > /home auto.home > /apps auto.apps > The auto.home would look like: > joe server1:/home/joe > sue server1:/home/sue > > Those in favor of this way are saying it would decrease network traffic because > you would not mount a whole directory and it would give us more flexibility > in configuration of users home. Can anyone add to this arguments and tell > us what way they think would be better.
Well, I wouldn't go as far to say that each application should have its own mountpoint, though I think most sites set up a separate mount for each user's home directory. Your scheme will work OK but it won't scale. You'll be in trouble if you have to split your home directories across multiple servers.
Set up a separate entry in auto.home for each user so that each user's home directory mounts separately.
For your apps you may want to handle it a bit differently. Leave your apps directory as it is now, though at some time in the future you may choose to replicate the apps directory on several servers and have the automounter choose the most appropriate server for each client.
>From comp.sys.sun.admin Tue Nov 8 18:31:16 1994 Path: panix!news.mathworks.com!yeshua.marcam.com!usc!howland.reston.ans.net!EU.net!uunet!tinman2!tinman2!usenet From: pluta@eda.mke.ab.com (Rick Pluta) Newsgroups: comp.sys.sun.admin Subject: Re: NIS Automount Debate Date: 8 Nov 1994 14:52:56 GMT Organization: Allen-Bradley Co., Milwaukee, WI Lines: 38 Message-ID: <39o3c8INN9jv@scarecrow.mke.ab.com> References: <39m92t$f66@ns1.arlut.utexas.edu> Reply-To: pluta@eda.mke.ab.com NNTP-Posting-Host: cgc2.mke.ab.com
In article f66@ns1.arlut.utexas.edu, smcdow@arlut.utexas.edu (Stuart McDow) writes:
---Lines deleted
> >Mounting the entire filesystem shouldn't produce any more traffic than >mounting a single subdir. OTOH, going out and doing a separate NFS >mount for several subdirs will increase network traffic because (in >part) each NFS mount has to be kept alive. If you have many separate >NFS mounts (even from the same filesystem), the traffic will bog you >down. >
---Lines deleted
About 1-1/2 years ago, we had a debate here as to whether NFS mounted filesystems generated network traffic when not being accessed. At that time I decided to check via etherfind and found there was none.
I saw network activity when the filesystem was mounted and accessed. However, when the filesystem was inactive (I checked for a period of two hours), I saw no network activity.
I decided to run that test again today (11-8-94) for a period of 1/2 hour, and found the same to be true.
Granted, I ran this test on a manually mounted filesystem so I did not see the network activity which would be generated when an automounted filesystem times out and is unmounted. However, I believe an NFS mount on its own is not "kept alive" by sending packets between the server and client.
Rick Pluta Systems Analyst, CAE/CAD Services Voice: (414)382-3799 Allen-Bradley Co. Fax: (414)382-4444 Milwaukee, Wi. USA Email: pluta@eda.mke.ab.com
>From comp.sys.sun.admin Tue Nov 8 18:31:26 1994 Path: panix!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uunet!news.eden.com!arlut.utexas.edu!mamba!smcdow From: smcdow@arlut.utexas.edu (Stuart McDow) Newsgroups: comp.sys.sun.admin Subject: Re: NIS Automount Debate Date: 7 Nov 1994 22:18:05 GMT Organization: The Church of The Type 259 Flat-Twin Engine Lines: 35 Message-ID: <39m92t$f66@ns1.arlut.utexas.edu> References: <PETERS.94Nov4122757@swisrv1.swi.com> NNTP-Posting-Host: mamba.arlut.utexas.edu Originator: smcdow@mamba
peters@swisrv1.swi.com (Mark Peters) writes: > You are right about the reduced traffic and flexibility.
I do agree about flexibility. I'm not so sure about the reduced traffic part.
Mounting the entire filesystem shouldn't produce any more traffic than mounting a single subdir. OTOH, going out and doing a separate NFS mount for several subdirs will increase network traffic because (in part) each NFS mount has to be kept alive. If you have many separate NFS mounts (even from the same filesystem), the traffic will bog you down.
> We use an auto.home map that looks like this: > > andrew server1:/data/& > mary server1:/data/& > > * server1:/users/& > >
Better yet, you could use this construct to reduce the number of mounts: * server1:/users:&
Note the ':' where the '/' was.
This will prevent the client from going out and re-mounting a volume that has already been mounted. It simply (depending on the OS) will do a lofs mount (preferred) for a new directory or create a symbolic link. In either case, the total number of NFS mounts is one.
-- Stuart McDow Applied Research Laboratories smcdow@arlut.utexas.edu The University of Texas at Austin
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:15 CDT