changing the configuration backup script

[Tim Turay]

Hi All,

I'm trying to do a configuration backup on a Juniper Firewall and the script is failing.  On closer examination I can see where the script is failing and I need to edit it.  How do I go about editing the script?

Thanks,

Tim

[LindsayHill]

Pretty straightforward.

1.  Open file in your editor of your choice
2. Make changes
3. Save file.
4. Re-run backup

That's about it. If you're changing a .tcl or a .pl file, you don't need to restart IMC, as those files get read every time they run. If you're changing an XML file, you'll need to restart IMC.

The only wrinkle is dealing with IMC updates. Future updates will over-write your changes. With a bit of luck, HP will include your fix in a future change. This is MUCH more likely if you log a support case explaining the problem, and include your suggested fix.

Otherwise, be prepared to make the same changes every time you update IMC.

[Tim Turay]

Hi Lindsay,

Sounds easy enough.  Where is the file stored?

[LindsayHill]

Sorry, I thought from reading above that you'd already identified the file you needed to change.

Adapter files are under <IMC>/server/conf/adapters/ICC/<vendor name>/<adapter name>

[Tim Turay]

Hi Lindsay,

That worked great.  Now the only problem is by changing this it affected the other firewall backups.  Is it possible for a backup to use a different script?

[LindsayHill]

Adapters are used on a per-model basis, not a per-device basis. If there's something really specific you need to do for one single device, you could probably do something ugly inside the script to identify that specific device. 

But it might be better to look at what you're trying to do. What's the issue that you're having with that one device, and what changes did you make to work around it? And why does that break other backups? We might be able to come up with a better way of solving the problem.

[Tim Turay]

Our setup is our main site (where the IMC server is) and four remote sites. When I use IMC to do a backup of the firewalls, the remote sites fail and the main site firewall is a success. I edited the backup script changing the TFTP server to an IP address redirect on our main FW (where the IMC server is) and the remote sites work but the local FW fails to backup now. What would you recommend in this situation?  Thanks for your help on this.

[LindsayHill]

Number one thing: Stop using TFTP. Seriously. Don't do it. Especially for firewall configs.

Your problem is the direction of traffic flows. IMC can back up a device using these methods:

1. TFTP the backup file *from* the device *to* the server
2. FTP the backup file *from* the device *to* the server
3. Use SCP to *pull* the file back to IMC from the device. Note that IMC *initiates* that connection
4. Use SFTP (same process as #3, but using SFTP)
5. Use CLI, where IMC connects to device via either SSH or Telnet, and runs "show run" or equivalent, and captures the output. CLI is the fall-back option.

Different backup adapters use different methods, as obviously it depends on the device. Some adapters have multiple methods they can try. They'll go through those in order until they get one that works. The other relevant item is the file transfer method. You can set that on a global default basis (default TFTP), and you can over-ride it per-device.

You saw the TFTP Server IP Variable in those scripts. By default, IMC will put its own IP in there. If you use NAT between IMC and the device being backed up, you need to put the NAT IP. The 'right' way to do this is in <IMC>/server/conf/qvdm.conf. You set server_nat_ip in there. 

So then when IMC goes to back up a device using TFTP, it will tell the device to send the backup to that NAT IP, not the real IP.

However...that's a global setting. So you'd have the same problem as what you've seen where you changed the adapter.

The *much* better fix is to get IMC to use either SCP or CLI to backup the device. That way IMC makes an outbound connection to the device, and NAT won't be a problem for you. I'm assuming you're using the JuniperGeneric adapter. It looks like that has some code for SCP backup, but it is commented out. I don't know why. So you'll want it to use the CLI adapter. One way to force that is to change the file transfer mode for that device to use SCP. Then when the backup runs, it will look for an SCP adapter, see that it doesn't have one, then it will switch to CLI.

(Sorry for the wall of text, but hopefully it explains a bit about what's going on)

[Tim Turay]

More info the better!!  Thanks, I will give this a try in the next day or so.

[racowi]

I'm in a very similar situation. I have 2 devices that need NAT IP address in order to make a successful backup. But I tried the things you suggested, but the SCP is not working for me, and when it try to use CLI, it also fail.

The device is a Cisco, and if I use the nat address is work, but not with the IMC IP.
Thanks

[LindsayHill]

@racowi where is the NAT in your case? Is the IMC server being NATted, or is it the device?

What happens if you try to manually back the device up using SCP? Do it from the IMC server, but don't use IMC itself - just use scp on the CLI. Does that work? If not, where does it fail? Have you configured SCP on the Cisco device?

Similarly with CLI backup - where is that failing? What errors are you getting? Can you manually SSH from your IMC server to the device?

[racowi]

I've fixed it! I was receiving the error Privilege Denied from Cisco, but I figured out it 'aaa authorization' command was missing on the config. For the backup cli script, I was receiving "error message: Could not show the running-config."

I never figured out the reason for this one. But the SCP is running now. Thanks.

[LindsayHill]

Good to hear!

[racowi]

@LindsayHill BTW, Do you have knowledge on the "Intelligent Policy Center" module on IMC? It look very interesting, but some of the thing dont run for me or I don't understand how achive them. I also tried to find documentation for this, but even in the IMC help, this area is not mentioned.

Thanks

[NeilR]

Intelligent policy center is covered in the Enterprise and Standard Platform administrator guide Part number: 5200-2690
Software version: IMC PLAT 7.3 (E0502) page 925:

IPC includes the following parts:
 Event Configuration—Allows you to define device alarm events and periodic events.
 Action Configuration—Allows you to view available actions.
 Policy Management—Allows you to manage policies. A policy specifies the actions to take in response to an event.
 View Event—Displays events that occurred and policy execution results.
 Report—Allows you to view the event report and policy execution report for the last hour.

You select alarms to monitor, then create a policy to take some action, such as shutdown a port, restart a vm, run a check task, send an email, run a script etc  - 17 defined currently. You can apply to entire network or just a range of IPs or group of devices.

[LindsayHill]

There's some stuff in the Admin Guide PDF about Policy Centre.

I tried doing some things with it a few years ago, but didn't have much luck. At the time the docs implied you *could* extend it, but in reality you couldn't. I think that may have changed since, but I haven't had a chance to try it out.

[NeilR]

It's improved somewhat since then

[LindsayHill]

Good to hear

[racowi]

Yes, I read the PDF but even with that, the information is too basic "generic". Some of the actions dont work for me or failed when are executed. The "Execute Under Condition" have never worked for me. Is like the script or development of this IMC "area" is damaged.

I'll look forward to use this feature in the future.

[LindsayHill]

---

@racowi wrote:

Yes, I read the PDF but even with that, the information is too basic "generic". Some of the actions dont work for me or failed when are executed. The "Execute Under Condition" have never worked for me. Is like the script or development of this IMC "area" is damaged.

I'll look forward to use this feature in the future.

---

Start a new thread, and provide specifics of what you're trying to do, and what's not working.