At least one other Control Panel system has the ability to export an entire account, including but not limited to:
- account passwords,
- parked domains,
- email accounts including email data,
- email forwarders, and, of course,
- databases including users, passwords, and privileges,
- the website data.
Obviously this is a complex operation. Moving between existing systems that are the same still has issues such as naming conflicts. However, the format of the export itself is simply constructed as a tar file with a known stucture, so should be relatively easy to parse.
The things we need to worry about here are:
Block the import
- if the file is missing integral data (such as an account user or password)
- if the integral data (account user, domain, database name, email address, etc.) is already in use on the destination server and doesn't match.
Warn and ask the user to confirm on import
- if the import contains data that is not supported by the system (e.g. installing a mysql database on a server that doesn't have mysql)
- if the integral data does match, but the other data is different (to allow an account merge, for example)
We can test this by constructing a small set of import files that should pass or fail these tests.
I think this is an import-ant (:-p) step we need to take. I personally run many of these other systems, and it's in my company's interest to support Open Source software such as zpanelx. (We'd rather pay a "support fee" than a "license fee".) However, the barrier to entry for us is moving clients from one server to another with as little downtime as possible.
When I get time, if noone else has moved forward on it, I'll contribute some code. In the meantime, this is a feature request to remind me that I need to do that.
At least one other Control Panel system has the ability to export an entire account, including but not limited to:
Obviously this is a complex operation. Moving between existing systems that are the same still has issues such as naming conflicts. However, the format of the export itself is simply constructed as a tar file with a known stucture, so should be relatively easy to parse.
The things we need to worry about here are:
Block the import
Warn and ask the user to confirm on import
We can test this by constructing a small set of import files that should pass or fail these tests.
I think this is an import-ant (:-p) step we need to take. I personally run many of these other systems, and it's in my company's interest to support Open Source software such as zpanelx. (We'd rather pay a "support fee" than a "license fee".) However, the barrier to entry for us is moving clients from one server to another with as little downtime as possible.
When I get time, if noone else has moved forward on it, I'll contribute some code. In the meantime, this is a feature request to remind me that I need to do that.