Cluster Update to Wheezy (from old ISPConfig version)

Discussion in 'ISPConfig 3 Priority Support' started by stefanm, May 27, 2013.

  1. stefanm

    stefanm New Member HowtoForge Supporter

    Hi Till, Hi Falko,

    now that Wheezy is released and support for Squeeze is ending soon (;), I started planing how to proceed with my cluster setup.

    At the moment I run two servers that are still on ISPConfig 3.0.3 and that are clustered mainly according to your original cluster tutorial (with glusterfs) with the only notable exception that the databases are not on the gluster fs volume but replicated through MySQL and stunnel. (the two servers are located @hetzner with a failover ip)

    I think I have mainly two options to proceed, but I am unsure how ispconfig will handle this (or what I would have to handle):

    A. Just take the two servers, upgrade ispconfig and upgrade to wheezy...

    B. Ordner two new servers, set it up with wheezy an migrate over with the ispconfig installation. Preferrably with the move to new servers I would also like to replace gluster fs with something like unsion and move from courier to dovecot.

    My questions:
    At the moment I would prefer the second option because of the much better hardware for the same price.
    How does ISPConfig handle the distribution specific parts? Is it save to migrate from a squeeze installation to a wheezy installation (as it is described in various threads - but these were always about migrating between the same base distributions, afaik)
    When setting up the ispconfig servers I suffered from the bug with the different user ids in the cluster setup (Note: I don't blame you for this! It was a bug and this happens... ispconfig is despite definitely the best admin panel out there, including the commercial alternatives. It was just a hell lot of work to fix this and I was happy with the afterwards very well working system, so I was reluctant to upgrade). Meanwile Ispconfig got the option to sync user ids to systems ids. Can this be enabled in an existing installation (after upgrading from 3.0.3 to 3.0.5) or is this only applicable for "fresh" installations?

    If I would only upgrade the existing servers, what would be the right order in a cluster setup. I guess, there might come up inconsistencies if one server is still on "Squeeze" and the other server is on "Wheezy" already or can ispconfig handle this transparently?

    A lot to read... sorry. But there are quite some questions in my head how to do the upgrade with minimum downtime (as least as minimum as such a small setup permits:eek:)

  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Updating from squeeze to wheezy does not cause any problems according to our tests. In genaral its better to update the Linux distribution first and then update ispconfig, so that the ispconfig updater is able to install the config files for the new linux distribution.

    It is safe as it will affect only new websites. But you will have to take care that no userids of old sites are in the range used by ispconfig. You can set the start userid under system server config and new id's are calculated like this:

    startid + domain_id of the website

    So select a startid that is above the highest userid ID currently used on your servers to avoid conflicts.

    The website , mailuser and dns record specific setup is the same for all linux distributions, so it does not matter for ispconfig if one server is squeeze and one is wheezy, most likely it would also work if one is debian and another one centos, but I haven tested that and wont recommend such a setup :). But its a problem if the ispconfig versions on both servers are the same, so you should try to avoid to do any changes inside ispconfig until both ispconfig versions are updated. The reason is that new ispconfig versions have new columns in the database tables and if ispconfig would try to replicate a record from one server to another were the new column is missing, it would cause a replication error and ispconfig will halt the processing until the administrator confirmed in system log of the monitor that the error has been resolved.

    In general I think the update + migration is the safer option as you can do the migration and test the new setup on wheezy before you go live.

Share This Page