Last articles



3.3.2 451 group 451 research apache APIs app store appcenter apphub Appliance appliance Appliance Template appliance template application delivery application marketplace apx aws AWS aws marketplace Azure azure bento boxes bfm business big data Billing cisco citrix cloud Cloud Computing cloud computing cloud expo cloud hybride cloud migration cloud migrations cloud onboarding cloud server images cloudplatform cloudscape CloudStack cloudstack cloudwatt collaboration container crayon custom software DEB


Adding Custom Software to Appliances

Written by Elaine Muus le 12 january 2015

There are two ways to add 3rd party software components or your own software to an appliance.

The first way is through the Project Catalog. This catalog provides a set of software components that you can quickly add to your appliance.

The second method is to use your private software library, known as “My Software”. This library can include any software that you upload into UForge.

To add custom software components you must upload the files, then add them to the existing appliance.

Read more Adding Custom Software to Appliances

Classified in : Tutorial, Tip - Tags : uforge, appliance, template, my software, custom software - no comments

Adding "WordPress" to Windows Templates, couldn't be easier

Written by Nik Tetteh-Lartey le 31 january 2014

Seen our last blog on creating a Windows 2008 R2 XAMPP server template? If yes, then creating a WordPress blogging server is as easy as just adding an extra package!

What do we do?

After we have created our XAMPP server template we perform two additional steps.

  • Add the WordPress component to the XAMPP stack

  • Update our installation and configuration script
C:\uploads\mysoftware\JREWindows64bit-7.45\jre-7u45-windows-x64.exe /s
C:\uploads\mysoftware\MSVS-2008\vcredist_x64-2008.exe /q:a 
timeout 30
taskkill /F /IM TrustedInstaller.exe
C:\uploads\mysoftware\XAMPP-1.8.3\xampp-win32-1.8.3-2-VC11-installer.exe --mode unattended
timeout 20
timeout 20
  --mode unattended
timeout 20


That's all to it. Just follow the previous XAMPP blogs steps to generate, launch and access your WordPress Windows image.

Classified in : Technology, Tutorial, Microsoft Windows - Tags : template, windows, uforge, wordpress, php, mysql, perl, XAMPP, apache, tomcat - no comments

Anyone fancy creating a Windows Server "XAMPP" template!

Written by Nik Tetteh-Lartey le 31 january 2014

Getting started

Imagine we want to build a Windows server machine, containing a web development stack, including Apache web server, MySQL, PHP and Perl, the equivalent to the popular LAMP stacks, but with the Perl language added on, just for more flexibility! UForge factory will allow us to do this and more, as it will allow us to define our Windows machine as a "model" or so called server template, giving us the flexibility to add to or refine our machines capabilities and or functionalities, over time, by the simple clicking of a button. Let's get started. Firstly, we have to create a new server template which is based on our chosen Windows operating system and architecture.

  • Using the UForge UI, we create the template selecting Windows Server 2008 R2 as our preferred operating system.

  • This completed, we now proceed to defining the "OS profile" by selecting the Windows Server 2008 R2 distribution we'd like to use, in this case, Enterprise, Core, English.

Adding the software

The next step is to add the necessary middleware components. There are many options available here and a simple Internet search can give us some ideas. In this case we opted for Apache Friends community offering with a well-integrated middleware stack using an opensource software project called XAMPP. As we will find in the XAMPP online documentation, PHP needs some extra software i.e. the Microsoft Visual 2008 studio compiler, which is a redistributable package from Microsoft. Finally, we note, that Tomcat has one additional requirement; a Java runtime environment (JRE). So re-capping, we need to add two extra pieces of software, JRE, Microsoft Visual C++ and XAMPP itself. With UForge, adding these extra pieces of software to a template can be done using what is called My Software projects. Typically, for our XAMPP server template, we will create three of these My Software projects, but this is only a suggestion, we can, if we want, create more or less, depending on how we want bundle certain pieces of software and/or special files. Each project is named, with a version number and a description. We may also consider adding the corresponding software license file to the projects. As for the software itself, we simply upload the each piece of software to its corresponding My Software project.

