*** Bug 1707 has been marked as a duplicate of this bug. ***

(In reply to comment #0)
> In the current developer preview, the installer creates a home directory under
> /export/home/<username>.  Instead, there should be a auto_mounter map set up
> under /etc/auto_home of the form
> 
> jack        localhost:/export/home/&

It may be better to provide a catch-all in this case, e.g.
-- snip --
* localhost:/export/home/&
-- snip --
... that all local users are mapped to /export/home/ ...
... or modify "useradd" to add entries to 7etc/auto_home ... or make auto_home
a shell script which looks-up the user's home dir location dynamically...

*** Bug 3231 has been marked as a duplicate of this bug. ***

I think it would be good to fix this earlier rather than later so I'm marking
it as a potential stopper.

Have talked to submitter and agreed on targeting bug fix for 2009.04 release.

(In reply to comment #5)
> Have talked to submitter and agreed on targeting bug fix for 2009.04 release.

Sadly, I filed a similar bug against one of the SXDE releases... it wasn't
addressed there either...

*** Bug 4846 has been marked as a duplicate of this bug. ***

Sanjay:
Please see comment #2 for a proposed fix.

(In reply to comment #8)
> Sanjay:
> Please see comment #2 for a proposed fix.

It shouldn't be to hard to add this entry in auto_home as an ICT.

This bug is an important one to be fixed.  However I believe fixing it
in the installer tools is fundamentally in the wrong place.

Given this is updating auto_home with the generic 
"* localhost:/export/home/&" form then that should be placed in the master 
auto_home file in the ON consolidation.   

If instead it was adding a specific entry just for the user(s) that are created
by the installer then I'd say updating auto_home does belong in the installer.

While the effect is basically the same I strongly believe that modifying 
auto_home with a generic entry in the installer is the wrong thing to do.

Also this type of change to auto_home really should have a PSARC 
fast-track filed for it - which I'd be more than happy to sponsor for you.

The fix for this has been reviewed and will be pushed as soon as the move to
Python 2.6 is complete.

(In reply to comment #10)
> This bug is an important one to be fixed.  However I believe fixing it
> in the installer tools is fundamentally in the wrong place.
> 
> Given this is updating auto_home with the generic 
> "* localhost:/export/home/&" form then that should be placed in the master 
> auto_home file in the ON consolidation.   

This could at some later time be added to the auto_home file in ON but that is
something that will need to be addressed at a later time. Doing that type of
thing is outside the scope of this bug fix.

> 
> If instead it was adding a specific entry just for the user(s) that are created
> by the installer then I'd say updating auto_home does belong in the installer.

This was the original approach but it was decided that it would be better to
add the more generic entry. 

> 
> While the effect is basically the same I strongly believe that modifying 
> auto_home with a generic entry in the installer is the wrong thing to do.

Because this is being placed art the end of the file and after the +auto_home
entry only those users not found in other maps will hit this. Also it's easy
enough to only add the entry for the user being added and not the more generic
line.

> 
> Also this type of change to auto_home really should have a PSARC 
> fast-track filed for it - which I'd be more than happy to sponsor for you.

If what we are doing here is the wrong thing to do then what is the point of
filing a fast-track to provide this generic entry? It seems that if we should
only be adding the single entry here for the user created during install then
the fast-track shouldn't be needed.

I don't believe the entry in any case should be added to the end, unless I'm
misremembering how the automounter parses the maps.  The added entry should
take precedence over the auto_home map (if I plug my laptop into the SWAN and
have set up NIS, I would expect my local home directory to be used and not
automounted from the SWAN server.)

David is correct if the intent is that the users local home directory is always
used in preference to anything picked up from the network then the entry must
go before and not after the +auto_home line.

(In reply to comment #13)
> I don't believe the entry in any case should be added to the end, unless I'm
> misremembering how the automounter parses the maps.  The added entry should
> take precedence over the auto_home map (if I plug my laptop into the SWAN and
> have set up NIS, I would expect my local home directory to be used and not
> automounted from the SWAN server.)

You correct on how the automounter will parse the map. it will use the entry it
finds first for that user. If you have entries multiply defined for your user
in both a map on the network and one local on the system it will make use of
the first one it sees. If you are expecting the local entry all the time
instead of the entry in the map on the network then it would have to come
first. The reasoning behind placing the entry at the end was so we did not
override anything that might be configured in a network map. However I can see
your point that you would want the local home directory to be what it auto
mounted in the case where it user is multiply defined in this way.

(In reply to comment #14)
> David is correct if the intent is that the users local home directory is always
> used in preference to anything picked up from the network then the entry must
> go before and not after the +auto_home line.

This was not the original intent. The intent was that we would add this
entry at the end so that anything configured in a map on the network
would take precedence over the local entry.

(In reply to comment #15)
> (In reply to comment #13)
> > I don't believe the entry in any case should be added to the end, unless I'm
> > misremembering how the automounter parses the maps.  The added entry should
> > take precedence over the auto_home map (if I plug my laptop into the SWAN and
> > have set up NIS, I would expect my local home directory to be used and not
> > automounted from the SWAN server.)
> 
> You correct on how the automounter will parse the map. it will use the entry it
> finds first for that user. If you have entries multiply defined for your user
> in both a map on the network and one local on the system it will make use of
> the first one it sees. If you are expecting the local entry all the time
> instead of the entry in the map on the network then it would have to come
> first. The reasoning behind placing the entry at the end was so we did not
> override anything that might be configured in a network map. However I can see
> your point that you would want the local home directory to be what it auto
> mounted in the case where it user is multiply defined in this way.

Thinking about this a bit more I believe that placing this at the end is the
correct thing to so that we do not interfere with any entry that may be
configured in a map on the network. If something else is wanted then that
should be left as an exercise for to the user (this is the admin user in this
case) to change that configuration.

(In reply to comment #17)
...
> Thinking about this a bit more I believe that placing this at the end is the
> correct thing to so that we do not interfere with any entry that may be
> configured in a map on the network. If something else is wanted then that
> should be left as an exercise for to the user (this is the admin user in this
> case) to change that configuration.

I disagree.  These entries are primarily directed at standalone environments,
where least surprise leads me to believe the user will expect to always arrive
at the same home directory, no matter where the system happens to be located. 
Other behaviors are, by comparison, advanced, and open up issues such as having
synchronized uid and gid spaces, as well as Gnome's well-known issues with
having multiple simultaneous sessions open against the same home directory. 
Please place it first.

(In reply to comment #18)
> (In reply to comment #17)
> ...
> > Thinking about this a bit more I believe that placing this at the end is the
> > correct thing to so that we do not interfere with any entry that may be
> > configured in a map on the network. If something else is wanted then that
> > should be left as an exercise for to the user (this is the admin user in this
> > case) to change that configuration.
> 
> I disagree.  These entries are primarily directed at standalone environments,
> where least surprise leads me to believe the user will expect to always arrive
> at the same home directory, no matter where the system happens to be located. 
> Other behaviors are, by comparison, advanced, and open up issues such as having
> synchronized uid and gid spaces, as well as Gnome's well-known issues with
> having multiple simultaneous sessions open against the same home directory. 
> Please place it first.

Valid points. I've changed this to place the new line before the +auto_home
line.

Fixed in changeset:

changeset:   669:2a993be66d02
tag:         tip
user:        Evan Layton <Evan.Layton@Sun.COM>
date:        Mon Dec 14 20:17:40 2009 -0700
description:
        7880 image-update fails if boot directory doesn't already exist
        11436 beadm create should support multiple pools
        364 user's home directory should be /home/<username>