카테고리 보관물: Tools & Tips

Firewall 바깥의 git을 clone하기

Firewall등이 막고 있어서 외부의 git repository를 HTTPS로는 clone할 수 있지만 SSH로는 막히는 경우가 있다. 특히나 GitHub의 two-factor authentication을 설정한 경우라면 매번 token값을 입력하는 것 때문에 commit을 push하는게 매우 귀찮아진다.

이 문제는 ssh config file에 Proxy command를 설정해서 해결할 수 있는데
${HOME}/.ssh/config에 다음과 같이 추가해 주고, credential caching을 설정해 준다. (-S option에는 SOCKS port를 설정해야 함)

Host GitHub.com
  HostName github.com
  User git
  Port 22
  PorxyCommand connect-proxy -S {proxy-server}:{socks-port} %h %p

Travis CI 설정과 docker image 사용

GitHub project에 CI를 붙이고 싶은데 Jenkins server가 회사 firewall 안에 들어 있어서 GitHub에서 직접 webhook을 붙일 수 없는 문제가 있다. Jenkins의 GitHub plugin으로 tunneling을 설정하는 방법 등 있기는 하지만 다른 CI 옵션들을 살펴 보던중 Open source project에 대해서는 무료라는 Travis CI가 있다는 것을 알게 되었다. Travis CI는 기본으로 Ubuntu를 지원하고 그 외의 경우는 docker를 사용해서 환경을 설정할 수도 있다. 이 포스팅은 Travis CI에서 ClearLinux docker를 사용한 설정에 대한 기록이다.

삽질1: Travis CI의 Ubuntu이용

빌드와 Google test를 이용한 unit test만 할 것이니까 OS를 크게 타지 않을테니 기본으로 제공되는 Ubuntu 환경에 필요한 도구들만 설치 하면 가장 빠르지 않을까?

일견 타당해 보이기는 하지만 문제는 의존성이다. Pre-compile된 Google test를 download 받는다 해도, 2019년 1월 현재 아직 Travis CI에서 제공하는 Ubuntu의 가장 최신 버전은 Xenial이다. CMake version이 안맞아서 최신버전으로 설치하고 Intel LibVA, Intel MediaSDK등의 의존 package들을 컴파일한 후 빌드를 하고 unittest를 하도록 하는데 14분이 넘게 걸렸다. 다음은 사용한 .travis.yml file이다.

language: cpp 

compiler:  - gcc 

dist: xenial 

env:   
  global:    
- EA_INSTALL_PREFIX=${TRAVIS_BUILD_DIR}/local    
- PATH=${EA_INSTALL_PREFIX}/bin:$PATH before_install:  
- mkdir -p ${TRAVIS_BUILD_DIR}/local  
- sudo apt-get install curl wget autoconf libtool libdrm-dev \
libboost-all-dev libgstreamer1.0-0 libasound-dev \
libgles2-mesa-dev gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good gstreamer1.0-plugins-bad \
gstreamer1.0-plugins-ugly gstreamer1.0-libav gstreamer1.0-doc \
gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-alsa \
gstreamer1.0-pulseaudio
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/Kitware/CMake/releases/download/v3.13.2\
/cmake-3.13.2.tar.gz \
&& tar xvf cmake-3.13.2.tar.gz&&cd cmake-3.13.2&&./configure --\
prefix=${EA_INSTALL_PREFIX}&&make&&make install  
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/intel/libva/archive/2.3.0.tar.gz&&\
tar xvf 2.3.0.tar.gz \
&&cd libva-2.3.0&&./autogen.sh&&./configure --\
prefix=${EA_INSTALL_PREFIX}&&make&&make install  
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/Intel-Media-SDK/MediaSDK/archive/\
intel-mediasdk-18.3.1.tar.gz \
&& tar xvf intel-mediasdk-18.3.1.tar.gz&&\
cd MediaSDK-intel-mediasdk-18.3.1/&& \
cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_OPENCL=OFF -DBUILD_SAMPLES=OFF .&&make&&\
make install 

