Migrating IW 6.14.5 on CentOS 6 to IW 8 on AlmaLinux 9 - Assumptions & Questions

General Interworx Control Panel Info General Inquries
1

Planning a migration from IW 6.14.5 on CentOS 6 to a fresh IW 8 on AlmaLinux 9. Moving 7 SiteWorx accounts out of ~20 on the source. This is a ~15-year-old installation, so plenty of accumulated cruft that won’t be coming along. I’ve audited the source server and read through the IW8 docs. Want to validate assumptions and get answers on a few things the docs don’t cover.

(This list was generated with the help of Claude Code after a comprehensive remote audit of the source server and review of IW8 documentation.)

Source Server Summary

  • Interworx: 6.14.5-2593
  • Mail: qmail 1.03 + vpopmail 5.4.33 + Dovecot 2.3.10
  • DNS: djbdns/tinydns, zones managed in IW MySQL, data.cdb compiled directly
  • Web: Apache 2.2.34 + PHP-FPM via Remi (5.4 through 7.3)
  • DB: MySQL 5.7 community (port 3306), Percona 5.5 iworx-db (port 2307)
  • Services under daemontools: tinydns, axfrdns, dnscache, qmail smtp/send, dovecot imap/pop3

What I believe is true based on docs (confirm or correct)

1. IW 6.14.5 SiteWorx backups import into IW 8.
The .tar.gz format is cross-version compatible. Any known issues with backups from IW 6.x this old?

2. The IW 8 SSH migration tool works against an IW 6.14.5 source.
Or does it require IW 7+ on the source side?

3. DNS zones come across automatically.
Both sides use djbdns/tinydns and IW manages zones in its own MySQL. The import should recreate the zone data on the target. Correct?

4. Mail passwords transfer as-is.
Both sides are qmail + vpopmail with MySQL-backed auth. All pw_clear_passwd are NULL (hashes only). The vpopmail password hashes should be compatible between the two versions without needing user password resets.

5. MySQL 5.7 dumps import into MariaDB 10.11.
IW8 defaults to MariaDB 10.11. The SiteWorx backup includes mysqldump output. Any known gotchas with MySQL 5.7 → MariaDB 10.11 through the import process?

6. Apache vhosts regenerate in 2.4 syntax.
IW-generated vhosts will be recreated properly. Custom .htaccess using 2.2-era directives (Order/Allow/Deny) will need mod_access_compat or manual fixes. At least one account has an IW-generated IP deny list using Order deny,allow syntax in its .htaccess - that’ll 500 on Apache 2.4 without the compat module.

7. Redirect and pointer domains transfer with the account.
I have Interworx-configured redirect domains and a pointer domain. These should come across with the SiteWorx import since they’re in the IW database.

Questions the docs don’t answer

Q1. What happens when an imported account references a PHP version unavailable on the target?
Source accounts use PHP 5.4-7.3 via Remi. Some of the accounts being migrated are actively assigned to PHP 7.3 FPM pools. On AlmaLinux 9, Remi doesn’t provide anything below 7.4. Does the import fail, fall back to the system default, or import with a broken PHP-FPM assignment? Want to know whether to pre-install PHP versions or just plan for post-import fixup.

Q2. Migration tool vs. backup/import - which is recommended for this version gap?
Only 7 accounts, but one has a ~2 GB MySQL database. Is one approach more reliable than the other when going from IW 6.x to IW 8? The docs mention the migration tool is better for large accounts and warns about timeouts during import — is that size likely to cause issues with the backup/import approach?

Q3. What does the import recreate in MySQL?
Two related concerns:

  • Vpopmail: User records (pw_name, pw_domain, pw_passwd, etc.) live in iworx_vpopmail on port 2307. Does the SiteWorx backup capture and restore these records, or does it import Maildir files and regenerate vpopmail entries from IW’s own account data?
  • Database users/grants: The source server has MySQL users with Interworx-style truncated names (e.g., <acct>_<dbuser>@localhost with grants on <acct>_<dbname>.*). There are also % host users for some accounts. Does the import preserve these existing users and grants as-is, or does it recreate them? If recreated, will the usernames and passwords match what’s already in wp-config.php? Multiple WordPress sites depend on these credentials matching.

