Thursday, January 18, 2018

Security Release: GitLab 10.3.4

The GitLab project has released a new update that contains several security fixes, including two that prevent remote code execution. We recommend that all GitLab installations be upgraded to GitLab's new version (GitLab 10.3.4) immediately.

We have released new versions of Bitnami GitLab 10.3.4 virtual machines and cloud images that fix the following security issues along with others:

  • Remote Code Execution Vulnerability in GitLab Projects Import (CVE-2017-0915 and CVE-2018-3710): These allow an attacker to write files to arbitrary directories on the server, which in turn could result in remote code execution.
If you are unable to upgrade immediately, you can use the following workaround in your existing GitLab installation to fix this vulnerability:
  1. Go to the /admin/application_settings URL of your GitLab instance.
  2. Under "Import sources", uncheck the "GitLab export" checkbox.
  3. Click "Save".

  • GitLab CI Runner Can Read and Poison Cache of All Other Projects (CVE-2017-0918): No workaround currently available
  • Jupyter Notebook XSS (CVE-2017-0923): No workaround currently available
  • Sensitive Fields Exposed to Admins / Masters in the Services API (CVE-2017-0925): No workaround currently available

More information about these issues can be found in the official blog post. Apart from the workaround described above for the remote code execution vulnerability, there is currently no available workaround for the remaining vulnerabilities. Therefore, if you are running a GitLab instance with a version prior to 10.3.4, you will need to upgrade GitLab to the latest version by following this documentation (

Do you have questions about Bitnami GitLab or these security issues? Please post to our community forum, and we will be happy to help you.

Monday, January 15, 2018

Top 5 excuses for not migrating your applications to the cloud

Authored by Michael Murphy, Product Marketing Manager

Most companies see the writing on the wall regarding the fate of the traditional on-premises data center.  Aside from some specific use cases, there is broad agreement that the corporate data center’s days are limited. Cloud platforms have matured, and can now deliver the same infrastructure services and platform functions more efficiently, more cost effectively, and more flexibly in a public cloud or private cloud model.  They also support the latest development architectures, and are better suited to delivering applications and content to the myriad of devices in use today.

So why are so many companies still hosting legacy applications in a traditional data center?  In this article, I look into a few of the key reasons and try to separate fact from fiction.  Even if you haven’t articulated what’s holding you back, perhaps this discussion will encourage a closer look.  In identifying the reasons, perhaps you will rethink some of your own hesitation.

Lack of budget and / or available resources

Both totally valid reasons for planning the timing of your migration.  I would just encourage you to be realistic on both counts. Let’s look at cost first. It is important to start with concrete cost assumptions, not loose ‘I think…’ or ‘migrating costs roughly…’ estimates.  Many factors affect costs, like which approach you will take (re-architecting, rehosting etc.), and how the migration will be done (by your staff, or a SI or consultancy etc.).
Remember also that other cost benefits can be realized as a result of a migration, such as the costs associated with updating and maintaining applications after migration – these will also vary depending on the migration approach you take.  And be sure to compare these cost estimates and benefits of migrating to the expenditures and challenges you experience today by maintaining these applications in your data center.

Resource constraints can often be a bottleneck - often because much of your current IT staff’s time is consumed in managing the very applications and data center you are trying to reduce.  Depending on which migration approach you take, much of this IT time drain can be decreased after the migration.  So I would argue that in terms of resources, it is in your interest to make migration a priority so that you can remove this bottleneck as quickly as possible, freeing up future IT resources. 
And remember, not all of the migration approaches require specialized knowledge of the latest development frameworks or cloud platform characteristics.  It is possible to use the migration process as a way gain cloud knowledge and experience - at your pace, with existing resources.

There is comfort in the known

There is indeed comfort in the known.  Even when ‘the known’ is a process that is crazy, manual, not scalable, difficult to support, not optimized for today’s modes of consumption…should I go on?  Still, you know it, and you have a ‘system’ in place to manage, maintain, and update it, and on some level, this works, if imperfectly, for you.  Sometimes, we stay with the known because at least it is known.  And non-threatening.  We endure the difficulties because hey, that other option…who knows what that will be like?

Changing a process can seem daunting.  Making a decision, or in this case not making a decision, based on assumptions that haven’t been verified, is usually not a great strategy.  So, it's important to understand the basics – like what the change really involves, and what the risks and rewards are.  Finding this starting point can make all the difference – getting information from a trusted source, for example.  You can always start small, say with one not-so-critical application, and see what the experience and benefits look like.  Learning and adopting can be an incremental exercise, it doesn’t have to be ‘all-in’.  And let's be honest - the move to the cloud is not a fad, it is a shift.  And you will have to make that shift at some point...

You haven’t thought through maintenance

Are you assuming that the maintenance will be handled the same as now once you migrate?  It will not – or rather, it should not.  If you approach maintenance in the cloud as you do today in your data center, you will not only miss out on many of the cloud benefits, but also be setting yourself up for frustration.

Clouds are designed differently from data center.  You cannot view a cloud platform simply as a remote data center. There is a paradigm shift when you go to a cloud platform model, and significant benefits can be gained if you adjust your approach when you switch. 

It is sometimes explained in a ‘pets vs. cattle’ comparison.  In your data center, you establish a ‘relationship’ with the servers running your applications.  You name them, understand their idiosyncrasies, and repair them when they break down.  They are like pets.  In the cloud platform model, servers don’t have names they have numbers, and if one doesn’t function as planned it is replaced.  It is one of many cattle on a server farm.

It is important to understand the difference in these approaches, and understand that many of the maintenance difficulties you experience in your data center paradigm will disappear in the cloud platform paradigm.  If you don’t understand this difference and the positive implications it has for you, you may well be viewing your migration to a cloud platform with trepidation, as in ‘most of the problems I face today, but further away, less tangible, and less in my control’.   That is not an accurate portrayal.

You are intimidated – you don’t think you know enough about the cloud

Most of the companies still maintaining applications in their data center are not software development companies.  Nor are they necessarily global corporate entities that employ a robust IT staff.  More often than not, they are medium to large companies in industries like insurance, transportation, and manufacturing.  Many of them have limited IT resources, and are trying to focus on their core business.  They task IT to deliver applications and data so their workforce can be productive.

These IT folks may have limited exposure and experience with cloud platforms and technology.  If you have never built cloud images, or dealt with orchestration for the cloud, you might not know where to start.  This is totally understandable.

The good news is that not all migration solutions require specialized cloud knowledge and experience, or require those who don’t have it to engage consulting services expertise.  There are migration tools available that help you get your applications out of the legacy data center, gain cloud benefits, and also gain cloud experience in the process. 

You don’t want to re-architect your applications, yet ‘lighter touch’ options don’t meet your needs

Let’s take a look at the migration options.  

Re-architecting your applications is a significant undertaking that involves rewriting your application source code, using new frameworks and languages that are designed for the cloud platform you choose.  It will deliver the most comprehensive cloud benefits, but requires a lot of effort and development knowledge. 

Rehosting (‘lift and shift’) your application is a light touch option that does not require you to alter your source code.  With rehosting, you are essentially swapping out deployment infrastructure locations – you move your VM from the server in your data center and deploy it to the infrastructure of a cloud provider or in a cloud platform locally.  It requires some updating to configuration files and location pointers, but that is pretty straightforward.  But rehosting has a major drawback – while it does addresses your immediate day 0 issue by enabling you to migrate your application from the server in your data center to a cloud platform, it does little else.  It does nothing to alleviate the day 1 and beyond challenges of updating, rebuilding, and monitoring your application once it is migrated. 

Retiring and replacing your application with a similar SaaS offering is not really an application migration option, and it requires a different paradigm entirely.  It also forces you to make decisions about key functional issues, such as how you will deal with the legacy data currently in your application; what you will do about any customizations you have implemented (does the SaaS offering have the fields I need?); and what to do with any of the application integrations currently in place. 

There are also some replatforming options (sometimes referred to as ‘lift-tinker-and-shift’), but these options still require you to update the application source code itself.  Many companies do not want to do that.

So, of the available migration options, the only one that does not require you to edit or re-write your application source code is rehosting.  But with its limited benefits – you are on a cloud platform, yet unable to reap cloud benefits - rehosting is not an ideal solution for many companies.

A new option will be available soon

The good news is that a new self-service replatforming tool will soon be available from Bitnami. It empowers those with limited experience to take on the task of replatforming. It provides a clear, well documented step-by-step process, flexible templates to ensure applications get optimized for the chosen target platform, and powerful automation that simplifies the application build process. This transparent process not only lets you move at your own pace, but enables you to gain experience and even implement best practices. It is the tool that has been missing from the market.

It is also a light touch option that doesn’t require you to update your application code. And takes about the same effort as rehosting. Yet it delivers so much more: all the day 0 benefits of rehosting, but also significant day 1 and beyond automation and simplification benefits that makes packaging, deploying, and maintaining your applications much easier. All while helping you gain knowledge and cloud experience.

If you have been hesitant to get started with your application migration to date, I hope that the above discussion provided some valuable context on how to approach a migration, and what options are available. There is no time like the present. Let Bitnami empower your successful cloud migration.

The new replatforming tool from Bitnami will be available soon. If you are interested in finding out more, let us know at and we’ll be happy to schedule a demo.

Thursday, January 4, 2018

Migrating Your Applications to the Cloud - Replatforming to gain maximum benefits

Authored by Michael Murphy, Product Marketing Manager

Many companies still host and run legacy software and in-house applications in their on-premises data centers. (According to recent research only 5% of x86 workloads have been migrated to the cloud.) Supporting these applications can be a burdensome, manual, and time-consuming task.  It requires expertise to maintain the software itself as well as the infrastructure it is running on. In a time when there is a clear shift away from the corporate datacenter to public cloud infrastructure, and modern applications are being built and delivered to take advantage of distributed cloud architectures, smart businesses are planning and executing on a cloud migration strategy.

Cloud application migration comes in many forms and enterprises have been told for years that to truly realize cloud benefits, applications must be re-architected. But re-architecting takes a lot of work, and many companies find it difficult to resource or prioritize re-architecting (rewriting) their applications.  Aside from rewriting the applications, companies have been left to choose between abandoning them in favor of a SaaS offering, or rehosting (‘lift & shift’) them as simple VMs where possible.

Rehosting (lift & shift) can be appear to be an attractive option as a ‘light touch’ solution that doesn’t require you to revise or rewrite your application code.  And it does get your application out of the data center.  But that’s pretty much where the benefits end.  Remember, the difficulties of maintaining the data center infrastructure represent only half the challenge – the ‘day 0’ tasks.  The other challenges, the day 1 and beyond tasks, come with maintaining and updating the applications themselves.  Rehosting only addresses your ‘day 0’ issues.  In addition, this lift & shift approach offers little to no additional cloud benefit in the form of scalability or automation.

What if there was an application migration solution that filled the gap between the rigor of re- architecting your applications and the simplicity of rehosting?  A tool to automate packaging, deploying and maintaining your custom applications in the cloud that optimizes the application for the target cloud and simplifies ongoing maintenance and security...without requiring a rewrite?

Bitnami has been working on delivering exactly that!  A tool that leverages our expertise in packaging applications for the leading cloud providers, but can be leveraged externally by enterprises to simplify the migration of their applications to the cloud.  A tool that bridges the gap between rehosting and re-architecting, a category we refer to as replatforming.

Replatforming with Bitnami is also a light touch solution that does not require you to update your application code.  It requires about the same effort as rehosting, and delivers all the same day 0 benefits, but it also delivers day 1 and beyond automation and simplification benefits such as:

  • Automating the updating and application rebuild process
  • Tracking and managing build components and versions
  • Providing templates to optimize your application for the target platform
  • Using a single build process to create multiple target images
  • Monitoring the build components and alerting you when updates are available

All of the above remove a significant burden from your IT staff, freeing up time and simplifying the application updating process.  And it can all be done without source code modifications or specialized development skills or knowledge.

Sound Interesting? This new tool from Bitnami will be available soon!

Can’t wait? Ping us using the form at and we’ll be happy to schedule a demo.