William,
Thanks!
Looks good to me now.
Joe
William Schumann wrote:
> 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
>>>>>>
>>>>
>>
