Continuing on in our Installer Cheat Sheet Series, this week's Cheat Sheet is the Installer Folders Cheat Sheet. 

Most packagers and setup developers have had that moment when they knew where a file needed to go, but weren't quite sure how to get it there. This is a Cheat Sheet for the translation between how the common folder paths resolve, and the variables you're most likely to need to map those values to in the installation.

Note that the behavior of InstallScript variables is somewhat more complex than this chart suggests, changing based on project type and other conditions on the operating system. I would recommend reading the individual documents when using these to ensure you are getting expected behavior.

Feel free to leave us suggestions for additional cheat sheets you'd like to see. 

Did you miss one of the Cheat Sheets series? Read them here: Introducing the Installer Cheat Sheet Series, Installer Cheat Sheet Series – Part 2

Development teams building cloud-enabled virtual appliances have a number of considerations to take into account: the application, the cloud environment, the users, and other facets of the business and execution issues. Decisions regarding these considerations will drive how developers make use of cloud services.

While it's possible to start developing and deploying to a cloud very quickly, development teams should start cautiously, making sure that all of the team members understand the goals and processes involved first. Here are six considerations in preparation for deploying virtual appliances to the cloud for the first time.

1. Select a cloud provider. There are hundreds of different public cloud providers. If your organization isn't already using one, research as many options as possible for price, service-level agreements, reputation, locations, and software features.
2. Understand your application needs to determine your cloud requirements. Once you've selected a cloud provider based on the nature of your application, obtain a deep technical understanding of the infrastructure and platform offerings available, and select the ones that best meet the needs of the organization, application, and users.
3. Plan the deployment process. Lay out what the virtual appliance is supposed to do, then define the features that are needed to execute the deployment. Make sure you know exactly what is supposed to happen at every step of the deployment process, and plan for errors.
4. Set up and test the cloud execution environment. Whether you're leveraging a highly configured cloud execution environment such as Microsoft Azure, or a cloud with little or no supporting infrastructure, you have to define your deployment and execution environment and create it, either in a virtual machine (VM) locally or in the cloud itself. Further, it has to be consistent with the development environment, so that the deployment and execution process go smoothly.
5. 'Smoke test' the actual deploy before releasing it to the cloud. Make sure that the deployment will run to completion, even if it's incomplete or has defects. Set up your 'smoke test' as an integral part of the build process so that the team gains confidence in their ability to build the deploy package.
6. Practice the process of deploying your application to the cloud often. Make sure you have the process down properly before going live with the virtual appliance. If your team is using agile development processes you may be deploying to the cloud at the end of every agile sprint, and hopefully those are either continuous or at least daily. The more you practice, the better you'll get at it.

What considerations or steps have you taken to ensure a successful virtual appliance deployment to the cloud?

Read last week's post: Managing the Life Cycle of a Suite/Advanced UI Installation

Earlier this week I read a CIO.com blog post: Easy XP-Windows 7 Upgrades are Over regarding enterprise Windows 7 migrations.  A discussion in the comments section that enterprise IT departments are replacing products that haven't yet released support for Windows 7 with competitive solutions caught my eye. As software producers, this is a reminder of the importance to stay on top of enterprise technology trends or risk being replaced. Currently Windows migrations, application virtualization, and the move to 64-bit platforms are among the major enterprise IT initiatives that all software vendors should be supporting if they want to maintain their strategic enterprise accounts. 

One step that can help you stay on top of these trends is to ensure your development tools, such as InstallShield, are kept up to date. Upgrading to the latest version of InstallShield not only ensures your installation supports the latest Windows editions, but also tests your application against Windows best practices and logo requirements. By including a maintenance plan, you receive the latest platform updates and support for new enterprise technology trends as they become available. Plus, InstallShield's Virtualization Pack is available to release your application for Microsoft App-V enterprise deployments.

