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 Programmer/Analyst CNF Computing [email protected] ******************************** _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
