본문 바로가기
IT Security/LINUX Basic

43. Linux rpm 파일 만들기2 - spec 파일 macros 및 rpm 관리

by Rosmary 2023. 8. 14.
728x90
반응형

 

 

지난 포스팅에서 spec 파일 및 테스트용 shell 파일을 사용하여 간단하게 rpm 패키지를 만들고 동작시켜보았다. 그리고 지난 포스팅의 마지막에서, rpmbuild 폴더를 여러 rpm이 공유해야한다는 문제점과, spec 폴더의 경로 관리의 어려움에 대해 간략하게나마 언급을 했었다. 

 

이번 포스팅에서는 지난 포스팅에서 언급한 문제점을 피해 효율적으로 rpm 패키지를 관리할 수 있는 방법을 알아보려한다.

 

 

1. rpm마다 별도의 폴더로 관리하기 (rpmbuild 명령어 --define 옵션 사용하기)

 

지난 포스팅에서 만든 rpm 관련 파일과 폴더를 싸그리 지우고, 새로 rpm 패키지 2개를 신규로 생성해보려 한다. 하나는 일반 shell로 의미없는 문구 몇 줄을 출력하는 rpm, 다른 하나는 python 실행 파일로 특정 설정 파일의 내용을 읽어 실행 인자의 두 인수에 대한 계산을 진행하는 rpm을 추가해보려한다. 

 

[ RPM1 ]

-  mybash.sh : 단순 echo 출력 스크립트.  rpm 설치 시, /usr/bin/에 저장할 예정

 

[ RPM2 ]

-  calculator  : 설정 파일(/etc/calculator/calc.yaml)의 연산 종류(덧셈, 뺄셈, 곱셈, 나눗셈)를 읽어, 실행 파일 인자의 두 정수에 대한 계산 결과값을 출력하는 실행파일.  rpm 설치 시, /usr/bin에 저장할 예정

-  calc.yaml:  Yaml 설정파일로 연산자 정보를 저장. rpm 설치 시 /etc/calculator/에 저장할 예정.

 

위의 내용대로 먼저 파일을 만들어보자.

 

* mybash.sh

 

* calc.yaml

 

* python - calculator.py

 

참고로 python 파일의 yaml 파일 경로는 이 테스트 이후 /etc/calculator/calc.yaml로 변경하였다. calculator.py 파일은 pyinstaller를 통해 컴파일 된 형태로 변환할 예정이다.

 

 

 

이제 각각의 rpm 패키지 환경 구성을 위해 rpmbuild로 폴더를 두 개 만들 예정이다. 물론 rpmdev-setuptree는 rpmbuild 폴더만 만들기 때문에 하나의 rpmbuild 폴더가 생성되고 나면 바로 이름을 변경해야 한다. 아래와 같이.

 

 

여기까지 완료되었다면 각 소스 파일을 적절한 rpm 폴더로 이동한다. 필자의 경우 calculator와 calc.yaml은 Calculator의 SOURCES 폴더 내로, mybash.sh는 mybash/SOURCES 폴더 내로 이동시킨다. 단, source 파일이 두 개 이상인 Calculator는 소스 파일 두 개를 tar 형태로 묶어 저장한다.

 

 

묶인 tar 파일의 내부 구조는 아래와 같다.

 

 

이제 개별 rpm에 대한 spec 파일을 생성해서 각 RPM 환경 폴더의 SPEC 파일에 넣어주자.

 

 

[ Calculator.spec 파일 내용 ]

 

Calculator.rpm의 경우, tar 파일 내에 압축 후 각 소스 파일이 위치해야하는 폴더를 만들어 그 안에 소스 파일을 위치시켰기 때문에 %install 부분은 단순히 tar 파일 압축 해제 코드만 있으면 된다. 

[ mybash.spec 파일 내용 ]

 

이전의 포스팅에서 다루었던 SPEC 내용과 큰 차이가 없으므로 설명 없이 넘어간다.

 

마지막으로 rpmbuild를 진행해보자. 그런데 이전 포스팅에서 단순히 'rpmbuild -ba ' 명령어로만 rpmbuild를 실행하면 오류가 나는데, 오류의 내용을 보면 필자가 지정한 rpm의 각 폴더가 아니라 홈 폴더의 rpmbuild에서 지속적으로 작업을 진행하려고 시도하는 것을 볼 수 있다.

화면이 작아 잘 보이지 않지만 두 rpm 파일 모두 /root/rpmbuild 폴더에서 작업하려는 시도 때문에 오류가 발생했다.

 

rpmbuild는 spec 파일의 이름만으로는 어떤 폴더를 참조하여 소스 파일을 찾아야 하는지, 혹은 어떤 폴더에서 작업을 진행해야하는지 알지 못한다. 따라서 기본적으로 모든 rpmbuild 명령어는 접속 계정의 홈 폴더에 위치한 rpmbuild에서 작업을 진행하려고 시도한다. 그리고 그 이유는 홈 폴더의 .rpmmacros라는 폴더를 열어보면 확인할 수 있다.

 

 

