About Projects: Define and Apply Default Configurations
This article applies to: Managed Servers
A project defines a list of default configurations for virtual machines within a Service Group. A service group may have one or more projects.
- One Project: Encompasses the configuration for every virtual server they order.
- Multiple Projects: Apply specific configurations to certain classes of systems.
The project configuration can define the following:
- Account Number: The account number is set at the service group level. It's possible to create additional account numbers for specific projects.
- Destination Network: Used when additional networks are required, for example to place some hosts behind a load balancer or behind the server farm firewall appliance.
- Hostname Scheme: Virtual servers will be assigned host names from a pre-allocated pool. See Limitations.
- OS Configuration Defaults: For Windows servers, sets the default Active Directory OU and domain-based policies. On Linux servers, defines the default Cfengine class and SFAM role(s). Linux systems have an option to run a post-installation script. See Linux Custom Post-Install Script.
- Limit OS Choices: Used to limit operating system options for projects designed to be Linux or Windows-only (or specific to particular versions of an OS). (Default is to allow all supported operating systems to be selected for new orders.)
Red Hat Linux builds can run a customization script, provided by the customer, after the server has been built and booted successfully into multi-user mode. This script may be useful to Service Groups deploying a number of Linux virtual machines that all require some shared initial configuration steps. For example, a service group may want to install standard software on all of their self-service VMs.
Post-install scripts can be set for the entire Service Group, individual projects within the group, or both. A script configured at the Project level takes precedence over anything configured for the Service Group as a whole. This means you have the option to provide multiple post-install scripts, perhaps one for the entire Service Group (if no project overrides it) and others tailored specifically to certain projects within the group.
Request a Custom Post-Install Script
- The Area Manager should email firstname.lastname@example.org to make a request.
- Systems Support creates a wrapper for your script and adds it to the build process. The wrapper script is responsible for downloading, running, and logging the output (and exit code) from your custom post-install script.
The necessary configuration is added to the VM Self-Service application to call the custom script on Linux virtual machines you request.
Note: We currently do not perform any error notification on the result of your script's execution. You will need to check the log files for success/failure and any output information.
- The wrapper script logs all output from the execution of the script, including the attempt to download it from your server, to the file /var/log/cit_kickstart_customer_post.log. Assuming your script was able to be downloaded and executed, the last log entry in this file should contain the numeric exit code.
View Projects that Have Custom Post-Install Scripts
On the VM Self-Service menu, click Sub-Project Detail, you can see which projects have custom post-install scripts. If a script has been set, the name of the wrapper script is listed.
Not Set indicates no script will be run for hosts requested under that project.