Saturday, June 25, 2016

Security Release: Node.js 4.4.6

The Node.js project has just released a new version that fixes a vulnerability under certain conditions: V8 may improperly expand memory allocations in the Zone::New function. This is related to the CVE-2016-1669.

Read more about the security issue on the Node.js blog.

We want to let Bitnami users know that Node.js 4.4.6 installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your Node.js applications to the latest version.

If you work with containers, Stacksmith already has the latest versions of Node.js available.

Do you have questions about Bitnami Node.js or the security issues? Please post to our community forum and we will be happy to help.

Security Release: PHP 5.5.37

A PHP security issue that affects previous versions of PHP was recently announced. A signedness vulnerability (CVE-2015-8874) is present that allows remote attackers to cause a denial of service via a crafter imagefilltoborder call. 

We want to let Bitnami users know that all MAMP, LAMP, WAMP Stacks installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your PHP stacks to the latest version.

If you work with containers, Stacksmith already has the latest versions of PHP available.

Do you have questions about Bitnami PHP stacks or the security issues? Please post to our community forum and we will be happy to help.

Sunday, June 19, 2016

Introducing Bitnami Development Containers

Folks who have known me for a while, know that I love to make things easy for developers. From my days as a usability engineer on the Visual Studio team, to my pet projects, to my tutorials and samples, making programming easy and fun has been a theme of my work since 1998.

Now at Bitnami, I am happy to be working with a team who is as excited about this as I am. We have started a project that takes advantage of Docker to make developing with whatever framework you choose easy and fun. We call this project “Bitnami Development Containers.” This project is an extension of the development process that we have created for our own internal development. It only made sense to share our experience with developers everywhere.

We are in the beginning phase of the public part this project, and we are practicing the “release early and often” strategy, so let’s see what people think.

The basic idea behind the project is that if you have Docker enabled on your development machine, trying a framework should be as simple as what I affectionately call, “curling up”. That means that all you need to do is curl (download) a docker-compose file, and then run it with the docker-compose up command. After those two steps, and only those two steps, you can see your app running and start coding. It is that easy.

To accomplish this, we had to do a couple of things:
  1. First, we created custom containers that are meant specifically for developing with the frameworks of interest. These containers have an entry point that is designed to get developers going with zero configuration. We take care of all the configuration and any code generation necessary to get started.
  2. We include any necessary infrastructure and orchestrate them together using a simple docker-compose file. That means that if your framework of choice requires a database, maybe a specific database configured in a specific way, you don’t have to worry. We took care of all the work to set it up that way. You can just start coding.
So, for any framework that we support, with a development container, for example, if I wanted to write some good old Ruby on Rails code, I would just do this:

$ mkdir myrailsapp
$ cd myrailsapp
$ curl -L "" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Rails welcome page. 

The exact same process works for Express:

$ mkdir express
$ cd express
$ curl -L "" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Express welcome page. It’s always the same simple steps.

One important thing to note is that the containers are designed to work as immutable infrastructure. By that, I mean, none of the code that is generated or that you write is on the container. Rather, it is also mounted in a volume. That is important because it means that the containers support easy reproducibility. So, if you change some code, you can check in that code, and someone else can check it out, and docker-compose up just works with the existing code.

Ok, let’s just try it. I heard about Laravel. My team says it's pretty cool, but I never really knew what it was. So, I am going to using Bitnami’s Development Container to quickly get started with it.

First thing, I will create a directory for the application that I will write. Then I will download the docker-compose file into that dir. Again, the same simple steps, “curl up.”

$ mkdir laravel
$ cd laravel
$ curl -L "" > docker-compose.yml

Screen Shot 2016-06-19 at 11.19.40 AM.png

That went fast, so let’s take a look:

$ cat docker-compose.yml

Screen Shot 2016-06-19 at 11.20.18 AM.png

Ok, that is a nice and simple file. I can see that I am going to get a copy of MariaDB along with it. That’s handy, since as far as I can tell, Laravel and MariaDB go together like peanut butter and jelly. Note also that the port is already mapped for me.

