In hindsight, it would make more sense and be easier if I'd set up the ISPConfig master to be on the backend and not the frontend. This was basically a poor decision on my part, back when I was young and naive about the ways of ISPConfig. Of course, the obvious thing to do is uninstall it all and then reinstall it in an improved configuration. But, well, I've already moved websites over to the cluster now, so it's a question of how I would do this with minimum service disruption. I mean, there will be service disruption. I will have to announce "scheduled maintenance" and beg forgiveness for breaking the cardinal rule of hosting - ruining your uptime statistics - but there really is no other way to do it. But what prompts me to post here is that, if I uninstall ISPConfig on all nodes and reinstall them again - so as to rearrange which is the master server - then do I have any way of preserving the configuration, in terms of clients / resellers / websites / emails? Some sort of method of exporting this information from the current multiserver setup and then importing it into the newly changed setup afterwards? (And, if not, then you can consider this to be a "feature request" for the ability to do that. Sometimes you need to take "the Microsoft approach" to things - that is, "turn it off and back on again" / "uninstall and reinstall" - but it'd be nice if this wouldn't involve having to completely start from scratch. I mean, the website files, emails and databases themselves will be preserved as they're on the storage server's RAID array - now perhaps my want for such a clear separation of duties is apparent - and I could just recreate it all. But, as mentioned, I'd like to minimise the service disruption, so I'd rather not have to manually recreate it all again, as that could take some time.)
Not sure if I understand correctly what and why you want to do that, but maybe reinstalling is not the right solution and you should try to avoid it if possible as ispconfig will loose the whole config on reinstall. The ispconfig master is basically just a database and the interface part from ISPConfig which connects to it. The slave nodes then connect to this database and poll the sys_datalog for changes and write monitor data to the apropriate tables. So generally you can move the master by putting the database wherever you want, then ensure that the interface that you want to use connects to this database (login details in /usr/local/ispconfig/interface/lib/config.inc.php) and that the slaves have the right details in the dbmaster part of their /usr/local/ispconfig/server/lib/config.inc.php file to connect to this master database.
Well, granted, what I'm doing now isn't necessary. The system is up and running as it is. But I'm just going over things and doing a bit of optimising, tweaking and generally making things better. Tweaking, optimising, moving things around. Tidying it all up. Getting the system to a point where I can feel happy to look at it and think "job done" (well, not that the job will actually end there, as it'll require maintenance and improvement over time, but you know what I mean). As for why I'd uninstall and reinstall, it's simply that, until you explained it to me, I wasn't entirely sure if there was a way to move the master without starting from scratch. I'm glad to hear that it is possible without doing that. Really, I was posting here so that I could hear you (or one of the other developers) say that I didn't need to do the uninstall / reinstall thing. I wanted you to tell me that it was unnecessary, because I didn't want to have to do that.
