There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
Thank you.
P.S. I know about rsh/ssh :)
-----Original Message----- From: Jeffrey Krueger To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters@mathworks.com Sent: 1/12/01 2:30 PM Subject: Re: /home layout with many filers and NIS automount
On Fri, Jan 12, 2001 at 10:47:54AM -0600, Rainchik, Aleksandr (MED, Non GE) wrote:
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.
Point of clarification: 5-10 filers for 1,000 users? What model filers are they and I hope they are serving other data besides homedirs! At one point we had about 15,000 home directories mostly on two NetApps - a F330 and a F540 - and they were pretty bored filers.
One way to simplify your design would be to reduce the number of filers serving homedirs, especially for 1,000 users. Two good reasons to spread out homedirs are for bandwidth constraints and to spread risk/reduce points of failure. But if you have consistently high bandwidth between all users and filers than 2-4 homedir servers should be more than plenty mitigation of risk considering the cost of additional filers versus the additional benefit (considering NetApps impressive reliability).
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
This is a very restrictive design because it makes homedir moves extremely conspicuous. It also flies a bit in the face of a large selling point of the automounter - eliminating host-based network paths. If a user is moved from one filer to another, or even from one volume to another, they will have a whole new path to their home directory. Worse yet, any scripts or application configurations which use the full path to their home directory will need to be re-coded or re-configured - YUK!
Being able to "hide" the location of a home directory (or any other remote filesystem) is extremely useful.
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/&
This is the way we do it, and the way I'd venture to guess most/many places do it. From the user perspective, it is very simple. From the admin perspective, it is easy to manage. We've found it to give maximum flexibility with minimum hassle.
Do you know if there is more elegant solution for this problem? Can
you
tell me, what is your preference for /home layout?
What do you mean by elegant? The above is pretty darned elegant, and for 1,000 users it should be easily manageable too. We currently have 10,223 home directories and we've got one big home directory map like above. It works great!
One recommendation is you may want to use a script or database to help generate that automount map. The easiest way would be to write a shell/perl script that scanned all your "homedir" directories on each filer, ensured username uniqueness and then build the automount map. For added flexibility, we use a small database. Each row in the homedir table has the username (mountpoint under /home), the filer, and the path to their homedir. At some interval a script comes thru and builds the map.
Hope this info helps!
-- Jeff
-- ------------------------------------------------------------------------ ---- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com
On Sat, 13 Jan 2001, Rainchik, Aleksandr (MED, Non GE) wrote:
There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
Yes, updated maps are pushed from your master NIS server to any slaves. You just edit the master copy and 'make' the map. (And btw, automount doesn't use the passwd map)
-tom
Thank you.
P.S. I know about rsh/ssh :)
-----Original Message----- From: Jeffrey Krueger To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters@mathworks.com Sent: 1/12/01 2:30 PM Subject: Re: /home layout with many filers and NIS automount
On Fri, Jan 12, 2001 at 10:47:54AM -0600, Rainchik, Aleksandr (MED, Non GE) wrote:
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.
Point of clarification: 5-10 filers for 1,000 users? What model filers are they and I hope they are serving other data besides homedirs! At one point we had about 15,000 home directories mostly on two NetApps - a F330 and a F540 - and they were pretty bored filers.
One way to simplify your design would be to reduce the number of filers serving homedirs, especially for 1,000 users. Two good reasons to spread out homedirs are for bandwidth constraints and to spread risk/reduce points of failure. But if you have consistently high bandwidth between all users and filers than 2-4 homedir servers should be more than plenty mitigation of risk considering the cost of additional filers versus the additional benefit (considering NetApps impressive reliability).
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
This is a very restrictive design because it makes homedir moves extremely conspicuous. It also flies a bit in the face of a large selling point of the automounter - eliminating host-based network paths. If a user is moved from one filer to another, or even from one volume to another, they will have a whole new path to their home directory. Worse yet, any scripts or application configurations which use the full path to their home directory will need to be re-coded or re-configured - YUK!
Being able to "hide" the location of a home directory (or any other remote filesystem) is extremely useful.
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/&
This is the way we do it, and the way I'd venture to guess most/many places do it. From the user perspective, it is very simple. From the admin perspective, it is easy to manage. We've found it to give maximum flexibility with minimum hassle.
Do you know if there is more elegant solution for this problem? Can
you
tell me, what is your preference for /home layout?
What do you mean by elegant? The above is pretty darned elegant, and for 1,000 users it should be easily manageable too. We currently have 10,223 home directories and we've got one big home directory map like above. It works great!
One recommendation is you may want to use a script or database to help generate that automount map. The easiest way would be to write a shell/perl script that scanned all your "homedir" directories on each filer, ensured username uniqueness and then build the automount map. For added flexibility, we use a small database. Each row in the homedir table has the username (mountpoint under /home), the filer, and the path to their homedir. At some interval a script comes thru and builds the map.
Hope this info helps!
-- Jeff
--
Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com
On Sat, Jan 13, 2001 at 03:16:20PM -0600, Rainchik, Aleksandr (MED, Non GE) wrote:
There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =)
-- Jeff
On Mon, 15 Jan 2001 10:37:38 PST, Jeffrey Krueger wrote:
There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =)
Er? Solaris? That's one of the (few) beauties of NIS -- you don't have to go around telling everything that a map has changed.
I've never gone machine-to-machine running automount(1) to kick it in the pants just because we changed the password or auto_home map. The _worst_ is that ncsd caches something and we need to kill and restart it.
Rob++ ---------------------------------------- Rob Windsor E-Mail - mailto:rob_windsor@adc.com Senior Unix Systems Administrator Voice - phone:972-680-6919 Computer Services Fax - phone:972-680-0370 Broadband Access and Transport Group __o ADC Telecommunications _`<,_ Richardson, TX 75082 (_)/ (_)
On Mon, Jan 15, 2001 at 02:45:11PM -0600, Rob Windsor wrote:
On Mon, 15 Jan 2001 10:37:38 PST, Jeffrey Krueger wrote:
There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =)
Er? Solaris? That's one of the (few) beauties of NIS -- you don't have to go around telling everything that a map has changed.
As noted later in this thread, I stand corrected. What I left out is the fact that only indirect mount maps require kicking the automounter. Direct mount maps aren't affected.
-- Jeff
On Tue, 16 Jan 2001 18:16:10 PST, Jeffrey Krueger wrote:
There is another thing against
#auto_home NIS map user1 filer2:/vol/vol1/&
design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again?
This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =)
Er? Solaris? That's one of the (few) beauties of NIS -- you don't have to go around telling everything that a map has changed.
As noted later in this thread, I stand corrected. What I left out is the fact that only indirect mount maps require kicking the automounter. Direct mount maps aren't affected.
Uh, I hate to beat the subject to death, but you have that backwards.
Only direct mount maps require automount(1)-type frobbing to wake up.
Indirect maps update automagically since automountd already has complete control of the mountpoint.
Rob++ ---------------------------------------- Rob Windsor E-Mail - mailto:rob_windsor@adc.com Senior Unix Systems Administrator Voice - phone:972-680-6919 Computer Services Fax - phone:972-680-0370 Broadband Access and Transport Group __o ADC Telecommunications _`<,_ Richardson, TX 75082 (_)/ (_)
-
Jeffrey Krueger -
Rainchik, Aleksandr (MED, Non GE) -
Rob Windsor -
Tom.Lislegaard＠proact.no