Q4. Is /chroot/home/ still used for FTP jailing in IW 8?
Old server has jailkit-based chroot at /chroot/home/ sharing inodes with /home/. The FTP docs don’t mention the chroot path structure. Does IW 8 still work this way, or has the jailing mechanism changed?

Q5. Will the import process touch custom Apache configs in conf.d/?
If I put custom files in /etc/httpd/conf.d/ on the new server before importing (e.g., a mod_remoteip config for Cloudflare), will the import leave them alone or overwrite?

Q6. Is there an upgrade path from VPS to dedicated license?
We’re planning to start with the VPS license. If we later need to move to a dedicated license (more than 4 vCPUs or clustering), is there a self-service upgrade path or do we contact billing?

Things we plan to verify post-import (heads up if you know of gotchas)

  • CMS database credentials - Multiple WordPress sites across the migration accounts. After import, the DB host, socket path, username, and password in wp-config.php may not match the new server. Planning to check and update these manually, but if the import handles credential rewriting, that’d be good to know.
  • Dovecot IMAP subscriptions - Source server has courier-imap installed alongside Dovecot (likely a leftover). If the import picks up stale Courier subscription files instead of Dovecot’s, that could cause minor issues for IMAP clients.
  • Large database import time - One account has a ~2 GB MySQL database. Will verify it imports completely and doesn’t time out.

Thanks in advance. Happy to provide more detail on any of the above.

– Mike

2

Hi johan-hammy

I have recently completed what your asking do talking from experience

most of your post is straightforward and probably overthinking things

You cannot install php lower then 7.4 on almalinux 9 due to mainly wrong packages such as SSL etc… but please research yourself

So any siteworx accounts which use older php then 7.4 would use the default set php from Apache in nodeworx - this may not be system php if set differently

A good note here is make sure all php packages you would have used are installed and set php memory and upload limits as you need prior to importing

MySQL had no issues with 5.7 to 10.11

The imports or server to server transfers for siteworx accounts do not transfer and conf.d files

note Cloudflare has changed and be careful with CF if using Google seo due to AI bots and arguments over CF suggesting Google should pay or have direct permission for AI bots.

All siteworx passwords and credentials for email siteworx etc… remain the same

The SSL will need to be regenerated for siteworx accounts as these would not be transferred

Changing IW licences from VPs to dedicated, simple ask your billing and apart from a little change is all that’s needed to change license

I have to go now but if you need to be sure, either create a test siteworx account on each server and transfer then test for credentials

Many thanks

John

1 Like
3

Hello–

Just a a note, please do not ever use any kind of AI, including Claude, to get answers for questions related to InterWorx. It has a tendency to just make things up a significant amount of the time. I spend a large part of my week trying to piece servers back together after folks have followed completely made up AI instructions, and multiple customers have essentially bricked their servers due to following AI instructions.

We never, ever recommend it. Please do not use it at all in anything related to your migration. If you have questions or need assistance, just reach out to us at support.interworx.com.

If you would like a demo key to assist with the migration, let us know at support.interworx.com.

Also, if the other 13 accounts are working, live accounts, it is imperative that you also migrate those to IW8/EL9. CentOS 6 has been EOL for six years, now. It is a huge, huge security risk to have anything on that server.

To answer each of your questions:

1. IW 6.14.5 SiteWorx backups import into IW 8.

Yes, IW6 backups can be migrated to IW8. InterWorx 8 also has a new migration tool, which doesn’t use the backup system at all, which may also be helpful, especially if you have any large accounts: How to: Import Hosting Accounts to InterWorx — InterWorx documentation

Note: it doesn’t work the other way, though. If you import an account from IW6 > IW8, you would not be able to take a new backup and migrate it back to the IW6 server (which I’ve seen some customers attempt to do). Our backups are always forward compatible between major versions, but never backwards compatible.