Installation and configuration

The installation and configuration of our chosen middleware software components can be done in many ways, two of which are:

  • In the My Software project itself, by ticking the "Install this software" check box, and giving some parameters to pass for the installation process.
  • Using classic Windows bat configuration scripts files.

In this example, we'll illustrate how to perform our chosen middleware software installation and configuration with bat installation scripts. We will create two scripts: one to be executed at first boot, and one to launch XAMPP service on every boot. The installation script is a simple Windows executable bat file, Note: this first boot script contains all the installation, configuration and service setup processes:

C:\uploads\mysoftware\JREWindows64bit-7.45\jre-7u45-windows-x64.exe /s
C:\uploads\mysoftware\MSVS-2008\vcredist_x64-2008.exe /q:a
timeout 30
taskkill /F /IM TrustedInstaller.exe
C:\uploads\mysoftware\XAMPP-1.8.3\xampp-win32-1.8.3-2-VC11-installer.exe --mode unattended

This script installs the JRE, Microsoft Visual Studio and XAMPP stack. Looking at the script launching the XAMPP management stack for every boot, it contains only the XAMPP stack's component startup scripts:


Adding the Windows bat script files to the template is easy, we just use the UForge UI's Configuration view, as the following clearly depicts.

Et voila ... that's it!

We're done, our UForge Server Template is complete, at least for this iteration of its life. Note we can easily update this server template, at any time, to improve and perfect it, over its overall life-time. So, what's next for our newly created Windows 2008 R2 Server XAMPP server template?

Image Generation and Launch

We specify some desired machine sizes and select our preferred "physical, virtual or cloud" format to create the image in, after which we are ready to launch and start it. 


Note using our template description for instructions, we'll be able to connect to the XAMPP console using our favorite web browser.

You can also launch the XAMPP Control Panel in the Windows image.

So what are you waiting for? Try it out for yourselves, now! Just sign-up at UShareSoft for your free account and get cracking with modelling and building your very first Windows server template, you can even use our Marketplace templates as basis of yours.

Classified in : News, Technology, Tutorial, Microsoft Windows - Tags : template, windows, uforge - 2 comments

"I'm My Own Grandpa" - Avoiding Dependency Hell

Written by James Weir le 15 october 2013

"I'm My Own Grandpa" is a song that tells the story of a man who, through a series of complicated marriages, becomes his own step-grandfather. Over the years, there have been many real examples that have been published in newspapers and magazines :


"There was a widow and her daughter-in-law, a man and her daughter-in-law, and man and his son. The widow married the son, and the daughter the old gentleman. The widow was therefore mother to her husband’s father, and consequently grandmother to her own husband. They had a son, to which she was a great-grandmother: now, as the son of a great-grandmother must be either a grandfather or great-uncle, this boy was one or the other" - Hood's magazine in 1884

Reading this reminded me of the confusion and pain that I have been through on the numerous occasions when I have had to install or upgrade packages on a system. A typical scenario would be, when installing a new package, I would quickly realise that this package required a whole bunch of other packages. Once those are installed, then guess what, I was missing their package dependencies as well, turning a simple installation into a nightmare. Welcome to dependency hell.

What is a Dependency

A dependency is a piece of information in a software package that describes which other packages it requires to function correctly. Many packages require the OS's system libraries as they provide common services that just about every program uses (filesystem, network, memory etc). For example, network applications typically depend on lower-level networking libraries provided by the operating system. The principle behind package dependencies is to share software, allowing software developers to write and maintain less code at a higher quality. Operating systems have thousands of packages. In the world of virtualization and cloud computing, it is becoming imperative to strip down the number of operating system packages to just the required packages to run a particular application. This process, known as JeOS (pronounced "juice") standing for "Just Enough Operating System" is a very painful manual process. So much so that many operating system vendors now supply a core operating system ISO with the minimum set of packages required to boot the system. The fun then begins as you manually install only the packages (and their dependencies) required to run your application.

