Drupal Planet on Colan Schwartz on Cloud Architecture, Security, Privacy & Startups

Announcing Drubernetes v2: Moving from Bitnami to the Official MariaDB Operator

Wed, 22 Oct 2025 00:00:00 +0000

This article was originally published on the BackUpScale blog.

Why It Matters

For many open-source projects and small teams, Bitnami’s charts were the default starting point for running DBs and applications on Kubernetes. When a large vendor changes course, it sends ripples across the ecosystem; it can suddenly make basic infrastructure harder or more expensive to maintain. Drubernetes v2 ensures that Drupal deployments remain fully open, self-contained, and future-proof, regardless of corporate licensing shifts. Community-driven alternatives are essential to preserve innovation and accessibility.

Background: Why Drubernetes Needed a v2

When we first built Drubernetes, the goal was simple: make it easy for various organizations to deploy Drupal on Kubernetes using Terraform for infrastructure automation. Our stack relied heavily on community-maintained Helm charts (most notably Bitnami’s MariaDB chart) for reliability and ease of integration.

But the open-source ecosystem around Bitnami has shifted dramatically.

Bitnami’s Policy Shift: From Open Access to Paywall

Bitnami historically maintained one of the best collections of open Helm charts in the cloud-native space. These charts were widely used for MySQL, MariaDB, Redis, WordPress, and many others, often forming the foundation of production workloads for startups and open-source projects.

However, following VMware’s 2022 acquisition by Broadcom and its ensuing restructuring, Bitnami’s open chart repositories were deprecated, and support for their community versions effectively ended. As covered in Fastcode’s analysis, Broadcom’s pivot toward expensive subscription-only licensing has created a domino effect, shuttering long-standing open-source pipelines and forcing projects like ours to re-architect.

For open-source maintainers like BackUpScale, continuing to use Bitnami’s images now involves licensing uncertainty, limited updates, instability and the risk of losing upstream security fixes.

Simply put: Bitnami’s stack is no longer a viable base for sustainable open-source projects with limited funding.

What Changed in Drubernetes v2

To keep Drubernetes fully open and future-proof, we replaced our only Bitnami dependency, MariaDB, with the official MariaDB Enterprise Operator.

You can review the full changelog on the 2.0.0 release page and discussion in Issue #3.

Migration Guide: Upgrading from v1.x to v2.0

While this release represents a major step forward, the migration process does require manual intervention due to the difference in architectures.

Please review the complete details in the release notes.

Looking Ahead

Drubernetes v2 isn’t just about keeping up with upstream changes. It’s about reinforcing the open-source foundations we depend on. By moving to the official Helm charts, we gain:

Transparent governance and roadmaps
Consistent upstream support
Easier compliance for enterprise users
Freedom from vendor lock-in

We’ll continue to monitor the health of the operator ecosystem and ensure Drubernetes remains reliable, free from opaque licensing traps.

For more information, visit:

The introducing article: Want to Run Drupal in Kubernetes? Try Our New Terraform Module
The project page: gitlab.com/backupscale/drubernetes
The Terraform registry module: BackUpScale/drupal/kubernetes

Want to Run Drupal in Kubernetes? Try Our New Terraform Module

Sun, 13 Jul 2025 00:00:00 +0000

This article was originally published on the BackUpScale blog.

Background

Our customer dashboard, which will soon be used for managing subscriptions to our backup service (and not just newsletters and our contact form, as we’re doing now), is built on the Drupal data management framework. Until now, we’ve been hosting it with a company that specializes in hosting very specific types of applications, like Drupal. This wasn’t working for us because our service is running in our Kubernetes cluster at a cloud service provider that specializes in managed Kubernetes hosting, which let’s us run whatever applications we want, and configure them however we need. The challenge was getting the dashboard to communicate securely with our other applications.

It needs to communicate with our back-end systems in the Kubernetes cluster to:

send requests from customers to provision services,
configure customer accounts, and
receive status information from back-end services to create log entries that users can see in their accounts.

Why the old approach broke down

In order for things to work with the old set up, we’d have to:

expose internal applications to the Internet (so the dashboard site could access them), and
add additional layers of security to the communications to ensure privacy.

We didn’t feel as confident with this set-up as moving everything into our private Kubernetes network, which protects all of our services with a single firewall. Keeping non-public facing services within that network ensures that they’re not accessible by anyone on the greater Internet (except our staff using the company VPN), which ensures greater security and privacy for our users.

In order to make the change, we needed to be able to run a Drupal site within Kubernetes. Given that Drupal is a popular framework, and Kubernetes is a popular container orchestration system, we assumed that there would be good options for putting them together using open-source infrastructure as code (IaC) to handle the automated provisioning (we automate everything here). However, we weren’t able to find anything that could help us.

Evaluated options

We explored the following options:

The Bitnami Helm chart did at least one very strange thing: It was placing the Drupal code files on the persistent volume instead of placing them in the container image. We wanted the Drupal code (or at least the Composer files that build it along with any custom code) to be version controlled with Git. When we tried to work around this, they made it very difficult to make these changes.

Jeff Geerling simply stopped recommending his earlier approach (except for potentially hosting many sites on a hosting platform), and said that he currently uses his own Kubernetes primitives. So we took that idea, and expanded on it to build a fairly complete solution. Once we had something that worked for us, we believed we could make it generic enough to make it available to everyone else. So that’s what we did.

This move eliminated two Internet-facing endpoints and let us apply a single network-policy layer to all microservices. Additionally, running inside the cluster removes a public load balancer, and shrinks latency.

Meet “Drubernetes”

Because we automate all of our infrastructure with Terraform, we just released Drubernetes, a new module in the Terraform Registry, which provisions Drupal onto a generic Kubernetes cluster. It shouldn’t matter where your cluster is, who’s managing it for you, or if you’re managing it yourself on your own hardware. We wanted to provide something standardized that everyone can use and build from.

Contribute

Contributions are welcome! Please try it, and provide any feedback that you may have. The project is hosted on Gitlab.com, and any issues can be opened from the board.

As always, if you have questions or feedback, feel free to reach out. We appreciate your support and can’t wait to bring you the next chapter of BackupScale.

From DevOps Headaches to Seamless Onboarding: How Dropping Chocolatey Made DDEV the Perfect Fit for a Client's Drupal Team

Thu, 03 Jul 2025 00:00:00 +0000

TL;DR

