반응형
목차
- 들어가기
- 주요특징
- RAUC 기초
- RAUC 사용하기
- RAUC 커스텀하기
- 마무리
들어가기
github 페이지(링크)를 보면 기본적으로 임베디드 디바이스를 위한 업데이트 솔루션이다.
RAUC는 다음과 같이 구성된다.
- 임베디드 디바이스 데몬 : 새로운 버전으로 업데이트를 담당하는 데몬
- 호스트 디바이스 툴 : 업데이트 이미지 생성/수정/점검을 위한 툴
RAUC 자체는 GUI나 application을 제공해주지 않는다. 테스팅을 위한 기본적인 CLI를 제공해주지만 결국 특정 플랫폼과 통합하기 위해서는 DBus 인터페이스를 통해야한다. 그리고 잘 정의된 부트로더 인터페이스를 통해서 자체 부트로더와 연동할 수 있도록 지원한다.
호스트에서 툴로써 업데이트 이미지를 생성할 수 있지만 RAUC 자체적으로는 서버를 포함하지 않는다. 다만 외부 솔루션을(링크) 사용해서 hawkBit 서버를 사용할 수는 있다.
주요특징
다음과 같은 주요특징을 가진다.
- File-based와 Block-based 모두 지원한다. 다만 Block-based가 디폴트이다.
- 특정 파티션 레이아웃을 강제하지 않는다. A/B System update 또한 지원한다.
- Rootfs의 제약사항 또한 없다. read-only 일수도, read-write일수도 있다.
- RAUC는 업데이트를 수행하는 core의 역할만 수행한다. 기본적으로 로컬에 저장된 이미지에 대한 업데이트를 수행한다. 즉, OTA를 위한 서버/클라이언트는 별도의 솔루션으로 구현해야 한다.
- delta 업데이트와 Streaming 업데이트를 지원한다.
- 부트로더 (Barebox, U-Boot, GRUB, UEFI)를 통한 fallback을 허용한다.
- OpenSSL 기반으로 업데이트 이미지에 대한 암호화 및 검증을 지원한다.
- IMA, SELinux, dm-verity 같은 verified boot와 호환성을 가지고 있다.
RAUC 기초
Bundles
업데이트 이미지 자체를 가리키는 RAUC의 용어이다. 하나의 Bundle은 아래의 구성요소를 가진다.
참고로 Bundle은 SquashFS 포맷으로 만들어진다. 확장자명은 .raucb
- 파일시스템 이미지 혹은 아카이브 파일
- manifest 파일(manifest.raucm) : 이미지 리스트와 옵션들이 기술된 파일
- 스크립트파일 : 업데이트 전, 도중, 후에 호출됨
RAUC는 bundle을 생성할 때, 이미지의 hash값을 구해서 manifest 파일에 저장해놓는다. 각각의 이미지를 Target에 인스톨할 때, RAUC는 이미 인스톨되어 있는 버전의 hash 값과 비교를 해서 불필요한 업데이트를 skip 한다.
Slots
업데이트가 가능한 단위이다. 하나의 디바이스, 파티션, 불륨 혹은 파일을 의미한다. system configuration 파일에 모든 slot은 기술되어야 한다. 이 파일에는 현재 사용중인 부트로더 혹은 수행할 스크립트 등이 모두 기술되는 중요한 파일이다.
아래 Bundle과 Target의 예를 보자.
첫 번째로 중요한 것은 Bundle의 AppFS와 Target의 AppFS.0 Slot에 맵핑하는 것이다. 참고로 AppFS.0와 RootFS.0는 inactive slot group이다. 이렇게 여러 slot이 묶여있는 것을 slot group이라 한다. active/inactive를 구별하기 위해서 RAUC는 커널 커맨드라인 혹은 mount 정보를 사용한다.
Boot Slot
RAUC는 Barebox, U-Boot, GRUB 을 지원하고 자체 부트로더 지원을 위한 커스텀 인터페이스를 가지고 있다.
mark primary는 inactive/active slot group을 변경하는 인터페이스이다.
mark good/bad는 fallback을 위한 인터페이스이다. 부팅이 실제로 성공했다고 할지라도 해당이미지는 정상적으로 동작하지 않을 수 있다. 이때 해당 부트로더 인터페이스를 통해서 mark bad를 호출하고 fallback 루틴으로 진입한다.
RAUC 사용하기
RAUC는 호스트 사이드의 툴과 타겟 사이드의 데몬으로 구성된다.
이미지 생성하기
$ rauc bundle --cert=<certfile> --key=<keyfile> --keyring=<keyringfile> <input-dir> <output-file>
cert, key, keyring 옵션은 생성되는 이미지를 암호화하기 옵션들이다.
input-dir에는 모든 이미지와 manifest 파일들이 위치하고 output-file 생성될 bundle 파일의 path이다.
bundle 정보확인
$ rauc info [--output-format=<format>] <input-file>
위 명령을 통해서 input-file로 지정된 bundle의 compatible, version, build-id, description 등을 확인할 수 있다. output-format을 통해서 파싱하기 쉬운 json이나 읽기쉬운 포맷을 선택할 수 있다.
$ rauc status [--detailed] [--output-format=<format>]
위 명령을 통해서는 현재 시스템의 인스톨된 bundle의 정보를 확인할 수 있다.
bundle 업데이트
아래 명령을 통해서 실제로 bundle을 업데이트 할 수 있다.
$ rauc install <input-file>
업데이트가 정상적으로 일어나면 아래 명령을 통해서 mark-good을 호출할 수 있다.
$ rauc status mark-good
$ rauc status mark-bad
재밌는것은 수동으로 inactive slot group을 지정할 수 있다는 것이다.
$ rauc status mark-active [booted | other | <SLOT_NAME>]
RAUC 커스텀하기
configuration
이미 정의된 방식으로 RAUC를 커스텀하는 방식이다.
아래는 configuration 파일의 내용이다.
[system]compatible=FooCorp Super BarBazzerbootloader=barebox[keyring]path=/etc/rauc/keyring.pem[handlers]system-info=/usr/lib/rauc/info-provider.shpost-install=/usr/lib/rauc/postinst.sh[slot.rootfs.0]device=/dev/sda0type=ext4bootname=system0[slot.rootfs.1]device=/dev/sda1type=ext4bootname=system1
handlers
인스톨 과정을 변경할 수 있는 방식이다. system configuration 파일에 정의된 rootfs내의 스크립트파일로 보면된다. 위에 configuration 파일에서 handler가 정의된 것을 볼 수 있다.
- system-info : configuration 파일이 로딩되고 호출. 타겟의 시리얼 번호 등을 읽어들이는 역할.
- post-install : 성공적으로 업데이트 되었을 때 호출됨. 일반적으로 reboot 등을 수행.
hooks
handler와 비슷하지만 hooks의 경우는 bundle에 존재한다. 이전 버전의 이미지를 고려하지 않고 업데이트 이미지를 구성하거나 데이터 마이그레이션을 고려할 때 사용한다.
마무리
RAUC는 기본적으로 확장성/융통성이 높은 것 같다. 레퍼런스 보드를 공식적으로 언급하지 않았지만 지원하는 부트로더 등을 보면 굉장히 여러 프로젝트에서 지원되는 것 같다. 다만 서버는 제공해주지 않고 커스텀이 필요한 부분이 많을 있다는 이슈가 있다.
반응형
'소프트웨어 > OTA(on-the-air)' 카테고리의 다른 글
| libostree (OStree) 예제 - 시작하기 (0) | 2019.01.30 |
|---|---|
| Eclipse hawkBit 간략하게 살펴보기 (0) | 2019.01.22 |
| Clear Linux & swupd 살펴보기 (0) | 2019.01.18 |
| SWUpdate (Software Update for Embedded Systems) 살펴보기 (0) | 2019.01.16 |
| Mender (Over-the-air software updates) 솔루션 살펴보기 (0) | 2019.01.16 |
