Changes between Version 1 and Version 2 of Download/ManualActivation manual activation guide
- Timestamp:
- Nov 9, 2011, 8:25:29 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Download/ManualActivation manual activation guide
v1 v2 3 3 The appliance comes pre-seeded with only a very small amount of information - basically just a few different hardware models. In order to make use of the appliance you will need to provide some metadata describing your environment. 4 4 5 1. The first step is to define an _archetype_. An archetype is a library of rules that define how to provision a machine. You can create multiple archetypes (for example, a filer may have a very different way of being provisioned compared to a Linux server!). For now, you should create an archetype called "example-arch". Make sure you select "compilable"! Only compilable archetypes will produce configuration profiles. You may want to have non-compilable archetypes in order to reference hosts that are managed outside of Aquilon.5 1. The first step is to define an ''archetype''. An archetype is a library of rules that define how to provision a machine. You can create multiple archetypes (for example, a filer may have a very different way of being provisioned compared to a Linux server!). For now, you should create an archetype called "example-arch". Make sure you select "compilable"! Only compilable archetypes will produce configuration profiles. You may want to have non-compilable archetypes in order to reference hosts that are managed outside of Aquilon. 6 6 7 2. Secondly, you need to define a _personality_. The personality defines a specific use-case of a host. For now, you should create a personality called "app-server". Note that personalities are created within an archetype - the archetype we just created should be the default choice on this form.7 2. Secondly, you need to define a ''personality''. The personality defines a specific use-case of a host. For now, you should create a personality called "app-server". Note that personalities are created within an archetype - the archetype we just created should be the default choice on this form. 8 8 9 9 3. An operating systems must then be defined (again, within an archetype - this means that an operating system for something like a filer is managed completely distinct from operating systems used within Linux builds). Give a name of "rhel" and a version of "5u5_x64". … … 13 13 5. Defining a DNS domain is simple - just specify the domain name, with no extra information. 14 14 15 6. A _hub_ is an Aquilon name referring to the support "center" of a region. Typically, a single "hub" will look after satellite offices or sites. For example, you might have a hub of "ln" (London) which looks after all of the machines in EMEA. Note that regions are not the same as continents (for example, the commonly used region EMEA - "Europe, Middle East, Africa"). Define the hub as your center of operations. You should use the drop-down box on the organization to select your previously defined organization. Note: the "fullname" of the hub must be a single alphanumeric word at the moment due to a later bug. You can use a non-alphanunmeric fullname but it will break later compiles, so don't do that!15 6. A ''hub'' is an Aquilon name referring to the support "center" of a region. Typically, a single "hub" will look after satellite offices or sites. For example, you might have a hub of "ln" (London) which looks after all of the machines in EMEA. Note that regions are not the same as continents (for example, the commonly used region EMEA - "Europe, Middle East, Africa"). Define the hub as your center of operations. You should use the drop-down box on the organization to select your previously defined organization. **Important Note**: the "fullname" of the hub must be a single alphanumeric word at the moment due to a later bug. You can use a non-alphanunmeric fullname but it will break later compiles, so don't do that! 16 16 17 7. A _continent_, _country_ and _city_must be defined. Obviously these don't change much so why do you need to define them? Because of an implementation detail that declares all locations as a hierarchy (with continents as children of regions). It's something that should be fixed real soon but for now you just have to live with it. Define a continent corresponding to your location and put it in the appropriate hub. The name of the continent, country and cities are short codes (e.g. "eu"). Filling in the fullname here will make future forms and displays more descriptive, so put down the fullname of the continent (e.g. "Europe").17 7. A ''continent'', ''country'' and ''city'' must be defined. Obviously these don't change much so why do you need to define them? Because of an implementation detail that declares all locations as a hierarchy (with continents as children of regions). It's something that should be fixed real soon but for now you just have to live with it. Define a continent corresponding to your location and put it in the appropriate hub. The name of the continent, country and cities are short codes (e.g. "eu"). Filling in the fullname here will make future forms and displays more descriptive, so put down the fullname of the continent (e.g. "Europe"). 18 18 19 8. A _building_is where it starts to get a little more interesting. Buildings are really datacenters. They have names similar to the previous location types (a short code and a fullname). You could subdivide buildings further into floors and rooms but we won't be doing that in this initial installation.19 8. A ''building'' is where it starts to get a little more interesting. Buildings are really datacenters. They have names similar to the previous location types (a short code and a fullname). You could subdivide buildings further into floors and rooms but we won't be doing that in this initial installation. 20 20 21 9. All hosts must be placed into _racks_. A rack has an identifier which is a unique name based on the building code. For example, if you have a building called "bu" and you're creating the very first rack, then you may want the rack to be called "bu1". If you just put an id number (e.g. "1") as the rack ID then Aquilon will assign a name using the building code as a prefix. The racks typically have a row and column (each of which use alphanumeric identifiers). The row/column location is stored out within the final configuration profile, for use by monitoring tools and the like, but is not used within Aquilon itself.21 9. All hosts must be placed into ''racks''. A rack has an identifier which is a unique name based on the building code. For example, if you have a building called "bu" and you're creating the very first rack, then you may want the rack to be called "bu1". If you just put an id number (e.g. "1") as the rack ID then Aquilon will assign a name using the building code as a prefix. The racks typically have a row and column (each of which use alphanumeric identifiers). The row/column location is stored out within the final configuration profile, for use by monitoring tools and the like, but is not used within Aquilon itself. 22 22 23 23 10. Finally we can start defining machines! Although the machine form has a lot of options, you can happily ignore most of them! The key is in picking a machine model that has been fully defined (i.e. with information such as number of CPU's, etc). For example, the bl260c is a machine model that has been defined fully as an example. If you pick a "complete" model such as this, then the only other required field is the machine name. This is a label used to identify that specific piece of equipment (irrelevant of what DNS hostname it may pick up over time). You might choose to use the serial number. Or an asset code. Or just a sequence of names based on the building prefix. … … 25 25 11. Add a network interface to your newly defined machine. The interface name is typically something like "eth0". For now, define the MAC address and don't use automac, since we're leaving virtual hardware for later! Leave all the other options empty/default, including the IP address. 26 26 27 12. At this point you can create a host that will run on this hardware. You must provide a fully qualified hostname (and the domainname must be one of the DNS domains you created in step 5). Select the machine, archetype and personality using the drop-down selectors. You should give the branch _domain_ of "prod" and give the host a meaningful IP address (again, this must be an IP within one of the networks you defined in step 4. You can fill in the options here defining more about the host (you can also leave them blank and fill them in later, but at some point you're going to *have* to do it, so just do it now). Provide an osname of "rhel" and an osversion of "5u5_x64" (the same values that we defined earlier). Leave the other fields blank.27 12. At this point you can create a host that will run on this hardware. You must provide a fully qualified hostname (and the domainname must be one of the DNS domains you created in step 5). Select the machine, archetype and personality using the drop-down selectors. You should give the branch ''domain'' of "prod" and give the host a meaningful IP address (again, this must be an IP within one of the networks you defined in step 4. You can fill in the options here defining more about the host (you can also leave them blank and fill them in later, but at some point you're going to **have** to do it, so just do it now). Provide an osname of "rhel" and an osversion of "5u5_x64" (the same values that we defined earlier). Leave the other fields blank. 28 28 29 29 13. Finally, build the host. Specify the hostname you just created in step 12. The options should all be left alone here (since you just declared them in step 12). If all has gone well, you should receive the compiler output saying that the host was compiled successfully.
