texroemer
commented
4 years ago Hi @KeithBierman
I updated Python SCP import scripts to now allow you to pass in the new password being set by SCP import as an argument. Once script detects 401 status code, it will attempt to use the new password passed in.
Example of running new script:
C:\Python38-32>ImportSystemConfigurationLocalFilenameREDFISH.py -ip 192.168.0.120 -u root -t IDRAC -f 2020-8-5_135318_export.xml -p calvin -np Test1234#
- JID_966485164453 successfully created for ImportSystemConfiguration method
- WARNING, JobStatus not completed, current status: "Importing Server Configuration Profile.", percent complete: "20"
- WARNING, status code 401 and argument -np detected. Script will now query job status using iDRAC user "root" new password set by SCP import
- PASS, job ID JID_966485164453 successfully marked completed
- Detailed configuration changes and job results for "JID_966485164453"
@odata.type: #DellManager.v1_0_0.ServerConfigurationProfileResults
DisplayValue: User Admin Password
ErrCode: 0
Name: Users.2#Password
NewValue: ******
OldValue: ******
Severity: OK
Message: Successfully imported and applied Server Configuration Profile.
MessageArgs: []
MessageArgs@odata.count: 0
MessageId: SYS053
KeithBierman
Background: For a bare metal as a service deployment, we had planned to execute systemerase with crypto and idrac settings, and then to restore to a "golden configuration" via ImportSystemSettingsNetwork. The latter seemed to unpredictably fail (racadm, GUI) but those tools did not provide any clue as to what failed. Kudos to Texas, the python code did. One fraction of the time it was failing to restore the BOSS configuration (reason unknown) which was problematic for us. The other fraction of the time it had to do with failing to set user credentials (primarily of user slots we didn't use). However, a third and most problematic case is where just around the 20% mark, we'd get WARNING, query job ID command failed, error code is: 401. Script will retry checking job status. This would time out, and then we'd get no usable diagnostics about what the issue was (I upped the max count to 30 in a futile effort ).
It has been suggested that issue probably is that when the password for root is changing due to the import, that attempts to check the status fail, and then all data is lost. The problem with this theory is that often the script doesn't fail in this way, and the root password is always changing from calvin to our password ... so I am at a loss to understand what is actually going on.
If there are some conditions when the authentication can fail in the middle of operation (which would be unfortunate!) then providing a secondary password for retries would be helpful.