구성 커밋
commit 구성 모드 명령을 사용하면 디바이스 구성 변경 사항을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화할 수 있습니다.
구성을 위한 커밋 모델
디바이스 구성은 커밋 모델을 사용하여 저장됩니다. 후보 구성은 원하는 대로 수정된 다음 시스템으로 커밋됩니다. 구성이 커밋되면 디바이스는 구문 오류가 있는지 구성을 확인하고, 오류가 없으면 구성이 juniper.conf.gz 로 저장되고 활성화됩니다. 이전 활성 구성 파일은 첫 번째 롤백 구성 파일(juniper.conf.1.gz)으로 저장되고, 다른 롤백 구성 파일은 1씩 증가합니다. 예를 들어, juniper.conf.1.gz 는 juniper.conf.2.gz으로 증가하여 두 번째 롤백 구성 파일이 됩니다. 디바이스는 시스템에 최대 49개의 롤백 구성(번호가 1에서 49까지)을 저장할 수 있습니다.
디바이스에서 현재 구성 파일과 처음 3개의 롤백 파일(juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3)은 /config 디렉터리에 있습니다. (4부터 49까지의 나머지 롤백 파일은 /var/db/config에 있습니다.)
복구 구성 파일이 rescue.conf.gz 있는 경우 이 파일도 /config 디렉터리에 있습니다. 공장 기본 파일은 /etc/config 디렉터리에 있습니다.
디바이스 내 라우팅 엔진 간에 구성을 전파하는 데 사용되는 두 가지 메커니즘이 있습니다:
동기화: 동일한 디바이스 섀시 내에서 하나의 라우팅 엔진에서 두 번째 라우팅 엔진으로 구성을 전파합니다.
구성을 동기화하려면 CLI 명령을 사용합니다
commit synchronize. 라우팅 엔진 중 하나가 잠기면, 동기화는 실패합니다. 잠긴 구성 파일 때문에 동기화가 실패하면, 이commit synchronize force명령을 사용할 수 있습니다. 이 명령은 잠금을 재정의하고 구성 파일을 동기화합니다.-
배포: 다중 섀시 디바이스의 라우팅 플레인을 통해 구성을 전파합니다. 배포는 자동으로 발생합니다. 배포 프로세스를 제어할 수 있는 사용자 명령은 없습니다. 구성을 배포하는 동안 구성이 잠기면, 잠긴 구성은 배포된 구성 파일을 수신하지 않으므로 동기화가 실패합니다. 구성 전에 잠금을 제거하고 라우팅 플레인을 재동기화해야 합니다.
참고:다중 섀시 플랫폼에서 CLI 명령을 사용할
commit synchronize force때, 구성 파일의 강제 동기화는 라우팅 플레인 전체의 구성 파일 배포에 영향을 주지 않습니다. 구성 파일이 명령이 내려진 디바이스에서 멀리 떨어진 디바이스에 잠겨 있으면, 원격 디바이스에서의 동기화는 실패합니다. 잠금을 제거하고 명령을 다시 내려야 합니다.synchronization참고:Junos OS Evolved는 다음
commit구성 옵션을 지원하지 않습니다.-
fast-synchronize -
peers -
peer-synchronize -
commit-synchronize-server
-
디바이스 구성 커밋
디바이스 구성 변경 사항을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화하려면 구성 모드 명령을 사용합니다 commit . 모든 계층 수준에서 명령을 실행할 commit 수 있습니다.
[edit]
user@host# commit
commit complete
[edit]
user@host#
명령을 입력 commit 하면 먼저 구성에 구문 오류가commit check 있는지 확인합니다(). 그런 다음, 구문이 정확하면 구성이 활성화되고 현재 작동하는 디바이스 구성이 됩니다.
라우터에서 Graceful 라우팅 엔진 스위치오버가 활성화된 경우 백업 라우팅 엔진에서 커밋 작업을 수행하지 않는 것이 좋습니다.
구성 커밋은 다음과 같은 이유로 실패할 수 있습니다.
-
구성에 잘못된 구문이 포함되어 있어 커밋 검사에 실패합니다.
-
커밋하려는 후보 구성이 700MB보다 큽니다.
-
명령을 입력한 사용자에 의해 구성이 잠깁니다.
configure exclusive
구성에 구문 오류가 포함된 경우 오류의 위치를 나타내는 메시지가 표시되고 구성이 활성화되지 않습니다. 오류 메시지의 형식은 다음과 같습니다.
[editedit-path] ‘offending-statement;’error-message
예를 들어:
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
구성을 다시 커밋하기 전에 오류를 수정해야 합니다. 오류가 있는 계층 수준으로 신속하게 돌아가려면, 오류 첫 번째 줄에서 경로를 복사하여 계층 수준의 구성 모드 프롬프트 [edit] 에 붙여넣습니다.
커밋되지 않은 후보 구성 파일은 /var/rundb/juniper.db입니다. 기본적으로 파일 크기는 구성 데이터베이스의 기본 최대 크기로 제한됩니다. 명령을 실행 show system configuration database usage 하여 디스크의 데이터베이스 크기와 최대 데이터베이스 크기를 확인할 수 있습니다. 또한 명령을 실행하여 구성 모드에서 파일 크기를 볼 수도 있습니다. run file list /var/rundb detail 후보 구성이 최대 데이터베이스 크기를 초과하면 커밋이 실패하고 메시지가 표시됩니다. configuration database size limit exceeded 오류를 해결하기 위해 다음을 수행할 수 있습니다.
-
이 문을 지원하는 디바이스의 계층 수준에서
[edit system configuration-database]문을 구성extend-size하여 구성 데이터베이스의 최대 크기를 늘립니다. 변경사항을 적용하려면 디바이스를 재부팅해야 합니다. -
와일드카드로 구성 그룹을 만들거나 방화벽 필터에서 덜 구체적인 일치 정책을 정의하여 구성을 단순화하고 파일 크기를 줄입니다.
구성을 커밋하고 필요한 경우 재부팅한 후 명령을 show system configuration database usage 실행하여 디스크의 데이터베이스 크기 또는 최대 데이터베이스 크기에 대한 업데이트를 확인할 수 있습니다.
계층 수준에서 [edit interfaces] 구성 변경에 대해 표시되는 CLI 커밋 시간 경고가 제거되고 시스템 로그 메시지로 기록됩니다.
이는 다음 계층 수준의 VRRP 구성에도 적용할 수 있습니다.
-
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address] -
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]
구성을 커밋할 때 전체 구성을 현재 형식으로 커밋합니다.
-
디바이스에서 그레이스풀 라우팅 엔진 전환 이 활성화된 경우 백업 라우팅 엔진에서 커밋 작업을 수행하지 않는 것이 좋습니다.
-
관리 인터페이스 또는 내부 인터페이스
re0:mgmt-0(예: 및 외부 물리적 인터페이스xe-0/0/1)에 대해 동일한 IP 주소를 구성하는 경우, GRES(Graceful 라우팅 엔진 스위치오버)가 활성화되면 CLI는 프라이빗 및 공용 인터페이스에서 동일한 주소가 발견되었다는 적절한 커밋 오류 메시지를 표시합니다. 이러한 경우 중복 주소가 있는 두 인터페이스에 고유한 IP 주소를 할당해야 합니다.
여러 사용자가 소프트웨어를 구성할 때 커밋 작업
최대 32명의 사용자가 구성 모드에서 동시에 구성을 변경할 수 있습니다. 모든 사용자가 수행한 변경 사항은 구성을 편집하는 모든 사람에게 표시됩니다. 구성을 변경하는 명령(예 set: , edit, 또는 delete)의 끝에서 Enter 키를 누르는 즉시 변경 사항이 표시됩니다.
구성을 편집하는 사용자가 명령을 실행 commit 하면 CLI는 모든 사용자의 변경 사항을 확인하고 활성화합니다.
명령 configure private 으로 구성 모드에 들어가면, 각 사용자는 다른 사용자와 어느 정도 독립적으로 편집할 수 있는 프라이빗 후보 구성을 갖게 됩니다. 구성을 커밋하면 CLI는 자체 변경 사항만 커밋합니다. 다른 사용자가 변경 사항을 커밋한 후 구성 사본을 동기화하려면 구성 모드에서 명령을 실행할 update 수 있습니다. 또한 커밋 작업은 모든 프라이빗 후보 구성을 업데이트합니다. 예를 들어, 사용자 X와 사용자 Y가 모두 모드에 있고 configure private 사용자 X가 구성 변경을 커밋했다고 가정해봅시다. 사용자 Y가 후속 커밋 작업을 수행한 다음 새 구성을 볼 때, 사용자 Y가 보는 새 구성에는 사용자 X가 변경한 내용이 포함됩니다.
명령 configure exclusive 으로 구성 모드에 들어가면, 구성 모드를 유지하는 한 후보 구성을 잠급니다. 이를 통해 다른 사용자의 간섭 없이 변경할 수 있습니다. 다른 사용자는 구성 모드를 시작하고 종료할 수 있지만 구성을 커밋할 수는 없습니다. 명령을 입력하기 전에 다른 사용자가 구성 모드에 들어간 경우에도 마찬가지입니다.configure exclusive 예를 들어 사용자 X가 이미 or configure 모드에 있다고 configure private 가정해 보겠습니다. 그런 다음 사용자 Y가 모드에 들어간다고 가정합니다.configure exclusive 사용자 X는 사용자 Y가 로그인하기 전에 변경 사항을 입력한 경우에도 구성에 대한 변경 사항을 커밋할 수 없습니다. 사용자 Y가 configure exclusive 모드를 종료하면 사용자 X가 또는 configure 모드에서 변경한 configure private 내용을 커밋할 수 있습니다.
커밋 준비 및 활성화 개요
커밋 프로세스는 두 단계로 완료할 수 있습니다. 2단계 커밋 기능을 사용하면 여러 디바이스를 구성하는 동시에 구성을 활성화할 수 있습니다. 2단계 커밋은 커밋이 시스템에서 유효할 수 있는 결정적인 시간 창을 제공합니다. 커밋이 준비된 후 커밋 모드로 전환할 수 있지만 커밋이 활성화 보류 중이라는 메시지가 표시됩니다.
준비 단계인 첫 번째 단계에서 커밋의 유효성이 검사되고 필요한 파일이 포함된 새 데이터베이스가 생성됩니다. 구성에 구문 오류가 있으면 해당 오류 메시지가 표시되고 구성이 준비되지 않았습니다. 준비 단계에서 실패하면 오류 메시지가 commit check-out failed표시됩니다.
두 번째 단계인 활성화 단계에서는 미리 준비된 구성이 활성화됩니다. 다음으로, 준비된 구성을 지워야 하는 경우 명령을 사용하여 clear system commit prepared 지울 수 있습니다. 보류 중인 커밋을 성공적으로 지울 때 로그 메시지가 생성됩니다.
준비 단계와 활성화 단계 사이에는 구성을 변경하지 않는 것이 좋습니다.
2단계 커밋 프로세스는 time-critical 커밋의 경우 단일 단계 프로세스보다 우수합니다. 단일 단계 프로세스에서 준비 시간은 장치의 기존 구성에 따라 달라질 수 있습니다. 2단계 과정에서는 복잡한 준비 작업이 더 효율적으로 처리됩니다.
구성 캐시를 준비하고 구성을 활성화할 수 있는 구성 명령이 제공됩니다. 새 구성으로 장치를 준비하고 원하는 시간에 활성화할 수 있습니다.
명령은 commit prepare 구성을 검증하고 명령은 commit activate 구성을 활성화합니다. 명령에는 다음 구성 옵션이 있습니다.
-
and-quit -
no-synchronize -
peers-synchronize -
synchronize
and commit activate 명령은 commit prepare 비공개, 배타적 및 공유 커밋에만 사용할 수 있습니다. 이 명령은 동적 및 임시 모드에 적용할 수 없습니다. 이 기능은 다중 섀시 디바이스에 적용 가능하지만 배치 커밋에는 적용되지 않습니다.
NETCONF(Network Configuration Protocol)를 사용하여 이 기능을 지원하기 위해 다음과 같은 새로운 원격 절차 호출(RPC)이 제공됩니다.
-
<commit-configuration>< prepare/></commit-configuration> -
<commit-configuration><activate/></commit-configuration> -
<clear-system-commit><prepared/></clear-system-commit>
두 단계로 디바이스 구성 커밋: 준비 및 활성화
커밋 프로세스는 두 단계로 완료할 수 있습니다. 이렇게 하면 여러 디바이스를 구성할 수 있으며 구성을 동시에 활성화할 수 있습니다. 준비 단계로 알려진 첫 번째 단계에서 커밋의 유효성이 검사되고 필요한 파일과 함께 새 데이터베이스가 생성됩니다. 구성에 구문 오류가 있으면 해당 오류 메시지가 표시되고 구성이 준비되지 않았습니다. 활성화 단계라고 불리는 두 번째 단계에서, 미리 준비된 구성이 활성화되고 현재의 작동 디바이스 구성이 된다.
구성을 준비하려면:
준비된 구성을 활성화하려면
명령 사용
commit activate[edit] user@host#
commit activate메시지가
commit complete표시됩니다.활성화된 시스템 구성을 확인하려면 다음 명령을 사용합니다.
user@host>
show configuration system scriptslanguage python;
실행된 후 commit activate 및 명령 show system commit revision detail 의 show system commit 출력을 확인하려면 다음 명령을 실행합니다.
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
확인으로 디바이스 구성 활성화
현재의 후보 구성을 커밋할 때 커밋이 영구적이 되도록 명시적인 확인이 필요할 수 있습니다. 이는 구성 변경이 올바르게 작동하는지 확인하고 디바이스에 대한 액세스를 차단하지 않는지 확인하는 경우에 유용합니다. 이러한 변경으로 인해 액세스가 차단되거나 다른 오류가 발생하는 경우, 디바이스가 자동으로 이전 구성으로 돌아가고 롤백 확인 시간이 초과된 후 액세스를 복원합니다. 이 기능을 자동 롤백이라고 합니다.
현재 후보 구성을 커밋하지만 커밋이 영구적이 되도록 명시적인 확인이 필요하면 구성 모드 명령을 사용합니다 commit confirmed .
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
변경이 올바르게 작동하는지 확인한 후에는 명령 후 10분 이내에 또는 commit check 명령을 입력 commit 하여 새 구성을 활성 상태로 유지할 수 있습니다.commit confirmed 예를 들어:
[edit]
user@host# commit check
configuration check succeeds
커밋이 특정 시간(기본 10분) 내에서 확인되지 않으면 운영 체제는 자동으로 이전 구성으로 롤백하고 로그인한 모든 사용자에게 브로드캐스트 메시지가 전송됩니다.
명령 이후에 commit confirmed 롤백이 예정된 시점을 표시하려면 명령을 입력합니다. show system commit 예를 들어:
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
명령과 commit 마찬가지로 이 명령은 commit confirmed 구성 구문을 확인하고 오류를 보고합니다. 오류가 없으면 구성이 일시적으로(기본적으로 10분) 활성화되고 디바이스에서 실행되기 시작합니다.
확인
새 구성을 확인해야 하는 시간을 변경하려면 다음 명령을 실행할 때 분 단위로 지정합니다.
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
구성 모드에서도 명령을 사용할 commit confirmed 수 있습니다 [edit private] .
커밋 작업 예약
후보 구성을 활성화하려는 때를 예약할 수 있습니다. 향후 시간이나 재부팅 시 디바이스에서 디바이스 구성 변경 내용을 저장하고 구성을 활성화하려면 구성 모드 명령을 사용하여 commit at [edit] 계층 수준에서 향후 시간을 지정합니다reboot.
[edit]
user@host # commit at string
string 구성 변경 내용을 활성화할 시간이거나 향후 시간입니다 reboot . 두 형식으로 시간을 지정할 수 있습니다.
[
ss:] 형식hh:mm의 시간 값(시, 분, 그리고 선택 가능한 초)-지정한 시간에 구성을 커밋합니다. 미래이지만 구성 모드 명령을 내린 당일commit at의 11:59:59 PM 이전이어야 합니다. 값에hh24시간 시간을 사용합니다. 예를 들어 4:30:00 AM이고20:008:00 PM04:30:00입니다. 시간은 라우터의 클럭 및 시간대 설정에 대해 해석됩니다.[
ss:] 형식yyyy-mm-dd hh:mm의 날짜 및 시간 값(년, 월, 일, 시, 분 및 선택 가능한 초)-지정된 날짜와 시간에 구성을 커밋합니다. 이 날짜는 명령이 내려진 이후commit at여야 합니다. 값에 24시간 시간을 사용합니다.hh예를 들어2018-08-2112:30:002018년 8월 21일 오후 12시 30분입니다. 시간은 라우터의 클럭 및 시간대 설정에 대해 해석됩니다.
따옴표(" ")로 값을 묶 string 습니다. 예를 들면 . commit at "18:00:00" 날짜와 시간은 동일한 따옴표 집합에 두 값을 포함합니다. 예를 들어 commit at "2018-03-10 14:00:00".
구성 모드 명령을 내리면 커밋 검사가 commit at 즉시 수행됩니다. 검사 결과가 성공적이면, 현재 사용자는 구성 모드에서 로그아웃되고 구성 데이터는 읽기 전용 상태가 됩니다. 예정된 커밋이 완료될 때까지 다른 커밋은 수행되지 않습니다.
구성 변경이 활성화되기 전에 디바이스 소프트웨어가 실패하면 모든 구성 변경 사항을 잃게 됩니다.
명령을 내린 request system reboot 후에는 구성 명령을 입력commit at 할 수 없습니다.
미래의 특정 시간에 커밋 작업을 예약하면 명령을 입력 request system reboot 할 수 없습니다.
예약된 커밋이 보류 중일 때는 구성을 커밋할 수 없습니다. 명령을 통해 clear 예약된 구성을 취소하는 방법에 대한 자세한 내용은 CLI 탐색기를 참조하십시오.
디바이스에서 그레이스풀 라우팅 엔진 전환이 활성화된 경우 백업 라우팅 엔진에서 커밋 작업을 수행하지 않는 것이 좋습니다.
커밋 프로세스 모니터링
디바이스 구성 커밋 프로세스를 모니터링하려면, 다음과 같은 명령의 파이프 뒤에 display detail 명령을 사용하십시오:commit
user@host# commit | display detail
예를 들어:
[edit]
user@host# commit | display detail2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
커밋된 구성을 설명하는 코멘트를 추가합니다
커밋된 구성에 대한 변경 사항을 설명하는 코멘트를 포함할 수 있습니다. 이렇게 하려면 문을 포함합니다. commit comment 코멘트는 최대 512자까지 입력할 수 있으며 한 줄에 입력해야 합니다.
[edit]
user@host# commit comment comment-string
comment-string 는 주석의 텍스트입니다.
명령에는 코멘트를 포함할 수 없습니다.commit check
명령에 commit 코멘트를 추가하려면, 명령 뒤에 문을 포함합니다:comment commit
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
명령에 commit confirmed 코멘트를 추가하려면, 명령 뒤에 문을 포함합니다:comment commit confirmed
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
이러한 커밋 코멘트를 보려면 운영 모드 명령을 실행 show system commit 합니다.
구성 모드에서도 명령을 사용할 commit confirmed 수 있습니다 [edit private] .
Junos OS 릴리스 24.2R1부터 Junos OS는 각 커밋 요청에 대한 코멘트를 제공하도록 강제합니다. 이는 커밋 시 여러 사용자 또는 관리자가 변경한 내용을 추적하는 데 도움이 됩니다.
commit 인수가 없으면 명령이 실행되지 않습니다.comment
사용자가 각 커밋 요청에 대한 코멘트를 추가하도록 하려면 계층 수준에서 [edit system commit] 옵션을 구성 force-commit-log 합니다.
일괄 커밋 개요
일괄 커밋은 서로 다른 CLI 세션 또는 사용자의 여러 구성 편집을 어그리게이션 또는 병합하여 일괄 커밋 대기열에 추가합니다. 디바이스에서 실행되는 일괄 커밋 서버는 일괄 커밋 대기열에서 하나 이상의 작업을 가져와 공유 구성 데이터베이스에 구성 변경 사항을 적용한 다음 단일 커밋 작업에서 구성 변경 사항을 커밋합니다.
일괄 작업은 사용자가 지정한 일괄 처리의 우선 순위 또는 일괄 작업이 추가되는 시간을 기반으로 커밋 서버가 우선 순위를 지정합니다. 하나의 일괄 커밋이 완료되면 다음 구성 변경 사항 세트가 어그리게이션되어 일괄 커밋 작업의 다음 세션을 위한 일괄 작업 대기열에 로드됩니다. 일괄 작업은 대기열 디렉터리에 남은 커밋 항목이 없을 때까지 생성됩니다.
모든 커밋이 독립적으로 순차적으로 커밋되는 일반 커밋 작업과 비교할 때 일괄 커밋은 단일 커밋 작업으로 여러 개의 작은 구성 편집을 커밋하여 시간과 시스템 리소스를 절약합니다.
일괄 커밋은 구성 모드에서 수행됩니다[edit batch]. 커밋 서버 속성은 계층 수준에서 구성할 수 있습니다.[edit system commit server]
집계 및 오류 처리
어그리게이션된 작업 중 하나에서 로드 시간 오류가 발생할 경우, 오류가 발생한 커밋 작업은 폐기되고 나머지 작업은 어그리게이션 및 커밋됩니다.
예를 들어, 다섯 개의 커밋 작업( , , , , 및 commit-5)이 어그리게이션 commit-3 되고 로드하는 중에 오류가 발생하면 폐 commit-3 commit-1기되고 , , commit-4commit-2, , 집 commit-5 계 및 커밋됩니다. commit-4commit-3commit-2commit-1
두 개 이상의 작업이 어그리게이션 및 커밋될 때 커밋 작업 도중 오류가 발생하면 어그리게이션은 폐기되고 각 작업은 일반 커밋 작업처럼 개별적으로 커밋됩니다.
예를 들어, 어그리게이션된 커밋 작업(commit-1 , commit-2, commit-3commit-4commit-5)이 다섯 개 있고 로 인해 commit-3커밋 오류가 발생한 경우, 어그리게이션은 폐기되고, , commit-4commit-3commit-2개 commit-5 별적으로 커밋되고, commit-1CLI는 에 대한 커밋 오류를 보고합니다.commit-3
예: 일괄 커밋 서버 속성 구성
이 예에서는 일괄 커밋 서버 속성을 구성하여 일괄 커밋 작업을 관리하는 방법을 보여줍니다.
개요
계층 수준에서 [edit system commit server] 서버 속성을 구성하여 커밋 서버에서 일괄 커밋 대기열을 처리하는 방법을 제어할 수 있습니다. 이를 통해 단일 일괄 커밋에 어그리게이션 또는 병합할 커밋 작업의 수, 대기열에 추가할 수 있는 최대 작업 수, 일괄 커밋 오류 로그를 보관하는 일 수, 두 일괄 커밋 간의 간격, 일괄 커밋 작업에 대한 추적 작업을 제어할 수 있습니다.
구성
CLI 빠른 구성
예의 이 섹션을 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일에 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성과 일치시키는 데 필요한 세부 사항을 변경한 다음, 계층 수준에서 [edit] 명령을 복사하여 CLI에 붙여넣습니다. 커 [edit] 밋 서버 속성을 구성할 수 있습니다. 일반 모드 또는 모드에서 커밋 서버 속성을 구성할 수 있습니다.[edit batch]
디바이스 R0
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
커밋 서버 속성 구성
단계별 절차
-
(선택 사항) 단일 커밋 작업에서 어그리게이션 또는 병합할 커밋 트랜잭션 수를 구성합니다.
의
maximum-aggregate-pool기본값은5입니다.참고:각 작업을 개별적으로 커밋하도록 설정합니다
maximum-aggregate-pool1.이 예제에서 커밋 트랜잭션 수는 커밋 작업이 시작되기 전에 네 개의 서로 다른 커밋 작업이 단일 커밋으로 어그리게이션됨을 나타내는 것으로
4설정됩니다.[edit system commit server]user@R0#set maximum-aggregate-pool 4 -
(선택 사항) 일괄 작업에서 허용되는 최대 작업 수를 구성합니다.
이렇게 하면 대기열에 추가되는 커밋 작업의 수를 제한할 수 있습니다.
[edit system commit server]user@R0#set maximum-entries 500참고:로
1설정maximum-entries하면 커밋 서버는 큐에 두 개 이상의 작업을 추가할 수 없으며 둘 이상의 작업을 커밋하려고 할 때 CLI가 적절한 메시지를 표시합니다. -
(선택 사항) 다음 일괄 커밋 작업을 시작하기 전에 대기할 시간(초)을 구성합니다.
[edit system commit server]user@R0#set commit-interval 5 -
(선택 사항) 오류 로그를 보관하는 일수를 구성합니다.
기본값은 일입니다
30.[edit system commit server]user@R0#set days-to-keep-error-logs 30 -
(선택 사항) 일괄 커밋 이벤트를 기록하는 추적 작업을 구성합니다.
이 예에서 일괄 커밋 이벤트를 기록하기 위한 파일 이름은
commitd_nov이며, 모든 traceoption 플래그가 설정됩니다.[edit system commit server]user@R0#set traceoptions commitd_novuser@R0#set traceoptions flag all
결과
구성 모드에서 명령을 입력하여 구성을 확인합니다. show system commit server 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
일괄 구성 모드에서 구성 커밋
단계별 절차
모드에서 구성을 [edit batch] 커밋하려면 다음 중 하나를 수행합니다.
-
디바이스에 로그인하고 을 입력합니다
commit.[edit batch]user@R0#commitAdded to commit queue request-id: 1000 -
일괄 커밋 작업에 더 높은 우선 순위를 지정하려면 옵션과 함께 명령을 실행
commit합니다.priority[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
구성 변경 사항을 대기열의 다른 커밋 작업과 어그리게이션하지 않고 구성을 커밋하려면 옵션과 함께 명령을 실행
commit합니다atomic.[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
구성 변경 사항을 대기열의 다른 커밋 작업과 어그리게이션하지 않고 커밋 작업에 더 높은 우선 순위를 지정하여 구성을 커밋하려면 옵션과 함께 명령을 실행
commit합니다.atomic priority[edit batch]user@R0#commit atomic priorityAdded to commit queue request-id: 1003
검증
구성이 제대로 작동하고 있는지 확인합니다.
일괄 커밋 서버 상태 확인하기
목적
일괄 커밋 서버의 상태를 확인합니다.
작업
user@R0> show system commit server
Commit server status : Not running
기본적으로 커밋 서버의 상태는 Not running입니다. 커밋 서버는 일괄 커밋 작업이 대기열에 추가될 때만 실행되기 시작합니다.
일괄 커밋 작업이 대기열에 추가되면 커밋 서버의 상태가 로 변경됩니다.Running
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
의미
필드에는 Jobs in process 처리 중인 작업의 커밋 ID가 나열됩니다.
일괄 커밋 상태 확인하기
목적
커밋 서버 대기열에서 일괄 커밋의 상태를 확인합니다.
작업
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
의미
Pending commits 커밋 대기열에 추가되었지만 아직 커밋되지 않은 커밋 작업을 표시합니다. Completed commits 성공한 커밋 작업의 목록을 표시합니다. Error commits 오류로 인해 실패한 커밋입니다.
일괄 커밋 작업의 패치 파일 보기
목적
각 커밋 작업의 타임스탬프, 패치 파일 및 상태를 확인합니다. 패치 파일은 일괄 커밋 대기열에 추가되는 각 커밋 작업에서 발생하는 구성 변경 사항을 보여줍니다.
작업
-
이 명령을 사용하여
show system commit server queue patch모든 커밋 작업에 대한 패치를 확인합니다.user@R0>
show system commit server queue patchPending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }출력은 각 커밋 작업 ID에 대한 구성의 변경 사항을 보여줍니다.
-
특정 커밋 작업 ID에 대한 패치를 보려면 명령을 실행합니다.
show system commit server queue patch id <id-number>user@R0>
show system commit server queue patch id 1000Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
의미
출력에는 커밋 작업에 대해 생성된 패치가 표시됩니다. 또는 - 기호는 + 특정 커밋 작업에 대한 구성의 변경 사항을 나타냅니다.
일괄 커밋 작업에 대한 추적 파일 보기
목적
일괄 커밋 작업에 대한 추적 파일을 확인합니다. 문제 해결을 위해 추적 파일을 사용할 수 있습니다.
작업
-
이 명령을 사용하여
file show /var/log/<filename>로그 파일의 모든 항목을 봅니다.user@R0>
file show/var/log/commitd_nov출력에는 커밋 서버 이벤트 로그와 일괄 커밋에 대한 기타 로그가 표시됩니다.
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
성공한 일괄 커밋 작업에 대한 로그 항목만 보려면 pipe 옵션을 포함하는 명령을 실행
file show /var/log/<filename>합니다| match committed.출력에는 성공한 커밋 작업에 대한 일괄 커밋 작업 ID가 표시됩니다.
user@R0>
file show/var/log/commitd_nov | match committedNov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
실패한 일괄 커밋 작업에 대한 로그 항목만 보려면 pipe 옵션을 포함하는 명령을 실행
file show /var/log/<filename>합니다| match “Error while”.출력에는 실패한 커밋 작업에 대한 커밋 작업 ID가 표시됩니다.
user@R0>
file show/var/log/commitd_nov | match “Error while”Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
커밋 서버 이벤트에 대한 로그 항목만 보려면 pipe 옵션과 함께 명령을 실행
file show /var/log/<filename>합니다| match “commit server”.출력에는 커밋 서버 이벤트 로그가 표시됩니다.
user@R0>
file show/var/log/commitd_nov | match “commit server”Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
대체 부트 드라이브에서 커밋된 구성 백업
구성을 커밋하고 성공적으로 실행되는 것에 만족하면, 명령을 내려 request system snapshot 파일 시스템에 새 소프트웨어를 /altconfig 백업해야 합니다. 명령을 내리 request system snapshot 지 않으면, 대체 부트 드라이브의 구성이 기본 부트 드라이브의 구성과 동기화되지 않습니다.
이 명령은 request system snapshot 루트 파일 시스템을 /altroot에 백업하고 /config 에 백업합니다. /altconfig 루트 및 /config 파일 시스템은 라우터의 플래시 드라이브에 있으며, /altroot 파일 /altconfig 시스템은 라우터의 하드 디스크(사용 가능한 경우)에 있습니다.
명령을 내린 request system snapshot 후에는 소프트웨어의 실행 및 백업 사본이 동일하므로 소프트웨어의 이전 버전으로 돌아갈 수 없습니다.