[4608] in Release_7.7_team
Re: [Fwd: [SA] What's all this about Hesiod support?]
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jun 21 19:57:16 2004
From: Greg Hudson <ghudson@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
Cc: release-team@mit.edu, jdreed@mit.edu
In-Reply-To: <1087849094.7224.53.camel@tokata.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1087862230.12585.129.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Date: Mon, 21 Jun 2004 19:57:10 -0400
On Mon, 2004-06-21 at 16:18, Bill Cattey wrote:
> Is this information, about to be given as an IS&T Stock Answer to
> stand-alone Red Hat Enterprise Linux users consistent with what we tell
> users of DISCONNECTABLE Athena?
Essentially.
> Have we ourselves crafted a response to the "nonexistant
> /bin/athena/tcsh" failure?
Why would /bin/athena/tcsh not exist?
> Do we tell users to avoid creating their local account with a
> /mit/<uname> home directory?
Our offlinehome script creates the local homedir in /home/<username>.
That way if you want to copy files back and forth to your AFS homedir,
you can "attach <username>" and refer to it with /mit/<username> like
you'd expect.
jdreed wrote:
> P.S. What if I create /mit/username and /bin/athena/tcsh?
>
> Don't do that. The first one will cause problems if you ever wish to
> use OpenAFS, and the second one may cause updates to fail.
> Additionally, Athena tcsh has some customizations that will not exist
> on RedHat Enterprise.
How would creating /bin/athena/tcsh cause updates to fail?
The Athena local tcsh customizations are pretty minimal, and the most
visible one (~username) would be available with libc Hesiod support
turned on (though ~~username support would not).
