scottdware / go-junos Goto Github PK

Hi,

Whenever I try to retrieve a Junos config using:

jnpr, err := junos.NewSession(hostname, username, password)
config, err := jnpr.GetConfig("", "text")

I always get this error: netconf rpc [error]: syntax error, expecting </configuration>.

This doesn't seem to be device-specific as I get the same error on SRX, MX and QFX.

Is this a know bug or simply an error on my part?

I used go get about a week ago so the go-junos code I'm using should be fairly recent.

Thanks,
-Martin

if len(message) > 0 { command = fmt.Sprintf(rpcCommitAtLog, time) }

Should not it be :
if len(message) > 0 { command = fmt.Sprintf(rpcCommitAtLog, message) }

• Specify source, destination, ports, etc. to build policy.
• Assign to a device as well?

Allow the creation of policies on an SRX like so:

• Create a struct that will hold all the policies (XML format?) p := j.BuildPolicy()
• Add functions to create multiple rules; many can be added: p.AddRule("name", "src-zone", src", "dst-zone", "dst", "service", "action")
  • src and dst can have multiple values, i.e.: "1.1.1.1/32, 2.2.2.0/24" or "[]string{"1.1.1.1/32", "2.2.2.0/24"}"
• Assign all the rules to a variable which will get passed to Config(): config := p.CreatePolicy()
• Create similar function for Junos Space?

Add a function to get "facts" about the device such as software, hardware, etc.

Just a note.

There seem to be a documentation error on your readme :

When I use jnpr.Views("..."), i get following errors:
./main.go:21:20: jnpr.Views undefined (type *junos.Junos has no field or method Views)

When I change to jnpr.View("..."), things will work, if this is an error, can you fix it ?

i was wondering do you have any code snippets for updating the switch , i.e. - rather than just operational commands, e.g. - set interface ge-0/0/44 description HbWjpLzzwGVwSMjsuUoL

Using the Command() function.

just want to check if there is a way for the Views to support sub commands like show interfaces descriptions instead using show interfaces?

Create queues using the HornetQ service that Junos Space uses. This will help speed up results when calling the API multiple times, especially when adding devices/objects.

• Create a function to query the jobs
• Filter on a specific status?
• Add the ability to filter on job ID, and return the info for said job.

Add functions to get some basic information from commonly used commands per device type. One for SRX, MX/routing, EX/switching, etc.

SRX

• Session information
• Zone information
• IPSec tunnels

MX/routing

• Route table information
• Protocol information (BGP, OSPF, etc.)

EX/switching

• MAC address table
• Interface status/information

First, thanks for fixing the documentation error.

I have another question, if I just want to display one particular interface, how can I filter by interface name instead of getting all the interfaces ? Is there a way to pass in a filter on the following ?

  "interface":      "<get-interface-information/>",

• Interfaces, VLAN's, routing-instances, users, etc.
• SRX
  • Zones
• Build the config in a struct first, then apply it?
• Individual functions as well, for giving users different options?

I think it would be nice to have a way to bring your own SSH session (net.Conn) or SSH config (ssh.ClientConfig). For example, to specify SSH connection timeout, or connect via a proxy.

IMHO, it would make the most sense (for backwards compatibility) to refactor NewSession and move all the post session-establishment code into a new function, and create an additional function to deal with the new BYOS features.

Let me know if you agree with adding this functionality and I'll implement it and submit a PR.

Fix yo shit!

ConfigDiff() uses rpcGetRollbackCompare which is using the following RPC

<get-rollback-information>
   <rollback>0</rollback>
   <compare>0</compare>
   <format>text</format>
</get-rollback-information>

That RPC is for comparing amongst active and previous rollback points. It does not work on candidate configurations.

Juniper.net documentation shows that the proper RPC to use is:

<get-configuration compare="rollback" rollback="[0-49]" format="text"/>

Where 0 would compare the candidate configuration to rollback 0 (the active config). Or one could compare to any of the previous commits (0-49)

Using the get-configuration RPC instead of get-rollback-information would allow
a diff to be generated for a for Config that has not yet been Commit.

This is useful for interactive sessions or merely logging the diff output to file
or other output (API/console, etc.)

• Specify source, destination, ports, etc. to build policy.
• Assign to a device as well?

Currently, users can run commands and output the format in text or XML, but these only run in operational mode.

• Give the user the ability to run an RPC command of their choice (i.e.: jnpr.RPC("get-routing-engine-information")).
• Have the ability to specify the output they want to see. A "struct-on-demand" type config?

Technically, this can be done via the RunCommand() call. You just can't specify the actual RPC XML in the request, but the "show" version of it instead.

Does this need to be changed?

would love to have ability to use SSH keys to authenticate instead of password

Just a test to remember to do something!

In the case where I would like to compare a candidate config to the running config, the uncommitted session remains around waiting for commit. Rollback(0) looks like it would commit, even when there was nothing to commit.

Allow filtering on device information for Devices() and SecurityDevices().

• Use url.Encode()

returns a pointer regardless of the 2 if conditions.

should return

config,errors.New("no credentials/keys available")

Looking over the Config() method, its not clear to me if I can pass the config text in as a string. I see loading a file and such, but say I were to render a template. Would I be able to pass text in to the Config() method and have it get loaded to the device?

Trying to commit now I get:

expected element type <commit-results> but have <ok>

Is this perhaps something upstream? I see that we are looking for commit-results in the XML, so perhaps this is a change on newer firmware?

• Mainly for LoadConfig().
• []byte() slice?
• Use for the Command() function as well for multiple commands.