After watching my enterprise client’s Drupal developers lose hours every week wrestling with raw Docker Compose for local development, I championed a switch to DDEV, the open‑source tool that gives “container superpowers with zero required Docker skills” (ddev.com). One of the snags on their Windows laptops was the Chocolatey package manager, whose install path clashed with locked‑down corporate security policies. Working with DDEV maintainer Randy Fay, I removed the Chocolatey dependency, paving the way for a leaner installer that shipped in version 1.24.5. Development team members now onboard much quicker, and leadership can point to measurable productivity gains.

The Starting Point: Docker Compose Drag

My client’s legacy workflow relied on a bespoke Docker Compose stack. Developers routinely diverted time to babysit containers as well as copying their work in and out, instead of writing code. This echeos industry findings that more than 58% of engineers lose 5‑plus hours per week to “unproductive work”. This DevOps overhead impacts their developer experience (DX), which is a distraction from their actual work.

Enter DDEV

DDEV abstracts all that Docker plumbing with simple commands (e.g. ddev start, ddev stop) while still running everything locally. Its promise, “environments in minutes, multiple concurrent projects, and less time to deployment”, resonated immediately.

Why It Mattered for Drupal

A Drupal codebase is never just PHP; it drags along Composer, Drush, front‑end toolchains, and database snapshots. DDEV’s predefined Drupal preset provides a reproducible stack with Nginx/Apache, MariaDB, and Mailhog out of the box.

A Windows Speed‑Bump Called Chocolatey

The developers work on locked‑down Windows laptops. DDEV’s install script used the Chocolatey package manager, which corporate policies block from writing to its default location. Workarounds involved various hurdles, exactly the sort of DevOps toil they wanted to eliminate.

Collaborating Upstream: Issue #6636 → PR #7049

While in research mode, I discovered Issue #6636, maintainers themselves wanted to drop Chocolatey but hadn’t had the bandwidth to do so. I volunteered a pull request that:

removed Chocolatey from the installation process, and
no longer required an Administrator Powershell; an unprivileged user could install it in a terminal.

The patch was merged on April 10, 2025.

Release v1.24.5: Goodbye Chocolatey

A month later, the change landed in v1.24.5 with a shout‑out in the release notes: “Chocolatey removed from automated Windows installation scripts. Thanks to @colans.” It’s now simpler for Windows developers to install DDEV, and they don’t have to be an administrator.

Business Case (as pitched to leadership)

“Container superpowers with zero required Docker skills” isn’t just marketing. Here’s the quantified rationale I presented:

Zero Docker config: ddev start replaces hand‑rolled Compose files.
No central registry maintenance: Images build locally.
Host‑level commands: ddev drush status or ddev composer install without docker exec.
Unified file system: The code lives on the host, eliminating copy‑in/out cycles.
Safe rebuilds: Deleting containers never loses work.
Always‑on Git: blame, diff, and branch with the active code without stepping into the container.
First‑class Composer: Composer‑managed Drupal is just a ddev composer require away.

Outcomes

Onboarding time dropped from half a day (or more) to an hour (or less).
Additonal support for broken sandboxes fell to nearly zero.
Developers now focus on development, not troubleshooting containers, or moving code in and out of them.

Gratitude

I’d like to thank Randy Fay for prompt code reviews, patient feedback, and for shepherding the change into a release.

Ready to Try?

Head to the official DDEV installation documentation and give it a spin. And if you’re stuck on Windows, it’s now much easier to install.

Does your Drupal hosting company lack native Composer support?

Thu, 12 Mar 2020 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

Best practices for building Web sites in the Drupal framework (for major versions 8 and above) dictate that codebases should be built with the Composer package manager for PHP. That is, the code repository for any sites relying on it should not contain any upstream code; it should only contain a makefile with instructions for assembing it.

However, there are some prominent Drupal hosting companies that don’t support Composer natively. That is, after receiving updates to Composer-controlled Git repositories, they don’t automatically rebuild the codebase, which should result in changes to the deployed code.

If you’re hosting your site(s) at one of these companies, and you have this problem, why not consider the obvious alternative?

Aegir, the one-and-only open-source hosting system for Drupal that’s been around for over 10 years, has had native Composer support for over 2 years. That is, on each and every platform deployment (“platform” is Aegir-speak for a Drupal codebase), Aegir reassembles the upstream code assets by running the following automatically:

`1`	`composer create-project --no-dev --no-interaction --no-progress`

As a result, any sites created on that platform (or migrated/upgraded to it) will have access to all of the assets built by Composer.

Additionally, Aegir now ships with the Aegir Deploy module, which enhances the platform creation process. It allows for the following types of deployment:

Classic/None/Manual/Unmanaged
Drush Makefile deployment
Pure Git
Composer deployment from a Git repository
Composer deployment from a Packagist repository

For more information, please read the Deployment Strategies section of the documentation.

If you’d like to get started with Aegir, the best option would be to spin up an Aegir Development VM, which allows you to run it easily, play with it, and get familiar with the concepts. Naturally, reading the documentation helps with this too.

Afterwards, review the installation guide for more permanent options, and take advantage of our Ansible roles. We have a policy role that configures the main role using our favoured approach.

For help, contact the community, or get in touch with me directly. I provide the following Aegir services:

Installation & maintenance in corporate/enterprise (or other) environments
Architectural and technical support
Hosting guidance
Coaching
Audits
Upgrades
Conversion to best practices

Aegir 5 is coming, and not just for Drupal!

Tue, 10 Mar 2020 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

Aegir is the one-and-only FLOSS hosting system for Drupal sites that’s been around for over 10 years, a rock in the community. While Drupal hosting companies have come and gone, Aegir’s always been there for folks who want to host Drupal sites themselves. According to recent data at the time of this writing, there are 567 instances (that we know about).

It’s used by organizations worldwide such as the US National Democratic Institute, NASA, and the European Commission.

While Aegir 3 is the currently stable recommended major release, we’ve started working on Aegir 5, which is a complete rewrite. It has notable differences such as:

Drush, traditionally used as the provisioner, has been replaced by Ansible, which allows for the hosting of any type of site or service, not just Drupal.
The front-end, formerly Drupal 7, has been replaced by Drupal 8, which allows us to take advantage of all of the newer features it provides.
Components are now best-of-breed open-source tools such as Celery, for the task queue. When Aegir was originally written, tools such as Ansible and Celery didn’t exist so all of the functionality was written as Aegir-specific code. We can now get off that island.
The entire project is now maintained in a single code repository, unlike the traditional four (Hosting, Provision, Hostmaster and Eldir) that have been maintained historically.
An out-of-the-box framework for automatic site updates via the Distributions concept. This was experimental in Aegir 3.

