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: Code: $sql = "INSERT INTO sys_remoteaction (server_id, tstamp, action_type, action_param, action_state, response) " . "VALUES (". (int)$this->form->dataRecord['server_id'] . ", " . time() . ", " . "'backup_restore', " . "'".$backup_id."', " . "'pending', " . "''" . ")"; 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
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
Thats on the rodmap already, please see here: http://bugtracker.ispconfig.org/index.php?do=details&task_id=1938&project=3
Thank you. I uploaded the first, incomplete version to svn and added the task details and dependencies to the bugtracker.
Does that mean there is a (at least partly) working way to migrate from Plesk to ISPConfig3? Is this available to the public? If so, where can I find it? regards, Tom
Please keep in mind that it is far from finished. Databases and some other features are not yet migrated, so it will take a while until it is usable.
Hi Marius, thanks for the warning, but that's ok with me. If only the annoying and error-prone work of copying resellers, clients, etc. would done automatically, it would be a great achievement. So I am very willing to try... I have no idea how to enable your plesk migration into a running ispconfig3 though. Is there a howto somewhere? Thank you, Tom
This is only implemented in svn, not in stable version of ispconfig. Do not use it on you production installation, as it might crash. First step: Create a (read only) database user on your plesk database. Second step: Update your ispconfig install to the latest svn version /usr/local/ispconfig/server/scripts/update_from_svn.sh Third step: As admin in your ispconfig interface got to "tools" -> Import plesk. Fouth step: Enter the plesk database details (options below are non-functional, yet). Submit the form and pray
hmm.... I'd rather not install an unstable version, but on the other hand it is not a productive system at the moment. And what is more: it is virtualized and I cound make a copy beforehand. So if i did the svn update, will I be able to update to a release version of ispconfig afterwards? Then I'd do the svn update, import from plesk and afterwards do a 'normal' update. Would that be possible?
I would not recommend doing this... it might mess up your installation switching like that. You could try to apply this on a copy of your installation just to check if the plesk import would work for you at all.
OK, I'll give you a small feedback on my first attempt: I followed your small howto... I'll just tell you all the issues that occurred to me; please don't take it as criticism. First issue is: you don't get any feedback of the GUI. At first I had a typo in my server address and did not get a warning (ping test or so). When I corrected it and the script finally started, I had no clue it did (beacause no progress/activity is shown). So I also did not know when it was finished, and if any errors had occurred (is there a log for it?) When I considered the migration finished after several minutes, the following had been done: - Resellers imported - Clients imported - dns zones imported - Domains and Aliasdomains imported - Subdomains imported as 'normal' domain (like in your description) - mail domains created, but not a single mailbox, redirect or alias - no ftp users created I did not check everything in detail yet (like limits for users) though. Concerning the sequence of tasks, does this indicate the script has stopped because of an error? regards, Tom
First of all: Thanks for the feedback, I know there's no progress indicator or anything like that, not needed for development phase I plan to split the process to a few steps just to avoid running into php execution time limits or something like that. If you get an error during the process it should either be in the syslog/web log (if it is a php error) or on the interface (db error). I have not yet come to the point where I needed further error info because the import steps are not ready, yet. As you state that you got no ftp user import, mail accounts cannot be created because they come after ftp. Either there was en error in dns import or ftp user import I think.