script:  
- cd ${TRAVIS_BUILD_DIR} && \
cmake . && make && make install && test/ea_test

삽질2: Clear Linux docker image 사용 

시간만 오래 안 걸렸어도 기본 Ubuntu OS로 어떻게든 해보는 건데, 14분이면 시간이 너무 오래 걸린다. 이왕 시간이 오래 걸리는 거라면 타겟인 Clear Linux docker image를 사용해보자.

Clear Linux docker image를 생성하기 위한 dockerfile을 다음과 같이 작성해준 다음

FROM clearlinux

RUN clrtrust generate

RUN swupd bundle-add software-defined-cockpit-dev

.travis.yml file을 다음과 같이 선언해 준다.

language: cpp
services:
 - docker
before_install:
 - docker build -t clearlinux_ea .
 - docker run -d -v ${TRAVIS_BUILD_DIR}:/src clearlinux_ea /bin/sh -c "cd /src;cmake .;make;make install"

script:	 	 
 - docker run -d -v ${TRAVIS_BUILD_DIR}:/src clearlinux_ea /bin/sh -c "cd /src;test/ea_test"

총 소요된 시간은 17분 41초 그 중에 docker 설정하는데 걸린 시간만 16분이 넘는다. 나머지 시간에 unit test. 대부분의 시간이 docker를 빌드 하고 설정하는데 사용 되고 있었다. 

삽질3: 만들어 둔 Docker image 다운로드

빌드하는데 시간이 오래 걸린다면 이미 만들어 둔 docker image를 저장소에 넣어두고 pull해서 사용하면 좀 빠르지 않을까? Docker 빌드 vs Docker 다운로드.

이미 빌드 한 docker image를 공개 저장소인 docker hub에 넣어두고 Travis CI에서 pull하도록 변경하면 시간은 8분정도로 줄어든다.

language: cpp

services:
 - docker
	
before_install:
 - docker pull litcoder/clearlinux_ea
 - docker run -v ${TRAVIS_BUILD_DIR}:/src litcoder/clearlinux_ea /bin/sh -c "cd /src;cmake .;make;make install;"
	
script:
 - docker run -v ${TRAVIS_BUILD_DIR}:/src litcoder/clearlinux_ea /bin/sh -c "cd /src;test/ea_test"

흠.. 일단은 이걸로.

 결론

Travis CI에서 제공되는 연산 성능은 매우 떨어져서 컴파일이나 도커 빌드를 효율적으로 수행하지 못한다. 반면, 이미 만들어진 이미지의 다운로드는 상대적으로 빠르게 수행 할 수 있다. Travis CI에서 Docker를 이용한 테스트 환경을 구성하고자 한다면 미리 만들어 둔 이미지를 Docker Hub에 올려두고 CI script에서 pull 해서 사용하는 방법이 가장 고려해 볼 만한 선택이다.

[Tip] Fedora CUI booting 설정

Fedora (Version26, Workstation edition)은 /etc/inittab file로 runlevel을 변경하던 이전의 방식은 지원되지 않는다. /etc/systemd/system/default.target file을 보면 /lib/systemd/systm/graphical.target으로 link되어 있는데 이것을 multi-user.target으로 변경해 주면 CUI console로 진입할 수 있다.

$ sudo ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target 

설정 후 시스템을 리붓하면 CUI로 booting되고 startx 명령으로 GUI를 불러 올 수 있다. Display Manager를 띄우지 않기 때문에 GUI에서 logout하면 CUI로 되돌아온다.

$ startx

[Tip] WinDbg에서 경로가 다른 PDB의 source를 load하기

Windows에서 WinDbg로 디버깅할 때, PDB에 적혀있는 절대경로 때문에 다른 machine에서 빌드한 바이너리(dll/sys/exe)를 디버깅할 때는 소스가 맞지 않아 번거롭다. 이 것을 해결하는 방법으로 source indexing을 사용하라는 글이 있기는 했었는데 내가 뭐 배포정책을 바꿀만큼 힘이 있는 것도 아니고… 아주 약간(!) 지저분 하긴 하지만 Windows의 subst 명령어를 사용해서 PDB에 적힌 경로를 흉내내는 것으로 이 문제를 해결할 수 있었다.

