Tabeller og synspunkter med Junos Pyez

(Nayan Gadre) (12. sep 2020)

Dette er noter oprettet, mens arbejder med Junos pyez-biblioteket til netværksautomatisering. Junos leverer tabeller og visninger til at indstille og udtrække brugerdefinerede konfigurationsdata. Al pyez-kode og ncclient er opensource under Apache 2.0-licens

Du definerer en tabel og en visning i en Yaml-fil i lib / jnpr / junos / ressourcer
såsom “ user.yml ” og dens tilsvarende loader-fil som “ user.py

user.yml
user.py

user.py ”bruges til at konvertere yaml-filen Tabel og se definitioner til pythons globale ordbogselementer. Her peger \_\_file \_\_ på “ user.py ” -fil, der vil. konverteres derefter til “ user.yml ” filnavn. Junos pyezs loadyaml konverterer derefter brugeren “.yml ”i en ordbog for at føje den til globaler () ordbog.

Både definitionerne i tabel og visning i yaml konverteres til klasser i python. loadyaml er en fabriksmetode og eksponeres som offentlig API ved hjælp af \_\_ alle \_\_ pythonisk erklæring. Det giver en ordbog med definitioner på varenavn og vareklasse, som det kan ses i snaplinjen på en linje.

User.yml-filen er opdelt i to øverste niveau-taster: “ UserTable ” og “ UserView ” så loadyaml returnerer 2 klasser med disse navne.

ordbog konverteret fra brugeren.yml

Denne ordbog overføres til FactoryLoader.load ( ) metode til at generere klasser:

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

Formålet med fabrikslæsserklasse

Ordbøgerne () metoden r eturerer et visningsobjekt, der indeholder en liste over tupler, der indeholder nøgleværdipar.

Den måde, fabriksindlæseren beslutter, om det angivne tabel- og visningsskema er til konfiguration eller til operation, er via de nøgler, der findes i skemaet . For eksempel: “ sæt ” og “” nøgler ville gøre det til en konfigurationstabel,
rpc ” så er det en operation tabel, “ kommando ” eller “ titel ” så er det en kommandotabel, der er også en forvirrende kombination af “ element ” “ visning ”og“ * ”som også dikterer, om det er en kommandotabel.

Da vi fokuserer på “ user.yml ” kan vi se, at det “er en konfigurationstabel, da den har en” sæt ” i dets hierarki. Derfor skal vi udfylde \_item\_cfgtables med UserTable -tast.

Dette er klassebygningsfunktionen til at generere tabelklassen til konfigurationstypetabeller.

Tabelklassen indeholder en henvisning til visningsklassen, derfor hvis der er en visning defineret under tabelafsnittet, opretter vi en klasse til den visning ved hjælp af \_build\_view () -metoden og sæt klassen som værdien for “ visning ” -tasten.

Ordbogen get () -metoden giver mulighed for at indstille en standardværdi, hvis nøglen ikke er til stede her “ view\_name ” -tasten vil være fraværende, så \_build\_view ( view\_name ) opretter en klasse og knytter klassen som værdi til view\_name tast. Det vil også udtrække grupperne, eval, felter og gemme dem i visningsobjektets interne felter.

Vi vil først kontrollere, hvordan containeren CFGTABLE oprettes på \_CFGTBL
\_CFGTBL = FactoryCfgTable

Python giver dig mulighed for at oprette dynamiske klasser eller typer ved hjælp af metoden “ type .
Hvis“ type ”sendes til et eksisterende objekt, det returnerer sin type. Men hvis “ type ” sendes 3 argumenter, “ klasse navn ”,“ bases tuple ”,“ dict ”så er det returnerer en ny klasse. Der er også en “ vars ” metode, som returnerer \_\_dict\_\_ -attribut, der gemmer objekter, der kan skrives. Python opretter andre klasser ved hjælp af metaclasses.

Vi kan videregive navnet på den klasse, hvorfra den nye klasse arver som en enkelt tuple: For f.eks: new\_cls = type (tabelnavn, (CfgTable,), {})

Hvis “ sæt ”nøgleord findes under tabelafsnittet:
for f.eks: sæt: system / login / bruger
Så vi skal også videregive i config-baseklassen for at oprette vores UserTable-klasse:
For eksempel: new\_cls = type (tabelnavn, (CfgTable, Config), {})

felter, der automatisk udfyldes i klasse

Når klassen er er oprettet, vil vi tilføje det til kataloget over fabriksladerklasser: self.catalog [table\_name] = cls

Går nu videre til at konstruere visningsklassen:

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

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

Endelig skal” indlæses ”Returnerer et katalog over klasser oprettet af FactoryLoader klassen.

Så opsummerende sti:

Det er bare at udfylde en del, hvor yml konverteres til klasser, som derefter kan bruges til at arbejde på. Så næste, vi starter med at oprette et objekt fra vores UserTable-klasse.

user\_table = UserTable (dev)

Siden den nyoprettede UserTable arver fra CfgTable og Config-baseklasser, arver vi konstruktøren og alle metoder defineret i disse basisklasser. Så snart vi opretter et nyt UserTable objekt, kalder det \_\_init\_\_ for de overordnede klasser. Da “ sæt ” er nævnt i yml-filen, vil vi også kalde konstruktøren af ​​config basisklasse.

Herefter kaldes get () metoden til at hente konfigurationsdata til system / login / bruger hierarki.
Vi kontrollerer først indstillingen namesonly = false .

Husk hierarkiet for xpath-udtrykket var allerede indstillet gennem sæt: system / login / bruger “ user.yml ”udsagn. En funktion \_build\_xml oversætter det til en. XML som nedenfor:

Hvis brugeren specificerede et specifikt brugernavn, kaldet “ namekey ” så har vi brug for for at indsætte det i ovenstående genererede xml. For eksempel: get (user = ”regress”) indsætter navnelementet med værdi regress:

regress

alt pakkes ind i get\_cmd og sendes til self.RPC.get\_config (get\_cmd)
En typisk XML- RPC ser sådan ud nedenfor:

format af XML RPC-metode kald XML

Vores XML til get-brugeroplysningerne ser sådan ud:

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

Det faktiske RPC-opkald foretages via ncclients rpc-metode over ssh, så data krypteres.

RPC-håndtering af rpc\_cmd\_e er. udført af ncclient, som giver implementering af netconf over ssh. Det bliver svært at forstå, hvor rpc-metoden i Manager () -objektet fra ncclient-pakken faktisk er defineret. Efter at have studeret ncclient-biblioteket fandt jeg ud af, at det er defineret som en ordbog over metoder med “rpc” = ExecuteRpc , og denne ordbog er leverandørspecifik. Klik her for at læse mere .

Hele denne operation for at navngive ordbogen oprettes for hver tilslutningsanmodning baseret på leverandøren og returneres.

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

En hurtig resume af netconf-sessionens initiering og udveksling:

Klienten skal starte en netconf-forbindelse til port 830 over ssh. Serveren skal sende sin HELLO -meddelelse med det samme, og klienten skal også gøre det samme. Hele hej > meddelelsen specificerer klientens og serverens muligheder. Serveren skal derefter vente med at behandle alle rpc > anmodninger og skal sende en rpc-svar >. Klienten kan tilføje så mange XML-attributter til rpc > som ønsket, og serveren returnerer alle disse attributter i rpc-svar > element.

Svaret er analyseret for ok > og rpc-fejl > tags, der angiver ingen / nogen fejl. Derefter omdannes det i et enheds- / leverandørafhængigt format, fjern navneområdetags osv.

Svaret modtages endelig som nedenfor:

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