Tabeller og visninger med Junos Pyez

(Nayan Gadre) (12. september 2020)

Dette er notater opprettet mens arbeider med Junos pyez-biblioteket for nettverksautomatisering. Junos tilbyr tabeller og visninger for å angi og trekke ut tilpassede konfigurasjonsdata. All pyez-koden og ncclient er opensource under Apache 2.0-lisens

Du definerer en tabell og en visning i en Yaml-fil på lib / jnpr / junos / ressurser
som « user.yml ” og tilhørende lasterfil som “ user.py

user.yml
user.py

» user.py ”brukes til å konvertere yaml-filen Tabell og vise definisjoner til pythons globale ordbokselementer. Her peker \_\_file \_\_ til “ user.py ” fil som vil. konverteres deretter til “ user.yml ” filnavn. Junos pyezs loadyaml konverterer deretter brukeren .yml ”i en ordbok for å legge den til globaler () ordbok.

Både tabell- og visningsdefinisjonene i yaml blir konvertert til Klasser i python. loadyaml er en fabrikkmetode og blir eksponert som offentlig API ved hjelp av \_\_ alle \_\_ pythonisk erklæring. Den gir en ordliste med definisjoner av varenavn og elementklasse som du kan se i en linjeknapp.

User.yml-filen er delt inn i to øverste nivåtaster: “ UserTable ” og “ UserView ” slik at loadyaml returnerer to klasser med disse navnene.

ordbok konvertert fra brukeren.yml

Denne ordboken sendes til FactoryLoader.load ( ) metode for å generere klasser:

FactoryLoader (). load (yaml.load (open (path, “r”), Loader = yaml.FullLoader))

Formålet med fabrikklasterklasse