2. The IW 8 SSH migration tool works against an IW 6.14.5 source.

I don’t what you specifically mean by “SSH migration tool”. However, both the new migration tool, and the standard mass import tool (which uses the backup system) both will work from IW6 > IW8.

3. DNS zones come across automatically.

Correct, using the migration tool, mass import tool, or importing a single backup, the new zone will be created and will bring over any custom DNS records from IW6.

4. Mail passwords transfer as-is.

Correct, mail passwords should not change between versions.

5. MySQL 5.7 dumps import into MariaDB 10.11.

As far as I am aware, dbdumps from MySQL 5.7 should be able to import to MariaDB 10.11.

However, I cannot tell you if there are any specific gotchas because, frankly, I have not heard of anyone who has made that kind of jump.

We do not directly support the system MySQL/MariaDB instance, so this is something that you might what to do some googling on, or test for yourself

6. Apache vhosts regenerate in 2.4 syntax.

IW8 uses an entirely different vhost template system than IW6 (as did IW7). Any manual changes that may have been made to vhosts may not be brought over in the import. They will need to be re-added using the new template system or as an Apache include.

Also, yes, you will most likely need to update and 2.2 specific syntax in htaccess files to be compatible with 2.4. I cannot speak to any specifics, though,that is something that you will need to make note of and test during the migration.

7. Redirect and pointer domains transfer with the account.

Yes, redirects and pointer domains will be migrated. They are part of the basic account structure.

Questions the docs don’t answer

Q1. What happens when an imported account references a PHP version unavailable on the target?

If an account is set to use a PHP version that is not installed or not available on the server, the account will automatically be set to the system PHP version.

On InterWorx 8, multiple PHP is enabled by default. All of the available PHP versions for EL9 will be listed in that section on the Webserver page in NodeWorx. You are correct that you will not be able to install anything lower than 7.4, as lower versions are not available on EL9: How To: Manage PHP Versions in NodeWorx — InterWorx documentation

If, after you import the account, you want to set the PHP version to something other than the system version, that is possible: How To: Manage Multiple PHP Versions for SiteWorx Accounts — InterWorx documentation

and How To: Change the PHP Version For a Domain — InterWorx documentation

If you need legacy versions of PHP, CloudLinux may be a good option for you, as they offer old, EOL PHP versions through their system (note, we do not directly support the PHP versions provided by CloudLinux): How To: Install and Enable the CloudLinux Plugin for InterWorx — InterWorx documentation

Q2. Migration tool vs. backup/import - which is recommended for this version gap?

We do not have any recommendations, as all options will work.

Migrating via a backup (including with the mass import tool) can be an issue if the account is larger than 8-10G. A 2G account should be fine if you want to go that route.

Either way would work fine with accounts that are smaller than 8G or so, though. It’s all up to you.

The main difference between the two is that the mass import tool migrates the accounts one by one, whereas the migration tool imports things in steps. So it creates all of the accounts, and then imports all of the databases, and then imports all of the email, and then rsyncs all of the web files, etc.

Q3. What does the import recreate in MySQL?

  • Vpopmail: All of the data in the iworx_vpopmail database will be migrated over. That is part of the basic account data
  • DB users/grants: the mysql dump will include all of this information and importing the dump will import it.

You should not need to make any password changes after the import.

Q4. Is /chroot/home/ still used for FTP jailing in IW 8?

As far as I am aware, nothing has changed, here.

Q5. Will the import process touch custom Apache configs in conf.d/?

Importing accounts only does just that–import accounts. Nothing about the import process would have anything to do with non-vhost files under /etc/httpd/conf.d, as those files are not associated with your accounts.

The only thing the import process touches under that directory is creating the vhosts.

Q6. Is there an upgrade path from VPS to dedicated license?

VPS licenses cannot be changed to dedicated licenses. If you were to change your license type, the steps would be:

Things we plan to verify post-import (heads up if you know of gotchas)

  • CMS database credentials - Multiple WordPress sites across the migration accounts. After import, the DB host, socket path, username, and password in wp-config.php may not match the new server. Planning to check and update these manually, but if the import handles credential rewriting, that’d be good to know.