While still maintaining Aegir 3, we’d like to direct any new development initiatives towards the more modern Aegir 5.

The initial focus is on supporting Drupal. We then intend to add support for Matomo, Hugo, and other applications we use. However, documentation has been started on how to add support for anything else so merge requests or funding for new apps are greatly encouraged.

Along with the main documentation site, which includes the architecture, there is also an issues board for tracking tickets.

While we’re working on it as quickly as we can, we sometimes get delayed by other priorities. As such, we’re actively looking for sponsors to help us prioritize development. Please get in touch if you’re interested in partnering, collaborating, providing funding, or anything else.

Drupal North 2019: Drupal SaaS: Building software as a service on Drupal

Fri, 15 Nov 2019 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

On Friday, June 14th, I presented this session at Drupal North 2019. That’s the annual gathering of the Drupal community in Ontario and Quebec, in Canada.

As I realized I hadn’t yet posted this information yet, I’m doing so now.

Session information:

Are you (considering) building a SaaS product on Drupal or running a Drupal hosting company? Have you done it already? Come share your experiences and learn from others.

Among other things, we’ll be discussing:

Project vs. product business

Installation profiles / distributions

Customer service (e.g. GitLab’s Service Desk)

Hosting architecture (Drupal hosting companies vs. Aegir)

Infrastructure (IaaS hosting providers: OpenStack vs. AWS, GCS, Azure, etc.)

E-commerce, recurring billing and subscription provider integration

Aegir Site Subscriptions

Others?

Resource quotas

Site admin access permissions for clients

…and any other related topics that come up.

A video recording of my presentation is available on:

My slides (with clickable links) are available on our presentations site.

Exposing Drupal's Taxonomy Data on the Semantic Web

Thu, 24 Oct 2019 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

As a content management framework, Drupal provides strong support for its taxonomical subsystem for classifying data. It would be great if such data could be exposed via the Simple Knowledge Organization System (SKOS) standard for publishing vocabularies as linked data. As Drupal becomes used more and more as a back-end data store (due to features such as built-in support for JSON:API), presenting this data in standard ways becomes especially important.

So is this actually possible now? If not, what remains to be done?

Drupal’s history

First, let’s explore some of Drupal core’s history as it relates to the Semantic Web and Web services formats, also useful for future reference. This is basically the backstory that makes all of this possible.

REST support was added to Views

This was implemented in the (now closed) issues:

Non-Schema.org namespace mappings were removed (including contrib’s UI support) in Drupal 8

Here’s the change notice:

Use schema.org types and properties in RDF mappings

And a follow-up issue requesting support for additional namespaces:

Allow usage of any namespace in RDF mapping UI

The community chose to replace JSON-LD with HAL in Drupal 8

Here’s an article with the details:

Decoupling Drupal 8 Core: Web Services in Core and the Serialization Module

Multiple Components

As this is really a two-part issue, adding machine-readable metadata and then making machine-readable data available, I’ll split the discussion into two sections.

Adding machine-readable metadata

While there’s an RDF UI module that enables one to specify mappings between Drupal entities and their fields with RDF types and properties, it only supports Schema.org via RDFa (not JSON-LD).

As explained very well in Create SEO Juice From JSON LD Structured Data in Drupal, a better solution is to use the framework provided by the Metatag module (used by modules such as AGLS Metadata). The article introduces the Schema.org Metatag module, which uses the Metatag UI to allow users to map Drupal data to Schema.org, and exposes it via JSON-LD.

So one solution would be to:

Clone Schema.org Metatag, calling the new module SKOS Metatag.
Replace all of the Schema.org specifics with SKOS.
Rejoice.

But after taking some time to process all of the above information, I believe we should be able to use the knowledge of the vocabulary hierarchy to add the SKOS metadata. We probably don’t need any admin UI at all for configuring mappings.

Assuming that’s true, we can instead create a SKOS module that doesn’t depend on Metatag, but Metatag may still be useful given that it already supports Views.

Making the machine-readable data available

Exposing the site’s data can be done best though Views. I wouldn’t recommend doing this any other way, e.g. accessing nodes (Drupal-speak for records) directly, or through any default taxonomy links for listing all of a vocabulary’s terms. (These actually are Views, but their default set-ups are missing configuration.) A good recipe for getting this up & running, for both the list and individual items, is available at Your First RESTful View in Drupal 8.

To actually access the data from elsewhere, you need to be aware of the recent API change To access REST export views, one now MUST specify a ?_format=… query string, which explains why some consumers broke.

The JSON-LD format is, however, not supported in Core by default. There is some code in a couple of sandboxes, which may or may not work, that will need to be ported to the official module, brought up-to-date, and have a release (ideally stable) cut. See the issue JSON-LD REST Services: Port to Drupal 8 for details.

Now, the Metatag solution I proposed in the previous section may work with Views natively, already exposing data as JSON-LD. If that’s the case, this JSON-LD port may not be necessary, but this remains to be seen. Also, accessing the records directly (without Views) may work as well, but this also remains to be seen after that solution is developed.

Conclusion

Clearly, there’s more work to be done. While the ultimate goal hasn’t been achieved yet, at least we have a couple of paths forward.

That’s as far as I got with pure research. Due to priorities shifting on the client project, I didn’t get a chance to learn more by reviewing the code and testing it to see what does and doesn’t work, which would be the next logical step.

If you’ve got a project that could make use of any of this, please reach out. We’d love to help move this technology further along and get it implemented.

References

General information

Contributed modules that probably aren’t helpful (but could be)

Structured Data (JSON+LD Rich Snippets)
JSON LD Schema API
WissKI
Ontology (OWL)
DCAT
RDF entity
Drupal2RDF (This is brand new, but at the time of this writing, there’s not enough info/code yet to figure out what it’s trying to do.)
There’s a module called Smart Glossary which allows you to have multilingual SKOS Thesauri on your Drupal site, but I don’t think it’s useful at all as it’s part of a suite of modules maintained by PoolParty, where they expect you to use their data store:

Questions about importing SKOS data (not exporting it)

Aegir DevOps: Deployment Workflows for Drupal Sites

Tue, 24 Sep 2019 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

