리눅스 환경에서 프로그래밍을 한다면 Makefile의 필요성을 절실하게 느낄겁니다. 

Makefile이 있기에 수 많은 파일을 간단한 명령어 하나로 손쉽게 빌드하는게 가능하기 때문입니다. 

문제는 대규모 프로젝트에서 Makefile을 문법에 맞게 작성하는것이 간단한 일은 손이 많이 가고 귀찮은 일일 겁니다. 

이럴 때 autotool을 사용해 보세요. 

초기 설정과 수정이 용이하고, 누구나 쉽게 변경 할 수 있게 해줍니다. 

프로젝트 폴더로 이동해서 아래의 순서에 따라 명령어를 수행해 보세요. 

$ autoscan 

하위 폴더를 검색해서 configure.scan 파일을 생성해줍니다. 

이 파일을 configure.ac로 이름을 변경해서 사용 하면 됩니다. 

파일명을 변경 한 후 configure.ac 파일을 열어서 대괄호로 묶여 있는 변수에 적절한 값을 채워주세요. 

예를 들면  'AC_INIT'에는 이렇게 되어 있을 겁니다. 

여기에 아래와 같이 현재 프로젝트에 맞게 값을 채워주시면 됩니다.  

$ autoconf 

configure 스크립트를 생성합니다. (동시에 autom4te.cache 파일도 생성해줍니다. )

이 과정을 위해서는 configure.ac 파일이 존재해야 합니다. 

즉, configure.ac 파일에 있는 설정을 참고해서 configure 파일을 생성하는 겁니다. 

$ aclocal

다음 과정인 automake를 하기 위해 필요한 aclocal.m4 파일을 생성해줍니다. 

이 파일에는 automake에서 쓰는 매크로(macros)에 대한 내용이 들어있습니다. 

$ automake 

Makefile을 만드는데 필요한 Makefile.in 파일을 만들어 줍니다. 

automake명령어를 수행하게 되면 Makefile.am 파일을 참고해서 Makefile.in 파일을 생성해줍니다. 

Makefile.am은  프로그래머가 작성해 줘야 하는 파일로, 해당 프로젝트에 해당하는 정보를 기술해 주는 파일입니다. 

결과물로 생성될 실행 파일 이름을 뭐라고 할 지, 하위 디렉터리, 소스 파일, 사용할 라이브러리 정보 등을 써주셔야 합니다. 

위의 예제만 봐도 대충 어떻게 작성해줘야 하는지 감을 잡을 수 있을 겁니다. 

이 파일은 프로젝트의 모든 디렉터리 마다(include 폴더는 제외) 작성해 주어야 하며, 해당 경로에 소스코드가 없다면 'SUBDIRS'만 쓰면 됩니다. 

Makefile.am 파일의 문법에 대해 자세히 알고 싶으시다면 다음 링크를 참고하세요. 

만약, automake 과정에서 아래와 같은 에러가 발생하면.. 

configure.ac 에 아래처럼  'AM_INIT_AUTOMAKE'를 추가해 줘야 합니다. 

$ autoreconf 

automake 과정에서 config.h.in 파일이 없다고 아래와 같은 오류가 나오면 실행해 줍시다. 

그러면 config.h.in 파일이 생성됩니다. 

$ automake --add-missing

automake 에서 아래와 같이  'COPYING' 이 필요한데 없다고 에러가 나면 실행해 줍시다. 

그러면, 'COPYING'와 같은 automake 에 필요한 디렉터리가 자동으로 생성됩니다. 

$ ./configure

autoconf로 생성한 configure를 실행 시킵니다. 

이 스크립트는 automake로 생성한 Makefile.in을 참고해서 Makefile을 만들어줍니다. (중간 과정에서 config.status 파일이 생성됩니다. )

이 과정까지 모두 오류없이 진행 하였다면 Makefile이 생성되어 있어야 합니다. 

$ make