Finally, note that it mounts a volume called “./app”. This is very important and interesting. What this means is that the application code that is generated and that I will modify is NOT in the container, but rather right on my desktop. This is how we achieve the immutability I mentioned above. This way, besides being easy to manage with source control, it is also trivially easy to edit with my desktop editor.

So, I curled, now I up. Of course, make sure that Docker is running before you do this:

$ docker-compose up

Screen Shot 2016-06-19 at 11.22.34 AM.png

The first time I run this, Docker will download the images first. Then it will start the containers.

Screen Shot 2016-06-19 at 11.23.24 AM.png

Looks like the container is started. Let’s check out the app.

First, I’ll check the ip address of my Docker VM:

$ docker-machine ip

Screen Shot 2016-06-19 at 11.24.09 AM.png

Now that I have that, I can navigate to port 3000. Port 3000 is a typical port for development web servers to run on. I could also tell I needed to port 3000 from the docker-compose file.

Screen Shot 2016-06-19 at 11.25.08 AM.png

It works! Let’s pause for a moment and consider how cool this is. In a matter of minutes I went from having an empty Docker environment to having a running Laravel 5 app. And I’ve never used Laravel before.

Of course, the first thing I want to do is to change the default to prove to myself that I have some control over the content.

Because this is my first experience with Laravel and I know almost nothing about it, I will have to poke around a bit. I’ll just guess that the string displayed in the default web page will help me out, so I will start with a recursive grep.

$ grep "Laravel 5" -R ./

Screen Shot 2016-06-19 at 11.28.11 AM.png

That “welcome.blade.php” file looks like a promising start for making my first change. Keep in mind, I have never even written PHP code, much less Lavarel code. But, I love to learn by doing, so I am just going to dive in with my editor and see if I can make a change.

Screen Shot 2016-06-19 at 11.30.40 AM.png

And …

Screen Shot 2016-06-19 at 11.31.57 AM.png

Yup! It’s that easy. Within minutes, I have made a change!

Let’s take another look at my Mac’s directory:

Screen Shot 2016-06-19 at 11.33.18 AM.png

As I mentioned before, you can see that the application code is on my development machine, NOT in the container. Furthermore, the docker-compose.yml file that sets up the development environment is in the same directory. That means I can easily commit this directory and share it. Anyone could check it out from source control, and run $ docker-compose up, and end up with the exact same environment. So, a team of developers could easily use the Bitnami Development Containers to collaborate on projects, and easily stay in sync with both the development environment and the code.

Today we have 3 development frameworks ready. Rails, Express, and Laravel, with more on the way. Please try them out and give us feedback. And please let us know what other frameworks you think we should do next! You can reach us at

- Rick Spencer, Bitnami VP of Engineering

Thursday, June 16, 2016

Security Release: Drupal 7 and 8

The Drupal project released a new update that fixes several security vulnerabilities. We strongly recommend upgrading your existing Drupal 7 and 8 sites.

Information regarding the additional changes is available in the official security advisory. In response to the new Drupal version, we have released the following: Bitnami Drupal 7 and 8 installers, virtual machines, and cloud images.

Two notable issues include:
  1. A vulnerability exists in the User module, where if some specific contributed or custom code triggers a rebuild of the user profile form, a registered user can be granted all user roles on the site. This would typically result in the user gaining administrative access.
  2. An access bypass vulnerabilty exists in the Views module, where users without the "View content count" permission can see the number of hits collected by the Statistic module for results in the view.
Our new releases fix the known security issues. There are no new features or non-security related bug fixes in these releases.

If you have questions about Bitnami Drupal or these security issues, please post to our community forum and we will be happy to help you.

Automated Container Delivery Using Stacksmith with GitHub

When developing with Docker containers, updates to an application’s stack or environment are rolled out by stopping outdated containers and replacing them with an updated container image. Docker is a popular toolchain for developing applications in containers that makes it incredibly easy to conduct these container image updates. However, the process of deploying updated container images is still a repetitive series of manual steps that can be mechanized. Bitnami built Stacksmith to automate this process.

Stacksmith automates the deployment of container images by maintaining a base Dockerfile, and by keeping each stack up-to-date against version updates and security vulnerabilities. Conveniently, Stacksmith integrates with GitHub so that when there’s an update to an application’s stack, a developer simply has to merge an automatically generated pull request from Stacksmith that contains the updated container image.