Authored by three InstallShield software engineers, a new white paper "Managing the Life Cycle of a Suite/Advanced UI Installation" is a must-read that helps in planning a new version of a Suite/Advanced UI installation that may—for example—introduce a new package, upgrade a package, remove a package, replace two packages with a new updated version, or any combination of these scenarios and more.

Read the introduction below and then click on the link to be taken directly to the white paper to read in its entirety.

The life cycle of a single package—perhaps a Windows Installer package or an InstallScript installation—consists of well-understood phases: first-time installation of a product, maintenance of the product, upgrades to the product, and product removal. In scenarios in which one package replaces another package, the level of complexity increases. A Suite installation further increases this complexity, since each package in the Suite may reach various phases at different stages during the life of the Suite. For example, a new version of a Suite installation may introduce a new package, upgrade a second package, and remove a third; it may also replace two packages with a new updated version. And on some target systems, all of those packages may behave as a first-time installation. Although the level of complexity increases with some of these Suite scenarios, the flexibility that is available makes the Suite project type a powerful choice for addressing various scenarios of modern installations. Accounting for each of the supported scenarios requires careful planning.

This white paper presents background information that explains how the Suite engine determines the state of each target system as well as the phase that should be used to run a Suite installation. This white paper also highlights how to plan and manage a Suite installation that successfully addresses each required phase in its life cycle.

Read the full white paper: Managing the Life Cycle of a Suite/Advanced UI Installation

Check out last week's post: Installer Cheat Sheet Series – Part 2

The second in the Series is the InstallScript Reference Cheat Sheet, a guide on the basics of InstallScript syntax.

We invite you to offer suggestions for additional Cheat Sheets you'd like to see. Stay tuned to InstallTalk for the next Cheat Sheet coming soon.

We'd like to note that the Cheat Sheet content was developed by Cary Roys, former consultant with Flexera Software. Thank you Cary!

Check out last week's post – Introducing the Installer Cheat Sheet Series

Cheat sheets serve as great references, offering fast help in different areas of life. A great resource for our development team has been http://www.cheat-sheets.org/, which covers most major programming languages.

Recently, the Flexera Software team took the opportunity to develop cheat sheets for a few software installer related tasks to help you get your job done better and faster. Below are topics of the cheat sheets we will share with you throughout this series:

• Common MSI Conditions
• InstallScript Reference
• Installer Folders

To kick off the series, the Common MSI Conditions Cheat Sheet gives you some of the most common conditions used in MSI projects for custom actions, features, components, etc. It also serves as a quick reference for most of what you need to know about Conditional Statement Syntax. 

We invite you to offer suggestions for additional cheat sheets you'd like to see. Stay tuned to InstallTalk for the next cheat sheet coming soon.

Read last week's post: 3 Common Pitfalls to Avoid with Virtual Appliances

Virtual appliances provide a way to deliver complex software to prospects and customers. They simplify the proof of concept process for software vendors, and make it straightforward for enterprises to give a product a try without being distracted by complicated configuration steps. They also make it easy for software vendors to deploy their products as hosted SaaS offerings on public clouds. Virtual appliances can save time and technical effort, and prevent problems later in the lifecycle.

A virtual appliance consists of the software performing the required work, such as an enterprise application, along with just enough operating system (JeOS) and any required prerequisites for the application to function. It often includes supporting software such as an application server, some level of database availability, and scripting language. In the open source world, this is the LAMP stack – Linux, Apache, MySQL, and PHP, Perl, or Python.

While at first glance there doesn't appear to be any downside to enabling customers to use software as virtual appliances, there are risks for the provider. Any self-contained software delivery is expected to work properly almost immediately, and there are some circumstances under which providers may face unexpected difficulties. Here are three common pitfalls to avoid with virtual appliances:

