Manage Changing/Dynamic IP Address in Stackato


How To Manage Changing/Dynamic IP Address in Stackato


Applies to: Stackato 1.x

One of the issues with managing a portable Stackato system (e.g. a micro cloud) is dealing with having your IP address change as you move environments.

If you use a NAT-ed setup (such as with VMware Fusion), this shouldn't happen, but you may desire to move to bridged to share your micro cloud with others on the same network.

There are many services running on Stackato that are sensitive to the current IP address. When the IP address changes, you will want to run the following commands to ensure everything continues to work as expected.

Symptoms of modified IP address without reconfiguration include services not being created successfully, or the file system service hanging when trying to start your application runtime. The way to diagnose a changed IP address is to run the following as the stackato on the server:

  % grep host ~/stackato/etc/vcap/*.yml

where you should see an IP address that does not correspond to that reported by

  % ifconfig eth0

To reconfigure your system if the IP address has changed and you are running a micro-cloud:

  1. This step is not necessary if you just rebooted and have obtained a new IP address from the new network. If the machine is already running and you want to force an update of the IP address (say you have moved networks and are running a Bridged Stackato), run
      % sudo /etc/init.d/networking restart
    You will be asked for the stackato user password. Following this, you should see ifconfig eth0 has obtained a new, pingable IP address. If this does not happen, there may be an error with DHCP in your setup (e.g. locked to only known MAC addresses). Contact the local network administrator to get access to that network.
  2. Stop the current Stackato server to make the rest of the changes
      % stackato-admin stop
  3. After your IP address has changed, run
      % stackato-admin reconfigure
    This will update the config files with the current IP address.
  4. If your server had running data/msg services (mysql, fs, redis, etc.), you must run
      % stackato-admin update-services-ip [newip]
    This will update the cached controller database IP references for the existing applications.
  5. Now restart the Stackato system and you are ready to go.
      % stackato-admin restart

Use PHP Sessions in Stackato VM


How to handle PHP sessions in Stackato VM


Applies to: Stackato 1.x, 2.x

One of the issues with managing a custom PHP application with multiple instances in Stackato is dealing with user sessions.

Because of Stackato's architecture, a user of your site may not access the same server that started their session for each subsequent HTTP request. Based on traffic at any given moment, the router in Stackato 1.2.6 will direct requests to any DEA associated with your app. This will be improved in a new version of the router.

A simple solution is to store the user session in a shared location on the persistent file system. If your custom PHP application stores sessions in a database, you do not have to worry about this issue.

1. Add a new filesystem service in stackato.yml file:

           session-fs: filesystem

2. Override the default location for storing session variables by inserting this before the session_start() function call. This is usually located at the top of most PHP files.

        ini_set("session.save_path", "/app/fs/session-fs");

Unfortunately, you can not set this inside php.ini in Stackato.

Set Static IP in Stackato


How do I set a static IP for my Stackato VM


In Stackato 2.4, you can use the command "kato op static_ip" to easily set static IP in Stackato. (Strongly Recommended)

In versions prior to Stackato 2.4, it's fairly simple to set a static IP address. The main file you will need to edit is:


Look for the line that starts with 'eth0' and modify it so it looks similar to the following (modify for your network settings where appropriate)

auto eth0
iface eth0 inet static

We also use resolvconf to manage DNSmasq settings for the LXC containers so be sure to also edit /etc/resolvconf/resolv.conf.d/base and add your DNS servers there, example:

search     <your top level domain (i.e: '')>

Then restart the networking:

sudo /etc/init.d/resolvconf restart
sudo /etc/init.d/networking restart

Configuring your application to use the persistent file system


How to configuring a application to use the persistent file system in stackato?


Applies to: Stackato 1.x, 2.x

A persistent file system service allows apps to do the following:

1. Share files across multiple instances of an app
2. Store files that persist if an app is removed (providing the service is not deleted) or if the server is restarted.

Below we will go through how we customized our WordPress installation to use the persistent file system. Before you begin, find out where all the user generated contents are saved. In WordPress, they are stored in wp-content folder.

Therefore we add the following to our stackato.yml::

  fs-wp: filesystem

    # create wp-content in the shared filesystem
    - mkdir -p "$STACKATO_FILESYSTEM"/wp-content 

    # migrate existing wp-content data into the shared filesystem
    - mv wp-content/* "$STACKATO_FILESYSTEM"/wp-content
    # remove unused wp-content directories
    - rm -rf wp-content
    # link to wp-content folder in the shared filesystem
    - ln -s "$STACKATO_FILESYSTEM"/wp-content wp-content

That's all! You may have to make modifications to this general approach if your application requires stores user generated content in more than one location.

Contents of cumulative-patch-1 for 3.6.0


What fixes were included in 3.6.0 cumulative-patch-1?


This patch fixes the following issues:

-Minor issue with authentication component failing to re-advertise itself if it crashed for a length of time
-Issue with importing data from previous version if the import included admin buildpacks
-Removes requirement to authenticate newly attached DEAs with every existing DEA. Also removes this requirement from restarting the DEA role or restarting the DEA itself.
-Allows specifying source using https for custom appstore URLs in the web console.

Contents of Batch Patch-23092014-1 and Batch Patch-24092014-2 - 3.4.1


What fixes were included in 3.4.1 batch patch-23092014-1, and patch-24092014-2?


These patches fix the following issues:

- API performance enhancements
- Bug deploying apps
- Bug deleting deployed apps
- Option for LDAP users to be assigned to dynamically generated space following their username. Users will be placed within personal organization and space with a configurable quota

- Typo `kato report --cluster`
- Bug OEM white label console customizations
- Bug deleting users from orgs
- Bug viewing applications

Kato patch external hosts


I need to manually whitelist hosts in my corporate proxy. What hosts does kato patch need to access?


The hosts that kato patch needs to access may vary with local configuration, and may change depending on changes to 3rd party services such as

We recently audited kato-patch and found it accesses the following hosts:

How do I authenticate with Stackato 3.x?


I'm writing a script that interacts with Stackato. How do I get an authorization token?


In this example, let's assume your Stackato host is and your Username/Password are JamesF/securepass

Issue an HTTP POST to the aok endpoint of your Stackato system. This will usually be similar to the api endpoint, but begin with "aok", something like "".

The POST request should contain an AUTHORIZATION header with a value of "Basic Y2Y6" and the parameters should be username, password and a parameter "grant_type" with a value of "password":


Thus, here is an example request using cURL:

$ curl -k -H 'AUTHORIZATION: Basic Y2Y6' -d "username=JamesF&password=securepass&grant_type=password"

From this request you should receive an access token which can then be used in an Authorization header for future REST requests. For example, to then get Stackato usage as an admin, you might issue:

$ curl -k -H 'Authorization: bearer <access_token>'

Changing Stackato >= 3.2.1 default rebranding values


How do I rebrand my Stackato instance earlier in the setup process? How do I change the defaults?


It's possible to change the look and feel of your Stackato console right on the "Settings" creen, but this must be done after the first user is setup.

We've issued a patch for Stackato 3.2.1 which enables you to change the default look and feel values, and it also allows you to customize things prior to the first user setup.

To do this, install the patch "console-theming" via kato patch. After applying it, you may put the following files in your /s/static directory:

console_eula_template.ejs (EULA template)
console_support_template.ejs (Support page template)
console_welcome_template.ejs (Welcome page template)
console_settings.json (various settings as below):

     "product_name": "Stackato",
     "company_name": "ActiveState Software",
     "vendor_version": "3.2",
     "default_locale": "en",
     "product_logo_favicon_url": "img/stackato_logo_favicon.png",
     "product_logo_header_url": "img/stackato_logo_header.png",
     "product_logo_footer_url": "img/stackato_logo_footer.png",
     "background_color": "#ffffff",
     "style": "",
     "external_docs_url": "",
     "use_local_docs": "false",

If you have any questions contact Stackato support.

My app fails to start, it seems to timeout


Why is my app failing to start?


It could be that something is timing out. There are three timeout settings to watch for:

Client timeout

$ stackato push --timeout 2m

This timeout sets how long the client will wait for the application to start before giving up and returning an error. The app may still start successfully. The default value is 2 minutes. See "stackato help push" for more details.

Staging timeout

$ kato config set dea_ng staging/max_staging_duration 900

This timeout sets when the staging will time out. The default is 900 seconds. Changing this value requires a restart of your DEA nodes.

Health Manager timeout

$ kato config set dea_ng default_health_check_timeout 60

This timeout sets how long the health manager will wait for the fully staged app to start. The default is 60 seconds. Changing this value requires a restart of your DEA nodes.

Set Health Manager Timeout

$ kato config set cloud_controller_ng maximum_health_check_timeout 180

This sets the maximum timeout. The default is 180 seconds. Changing this value require a restart of your controller nodes.