Config File Export - Cluster Version Only?

[ChrisLord09]

Hi All,

We have Ironport C650's in a cluster. I'd like to export the config file off one of them so that I can import it to a stand-alone C650 we have in a test environment.

As it stands, even if I remove a node from the live cluster then do the 'saveconfig' on that removed node, I still only get a large config file containing the config for all devices and details of the cluster configuration....which I assume is the cluster configuration.

My question is how do I get a 'single machine' version of the config file that I can use on my stand-alone C650? We're running AsyncOS version 5.0.0.252 if that's of relevance.

Hope y'all can help!

Thanks,

Chris.

[lucas.castro_ironport]

hi,

i'm not sure about this, but i think you should take care about exporting a config file and importing it to another box. Otherwise, you can end up crashing your test box.

Why dont you export hat info and other major pieces, like smtp routes, and import module by module? I think its a little bit safer.

[Donald Nash]

i'm not sure about this, but i think you should take care about exporting a config file and importing it to another box. Otherwise, you can end up crashing your test box.

Before we clusterized our appliances, I did this all the time. I'd make changes on one unit, export the config, run it through a script which would make all the proper adjustments like changing the host identity information (IP addresses and host names), then blow the results into the other units. It's quite safe.

Getting back to Chris' question, yes the cluster does make it difficult. In theory, you could edit the cluster config by removing all the other nodes from it, moving all the items configured at the cluster and group levels to the local node, and removing all the now-emtpy cluster stuff. You could use an existing standalone config as a template. But in practice, I'd be very afraid of getting all that right. I think Lucas' idea of exporting it module by module is better.

Or you can do what we do: put your test unit in the cluster. You can experiment with config changes by doing them at the local node, then move them up to the cluster when you're satisfied with them. And when you do OS upgrades, you have to drop out of the cluster anyway. So drop the test unit out of the cluster, upgrade it, test it, and then proceed with the rest of the cluster when you're satisfied. CM is very flexible. Let it work for you instead of against you.

[lucas.castro_ironport]

i'm not sure about this, but i think you should take care about exporting a config file and importing it to another box. Otherwise, you can end up crashing your test box.
Before we clusterized our appliances, I did this all the time. I'd make changes on one unit, export the config, run it through a script which would make all the proper adjustments like changing the host identity information (IP addresses and host names), then blow the results into the other units. It's quite safe.

Thanks for the feedback Don. I've tested the export and it worked fine for me too. Must remember to not encrypt the passwords ;)

[ChrisLord09]

Thanks for the info guys.

I managed to figure it out in the end, here's what I did;

- Exported the 'live' Cluster config file from a cluster member box

- Exported the existing config file for the stand-alone test box

- Cut the "Mail Configuration" and "Log File and Alert Configuration" sections out of the Cluster config file

- Pasted these sections into the stand-alone box's config file, replacing the existing sections.

- Uploaded the modified file to the stand-alone test box

This way I retained all the existing network config, etc but kept the policy config, banners, etc.

Hope this might be useful for someone else down the line.

Thanks again,

Chris.

[bfayne_ironport]

If you do a full 'removemachine', not just 'disconnect', the config file that gets exported will not include any cluster information. :)