Skip to main content

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.)

Linux Custom Post-Install Script

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

  1. The Area Manager should email systems-support@cornell.edu to make a request.
  2. 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.
  3. 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.
  4. 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

  1. 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.

Was this page helpful?

Your feedback helps improve the site.

Comments?