Tabeller och vyer med Junos Pyez

(Nayan Gadre) (12 sep 2020)

Dessa är anteckningar som skapats medan arbetar med Junos pyez-biblioteket för nätverksautomatisering. Junos tillhandahåller tabeller och vyer för att ställa in och extrahera anpassade konfigurationsdata. All pyez-kod och ncclient är opensource under Apache 2.0-licens

Du definierar en tabell och en vy i en Yaml-fil i lib / jnpr / junos / resurser
såsom “ user.yml ” och dess motsvarande loader-fil som “ user.py

user.yml
user.py

user.py ”används för att konvertera yaml-filen Tabell och visa definitioner till pythons globala ordbokselement. Här pekar \_\_file \_\_ på ” user.py ” -fil som kommer. konverteras sedan till “ user.yml ” filnamn. Junos pyezs loadyaml konverterar sedan användaren “. id = ”bdc0565b95”> ”i en ordbok för att lägga till den i globalerna () ordlistan.

Både definitionerna i tabellen och vyn i yaml omvandlas till klasser i python. loadyaml är en fabriksmetod och exponeras som ett offentligt API med \_\_ alla \_\_ pythonisk deklaration. Den tillhandahåller en ordlista med definitioner av artikelnamn och artikelklass, vilket kan ses i en rad.

User.yml-filen är uppdelad i två tangenter på toppnivå: “ UserTable ” och “ UserView ” så att loadyaml returnerar två klasser med dessa namn.

ordbok konverterad från användaren.yml

Denna ordbok skickas till FactoryLoader.load ( ) metod för att generera klasser:

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

Syftet med fabriksladdarklass

Ordböckerna () metod r skapar ett visningsobjekt som innehåller en lista med tuplar som innehåller nyckel-värdepar.

Sättet som fabriksladdaren bestämmer om det angivna tabell- och visningsschemat är för konfiguration eller för operationer sker via tangenterna i schemat . Till exempel: “ ställer in ” och “ får ” -tangenterna skulle göra det till en konfigurationstabell,
rpc ” då är det en operation tabell, “ kommando ” eller “ titel ” då är det en kommandotabell, det finns också en förvirrande kombination av ” objekt ” “ visa ”och“ * ”vilket också dikterar om det är en kommandotabell.

Eftersom vi fokuserar på “ user.yml ” kan vi se att det är en konfigurationstabell, eftersom den har en ” ställer in ” i dess hierarki. Därför ska vi fylla i \_item\_cfgtables med Användartabell nyckel.

Detta är klassbyggarfunktionen för att generera tabellklassen för konfigurationstabeller.

Tabellklassen innehåller en referens till Visa-klassen, därav om det finns en vy definierad under tabellavsnittet ska vi skapa en klass för den vyn med metoden \_build\_view () och ställa in klassen som värdet för “ visa ” -tangenten.

Ordboken get () -metoden gör det möjligt att ställa in ett standardvärde om nyckeln inte finns , här kommer view\_name ”frånvarande, så \_build\_view ( view\_name ) skapar en klass och associerar klassen som värde till view\_name tangent. Det extraherar också grupperna, eval, fält och lagrar dem i interna fält för visningsobjekt.

Vi kommer först att kontrollera hur behållaren CFGTABLE skapas på \_CFGTBL
\_CFGTBL = FactoryCfgTable

Python låter dig för att skapa dynamiska klasser eller typer med ” typ ” -metoden.
Om ” typ ”skickas ett befintligt objekt, det returnerar sin typ. Men om ” typ ” skickas tre argument, “ klassnamn ”,“ bas tuple ”,“ dict ”sedan returnerar en ny klass. Det finns också en metod vars ”, som returnerar \_\_dict\_\_ attribut, som lagrar objekt skrivbara attribut. Python skapar andra klasser med hjälp av metaclasses.

