gabriel rosenkoetter on Thu, 20 Feb 2003 10:29:04 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] OT: Defualt Sun partitions


On Thu, Feb 20, 2003 at 09:34:40AM -0500, Edward M. Corrado wrote:
> Sorry I didn't respond to this sonner, but I've had the flu and haven't
> been checking my e-mail.
 
No sweat. You quoted enough (and cited appropriately! :^>) that the 
thread's still clear.
 
> # useradd -D
> group=other,1  project=,3  basedir=/home
> skel=/etc/skel  shell=/bin/sh  inactive=0
> expire=  auths=  profiles=  roles=
> #
>
> So it is trying for /home, but I by default I don't have anything but
> (what looks like an apparent) [auto]mount point?
 
Right. And if you give useradd the -m flag, it *will* fail. Because,
Sun's idea is, in the general case, you don't don't want to be
creating local home directories.
 
Bear in mind that what makes Sun money isn't home users, it's
corporate network environments, with a single NFS server for all
home directories (which probably has that file system on a RAID
array of some sort, quite plausibly in a SAN shared by another Sun
box or NAS doing the sharing itself).
 
The general case for the majority of Solaris users (and it really is
the general case, I'd say; look at their market numbers) is that at
the time of a useradd, the home directory already exists, so you
typically don't want the -m (which is why it's not the default to
include it), and you typically want the home directory to be the
auto_home dir (which defaults to /home), because you'll typically
have /etc/auto_home configured with a line like:

*	nfshost:/export/home/&

(Which maps all users to the directory of their name inside
/export/home on the host nfshost.)

This means that even workstations in environments with nothing but
Sun systems can all use the same home directories. You can't imagine
how much easier that makes setting up users with a Unix workstation.
(Well, actually, you probably can. :^>)

> /etc/auto_home is basically empty.
> 
> # more /etc/auto_home
> # Home directory map for automounter
> #
> +auto_home
> # 
> 
> automountd is running by default - it is just not configured to automount
> anything :-)

That +auto_home is enough to make automountd start without
complaints, but it won't do anything.

Try this:

mkdir -p /export/home/foo
echo "* localhost:/export/home/&" >> /etc/auto_home
/etc/init.d/autofs stop && /etc/init.d/autofs start
cd /home
ls
cd foo
ls /home

Neat, huh?

(Make sure your NFS server's running for the above, or it won't
work... but I'm pretty sure automountd wouldn't have started if you
weren't running the appropriate RPC services.)

If that path goes unused for long enough, the mount will go away.
Note that the user MAY NOT HAVE LOGGED OUT at that point. That
doesn't matter, though, because it will be instantly remounted as
soon as any CWD on the system becomes /home/foo.

> I take my bad Sun comment back. Good Sun.

Well, contextually good Sun. They *are* still forcing you to do it
their way, but at least their way does, in fact, work, and does make
things simple for admins on the majority of the systems they sell.

> I don't care what they intend, I need users to have a home directory - 
> and luckily with *NIX I can do what they don't intend :-). Actually, I
> probably will keep it like this for a while just to see how it works. I
> just will need to look into this auto_home thing a little more. Maybe I'll
> use it and make the home directory NFS from a different Solaris box -
> which from what I think you are saying is the intended way? 

Precisely. I'd recommend you give it a try. Having a single home
directory across a bunch of systems that are in a logical group is
*really* useful (what you want is always local, logically speaking;
you never have to ftp or scp it), but only do it if you can trust
the network involved (NFS traffic riding in the clear... unless
you're using TCP NFS and running it through an SSH pipe or similar;
only do that if you've got the bandwidth and processor overhead
for it but don't trust the network).

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpBJyYhKNKMj.pgp
Description: PGP signature