위 과정에서 생성한 Makefile에 따라 빌드를 수행합니다.

$ make install

필요에 따라 빌드한 결과를 설치하면 됩니다. 

결과적으로 직접 만들어 줘야 하는 것은 Makefile.am 파일 하나 밖에 없구요. configure.ac는 조금 수정만 해주면 됩니다. 

과정이 조금 복잡해 보이기는 하지만 한 번 설정 해두면 복잡한 문법의  Makefile  대신 하위 디렉터리, 소스코드 이름 정도만 나열해 주면 되는 Makefile.am파일만 수정하면 되기 때문에 매우 편하게 작업을 할 수 있답니다. 

Django 어플리케이션을 Apache 서버에서 구동 시키기 위해 Debian 패키지를 만드는 방법입니다. 

이 글에서는 바이너리 패키지를 만드는 방법에 대한 설명만 하도록 하겠습니다. 

deb 패키징을 하려는 어플리케이션이  /home/USERNAME/Workspace/myapp 폴더라고 가정하고 진행하겠습니다.  (django 어플리케이션을 패키징 하는 것이므로 settings.py나 manage.py와 같은 파일들이 들어 있을 겁니다. ) 

myapp 이란 django 어플리케이션을 djangoapp이란 이름이로 패키지를 하는 절차입니다. 

작업을 진행하기 앞서 패키징을 진행할 위치에서 필요한 폴더를 만들고 작업하려는 파일들을 복사해 주어야 합니다. 

그 다음 패키징과 관련된 파일들을 넣어줄 'DEBIAN' 폴더도 만들어 줍시다. 

DEBIAN 폴더

이 폴더는 아래 파일들을 포함하고 있어야 합니다. 

• control
• config
• conffiles
• templates
• postinst
• postrm
• preinst
• prerm

각 파일들을 어떻게 작성해야 하는지 차례대로 알아봅시다. 

control 

이 파일은 패키징에 매우 중요한 파일입니다. 패키지에 대한 정보와 디펜던시(dependency)정보 등을 기술해줍니다. 우리는 바이너리(binary)패키지만 할 것이므로 아래와 같이만 기술해주면 됩니다. 

디펜던시(depends)에 이 패키지를 실행하기 위해 필요한 패키지 들을 나열해 주면 됩니다. 

config

패키지를 설치하기 전에 입력받아야 할 값이 있다면 이 파일에서 질문을 지정해주면 됩니다. 예를 들어 이름을 묻고 싶다면 아래와 같이 작성하세요. 

이 파일에는 질문에 대한 내용이 안보이죠? 그 내용은 아래 나오는 'templates'파일에서 기술하면 됩니다. 

templates

질문을 입력받기 위한 내용입니다. 일반적인 경우 입력 받을 일이 없으니 참고만 하세요. 

conffiles 

이 파일에는 패키지를 설치 할 때 일반적으로 '/etc' 하위 폴더에 넣어 줄 설정 파일과 관련된 정보를 기술해 줍니다. 우리는 django(장고) 시작 스크립트(script)와 apache(아파치) 설정 파일에 대한 정보를 입력해 주면 됩니다. 

아파치 설정 파일은 아파치 버전에 따라 다르겠지만,  버전 2.2.22 를 사용중인 저의 경우 'site-available'에 설정 파일을 넣어주고 'enable'시켜주는 방식이라 저 폴더에 넣어줬습니다. 

preinst

파일 이름에서 느낄 수 있는 것 처럼 설지를 진행하기 이전에 수행할 작업을 기술해 주는 파일 입니다. 

혹시나 이미 설치가 되어있어서 동작 중이었다면 동작을 중단 하도록 해줬습니다. 

postinst 

이 파일은 패키지를 압축을 푼 다음에 수행할 작업을 기술해 주는 파일입니다. 

설치시에 입력받았던 이름을 사용해서 무언가를 할 수 도 있습니다. 