Aegir is often seen as a stand-alone application lifecycle management (ALM) system for hosting and managing Drupal sites. In the enterprise context, however, it’s necessary to provide mutiple deployment environments for quality assurance (QA), development or other purposes. Aegir trivializes this process by allowing sites to easily be copied from one environment to another in a point-and-click fashion from the Web front-end, eliminating the need for command-line DevOps tasks, which it was designed to do.

Setting up the environments

An Aegir instance needs to be installed in each environment. We would typically have three (3) of them:

Development (Dev): While generally reserved for integration testing, it is sometimes also used for development (e.g. when local environments cannot be used by developers or there are a small number of them).
Staging: Used for QA purposes. Designed to be a virtual clone of Production to ensure that tagged releases operate the same way as they would there, before being made live.
Production (Prod): The live environment visible to the public or the target audience, and the authoritative source for data.

(While outside the scope of this article, local development environments can be set up as well. See Try Aegir now with the new Dev VM for details.)

To install Aegir in each of these, follow the installation instructions. For larger deployments, common architectures for Staging and Prod would include features such as:

Separate Web and database servers
Multiple Web and database servers
Load balancers
Caching/HTTPS proxies
Separate partitions for (external) storage of:
- The Aegir file system (/var/aegir)
- Site backups (/var/aegir/backups)
- Database storage (/var/lib/mysql)
etc.

As these are all out of scope for the purposes of this article, I’ll save these discussions for the future, and assume we’re working with default installations.

Allowing the environments to communicate

To enable inter-environment communication, we must perform the following series of tasks on each Aegir VM as part of the initial set-up, which only needs to be done once.

Back-end set-up

The back-ends of each instance must be able to communicate. For that we use the secure SSH protocol. As stated on Wikipedia:

SSH is important in cloud computing to solve connectivity problems, avoiding the security issues of exposing a cloud-based virtual machine directly on the Internet. An SSH tunnel can provide a secure path over the Internet, through a firewall to a virtual machine.

Steps to enable SSH communication:

SSH into the VM.
- ssh ENVIRONMENT.aegir.example.com
Become the Aegir user.
- sudo -sHu aegir
Generate an SSH key. (If you’ve done this already to access a private Git repository, you can skip this step.)
- ssh-keygen -t rsa -b 4096 -C "ORGANIZATION Aegir ENVIRONMENT"
For every other environment from where you’d like to fetch sites:
1. Add the generated public key (~/.ssh/id_rsa.pub) to the whitelist for the Aegir user on the other VM so that the original instance can connect to this target.
  - ssh OTHER_ENVIRONMENT.aegir.example.com
  - sudo -sHu aegir
  - vi ~/.ssh/authorized_keys
  - exit
2. Back on the original VM, allow connections to the target VM.
  - sudo -sHu aegir
  - ssh OTHER_ENVIRONMENT.aegir.example.com
  - Answer affirmatively when asked to confirm the host (after verifying the fingerprint, etc.).

Front-end set-up

These steps will tell Aegir about the other Aegir servers whose sites can be imported.

On Aegir’s front-end Web UI, the “hostmaster” site, enable remote site imports by navigating to Administration » Hosting » Advanced, and check the Remote import box. Save the form. (This enables the Aegir Hosting Remote Import module.)
For every other server you’d like to add, do the following:
1. Navigate to the Servers tab, and click on the Add server link.
2. For the Server hostname, enter the hostname of the other Aegir server (e.g. staging.aegir.example.com)
3. Click the Remote import vertical tab, check Remote hostmaster, and then enter aegir for the Remote user.
4. For the Human-readable name, you can enter something like Foo's Staging Aegir (assuming the Staging instance).
5. You can generally ignore the IP addresses section.
6. Hit the Save button.
7. Wait for the server verification to complete successfully.

All of the one-time command-line tasks are now done. You or your users can now use the Web UI to shuffle site data between environments.

Deploying sites from one environment to another

Whenever necessary, this point-and-click process can be used to deploy sites from one Aegir environment to another. It’s actually a pull method as the destination Aegir instance imports a site from the source.

Reasons to do this include:

The initial deployment of a development site from Dev to Prod.
Refreshing Dev and Staging sites from Prod.

Steps:

If you’d like to install the site onto a new platform that’s not yet available, create the platform first.
Navigate to the Servers tab.
Click on the server hosting the site you’d like to import.
Click on the Import remote sites link.
Follow the prompts.
Wait for the batch job, Import and Verify tasks to complete.
Enable the imported site by hitting the Run button on the Enable task.
The imported site is now ready for use!

Try Aegir now with the new Dev VM

Mon, 09 Sep 2019 00:00:00 +0000

Originally published on the Consensus Enterprises blog.

Have you been looking for a self-hosted solution for hosting and managing Drupal sites? Would you like be able able to upgrade all of your sites at once with a single button click? Are you tired of dealing with all of the proprietary Drupal hosting providers that won’t let you customize your set-up? Wouldn’t it be nice if all of your sites had free automatically-updating HTTPS certificates? You probably know that Aegir can do all of this, but it’s now trivial to set up a temporary trial instance to see how it works.

The new Aegir Development VM makes this possible.

History

Throughout Aegir’s history, we’ve had several projects striving to achieve the same goal. They’re listed in the Contributed Projects section of the documentation.

Aegir Up

Aegir Up was based on a VirtualBox virtual machine (VM), managed by Vagrant and provisioned with Puppet. It was superseded by Valkyrie (see below).

Aegir Development Environment

Aegir Development Environment took a completely different approach using Docker. It assembles all of the services (each one in a container, e.g. the MySQL database) into a system managed by Docker Compose. While this is a novel approach, it’s not necessary to have multiple containers to get a basic Aegir instance up and running.

Valkyrie

Valkyrie was similar to Aegir Up, but provisioning moved from Puppet to Ansible. Valkyrie also made extensive use of custom Drush commands to simplify development.

Its focus was more on developing Drupal sites than on developing Aegir. Now that we have Lando, it’s no longer necessary to include this type of functionality.

It was superseded by the now current Aegir Development VM.

Present

Like Valkyrie, the Aegir Development VM is based on a VirtualBox VM (but that’s not the only option; see below) managed with Vagrant and provisioned with Ansible. However, it doesn’t rely on custom Drush commands.

Features

Customizable configuration

The Aegir Development VM configuration is very easy to customize as Ansible variables are used throughout.

