Skip to content

Znuny Staging System – Migration and Secure Test Environment

A staging system is the perfect environment for safely testing changes to the ticket system — for Znuny. It is an exact copy of the production system where functions, configurations, and data are migrated, tested, and validated — without affecting the live system.

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 with, e.g., Playwright
  • GDPR-compliant testing after anonymization
  • Recovery tests & backup verification
  • Ubuntu 20.04+ or Debian 10+
  • Docker Compose (recommended) or official Linux installation
  • Sufficient system resources (8 GB RAM, 4 CPUs)
  • Access to current production data (DB & file system)
  • Ability to disable email dispatch (e.g., via dummy SMTP)

A Docker Compose installation is the fastest way to spin up an isolated staging instance:

  1. Follow Installing Znuny with Docker Compose on a separate VM or host.
  2. Use a different compose project name or directory than production so volumes do not collide.
  3. Complete the web installer with a separate database (empty schema).
  4. For ongoing operations, see Znuny Docker (backups, console commands, updates).

For bare-metal staging, follow the official installation guide on a dedicated server.

If you are using a dev system as a base:

  • Remove test tickets and agents you do not need.
  • Reset SysConfig values that point to production URLs, LDAP, or mail servers.
  • Verify no production API keys or web service credentials remain.

Database:

Terminal window
# On production (example for MariaDB)
mysqldump -u root -p znuny > znuny-prod-$(date +%F).sql
# On staging — import into the DB container
docker compose exec -T db mysql -u root -p znuny < znuny-prod-$(date +%F).sql

File system / volumes:

Copy the var directory (attachments, sessions) from production. On Docker stacks, this is typically the znuny-var volume — see volume backup.

Data privacy: Anonymize all production customer data, e.g., in the customer_user table, or remove email addresses using an SQL script before sharing the staging environment with testers.

In SysConfig on staging:

  • Set the system FQDN and HTTP URLs to the staging hostname.
  • Point LDAP and external integrations to test endpoints or disable them.
  • Lower cache TTL if you need faster feedback during testing.

In SysConfig:

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

Re-run Maint::Config::Rebuild and Maint::Cache::Delete in the app container after bulk SysConfig changes.

  • Use Playwright or Cypress scripts for UI tests
  • Use bin/znuny.Console.pl Maint::Test::System
  • Check data integrity & UI behavior
  • Disable integrations like LDAP or web services, or redirect them to test servers
  • 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)

Once testing is complete in staging:

  1. Stop the 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 structure migration

A Znuny staging system offers maximum security when introducing changes. Through structured migration, anonymized test data, and automated tests, you avoid downtime and ensure stable deployments.

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

Znuny Hosting & Maintenance

Worry-free Znuny operations: Softoft manages hosting, staging setups, regular patching, automated backups, and proactive monitoring.

Frequently asked questions

Why is a Znuny staging system crucial for safe system changes?

A Znuny staging system is an indispensable tool for maintaining the stability and reliability of your live ticket system. It serves as an exact, isolated copy of your production environment, allowing you to thoroughly test new functions, configurations, custom code, packages, and migrations without any risk to the operational system. This environment facilitates automated end-to-end tests using tools like Playwright, ensures GDPR compliance through data anonymization, and can even be used for critical recovery tests and backup verification. By identifying and resolving potential issues in staging, you proactively prevent downtime and ensure a smooth, stable deployment to production.

Quellen

How do I prevent the Znuny staging system from sending real emails?

To prevent your Znuny staging system from inadvertently sending real emails, which could lead to accidental communication with customers or external services, you have two primary methods. The recommended approach is to adjust the SendmailModule setting within SysConfig. Change its value to Kernel::System::Email::DoNotSendEmail. Alternatively, you can reconfigure the SMTP server settings to point to a dummy host, such as 127.0.0.1 on port 1. This effectively redirects all outbound mail to a non-existent destination. After making significant SysConfig changes, it's crucial to re-run Maint::Config::Rebuild and Maint::Cache::Delete in the application container to ensure the new settings are applied and the cache is cleared.

Quellen

What are the key prerequisites for setting up a Znuny staging system?

Setting up a robust Znuny staging system requires several key prerequisites to ensure a smooth and effective testing environment. You'll need a compatible operating system, such as Ubuntu 20.04+ or Debian 10+. For the Znuny installation itself, using Docker Compose is highly recommended due to its ease of setup and isolation, though an official Linux installation is also an option. Sufficient system resources are vital, with at least 8 GB RAM and 4 CPUs being a good baseline. Crucially, you must have access to your current production data, including both the database and the file system, to create an accurate copy. Finally, the ability to disable email dispatch on the staging system, for example, by configuring a dummy SMTP server, is essential to prevent unintended communication.

Quellen

How can I ensure customer data privacy (GDPR) when using production data on a staging system?

Ensuring customer data privacy, especially in compliance with regulations like GDPR, is paramount when using production data on a staging system. It is absolutely critical to anonymize all sensitive production customer data before granting testers access to the staging environment. This typically involves modifying or removing identifying information from database tables such as customer_user. For instance, email addresses can be removed or replaced with dummy values using SQL scripts. The goal is to create a realistic testing environment without exposing actual customer identities or personal data. This step transforms the staging system into a GDPR-friendly space, allowing thorough testing while safeguarding privacy.

Quellen

What is the recommended approach for building a Znuny staging system and copying production data?

The recommended and most efficient approach for building a Znuny staging system involves using Docker Compose. Begin by installing Docker Compose on a separate virtual machine or host, distinct from your production environment. When setting up, ensure you use a different Docker Compose project name or directory to prevent volume collisions with your live system. Complete the initial web installer with an empty database schema. For copying production data, first, create a database dump from your production system (e.g., mysqldump -u root -p znuny > znuny-prod-$(date +%F).sql) and then import it into your staging database container. Simultaneously, copy the var directory (which contains attachments and sessions) from production; for Docker stacks, this typically means backing up and restoring the znuny-var volume. Remember to anonymize all production customer data before making the staging environment accessible to testers.

Quellen

What configurations should be adjusted in SysConfig after copying production data to staging?

After copying production data to your Znuny staging system, it's essential to adjust several configurations within SysConfig to ensure the staging environment operates correctly and remains isolated. First, update the system's FQDN (Fully Qualified Domain Name) and HTTP URLs to reflect the staging hostname. This prevents staging from linking back to production resources. Next, redirect or disable any LDAP and external integrations, pointing them to dedicated test endpoints or turning them off entirely to avoid unintended interactions with live services. Additionally, you might consider lowering the cache TTL (Time To Live) if you require faster feedback during your testing cycles. These adjustments are crucial for maintaining the integrity and isolation of your staging environment.

Quellen