Mass NMC Updates

[Anonymous user]

I know there are a lot of threads around this topic but I wanted to make sure I am on the right track for our particular environment with 300+ UPS devices and a mixture of 9617,9618,9619 and 9631 NMCs.

The main thing we are trying to accomplish is to update the email alerts on all NMC's so that the alarming is consistent across the board. I am new to this institution (University) but for security reasons they prefer to have FTP disabled on the NMCs.

Questions:

1) Is there a way via script or SNMP to mass enable/disable FTP on the NMCs so that we can toggle the FTP setting when we need to make config changes?

If mass enabling FTP is possible the idea was to do the following:
- Configure email alerts on one UPS exactly how we want it
- Export this updated config.ini file
- Enable FTP via SNMP (it's configured on all cards) using some type of script.
- Update all NMCs by importing the EventActionConfig section of the config.ini file either via script or using the ini utility.
- Disable FTP via SNMP using a script

2) Can the above be accomplished with any of APCs network management software? If so which one keeping in mind we only want to manage the UPS devices and nothing else.

3) Is there a way to mass upgrade the NMC firmware via scripts(preferably) or APC software?

Thanks,

Carlos

[BillP]

i know in the last couple years, we've gotten away from doing configurations via SNMP.

the only OIDs for FTP and file transfer I see (which don't include enabling/disbling FTP) are under .iso.org.dod.internet.private.enterprises.apc.apcmgmt.mfiletransfer.mfiletransferConfig / .1.3.6.1.4.1.318.2.4.2

another way to consider doing something like this could also be by using DHCP which there is an option for FTP or TFTPing a boot file during a DHCP request. http://www.apc.com/site/support/index.cfm/faq/ -> search for FA156110 (maybe this is not an option for you but i figured I'd throw it out there)

anyway, the only way i know of to mass enable/disable FTP would be through the INI file itself. have you considered using SSH/SCP? SCP gets enabled when you turn on SSH and is secure. i wasnt sure if FTP is disabled because it is unsecure.

struxureware central is the product we sell that would have the capability to do all of this from a GUI. the other utility you mentioned, the INI utility, is the only other item we have to assist in mass configuration at this time. we don't have any other scripting tools.

[Anonymous user]

Yes - FTP is disabled for security reasons. You mentioned considering SSH/SCP but I thought the only way to update the .ini file was through FTP. How can I specifically use SSH/SCP to update the config.ini file? Do you mean logging into a NMC via a script, enabling FTP via scripted commands and then using the ini utility to upload the changes once FTP is enabled? Please clarify so I can decide what direction to take.

I'll also look at the Struxureware Central product but my uderstanding is that this tool does a lot more than what I am looking for and is priced as such. It would be nice if a smaller scale solution was available just to manage the UPS NMCs for firmware, config and alerting updates.

[BillP]

the INI utility is what we offer for free in regards to mass configuration. this tool works with FTP only.

if you can script a file transfer using an SCP client, then you could basically make your own INI utility that works off of SCP.

just a warning, using secure protocols on NMC1 such as AP917/18/19 is kind of slow but there is no performance issue on NMC2 like AP9630/31.

some information is located here on SSH/SCP -> http://www.apcmedia.com/salestools/AKAR-7FVQ2W_R1_EN.pdf (PDF page 32).

you can transfer files via secure copy securely but the problem I see is that you'll still need to enable SSH/SCP on each card to get that started. if you are going to permanently leave it on, that's fine but if not, you might as well also consider going with FTP and the INI utility as well.

let me know if you need any further clarifications. how you script via SCP is going to depend on the SCP client that you choose most likely.

[Anonymous user]

After looking at all the alternatives it appears that a script using SCP is our best bet as we have SSH enabled on all the devices (hence SCP is enabled as well). I have successfully done some tests uploading config changes to a 9617 and a 9631. However, I have noticed one small difference when the APC NMCs are using local authentication versus radius. When I use an SCP client with local authentication the file uploads successfully and all login methods (SSH/WEB) work as expected.

However, when using radius authentication the file uploads successfully but when trying to access the NMC via web you get the "Someone is currently logged into the apc management web server" message. If I then log into the NMC via SSH and logout the web login then works as expected. Although this doesn't appear to be a show stopper since we can most likely use this workaround, I'm wondering if this is a bug of some sort.

Thanks,E

[BillP]

hello,

does this happen on both cards (AP9617/18/19 and the AP9630/31s)?

what RADIUS server are you using? i do know that these cards require two requests, one to authenticate and one to connect when using RADIUS. I wonder if it is related but I am not sure - it is just what came to mind. depending on how the particular RADIUS server and how it authenticates the user, i thought maybe its coming into play. for example, when using RSA tokens with RADIUS, we have seen issues with this because of the two requests.

can you get me steps to replicate? if none of that seems right, i will try to replicate it. from what i understand it is:

1.) Configure NMC with RADIUS.
2.) Enable SSH (and SCP)
3.) Login via SCP and transfer config.ini to NMC. Log out of SCP session and disconnect.
4.) Within X minutes, access NMC web interface (via HTTP or HTTPS?) and notice it tells me someone else is already logged in.
5.) Complete same steps with local authentication only, everything works fine?

