Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
software:rnotes:rn-rel3.2 [2012/01/16 07:05] nachosoftware:rnotes:rn-rel3.2 [2014/01/07 11:47] (current) – external edit 127.0.0.1
Line 21: Line 21:
 ======= What's New in OpenNebula 3.2 ======= ======= What's New in OpenNebula 3.2 =======
  
-In the following list you can check the highlights of 3.2 by component, [[http://dev.opennebula.org/projects/opennebula/issues?query_id=19 | a detailed list of changes can be found here]]:+In the following list you can check the highlights of 3.2 by component, [[http://dev.opennebula.org/projects/opennebula/issues?query_id=19 | a detailed list of changes can be found here]].
  
 ===== OpenNebula Core ===== ===== OpenNebula Core =====
Line 29: Line 29:
   * **[[documentation:rel3.2:auth_overview|Security and User management]]**, is one of the pillars of this release. In particular several potential threats have been secured, and the efficiency of the system has been improved:   * **[[documentation:rel3.2:auth_overview|Security and User management]]**, is one of the pillars of this release. In particular several potential threats have been secured, and the efficiency of the system has been improved:
     * Users now have a pre-defined driver (set by the admin). One of the issues found is that there are potential security holes if the user is able to choose its own driver through its ONE_AUTH file.     * Users now have a pre-defined driver (set by the admin). One of the issues found is that there are potential security holes if the user is able to choose its own driver through its ONE_AUTH file.
-    * Cloud services now uses an special authentication mechanism, using special server users.A server user account is granted to authenticate on-behalf of other users. Two mechanism are provided for this: cipher that uses symmetric cryptography, and x509 certificates.+    * Cloud services now use an special authentication mechanism, using special server users. A server user account is granted to authenticate on-behalf of other users. Two mechanism are provided for this: cipher that uses symmetric cryptography, and x509 certificates.
     * Notion of public users, that are restricted to public cloud APIs (e.g. EC2 or OCCI)     * Notion of public users, that are restricted to public cloud APIs (e.g. EC2 or OCCI)
     * Restricted attributes in VM Templates: DISK/SOURCE, CONTEXT/FILES, NIC/MAC and NIC/VLAN_ID. These attributes can be easily used to gain oneadmin access or to comprise VMs of any user.     * Restricted attributes in VM Templates: DISK/SOURCE, CONTEXT/FILES, NIC/MAC and NIC/VLAN_ID. These attributes can be easily used to gain oneadmin access or to comprise VMs of any user.
-    * Authentication Token caching. As some of the drivers may take some time to authenticate a request (e.g. LDAP), session token can no be cached by OpenNebula.+    * Authentication Token caching. As some of the drivers may take some time to authenticate a request (e.g. LDAP), session token can now be cached by OpenNebula.
  
   * **[[documentation:rel3.2:chmod|Resource Permissions]]**, this new release includes a new permission set to manage access control to virtual resources. The new permissions overcomes the limitations of the previous PUBLIC attribute and allow to share resources between users in multiple ways. Combined with the ACL system (also simplified to match the new permissions) allows the implementation of multiple roles.    * **[[documentation:rel3.2:chmod|Resource Permissions]]**, this new release includes a new permission set to manage access control to virtual resources. The new permissions overcomes the limitations of the previous PUBLIC attribute and allow to share resources between users in multiple ways. Combined with the ACL system (also simplified to match the new permissions) allows the implementation of multiple roles. 
  
-  * **Images and Virtual Networks by Name**, by popular request we've brought back these feature. When two resources share the same name, the UID or name of the owner of the resource can be used (defaults to "me") to select one of them.+  * **Images and Virtual Networks by Name**, by popular request we've brought back this feature. When two resources share the same name, the UID or name of the owner of the resource can be used (defaults to "me") to select one of them.
  
   * **Metadata for Users, Images and Virtual Networks**, you can update, and tag these resources with arbitrary metadata, that can be later used by other components.   * **Metadata for Users, Images and Virtual Networks**, you can update, and tag these resources with arbitrary metadata, that can be later used by other components.
Line 90: Line 90:
 ====== Migrating from OpenNebula 3.0 ====== ====== Migrating from OpenNebula 3.0 ======
  
-OpenNebula 3.2 is API compatible with OpenNebula 3.0, so you should expect that applications,  and drivers developed for 3.0 to work with this release, with the exception of custom authentication drivers. A detailed upgrade process [[documentation:rel3.2:upgrade]] can be found in the documentation.+OpenNebula 3.2 is API compatible with OpenNebula 3.0, so you should expect that applications,  and drivers developed for 3.0 to work with this release, with the exception of custom authentication drivers. A detailed [[documentation:rel3.2:upgrade|upgrade process]] can be found in the documentation.
  
 For a complete set of changes to migrate from a 3.0 installation please refer to the [[documentation:rel3.2:compatibility|Compatibility Guide]]. You should also read this document if you are an OpenNebula 3.0 user. For a complete set of changes to migrate from a 3.0 installation please refer to the [[documentation:rel3.2:compatibility|Compatibility Guide]]. You should also read this document if you are an OpenNebula 3.0 user.