PDB에 있는 절대 주소와 내 로컬 소스의 주소가 각각 다음과 같다고 가정한다.

PDB path - D:\AAA\BBB\CCC\DDD\EEE\FFF\GGG
Local path - C:\ZZZ\YYY\XXX\EEE\FFF\GGG

즉, Local path의 EEE directory에 PDB path EEE가 연결되도록 만들면 된다. D:가 유효하다면 그걸 사용하면 되지만, 이 글에서는 C:만 사용가능한 상태라 가정한다.

먼저 C:에 가짜 디렉토리 ‘AAA\BBB\CCC\DDD’를 만든다. 꼭 C: 밑에 바로 만들지 않더라도 나중에 subst 명령어에서 경로 지정만 잘 해주면 된다. 상황에 따라 admin권한이 필요할 수도 있다.

CMD> mkdir c:\AAA\BBB\CCC\DDD

Local path에 있는 EEE 디렉토리로 link를 만든다.

CMD> mklink /d c:\AAA\BBB\CCC\DDD\EEE c:\ZZZ\XXX\YYY\EEE

마지막으로 subst 명령어를 이용해서 Local에 만든 가짜 directory를 D:로 연결한다. 이때는 admin 권한으로 실행하면 안된다. 일반 권한으로 다음을 수행하자.

CMD> subst d: c:

subst의 두번째 인자는 처음에 만든 가짜 디렉토리에 따라 필요한 경우 디렉토리명을 적어도 된다. 이제 d:로 이동해 보면 PDB와 동일하게 D:\AAA\BBB\CCC\DDD\EEE 경로가 유효한 것을 볼 수 있고, WinDbg에서 source loading도 제대로 동작한다.

해제

subst는 system을 reboot하면 해제된다. 필요한 경우 /d option으로 해제할 수 있다.

CMD> subst /d d:

WordPress permalink(고유주소) 변경

WordPress의 permalink(고유주소) 형식을 변경하면 검색 엔진을 포함해서 외부에서 들어 오는 링크가 동작하지 않는다. 서버에 대한 root권한이 없다면 .htaccess file에, 권한이 있다면 apache2.conf에 새로운 형식의 permalink로 연결되도록 설정해 주는 것으로 이 문제를 해결 할 수 있다.

처음에는 서버를 재시작 할 필요가 없는 .htaccess에 관련 설정을 했었는데,  아파치 튜토리얼: .htaccess 파일 문서에 .htaccess file 설정은 성능에 영향을 미칠 수 있으므로 권한이 있는 경우라면 apache2.conf에 설정하라는 이야기가 있어서 이것을 수정했다.

먼저 Apache2의 rewrite module을 enable한다.

$ sudo a2enmod rewrite

그다음 apache2.conf에 관련 설정을 추가한다.

#
# Rewrite settings.
#
# Articles
#    e.g) ~/archives/1234 -> ~/?p=1234
# Tags/Categories
#    e.g) ~/archives/tag/database -> ~/?tag=database
# Dates
#    e.g) ~/archives/date/2013/02 -> ~/?m=201302
<IfModule mod_rewrite.c>
    RewriteEngine On
    RedirectMatch 301 ^/archives/(\d+)$ http://54.179.110.104/?p=$1
    RedirectMatch 301 ^/archives/(\w+)/(\w+)$ http://54.179.110.104/?$1=$2
    RedirectMatch 301 ^/archives/date/([0-9]{4})/([0-9]{2})$ http://54.179.110.104/?m=$1$2
</IfModule>


이 설정은 이전의 /archives/xxxx 형식의 글이나, /archives/tag/xxxx 형식의 tag, /archives/yyyy/mm 형식의 날짜를 “Ugly”한 기본 형식으로 변경하기 위한 것이다.

마지막으로 Apache2 서버를 재시작해준다.

$ sudo service apache2 restart