This post walks through how you can use Stacksmith with your application on GitHub to provide continuous delivery of your application container images.

Before you get started

This tutorial assumes you have Git, Docker (1.10+) and Docker Compose (1.6+) installed, and that you have some familiarity with these tools.

For this tutorial, we we will run Scotch’s Node Todo App on containers. The Node Todo App is a small, multi-tier and open source application that consists of an ExpressJS application server which connects to a MongoDB server for persistence. This architecture is referred to as a MEAN stack.

Once you confirm that you have the correct tools (Git/Docker/Docker Compose) installed, you are ready to get started by forking the Node Todo App repo on GitHub.

Create Your first Stacksmith Node.js stack

Stacksmith uses stacks to define the environments that make up your Dockerfiles. A stack is comprised of one or two components, most typically a runtime, as well as the base operating system. To run our Node Todo App on containers, we will create a stack that contains the Node.js runtime on top of Stacksmith’s Debian base:

On the Stacksmith homepage, select Node in the dropdown and click on ‘Create Stack’ to start configuring your stack.

Next, follow the instructions to connect your GitHub account to Stacksmith, and select your forked repository, the Node Todo App, in the dropdown list. By connecting your GitHub account with your Bitnami account, Stacksmith will be able to automatically add a Dockerfile to your repository that is configured based on your stack specifications. When there is an update to your stack, Stacksmith will automatically submit a pull request to your GitHub repository keep your application’s container image up-to-date.

Now select Node.js in the components dropdown. This will be the main component in our stack. We suggest that you select ‘6.x’ in the version dropdown, to ensure you only automatically update to security and patch fixes.

Once your components are entered, Stacksmith will prompt you to specify the kind of Dockerfile you need. In this case, the Node Todo App is an ExpressJS application, so you will select ExpressJS in the dropdown to get a Dockerfile that is most suited to running your application.

To complete the stack creation process, leave the base operating system as Debian, and click the ‘Create stack’ button to go ahead and create your stack. The new stack that you created will show up in the ‘Your Stacks’ page with the same name as your GitHub repository.

Merging in your new Dockerfile

To merge your Dockerfile into your forked repository, visit your repository on GitHub by clicking the link at the bottom of your “Stack Info” screen. You will see that Stacksmith automatically opened a pull request to add your new Dockerfile to the repository. Accept the change which adds the Dockerfile to your repository by clicking on the green “Merge pull request” button.

Building and running your application container

Cloning the GitHub repository

Now that your application code has a Dockerfile checked in, you should try it out by running the application. First, clone the repository from GitHub into a directory on your local machine.

> git clone<GITHUB-USERNAME>/node-todo.git
> cd node-todo/

Remember to replace the clone URL with your GitHub repository’s remote URL.

Setting up your Docker Compose file

Docker Compose is a tool that makes it easier to run multi-tiered applications in containers. Using Compose, a developer is able to define each service needed to run their application in a container by creating YAML configuration file. A developer is then able to use Compose to manage the group of containers, specifically by bringing them up and tearing them down as necessary.

Your repository already has a Dockerfile that can be used to run the ExpressJS server, so you can configure Compose to build the image using this Dockerfile with the following directive:

 build: .
- 3000:8080
We suggest configuring a port mapping to access the web server from outside the container.

For MongoDB, you will need to reference the Bitnami MongoDB Docker image that can be pulled directly from Docker Hub. This container image will come with everything you need to run a MongoDB server out of the box.

 image: bitnami/mongodb
The full docker-compose.yml file should look like this:
version: “2”
   build: .
 - 3000:8080
restart: always
     - mongodb
   image: bitnami/mongodb

Building and running your application using Docker Compose

Now that we’ve setup our Compose file, we can go ahead and run the application. To start all the services, run:
> docker-compose up
Oops, it failed! Check the logs to see what went wrong. The issue seems to be that your ExpressJS container is expecting to run the application using the npm start command, however, the Node Todo App hasn’t been configured to specify the correct start script to run in the package.json. To fix the issue, you can modify your package.json file to run the server.js script when using npm start, or you can more easily change the container startup command in the Stacksmith generated Dockerfile.

