Forum Discussion
Can we modify existing pool name ?
Ensure all latest changes are in the recent backup file
(bash) tmsh save sys config
Modify the backup file
(bash) vi /config/bigip.conf
(vi) :%s/STATEMENTS-PROD-80/STATEMENTS-DTCPROD-80
(vi) :wq
Load in the modified config from the backup file
(bash) tmsh load sys config
I give no guarantees, but I've done this during peak business hours without a negative consequence.
Caution: does this exact name pattern exist in other objects, other than the LTM Pool names? Issue a grep command on the bigip.conf backup file before you start.
- JinshuOct 17, 2016
Cirrus
I would add one more step in this to be on safer side. What do you think Hannes?
Ensure all latest changes are in the recent backup file (bash) tmsh save sys config Take the conf file back up (bash) cp /config/bigip.conf /config/bigip.conf_backup Modify the backup file (bash) vi /config/bigip.conf (vi) :%s/STATEMENTS-PROD-80/STATEMENTS-DTCPROD-80 (vi) :wq Verify the config file (bash) tmsh load sys config verify Load in the modified config from the backup file (bash) tmsh load sys config-Jinshu
- Hannes_Rapp_162Oct 17, 2016
Nacreous
Interesting inputs. I've added comments
Take the conf file back up (bash) cp /config/bigip.conf /config/bigip.conf_backupSure, why not.
This will give additional assurance in case you decide to roll back lets say a few days later, not shortly after the change. Naturally, there's another backup file (/config/bigip.conf.bak) which does the exact same thing. At all times, you effectively have an opportunity to roll back a single configuration change regardless if you take a backup or not. However, the bigip.conf.bak file like the main backup file updates itself automatically after changes to configuration are made. This backup file has a very short shelf life. If you consider a change risky, it's never a bad idea to take a hard backup for youself.
Verify the config file (bash) tmsh load sys config verifyNot a fan.
If there are problems with the configuration file from which you try to load the active configuration, the operation is cancelled automatically and any errors will be reported. Despite F5 recommending this 'verify' flag in various SOL articles, I'd say this command is next to useless and only wastes your time in the long run.
- JinshuOct 17, 2016
Cirrus
Cheers..!!
- Hannes_Rapp_162Oct 17, 2016
Nacreous
Giving another thought to it, the 'verify' flag is not entirely useless. It can have a purpose in 2-phase changes. If your business dictates that you must implement the change during off-peak hours, i.e. 2AM during the night. Then it might be wise to carry out the preparation phase during working hours, and validate the file using the 'verify' flag not to load in the configuration, but only to find out if the file is 'kosher and compliant' in terms of F5 formatting standards. This can potentially save you 10 minutes of troubleshooting efforts during your valuable sleeping hours.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com