그 외에도 필요한 폴더를 생성한다거나 다른 명령을 실행 하도록 지정 하는것도 가능합니다. 

( 'a2ensite'는 아파치의 'sites-available' 폴더에 넣어주었던 파일을 사용하도록 지정해 주는 명령어입니다.)

설치가 성공했다면 서비스를 시작하도록 해줍시다. 

prerm

이 패키지를 제거하는 명령어를 실행 했을 때 설치된 패키지를 제거하기 전에 수행할 작업을 기술해 주는 파일입니다. 

postrm

여기까지가 'debian/DEBIAN'폴더에 넣어주어야 하는 파일들입니다. 

웹 서버(아파치) 설정

위에서 아파치 폴더의 'sites-available' 폴더에 넣어줬던 파일에 대한 설명입니다. 

호스트 이름, 포트 명과 같은 서버 설정 정보와 'root'폴더를 지정해줍니다. 

그 아래 정보들은 django(장고)를 apache(아파치)에서 구동되도록 하기 위한 설정 들입니다. 참고만 하세요. 

Django(장고) init.d 스크립트 

시작 스크립트는 './debian/etc/init.d' 폴더에 넣어주면 됩니다. 

저는 웹 페이지 경로를 '/var/www/' 로 지정해 주었습니다. 이를 위해서 '/usr/share/myapp' 폴더의 링크를 '/var/www/djangoapp/myapp'에 만들어 주어야 합니다. 

위의 'DEBIAN/postinst' 에 예제로 적어놓은것 처럼 'postinst'에 지정해 주셔도 됩니다. 

Debian doc 파일들 

해당 패키지에 대한 문서 파일들을 작성해 주어야 합니다. 

changelog (changelog.Debian) 

changelog는 2개의 파일이 필요하지만 초기 설치이므로 같은 내용으로 작성해줍시다. 

이 파일은 은근 문법을 따집니다. 빈 줄을 제거하지 마시고 잘 넣어보시고 그래도 잘 되지 않는다면 changelog 문서를 참고하세요. 

작성한 파일은 './debian/usr/share/doc/djangoapp/'폴더로 복사한 다음 'gz'파일로 압축해 줍니다. 

copyright

copyright정보를 기술해 주는 파일입니다. 

이 파일도 changelog와 동일하게 복사하고 'gz'파일로 만들어 줍니다. 

debian은 파일의 권한(permission)을 755(-rwxr-xr-x)나 644(-rw-r--r--)로 할 것을 권장합니다. 

파일의 권한을 목적에 맞게 지정해 줍시다. 

준비를 다 했다면 패키지 빌드를 수행해 봅시다. 

dpkg-deb 명령으로 빌드를 수행하고, 그 결과 생성된 파일을 원하는 이름으로 수정 한 다음 lintian명령으로 패키지에 문제가 없는지 검사하는 순서로 진행하시면 됩니다. 

lintian명령 수행 결과 맨 앞에 'W'로 표시된 'Warning'은 수정하는게 좋지만 수정하지 않아도 배포는 가능하고, 'E'로 표시되는 'Error'는 모두 수정하셔야만 됩니다. 

'Error'가 없다면 deb파일을 배포할 준비가 완료 된겁니다. 

참고한 글 

리눅스 장비에서 파일을 압축하거나 푸는 방법은 다양합니다. 

압축 방식별 장/단점과 사용법에 대해 알아봅시다.

1. ZIP

가장 일반적으로 사용되는 압축 확장자입니다.

장점: 거의 모든 OS환경에서 호환이 됩니다. 

단점: 최고 레벨의 압축을 지원하지 않습니다. (tar.gz이나 tar.bz2 보다 압축 레벨이 낮습니다.)

• 압축 하기:

• 압축 풀기:

2. TAR

리눅스(Linux)환경에서 가장 일반적으로 사용됩니다.

장점: 압축에 소비되는 시간, CPU 가 적습니다.