Calculating Package Dependencies Automatically

One of the primary goals of the UForge platform was to avoid dependency hell when creating custom stacks (known as server or appliance templates). It was also important not to use core ISO images as the base of generating custom stacks as these are opaque, but to expose all the operating system packages in your template. Each appliance template has an os profile. This os profile contains all the operating system packages you have chosen. To help you get started, you can either choose from one of several standard os profiles (choosing the "bottom-up" approach) or use the smallest standard os profile available (choosing the "top-down" approach). You can then complement this package list by searching for other packages you require from the os distribution or upload and add any custom native packages (via "My Software").


So far you have not had to worry about package dependencies. You only need to add the packages you know you require to run your application (i.e. the first level dependencies your application requires).


Package dependency checking occurs when you generate a new image. During the first phase of generation, UForge calculates automatically all the dependencies of each package in the os profile as well as any packages contained elsewhere in your custom stack (custom software in "My Software" and "Projects"). All missing packages are automatically added to your os profile. For each package added, this package's dependencies are also checked. This process continues until all the dependencies have been met. The end result is a complete dependency tree of all the packages you require to run your application. What normally may take hours or days to do manually, only takes a few minutes.

Under The Hood

Each package has meta-data on what the package requires (that is, what the package depends on) and what it provides in terms of functionality. This meta-data varies on the package type (RPM, DEB etc). For example: RPM:

  • Provides - one or more libraries or services this package provides
  • Requires - one or more packages required for this package to run correctly
  • Conflicts - one or more packages this package conflicts with (the other packages cannot be installed if this package is installed)
  • Obsoletes - this package supersedes another (can be used for package renaming)


  • Provides - one or more libraries or services this package provides
  • Requires - one or more packages required for this package to run correctly
  • Conflicts - one or more packages this package conflicts with (the other packages cannot be installed if this package is installed)
  • Obsoletes - this package supersedes another (can be used for package renaming)
  • Recommends - one or more packages that is recommended to be installed (optional)
  • Suggests - one or more packages that is recommended to be installed (optional)

UForge works with repositories. These repositories can be official operating system mirrors or private repositories. Other repositories including EPEL can also be handled by UForge. For each package in the repository, UForge uses the meta-data to calculate the dependencies in the os profile of your appliance template. The dependency calculation is done using a specific moment in time. This date is stored in your appliance (Appliance object, attribute: lastPkgUpdate). When creating a new appliance, the "lastPkgUpdate" date is the same date as the created time. Chosen package versions and dependencies are calculated by ensuring that they are equal to or less than the "lastPkgUpdate". Let's take an example. Imagine you create a new appliance on June 17th 2013, 17:00 GMT+1, and you choose package A, B and C in the os profile. Note that packages A, B and C may have more than one version (updates added to the repository due to bug fixing and or new features). The versions displayed for A, B and C will be dates of each of these packages closest (but inferior) to the "lastPkgUpdate".


In this case: package A v1.3, B 7.2, and C 3.2 is chosen. All dependencies for A, B and C will be calculated based on these versions using the package meta-data existing in UForge.

Wait A Minute, What About New Updates ?

As you probably know, packages evolve as bugs are fixed and new features are added. These new packages become available in the operating system repository. UForge uses an internal mechanism to check for any new package update available in the repository, and, if found, adds the meta-data of this package to its own database. Using this process, UForge builds a history of the operating system, as it keeps references to the old packages that are being replaced by the update. These updates do not get taken into account for your current appliance when generating a new image. UForge ensures the same package versions are used regardless of when you generate your image, the same image is generated time after time. This is due to always using the "lastPkgUpdate" timestamp of the appliance in question. Ok great, but what if I actually wanted to include these updates in my next generation? Well, it's a simple matter of updating the "lastPkgUpdate" of the appliance. UForge actually provides this update information for you. It knows the "lastPkgUpdate" of each of your appliances, as well as the list of packages in your os profile and therefore calculates whether or not any new updates are available.


