Best way to test drive a migration?

Discussion in 'Installation/Configuration' started by toolforger, Oct 5, 2013.

  1. toolforger

    toolforger New Member

    I need to migrate a medium-sized root server from SysCP to ISPConfig.
    Points I need to consider:
    • The root server is accessible only via SSH. If things go ugly I can use a rescue system and/or a KVM switch, but things are getting slow.
    • I have to deal with approx. 50 users, 150 domains, 300 mail accounts.
    • Minimize downtime. Half a day once is acceptable, daily half a day over a couple of weeks until I get the last migration problem fixed is not.
    • Migrating passwords. Can ISPConfig decode whatever password formats SysCP might have used in its lifetime, or do I need to tell users to reset their passwords? (Some users are really incompetent and will have serious trouble with that.)
    • I'd like to test drive the migration inside a virtual machine. Optimally, that would be a whole virtual network consisting of a virtual DNS root, mail senders and recipients, and HTTP client. I suppose this virtual environment is best setup on my local machine, just to test the migration. Does anybody have pointers to recipes for doing this?
    • The existing server runs a Ubuntu LTS. I'm considering switching back to Debian, or possibly something that updates a bit quicker without sacrificing stability. However, the prime factor for selecting a distro would be "what ISPConfig runs best on", simply because the machine's primary purpose will be to serve ISPConfig-managed domains.

    Optionally, I'd like to add this:
    • Migrate the web roots from /var/www/webs/<user> to /home/<user>/webs/.
    • Enforce that new web roots are created at least one directory away from /home/<user>/webs/.

    Any advice appreciated.
    Last edited: Oct 5, 2013
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    ispconfig uses passwords in Linux standard format (crypt-md5 with salt). If syscp uses the same password encryption or cleartext passwords which you can encrypt for ispconfig, then you can reuse the passwords. Otherwise you will have to set new passwords.

    You can do this e.g. with virtualbox or vmware. Ready installed virtualbox vm's with ispconfig preinstalled are available here at howtoforge.

    I recommend to use debian. ISPConfig is developed o debian, so thats the most stable distribution.

    Thats not a good idea. Websites should reside under /var/www, if not, suexec will fail.

    I highly recommend to use the default paths from ispconfig, so you ensure that you wont run in problems in future.
  3. toolforger

    toolforger New Member

    Ah pity. I had hoped that ispconfig might support webroots inside home directories using apache2-suexec-custom.
    It's really annoying to have to explain to everybody that they have sort-of two home directories, one for their personal data and one for their webroot(s).
    Ah well. Can't have everything I guess.

    I noticed the ispconfig appliance, and very much liked having it.
    The issue is I'd like to simulate a DNS for it, so I can test DNS and mail configuration. I need to make sure that DNS caching and domain name configuration are properly set up, I had issues with the machine assuming responsibility for a slightly different set of domains than it was advertising to the outside world (this got noticeable only with mail, but then it became nasty).

    Thanks for all the answers, note-taking and preparing underway :)
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    You can try that but there might occur problems.

    Thats not the case when you use ispconfig to create the shell users.

    you can test dns with the dig command:

    dig @localhost yourdomain.tld.

    To test web and mail, use this:
  5. toolforger

    toolforger New Member

    Not sure about the shell user thingie, but I guess I'll see once I start playing a bit with ISPConfig.

    The DNS stuff is a bit more elaborate; I wanted to test drive the port in the VM, then see that the DNS is correct, that mails get sent and received correctly inside the VM, and from the outside to the VM.
    dig might help, but there's always the risk that I misinterpret the results and things still break when I transplant the VM to the real server. Or that things just seem to work because the mails accidentally get routed through the real server and everything looks fine but the VM simply doesn't work.
    So I'd like to set up my own little virtual Internet virtually, with some kind of "stub DNS".

    Googling didn't turn up any useful results, so I guess nobody is doing that.
    Ah well, I'll have to manage then; it's just one more thing that can break when going from VM to reality. (Not that there are THAT many.)

Share This Page