단점: 압축이 거의 되지 않습니다. 주로 여러 파일을 하나의 파일로 묶는 용도로 사용됩니다. 

• 압축 하기:

• 압축 풀기:

• 지정된 위치에 풀기:

3. TAR.GZ

리눅스 환경에서 사용하기 가장 좋은 압축 옵션 중 하나 입니다.

장점: 압축률은 높은 편이지만, CPU는 많이 소비되지 않습니다.

단점: 최고 레벨의 압축을 지원하지 않습니다. 

• 압축 하기:

• 압축 풀기:

• 지정된 위치에 풀기:

4. TAR.BZ2

리눅스 환경에서 사용하기 가장 적합한 압축 옵션 중 하나 입니다.

장점: 최고의 압축률을 자랑합니다.

단점: 시간과 CPU사용률이 적지 않습니다. 

• 압축 하기:

• 압축 풀기:

• 지정된 위치에 풀기:

• 요약 정리 

RPM (Red Hat Package Manager)은 리눅스에 사용되는 가장 일반적인 소프트웨어 패키지 방법입니다. 

Debian에서 사용하는 deb방식도 있지만 일반적으로 rpm으로 패키징 되어 배포되고 있습니다. 

rpm을 만드는 내용은 .spec 파일에 정의해 주면 됩니다. 

spec파일은 vim 에디터로 name.spec 과 같이 임의의 파일을 생성하면 자동으로 기본 탬플릿을 채워줍니다. 

rpmbuild 명령어로 spec파일을 인자로 주어 실행하게 되면 패키징을 수행합니다. 

spec파일에는 수행해야할 명령들이 정의해줘야 합니다. (위에 접혀 있는 'spec 파일 탬플릿 열기'를 펼쳐 보세요.)

spec 파일의 각 파트별 역할에 대해 알아봅시다. 

- Preamble(서문)

● Source

RPM을 만들기 위해 사용할 압축 파일(.tar.gz) 지정 해 줄 수 있습니다. 

Source 뒤에 숫자를 붙여 여러 소스파일을 지정 해 줄 수 있습니다. 숫자는 '0' 부터 시작해야 합니다. 

● Requires

이 rpm이 built(설치)되기 이전에 설치 되어 있어야 할 rpm을 지정해줄 수 있습니다. 

기본적으로 이름만 써도 되지만, 버전을 체크 하도록 할 수 있습니다. 

비교 연산자는 ( <, >, =, >=,  <=) 를 지원합니다. 

만약 64bit 머신에 32bit rpm을 설치해야 할 일이 있는경우 해당 정보를 지정해 주어야 합니다. 

아래 처럼 괄호안에 지정해 주면 됩니다. 

● BuildRequires 

이 rpm을 build 하기 위해 필요한 rpm을 지정해 줄 수 있습니다.  

빌드에 필요한 rpm이므로 주로 devel 패키지가 될 겁니다. 

- Scriptlets 

실제로 수행할 명령을 지정해주는 섹션으로 bash shell 명령어를 지원합니다. 

● %prep 

Source0에서 지정한 파일을 빌드를 하기 위해 필요한 일들을 지정해 줍니다. 압축을 푸는 작업이 주된 작업이 됩니다.  

-q 옵션을 사용하면 압축을 푸는 과정을 보여주지 않습니다. 진행 과정을 감춘다고 생각하면 됩니다. 

-n 옵션으로는 이름을 지정해 줄 수 있습니다. 

● %build

'%prep' 다음에 수행되며, 압축을 푼 소스를 가지고 빌드를 수행합니다. 

주로 './configure'를 실행하여 'Makefile'을 생성하고, 'make'를 수행하여 빌드를 수행합니다. 

● %install

'%build' 다음에 수행되며, 빌드 수행결과 생성된 파일들을 설치 폴더로 복사하는 역할을 수행합니다. 