For example, if you’d like to use Nginx instead of Apache, simply replace:

`1`	`aegir_http_service_type: apache`

…with:

`1`	`aegir_http_service_type: nginx`

…or override using the command line.

You can also install and enable additional Aegir modules from the available set.

Support for remote VMs

For those folks with older hardware who are unable to spare extra gigabytes (GB) for VMs, it’s possible to set up the VM remotely.

While the default amount of RAM necessary is 1 GB, 2 GB would be better for any serious work, and 4 GB is necessary if creating platforms directly from Packagist.

Support for DigitalOcean is included, but other IaaS providers (e.g. OpenStack) can be added later. Patches welcome!

Fully qualified domain name (FQDN) not required

While Aegir can quickly be installed with a small number of commands in the Quick Start Guide, that process requires an FQDN, usually something like aegir.example.com (which requires global DNS configuration). That is not the case with the Dev VM, which assumes aegir.local by default.

Simplified development

You can use it for Aegir development as well as trying Aegir!

Unlike the default set-up provisioned by the Quick Start Guide, which would require additional configuration, the individual components (e.g. Hosting, Provision, etc.) are cloned repositories making it easy to create patches (and for module maintainers: push changes upstream).

Conclusion

We’ve recently updated the project so that an up-to-date VM is being used, and it’s now ready for general use. Please go ahead and try it.

If you run into any problems, feel free to create issues on the issue board and/or submit merge requests.

DrupalCamp Ottawa 2018: Drupal SaaS: Building software as a service on Drupal

Fri, 26 Oct 2018 00:00:00 +0000

On Friday, October 26th, I presented at DrupalCamp Ottawa 2018, the annual gathering of the Drupal community in Ottawa, Ontario, Canada.

Session Information

Are you (considering) building a SaaS product on Drupal or running a Drupal hosting company? Have you done it already? Come share your experiences and learn from others.

Among other things, we’ll be discussing:

Project vs. product business

Installation profiles / distributions

Customer service (e.g. GitLab’s Service Desk)

Hosting architecture (Drupal hosting companies vs. Aegir)

Infrastructure (IaaS hosting providers: OpenStack vs. AWS, GCS, Azure, etc.)

E-commerce, recurring billing and subscription provider integration > - Aegir Site Subscriptions

Others?

Resource quotas

Site admin access permissions for clients

…and any other related topics that come up.

Resources

A video recording of our presentation is available on YouTube (with the audio track missing, unfortunately), and my slides (with clickable links) are available at talks.consensus.enterprises/drupal-saas.

Drupal North Toronto 2018: Hosting Drupal Sites? You need Aegir

Sat, 18 Aug 2018 00:00:00 +0000

On Saturday, August 11th, Christopher Gervais and I presented at Drupal North 2018, the annual gathering of the Drupal community in southern Ontario and Quebec, Canada.

Session Information

Do you need a self-hosted solution for hosting and managing Drupal sites? Would you like to be able to upgrade all of your sites at once with a single button click? Are you tired of dealing with all of the proprietary Drupal hosting providers that won’t let you customize your set-up? Wouldn’t it be nice if all of your sites could automatically get free HTTPS certificates?

If you said yes to any of the above questions, there’s only one option: the Aegir Hosting System. While it’s possible to find a company that will host Drupal sites for you, Aegir helps you maintain control whether you want to use your own infrastructure or manage your own software-as-a-service (SaaS) product. Plus, you get all the benefits of open source.

We’ll cover:

History

Architecture

Basic features

Advanced features

Development workflows

Recent additions

Future

Questions & discussion

Resources

A one-hour video recording of our presentation is available on YouTube, and our slides (with clickable links) are attached here.

Slides

DrupalCamp Montreal 2018: Hosting Drupal Sites? You need Aegir

Fri, 15 Jun 2018 00:00:00 +0000

On Friday, June 15th, Christopher Gervais and I presented at DrupalCamp Montreal 2018, the annual gathering of the Drupal community in Montreal, Canada.

Session Information

Do you need a self-hosted solution for hosting and managing Drupal sites? Would you like to be able to upgrade all of your sites at once with a single button click? Are you tired of dealing with all of the proprietary Drupal hosting providers that won’t let you customize your set-up? Wouldn’t it be nice if all of your sites could automatically get free HTTPS certificates?

If you said yes to any of the above questions, there’s only one option: the Aegir Hosting System. While it’s possible to find a company that will host Drupal sites for you, Aegir helps you maintain control whether you want to use your own infrastructure or manage your own software-as-a-service (SaaS) product. Plus, you get all the benefits of open source.

We’ll cover:

History

Architecture

Basic features

Advanced features

Development workflows

Recent additions

Future

Questions & discussion

Resources

A one-hour video recording of our presentation is available on YouTube, and our slides (with clickable links) are attached here.

Slides

Aegir: Your open-source hosting platform for Drupal sites

Thu, 07 Dec 2017 00:00:00 +0000

If you need an open-source solution for hosting and managing Drupal sites, there’s only one option: the Aegir Hosting System. While it’s possible to find a company that will host Drupal sites for you, Aegir helps you maintain control whether you want to use your own infrastructure or manage your own software-as-a-service (SaaS) product. Plus, you get all the benefits of open source.

Aegir turns ten today. The first commit occurred on December 7th, 2007. We’ve actually produced a timeline including all major historical events. While Aegir had a slow uptake (the usability wasn’t great in the early days), it’s now being used by all kinds of organizations, including NASA.

I got involved in the project a couple of years ago when I needed a hosting solution for a project I was working on. I started by improving the documentation, working on contributed modules, and then eventually the core system. I’ve been using it ever since for all of my SaaS projects and have been taking the lead on Drupal 8 e-commerce integration. I became a core maintainer of the project about a year and a half ago.

So what’s new with the project? We’ve got several initiatives on the go. While Aegir 3 is stable and usable now (Download it!), we’ve started moving away from Drush, which traditionally handles the heavy lifting (see Provision: Drupal 8.4 support for details), and into a couple of different directions. We’ve got an Aegir 4 branch based on Symfony, which is also included in Drupal core. This is intended to be a medium-term solution until Aegir 5 (codenamed AegirNG), a complete rewrite for hosting any application, is ready. Neither of these initiatives is stable yet, but development is ongoing. Feel free to peruse the AegirNG architecture document, which is publicly available.

Please watch this space for future articles on the subject. I plan on writing about the following Aegir-related topics:

