[OpenAFS] OpenAFS for Windows Integrated Logon - On or Off by default?

Dave B botsch@cnf.cornell.edu
Mon, 03 May 2010 14:08:11 -0400

My thoughts...

if the 1.6 branch is about to come out, then that version number change
would be a good place to make the integrated login change.

That said, as long as it's well announced, I don't have a problem w. the
change being made in 1.5.whatever ... now that I've learned how to do
transforms, this additional change should be relatively trivial.

On Mon, 2010-05-03 at 13:51 -0400, Jeffrey Altman wrote:
> The OpenAFS for Windows distributions come in two different installation
> packaging flavors.  The .EXE installer based on NSIS defaults integrated
> logon to be disabled.  The .MSI installer based on WiX defaults
> integrated logon to be enabled.  The reason for this difference is
> historical.  The MSI installer package was developed at MIT for use in
> pushing out OpenAFS to large numbers of clients via an automated "quiet"
> process.  The EXE installers were designed for use by individuals.  For
> the individual case the integrated logon functionality is less likely to
> be needed whereas the managed desktop environment is more likely to want it.
> Over the years the MSI installer package has begun to be used more
> frequently by individual users.   This is especially true for 64-bit
> Windows because there is no EXE option available.  When integrated logon
> is turned on by default and it is not properly configured this can cause
> long delays when attempting to logon to the machine.  Proper
> configuration requires a cell name, perhaps a realm name, and Kerberos
> configuration data available either via local configuration files or DNS
> SRV records.  This long delay results in end users (and even some
> experienced OpenAFS developers) believing that OpenAFS has somehow
> broken their machine.
> What I want to do is change the default in the MSI installer to be "off"
> [var.LogonOptions = "0"] but such a change will cause site specific
> transforms to do the wrong thing unless the transform is rebuilt.  Even
> though this change will be documented in the ChangeLog, the Release
> Notes, and in the Release Announcement I suspect that there are going to
> be a number of sites that will get burned by this change.  We have known
> about this problem for many years now and have put off dealing with it. 
> The question is, "is now the time to address the problem and prevent
> additional end users from getting burned when they decide to experiment
> with OpenAFS for Windows on their machine?"
> One option would be to hold off on this change for another month or two
> and apply it to the tree just before the 1.6 branch is cut.
> Thoughts?
> Jeffrey Altman
David William Botsch
CNF Computing