We suggest the latter option in order to demonstrate how you can go about customizing the Dockerfile generated by Stacksmith. In your Dockerfile, change the CMD line from:

CMD [“npm”, “start”]


CMD [“node”, “server.js”]

If you rebuild and run the application again, you will see that the Node Todo App crashes because it is unable to connect to MongoDB. By default, the Node Todo App is configured to connect to MongoDB on localhost. The host needs to be changed to use the Service Discovery on the Docker Network that Compose sets up for us. To do this, change config/database.js to:

module.exports = {
   remoteUrl : 'mongodb://',
   localUrl: 'mongodb://mongodb/meanstacktutorials'

Now run docker-compose up --build and you will see that both containers start successfully, and you should try to access the Node Todo App in your browser at DOCKER_IP:3000, replacing DOCKER_IP with the IP address of your Docker Machine (if running in a VM), or localhost if running locally.

To find out the IP address of your Docker Machine instance, you can run the following command:

> docker-machine ip $(docker-machine active)

Committing and pushing your changes to GitHub

Now that you have made changes to the Dockerfile to run your container, you should commit and push your changes to GitHub.

After pushing the changes to GitHub, visit Stacksmith to see that your changes have been tracked correctly. This will ensure that when there is an update for your stack, your changes will be kept when you regenerate the Dockerfile.

Automating your container builds using Docker Hub Automated Build

To have your container continuously built when you update your application code, or when there is an update in your stack, you can setup an Automated Build repository in Docker Hub. For documentation on setting this up with your repository, visit the Docker Docs:

Receiving a stack update from Stacksmith

At this point you should have the following setup:
  1. Stack in Stacksmith that defines your application’s runtime requirements.
  2. Dockerfile generated by Stacksmith for building your application container.
  3. Connection to Docker Hub automated builds that automatically build and push your container to the Docker Hub Registry when you make changes in your repository.

What happens when a new version of Node.js is released? Or what happens when there is a security patch available for either Node.js or one of the packages in the Debian base image? In the container world the existing procedure for dealing with this scenario is to rebuild the whole application container on top of the new, updated and secure stack. Stacksmith introduces a new and easier way to deal with updates to your stack.

For example, it may turn out for you that within days or weeks of creating your stack, an update to Node.js may become available. When an update is released, Stacksmith will notify you via email, Slack, or a custom webhook.

For me, several days after I created my Node Todo App stack I received an email notification that I can update to Node.js 6.2.1. Below are the steps I followed to regenerate my Dockerfile:

Going back to Stacksmith to view my stack, I can see that I am currently using 6.2.0 and I can regenerate my Dockerfile to update to 6.2.1.
I click the “Regenerate” button to instruct Stacksmith to create a new stack with the updated version.
Next, I head over to my forked repository on GitHub where I can see that Stacksmith also created a new pull request with an update to the Dockerfile. The Stacksmith Bot leaves my Dockerfile modifications unchanged, and simply updates the referenced version of Node.js and the metadata about the new stack.

After I merge the pull request from Stacksmith, my Docker Hub integration kicks off an automated build using the new Dockerfile. Then after a few moments, I have a new Docker image for running my Node Todo App on top of the latest Node.js version. I can then reference the new Docker image in the Compose file, or a Kubernetes manifest and re-deploy my application.

If I want a more complete workflow for a production use-case, I can automate the deployment with an existing CI/CD pipeline that will kick-off after the merge of the Stacksmith pull request.

That’s all! If you are using Stacksmith to run your applications in development or production, please let us know! We’re eager to hear how we can improve Stacksmith for you.

Watch a demo of our Stacksmith and GitHub integration:

Wednesday, May 18, 2016

Security Release: Magento 2.0.6

The Magento project has released a new update that fixes several security vulnerabilities. A few of the notable fixes include:
  • APPSEC1420: Magento no longer permits an unauthenticated user to remotely execute code on the server through APIs.
  • APPSEC1421: The Magento installation code is no longer accessible once the installation process has completed.
  • APPSEC1422: Magento no longer allows authenticated customers to change other customers' account information using either SOAP or REST calls.

We highly recommend upgrading your existing Magento Community Edition 2.0 sites. For more information about the security issues fixed with this recently released update, please check out Magento's Security Center.

We have released Bitnami Magento 2.0.6 installersvirtual machines and cloud images that fix the security issues.

If you already have a running version of Bitnami Magento, you can upgrade the application by following the detailed steps on our wiki page:

Do you have additional questions about Bitnami Magento? Post to our community forum, and we will be happy to help you.

Wednesday, May 11, 2016

Security Release: Gitlab 8.7.4

The Gitlab project released a new update that contains security fixes, including one for an XSS vulnerability via faulty URI scheme sanitization, and we strongly recommend that all GitLab installations be upgraded to the new version immediately.

We released new versions of Bitnami Gitlab 8.7.4 installers, virtual machines and cloud images that fix the security issues.

Additional information regarding XSS vulnerability via faulty URI scheme sanitization:

The URI scheme of user-supplied links was not being properly sanitized. Please see the GitHub issue for more details. Additional information regarding the additional changes is available in the official security advisory.

Do you have questions about Bitnami Gitlab or the security issue? Please post to our community forum, and we will be happy to help you.

PHP Security Issue: libgd CVE-2016-3074

A PHP security issue that affects previous versions of PHP was recently announced. A signedness vulnerability (CVE-2016-3074) exists in libgd 2.1.1, which may result in a heap overflow when processing compressed gd2 data.

[Update: 2016/05/11]

We want to let you know that the Bitnami Team worked on updating all the native installers, virtual machines and the cloud providers images of all the affected applications and all of them are already available. We will continue working on updating the Bitnami Cloud Hosting base image.

If for any reason you are not able to update your application, follow the instructions below:

  • Disable the following PHP functions (imagecreatefromgd2, imagecreatefromgd2part, imagegd2) in the php.ini file.
disable_functions = imagecreatefromgd2, imagecreatefromgd2part, imagegd2

  • In Windows systems, the gd extension can be disabled easily. Comment out this line in the php.ini file:

More information about the fixed version can be found on the GD Graphics GitHub page:

Do you have questions about the security issue? Post to our community forum, and we will be happy to help you.

[Update: 2016/05/12]

The Bitnami Cloud Hosting base image was released today so all of the new servers launched using our platform will include the latest security update.

Tuesday, May 10, 2016

Security Release: WordPress 4.5.2

The WordPress project has just released a new version due to two security vulnerabilities:

  • WordPress versions 4.5.1 and earlier are affected by a SOME vulnerability through Plupload, the third-party library WordPress uses for uploading files. 
  • WordPress versions 4.2 through 4.5.1 are vulnerable to reflected XSS using specially crafted URIs through MediaElement.js, the third-party library used for media players.

The WordPress team strongly encourages their users to update their site to version 4.5.2. For more details please check the official announcement. Bitnami users who are already running a version of Bitnami WordPress will not be affected, as their application will be automatically updated. If you are using Bitnami WordPress, you can confirm that the update has been done by checking the version from your admin panel.

We have released Bitnami WordPress 4.5.2 (and Multisite version) installers, virtual machines and cloud images that fix these issues.

Do you have questions about Bitnami WordPress or the security issue? Post to our community forum, and we will be happy to help you.

WordPress Stack with PHP7

WordPress announced a few months ago that it is fully compatible with the latest version of the PHP framework, PHP7. Nowadays most of the popular plugins are already compatible and WordPress has also published a developer guide about how to update WordPress plugins to support PHP7.

Here, at Bitnami, we baked a new WordPress stack based on PHP7 to help you run the latest, shiniest and fastest software. WordPress + PHP7 is faster than ever before.

But that's not all. If you still want to run WordPress on PHP 5.6, now you can. Use the Bitnami LAMP Stack and install the WordPress module on it, or use the WordPress Legacy Stack. The WordPress Legacy Stack will have the same and latest version of WordPress but will ship with PHP 5.6

Both new WordPress versions are available as installers, virtual machines, and cloud images on the Bitnami WordPress Stack page.

If you have questions about Bitnami WordPress or the advantages of using PHP7 over PHP5.6, please post to our community forum, and we will be happy to help you.