ArubaOS ConfigSource

[Andrey Kitsen]

Locator ID: NWC2ZM

Required Properties: hasCategory("Aruba") && ssh.user && ssh.pass

Note: You may need to add an additional SysOID Map entry to capture some ArubaOS devices.

Categories: snmp,snmpTCPUDP,Aruba

OID: \.1\.3\.6\.1\.4\.1\.47196\.4\.1\.1    

[mnagel]

Thank you!  I have been asking for this via "proper" channels for some time with no results -- will try it out ASAP as I have an 8320 cluster waiting.

FWIW, I recommend using a standard property name alongside the ssh.user/ssh.pass (e.g., lmconfig.enabled) to allow disabling this premium feature at the group (client) level when it has not been subscribed to.  I know it is an uphill battle to get those all fixed, but I sure wish it could be done.  We still cannot use the new AD and DHCP modules due to lack of ability to disable LMConfig per client.

[mnagel]

22 hours ago, mnagel said:

Thank you!  I have been asking for this via "proper" channels for some time with no results -- will try it out ASAP as I have an 8320 cluster waiting.

FWIW, I recommend using a standard property name alongside the ssh.user/ssh.pass (e.g., lmconfig.enabled) to allow disabling this premium feature at the group (client) level when it has not been subscribed to.  I know it is an uphill battle to get those all fixed, but I sure wish it could be done.  We still cannot use the new AD and DHCP modules due to lack of ability to disable LMConfig per client.

I guess not ASAP:

This LogicModule is currently undergoing security review. It will be available for import only after our engineers have validated the scripted elements.

I guess I will check back at some indeterminate date in the future .

[sawyer.lef]

Is it possible to have the script account for username and password when entering enable mode?  I have tried editing the script to account for it but Im not familiar with Groovy scripts.  My issue is when logging into an Aruba switch and running the enable command the CLI prompts for Username then password not just the enable password.  The current script only accounts for a password after the enable command

[Stuart Weenig]

This section of code handles prompting for the enable password:

        // The enable command will elevate the prompt if possible.
        cli.send("enable\n")
        cli.expect(["(?i)password:", "${prompt[0..-2]}[>#\$]", prompt] as String[], smallBufferSize)

        if (cli.matched().toLowerCase().contains("password")) {
            cli.send("${epas}\n")
            cli.expect(rawPrompt, smallBufferSize)
        }

Are you saying that after entering "enable" at the prompt, it asks you for the username again? I hadn't seen that, but i haven't touched Aruba in a while.

 

If it's just asking for the password, the script already tries to pass in the password as contained in the "epas" variable. That variable is set at the beginning of the script using this line: 

def epas = hostProps.get("ssh.enable.pass") ?: hostProps.get("config.enable.pass") ?: pass

So, you should be able to just set "config.enable.pass" to the enable password on the device and it'll work. The "?: pass" bit at the end sets it to be the same as the logon password if you don't specify it.

[sawyer.lef]

Yes when logging in and running enable it asks for username and password again.

 

I asked support and the tech said there was no way to disable that

[Stuart Weenig]

Ok, good. Now that we know we can't do anything about it from the Aruba side, all we need to do is update the Expect script to provide the username.

Is the username the same username that's used to login? Is that coincidence or is it always the same username?

[sawyer.lef]

Same username and password used to login 

[Stuart Weenig]

Alright, so cards on the table: it's really hard to guide someone through an Expect script without being able to see the raw input/response in action, so you'll have to play with this to get it to work.

This section of code in both scripts sends the "enable" command to enter elevated privilege mode:

// The enable command will elevate the prompt if possible.
cli.send("enable\n")
cli.expect(["(?i)password:", "${prompt[0..-2]}[>#\$]", prompt] as String[], smallBufferSize)

if (cli.matched().toLowerCase().contains("password")) {
  cli.send("${epas}\n")
  cli.expect(rawPrompt, smallBufferSize)
}

The cli.send("enable\n") is what sends the word "enable" to the device. Currently, the script then waits for the device to respond with some text containing "password:". Since the response is actually "username:" or something like it, you'll need to add some code between the cli.send and the first cli.expect so that the script is expecting (using cli.expect) "username:" instead of "password:". Then you'll need to send the username (using cli.send). The username is contained in the ${user} variable so you should be able to do something very similar to what was done earlier in the script where the initial login happened:

if (cli.matched() =~ /[Uu]?ser\s?[Nn]ame\s?:/) {
                cli.send("${user}\n")
                cli.expect("[Pp]?assword:", smallBufferSize)
            }

 

I'm sorry it can't be as easy as "just use this code" but, this is often how it goes with Expect.

[mnagel]

The good news is it seems dev has finally released new modules that are more configurable, but I have not looked at how much complexity was shifted to propertysources and how maintainable that will end up being.  They tied to ssh.user/ssh.pass still, though, so you will still run the risk of incurring costs unexpectedly if you use those for non-LMConfig reasons (like errdisabled port detection).  I think it is possible to disable LMConfig modules in the subtree alert tuning, though, so that may mitigate the risk.

OSS tools do a much better job than LM did previously, hoping this brings some parity (and fixes for non-change thrashing we see all the time).  I would never dream of editing a 1200+ line module and then have to merge changes into updates later.

[sawyer.lef]

I added this but I am still getting a timeout with the discovery script

        // The enable command will elevate the prompt if possible.
        cli.send("enable\n")

            cli.expect([/[Uu]?ser\s?[Nn]ame\s?:/, /[Pp]?assword\s?:/] as String[], smallBufferSize)

            if (cli.matched() =~ /[Uu]?ser\s?[Nn]ame\s?:/) {
                cli.send("${user}\n")
                cli.expect("[Pp]?assword:", smallBufferSize)
            }

            if (cli.matched() =~ /[Pp]?assword\s?:/) {
                cli.send("${pass}\n")
            }

        // The enable command may have changed the prompt. We've got to get it again.
        prompt = "^${cli.matched().replaceAll(termClean, '').trim().replaceAll(/[.*+?^()|\[\]\\{}$]/, '\\\\$0')}"

 

[Michael Rodrigues]

It's probably timing out during one of the expect() methods because it isn't finding a match.

[Michael Rodrigues]

Also, if you're testing from a tool like PuTTY, IIRC it draws Username and Password prompts to the screen as if they're coming from the server, when they're actually coming from PuTTY.