Managing your development workflow across Aegir environments
Automatic HTTPS-enabled sites with Aegir
Remote site management with Aegir Services
Preventing clients from changing Aegir site configurations

Happy Birthday Aegir! It’s been a great ten years.

Representing Drupal at the GSoC 2017 Mentor Summit

Thu, 26 Oct 2017 00:00:00 +0000

I’ve been mentoring students as part of Drupal’s Google Summer of Code (GSoC) program for the last two years, where we guide students in working on Drupal projects over the summer. (For the projects I’ve been involved in, see User-friendly encryption now in Drupal 8! and Client-side encryption options now available in Drupal.) This year, our organization administrator, Matthew Lechleider, invited me to the Mentor Summit.

The Google-provided summit creates a forum for members of free/libre and open-source software (FLOSS) organizations to come together to discuss GSoC, mentoring, and FLOSS in an unconference format. I met attendees from all over the world, who flew in from far-reaching places to interact as part of a wider community. Generally, two mentors are invited from each organization, but some had more and some had less.

I arrived late Friday night, having missed that day’s introductory sessions due to some trouble at the US border. Historically, in my experience, we Canadians haven’t had too much trouble getting across the border for technology conferences. This has recently changed so it’s now necessary to provide proof of intent for being in the country (a signed invitation from the organizers) as well as proof of business activities (corporate and tax documents). Needless to say, all of this took a significant amount of time to prepare. Eventually though, I was allowed through and made my way to Sunnyvale, California.

On Saturday morning, the day started with Lightning Talks, where attendees gave presentations on their student projects having only a few minutes each to speak. There were so many presentations that it was necessary to split the session into two, continuing after dinner that same evening. While there were several interesting projects highlighted, the most interesting to me was Jitsi’s speech-to-text service. Besides making video conferences accessible through textual media, it also allows for automated note-taking. This was one of the truly amazing projects completed by a student over the summer.

In talking about Drupal with other folks, I was surprised to hear that many other delegates do not have paying day jobs associated with their organizations. They work on these projects on the side, and generally don’t get paid for them. For example, nobody in the Kodi contributor community gets paid; it’s all volunteer work. While there are volunteer contributions to Drupal, many of those contributors eventually turn that knowledge into paid work. I suppose we’re a lucky bunch, being able to work on an open-source project and get paid for it. And speaking of Kodi, I’m happy to report that they’re using Drupal for their website!

There were quite a few conversations about messaging applications, with a large XMPP delegation. There were also folks from the Zulip and Rocket.Chat communities. It was interesting to hear from a former XMPP developer who’s shifted completely to Matrix with the Riot client, exactly as I’ve done. I use that client and the federated protocol to bridge with other communications networks such as proprietary closed-source Slack and classic Internet Relay Chat (IRC) whenever possible. Matrix already integrates with these two protocols, and has built-in support. The goal is to eventually use only one messaging client, instead of the many applications we all have installed on all of our devices. Rocket.Chat has already started working on Matrix integration, while Zulip hasn’t. They’re open to it, and may move in this direction eventually, but for now they’re focused on user-experience innovations. In the Drupal community, we’ve had a very long discussion about using Matrix for our communications alongside IRC, and have finally put a plan into place to make this happen. For those eager to jump in, it’s now possible to use Matrix as an always-on IRC bouncer client to connect to Drupal’s IRC channels.

Alongside Drupal, representatives from other content management systems (CMSes) also attended. There were folks from both the Joomla and Plone communities. It would have been great to connect with them, but I didn’t get a chance. I was hoping that Airship CMS would have representation as that crew has been doing a lot of excellent security work with PHP projects (including helping us with Drupal), but they weren’t in attendance.

All in all, it was an excellent conference. In my humble opinion, it’s really important to stay in touch with this greater community, cross-pollinate with folks doing similar work in the public interest, and keep contributing!

Client-side encryption options now available in Drupal

Mon, 18 Sep 2017 00:00:00 +0000

After the success of last year’s GSOC project with Drupal, I thought it would be a great idea to see if we could take what we did there (server-side encryption) and do something similar on the client side. The benefit of this approach is that unencrypted content/data is never seen by the hosting server. So it’s not necessary to trust it to the same degree. This has been a requested feature for some time, and become very popular within the instant-messaging space.

I posted the idea, but wasn’t sure how much traction there would be given the additional complexity. Before long, there were two interested students, Marcin Czarnecki and Tameesh Biswas, who were interested in the project given their interest in cryptography. They both wrote very good proposals, which we in the Drupal community accepted.

With the help of Adam Bergstein (my co-mentor from last year) and Talha Paracha (last year’s student), we were able to mentor both students in working towards completing their projects, even with the added complexity. Unlike last year, users’ passwords couldn’t be used to encrypt anything because the site has access to these. An out-of-band mechanism was necessary to perform the encryption, public-key cryptography. It needed to be in the hands of users themselves instead of being handled implicitly by the server.

I’m delighted to report that both students passed. The community can now take their projects and build upon them. Please review the new Drupal modules at Client-side content encryption (overview) and Client Side File Crypto (overview). If there are any issues, please open tickets in the respective queues.

User-friendly encryption now in Drupal 8!

Mon, 12 Sep 2016 00:00:00 +0000

The problem with most encryption strategies nowadays is that they require third-party software and/or services, require maintenance of additional keys and/or secrets, and provide an awful user experience.

Earlier this year, I started wondering why we couldn’t simply encrypt data with pre-existing secrets, the passwords users already have for logging into their Drupal sites. They shouldn’t have to deal with public and private keys and other cryptographic details. So I did some research, and was happy to discover that the security model is already in existence. The folks at ownCloud have not only published it (Data Encryption Model 1.1 and 2.2); they’ve already implemented it in their product. What’s even better is that the product is also written in PHP like Drupal, and has an open-source license. So the ideas and code can be reused.

Not too long after I made this discovery, the Drupal community was looking for project ideas for Google’s Summer of Code (GSOC). So I added mine to the list. There were several students interested in the topic, and wrote proposals to match. Talha Paracha’s excellent proposal was accepted, and he began in earnest. With Adam Bergstein (nerdstein) and I mentoring him, Talha successfully worked though all phases of the project. For details, please see his blog posts.

Now that GSOC 2016 has come to a close, we have a full project release for the Pubkey Encrypt module. It’s currently in beta, awaiting community review before we publish a production-ready version. We’ve included an architecture document, user stories, and usage documentation. There’s also a video! Please take the time to experiment with the module, and create tickets for any issues that you find.

