Joe, Joseph J VLcek wrote: > William Schumann wrote: >> Joe, >> To be clearer, if there are missing passwords in either a >> user-supplied SC manifest or default.xml (which supplies the default >> user, user password, and root password), the installation will fail. > > This does not seem like a bad thing to me. As long as the failure > generates an informative message so the user can quickly determine > what went wrong. The messages needed some work.
I coded it to: - fail if root password is missing - warn if user defined, but user password missing Changed logging so that stderr messages will appear as well as in log (auto_log_print() does this). Updated webrev. Retesting in progress. William > Joe > > > > >> William >> >> Joseph J. VLcek wrote: >>> William, >>> >>> Sounds good to me. My brief comment below. >>> >>> Joe >>> >>> William Schumann wrote: >>>> Joe, >>>> >>>> Joseph J VLcek wrote: >>>>> William Schumann wrote: >>>>>> Default values for user and root passwords were not encrypted as >>>>>> called for in: >>>>>> >>>>>> - 4246 The user and root password are not encrypted in SC manifest >>>>>> >>>>>> http://cr.opensolaris.org/~wmsch/bug-6622/ >>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6622 >>>>>> >>>>>> Edited default.xml in SUNW-installadm-tools to provide usable >>>>>> encrypted passwords as described in bug report. >>>>>> >>>>>> user: jack password:jack >>>>>> root password: opensolaris >>>>>> >>>>>> Also added code to provide the same values if they are absent >>>>>> from the SC manifest for whatever reason. >>>>>> >>>>>> Informational debugging message in Orchestrator can now display >>>>>> the passwords, since they are encrypted. >>>>>> >>>>>> Tested default.xml changes going into SUNWinstalladm-tools >>>>>> package on x86 and SPARC. >>>>>> Tested new auto-install and liborchestrator on x86 and SPARC. >>>>>> Deleted entries from SC manifest and software generated correct >>>>>> default values. >>>>>> _______________________________________________ >>>>>> caiman-discuss mailing list >>>>>> caiman-discuss at opensolaris.org >>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>> >>>>> >>>>> William, >>>>> >>>>> Set the commit comment prior to generating the webrev. (I used >>>>> to forget to do this too. ;) >>>>> >>>>> Everything looks good... >>>>> >>>>> Just some nits. >>>>> >>>>> Hope this helps! >>>>> >>>>> Joe >>>>> >>>>> usr/src/cmd/ai-webserver/default.xml >>>>> ++++++++++++++++++++++++++++++++++++ >>>>> >>>>> Suggestion, Please consider: >>>>> ---------------------------- >>>>> >>>>> Is it considered safe to store encrypted defaults? >>>> Well, I suppose that it's a usability question. It is not safe for >>>> an uninformed user; however, many current users are evaluating AI >>>> and do not want to have to go through the process of generating >>>> passwords and placing them in manifests. Those concerned with >>>> maximum security will change the passwords in the manifest, protect >>>> manifests from public view, and change the passwords upon reboot. >>>>> What if the encryption algorithm changes? >>>> AI controls the encryption algorithm via >>>> /etc/security/policy.conf. If the security policy were changed in >>>> the distro, the default.xml passwords would also have to be changed >>>> to work. >>>>> >>>>> Since you added code to provide the defaults perhaps it might be >>>>> safest to not list the encrypted defaults in the manifest. >>>> Again, it is inherently unsafe to provide default passwords whether >>>> they are encrypted or not. It is assumed that the concerned user >>>> will override the defaults. Perhaps it is a bad idea to have the >>>> defaults in the code: if the default passwords are not provided in >>>> the code, the passwords could be removed from default.ini on the >>>> server so that there are no defaults at all (although I don't think >>>> this would be standard practice.) A custom distro could also have >>>> the default passwords removed. >>>> >>>> So, I am backing out the embedded passwords in the code, so that if >>>> passwords are not provided in a manifest, the install will fail. I >>>> also backed out the logging statements exposing the encrypted >>>> passwords in the log at an informational logging level. What do >>>> you think? >>> >>> This seems to me to be the correct thing to do. >>> >>> >>>>> >>>>> Question: >>>>> --------- >>>>> >>>>> Do/should we provide a mechanism or instructions for a user to >>>>> generate the encrypted passwords if they want something besides >>>>> the defaults? >>>> I have already provided instructions for this in the AI setup HTML >>>> page and the design document. >>>>> >>>>> usr/src/cmd/auto-install/auto_install.c >>>>> +++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> Comments on line 580 and 598 are the same. 598 should be changed >>>>> from: >>>>> 598 /* load user name from manifest or 'jack' */ >>>>> >>>>> To: >>>>> 598 /* load user login name from manifest or 'jack' */ >>>>> >>>> Changed. >>>> >>>> Thanks, Joe. Please review the modifications. >>>> William >>> >