Vi kan skicka namnet på den klass från vilken den nya klassen kommer att ärva som en enkel tupel: För t.ex.: new\_cls = type (tabellnamn, (CfgTable,), {})

Om “ set ”nyckelordet finns under tabellavsnittet:
för t.ex.: set: system / inloggning / användare
Så vi borde också skicka i config-basklassen för att skapa vår UserTable-klass:
För t.ex.: new\_cls = type (tabellnamn, (CfgTable, Config), {})

fält som fylls automatiskt i klass

En gång klassen skapas kommer vi att lägga till den i katalogen över fabriksladdarklasser: self.catalog [table\_name] = cls

Nu går vi vidare till att konstruera visningsklassen:

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

view\_name definierad i “ user.yml ” -filen är “ userView ”.

Slutligen,“ ladda ”Kommer att returnera en katalog över klasser som skapats av klassen FactoryLoader .

Så sammanfattar sökvägen:

Det är bara en del där yml konverteras till klasser som sedan kan användas för att fungera. Så nästa, vi börjar med att skapa ett objekt av vår UserTable-klass.

user\_table = UserTable (dev)

Sedan den nyligen skapade UserTable ärver från CfgTable och Config-basklasser kommer vi att ärva konstruktorn och alla metoder som definieras i dessa basklasser. Så snart vi skapar ett nytt UserTable -objekt kallar det \_\_init\_\_ för överordnade klasser. Eftersom “ set ” nämns i yml-filen kommer vi också att ringa konstruktören för konfiguration basklass.

Efter detta, ring get () metod för att hämta konfigurationsdata för system / inloggning / användare hierarki.
Vi kontrollerar alternativet namesonly = false .

Kom ihåg att hierarkin för xpath-uttrycket redan var inställt genom set: system / login / user ” user.yml ”uttalande. En funktion \_build\_xml översätter den till en. XML som nedan:

Om användaren angav ett specifikt användarnamn, kallat “ namekey ” så behöver vi för att infoga det i ovan genererade xml. För t.ex.: get (user = ”regress”) skulle infoga namnelementet med värdet regress:

regress

allt packas i get\_cmd och skickas till själv.RPC.get\_config (get\_cmd)
En typisk XML- RPC ser ut så här nedan:

format för XML RPC-metodanrop XML

Vår XML för get-användarinformation ser ut så här:

Denna XML-RPC omvandlas till en HTTP POST-begäran och skickas till servern: Utför en XML-RPC och returnerar resultat som antingen XML eller native python

Det faktiska RPC-samtalet görs via ncclients rpc-metod över ssh så att data krypteras.

RPC-hantering av rpc\_cmd\_e är. gjort av ncclient som ger implementering för netconf över ssh. Det blir svårt att förstå var rpc-metoden i Manager () -objektet från ncclient-paketet faktiskt definieras. Efter att ha studerat ncclient-biblioteket fann jag att det definierades som en ordlista över metoder med “rpc” = ExecuteRpc , och den här ordboken är leverantörsspecifik. Klicka här för att läsa mer .

Hela åtgärden för att namnge ordlistan skapas för varje anslutningsförfrågan baserat på leverantören och returneras.

Den slutliga XML RPC skickades över ssh för netconf-servern på Junos-enhet

En snabb sammanfattning av netconf-sessionens initiering och utbyte:

Klienten måste initiera en netconf-anslutning till port 830 över ssh. Servern ska skicka meddelandet HELLO och klienten bör också göra detsamma. Hela meddelandet hej > specificerar klientens och servern. Servern ska sedan vänta med att behandla alla rpc > förfrågningar och ska skicka en rpc-svar >. Klienten kan lägga till så många XML-attribut till rpc > som önskat och servern returnerar alla dessa attribut i rpc-svar > element.

Svaret analyseras för ok > och rpc-error > taggar som indikerar inga / några fel. Sedan omvandlas den i ett enhets- / leverantörsberoende format, tar bort namnområdestaggar etc.

Svaret mottas äntligen enligt nedan:

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