aaf76e2cfb
hdparm versions prior to 9.51 interpret the value, NULL, as a
password with string value: "NULL".
Example output of hdparm with NULL password:
[root@localhost ~]# hdparm --user-master u --security-unlock NULL /dev/sda
security_password="NULL"
/dev/sda:
Issuing SECURITY_UNLOCK command, password="NULL", user=user
SECURITY_UNLOCK: Input/output error
Example output of hdparm with "" as password:
[root@localhost ~]# hdparm --user-master u --security-unlock "" /dev/sda
security_password=""
/dev/sda:
Issuing SECURITY_UNLOCK command, password="", user=user
Note the values of security_password in the output above. The output
was observed on a CentOS 7 system, which ships hdparm 9.43 in the
offical repositories.
This change attempts to unlock the drive with the empty string if an
unlock with NULL was unsucessful.
Issuing a security-unlock will cause a state transition from SEC4
(security enabled, locked, not frozen) to SEC5 (security enabled,
unlocked, not frozen). In order to check that a password unlock attempt
was successful it makes sense to check that the drive is in the unlocked
state (a necessary condition for SEC5). Only after all unlock attempts
fail, do we consider the drive out of our control.
The conditions to check the drive is in the right state have been
adjusted to ensure that the drive is in the SEC5 state prior to issuing
a secure erase. Previously, on the "recovery from previous fail" path,
the security state was asserted to be "not enabled" after an unlock -
this could never have been the case.
A good overview of the ATA security states can be found here:
http://www.admin-magazine.com/Archive/2014/19/Using-the-ATA-security-features-of-modern-hard-disks-and-SSDs
Change-Id: Ic24b706a04ff6c08d750b9e3d79eb79eab2952ad
Story: 2001762
Task: 12161
Story: 2001763
Task: 12162
|
||
|---|---|---|
| doc/source | ||
| etc/ironic_python_agent | ||
| imagebuild | ||
| ironic_python_agent | ||
| playbooks/legacy | ||
| releasenotes | ||
| tools | ||
| zuul.d | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .travis.yml | ||
| CONTRIBUTING.rst | ||
| Dockerfile | ||
| LICENSE | ||
| README.rst | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| plugin-requirements.txt | ||
| proxy.sh | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
ironic-python-agent
An agent for controlling and deploying Ironic controlled baremetal nodes.
The ironic-python-agent works with the agent driver in Ironic to provision the node. Starting with ironic-python-agent running on a ramdisk on the unprovisioned node, Ironic makes API calls to ironic-python-agent to provision the machine. This allows for greater control and flexibility of the entire deployment process.
The ironic-python-agent may also be used with the original Ironic pxe drivers as of the Kilo OpenStack release.
Building the IPA deployment ramdisk
For more information see the Image Builder section of the Ironic Python Agent developer guide.
Using IPA with devstack
This is covered in the Deploying Ironic with DevStack section of the Ironic dev-quickstart guide.
Project Resources
Project status, features, and bugs are tracked on StoryBoard:
Developer documentation can be found here:
Additional resources are linked from the project wiki page:
- IRC channel:
-
#openstack-ironic
To contribute, start here: Openstack: How to contribute.