Znuny Staging System – Migration and Secure Test Environment

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.

Compatibility: The steps described in this article apply to Znuny 6.x+. Configuration files are consistent and are marked where necessary.

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)

Benefits of a Staging System

• 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

Prerequisites

• 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)

Step-by-Step Guide

1. Build the staging system

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.

2. Clean up the dev system

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.

3. Copy production data

Database:

# 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.

4. Adjust configuration

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.

5. Prevent email dispatch

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.

Tests in Staging

• 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

Secure the Staging System

• 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

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

Example Tools for Automation

• 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

Conclusion

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.