Joe,
Implemented your suggestions and resubmitted webrev.
William
Joseph J VLcek wrote:
> 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
>>>>>
>>>
>