Nothing should be re-written at all. The wordpress config files will be moved over and any information in the database will also just be imported with the database. Nothing related to InterWorx changes anything associated with Wordpres.

  • Dovecot IMAP subscriptions - Source server has courier-imap installed alongside Dovecot (likely a leftover). If the import picks up stale Courier subscription files instead of Dovecot’s, that could cause minor issues for IMAP clients.

Courier files will not be included in the import, at all.

  • Large database import time - One account has a ~2 GB MySQL database. Will verify it imports completely and doesn’t time out.

There should not be any timeout issues with a 2G DB. Again, that concern is for accounts that are larger than 8-10G.

If you have any other questions, let me know.

Thanks,
-Jenna
Friendly Neighborhood InterWorx Support Manager

1 Like
4

Thanks a bunch @IWorx-Jenna and @d2d4j .

5

Hello–

I did just notice that you are still using CentOS 6 on the old server. All of your questions focuses specifically on the IW version and I didn’t think about the OS, yesterday.

There is a possibility that you may run into issues with SSH between the two servers, due to old, insecure ciphers and such on the C6 server. EL9 may not accept them.

If that does happen, you’ll just need to make single backups, move them to the Destination server via FTP, SCP, rsync, etc, and import them individually: How to: Import Hosting Accounts to InterWorx — InterWorx documentation

Thanks,
-Jenna

1 Like
6

I did run into that SSH issue, and here’s how Claude got me through it.

Setup

Source Server (CentOS 6)

# Edit sshd config
nano /etc/ssh/sshd_config
# Change line 43 to:
# PermitRootLogin without-password

# Restart SSH
/etc/init.d/sshd restart

Destination Server (AlmaLinux 9)

# Get the root public key to add to the source
cat /root/.ssh/id_rsa.pub
# Copy this output — you'll need it on the source server

Back on source server:

# Add destination's public key to authorized_keys
nano /root/.ssh/authorized_keys
# Paste the public key from the destination server, save

# Ensure correct permissions
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Back on destination server:

# Add legacy algorithm support for the source host
nano /root/.ssh/config
# Add the following block:
# Host <source-hostname-or-ip>
#     HostKeyAlgorithms +ssh-rsa,ssh-dss
#     PubkeyAcceptedAlgorithms +ssh-rsa
#     KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
#     Ciphers +aes128-cbc,aes256-cbc,3des-cbc

# Set legacy crypto policy
update-crypto-policies --set LEGACY

# Reboot to apply crypto policy
reboot

# After reboot, test the connection
ssh root@<source-hostname-or-ip>
# Should land you at the source server root prompt

Teardown

Source Server (CentOS 6)

# Remove destination's public key from authorized_keys
nano /root/.ssh/authorized_keys
# Delete the line containing the destination server's key

# Revert sshd config
nano /etc/ssh/sshd_config
# Change line 43 back to:
# PermitRootLogin no

# Restart SSH
/etc/init.d/sshd restart

Destination Server (AlmaLinux 9)

# Remove legacy SSH host config
nano /root/.ssh/config
# Delete the entire block added for <source-hostname-or-ip>

# Restore default crypto policy
update-crypto-policies --set DEFAULT

# Reboot to apply
reboot

Verify source is no longer accessible:

ssh root@<source-hostname-or-ip>
# Should fail — root login is disabled and legacy crypto is gone
7

I’m now hitting an error during the analyzer phase of the migration tool:

Action Level Message Details Output Phase Step Task Error Code
Resolve / Retry / Rescan & Retry fatal analyzer error Analyzer - command failed: cd /tmp; sudo /home/interworx/bin/php /tmp/interworx-migration-analyzer.phar --test-mysql-connection --username root ERROR: root is unable to connect. initialization collect_server_info validate_mysql_connection 596

Running the same command manually on the source server produces the same result:

Detected InterWorx: 6.14.5
ERROR: root is unable to connect.

