Junos PyEZ構成テーブルを使用して、Junosデバイス上の構造化リソースを設定する
Junos PyEZ 設定 プロパティを指定する set テーブルを使用すると、Junos デバイスをプログラムによって設定するために使用できる構造化リソースを定義できます。構造化リソースのテーブル定義をJunos PyEZアプリケーションにロードまたはインポートすると、アプリケーションはデバイス上でリソースを設定できます。このトピックでは、Junos PyEZ 構成テーブルとビューを使用して、デバイス上の構造化リソースを構成するための一般的なプロセスといくつかの特定のタスクについて説明します。
一般的な構成プロセス
構成テーブル set プロパティは、リソースが構成されている構成階層レベルを識別し、ビュー内のフィールドの XPath コンテキストを設定します。たとえば、次の表では、 user 階層レベルでリソース [edit system login] が定義されています。
UserConfigTable:
set: system/login/user
key-field:
username
view: UserConfigView
UserConfigView:
groups:
auth: authentication
fields:
username: name
userclass: { class : { 'default' : 'unauthorized' }}
uid: { uid: { 'type': 'int', 'minValue':100, 'maxValue':64000 }}
fullname: full-name
fields_auth:
password: encrypted-password
ビューに含まれるフィールドは、ユーザーがそのリソースに対して構成できるリーフステートメントを定義します。フィールドには、既定値、型チェック、制約チェックを定義できます。
デバイス上に構造化リソースを構成するには、アプリケーションに Table を読み込むかインポートする必要があります。次に、Table オブジェクトを作成し、 Device ターゲット デバイスのオブジェクトに関連付けます。例えば：
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
from lxml import etree
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
リソースの設定ステートメントの値を定義するには、対応するフィールド名(ビューで定義)を目的の値と同じに設定します。
table_object.fieldname = value
フィールドの既定値は、View でそのフィールドの既定値が明示的に定義されていない限りです None 。ビューでフィールドの型または制約チェックが定義されている場合、アプリケーションはそのフィールドに正しいデータ型と値を指定し、チェックが失敗した場合に発生する可能性のあるエラーを処理するのが理想的です。Table key-field のプロパティで宣言されているすべてのキー フィールドの値 (この例では username) を常に定義する必要があります。
次のコードはUserConfigTable、 、 userclass、および usernamepassword の各フィールドの値をインポートして構成します。ビューのフィールドはpassword、設定内の ステートメントを参照encrypted-passwordします。したがって、データは事前に暗号化されたパスワードを提供する必要があります。
# Python 3
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
from lxml import etree
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
uc.username = 'user1'
uc.userclass = 'operator'
uc.password = '$ABC123'
...
固定形式のキーワードまたは複数の値を使用したステートメントの設定、ステートメントまたはリソースの複数のインスタンスの設定、リーフまたはコンテナステートメントの削除、Junos XML属性に対応するオブジェクトプロパティの設定など、より具体的な設定タスクの詳細については、次のセクションを参照してください。
オブジェクトを設定した後、メソッドを呼び出して append() 対応する Junos XML 設定を構築し、その Table オブジェクトの設定変更のマスター セットを格納するオブジェクトに追加 lxml する必要があります。構成の変更には、ビューで定義されたデフォルト値またはユーザー構成値のいずれかを持つフィールドのみが含まれます。の初期 None 値を保持するフィールドは無視されます。
uc.append()
XML の作成後、このメソッドはすべてのフィールドを既定値にリセットするかNone、append()View がそのフィールドの既定値を定義していない場合にリセットします。これにより、同じアプリケーションで複数のオブジェクトを構成でき、後続のリソースを構成するときに 1 つのリソースに定義された値が意図せずに使用されないようにすることができます。新しいリソースを構成するたびに、呼び出しappend()て構成の変更を変更のマスター セットに追加する必要があります。このappend()メソッドの詳細については、append() を使用した Junos XML 設定データの生成を参照してください。
必要に応じて、メソッドを呼び出して reset() Table オブジェクトのすべてのフィールドを手動でリセットすることもできます。
uc.reset()
このメソッドは reset() 、すべてのフィールドを既定値に復元するか、View で既定値が定義されていない場合は復元 None します。このメソッドは reset() 、フィールドの現在の値をリセットするだけです。メソッドの呼び出し append() によってその時点までに構築された構成変更を含む XML には影響しません。
「構成の変更の表示」で詳しく説明しているメソッドを呼び出すget_table_xml()ことで、アプリケーションの任意の時点で変更を表す XML 構成を取得できます。
configXML = uc.get_table_xml()
if (configXML is not None):
print (etree.tostring(configXML, encoding='unicode', pretty_print=True))
必要なオブジェクトをすべて設定して を呼び出し append()た後、次の 2 つの方法のいずれかを使用して、設定の変更をデバイスの共有設定データベースに読み込むことができます。
set()、load()、commit()、およびunlock()の各メソッドを自動的に呼び出すメソッドを呼び出します。lock()、
load()、commit()、およびunlock()の各メソッドを個別にlock()呼び出します
uc.set()
特定の構成モードを使用するパラメーターを含むmodeコンテキスト マネージャー (with ... as 構文) を使用して Table インスタンスを作成すると、コンテキスト マネージャーがデータベースの開閉とロック解除を処理します。この場合、デバイスを構成するために必要なのは、 load() および commit() メソッドを呼び出すことだけです。または set() メソッドを呼び出すlock()と、LockError例外が発生します。
1 つのset()メソッドを使用すると簡単になりますが、個々のメソッドを呼び出すと、構成データを読み込んだ後、コミットする前に他のメソッドを呼び出す必要がある場合など、柔軟性が高まります。たとえば、または pdiff() メソッドを呼び出してdiff()、データを読み込んだ後、コミットする前に構成の違いを確認できます。または、メソッドを呼び出してrollback()、候補構成をコミットするのではなく、アクティブな構成にリセットする必要がある場合があります。さまざまな方法を使用して設定データを読み込んでコミットする方法の詳細については、次を参照してください:Junos PyEZを使用してJunosデバイスを設定するおよびJunos PyEZを使用して設定をコミットするを参照してください。
タイムアウトする可能性がある大規模なロード操作とコミット操作の場合は、or commit() メソッド引数リストにパラメーターset()を含めるtimeoutことで、RPC タイムアウト間隔を調整できます。詳細については、「RPC タイムアウト間隔を制御する方法」を参照してください。
パラメーターを指定する set 構成テーブルはスーパーセットであり、パラメーターを指定する get 構成テーブルのすべての機能を備えています。Junos PyEZ アプリケーションでは、Table set getで または が を指定しているかどうかに関係なく、同じ方法で設定データを取得できます。設定テーブルを使用して設定データを取得する方法については、 Junos PyEZ設定テーブルを使用して設定データを取得するを参照してください。
固定形式のキーワードで構成されるステートメントの設定
リーフ ステートメントは、他のステートメントを含まない CLI 設定ステートメントです。ほとんどのリーフステートメントは、設定オブジェクトの1つの特性の値を定義し、次の形式をとります。
keyword value;
一部のリーフステートメントは固定形式のキーワードのみで構成され、変数形式の値は関連付けられていません。例えば、[edit system services]階層レベルの ステートメントは、ftp固定形式キーワードの例です。
system {
services {
ftp;
}
}
Junos XML APIは、このようなステートメントを空のタグで表現します。
<configuration>
<system>
<services>
<ftp>
</ftp>
...
</services>
</system>
</configuration>
Junos PyEZアプリケーションで固定形式のキーワードを設定するには、 ftp のステートメント [edit system services]のように、 ビューで定義されている対応するフィールド名の値をブール値 Trueと等しく設定します。
次の View について考えてみます。このビューでは、型の制約を使用してフィールドを定義し ftp 、フィールドの値がブール値になるようにします。
ServicesView:
fields:
ftp: { 'ftp' : { 'type': 'bool' } }
...
Junos PyEZアプリケーションでフィールドを設定するには ftp 、フィールド Trueを に設定します。
from jnpr.junos import Device
from myTables.ConfigTables import ServicesConfigTable
with Device(host='router.example.com') as dev:
sc = ServicesConfigTable(dev)
sc.ftp = True
sc.append()
sc.set()
同じステートメントに複数の値を設定する
Junos OSのリーフステートメントには、ユーザーが定義したものや、事前に定義した値のセットから抽出された複数の値を受け入れるものがあります。CLI 表記では、次のように、角括弧を使用してすべての値を 1 つのステートメントで囲みます。
keyword [ value1 value2 value3 ...];
例えば、以下の構成のように、トランクインターフェイスのVLAN IDリストの構成が必要になる場合があります。
interfaces {
ge-0/0/1 {
native-vlan-id 510;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 510 520 530 ];
}
}
}
}
Junos PyEZアプリケーションで複数の値を持つリーフステートメントを設定するには、対応するフィールド(ビューで定義)の値を、目的の値を含むPythonリストと同じに設定します。次の例では、フィールドが vlan_list CLI のステートメントに vlan-id-list マッピングされます。複数のVLAN IDを持つ ステートメントを設定するには、フィールド名をIDのリストと同じに設定します。
from jnpr.junos import Device
from myTables.ConfigTables import InterfacesConfigTable
with Device(host='router.example.com') as dev:
intf = InterfacesConfigTable(dev)
intf.name = 'ge-0/0/1'
intf.mode = 'trunk'
intf.native_vlan = 510
intf.vlan_list = [510, 520, 530]
intf.append()
intf.set()
同じステートメントの複数のインスタンスを設定する
特定の状況では、Junos OSの設定により、同じステートメントの複数のインスタンスを設定できます。例えば、論理インターフェースに同じプロトコルファミリーで複数のアドレスを設定することができます。次の設定スニペットでは、ループバックインターフェイスに 階層レベルで設定された複数のアドレス [edit interfaces lo0 unit 0 family inet] があります。
interfaces {
lo0 {
unit 0 {
family inet {
address 192.168.100.1/32;
address 192.168.100.2/32;
}
}
}
}
設定の Junos XML 表現は次のとおりです。
<configuration>
<interfaces>
<interface>
<name>lo0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>192.168.100.1/32</name>
</address>
<address>
<name>192.168.100.2/32</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
Junos PyEZ設定テーブルを使用して構造化リソースを管理する場合、対応するフィールド名を目的の値と等しく設定することで、設定ステートメントの値を定義します。しかし、Junos PyEZアプリケーションでは、2番目の値によって最初の値が上書きされるため、同じフィールドを2回定義することはできません。代わりに、フィールドを値のリストに等しく設定する必要があり、Junos PyEZがXMLへの変換を処理します。
次の表とビューについて考えてみます。
InterfaceTable:
set: interfaces/interface
key-field:
- name
- unit_name
view: InterfaceView
InterfaceView:
fields:
name: name
desc: description
unit_name: unit/name
ip_address: unit/family/inet/address
次のサンプルコードは、Junos PyEZアプリケーションでループバックインターフェイスに複数のアドレスを設定する方法を示しています。この場合、フィールドを ip_address アドレスのリストと等しく設定します。
lo0_addresses = ['192.168.100.1/32', '192.168.100.2/32']
...
intf = InterfaceTable(dev)
intf.name='lo0'
intf.unit_name = 0
intf.ip_address = lo0_addresses
intf.append()
intf.set()
...
その結果、次のようになります。
[edit interfaces]
+ lo0 {
+ unit 0 {
+ family inet {
+ address 192.168.100.1/32;
+ address 192.168.100.2/32;
+ }
+ }
+ }
同じリソースの複数のインスタンスを構成する
Junos PyEZ設定テーブルを使用して構造化リソースを設定する場合、同じリソースに対して複数のオブジェクトまたはレコードを設定する必要がある場合があります。例えば、複数のインターフェイスやユーザーを同時に設定することができます。Junos PyEZアプリケーションで同じ構造化リソースに対して複数のオブジェクトを設定するには、1つのオブジェクトのフィールドに値を定義し、メソッドを append() 呼び出し、後続のオブジェクトごとにこのプロセスを繰り返す必要があります。
たとえば、複数のユーザーを構成するには、最初のユーザーのフィールド値を定義し、メソッドを append() 呼び出します。次に、2 番目のユーザーのフィールド値を定義し、メソッドを呼び出します append() 。このメソッドは append() 、コンフィギュレーション変更用のJunos XMLデータを構築し、コンフィギュレーション変更のマスターセットを格納するオブジェクトに追加します lxml 。また、このメソッドは、すべてのフィールドを View で定義されている既定値に自動的にリセットするか、フィールドに既定値が定義されていない場合はリセット None します。
次に、2 つのユーザー オブジェクトを設定し、変更をコミットする例を示します。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
from lxml import etree
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
uc.username = 'user1'
uc.userclass = 'operator'
uc.uid = 1005
uc.password = '$ABC123'
uc.append()
uc.username = 'user2'
uc.userclass = 'operator'
uc.uid = 1006
uc.password = '$ABC123'
uc.append()
uc.set()
同じリソースに対して複数のオブジェクトの 1 つを構成した後にメソッドを呼び出 append() さないと、2 番目のオブジェクトのフィールド値によって最初のオブジェクトのフィールド値が上書きされます。
次のサンプル コードでは、よりコンパクトな構文を使用して、同じ 2 人のユーザーを構成します。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
from lxml import etree
users = ['user1', 'user2']
uids = ['1005', '1006']
passwds = ['$ABC123', '$ABC123']
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
for user, uid, passwd in zip(users, uids, passwds):
uc.username = user
uc.userclass = 'operator'
uc.uid = uid
uc.password = passwd
uc.append()
uc.set()
コンテナまたはリーフステートメントの削除
場合によっては、設定内のコンテナまたはリーフステートメントを削除する必要があります。Junos PyEZ 構成テーブルを使用して構造化リソースを管理する場合、適切なフィールド値を に設定 {'operation' : 'delete'}することで、アプリケーションでこの操作を実行できます。コンテナまたはリーフステートメントを削除するときは、削除が適用されるオブジェクトを示すために、常にすべてのキー項目の値を定義する必要があります。
次の Junos PyEZ 構成の表とビューについて考えてみます。
---
UserConfigTable2:
set: system/login
key-field:
- username
view: UserConfigView2
UserConfigView2:
groups:
auth: user/authentication
fields:
user: user
username: user/name
classname: { user/class : { 'type' : { 'enum' : ['operator', 'read-only', 'super-user'] } } }
uid: { user/uid : { 'type' : 'int', 'minValue' : 100, 'maxValue' : 64000 } }
fields_auth:
password: encrypted-password
テーブルとビューで定義されているリソースのリーフ ステートメントを削除するには、そのステートメント{'operation' : 'delete'}に対応するフィールドの値を に設定します。以下の例では、 user jsmithの ステートメントを削除しますuid。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable2
with Device(host='router.example.com') as dev:
uc = UserConfigTable2(dev)
uc.username = 'jsmith'
uc.uid = { 'operation' : 'delete' }
uc.append()
uc.set()
構成からコンテナーを削除するには、ビューでそのコンテナーのフィールドを定義する必要があります。テーブルとビューの例では、プロパティでset定義されている構成スコープは system/loginです。ビューは、コンテナにsystem/login/userマップするフィールド 'user' を定義します。この定義により、必要に応じてユーザー オブジェクトを削除できます。コンテナのフィールドを定義しない場合、削除できるのはコンテナ内のステートメントのみですが、コンテナ自体は削除できません。
Junos PyEZアプリケーションでコンテナを削除するには、コンテナ {'operation' : 'delete'}に対応するフィールドの値を に設定し、削除するオブジェクトを示すキーフィールドを定義します。次の例では、コンフィギュレーションからユーザ jsmith を削除します。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable2
from lxml import etree
with Device(host='router.example.com') as dev:
uc = UserConfigTable2(dev)
uc.user = { 'operation' : 'delete' }
uc.username = 'jsmith'
uc.append()
print (etree.tostring(uc.get_table_xml(), encoding='unicode', pretty_print=True))
uc.set()
アプリケーションは、メソッドから返された Junos XML 設定データを印刷します get_table_xml() 。識別子「jsmith」を持つユーザー要素には、 operation="delete" Junos OSにそのオブジェクトを設定から削除するよう指示する属性が含まれています。
<configuration>
<system>
<login>
<user operation="delete">
<name>jsmith</name>
</user>
</login>
</system>
</configuration>
Junos XML属性に対応するプロパティの設定
一部の設定モードコマンド (例えば deactivate 、 や protectは、inactive プロパティや protect プロパティなどの特定のプロパティを設定ステートメントに適用または削除します。CLIでは、このプロパティは設定ステートメントの前にあるタグで示されます。Junos XML 設定では、オブジェクトの XML 属性を使用してこのプロパティを示します。
たとえば、次のコマンドは、指定されたインターフェイスを無効にします。
[edit] user@host# deactivate interfaces ge-1/0/2
CLIで設定を表示すると、インターフェイス名の前にタグが表示されます inactive 。
[edit]
user@host# show interfaces
inactive: ge-1/0/2 {
description "to CustomerA";
unit 0 {
family inet {
address 198.51.100.1/24;
}
}
}
同様に、Junos XML 出力では、同じインターフェイスの要素に <interface> 属性 inactive="inactive" が含まれます。
user@host# show interfaces | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/18.3R1/junos">
<configuration junos:changed-seconds="1544581124" junos:changed-localtime="2018-12-11 18:18:44 PST">
<interfaces>
<interface inactive="inactive">
<name>ge-1/0/2</name>
<description>to CustomerA</description>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>198.51.100.1/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</rpc-reply>
Junos PyEZ 設定テーブルを使用すると、構造化リソースを設定する際に、オブジェクトでサポートされている XML 属性を定義できます。次の Junos PyEZ 構成の表とビューについて考えてみます。
InterfaceTable:
set: interfaces
key-field:
- name
view: InterfaceView
InterfaceView:
fields:
interface: interface
name: interface/name
desc: interface/description
unit_name: interface/unit/name
ip_address: interface/unit/family/inet/address
特定の構成オブジェクトの XML 属性を定義するには、そのフィールド (View で定義) を、属性とその値を含むディクショナリに設定します。たとえば、インターフェイスを定義したが、すぐに非アクティブ化するには、要素{'inactive':'inactive'}に対応する<interface>フィールドを に設定します。次の例では、指定されたインターフェイスを設定および非アクティブ化します。
from jnpr.junos import Device
from myTables.ifConfigTable import InterfaceTable
from lxml import etree
with Device(host='router.example.com') as dev:
intf = InterfaceTable(dev)
intf.name = 'ge-1/0/2'
intf.unit_name = 0
intf.ip_address = '198.51.100.1/24'
intf.desc = 'to CustomerA'
intf.interface = {'inactive':'inactive'}
intf.append()
configXML = intf.get_table_xml()
if (configXML is not None):
print (etree.tostring(configXML, encoding='unicode', pretty_print=True))
else:
print (configXML)
intf.set()
アプリケーションは、メソッドから返された Junos XML 設定データを印刷します get_table_xml() 。識別子 'ge-1/0/2' のインタフェース要素には、 inactive="inactive" 属性が含まれます。
<configuration>
<interfaces>
<interface inactive="inactive">
<name>ge-1/0/2</name>
<unit>
<name>0</name>
<family>
<inet>
<address>198.51.100.1/24</address>
</inet>
</family>
</unit>
<description>to CustomerA</description>
</interface>
</interfaces>
</configuration>
非アクティブなオブジェクトをアクティブ化するには、非アクティブなオブジェクト {'active':'active'}に対応する View フィールドを に設定します。
from jnpr.junos import Device
from myTables.ifConfigTable import InterfaceTable
from lxml import etree
with Device(host='router.example.com') as dev:
intf = InterfaceTable(dev)
intf.name = 'ge-1/0/2'
intf.interface = {'active':'active'}
intf.append()
intf.set()
同様に、構成要素を保護するか、保護された要素から属性を削除するには protect 、適切なフィールド値を {'protect':'protect'} または {'unprotect':'unprotect'}に設定します。Junos OS 設定における XML 属性の詳細については、 Junos XML 管理プロトコル開発者ガイド を参照してください。
append() を使用して Junos XML 設定データを生成します
Junos PyEZ設定テーブルを使用して構造化リソースを設定する場合、リソースのフィールドの値を定義し、メソッドを呼び出します append() 。メソッドを呼び出す append() たびに、現在の変更セットの Junos XML 設定データが生成され、設定変更のマスター セットが格納されているオブジェクトに追加されます lxml 。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
uc.username = 'user1'
uc.userclass = 'operator'
uc.password = '$ABC123'
uc.append()
uc.set()
メソッドを呼び出すと append() 、リソースの Junos XML 構成データが生成されます。構成の変更には、ビューで定義されたデフォルト値またはユーザー構成値のいずれかを持つフィールドのみが含まれます。の初期 None 値を保持するフィールドは無視されます。
XML の作成後、このメソッドはすべてのappend()フィールドを View で定義されている既定値にリセットするか、フィールドに既定値が定義されていない場合はリセットNoneします。フィールドをリセットすると、同じアプリケーションで複数のオブジェクトを設定するときに、1 つのオブジェクトにフィールド値を設定し、その後の別のオブジェクトの呼び出しappend()でその値を意図せずに使用することがなくなります。したがって、 を呼び出すappend()たびに、すべてのkey-fieldフィールドに新しい値を定義する必要があります。
構成変更のマスター セットにノードを追加すると、操作を元に戻すことはできません。
このメソッドはappend()、構成変更のマスター セットを含むオブジェクトに新しいlxml変更を追加するだけです。デバイス上で変更を読み込んでコミットするには、 メソッドまたは load() および commit() メソッドを明示的に呼び出すset()必要があります。
設定変更の表示
Junos PyEZ設定テーブルを使用して構造化リソースを設定する場合、リソースのフィールドの値を定義し、メソッドを呼び出します append() 。メソッドを呼び出す append() たびに、現在の変更セットの Junos XML 設定データが生成され、設定変更のマスター セットが格納されているオブジェクトに追加されます lxml 。場合によっては、アプリケーションのある時点までに構築された設定データを確認しなければならない場合や、設定変更をデバイスにロードした後に、候補となるコンフィギュレーションとアクティブなコンフィギュレーションの違いを確認したい場合があります。
変更を含む Junos XML 設定データを取得するには、Table オブジェクトのget_table_xml()メソッドを呼び出します。このメソッドはget_table_xml()、アプリケーションのその時点までに構築された XML 構成を返します。メソッドまたは load() および commit() メソッドを呼び出すset()と、アプリケーションはこのJunos XML設定データをデバイスにロードしてコミットします。
次の例では、get_table_xml()このメソッドを呼び出して構成の変更を取得し、変数にconfigXML格納します。メソッドを呼び出すappend()前に、メソッドNoneは get_table_xml() を返します。したがって、アプリケーションは、戻り値Noneが . でない場合にのみ、XML 構成データをシリアル化して出力します。
from jnpr.junos import Device
from myTables.ConfigTables import UserConfigTable
from lxml import etree
with Device(host='router.example.com') as dev:
uc = UserConfigTable(dev)
uc.username = 'user1'
uc.userclass = 'operator'
uc.password = '$ABC123'
uc.append()
configXML = uc.get_table_xml()
if (configXML is not None):
print (etree.tostring(configXML, encoding='unicode', pretty_print=True))
else:
print (configXML)
uc.set()
このメソッドは get_table_xml() 、コンフィギュレーション変更に関するJunos XMLデータのみを返します。また、コンフィギュレーションの変更をデバイスにロードした後に、候補となるコンフィギュレーションとアクティブなコンフィギュレーションを比較して、変更をコミットする前に相違点を確認することもできます。
相違点を取得するには、 、commit()load()および unlock() の各メソッドを個別に呼び出しlock()、データを読み込んだ後、コミットする前にメソッドを呼び出してpdiff()、構成の相違点を表示します。引数リストが空の場合、メソッドはpdiff()候補コンフィギュレーションとアクティブなコンフィギュレーションを比較し、パッチ形式の差分を標準出力に直接出力します。
...
uc.append()
uc.lock()
uc.load()
uc.pdiff()
...
uc.commit()
uc.unlock()
RPC タイムアウト間隔を制御する方法
Junos PyEZ設定テーブルを使用して構造化リソースを設定する場合、 メソッドまたは load() および commit() メソッドを呼び出すset()ことで、設定変更をロードしてコミットすることができます。メソッドとメソッドcommit()はset()、モジュールでdevice定義されている RPC タイムアウト値を使用します。プロパティに新しいDevicetimeout値を設定しない場合、Junos PyEZはデフォルト値の30秒を使用します。
大規模な設定変更は、デフォルトまたは構成されたタイムアウト値を超え、構成をデバイスにアップロードしてコミットする前に操作がタイムアウトする可能性があります。デフォルトまたは構成されたタイムアウト間隔よりも長いロード時間とコミット時間を必要とする可能性がある特定の構成変更に対応するには、アプリケーションで または メソッドを呼び出すset()commit()ときに引数をtimeout=seconds適切な値に設定します。例えば：
uc = UserConfigTable(dev)
uc.username = 'user1'
uc.userclass = 'operator'
uc.uid = 1005
uc.password = '$ABC123'
uc.append()
uc.set(timeout=300)