diff --git a/docs/en-US/scheduled-maintenance-maintenance-mode-hosts.xml b/docs/en-US/scheduled-maintenance-maintenance-mode-hosts.xml index 28769c76691..6364e8b0c78 100644 --- a/docs/en-US/scheduled-maintenance-maintenance-mode-hosts.xml +++ b/docs/en-US/scheduled-maintenance-maintenance-mode-hosts.xml @@ -1,9 +1,28 @@ - %BOOK_ENTITIES; ]> + + +
Scheduled Maintenance and Maintenance Mode for Hosts You can place a host into maintenance mode. When maintenance mode is activated, the host becomes unavailable to receive new guest VMs, and the guest VMs already running on the host are seamlessly migrated to another host not in maintenance mode. This migration uses live migration technology and does not interrupt the execution of the guest. -
+ diff --git a/docs/en-US/search-base.xml b/docs/en-US/search-base.xml index 3c0d1ef6e75..2584da9201c 100644 --- a/docs/en-US/search-base.xml +++ b/docs/en-US/search-base.xml @@ -1,32 +1,51 @@ - %BOOK_ENTITIES; ]> + + +
- Search Base - An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department.. - - - - - - LDAP Server - Example Search Base DN - - - - - ApacheDS - ou=testing,o=project - - - Active Directory - OU=testing, DC=company - - - - - - + Search Base +An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department.. + + + + + + LDAP Server + Example Search Base DN + + + + + ApacheDS + ou=testing,o=project + + + Active Directory + OU=testing, DC=company + + + + + +
diff --git a/docs/en-US/search-user-bind-dn.xml b/docs/en-US/search-user-bind-dn.xml index a4c9d4b210f..4c427cfd039 100644 --- a/docs/en-US/search-user-bind-dn.xml +++ b/docs/en-US/search-user-bind-dn.xml @@ -1,28 +1,47 @@ - %BOOK_ENTITIES; ]> + + +
Search User Bind DN - The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudPlatform user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs. - - - - - LDAP Server - Example Bind DN - - - - - ApacheDS - cn=Administrator,dc=testing,ou=project,ou=org - - - Active Directory - CN=Administrator, OU=testing, DC=company, DC=com - - - -
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the &PRODUCT; user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs. + + + + + LDAP Server + Example Bind DN + + + + + ApacheDS + cn=Administrator,dc=testing,ou=project,ou=org + + + Active Directory + CN=Administrator, OU=testing, DC=company, DC=com + + + + diff --git a/docs/en-US/secondary-storage-add.xml b/docs/en-US/secondary-storage-add.xml index b17b998dfe5..060c899a78e 100644 --- a/docs/en-US/secondary-storage-add.xml +++ b/docs/en-US/secondary-storage-add.xml @@ -1,9 +1,28 @@ - %BOOK_ENTITIES; ]> + + +
Adding Secondary Storage TODO -
\ No newline at end of file + diff --git a/docs/en-US/secondary-storage-outage-and-data-loss.xml b/docs/en-US/secondary-storage-outage-and-data-loss.xml index f651310376a..42ab7d47188 100644 --- a/docs/en-US/secondary-storage-outage-and-data-loss.xml +++ b/docs/en-US/secondary-storage-outage-and-data-loss.xml @@ -1,10 +1,29 @@ - %BOOK_ENTITIES; ]> + + +
Secondary Storage Outage and Data Loss For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online. - Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically.Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system. -
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system. + diff --git a/docs/en-US/secondary-storage-vm.xml b/docs/en-US/secondary-storage-vm.xml index 40c8a279b7d..792644432d2 100644 --- a/docs/en-US/secondary-storage-vm.xml +++ b/docs/en-US/secondary-storage-vm.xml @@ -1,14 +1,32 @@ - %BOOK_ENTITIES; ]> -
- Secondary Storage VM - In addition to the hosts, CloudPlatform’s Secondary Storage VM mounts and writes to secondary storage. - Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols. - The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups. - The administrator can log in to the secondary storage VM if needed. - -
+ + + +
+ Secondary Storage VM + In addition to the hosts, &PRODUCT;’s Secondary Storage VM mounts and writes to secondary storage. + Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols. + The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups. + The administrator can log in to the secondary storage VM if needed. +
diff --git a/docs/en-US/secondary-storage.xml b/docs/en-US/secondary-storage.xml index 4d6191eb3bf..e755b56734d 100644 --- a/docs/en-US/secondary-storage.xml +++ b/docs/en-US/secondary-storage.xml @@ -1,10 +1,29 @@ - %BOOK_ENTITIES; ]> -
- Secondary Storage - This section gives concepts and technical details about CloudPlatform secondary storage. For information about how to install and configure secondary storage through the CloudPlatform UI, see the Advanced Installation Guide. -
+ + + +
+ Secondary Storage + This section gives concepts and technical details about &PRODUCT; secondary storage. For information about how to install and configure secondary storage through the &PRODUCT; UI, see the Advanced Installation Guide. +
diff --git a/docs/en-US/security-groups.xml b/docs/en-US/security-groups.xml index 3c1ae91c5da..fdb4ee90a09 100644 --- a/docs/en-US/security-groups.xml +++ b/docs/en-US/security-groups.xml @@ -1,8 +1,27 @@ - %BOOK_ENTITIES; ]> + + +
diff --git a/docs/en-US/send-projects-membership-invitation.xml b/docs/en-US/send-projects-membership-invitation.xml index 67abf33aee5..164235f2abe 100644 --- a/docs/en-US/send-projects-membership-invitation.xml +++ b/docs/en-US/send-projects-membership-invitation.xml @@ -1,13 +1,32 @@ - %BOOK_ENTITIES; ]> + + +
Sending Project Membership Invitations Use these steps to add a new member to a project if the invitations feature is enabled in the cloud as described in . If the invitations feature is not turned on, use the procedure in Adding Project Members From the UI. - Log in to the CloudPlatform UI. + Log in to the &PRODUCT; UI. In the left navigation, click Projects. In Select View, choose Projects. Click the name of the project you want to work with. @@ -15,10 +34,9 @@ In Add by, select one of the following: Account – The invitation will appear in the user’s Invitations tab in the Project View. See Using the Project View. - Email – The invitation will be sent to the user’s email address. Each emailed invitation includes a unique code called a token which the recipient will provide back to CloudPlatform when accepting the invitation. Email invitations will work only if the global parameters related to the SMTP server have been set. See . + Email – The invitation will be sent to the user’s email address. Each emailed invitation includes a unique code called a token which the recipient will provide back to &PRODUCT; when accepting the invitation. Email invitations will work only if the global parameters related to the SMTP server have been set. See . - Type the user name or email address of the new member you want to add, and click Invite. Type the CloudPlatform user name if you chose Account in the previous step. If you chose Email, type the email address. You can invite only people who have an account in this cloud within the same domain as the project. However, you can send the invitation to any email address. + Type the user name or email address of the new member you want to add, and click Invite. Type the &PRODUCT; user name if you chose Account in the previous step. If you chose Email, type the email address. You can invite only people who have an account in this cloud within the same domain as the project. However, you can send the invitation to any email address. To view and manage the invitations you have sent, return to this tab. When an invitation is accepted, the new member will appear in the project’s Accounts tab. -
- +
diff --git a/docs/en-US/service-offerings.xml b/docs/en-US/service-offerings.xml index 8af653bb789..5283c05afa7 100644 --- a/docs/en-US/service-offerings.xml +++ b/docs/en-US/service-offerings.xml @@ -1,12 +1,31 @@ - %BOOK_ENTITIES; ]> + + +
Service Offerings vCenter Maintenance Mode XenServer and Maintenance Mode vCenter Maintenance Mode XenServer and Maintenance Mode -
+ diff --git a/docs/en-US/set-database-buffer-pool-size.xml b/docs/en-US/set-database-buffer-pool-size.xml index 3fc439b1a8e..1c7503101ca 100644 --- a/docs/en-US/set-database-buffer-pool-size.xml +++ b/docs/en-US/set-database-buffer-pool-size.xml @@ -1,14 +1,33 @@ - %BOOK_ENTITIES; ]> + + +
Set Database Buffer Pool Size It is important to provide enough memory space for the MySQL database to cache data and indexes: Edit the Tomcat configuration file:/etc/my.cnf - 2. Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM. + Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM. innodb_buffer_pool_size=700M Restart the MySQL service.# service mysqld restart diff --git a/docs/en-US/set-monitor-total-vm-limits-per-host.xml b/docs/en-US/set-monitor-total-vm-limits-per-host.xml index 806ba334679..c11b9564ac8 100644 --- a/docs/en-US/set-monitor-total-vm-limits-per-host.xml +++ b/docs/en-US/set-monitor-total-vm-limits-per-host.xml @@ -1,10 +1,29 @@ - %BOOK_ENTITIES; ]> + + +
Set and Monitor Total VM Limits per Host - The CloudPlatform administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudPlatform global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudPlatform UI to disable allocation of more VMs to the cluster. + The &PRODUCT; administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use &PRODUCT; global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the cluster.
diff --git a/docs/en-US/set-projects-creator-permissions.xml b/docs/en-US/set-projects-creator-permissions.xml index bc0080253a9..1d9309f8837 100644 --- a/docs/en-US/set-projects-creator-permissions.xml +++ b/docs/en-US/set-projects-creator-permissions.xml @@ -1,13 +1,32 @@ - %BOOK_ENTITIES; ]> + + +
Setting Project Creator Permissions - You can configure CloudPlatform to allow any user to create a new project, or you can restrict that ability to just CloudPlatform administrators. + You can configure &PRODUCT; to allow any user to create a new project, or you can restrict that ability to just &PRODUCT; administrators. - Log in as administrator to the CloudPlatform UI. + Log in as administrator to the &PRODUCT; UI. In the left navigation, click Global Settings. In the search box, type allow.user.create.projects. Click the edit button to set the parameter. @@ -20,11 +39,9 @@ allow.user.create.projects - Set to true to allow end users to create projects. Set to false if you want only the CloudPlatform root administrator and domain administrators to create projects. - + Set to true to allow end users to create projects. Set to false if you want only the &PRODUCT; root administrator and domain administrators to create projects. Restart the Management Server.# service cloud-management restart -
- +
diff --git a/docs/en-US/set-resource-limits-for-projects.xml b/docs/en-US/set-resource-limits-for-projects.xml index f9b57a86ee3..2c331acde51 100644 --- a/docs/en-US/set-resource-limits-for-projects.xml +++ b/docs/en-US/set-resource-limits-for-projects.xml @@ -1,10 +1,28 @@ - %BOOK_ENTITIES; ]> + + +
Setting Resource Limits for Projects - The CloudPlatform administrator can set global default limits to control the amount of resources that can be owned by each project in the cloud. This serves to prevent uncontrolled usage of resources such as snapshots, IP addresses, and virtual machine instances. Domain administrators can override these resource limits for individual projects with their domains, as long as the new limits are below the global defaults set by the CloudPlatform root administrator. The root administrator can also set lower resource limits for any project in the cloud + The &PRODUCT; administrator can set global default limits to control the amount of resources that can be owned by each project in the cloud. This serves to prevent uncontrolled usage of resources such as snapshots, IP addresses, and virtual machine instances. Domain administrators can override these resource limits for individual projects with their domains, as long as the new limits are below the global defaults set by the &PRODUCT; root administrator. The root administrator can also set lower resource limits for any project in the cloud
- diff --git a/docs/en-US/set-up-invitations.xml b/docs/en-US/set-up-invitations.xml index bc7b21aed27..e6a22dba1af 100644 --- a/docs/en-US/set-up-invitations.xml +++ b/docs/en-US/set-up-invitations.xml @@ -1,13 +1,32 @@ - %BOOK_ENTITIES; ]> + + +
Setting Up Invitations - CloudPlatform can be set up either so that project administrators can add people directly to a project, or so that it is necessary to send an invitation which the recipient must accept. The invitation can be sent by email or through the user’s CloudPlatform account. If you want administrators to use invitations to add members to projects, turn on and set up the invitations feature in CloudPlatform.. + &PRODUCT; can be set up either so that project administrators can add people directly to a project, or so that it is necessary to send an invitation which the recipient must accept. The invitation can be sent by email or through the user’s &PRODUCT; account. If you want administrators to use invitations to add members to projects, turn on and set up the invitations feature in &PRODUCT;. - Log in as administrator to the CloudPlatform UI. + Log in as administrator to the &PRODUCT; UI. In the left navigation, click Global Settings. In the search box, type project and click the search button. In the search box, type project and click the search button. @@ -16,48 +35,39 @@ searchbutton.png: Searches projects - 5. In the search results, you will see a few other parameters you need to set to control how invitations behave. The table below shows global configuration parameters related to project invitations. Click the edit button to set each parameter + In the search results, you will see a few other parameters you need to set to control how invitations behave. The table below shows global configuration parameters related to project invitations. Click the edit button to set each parameter Configuration Parameters Description - - project.invite.required Set to true to turn on the invitations feature. - - project.email.sender The email address to show in the From field of invitation emails. - project.invite.timeout Amount of time to allow for a new member to respond to the invitation. - project.smtp.host Name of the host that acts as an email server to handle invitations. - project.smtp.password (Optional) Password required by the SMTP server. You must also set project.smtp.username and set project.smtp.useAuth to true. - project.smtp.port SMTP server’s listening port. - project.smtp.useAuth @@ -74,6 +84,4 @@ Restart the Management Server service cloud-management restart -
- diff --git a/docs/en-US/set-up-network-for-users.xml b/docs/en-US/set-up-network-for-users.xml index bc8902f5f24..4e2be48e312 100644 --- a/docs/en-US/set-up-network-for-users.xml +++ b/docs/en-US/set-up-network-for-users.xml @@ -1,11 +1,30 @@ - %BOOK_ENTITIES; ]> + + +
Setting Up Networking for Users - People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudPlatform administrator, you can do the following things to set up networking for your users: + People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a &PRODUCT; administrator, you can do the following things to set up networking for your users: Set up physical networks in zones Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls) @@ -13,5 +32,4 @@ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member -
diff --git a/docs/en-US/set-usage-limit.xml b/docs/en-US/set-usage-limit.xml index 350d5c43e1b..3ef528a690c 100644 --- a/docs/en-US/set-usage-limit.xml +++ b/docs/en-US/set-usage-limit.xml @@ -1,14 +1,33 @@ - %BOOK_ENTITIES; ]> + + +
Setting Usage Limits - CloudPlatform provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis. + &PRODUCT; provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis. Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs. This section covers the following topics: Globally Configured Limits Default Account Resource Limits Per Domain Limits -
+ diff --git a/docs/en-US/shared-networks.xml b/docs/en-US/shared-networks.xml index 24e0252e1ea..d505fed97b1 100644 --- a/docs/en-US/shared-networks.xml +++ b/docs/en-US/shared-networks.xml @@ -1,11 +1,30 @@ - %BOOK_ENTITIES; ]> + + +
Shared Networks - A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudPlatform 3.0.3). + A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in &PRODUCT; 3.0.3). Shared Networks are created by the administrator Shared Networks can be designated to a certain domain @@ -13,6 +32,4 @@ Shared Networks are isolated by security groups Public Network is a shared network that is not shown to the end users - -
diff --git a/docs/en-US/signing-api-requests.xml b/docs/en-US/signing-api-requests.xml index b71cd42d9e5..b9922068e20 100644 --- a/docs/en-US/signing-api-requests.xml +++ b/docs/en-US/signing-api-requests.xml @@ -1,36 +1,60 @@ -
- Signing API Requests - Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process. - To show how to sign a request, we will re-use the previous example. - http://http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D - Breaking this down, we have several distinct parts to this URL. - - Base URL: This is the base URL to the CloudStack Management Server. - http://localhost:8080 - - API Path: This is the path to the API Servlet that processes the incoming requests. - /client/api? - - Command String: This part of the query string comprises of the command, its parameters, and the API Key that identifies the account. - As with all query string parameters of field-value pairs, the “field” component is case insensitive while all “value” values are case sensitive. - command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ - - Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm. - &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D - - - Every API request has the format Base URL+API Path+Command String+Signature. - To generate the signature. - - For each field-value pair (as separated by a ‘&’) in the Command String, URL encode each value so that it can be safely sent via HTTP GET. - Make sure all spaces are encoded as “%20” rather than “+”. - - Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following. - apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2&zoneid=4 - - Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be “Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D”. - By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like: - http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D - - -
\ No newline at end of file + + +%BOOK_ENTITIES; +]> + + + +
+ Signing API Requests + Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process. + To show how to sign a request, we will re-use the previous example. + http://http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D + Breaking this down, we have several distinct parts to this URL. + + Base URL: This is the base URL to the CloudStack Management Server. + http://localhost:8080 + + API Path: This is the path to the API Servlet that processes the incoming requests. + /client/api? + + Command String: This part of the query string comprises of the command, its parameters, and the API Key that identifies the account. + As with all query string parameters of field-value pairs, the "field" component is case insensitive while all "value" values are case sensitive. + command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ + + Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm. + &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D + + + Every API request has the format Base URL+API Path+Command String+Signature. + To generate the signature. + + For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET. + Make sure all spaces are encoded as "%20" rather than "+". + + Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following. + apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2&zoneid=4 + + Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D". + By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like: + http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D + + +
diff --git a/docs/en-US/site-to-site-vpn.xml b/docs/en-US/site-to-site-vpn.xml index 2e29909f4ae..034fb42fdd8 100644 --- a/docs/en-US/site-to-site-vpn.xml +++ b/docs/en-US/site-to-site-vpn.xml @@ -1,14 +1,33 @@ - %BOOK_ENTITIES; ]> + + +
Site-to-Site VPN To add a Virtual Private Cloud (VPC): - Log in to the CloudPlatform UI as an administrator or end user. + Log in to the &PRODUCT; UI as an administrator or end user. In the left navigation, choose Network In the Select view, select site-to-site VPN. Click Add site-to-site VPN. Provide the following information: @@ -23,5 +42,4 @@ Click OK. -
diff --git a/docs/en-US/snapshot-restore.xml b/docs/en-US/snapshot-restore.xml index 2a63f1f1917..b2f60f4b1e9 100644 --- a/docs/en-US/snapshot-restore.xml +++ b/docs/en-US/snapshot-restore.xml @@ -1,9 +1,28 @@ - %BOOK_ENTITIES; ]> + + +
- Snapshot Restore - There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk. -
+ Snapshot Restore + There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk. + diff --git a/docs/en-US/standard-events.xml b/docs/en-US/standard-events.xml index 290b8bc5625..b4a4c68a6cb 100644 --- a/docs/en-US/standard-events.xml +++ b/docs/en-US/standard-events.xml @@ -1,8 +1,27 @@ - %BOOK_ENTITIES; ]> + + +
Standard Events The events log records three types of standard events. @@ -17,6 +36,4 @@ ERROR. This event is generated when an operation has not been successfully performed - -
- + diff --git a/docs/en-US/static-nat.xml b/docs/en-US/static-nat.xml index ea7c7d8d565..ef9e2fc9167 100644 --- a/docs/en-US/static-nat.xml +++ b/docs/en-US/static-nat.xml @@ -1,9 +1,28 @@ - %BOOK_ENTITIES; ]> + + +
Static NAT - A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called “static” NAT. This section tells how to enable or disable static NAT for a particular IP address. + A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
diff --git a/docs/en-US/sticky-session-policies-for-lb-rules.xml b/docs/en-US/sticky-session-policies-for-lb-rules.xml index a8c11c95ff5..972a1954f13 100644 --- a/docs/en-US/sticky-session-policies-for-lb-rules.xml +++ b/docs/en-US/sticky-session-policies-for-lb-rules.xml @@ -1,11 +1,30 @@ - %BOOK_ENTITIES; ]> + + +
Sticky Session Policies for Load Balancer Rules - Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of “stickiness” is also referred to as persistence or maintaining state. - Any load balancer rule defined in CloudPlatform can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie, application-generated cookie, or source-based. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. The cookie name can be specified by the administrator or automatically generated. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached. - For the most up to date list of available stickiness methods, see the CloudPlatform UI or call listNetworks and check the SupportedStickinessMethods capability. + Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of "stickiness" is also referred to as persistence or maintaining state. + Any load balancer rule defined in &PRODUCT; can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie, application-generated cookie, or source-based. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. The cookie name can be specified by the administrator or automatically generated. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached. + For the most up to date list of available stickiness methods, see the &PRODUCT; UI or call listNetworks and check the SupportedStickinessMethods capability.
diff --git a/docs/en-US/stop-restart-management-server.xml b/docs/en-US/stop-restart-management-server.xml index 26d30eab340..2edc23332c0 100644 --- a/docs/en-US/stop-restart-management-server.xml +++ b/docs/en-US/stop-restart-management-server.xml @@ -1,12 +1,31 @@ - %BOOK_ENTITIES; ]> + + +
Stopping and Restarting the Management Server The root administrator will need to stop and restart the Management Server from time to time. - For example, after changing a global configuration parameter, a restart is required. If you have multiple Management Server nodes, restart all of them to put the new parameter value into effect consistently throughout the cloud.. + For example, after changing a global configuration parameter, a restart is required. If you have multiple Management Server nodes, restart all of them to put the new parameter value into effect consistently throughout the cloud. To stop the Management Server, issue the following command at the operating system prompt on the Management Server node: # service cloud-management stop To start the Management Server: diff --git a/docs/en-US/stopped-vm.xml b/docs/en-US/stopped-vm.xml index e6b8400c897..0983142423d 100644 --- a/docs/en-US/stopped-vm.xml +++ b/docs/en-US/stopped-vm.xml @@ -1,12 +1,35 @@ -
- Stopped VM - CloudPlatform now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state. - A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. - The possible values are: - - true - The VM starts as a part of the VM deployment. - false - The VM is left in the stopped state at the end of the VM deployment. - - The default value is true. -
+ + +%BOOK_ENTITIES; +]> + + +
+ Stopped VM + &PRODUCT; now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state. + A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. + The possible values are: + + true - The VM starts as a part of the VM deployment. + false - The VM is left in the stopped state at the end of the VM deployment. + + The default value is true. +
diff --git a/docs/en-US/stopping-and-starting-vms.xml b/docs/en-US/stopping-and-starting-vms.xml index 20d0d952327..845260e8e21 100644 --- a/docs/en-US/stopping-and-starting-vms.xml +++ b/docs/en-US/stopping-and-starting-vms.xml @@ -1,5 +1,28 @@ + + +%BOOK_ENTITIES; +]> + + +
Stopping and Starting VMs Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
- diff --git a/docs/en-US/storage-tags.xml b/docs/en-US/storage-tags.xml index 3297c8d83c2..6d18c90ada8 100644 --- a/docs/en-US/storage-tags.xml +++ b/docs/en-US/storage-tags.xml @@ -1,11 +1,29 @@ - %BOOK_ENTITIES; ]> + + +
Storage Tags - Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by CloudPlatform. They are matched against tags placed on service and disk offerings. CloudPlatform requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume. + Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by &PRODUCT;. They are matched against tags placed on service and disk offerings. &PRODUCT; requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume. The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same. - -
+
diff --git a/docs/en-US/storage.xml b/docs/en-US/storage.xml index 45fa648db58..7d1a65744bc 100644 --- a/docs/en-US/storage.xml +++ b/docs/en-US/storage.xml @@ -1,11 +1,30 @@ - %BOOK_ENTITIES; ]> -
- Deleting VMs - CloudPlatform defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS. - There is no ephemeral storage in CloudPlatform. All volumes on all nodes are persistent -
+ + + +
+ Deleting VMs + &PRODUCT; defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS. + There is no ephemeral storage in &PRODUCT;. All volumes on all nodes are persistent +
diff --git a/docs/en-US/suspend-project.xml b/docs/en-US/suspend-project.xml index 9ad1e622fc0..bfaa12a03d9 100644 --- a/docs/en-US/suspend-project.xml +++ b/docs/en-US/suspend-project.xml @@ -1,15 +1,34 @@ - %BOOK_ENTITIES; ]> + + +
Suspending or Deleting a Project When a project is suspended, it retains the resources it owns, but they can no longer be used. No new resources or members can be added to a suspended project. When a project is deleted, its resources are destroyed, and member accounts are removed from the project. The project’s status is shown as Disabled pending final deletion. - A project can be suspended or deleted by the project administrator, the domain administrator of the domain the project belongs to or of its parent domain, or the CloudPlatform root administrator. + A project can be suspended or deleted by the project administrator, the domain administrator of the domain the project belongs to or of its parent domain, or the &PRODUCT; root administrator. - Log in to the CloudPlatform UI. + Log in to the &PRODUCT; UI. In the left navigation, click Projects. In Select View, choose Projects. Click the name of the project. @@ -26,5 +45,4 @@ deletebutton.png: Removes a member -
- + diff --git a/docs/en-US/sys-reliability-and-ha.xml b/docs/en-US/sys-reliability-and-ha.xml index d8c4bbdf69c..bdb36d0fa46 100644 --- a/docs/en-US/sys-reliability-and-ha.xml +++ b/docs/en-US/sys-reliability-and-ha.xml @@ -1,12 +1,31 @@ - %BOOK_ENTITIES; ]> + + +
System Reliability and High Availability vCenter Maintenance Mode XenServer and Maintenance Mode vCenter Maintenance Mode XenServer and Maintenance Mode -
+ diff --git a/docs/en-US/sysprep-for-windows-server-2003R2.xml b/docs/en-US/sysprep-for-windows-server-2003R2.xml index bdde68e89b2..86e1667a1c5 100644 --- a/docs/en-US/sysprep-for-windows-server-2003R2.xml +++ b/docs/en-US/sysprep-for-windows-server-2003R2.xml @@ -1,39 +1,57 @@ - %BOOK_ENTITIES; ]> + + +
- Sysprep for Windows Server 2003 R2 - Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2. - - Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM. - Run c:\sysprep\setupmgr.exe to create the sysprep.inf file. - - Select Create New to create a new Answer File. - Enter “Sysprep setup” for the Type of Setup. - Select the appropriate OS version and edition. - On the License Agreement screen, select “Yes fully automate the installation”. - Provide your name and organization. - Leave display settings at default. - Set the appropriate time zone. - Provide your product key. - Select an appropriate license mode for your deployment - Select “Automatically generate computer name”. - Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up. - Leave Network Components at “Typical Settings”. - Select the “WORKGROUP” option. - Leave Telephony options at default. - Select appropriate Regional Settings. - Select appropriate language settings. - Do not install printers. - Do not specify “Run Once commands”. - You need not specify an identification string. - Save the Answer File as c:\sysprep\sysprep.inf. - - - - Run the following command to sysprep the image:c:\sysprep\sysprep.exe -reseal -mini -activated - After this step the machine will automatically shut down - -
+ Sysprep for Windows Server 2003 R2 + Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2. + + Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM. + Run c:\sysprep\setupmgr.exe to create the sysprep.inf file. + + Select Create New to create a new Answer File. + Enter “Sysprep setup” for the Type of Setup. + Select the appropriate OS version and edition. + On the License Agreement screen, select “Yes fully automate the installation”. + Provide your name and organization. + Leave display settings at default. + Set the appropriate time zone. + Provide your product key. + Select an appropriate license mode for your deployment + Select “Automatically generate computer name”. + Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up. + Leave Network Components at “Typical Settings”. + Select the “WORKGROUP” option. + Leave Telephony options at default. + Select appropriate Regional Settings. + Select appropriate language settings. + Do not install printers. + Do not specify “Run Once commands”. + You need not specify an identification string. + Save the Answer File as c:\sysprep\sysprep.inf. + + + Run the following command to sysprep the image:c:\sysprep\sysprep.exe -reseal -mini -activated + After this step the machine will automatically shut down + + diff --git a/docs/en-US/sysprep-windows-server-2008R2.xml b/docs/en-US/sysprep-windows-server-2008R2.xml index 37a2e1cefda..af36d15a2c1 100644 --- a/docs/en-US/sysprep-windows-server-2008R2.xml +++ b/docs/en-US/sysprep-windows-server-2008R2.xml @@ -1,12 +1,31 @@ - %BOOK_ENTITIES; ]> + + +
- System Preparation for Windows Server 2008 R2 - For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location: - Microsoft Download Center. + System Preparation for Windows Server 2008 R2 + For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location: + Microsoft Download Center. Use the following steps to run sysprep for Windows 2008 R2:The steps outlined here are derived from the excellent guide by Charity Shelbourne, originally published at Windows Server 2008 Sysprep Mini-Setup Download and install the Windows AIKWindows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file. @@ -44,8 +63,5 @@ cd c:\Windows\System32\sysprep sysprep.exe /oobe /generalize /shutdown The Windows 2008 R2 VM will automatically shut down after sysprep is complete. - - -
diff --git a/docs/en-US/system-reserved-ip-addresses.xml b/docs/en-US/system-reserved-ip-addresses.xml index aadd2d7d8f7..2f4922553fa 100644 --- a/docs/en-US/system-reserved-ip-addresses.xml +++ b/docs/en-US/system-reserved-ip-addresses.xml @@ -1,19 +1,38 @@ - %BOOK_ENTITIES; ]> + + +
System Reserved IP Addresses - In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudPlatform Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP. + In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the &PRODUCT; Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP. The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone. The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in. - Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudPlatform can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts. + Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. &PRODUCT; can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts. In all zones: - Provide private IPs for the system in each pod and provision them in CloudPlatform. + Provide private IPs for the system in each pod and provision them in &PRODUCT;. For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth. In a zone that uses advanced networking: - For vSphere with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudPlatform System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide. + For vSphere with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required &PRODUCT; System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide. When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi. To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or more of the following techniques: TODO diff --git a/docs/en-US/system-service-offerings.xml b/docs/en-US/system-service-offerings.xml index 92aff735111..75aa128d4c8 100644 --- a/docs/en-US/system-service-offerings.xml +++ b/docs/en-US/system-service-offerings.xml @@ -1,10 +1,29 @@ - %BOOK_ENTITIES; ]> + + +
System Service Offerings - System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudPlatform root administrator. CloudPlatform provides default system service offerings. The CloudPlatform root administrator can create additional custom system service offerings. - When CloudPlatform creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering. + System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the &PRODUCT; root administrator. &PRODUCT; provides default system service offerings. The &PRODUCT; root administrator can create additional custom system service offerings. + When &PRODUCT; creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
diff --git a/docs/en-US/system-vm-template.xml b/docs/en-US/system-vm-template.xml index e873ee1b1e5..a9477f3a61d 100644 --- a/docs/en-US/system-vm-template.xml +++ b/docs/en-US/system-vm-template.xml @@ -1,8 +1,27 @@ - %BOOK_ENTITIES; ]> + + +
The System VM Template The System VMs come from a single template. The System VM has the following characteristics: @@ -15,5 +34,4 @@ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed Latest version of JRE from Sun/Oracle ensures improved security and speed -