Dipak D. Kuthe · Originally published May 16, 2026 as “Vicidial Installation Guide on Rocky Linux 9 (2026 Edition).” This revision replaces the old installation walkthrough with compatibility and migration guidance.
VICIdial can be assembled on Rocky Linux 9 through third-party procedures, but CoreSecTech found no official Rocky Linux 9 installation image or release-specific support commitment from the VICIdial project. If Rocky Linux is mandatory, validate the exact stack on an isolated host before relying on it. If the operating system is flexible, evaluate ViciBox, the official openSUSE-based installation image, and check the support status of the entire stack before planning a production rollout. VICIdial project · Official ViciBox downloads
What works on Rocky Linux 9?
VICIdial uses Asterisk for telephony, a web interface for agents and administrators, a database for application data, and Perl processes for background tasks. A package being available for Rocky Linux establishes very little about whether calls, agent login, scheduled jobs, recordings, and recovery work together.
If Rocky Linux 9 is mandatory, identify who maintains the installation procedure and who supplies security updates for each component. Validate the exact stack in isolation. If the operating system is flexible, evaluate the official ViciBox image in an isolated lab and confirm maintenance coverage before choosing it for production.
For a live migration, keep the existing system available while you verify agent login, inbound and outbound test calls, two-way audio, and backup restoration on the candidate. Agree on a rollback trigger and allow only one system to place live campaign calls during cutover. CoreSecTech did not run these installation or migration tests.
| Path | What the evidence supports |
|---|---|
| Official ViciBox ISO | The VICIdial project documents this openSUSE-based installation path. The release and dependency lifecycle still need checking. |
| Third-party Rocky Linux 9 build | One provider documents a specific mix of PHP 8.3, MariaDB 10.11, an Asterisk 22 build, and Perl dependencies drawn in part from EPEL. It also documents using permissive SELinux. These are that provider’s choices, with no CoreSecTech installation verification. |
| A different Rocky Linux stack | Compatibility remains unverified until the specific repository, packages, application revision, schema and SIP driver are tested together. |
For an existing deployment, record the package versions and origins, including AppStream selections, CRB or EPEL dependencies, and any custom RPMs. Check the PHP runtime serving web requests, its database extensions, the MariaDB server version and application schema, and the Perl modules needed by scheduled and background jobs. Verify who supplies updates for each component. Third-party Rocky Linux procedure · Rocky Linux repository guidance
Why the historical installation procedure was retired
The original article’s installer archive returned HTTP 404 during review. Its provenance, contents, dependency versions, and compatibility could not be established. Updating the OS, setting a stable hostname, and installing general utilities are useful preparations, but they do not install or validate VICIdial. The original seat estimates and installation time lacked workload evidence.
Verify the Asterisk SIP driver and media path
The old trunk example used legacy chan_sip configuration, including relaxed matching, and commands such as sip reload and sip show registry. Asterisk removed chan_sip in version 21. Before moving to PJSIP, inventory the actual endpoints, dialplan contexts, carrier authentication mode, DID mapping, codec and transport settings, and how configuration is generated. A registration status check applies only to a trunk configured to register. A connected call establishes signaling success, while two-way audio must be tested independently. The old TCP-only port check could not verify UDP signaling or RTP. Asterisk SIP driver status · Asterisk PJSIP NAT guidance
Keep SELinux, the firewall, and HTTPS in place
The old procedure stopped and disabled firewalld and made SELinux permissive. On Rocky Linux, keep SELinux enforcing. Investigate logged denials and verify supported file labels or narrowly scoped policy changes. Treat an unresolved denial as a release blocker. Keep management and database access private, and restrict SIP signaling and media to the paths required by the actual carrier and endpoints. Derive allowed addresses, transports, and ports from the deployed configuration. Preserve console access before changing network policy.
Use trusted HTTPS before entering admin or agent credentials. Verify hostname, certificate chain, renewal and expiry monitoring. Restrict administrative access and move credentials through an approved secret store. Rotate initial credentials before enabling access. Rocky Linux SELinux guidance · Rocky Linux firewall guidance · Asterisk network security
Is ViciBox a better migration target?
As checked November 14, 2026, ViciBox lists 12.0.2 as stable and 13.1.0 Beta 6 as test-only. The stable 12.0.2 image shipped with openSUSE Leap 15.6 and Asterisk 18, both past upstream end of life. The ViciBox 12.0 advisory requires PHP 8.2.35 or later for the affected environment. That fix does not extend the lifecycle of the OS or Asterisk. Use the version-specific manual and confirm maintenance for the complete stack before selecting a production target. If maintenance cannot be established, defer the rollout or evaluate another supported deployment. ViciBox release history · ViciBox release announcements · ViciBox security notices · openSUSE lifecycle notice · Asterisk lifecycle
See the ViciBox installation guide for the documented lab workflow and its release limitations.
Plan the migration from an existing Rocky Linux server
Planning checklist. CoreSecTech did not install, migrate, place calls, restore backups, or execute rollback for this guide.
Inventory and back up before building the target
- Record the Rocky Linux release, VICIdial revision and schema, Asterisk version and SIP driver, database version and storage engines, PHP runtime, Perl dependencies, and service ownership.
- Inventory trunks, DIDs, codecs, endpoint registrations, dialplan, agent accounts, permissions, campaigns, lists, dispositions, schedules, and recording policy.
- Map IPs, DNS names and TTLs, carrier allowlists, firewall and NAT paths, TLS certificate and renewal dependencies, recording mounts, prompts, application files, and scheduled tasks.
- Confirm the target’s documented database and application upgrade path. Rehearse conversion with copied data in isolation. Verify tables and application behavior before cutover.
- Back up the database, recordings, and managed configuration with restricted storage and independent recovery access. Check dump completion and restore the backup on the target version. An all-databases compressed dump alone cannot verify consistency or recover files outside the database. Verify representative campaign records and required recordings after restore. MariaDB upgrade guidance · MariaDB restore guidance
Test the target before switching traffic
Keep live trunks and automatic dialing disabled during restore. Use sanitized data where possible. When an authorized test route is available, use one test agent and destinations under your control.
| Test | Expected result |
|---|---|
| HTTPS and management | Browser validates the hostname and chain. Administrative services are reachable through approved paths only. |
| Agent and campaign | The test agent joins the intended campaign, the phone connects, and the correct controls appear. |
| Inbound and outbound | A test DID reaches the intended group and fallback. A manual outbound call reaches the approved destination. Both calls have two-way audio. |
| Recording and reporting | Disposition and reporting reflect the test. If recording is enabled and approved, the authorized user can retrieve it. |
| Recovery | A version-matched restore recovers the required database records, configurations, and recordings within the agreed targets. |
For one-way audio, compare the negotiated media path with expected NAT and firewall policy. For agent login issues, verify web credentials, campaign permissions, and the phone separately. If an inbound call reaches the wrong group, check the DID mapping, queue eligibility and fallback. Stop the cutover when a required check fails. Single-agent call flow and verification
Decide who can roll back and what they will restore
Record the deadline and triggers for rollback, such as failed inbound routing, one-way audio, or missing campaign data. Preserve the original deployment and keep it available without running the same dialing campaign on both systems. On rollback, stop traffic on the candidate and restore the prior carrier routing, DNS, or IP dependencies as appropriate. Recheck inbound and outbound traffic and allow for cached DNS where applicable. Reconcile new leads, dispositions and recordings before reopening service. After a schema migration, follow the rehearsed version-matched restore plan and verify the effect of reverting before switching back.
Frequently asked questions
Can I use a third-party Rocky Linux 9 installer in production?
Only after you can establish package provenance, patch ownership, effective SELinux and firewall controls, and repeatable call and recovery results for the exact build. A vendor’s successful test of its own installer does not validate your stack.
Can I copy my old SIP and database configuration into ViciBox?
Use the old configuration as inventory. Translate SIP settings for the target driver, and validate database and schema compatibility on a restored copy. A direct copy can preserve old assumptions about authentication, paths, IPs, and versions.
Bottom line
If you need a verified Rocky Linux installer, this guide provides the checks required to qualify one. If you’re moving an existing dialer, choose a maintained target and make controlled call tests and a rehearsed restore part of the cutover decision.