주로, 'make install'을 수행해서 실행 파일들을 '~/rpmbuild/BUILDROOT' 폴더 아래로 넣는 작업을 수행합니다. 

물론, Makefile에 make install시 수행할 동작에 대해 미리 정의해 주어야 합니다. 

일반적으로 빌드를 통해 생성된 실행 파일을 특정 경로에 넣어주는 작업을 설정해주게 됩니다. 

아래는 'mybin' 이란 파일을 지정한 경로에 설치 하기 위한 Makefile 예제입니다. 

물론, Makefile에는 값에 대한 정의가 되어 있어야 겠죠. 

만약 path를 Makefile에 넘겨줘야 할 상황이 발생하게 되면 아래와 같은 방식으로 지정해 줄 수 있습니다. 

● %check 

'%install' 다음에 수행되며, 설치 이후에 테스트 케이스 검증같은 작업을 위해 사용합니다. TDD기반의 프로젝트라면 이 위치에 테스트를 수행하도록 설정해주면 됩니다. 

● %clean

빌드 마지막에 수행합니다. 빌드 과정에서 생긴 파일들을 지우도록 설정 할 수 있으며, 주로 설치 폴더를 삭제하도록 설정해줍니다. 

spec파일 기본 탬플릿에 있는 내용을 그대로 사용하시면 됩니다. 

● %files 

rpm 파일에 묶여야(패키징) 하는 파일의 이름을 지정해주게 됩니다. 물론, 폴더 이름을 지정 해주는 것도 가능한데, 하위 폴더를 포함 한 모든 파일을 모두 묶는 의미로 사용됩니다. 

여기서 지정한 파일만 rpm 파일에 묶이게 된다고 생각하면 됩니다. 

파일 리스트를 파일로 입력 받는것도 가능합니다. 

패키징 될 파일의 경로(path)정보는 Makefile에서 사용한 값을 사용하게 됩니다. 

다시 말해서.. Makefile에서 install 한 경로 정보와 동일한 값으로 spec 파일에 지정해 주어야 하는 것입니다. 

물론, automake와 같은 툴을 사용한다면 크게 신경쓰지 않아도 되는 부분이기는 하나, Makefile을 직접 만들었다면 절대 경로가 아닌 상대 경로에 설치 하도록 해주어야만 rpmbuild 수행 시 ~/rpmbuild/BUILDROOT/ 아래 설치 하는게 성공 할 수 있습니다. 

파일 리스트 앞에는 Prefix가 붙을 수 있으며, 각각의 의미는 다음과 같습니다. 

◆  [기본] - 아무런 Prefix가 없음 

데이터 파일이라고 생각해서 항상 엎어쓰고 rpm 삭제시에는 제거해줍니다. 혹시 기존에 설치 되었던 파일을 수정했었다 하더라도 신경쓰지 않습니다. 

◆  %config

기존에 설치 된 파일이 수정되었다면 기존 파일을 '.rpmsave' 확장자를 붙여서 백업해놓고 새로운 파일을 설치합니다. 설치 이후에 파일이 수정되었다면 변경된 설정 값을 지우지 않고 백업해 준다는 의미입니다. 

◆  %config(noreplace)

기존에 설치 된 파일이 수정되었다면 기존 파일을 유지하고, 새로 설치될 파일을'.rpmsave' 확장자를 붙여서 설치합니다. 설치 이후에 파일이 수정되었다면 수정된 설정 값을 유지 시키기 위해 사용합니다. 

◆  %attr 

설치된 rpm 권한과 소유권을 지정해 줄 수 있습니다. 

◆  %defattr 

기본 권한 값을 설정 해 줄 수 있습니다. 

◆  %dir

패키지에 포함시킬 폴더를 지정해줘서 생성하도록 합니다. 주로 특정 위치에 빈 폴더를 생성 시키기 위해 사용합니다. 

● %package