1. Not installing and configuring the entire software stack on the virtual machine (VM). Deciding the appropriate supporting software stack for your application isn't as easy as it may sound. You may have questions such as do you include the web server, application server, database, and configuration language? It is good practice to make a virtual appliance as self-contained as possible, as long as it can fit into any customer's computing infrastructure. But you still may have to make compromises depending on licensing and customer preference. If you do, understand those compromises and make sure you have the ability to mitigate risks.
2. Not providing a full set of configuration options on the VM. Usually a virtual appliance has to be configured as a part of the setup in the customer computing environment. It likely has to take into account the customer's network configuration, databases, and storage architecture. Virtual appliances typically provide a configuration page for setting this up. If a customer has an unusual network or database configuration, you may find that the setup options you provide aren't sufficient. That can delay a proof of concept installation or even kill a deal.
3. Not updating the virtual appliance stack as new versions of supporting software become available. This is probably the biggest concern with using virtual appliances. Just because a virtual appliance is a self-contained unit doesn't mean that it can be installed and forgotten about. For the enterprise software, you are probably applying patches, and maybe also doing customization once the customer better identifies its requirements. But you are likely engineering the application with updated versions of  the supporting  stack. You have to provide for that in the resulting virtual  appliance. That may require going back to reprovision virtual appliances already in the field, and also defining new configurations for new versions being released.

None of these concerns should prevent you from creating virtual appliances. But you can't just deploy and forget. Instead, you have to manage your appliance and its lifecycle just as closely as you would a traditional physical installation, though in a different way. The virtual appliance will help ease your software into a customer's computing infrastructure, but only if you manage it for the long term.

Related posts: Now Boarding: InstallAnywhere Flight 101 to Cloud and Virtual Environments; Configuring User-Defined Boot and Login Scripts for a Virtual Appliance

To learn more about the latest features in InstallAnywhere, watch the What's New in InstallAnywhere 2012 Webinar.

What is the relationship between a business practice like enterprise transformation and application installation? It all comes down to the ability of enabling the application to quickly and easily respond to rapidly changing business needs.

Enterprise transformation means that business processes are analyzed and changed to adapt to both new business opportunities and advances in information technology. A key facet in supporting enterprise transformation is the ability to deliver applications and features where and when they are needed to support new business processes and opportunities.

Using modern agile development methodologies, IT software development teams and application producers have been able to build application features iteratively in response to high-priority business needs. But to make those features useful, you have to do more than simply build them – you also need to create an installer in order to deliver them to the end-user.

There are many installation methods available today including virtual appliances and App Stores. Popular cloud platforms include Amazon EC2, RackSpace and Microsoft Azure. Azure is a popular choice with Microsoft developers because it offers a robust Windows and .NET execution environment. You may also provide your own Windows and .NET infrastructure.

To be agile and support the changing needs of business, teams may be required to change the installation priorities of an application under development. Even if installation requirements are known and defined at the beginning of a project, application producers are increasingly releasing their applications using multiple release types for their various users and target deployment environments.

All of this places many demands on the installation development process. Development teams need an installation solution that can create multiple installers for multiple environments. As business needs continue to rapidly change and adapt, the ability to provide the highest level of support and ensure successful transformation provides a competitive edge.

Learn more about the latest versions of InstallShield and InstallAnywhere

If you'd like to learn more about agile installation development, read our whitepaper: Agile and Installation Practices

Let us consider the following scenario. You have built a virtual appliance using InstallAnywhere 2012 Enterprise Edition with Cloud Pack. You have deployed the virtual appliance on VMware vSphere server and have switched it on. When the end user logs in to the appliance for the first time you would like to run certain scripts, for example, a script to install and configure an Apache server so that the end user of your virtual appliance can set the user name and password for the server. How does one do it? Consider another situation where you would like to run certain scripts every time you boot the virtual appliance, for example, starting and stopping operating system services, setting the default run level for these services, or downloading a file from a remote server. Is there any way to do so?