.rpmmacros는 마치 env 파일에 속성명과 속성값이 포함되듯이, rpmbuild에 필요한 변수명(macro라고 한다)과 값을 저장한다. rpmbuild는 명령어가 실행되는 경우, %_topdir의 경로를 참조하여 작업을 진행하게 된다. 그렇기 때문에 필자가 만든 두 rpm 패키지의 spec 파일이 각각 다른 폴더에 위치하고 있음에도 계속 rpmbuild에서 작업을 진행하면서 오류를 낸 것이다.

 

그럼, 서로 다른 rpm으로 작업할 때마다 .rpmmacros 파일에서 %_topdir 값을 계속 변경시켜줘야 하는 것일까? 다행히도 rpmbuild 명령어는 사용자가 이러한 종류의 불편함을 갖지 않게 --define이라는 옵션을 제공한다. 이 --define이라는 옵션은 rpmbuild에 사용할 macro 값을 변경하거나 추가해야할 필요가 있을 때 사용한다. 지금처럼 서로 다른 rpm에 대한 패키지 생성을 진행하는 경우, 아래의 명령어로 build를 진행하면 이전과 달리 정상적으로 rpm 패키지를 생성하는 것을 확인할 수 있다.

 

#  명령어: rpmbuild -ba --define "_topdir /root/{rpm폴더명}" {spec파일 경로}

두 rpm spec 파일 모두 정상적으로 build에 성공했다.

 

--define 옵션으로 rpm macro 지정 시, macro 이름 앞의 %를 제외하고 값과 함께 따옴표 안에 입력해주면 된다.

 

rpm 패키지의 설치와 각 파일의 경로 역시 적절히 잘 배분된 것을 확인할 수 있다.

 

 

2. rpm macro로 SPEC 파일 내 중복값 관리하기

 

필자가 만든 mybash의 SPEC 파일을 보자. 만약 필자가 rpm 패키지에 변경 사항이 생겨 버전을 변경해야한다고 가정해보자. 그러면 단순히 SPEC의 일반 변수인 Version 뿐만 아니라 각 지시자의 명령어에 적용된 경로 역시 수정을 진행해주어야 한다. 

 

 

지금이야 rpm 패키지의 구조가 간단해서 그나마 수동으로 고칠수나 있지, 만약 버전이 명시된 경로가 무수히 많다면 버전 변경때마다 노가다 작업을 하는 것도 고역일 것이다. 다행히 rpm은 SPEC 파일 내에서 특정 일반 변수를 macro로 호출할 수 있도록 지원하고 있다. 

 

필자가 Version 1.0 부분을 제외한 나머지 버전 부분을 아래와 같이 %{version}으로 변경해보았다.

 

 

이 SPEC 파일 역시 rpmbuild로 패키지 생성을 진행하면 아무런 문제 없이 Build가 되는 것을 확인할 수 있다.

 

 

rpm 은 Version 외에도 name, release, distribution 정보 뿐만 아니라 BUILDROOT의 경로 등 rpm build 환경의 각 폴더 정보를 제공하는 macro가 존재한다. 이 macro 정보는 아래의 홈페이지를 참고하도록 하자. 

 

RPM MACRO 종류 및 기능1
RPM MACRO 종류 및 기능2

 

macro를 사용하면 위의 예제에서 필자가 사용했던 shell 파일이나 tar 파일 역시 버전 관리가 가능하다는 장점이 있다. 

 

 

이제 필자는 버전 변경 시 Source 파일의 버전 및 SPEC 내용의 버전만 변경해주면 된다. 참고로 SOURCE0는 SOURCES 폴더의 Source0 파일 경로를 의미한다.

 

 


사실 포스팅을 거의 마무리 할 무렵, 필자가 테스트를 진행하면서 '굳이 rpm 폴더를 나누어서 관리해야 하는가'라는 근본적인 질문에 도달했는데, 어차피 rpm에 들어가는 파일을 tar로 묶어서 관리하면 rpmbuild 폴더 내에서도 여러 rpm이 관리가 가능하기 때문이다... 그런데 이미 글과 자료는 어느정도 완성은 되어버렸으니... 추후 참고할 수 있도록 내용은 지우지 않으려 한다.

 

다음 포스팅은 아마 시간이 많이 지나야 올릴 수 있을 듯 하다. 필자가 예전에 실제 리눅스 PC를 인터넷에 물려 돌리는 동안 해외의 수많은 해커들이 SSH 접속을 시도하는 것을 로그 파일로 확인한 적이 있다. 블로그에 올린 내용은 아니지만, 약 2년 전에 침입자의 IP만 추출하여 iptables에 자동으로 차단시키는 Bash 스크립트를 만들어 구동했던 적이 있다. 이제 서비스 생성도, rpm 패키지 생성도 가능하니 기존의 스크립트를 조금 더 발전시키는 프로젝트를 진행해보려 한다. 

 

 

Fin.

 

반응형

댓글