서브-패키지를 생성하기 위해 사용합니다. 이름은 당연히 'Name' 필드에 지정해준 이름을 사용하며 여기서 지정해준 이름을 이어서 패키지 이름을 지어주게 됩니다. 

Name은 'foo' 이고 '%package bar' 라고 지정하게 된다면 'foo-bar.rpm' 이란 이름의 rpm 파일이 생성될겁니다. (물론 뒤에 버전 정보 같은것도 들어가겠죠.) 

release 번호는 메인-패키지와 별도로 지정이 가능합니다. 

%if - %else - %endif

빌드 환경을 체크해서 환경에 따라 다르게 동작하게 할 수 있습니다. 

%if 의 종류는... 

아키텍쳐(architecture)를 검사하는 %ifarch 와 %ifnarch가 있습니다.  (i386, alpha, sparc, etc.. )

운영체제(operating system)을 검사하는 %ifos 와 %ifnos가 있습니다.  (linux, etc... )

%else와 %endif는 %if와 짝으로 사용하면 됩니다. 이름만으로 어떻게 동작하시는지 아실겁니다. 

● %post

 rpm 설치 이후에 뭔가 추가 작업을 해줘야 할때 사용합니다. 

예를 들면.. 설정 파일에서 값을 변경하거나.. chkconfig 와 같은 작업 지정이 가능합니다. 

※ 참고로 rpmbuild시 path 정보는 rpmmacros 파일에 정의해주면 됩니다. 

물론, BUILD, RPMS, SOURCES, SPECS, SRPMS 폴더는 미리 만들어 줘야 합니다. 

참고 링크 : 

http://www.rpm.org/max-rpm-snapshot/ch-rpm-specref.html

삼바(Samba)는?

삼바는 윈도우를 설치한 PC에서 리눅스(유닉스) 서버에 있는 파일을 공유할 수 있게 해줍니다. 

즉, 윈도우 사용자가 리눅스 장비의 삼바 서버에 접속한 후, 윈도우용 에디터를 이용하여 파일을 편집 하는게 가능하도록 해준다는 거죠. 

1. 삼바 설치

=============================================================================

 Package                  Arch      Version           Repository        Size

=============================================================================

Installing:

 samba                    x86_64    3.4.9-60.fc12     secui-updates    4.3 M

Installing for dependencies:

 libtalloc                x86_64    2.0.0-0.fc12      secui-mirror      19 k

 samba-common             x86_64    3.4.9-60.fc12     secui-updates     11 M

 samba-winbind-clients    x86_64    3.4.9-60.fc12     secui-updates    934 k

Transaction Summary

=============================================================================

Install       4 Package(s)

Upgrade       0 Package(s)

2. 삼바 설정 

설정 파일을 열어서 설정 가능 

기본적으로 'homes'가 공유되도록 되어 있음. 

삼바를 설치 한 장비에 유저로 등록 되어 있다면 자신의 'home' 디렉터리를 접근 할 수 있도록 해준다는 뜻. 

만약, public을 설정 하고 싶다면 설정 파일 하단에  'public'을 검색해서 주석을 해제하면 됩니다. 

[homes]

        comment = Home Directories

        browseable = no

        writable = yes

3. 삼바 시작 

yum을 통해서 설치 했다면 간단하게 아래 명령어만 실행 해주면 됩니다. 

'OK' 라고 나오면 정상적으로 시작 된겁니다. 

장비가 꺼졌다가 켜졌을 때 자동으로 시작하게 하려면 chkconfig에 등록 해야 합니다. 

우선 현재 상황을 확인합니다. 

아래 명령어를 수행해서 삼바를 등록해줍니다. 

이후 다시 확인하면 정상적으로 등록 되어있겠죠? 

4. 사용자 등록 

이제 삼바 사용자를 등록해주면 됩니다. 

아래 명령어를 실행해주면 됩니다. 

New SMB password:

Retype new SMB password:

Added user kthan.