Ordbøkene (() metoden r etur et visningsobjekt som inneholder en liste over tupler som inneholder nøkkelverdipar.

Måten fabrikklaster bestemmer om det oppgitte tabellen og visningsskjemaet er for konfigurasjon eller for operasjoner, er via tastene i skjemaet . For eksempel: “ sett ” og “” -tastene ville gjøre det til en konfigurasjonstabell,
rpc ” så er det en operasjon tabell, “ kommando ” eller “ tittel ” så er det en kommandotabell, det er også en forvirrende kombinasjon av “ element ” “ vis ”og“ * ”som også dikterer om det er en kommandotabell.

Siden vi fokuserer på “ user.yml ” kan vi se at det er en konfigurasjonstabell, siden den har en « sett ” i hierarkiet. Derfor skal vi fylle ut \_item\_cfgtables med UserTable key.

Dette er klassebyggerfunksjonen for å generere tabellklassen for konfigurasjonstypetabeller.

Tabellklassen har en referanse til visningsklassen, derav hvis det er en visning definert under tabellseksjonen, skal vi opprette en klasse for den visningen ved hjelp av \_build\_view () metoden og angi klassen som verdien av “ visning ” -tasten.

Ordboken get () -metoden, gjør det mulig å angi en standardverdi hvis nøkkelen ikke er tilstede , her vil « visningsnavn ” -tasten være fraværende, så \_build\_view ( view\_name ) vil opprette en klasse og knytte klassen som verdi til view\_name nøkkel. Det vil også trekke ut gruppene, eval, felt og lagre dem i interne felt for visningsobjekter.

Vi vil først sjekke hvordan beholderen CFGTABLE opprettes på \_CFGTBL
\_CFGTBL = FactoryCfgTable

Python lar deg for å opprette dynamiske klasser eller typer ved hjelp av metoden “ type .
Hvis“ type ”blir sendt et eksisterende objekt, den returnerer sin type. Imidlertid, hvis “ type ” blir sendt 3 argumenter, “ klasse navn ”,“ baser tuple ”,“ dict ”så det returnerer en ny klasse. Det er også en “ vars ” -metode, som returnerer \_\_dict\_\_ attributt, som lagrer objekter som kan skrives. Python oppretter andre klasser ved hjelp av metaklasser.

Vi kan sende navnet på klassen som den nye klassen vil arve som en enkelt tuple: For f.eks: new\_cls = type (table\_name, (CfgTable,), {})

Hvis “ sett ”nøkkelord er tilstede under tabelldelen:
for f.eks: sett: system / login / user
Så vi bør også passere i config-baseklassen for å lage vår UserTable-klasse:
For f.eks: new\_cls = type (table\_name, (CfgTable, Config), {})

felt som automatisk fylles ut i klasse

En gang klassen er opprettet, vil vi legge den til i katalogen over fabrikklasterklasser: self.catalog [table\_name] = cls

Nå går vi videre til å konstruere visningsklassen:

view\_name = tbl\_dict [“ view ”]
tbl\_dict [“ view ”] = self.catalog.get (view\_name, self.\_build\_view (view\_name))

view\_name definert i “ user.yml ” -filen er “ userView ”.

Til slutt,“ last ”Kommer til å returnere en katalog med klasser opprettet av FactoryLoader klassen.

Så oppsummerer banen:

Det fullfører bare en del der yml konverteres til klasser som deretter kan brukes til å operere. Så neste gang begynner vi med å lage et objekt av klassen UserTable.

user\_table = UserTable (dev)

Siden den nylig opprettede UserTable arver fra CfgTable og Config-baseklasser, vil vi arve konstruktøren og alle metodene som er definert i disse basisklassene. Så snart vi oppretter et nytt UserTable -objekt, kaller det \_\_init\_\_ av foreldreklassene. Siden “ sett ” er nevnt i yml-filen, vil vi også kalle konstruktøren av config baseklasse.

Etter dette, ring get () -metoden for å hente konfigurasjonsdata for system / login / user hierarki.
Vi sjekker alternativet namesonly = false .

Husk at hierarkiet for xpath-uttrykket allerede var satt gjennom sett: system / login / bruker “ user.yml ”uttalelse. En funksjon \_build\_xml oversetter det til en. XML som nedenfor:

Hvis brukeren spesifiserte et spesifikt brukernavn, referert til som “ namekey ” så trenger vi for å sette det inn i generert xml ovenfor. For f.eks.: Get (user = ”regress”) vil sette inn elementelementet med verdiregress:

regress

alt pakkes inn i get\_cmd og sendes til selv.RPC.get\_config (get\_cmd)
En typisk XML- RPC ser slik ut nedenfor:

format for XML RPC-metoden kall XML

Vår XML for get-brukerinformasjonen ser slik ut:

Denne XML-RPC konverteres til en HTTP POST-forespørsel og sendes til serveren: Utfører en XML RPC og returnerer resultater som enten XML eller native python

Den faktiske rpc-samtalen gjøres via ncclients rpc-metode over ssh slik at data blir kryptert.

RPC-håndtering av rpc\_cmd\_e er. gjort av ncclient som gir implementering for netconf over ssh. Det blir vanskelig å forstå hvor rpc-metoden i Manager () -objektet fra ncclient-pakken faktisk er definert. Etter å ha studert ncclient-biblioteket, fant jeg ut at det er definert som en ordliste over metoder med “rpc” = ExecuteRpc , og denne ordboken er leverandørspesifikk. Klikk her for å lese mer .

Hele denne operasjonen for å navngi ordboken blir opprettet for hver tilkoblingsforespørsel basert på leverandøren, og returneres.

Den endelige XML RPC ble sendt over ssh for netconf-server på Junos-enhet

En rask oppsummering av start og utveksling av netconf-sesjonen:

Klienten må starte en netconf-tilkobling til port 830 over ssh. Serveren skal sende sin HELLO -melding med en gang, og klienten bør også gjøre det samme. Hele hallo > -meldingen spesifiserer klientens og serverens muligheter. Serveren bør da vente med å behandle alle rpc > forespørsler, og skal sende en rpc-svar >. Klienten kan legge til så mange XML-attributter til rpc > som ønsket, og serveren returnerer alle attributtene i rpc-svar > element.

Svaret er analysert for ok > og rpc-feil > koder som indikerer ingen / noen feil. Deretter blir den transformert i et enhets- / leverandøravhengig format, fjern navneområdekoder osv.

Svaret blir endelig mottatt som nedenfor:

[(regress, [(user, regress), (uid, 928), (class\_name, superuser), (password, abc123 @ # $ # $ ^)])]