Very Computer

Hello,

I just need a word of advice on how to structure /home if you
use automount, have 5-10 home directory servers (NetApp filers)
and around 1000 users.

I'm personally is looking for /home/homeserver-vol#/user-name
scheme, so my automount maps will be nice, small and manageble:

#auto_home NIS map
filer1-0   filer1:/vol/vol0
filer1-1   filer1:/vol/vol1
...
filer5-5   filer5:/vol/vol5

But it seems like users prefer /home/username scheme and it leads
to 1000+ NIS automount map for /home, like

#auto_home NIS map
user1      filer2:/vol/vol1/&
....
user9999   filer3:/vol/vol4/&

Do you know if there is more elegant solution for this problem?

Thank you.

-- Aleksandr Rainchik, SUN CSA

Sent via Deja.com
http://www.deja.com/

Stick with the

user  server:/directory

It will save you some headaches down the road if users have a need to
expand past the "normal" home with an extended home directory:

user / server2:/directory \
     /location server2:/directory

which I don't think is an option if you chose the other way...

[FWIW, 1000 entries isn't too many for auto_home.  At Sun, we are
working on smashing together our three biggest NIS domains into one,
which will mean about 20,000 individual entries coming from around 30 or
so servers in auto_home. =) ]

But as far as I know, when you change automount map (which
should be changed _every_ time you add/delete/modify user
if you go with user server:/dir layout) you have to go to
each NIS client machine and fire up "automount" to let
automountd know about change in maps. Sounds like headache...

Am I wrong?

Thank you.

-- Aleksandr Rainchik, Sun CSA

Sent via Deja.com
http://www.deja.com/

Yes and no.  IME if the filesystem hasn't been actively used
for some (undefined) period of time, then automountd will
see the changes and implement them.

The automounter on Solaris 2.6 has been a real headache for me,
as it is sometimes necessary to *reboot* the machine to get it
to act on changes.  That, obviously, is not even remotely acceptable
in a production environment.

I hear that it's better in more recent versions, but it looks
like we'd be more likely to migrate to Win2k on desktops than
upgrade to Solaris 8.

--
                      "I'm not sure if this is a good or a bad thing.
                  Probably a bad thing;  most things are bad things."
                                                 -- Nile Evil Bastard

You're only partly wrong.  You have to run "automount" on each client
*only* if you change a direct map.  If you change an indirect map (like
auto_home normally is), you don't have to do anything.  I'm not 100%
sure, but I believe this is because indirect map entries are the
contents of directories on autofs filesystems, which direct map entries
are the contents of other (regular) filesystems.

  - Logan

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

Also, mounted filesystems will not be changed until they
have been unmounted; direct maps are "sort-of" mounted immediately.
(I.e., the mount points are created and the mount is still done on demand
[in newer releases], but no map lookups take place)

Hierarchical mounts are also not reevaluated unless unmounted
completely (mounts of the form:  user server:/fs /usrdir2 server:/fs2
which mounts /home/user and /home/user/usrdir2)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Quote:> The automounter on Solaris 2.6 has been a real headache for me,
> as it is sometimes necessary to *reboot* the machine to get it
> to act on changes.  That, obviously, is not even remotely acceptable
> in a production environment.

automount -v didn't work?

Nope.  Neither does doing a stop/start of the automounter.

The problem is that the systems concerned are quite busy, and
so are many of the filesystems where we have this problem.  And
it seems as though in 2.6 at least the automounter has trouble
handling changes to busy trees.

("Quite busy" means ~60 active users, most of them using the
 automounter trees in question.  Minor stuff compared to student
 machines in academentia, but quite a lot compared, say, to a
 database server.)

--
           "Now, what was I doing before I so rudely interrupted myself?"

Quote:>Hierarchical mounts are also not reevaluated unless unmounted
>completely (mounts of the form:  user server:/fs /usrdir2 server:/fs2
>which mounts /home/user and /home/user/usrdir2)

Ah.  This would explain the problem I mentioned.  We have quite a few
of these, and it's sometimes impossible to unmount without rebooting
the machine (or chasing down every single process using it, but as
these are machines with ~60 active users...).

Which suggests that the automounter is *not* the best way to
manage this sort of hierarchy.  Not that knowing this is much
help at the moment, as we're more or less stuck with it.

--
               "Bastard's the name, but you can call me Right Bleedin'"

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

If those hierarchies change a lot, you are better of rearranging the
maps by loopback mounting other automount points rather than using
the hierachy as one map.

(Which basically is a on-demand mounted "direct" map)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

"fuser -c /mount/point" or "kill -WHATEVER `fuser -c /mount/point`".

Personally, I've never used hierarchical automount points.  It just
seemed prone to failure to me.  If I were given that task, I would
simulate the hierarchy with symbolic links in a directory; those
symbolic links would map to an indirect automount points that would go
to the read places.  I'd then copy that whole mess of directories of
symbolic links to multiple servers, and mount them with the
automounter's read-only failover.  Presto[1], no hierarchical mounts
necessary and yet you still get most of the same effect, although you
do have to life with symbolic links.

  - Logan

[1]  Sorry, NFS-related pun not intended.

Often doesn't work, in my experience.  Fuser tells me there are no
processes with locks and yet umount says the mount point is busy.

--
Real courtesy requires human effort and understanding.  
Never let your machine or your habit send courtesy copies.

One interesting/elegant idea from Toasters mailing list: to have one
fake home directory somewhere on file server, like filesrv1:/fake_home,
with links to real home directories in form of

user1 -> /net/filerserv9/vol/vol2/home/user1
...
user9999 -> /net/fileserv2/vol/vol0/user9999

and use very simple

#auto_home map
*       fileserv1:/fake_home/&

What do you (gurus) think about this layout? It will allow me
to have /home/user1 directories, auto_home map as big as one
line and no need to fire up "automount"!

Do you think it's going to affect performance?

-- Aleksandr Rainchik, Sun CSA

Sent via Deja.com
http://www.deja.com/

Been there, done that.

It quickly becomes an administrative nightmare--especially if you have
SAs that are used to doing it the "proper" way.   You'll need to create
some scripts that make sure the links stay intact and correct as well as
building scripts to add/delete users properly.  It also precludes users
being able to do their own restores with Legato (and probably other
backup programs as well), if you allowed such things in the past.  
[/home/blah is not a known filesystem anymore]

I'm still unclear as to why you don't run this the way it was intended.
Is it just to avoid some pain when a user moves from one server/file
path to another?

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

You don't need to fire up automount for /home entries.

You will probably have some problems with multiple filesystems
exported from your server, unless you map them through /net
(which also gives problems when adding filesystems after the
host has been mounted)

And you have to maintain the symlinks rather than the automount
map, not much of a difference and also not as visible.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.