Changes between Version 2 and Version 3 of Download/ManualActivation manual activation guide
- Timestamp:
- Nov 10, 2011, 11:07:35 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Download/ManualActivation manual activation guide
v2 v3 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". 10 10 11 4. Define a network. You can of course define as many networks as you want, however networks cannot overlap. You must specify the name of the network (a name that will be used within /etc/networks), the IP address and mask of the network, and a location of the network. For now you can provide your organization code to define the location. Leave the modifiers blank.11 4. Define a network. You can of course define as many networks as you want, however networks cannot overlap. You must specify the name of the network (a name that will be used within /etc/networks), the IP address and mask of the network, and a location (in the network_location_opts) of the network. For now you can provide your organization code to define the location. Leave the 'add_network_modifiers' options blank. 12 12 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. **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!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 bug which will cause problems for you later. You can use a non-alphanunmeric fullname but it will break later compiles, so don't do that! 16 16 17 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"). … … 19 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. Remember this rack name because you'll be using it in the next step. 22 22 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.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 and it's location. The machine name 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. The location of the machine should be the rack that you defined in step 9 - change the "add_machine_chassis_opts" to say "rack" and then provide the value. Sorry there's no drop-down for this form at the moment, you have to remember the values... 24 24 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.
