Question 1 : What's recommended for 3.2.2 to 3.2.8+ : Update from one point-release to another, or update from a current installation to the latest version in one shot? Question 2 : Is 3.2.8.p1 only a patch on 3.2.8? Or is a full release, sort of a 3.2.8.1 that can be used to update any prior 3.2 installation? It's always advisable to get a full backup, and even to test new software in a different environment. So in addition to backups, and rather than upgrading the existing systems in-place, I'm considering completely new (Perfect) installations of 3.2.8+. This will allow me to abandon any old junk that might have accumulated over the last couple years, and ensure that I have a complete handle on all non-default config settings. Yes, it might also result in time wasted to recreate an environment that already works well, double update of data between testing and live, etc.. We only have about 30 sites with low-traffic, there isn't that much to worry about. Question 3 : Is that a common practice? Iis that serious over-kill? Might that be OK for a major update but overkill for any point-release. I'm trying to get a sense of how others approach this. I currently have two ISPConfig servers, a simple primary/secondary for DNS/MX. I experimented with adding other servers for websites, databases, etc, but they are not production. I'm thinking about reconfiguring the architecture so that all services remain on these primary servers (or upgraded replacements), and moving the sites and databases to other servers. This will flatten out the network, take some load off of these servers, and expand our abilities and experience with a more distributed topology. Question 4 : (Opinions) Does anyone see an obvious (only an idiot would do that) reason not to do that? I am aware of the possible pain associated with a "double whammy" update of any environment, like hardware+OS+application migration. But I don't feel like an ISPConfig v3.2.x update is that significant that we would have special issues with this kind of change. Any other suggestions or warnings for such an update? Honestly, I'm terrified that something can go wrong, causing the loss of days in research. I'm looking for some "warm fuzzy feelings" about doing this update. Thanks!
The latter. In one shot. It is a patch, yes. It is also that. What is? If you ponder on using ISPConfig Migration Toolkit, for upgrading ISPConfig it is in my opinion overkill. If also OS needs update and or a new server host is purchased, Migration Tookit is a good way to go.
you don't say what OS (and release) you currently run, but if you're currently on ubuntu 20.04, or even 18.04, or on debian 10 / 11, i'd just go with the update straight to the latest ispconfig release for now You don't seem to have any urgent requirement to change, or spread out server services, or update the OS, so i wouldn't bother right now. even though a dist upgrade should be perfectly feasible, and trouble free, it has enough potential to go wrong that i would consider that creating a new multi-server setup for eg, the upcoming switch from ubuntu 20.04 to 22.04 could be a worthwhile option, especially if you are looking at changing the service allocation between servers.
It sounds like the update will be easier than I thought. Thanks for the reassurances. This is Ubuntu 20.04, no intent yet to go to v22. The only thing I'm worried about is that I should / need to move all of my postfix+dovecot customizations to the new ISPConfig locations. They can be found with postconf and doveconf. But the thought of moving rules around is scary. Testing is procedurally difficult, with or without a test server. I don't want to break integrations with Amavis, Rspamd, RoundCube, etc. And I have no idea if ISPConfig will modify settings in those or other applications - outside of looking through code, tracker, forum, and docs. I know we want ISPConfig to be a major/opinionated part of the installation, and I'm fine with that. The concern is that we do need to use other methods to manage parts of the system that ISPC does not - and when ISPC does get enhancements to extend into other parts of the system we need to reconcile the new delta - what do we now need to leave to ISPC integration and what do we still need to handle outside. Personally I find that to be challenge - there's no centralized info available like this. In addition to the above, a couple specifics of many that I think about are DNS Zone management, and additional Apache rules that get applied to sites. Does anyone have a checklist of things they know they need to explicitly check after an ISPC update? Do any of you have tools that you run after an ISPC update to re-apply changes you've made? I already have some tooling like this that I use to augment the Perfect installation. It seems like it might be valuable to have a repository of changes that admins apply to their sites, so that we can all see examples of the kinds of details that need to be managed outside of ISPC. Thanks as always!
Curious, what checklist that you think we all need just to update ISPConfig 3.2 to the latest version since so far I never needed that when running it from one release to another. In my experience, I just run the update, reconfigure services, and that was it all the time. I am not denying there were rare cases that claimed some services were down after an update but there normally will be a quick fix released by ISPConfig, so not rushing any update and wait a week or two before updating to it should be the best practise for live servers. I also don't think ISPConfig will mess up any of your custom settings especially in its custom conf folder where your customized conf will be kept and used instead of default. Oher than that you might want to use monit to monitor the server and its services so that it may trigger report accordingly and fix common errors automatically whenever possible (with some custom scripts). Anyway, I am not sure what you need to manage from outside ISPConfig. My latest venture using Dell R710 with single IP and behind a nat router will customize and use ISPConfig nginx web server in one vm as proxy manager to other ISPConfig servers in other vm's.
Thanks guys. We don't know what we don't know. That's why I ask ... that, and basic paranoia. @Th0m : I plan to move existing .cf / .conf file detail into the conf-custom files. It just takes some time to review the sorted multi-file structure to ensure we have the right conf-custom settings. As I said earlier, postconf and doveconf will help with this. Unfortunately as we gain some centralization with the v3.2 master files we lose the multi-file organization under /etc. That's fine. I'm thinking future ISPConfig enhancements will include UI maintenance of what many of us are putting into conf-custom, until eventually we won't need that anymore. I was originally reluctant to move to v3.2.3 specifically because I wasn't comfortable with putting server-specific configs under the ipsconfig/server structure. It feels like mixing a software repo with data, one that might accidentally get over-written on an update, and I felt that structure was a design error. I was also concerned about losing comments that are in the current postfix/dovecot folders. As noted in this thread, if things aren't explicitly stated, we're left to simply trust that things will happen elegantly. Sometimes that doesn't happen and we deal with it after we find out, after an update. I really try to get info like this beforehand to minimize time lost after. That sometimes means asking what seem like silly questions - and sometimes we have to wonder why no one asked these questions or published answers earlier. Thanks for bearing with this process. T
I guess if you are able to use good virtualization technologies (both softwares and hardwares) in managing your servers (e.g. proxmox), your life maybe be easier / better since you can make snapshots for you to easily back up and quickly restore any of your servers in case anything happened. The down time, if any, will be very much minimal and you may have a lot of tests before live production via numerous virtual machines created for that purpose and a lot of other things as well.
