William,
Summary of our phone conversation:
1 - check the logic @ line 596. What if no username but a password?
596 if (asp.username != NULL && asp.userpass == NULL) {
2 - Some of the auto_log_print lines can fit on one 80 char line now.
Joe
William Schumann wrote:
> 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
>>>>
>>
