Will Szumski aaf76e2cfb rework ATA secure erase
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
2018-05-16 13:18:15 +00:00
2018-03-22 13:45:58 -04:00
2013-09-17 13:41:59 -07:00
2018-03-28 14:15:29 +00:00
2017-03-02 11:45:38 +00:00

Team and repository tags

image

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:

https://storyboard.openstack.org/#!/project/947

Developer documentation can be found here:

https://docs.openstack.org/ironic-python-agent

Additional resources are linked from the project wiki page:

https://wiki.openstack.org/wiki/Ironic-python-agent

IRC channel:

#openstack-ironic

To contribute, start here: Openstack: How to contribute.

Description
A Python agent for provisioning and deprovisioning Bare Metal servers.
Readme 35 MiB
Languages
Python 99.9%
Shell 0.1%