In this case, UForge will notify you that three updates are available. Note, that for package B even if there is an intermediary package (version 7.3), only the last one is taken into account. UForge provides a way for you to see the evolution of package updates in the os profile. Clicking on the "update" button for a particular template produces a time graph of all the updates for the os package list through time. This allows you decide where to set the "lastPkgUpdate" to. By changing the "lastPkgUpdate" you can run a simulation that will describe which packages will be updated giving the current and new version of each package impacted.


By calculating package dependencies in this way, there is an interesting side-effect. Not only can you update (roll-forward) your packages, but you can generate an image from packages that were delivered in the past (roll-back). This is as simple as setting "lastPkgUpdate" to an earlier date. This is neat, as you don't necessarily need to always take the bleeding-edge latest updates of an operating system. This also goes a way forward to helping solve "destructive upgrades".

Destructive Upgrades

When you perform an upgrade of a package on a live system, the package manager will overwrite the files that are currently on your system with the files provided by the new package update. This works perfectly when you assume that the package you are replacing is backward-compatible. The problem is that it is extremely difficult to ensure this when delivering a new package version. Let's imagine that you wish to upgrade a package that depends on a newer version of php. When you upgrade, you will also upgrade the current version of php with the new one. If the php package is not completely backward-compatible then other applications that relied on the old php package may break. This is known as destructive upgrades. Once you have done a destructive upgrade, it is:

"...hard to undo, or roll back, an upgrade. Unless you or your package manager makes a backup of all the files that got replaced, you cannot easily undo an upgrade. Finally, while the package manager is busy overwriting all the files that belong to a package, your system is temporarily in an inconsistent state in which a package may or may not work properly. Hit the power switch on your computer halfway through your next OS upgrade and see if the system will still boot properly!" -- Pjotr Prins (Nix fixes dependency hell on all Linux distributions)

With the package "time machine", you can test whether you will have a destructive upgrade by simulating the upgrade, generating the image and testing it, prior to upgrading your production systems. Using UForge, you can also determine which packages will be updated and to which versions.

Sticky Fingers

Being able to roll-forward or roll-back the packages is all well and good, but what if we wanted to force a particular version of a package to be part of the generated image? Due to the current package version calculation being based on a particular date (the lastPkgUpdate) it is impossible to specify a particular package version to be part of the generation, as depending upon the build date of the package, potentially an earlier or more up to date version of the package may be chosen instead. To get around this issue, UForge provides a mechanism to enforce a particular package version. This is known as making a package "sticky".


In the os profile, by clicking on the "sticky" button, a list of all the versions of the package is displayed, allowing you to choose the version you require. Once chosen, this package becomes sticky. During image generation, this package version is chosen regardless of the current "lastPkgUpdate". All the package dependencies of this package are also calculated.


A simple click on the "sticky" package will make the package to become "unsticky", and the package version will be calculated as normal. To summarize, UForge provides powerful package dependency checking to create a JeOS appliance template with little to no manual effort - helping you to avoid dependency hell and ensure you will never be your own grandpa (or sister for that matter).

Classified in : Technology, Tutorial - Tags : UForge, Appliance, Template, Package, Package Dependency, Dependencies, RPM, DEB, OS packages, OS profile, destructive upgrades, live update - no comments

Setting the Status of Collaboration Workspace Members

Written by Elaine Muus le 19 june 2013

Once a user has joined your workspace, you (or another workspace administrator) can modify their status. By default, when users accept your invitation and join your workspace they will be collaborators.

Members of a Workspace are either:

  • Guest: A guest can read and post to the activity stream, and import templates into their private appliance library.
  • Collaborator: The collaborator has the same rights as the Guest, but can also share templates.
  • Administrator: This is generally the user who has created the workspace. There can be several administrators in a workspace. In addition to the basic rights of the collaborator, the administrator can invite members and is able to delete a Workspace. 

To modify the status of a member:

  1. Click on the drop-down menu next to the member's name.
  2. Select the new status.

Classified in : Tutorial, Tip - Tags : uforge, template, appliance, appliance template, collaboration, workspace - no comments

page 1 of 2 next