At the time of this writing, only field data can be encrypted via the Field Encryption module. The File Encryption module is still in development, but as soon as it’s released, it should work with Pubkey Encrypt as well.

Authenticating Drupal users via OAuth2

Sun, 06 Sep 2015 00:00:00 +0000

I recently had a client that began delegating access to all of its data assets across the enterprise network via OAuth, specifically the OAuth 2.0 protocol. While I was there architecting a Drupal solution as their new Web platform, they wanted me to hook into this system to authenticate their Drupal users. Although there have been some modules available in the ecosystem to support OAuth2, there weren’t any available to provide this functionality. So I created the OAuth2 Authentication module.

This module allows users to log into a Drupal site authenticating against a remote identity provider (IDP) via OAuth2. That is, if a user’s credentials can be used to retrieve a valid access token, he/she will be logged into the site with those credentials and the token will be added to his/her session. If the user account doesn’t exist yet, it will be created.

In doing this, we’re making the assumption that resource requesters are actually resource owners. Generally, one shouldn’t make that assumption as OAuth2 is an authorization mechanism, not an authentication mechanism. Ideally, logging in users via OAuth2 should be done with OpenID Connect. It provides a proper identity layer on top of OAuth2. It’s essentially the evolution of SAML; see my answer to Can OAuth 2 be used for SSO? Or do I need a more sophisticated authentication? for details. In situations where one doesn’t have access to an OpenID Connect server, but does have access to an IDP that speaks OAuth2 and can trust the environment in which all of it operates, this module is sufficient.

The security implications of using this module should be well understood. If one doesn’t control the environment in which it’s running, then it shouldn’t be used. For example, I don’t recommend running with this concept in a mobile environment as it can’t be trusted to the same extent as a Drupal site behind a corporate firewall. The following articles are on the subject are noteworthy:

It also wouldn’t hurt to study the official OAuth 2.0 Threat Model and Security Considerations.

Initial Set-Up

Install and enable the OAuth2 Client and OAuth2 Authentication modules as you would any other.
If you wish to override any of the methods in the OAuth2AuthenticationClient class to change the module’s behaviour, create another class that extends it and implement the desired methods. This is best done in a custom module for your site, something like Sitename Authentication (sitename_authentication) where S/sitename is the name of your site.
Surf to the configuration page over at Home » Administration » Configuration » Web services » OAuth2 Authentication to configure your token endpoint. This section is mandatory while the others are optional. They contain sane defaults, but look over all of it to make sure it’s what you need for your set-up.
If you subclassed OAuth2AuthenticationClient, replace the default class name in Miscellaneous Settings » Client Class with the name of your new class.
Hit the Save configuration button to save your settings.
Enjoy!

Notes

Once you’ve got this set up, you’ll have to ensure that the Web-services client module you’re using supports the OAuth2 protocol (i.e., token access to resources). If you’re already using one that doesn’t, you’ll have to add that support. Otherwise, go with one that supports this already.
When an existing local user logs in, the module will attempt to get an access token for him/her. On success, the token will be added to the user’s session. On failure, the user will still be logged in, but will not get a token. Whenever a request to get a token is made, the results are reported in the log.
If an existing user whose password has changed on the IDP, but not Drupal yet, logs in, the password hash stored locally will be updated. This is attempted after a local login failure: If the user can authenticate remotely, the account is updated locally, and the user is logged in normally. There are no noticeable differences to the end user.

Issues

Token Expiration

If the total expiration time for your tokens, including successive tokens returned by your token server through refresh tokens (RTs), is less than the maximum time a user can be logged in (see Session Expire for details), users will still be logged in when their final tokens expire.

As this module doesn’t (yet) deal with that situation, you’ll need to come up with a solution that meets your requirements. Some background information on this can be found over at Best-Practice for dealing with OAuth 2.0 Token expiration at the Consumer.

Options

Automatically log out each user after being logged in for the token expiry time.
Extend the token expiration time to the maximum amount of time a user can be logged in.
Add support for refresh tokens (RTs) that can keep working until a user’s login session expires.
Have the token server issue tokens that don’t expire.
Some combination of the above.

Real-World Solutions

Helpful Drupal Modules

Session expire (also explains the default login session length)
Automated Logout
Ejector Seat

Similar Modules

OAuth2 Login redirects users to another Drupal site for authentication, and then sends them back logged in once they’re authenticated. This module doesn’t do any redirection; everything is done behind the scenes. Users logging in won’t even know that they’re authenticating against another system. They simply log in using the normal Drupal login process, but get an access token on top of that (if granted). Users that don’t exist locally will be created during the login process.

In conclusion, although this solution isn’t the most appropriate given the technology that’s now available, it does fit a lot of real-world use cases. At the time of this writing, there are 130 sites using it. This is quite impressive given that I recommend against it on the project page!

Responding to Drupal's Highly Critical SQL Injection Vulnerability

Thu, 03 Sep 2015 00:00:00 +0000

On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.

At the time, I was asked by a client of mine to analyze a site to determine risk.

Some common attack vectors associated with the vulnerability were:

Changing the superuser’s (user ID 1) username, password or e-mail address.
Adding new users to the user table with the administrator role (usually ID 3).
Adding entries to the menu_router table.
Adding PHP files to the code base or in the sites/all/files directory.
Adding nodes (pages) or blocks with executable PHP.
Downloading the list of user passwords
Determining hackability through the version listed in CHANGELOG.txt
Spawned processes run by the Web server
Adding new roles
Permission changes

So based on the above, and some other sources, it was possible to produce a list of things one could look for to determine if a site had been compromised. As has been discussed elsewhere, failure to confirm any of these did not mean the site was not compromised, but it did provide some indication of risk.

Rerun the Security Review module.
Perform checks with the Drupalgeddon & Site Audit modules.
Check for changes to user 1’s username, password or e-mail address.
Check all users in roles other than “anonymous” and “authenticated”.
Check for strange entries in the menu_router table.
Check for code files outside of version control.
Check for code files inside sites/all/files.
Check for new nodes or blocks in the DB.
Check for strange processes spawned by the Web server user.
Check for any new roles.
Check for any permission changes.
Check the mail logs for anything suspicious being sent out.
Scan site with the Sucuri tools Free Website Malware and Security Scanner and Unmask Parasites.

