Migrating to ISPC3 from other panels (here: plesk)
 

I don't know if this discussion has already been there, but I didn't find any.

I am using ISPC3 nearly since it came out, but one of my servers is still running plesk. This is because there are some customers on it, that I do not want to bother with recreating their mail addresses and passwords and so on.

I did some analysing on the plesk database and found that (at least on my server) all passwords are stored in plain text. So it should be possible to migrate all the data to ISPC without having to recreate any passwords for the customers.
I don't know when I will have enough spare time, but I plan to write a "simple" migration script that converts from plesk to ISPC3 via the remote API. This script should also copy over all the web contents from the plesk server and automatically change the web root inside of the web files.

What I like to ask is, whether I should try to implement this as a feature of ISPC or as a standalone script. Usually I use perl for this kind of work, this would be a standalone script of course.

In my opinion you should use the technology that you know best. A standalone script would be fine as a migration need special permissions like ssh root access to copy data anyway which you would not allow gennerally trough the ispconfig interface.

That's right. I just thought about it as an feature to ispc because I saw the email import feature in the tools section.
So all the things like email addresses, databases, webs and so on (without the data) could be done inside of ispc.
Copying over the database contents could be done inside ispc, too.
If you make it mandatory to use a locally stored tar.gz with all the web data to restore you could do this via the ispc server scripts.
That's the reason why I asked myself if it would be an "upgrade" to ispc having such a feature.

It would be great of course if you could implement it in ispconfig directly :)

Such a script requires actions as root user, so it has to be be splitted into a interface part where you can define the settings like remote server IP, root password and database login. The interface part then writes the config data as an action to the sys_remoteaction and a server side plugin must be registered for the action event and start the migration. So there is no need for a additional database table for such a job. The new action framework has been added in SVN and will be part of 3.0.5.

A SQL query to insert a action might look like this:

Instead of the $backup_id you can also add several parameters as serialized array.


For the server side plugin, see new backup plugin as example for using the actions framework:

/usr/local/ispconfig/server/plugins-available/backup_plugin.inc.php

Ok, thank you for the information, I will try to give it a shot :)

I currently implement the structure import (clients, dns and so on) without web/db/email data first.
What exactly is the content of the "NS" field in the dns_soa.tform?
I think "origin" is the zone hostname (domain) but I couldnt figure out the ns entry, as it simply validates /^[\w\.\-]{1,255}$/

The ns column is the first nameserver of the zone.

Yes.

The table columns are based on the mydns specification:

http://mydns.bboy.net/doc/html/mydns_9.html#SEC9

So this is the status so far:

Works:
- importing client with their limits, contact data and passwords
- importing domains (created as mail domain, too)
- importing alias domains (created as mail domain, too)
- importing subdomains*
- importing dns_zones and records
- importing mail addresses including passwords
- importing mail redirects and aliases
- importing autoresponders**
- importing ftp accounts


Doesn't work yet:
- importing protected folders
- importing web(dav)_users
- importing spamfilter settings
- importing databases***
- importing database contents
- importing web contents from tgz

During import it is checked if the entry already exists. If it does, it is updated and not re-inserted.
There are no customizations available (, yet) so it's always a complete import.


* created as domains because they are vhosts in plesk
** plesk has no start/end dates for responders so if a responder is enabled in plesk i set the end date to one year in the future
*** as plesk uses multiple database users for each database, I have to implement this first: http://www.howtoforge.com/forums/showthread.php?t=57628

I realized folder protection is not part of the remoting yet. Is it in progress or at least in BT?

Thats on the rodmap already, please see here:

http://bugtracker.ispconfig.org/inde...1938&project=3