ArubaOS ConfigSource


Andrey Kitsen
 Share

Recommended Posts

  • LogicMonitor Staff

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    

513131446_ScreenShot2021-01-06at10_19_08AM.thumb.png.aa08b1407d7ece0c769dfbc074d267b2.png

1998534999_ScreenShot2021-01-06at10_17_32AM.png.ddeff7a0fa1ee378490fa94cd6b6abca.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :(.

Link to comment
Share on other sites

  • 5 months later...

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

Link to comment
Share on other sites

  • 1 month later...
  • Administrators

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.

Link to comment
Share on other sites

  • Administrators

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?

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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')}"

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share