Skip to content

Create an OTOBO Staging System — Step-by-Step Guide

https://softoft.sirv.com/Images/otobo-staging-2.png Set up an OTOBO staging system as a safe production copy: migrate the database and files, turn off real outbound mail, anonymize customer data, then validate packages and config before anything reaches live.


🔄 Overview: Staging System Migration Workflow

Section titled “🔄 Overview: Staging System Migration Workflow”
  1. Prepare development system
  2. Set up staging system
  3. Copy production data
  4. Test staging
  5. Deploy staging to production (optional)

  • Safe testing of configuration, custom code & packages
  • Automated end-to-end tests using tools like Playwright
  • GDPR-compliant testing after anonymization
  • Recovery tests & backup verification

  • Ubuntu 20.04+ or Debian 10+
  • Docker (recommended) or manual Linux installation
  • Sufficient system resources (8 GB RAM, 4 CPUs)
  • Access to current production data (DB & file system)
  • Ability to disable email sending (e.g., via dummy SMTP)

flowchart TD
    A[Feature ready for test] --> B[Clean up dev system, delete tickets]
    B --> C[Copy dev -> staging]
    C --> D[Wait for maintenance window]
    D --> E[Back up production data DB & files]
    E --> F[Transfer production data to staging]
    F --> G[Adjust configuration in staging]
    G --> H[Disable email sending]
    H --> I[Perform test run]

    I -->|Tests successful| J[Optional: Copy staging -> production]
    I -->|Tests failed| K[Fix errors and re-test]

    J --> L[Activate production]
    L --> M[Done, deployment complete]

    style D fill:#a9a,stroke:#333,stroke-width:1px
    style I fill:#aae,stroke:#333,stroke-width:1px
    style J fill:#9a9,stroke:#333,stroke-width:1px
    style K fill:#a99,stroke:#333,stroke-width:1px

A Docker installation is recommended:

Terminal window
sudo apt install docker.io docker-compose
cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-11_0
cd otobo-docker
cp .docker_compose_env_https .env
nano .env # Set OTOBO_DB_ROOT_PASSWORD

If you are using a dev system as a base:

Terminal window
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

Terminal window
# Back up database (production system)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql
# Back up articles & Kernel
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Import into staging:

Terminal window
# Import DB
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql
# Copy file system
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Data Privacy: Anonymize all production customer data, e.g., in the customer_user table, or remove email addresses using an SQL script.


Kernel/Config.pm
$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORD';

In SysConfig:

  • Set SendmailModule to Kernel::System::Email::DoNotSendEmail
  • Alternatively: Change SMTP server to 127.0.0.1 and port to 1

  • Use Playwright or Cypress scripts for UI tests
  • Use bin/otobo.Console.pl Maint::Test::System
  • Check data integrity & UI behavior
  • Disable integrations like LDAP or web services, or redirect them to a test server

  • Restrict access via VPN or IP whitelist
  • Set robots.txt to prevent indexing
  • If necessary, implement Basic Auth via Nginx
  • Secure SSL via SAN or wildcard certificate (*.staging.example.com)

🔄 Optional: Deploy Staging to Production

Section titled “🔄 Optional: Deploy Staging to Production”

Once testing is complete in staging:

  1. Stop production server
  2. Copy staging database and directories to production
  3. Adjust Config.pm
  4. Restart production

  • Playwright (for E2E tests)
  • rsync for fast data transfer
  • docker-compose for orchestrated environment
  • cron or systemd for regular backups
  • Python scripts for anonymization or structural migration

An OTOBO staging system lets you test upgrades, packages, and SysConfig changes on real-shaped data without risking production downtime or accidental customer emails.

🔁 Tip: Integrate staging processes into your CI/CD pipeline for automated quality assurance with every change.

Reliable OTOBO operations & expert support

Dependable support for version upgrades, staging environments, disaster recovery strategies, and 2nd-level technical support.

Frequently asked questions

What is an OTOBO staging system and why is it beneficial?

An OTOBO staging system is a near-identical copy of your production environment, designed to provide a safe and isolated space for testing. Its primary benefit lies in allowing administrators and developers to thoroughly test new configurations, custom code, package installations, and system upgrades without any risk of impacting the live production system or its users. This includes performing automated end-to-end tests with tools like Playwright, ensuring GDPR-compliant testing after data anonymization, and verifying backup and recovery procedures. By simulating real-world scenarios, a staging system helps identify and resolve potential issues before they reach production, ensuring stability and reliability. It also supports recovery tests and backup verification.

Quellen

What are the key steps to set up an OTOBO staging system?

Setting up an OTOBO staging system involves several critical steps to mirror your production environment effectively. First, you prepare the development system, often by cleaning up old tickets and articles if using an existing dev instance. Next, you set up the staging system itself, with a Docker installation being the recommended approach for ease of deployment and management. After the basic setup, you copy production data, including the database (using mysqldump) and file system data (Kernel and var/article via rsync), into the staging environment. Crucially, you then adjust the Kernel/Config.pm file to point to the staging database and disable email sending by setting SendmailModule to Kernel::System::Email::DoNotSendEmail or redirecting SMTP to prevent accidental outbound communication.

Quellen

How do you handle production data for an OTOBO staging system, especially regarding privacy?

When using production data for an OTOBO staging system, data privacy is paramount. While using production-like data is crucial for realistic testing, you must anonymize or restrict sensitive customer information, especially data in tables like customer_user and all email addresses, to ensure GDPR compliance. Never point the staging mail system at real customers. The process involves backing up the production database using mysqldump and relevant file data (like /opt/otobo/Kernel and /opt/otobo/var/article using rsync). These backups are then imported into the staging environment, with the database being restored via mysql and the file system copied using rsync. This ensures a realistic testing ground without compromising sensitive user data.

Quellen

What are the essential security measures for an OTOBO staging environment?

Securing your OTOBO staging environment is crucial to prevent unauthorized access and data exposure. Essential measures include restricting access via a VPN or IP whitelist, ensuring only authorized personnel can reach the system. To prevent search engines from indexing the staging site, implement a robots.txt file. For an additional layer of protection, consider implementing Basic Authentication through your web server (e.g., Nginx). Furthermore, secure SSL communication using a SAN (Subject Alternative Name) or wildcard certificate, such as *.staging.example.com, to encrypt data in transit. These steps collectively safeguard your test environment from external threats and maintain data confidentiality.

Quellen

What tools and methods are recommended for testing and automation within an OTOBO staging system?

For comprehensive testing and automation within an OTOBO staging system, a combination of tools and methods is highly recommended. For user interface (UI) and end-to-end (E2E) tests, tools like Playwright or Cypress are excellent for scripting browser interactions. System integrity can be verified using OTOBO's built-in console command bin/otobo.Console.pl Maint::Test::System. It's also vital to check data integrity and UI behavior manually. When automating data transfer, rsync is efficient for fast file synchronization. docker-compose can orchestrate the entire staging environment, while cron or systemd can schedule regular backups. Python scripts are useful for custom tasks like data anonymization or structural migrations, and integrations like LDAP or web services should be disabled or redirected to test servers.

Quellen