The answer to both the questions above is yes. InstallAnywhere 2012 Enterprise Edition with Cloud Pack not only lets you run executable scripts each time you power on your virtual appliance, but also every time you log in to the appliance. And the good thing about this is that you can make them work on both VMware vSphere 5 and Amazon EC2 hypervisors.

What Are Boot and Login Scripts?

Boot and login scripts are pretty straight forward. Any executable script that gets executed every time an end user boots (powers on) the virtual appliance is a boot script. The scripts that are run each time an end user logs into the appliance are login scripts.

Creating and Configuring Boot and Login Scripts

The shell scripts that are required to be run at boot or login time should be specified in the InstallAnywhere 2012 Advanced Designer, as shown in the following screen shot.

Navigate to Build Appliances | VM Configuration | Script Info tab and populate the following fields:

1. First Boot Script

   Choose the executable script that you would like to run when the virtual appliance is powered on the first time.

2. First Login Script

   Choose an executable script that should get executed the very first time an end user logs in to your virtual appliance.

3. Subsequent Boot Script

   Choose the executable script that you would like to run every other time, i.e., every subsequent time the virtual appliance is powered on.

4. Subsequent Login Script

   Choose an executable script that should get executed every other time, i.e., every subsequent time an end user logs in to your appliance.

In this blog I intend to demonstrate the usage of boot and login scripts for Ubuntu and CentOS virtual appliances.

Format of Boot and Login Scripts

All valid executable scripts for Ubuntu and CentOS are supported by InstallAnywhere 2012 Enterprise Edition with Cloud Pack. However, there are certain restrictions on the contents of boot scripts.

Restrictions on Boot Scripts

There are a couple of restrictions on the way the boot scripts should be written:

• They should not contain any command that requires any sort of user interaction, since the system is still powering on at boot time.
• These scripts cannot output any text on the Ubuntu or CentOS console. However, if you wish to log the output of your executable script, you can always redirect them to a log file. These logs will be available once the virtual appliance is powered on.


Examples

Let me give you an example of how to write a boot/login script for installing a LAMP stack on an Ubuntu virtual appliance.

A LAMP stack is a group of open source software; the acronym refers to Linux, Apache, MySQL, and PHP. Since installation of the Apache, MySQL, and PHP components requires user interaction in the form of keyboard input, we have to configure the installation process in the login script of the virtual appliance. Here is how you can write the script (say, lamp.sh):

#!/bin/sh

#This script installs a LAMP stack on my Ubuntu virtual appliance

#Update the package index

apt-get update

#Install Apache server

apt-get install apache2

#Install MySQL with PHP

apt-get install mysql-server libapache2-mod-auth-mysql php5-mysql

#Activate MySQL

mysql_install_db

#Run MySQL set up script

/usr/bin/mysql_secure_installation

#Install PHP

apt-get install php5 libapache2-mod-php5 php5-mcrypt

#Start the Apache server

/etc/init.d/apache2 start

exit 0

In the First Login Script field ( Build Appliances | VM Configuration | Script Info tab), enter the location of lamp.sh, and rest assured that this script will get executed when end users log in to your Ubuntu virtual appliance for the first time. This script will also enable the end users to configure information such as the user name, password, and port number, for the servers being installed.

It is quite evident that the moment you restart the virtual appliance, you will have to restart both the Apache and the MySQL servers. This job can be easily done by writing a small executable script and by specifying its location in the Subsequent Boot Script field. Here is an example of this script for an Ubuntu virtual appliance:

#!/bin/sh

#Start MySQL server

/etc/init.d/mysql start

#Start apache server

/etc/init.d/apache2 start

exit 0

Consider another example where you would like to download some documentation related to your virtual appliance from a remote HTTP server and store it to some location. You can set up your executable script in the following way:

#!/bin/sh

#Navigate to the location where the file has to be downloaded

cd /MY_WORK_DIR/Docs

#Download the file and store it at the above location

wget http://115.65.92.1/docs/MyVAppDocumenation.doc

exit 0

