sungyong
published on 공개 프로젝트는 GitHub를 사내 비공개 프로젝트는 GitLab를 사용중이다. GitHub의 CI/CD는 github action, GitLab은 gitlab-runner 이다. SaaS이다 보니 사용 시간에 따라 과금이 되는데, CI/CD같이 시간 많이 소요되는 작업은 클라우드가 불리하다. 사무실내에 놀고 있는 서버를 gitlab-runner 로 돌리는 것이 경제적이기에 셀프호스팅으로 정했다.
예전에 설정해서 썼었기에 그 기억대로 Runner 를 생성하고 확장 메뉴 버튼을 누르면 되겠거니 했는데, 이 방식은 더 이상 지원하지 않는다고 뜬다.
Group->Runners->Setting button
Yocto에서 Go 프로젝트 관리에 추가하여 JavaScript 기반의 프로그램을 Yocto의 패키지로 관리하는 방법을 정리해 본다.
관련 사항은 Yocto Wiki 의 NPM 기반 패키지 관리 방법에 간략하게 설명되어 있다.
Javascript 기반의 프로젝트도 Go 언어와 마찬가지로 패키지 관련한 문제가 있지만 이 부분은 어느정도 툴을 이용하여 해결된 상태이다.
임베디드 환경에서 Javascript NPM 를 사용하는 경우를 크게 보면 다음 두 경우가 있을 수 있다.
Node.js와 같은 프로젝트는 빌드 시 nodejs-native 도 필요하지만 target에서 동작하는 nodejs도 필요하다.
하지만 webpack과 같은 경우에는 nodejs-native만 있어서 configure, compile task에서 이를 이용하여 페이지를 생성하면 되고, 별도로 target에 nodejs를 설치할 필요가 없다.
Yocto recipe를 작성하다 보면 대부분의 프로젝트가 C, C++ 로 작성된 것들이라 이들은 참조할 것들이 많다. 하지만 Go, Rust, NodeJS 로 작성된 프로젝트는 Yocto에 추가하려다 보면 참고할 자료가 많지는 않은 편이다. 이 글에서는 Go 언어로 작성된 프로젝트를 추가하는 방법을 정리한다.
우선 간단하게 Go 의 모듈 정책에 대해서 정리 해본다.
2009년에 Go 가 처음 나왔을때는 모듈관리는 단순했다.
Go 프로젝트에서 참고하는 모듈은 go get 으로 다운로드하면 $GOPATH/src 디렉토리에 해당 모듈이 설치된다.
하나의 예를 들면 다음과 같이 src 디렉토리에 모듈 경로를 포함해서 설치가 된다.
일반 웹 환경에서는 이제는 사양화 되어 거의 사용하지는 않지만, CCTV 표준인 ONVIF나 관련 보안 인증에서는 아직까지 HTTP Digest Authentication 을 사용한다.
이 글에서는 HTTP Digest Authentication의 전반적인 사항을 정리한다. 목차는 다음과 같다.
HTTP Authentication은 RFC 표준으로 다음과 같이 정의 되어 있다.
웹 초창기에 사용자 인증이 필요한 페이지를 위하여 RFC 2617 로 표준이 정의 되었다. 이 표준안에는 다음과 같은 2가지 인증을 정의한다.
이전글 에서 설명한 Digital Signature 를 사용하면 문서의 서명을 검증할 수 있다. 이 서명을 체이닝으로 이어 나가면 3자 인증 기반의 PKI(Public Key Infrastructure)를 구성할 수 있다. X.509 는 ITU-T 에서 정의한 PKI 표준이다. 우리가 흔히 사용하는 인증서는 X.509 표준을 따른다.
인증의 기본적인 방법은 다음과 같은 절차이다.
YSLeesequenceDiagram
participant Root CA
participant Alias
participant Bob
Root CA-->>Bob: Root CA public key 전달
Alias-->>Root CA: 자신의 정보와 public key를 포함한 문서 전달
Root CA-->>Alias: Root CA private key로 서명하여 전달
Bob->>Alias: Alias 인증서 요청
Alias->>Bob: Alias 인증서 전달
note over Bob: Alias 인증서를 root CA publickey로 검증
Bob->>Alias: 임의의 랜덤한 문자열 전달
Alias->>Bob: 문자열을 Alias private key로 서명하여 전달
note over Bob: Alias public key로 서명 검증
위와 같은 절차가 PKI를 이용하여 서버 검증을 하는 기본적인 방법이다. 사전에 Root CA 인증서만 있으면, 이 Root CA 가 서명한 인증서를 검증할 수 있다. 이와 깉은 인증 체인을 2단계, 3단계 이상으로 체인으로 연결하여 구성할 수도 있다.
이전 글에 이어 PlatformIO를 이용하여 STM32Cube SDK 로 개발환경을 구성하는 것을 정리해 본다.
VSCode에서 아래와 같이 PlatformIO Home을 연다.
New Project 선택하여 다음과 같이 설정
우선 동작이 되는지만 확인키 위하여 다음과 같이 src/main.c 로 main() 함수를 만든다.
Cortex-M series 급을 이용한 임베디드 시스템 개발을 하다 보면, 지속적으로 사용할 수 있는 통합 개발 환경이 마땅치 않다는 문제가 있다. Windows 나 Linux 라면 한번 익혀 두면 수년은 두고 두고 쓸수 있는 개발 환경들이 있지만 임베디드 개발 환경의 경우 MCU 가 바뀔 때마다 개발환경을 바꾸어야만 하는 경우가 생긴다. 개발 환경의 범위를 최소 셋인 컴파일, 다운로드 만이 아닌 디버깅, unit test 까지로 고려한다면 범위가 더 좁아 질 수 밖에 없다.
지금까지는 대부분의 프로젝트는 임베디드 Linux 와 마찬가지로 gcc, binutils, gdb, OpenOCD 을 이용하여 개발하였고, 디버깅을 지원하는 통합 개발 환경으로는 emacs를 사용하였다.
Yocto project에서 기본 설정으로 빌드하면 SysV Init를 사용한다. 개발하는 제품이 이더넷 네트워크로 연결되고, 부팅 이후에는 네트워크 환경이 변하지 않는다면 SysV Init를 이용하는 것이 구조도 단순해서 더 좋을 수 있다.
하지만 다음과 같은 사항을 고려하고 있다면 systemd를 적용하는 것을 검토해 볼 수 있다.
물론 위의 기능을 사용하기 위해서 systemd만 가능한 것은 아니지만, systemd를 사용하는 경우 별도의 프로그램 없이 위 기능을 쉽게 적용할 수 있다.
대부분의 최신 linux 배포본에서 systemd를 적용하면서 로그 시스템도 syslog 에서 systemd 의 journald로 변경되었다.
PC급 이상의 linux 배포본에서는 journald와 기존 호환성을 고려하여 syslog 데몬이 같이 사용하도록 기본 설정되어 있고, 상대적으로 광활한 저장장치과 메모리를 가지고 있고, 적절한 용량 선에서 log rotate가 되도록 설정되어 있어, 사용자가 설치 후 로그에 대해서는 신경을 쓸 필요가 거의 없다.
하지만 용량이 작은 저장장치와 메모리를 가진 embedded linux 제품을 개발하는 경우에는 시스템 로그를 어떤 식으로 관리 할지 충분히 고민하고 설정하여야 한다. 그렇지 않다면 저장장치나 메모리가 로그로 가득차 버려서 더이상 동작을 하지 못하는 문제가 발생할 수 있다. Flash memory를 저장장치로 사용하는 경우에는 제품 수명 보다 저장장치의 수명이 길 수 있도록 erase 횟수도 감안하여 고려하여야 한다.
지금까지 설명한 암호화 알고리즘을 조합하여 확장을 해보기로 한다.
이 글에서 설명할 내용은 다음과 같다.
MAC은 한마디로 정리하면 Hash에 비밀키를 추가한 버전이라고 볼 수 있다.
키를 사용한다는 것으로 보면 DSA 디지털 서명과 비슷한 기능을 수행하지만, 공유키를 사용한다는 것이 다르다.
DSA는 Alice의 공개키를 가진 다수의 사람이 검증을 위한 용도이고, MAC은 키를 공유한 사람 간에 검증을 하기 위한 용도이다. 물론 연산량도 DSA와 비교하여 더 적고 빠르다.