[Anonymous user]

Yes, this happens on both cards (961X and 963X). We are using Cisco's ACS server (TACACS/RADIUS). I am using PSCP (Putty SCP) from a Windows 7 command prompt. It's only one command to initiate the transfer so there aren't multiple steps to login/upload/transfer/disconnect.

The command looks like this: pscp -pw password c:\temp\configup.ini admin@hostname.com:config.ini. After you run the command you return to the command prompt and get the status as shown below making you think all connections have been closed.

configup.ini | 0 kB | 0.0 kB/s | ETA: 00:00:00 | 100%
c:\PSCP>

You don't need to wait any amount of time as the web login issue is seen immmediately.

Your steps 1-5 are bascially correct except for the small differences I mention above for items 3 and 4.

[BillP]

can you post the events from the log at this time by any chance just so i have them? i will see if i can replicate.

EDIT - was able to replicate this using RADIUS then without RADIUS as you described.

here is my log:

01/24/2013 17:04:00 System: Web user 'admin' logged in from x.x.x.x
01/24/2013 17:03:48 System: Console user 'admin' logged out from x.x.x.x
01/24/2013 17:03:46 System: Console user 'admin' logged in from x.x.x.x
01/24/2013 17:01:32 System: Configuration file upload complete, with 3 valid values.
01/24/2013 17:01:32 System: Configuration change. System location.
01/24/2013 17:01:32 System: Configuration change. System contact.
01/24/2013 17:01:32 System: Configuration change. System name.
01/24/2013 17:01:32 System: SSH/SCP: File transfer complete.
01/24/2013 17:01:31 System: SSH/SCP: File transfer started.

i will see about logging this as an issue. it wouldnt be addressed on the older cards being discontinued most likely and ill have to look to see if i can upgrade a card to our upcoming release of 6.0.X firmware to see if it still does it.

[BillP]

i did not see this behavior using FTP and RADIUS. going to try with 6.0.X beta now. i imagine it won't matter with that because we will be supporting multiple user log ins anyway but i will check to see if the session ends at least after the SCP transfer.

EDIT I checked it in 6.0.X and even though it won't matter, i verified that my only session after testing the log in via web was the web session alone.

i will have to log an issue against this for 5.1.7.

[Anonymous user]

Thanks for following up on this. As a workaround I am trying to automate some type of mass login/logout because manually logging in and out of each device is not really an option when you have 400 devices. I was trying to do this with SecureCRT scripting but their SSH has issues accessing your NMCs. Any suggestions on that front would be appreciated.

[BillP]

way back when, this article was published -> http://www.apcmedia.com/salestools/VAVR-5ZJSVU_R2_EN.pdf and indicates SecureCRT was tested. it was most likely some time ago since I've been working on these devices several years ago and have not heard anyone talking about SecureCRT.

do you have details on what the problem is or what i should look at there?

also, this will be fixed in our next firmware release for sumx and sy apps which last I heard was coming out late next week. before you go crazy doing this, i didnt know if it'd be easier to consider upgrading all of the devices and then making configuration changes. on the other hand, this new firmware update is major and has a lot of changes in itself. it may be something you have to validate and check out before you consider updating but i figured i'd mention it if its an option.

[Anonymous user]

I have seen that document -Yes it was tested and is marked as not supported. I just tested again to give you the specifics. I can actually connect to the older NMCs (961x). It's seems I can't connect to the newer NMC2 cards. The screen just flashes and shows it's disconnected (never receiev a prompt or anything). I'm sure it has something to do with incompatible SSH standards or something like that.

A firmware upgrade would likely put me in the same spot because it would have to be done via SCP since FTP is disabled. Not to mention doing testing, etc. The short term goal is just to get the alerts and emails cleaned up and I am almost there. Even if the web login is unavailable until someone logs in to the ssh session first and logs out that might be ok. I'm just looking for a way to kill it all in one fell swoop.

Thanks,E

[BillP]

oh, crud, i read the document incorrectly and did not see the check versus X (meaning unsupported). oops.

anyways, in your experience with your testing, does the web UI eventually become available? meaning the auto-logout is by default 3 minutes and is a max of 10 minutes (which you can configure). i am curious if you wait this amount of time after transferring via SCP if the web UI is then accessible after whatever that setting is (between 1 and 10 minutes).

[Anonymous user]

The timeout does not work for this issue. If it were only a matter of waiting 10 minutes I wouldn't even care. The issue is that the web session stays locked until you SSH in an then logout. I just verified again right now but last week I waited like 30 minutes and still couldn't get in. If you have you lab scenario in tact you can verify.

[BillP · Accepted solution]

i did but then i put my card back to telnet only so i did not test today. i figured you had maybe checked that out too considering how thorough you've been but just wanted to verify.