Follow the examples above to configure your boot scripts in a similar way. Take care though that you don't put any commands involving user interaction in your boot scripts.

You may also like: Now Boarding: InstallAnywhere Flight 101 to Cloud and Virtual Environments

To learn more about the latest features in InstallAnywhere, view the What's New in InstallAnywhere 2012 Webinar.

In recent years, multiplatform products have been growing more and more complex. Complicated configuration steps for your customers means that it takes them longer to become productive using your software. It also lengthens the sales cycle for prospective customers who are evaluating your products, and it may negatively affect their first impressions of your software. InstallAnywhere 2012 offers new support to help you manage these sorts of challenges.

In this blog article, I present an overview of the virtual appliance support that we've introduced in InstallAnywhere 2012 Enterprise Edition with Cloud Pack. This should help clear the runway so that you can begin to talk about and plan an application that can be installed on multiple platforms the traditional way, but also can be deployed into cloud and virtual environments. Happy flight planning!

Decide Your Destination 

InstallAnywhere now has support for building virtual appliances. Virtual appliances are preconfigured, self-contained, ready-to-run application solutions that are made by combining an application with just enough operating system (JeOS) and any required prerequisites for the application to run on a virtual machine.

Virtualization and the cloud provide new methods for delivering complex software products. Whether you want to build a cloud-ready virtual appliance that you can deploy automatically as a hosted SaaS offering on a public cloud, or an enterprise-ready virtual appliance that your enterprise customers can host in their own virtual environments, InstallAnywhere makes the transition easy for you and your customers. You can ship your virtual appliances fully installed and configured for your customers so that they can just fasten their seat belts. Furthermore, prospective customers can give your product a test run right away, without being distracted by special configuration tasks or potential related issues.

Pack Your Bags 

InstallAnywhere helps you to make the most of your efforts in developing multiplatform software by enabling you to use a single project file to configure traditional multiplatform installations, as well as virtual appliances. This makes it easy for you to accommodate both existing and emerging environments: You can continue to support traditional configurations that many of your customers still want—the physical installations that run on Windows, Linux Mac OS X, and many other platforms. At the same time, you can also start delivering your products as cloud-based solutions.

The following screen shot shows InstallAnywhere's new Build Appliances task that lets you configure settings for a virtual appliance within your traditional installation project.

Prepare for Takeoff 

Offering your products as virtual appliances enables you to enter new markets that may previously have been prohibited by installation complexity. It helps you eliminate problems that arise because of complicated configuration requirements. Your customers simply download a single file and launch your product. The ability to offer virtual appliances for your products also lets you create cloud-hosted and virtual machine evaluations, demos, and virtual labs in a controlled environment.

What's on the Itinerary? 

The following procedure describes the workflow for creating a virtual appliance in an InstallAnywhere installation project:

1. Select a virtual machine template—a preinstalled virtual machine disk that contains the operating system and any required operating system packages. You can use one of the prebuilt templates that you have the choice of installing when you install InstallAnywhere, or you can download a template later from the Flexera Software site. As an alternative, you can create your own custom template.
2. Configure the settings for your virtual appliance. This includes specifying information such as the name that you want to use for your virtual machine.
3. If appropriate, specify any custom scripts that you want to be run at various stages of your appliance, such as at first boot time or login.
4. If appropriate, add any prerequisite installations that your product requires.
5. Build the virtual appliance.
6. Deploy the virtual appliance to a public cloud such as Amazon EC2 or distribute it to your enterprise customers for easy provisioning within their virtual environments.

Learning to Fly

The InstallAnywhere team has been writing various blog articles that highlight the new virtual appliance support. We'll cover topics such as creating custom virtual machine templates, as well as configuring custom boot and login scripts.

So make sure that you stay tuned to our InstallTalk blog, and let us know related topics that you'd like to see covered.

To learn more about InstallAnywhere 2012, see the What's New in InstallAnywhere 2012 Webinar.