There are some worthwhile things to note with respect to the checklist above:

Some of the clues (such as 5 and 6 above) would have been long gone as they’re rebuilt during cache clears and deployments.
It’s theoretically possible that malicious processes could have been spawned by the Web servers. The names could have been renamed to look non-malicious, but unless something was set up to make these persist across power cycles, they would be wiped on a system reboot.
It’s also theoretically possible that user passwords could have been compromised. In Drupal 7, hashed passwords are salted, but the random string used for the salt could have been read as it’s in sites/colan.consulting/settings.php. With that in mind, the site would be susceptible to brute force, dictionary and rainbow table attacks. If the site isn’t going to be rebuilt, it would be a good idea to expire all passwords and forcing users to reset them. If another system is handling authentication, this isn’t an issue.

And of course there could be any number of other things. The best course of action would be to rebuild the site. If that’s a challenge, always consider the level of risk before deciding not to. Hopefully we won’t have to make too many of these determinations in the future.

References

Drupal Helpers: Tools for DevOps and Deployment

Mon, 10 Aug 2015 00:00:00 +0000

As I’ve been architecting Drupal solutions for almost ten years now, I’ve accumulated quite a bit of knowledge on devops best practices, which constitutes a sizeable amount of the consulting that I do. This includes documentation, configuration management, development processes and deployment processes. In this article, I’ll be introducing Drupal Helpers, a collection of standard scripts and configurations that I use on all of my client projects (where applicable).

At the time of the writing, the repository provides support for the following operations and Drush set-up. Additional tools are always welcome.

Refreshing a development site’s database and files

The resync-drupal-db-for-dev script essentially deploys the database and files from a staging site (Staging) or production site (Prod) onto a development site, but it also does many other things that should be done as part of that process, devifying it.

It takes source and destination Drush aliases as arguments and the third one, a list of modules to disable, is optional. Here is the usage example:

resync-drupal-db-for-dev <SOURCE_DRUSH_ALIAS> <DESTINATION_DRUSH_ALIAS> [<MODULES_DISABLE>]

It performs the following tasks:

Saves a cache-cleared dump of the destination database (DB) as a backup.
Overwrites the destination DB with the source’s.
Rebuilds the registry in case PHP file locations have changed.
Updates the DB schema.
Reverts all features to the code in Features modules.
Reverts all views to those defined in code.
Disables modules that shouldn’t be enabled during development.
Enables modules that are helpful for development.
Disables CSS and JavaScript caching.
Sets the files and temporary directories to standard locations.
Enables on-screen error reporting.
Disables user-initiated cron runs. This should really be disabled everywhere for performance reasons.
Clears all caches.
Overwrites the destination’s files directory with the source’s.
Runs cron.

Developers should be doing all of this every time they refresh their DBs. Because it’s tricky and time-consuming to do all of these manually, some of the steps are often missed. This leads to configuration mismanagement issues between development sandboxes and other environments. I’d recommend that this script, or another one like it, be run frequently on the authoritative development/integration site (Dev) and local development sites to prevent such mishaps.

The script tries to be as versatile as possible, working in a variety of GNU/Linux environments. If it doesn’t work for yours, please submit a merge request so that we can get support added.

Deploying code to a development/integration site

The deploy-drupal-code-dev script is useful for deploying the latest development code that’s been merged to the development branch to Dev. As part of that process, it does everything else that’s necessary after a code deployment, including clearing external Varnish caches. It doesn’t produce output to the screen when running it directly, as it’s assumed to be run as a cron job. All output gets redirected to a log file. A best practice is to have it run nightly so that Dev is kept up-to-date.

Deploying code to staging or production sites

The two (2) scripts deploy-drupal-code-qa and deploy-drupal-code-prod basically follow the same idea as the Dev script above, except that:

They require a Git release tag as an argument, as only tagged releases should be deployed to Staging and Prod.
They produce output directly to the screen, as they are intended to be run manually.

PHP configuration for Drush

The drush.ini configuration file (see Configuring php.ini for details) adds Drush-specific configuration to PHP, differentiated by its being run from the command line; Drush’s PHP doesn’t go through a Web server.

As Drush is often called upon for batch processing, it requires more resources than Web-server PHP. Also, there aren’t usually multiple instances of it running so we don’t need be as concerned about overflowing resource limits. With Web servers, there could be a huge number of PHP processes running on public-facing sites.

The configuration file does the following:

Increases the memory limit.
Ensures all errors are shown.
Sets the time zone.
Increases the maximum execution time. You may need to do this for MySQL/variants as well.

Make sure this is set up by placing the file (or a symlink to it) in your /etc/php5/cli/conf.d/ directory (or the equivalent for different systems).

Default Drush alias configuration

The default.alias.drushrc.php Drush alias file is a standard location for storing all common Drush configuration. It needs to be set in each of your site alias’ configuration stanzas to use it.

The line is:

`1`	`<?php$aliases['dev'] = array( 'parent' => '@default', ...?>`

It could actually use an update now that Better handling of structure-tables and skip-tables options (including cache_* support!) is done. We no longer need to explicitly state which cache tables we need to skip during certain operations.

Backing up databases

The backup-drupal-db script will back up a Drupal DB whenever it’s run. It can be run stand-alone or as a Cron job. To save storage space, cache tables will not be included in the compressed dump files. Each is timestamped, and the “LATEST” file will always be a symbolic link to the most recent backup. Old backups are automatically deleted after a set number of days; the default is 60 (~2 months).

Rebuilding a site with its latest Drush makefile

The drupal-remake script will rebuild a Drupal site’s document root to reflect recent changes in its Drush makefile. It performs the following tasks:

Takes the site off-line.
Backs up the existing database.
Updates the Git repository with the latest code.
Purges the old code base.
Rebuilds it.
Re-installs the previous sites directory (with site-specific configuration).
Properly sets all file permissions.
Updates the DB schema.
Turns the site back on-line.
Clears all caches.

Deploying Solr onto the GlassFish application server

The deploy-solr-on-glassfish script sets up the Solr search engine to run on the GlassFish application server.

With Solr 5, it’s no longer necessary to run the search engine in an application server. It can run as a stand-alone application. See Install Apache Solr 5 and Drupal Search API on your laptop in minutes for an example of how to do this. For earlier versions though, this is helpful in getting the Java stack set up to run alongside the PHP one.

A special thanks goes out to Jamon Camisso for posting the original version of this on GitHub earlier.