The migration tool provides no MySQL credential input in the web UI. Has anyone encountered this and know what needs to be configured on the source server to allow the MySQL connection check to succeed?

8

Fix for “root is unable to connect” (Error Code 596)

Root cause: The database_servers table in the internal Interworx MySQL instance stores a DSN using the mysql:// prefix, which I believe routes to PEAR DB’s old mysql extension driver. PHP 7.2 removed the mysql extension entirely, so the connection fails regardless of credentials.

Step 1 — Find the iworx-db credentials

The internal Interworx MySQL instance credentials are stored in /home/interworx/iworx.ini:

grep "dsn" /home/interworx/iworx.ini | grep "iworx-db.sock"

Look for the line containing mysql://iworx: — the password is between the colon and the @ symbol.

Step 2 — Connect to the internal MySQL instance

mysql -u iworx -p'<password-from-iworx.ini>' -S /home/interworx/mysql/iworx-db.sock iworx

Note: during diagnosis we also investigated whether root needed access to the internal iworx-db instance, including using --skip-grant-tables to bypass authentication. In the end this was not necessary — the iworx user credentials from iworx.ini are sufficient.

Step 3 — Verify the problem

SELECT * FROM database_servers;

The DSN column will show mysql:// where it should be mysqli://.

Step 4 — Apply the fix

UPDATE database_servers SET dsn=REPLACE(dsn, 'mysql://', 'mysqli://') WHERE id=1;

Step 5 — Verify the fix

SELECT * FROM database_servers;

The DSN should now start with mysqli://.

Step 6 — Exit and test

EXIT;

Re-run the migration tool. The MySQL connection check should now pass.

Back out if needed

mysql -u iworx -p'<password-from-iworx.ini>' -S /home/interworx/mysql/iworx-db.sock iworx


UPDATE database_servers SET dsn=REPLACE(dsn, 'mysqli://', 'mysql://') WHERE id=1;
EXIT;
9

Bug: Migration Analyzer Fails with “Attempt to assign property of non-object” When Source Server Has Pointer Domains

Environment: Interworx 6.14.5 (CentOS 6) → Interworx 8.2.9 (AlmaLinux 9)

Error:

/home/interworx/tmp/get_domains.php failed with: Attempt to assign property
'dns_zone_records' of non-object

Surfaced in the migration UI as error 596: “Failed to get domains.”

Trigger: Any pointer domain on the source server — confirmed with both Server Alias type and 302 Redirect type. I assume 301 Redirect type would trigger it as well, but did not test that specifically.

Location in generated script (/home/interworx/tmp/get_domains.php):

function getPointerDomains($domain)
{
    $pointerdomains = swRouteFromPhp(
        $domain,
        'Ctrl_Siteworx_DomainsPointer',
        'listPointerDomains',
        __FUNCTION__
    );
    foreach ($pointerdomains as $pointerdomain) {
        $pointerdomain->dns_zone_records = getDnsZoneRecords($pointerdomain->domain);
    }
    return $pointerdomains;
}

I think the issue is that listPointerDomains in Interworx 6 returns data in a format where the elements are not objects, while the IW8 migration phar’s generated script assumes they are. The relevant Interworx 6 source files (Ctrl/Siteworx/DomainsPointer.php, DataSource/SW/Domains/Pointer.php) are ionCube-encoded, so I cannot confirm this directly. Other controllers called by the same script use identical -> property access and work correctly, so the issue appears specific to this controller.

The get_domains.php file is regenerated on each migration run, making a persistent patch impractical without a fix from Interworx.

Workaround: Remove all pointer domains from the source server before running the migration analyzer. Note their configuration first so you can recreate them manually on the destination server after migration completes.

10

Hello–

Thanks for that information.

Please use single account backups for your migration, especially since your very very old OS is going to add extra complications.

Also, I really cannot stress how much we do not ever advise ever taking advice from AI, including Claude. Multiple customers have essentially bricked their servers, and completely corrupted their installations by doing so.

Thanks,
-Jenna