firmware
펌웨어는 하드웨어와 소프트웨어를 합친 개념을 말한다.
예를 들어서 프린터는 프린터라는 하드웨어 장치와 이 프린터를 운영체제가 인식해서 작동시키는 소프트웨어 드라이버로 구성되어야 정상적으로 역할을 수행한다. 프인터의 소프트웨어(드라이버) 업데이트를 펌웨어 업데이트라고 표시하기도 한다. 하지만 아래 한글은 순수 소프트웨어이므로 펌웨어라고 할 수 없고 소프트웨어 업데이트라고 한다.
<= BIOS(Basic Input Output System) 칩이 전형적인 펌웨어이다.
BIOS (chip)은 내부적으로 소프트웨어가 hard coded 되어 있는 물리적인 장치이다.
하드코어는 EEEPROM(Electronic Electric Erasable Programmable ROM)라는 도구로 해줄 수 있다.
소프트웨어 컴파일
앞에서 커널 컴파일을 해보았는데 이번에는 소프트웨어 컴파일을 해보자. RedHat 계열에서는 프로그램을 설치할 때 RPM 소스코드를 다운받아서 사용하거나, YUM으로 소프트웨어 종속성 문제를 해결하면서 손쉽게 프로그램을 설치할 수도 있지만, 소스코드를 컴파일해서 정밀한 설정이나 특화된 설치를 할 수도 있다.
보통 소프트웨어 컴파일은 ./configure --options(설치환경 지정) ->make(기계어로 변환) ->make install(시스템에 설치) 과정으로 이뤄지는데 ./configure 과정에서 해당 소프트웨어와 종속되는 패키지를 함께 설치하거나 다른 패키지와 연계해서 설치할 때, 특정 경로를 지정해서 설치할 때-예를 들어 Ngin-X 웹 서버를 pcre, zlib, 그리고 openssl 등 종속 소프트웨어와 함께 설치하거나, 혹은 Apache 웹 서버를 PHP, MySQL과 연계해서 설치할 때 등에서 사용되는데 ./configure --옵션으로 환경을 지정해준다.
=>하지만 소스코드 컴파일은 나중에 업데이트나 패치 적용 시 디폴트 환경이 변경되어져 있기 때문에 일일이 설치된 곳을 찾아서 특성에 맞게 고치는 재작업 해주어야 하는 불편함이 있어서 최근에는 별로 권하지 않기도 한다.
패키지 컴파일하기
컴파일(Compile)과 인터프리터(Interpreter)를 간단히 말하자면 공통적으로 사람이 작성한 프로그램을 컴퓨터가 이해해서 실행되게 하는 처리과정을 말하는데, 고급언어인 Cobol, C나 C++, JAVA, Fortran 같이 사람이 작성한 (프로그래밍) 언어를 컴퓨터가 이해할 수 있는 기계어로 전환시키는 것을 컴파일이라고 하고, 고급언어가 아닌 (Visual) Basic이나 Scratch, Python, R과 같이 사람이 작성한 (프로그래밍) 언어를 컴퓨터가 이해할 수 있는 언어로 번역하는 것을 통역의 의미로 인터프리터라고 한다.
소스코드를 다운받고 컴파일해서 사용할 때 보통 소프트웨어 컴파일 설치는 다음의 5 단계를 따른다.
① 먼저 yum -y groupinstall "Development Tools" OR yum -y install gcc-c++ 해서 필요한 패키지를 설치하고,
② 다음처럼 작업 해보자.
a. cd Downloads 한 다음, Googling 하거나
wget http://www.dest-unreach.org/socat/download/Archive/socat-1.4.2.0.tar.gz식으로 해서 소스파일을 다운받는다.
b. ls 해서 다운받은 파일을 확인하고,
c. tar xvfz socat[Tab] 해서 압축을 풀고,
d. ls 해서 풀린 것을 확인한다.
③ 파일의 내용을 보는데
a. cd socat[Tab] && ls 해서 README 파일을 확인한다. 여기에 configure 파일 등이 있으면 대부분 컴파일해서 해당 소프트웨어를 설치해야 한다.
b. cat README 해서 README 파일을 읽어본다. 어느 프로그램이든지 거의 README 파일이 있는데 이 파일에는 해당 소프트웨어의 설치, 사용법, 버그 등에 관한 정보를 자세히 보이므로 먼저 읽어보는 습관을 기르는 것이 좋다.
프로그램 설명과 테스트된 운영체제와 설치 법등이 보이는데 중간쯤 보면
Get the tarball and extract it:
gtar xzvf socat.tar.gz
cd socat-1.4
./configure
make depend
make
su
make install # installs socat, filan, and procan in /usr/local/bin식으로 보인다.
보통 디렉터리에는 많은 하위 디렉터리와 파일들이 있는데 디폴트로
초록색은 실행파일이고, 검정색은 일반 파일이고, 파란색은 디렉터리이다.
초록색 abc 실행파일에서 확장자(xyz.py, qwe.pl, xyz.sh, ...)가 없으면
./abc 해서 실행하고, 확장자가 있으면 python xyz.py(OR perl qwe.pl, bash(sh) xyz.sh)식으로 하거나 ./xyz.py(OR ./qwe.pl, ./xyz.sh)식으로 해준다.
./configure에서 옵션을 뒤에 붙일 수 있는데
./configure —disable-ipv6 —enable-ssh —prefix=/usr/local/apache —enable-ssl —enable-mysql —with-ssl=/home/centos/openssl–0.9.8식으로 해주면 되고, 그냥 ./configure 해서 아무 옵션도 주지 않으면 디폴트로 환경을 잡아서 컴파일 한다는 의미이다.
yum -y install httpd 하면 Apache 웹 서버가 디폴트로 설치되어 홈피가 /var/www/html/ index.html로 들어가는데 이 위치를 보안을 위해서도 은밀한 장소나 다른 서버에 두기 위해서는 소스 컴파일로 설치해야 한다.
패치파일 이해하기
패치파일은 이전 버전에서의 문제점이나 개선 등을 목적으로 개발한 파일이다. 예를 들어 현재 Linux-2.6.32 버전을 안정적으로 사용하고 있다면, 전체적으로 Linux-3.0.0으로 업그레이드하지 않고 2.6.32 버전에서 업데이트가 필요한, 예를 들어서 네트워크 부분만 3.0.0 버전에서 빼내어 별도의 파일로 만들어 둔 것을 패치파일이라고 한다. 이 3.0.0 네트워크 패치파일을 2.6.32 버전에 적용시키면 네트워크 부분만 3.0.0으로 업데이트된다.
=>패칭은 부분 업데이트쯤으로 이해하고 있으면 된다.
∎ 업데이트(update)는 일부 정보, 리포지터리 등을 새롭게 갱신하는 것이고
∎ 업그레이드(upgrade)는 완전히 상위 버전으로 올리는 것이며
∎ 패치(patch)는 부분적으로 올리는 것으로 이해하고 있으면 된다.
그리고 패치는 2.6.32에서 단번에 3.0.0으로 패치하는 방식이 아니라 2.6.33으로 먼저 패치하고, 2.6.33에서 2.6.34, ...3.0.0식으로 단계적으로 진행시켜야 한다. 만일 2.6.32에서 단번에 3.0. 0으로 패치하려면 역 패치나 알렌콕스(*.ac) 패치 등의 기법을 사용하거나, 혹은 업데이트할 모든 패치 프로그램들의 압축을 풀어서 /usr/src에 차례로 놔두고 배치(batch)파일 형태의 쉘 스크립트를 작성해서 낮은 버전부터 차례로 적용시킬 수도 있다.
패치파일을 만들 때에는 diff 명령어를 사용하면 된다. diff 명령어로 두 버전에서 차이 나는 내용이나 파일들을 추출해서 패치파일을 만들 수 있다.
패치 파일 생성은 'diff -urN 원본_파일 비교_파일' > ‘패치_파일.patch’ 구문으로 해주면 되고, 패치 적용은 ‘patch 패치_될_파일’ < ‘패치_파일.patch’ 구문으로 해주면 된다.
그리고 패치 레벨을 -p0, -p1, -p2, ...식으로 지정한다.
/home/centos/ABC/abc
==>-p0는 /, -p1은 home, -p2는 centos, -p3는 ABC....
mkdir은 디렉터리를 생성해주는데
mkdir -p 옵션을 사용하면 상위 디렉터리와 하위 디렉터리를 동시에 생성해준다.
mkdir -p /ABC/{123,456} 하면 원래 mkdir /ABC 한 뒤에 mkdir /ABC/123과
mkdir /ABC/456 해줄 것을 한 번에 실행하는 셈이 된다.
mv A B 하면 동일한 디렉터리(위치)에서는 이름 변경이 되는 것이고
mv A /tmp/B 하면 다른 디렉터리(/tmp)로 이동하는 것이다.
=>rename A.txt B.list 하면 txt확장자를 list 확장자로 변경해준다.
X window 시스템
간단히 줄여서 X라고도 부르는 X Window System은 1984년 MIT에서 UNIX나 Linux와 같은 전통적인 텍스트 운영체제에서 그래픽이 실행되도록 그래픽 인터페이스로 개발했는데 X에서 실행되는 응용 프로그램이 키보드나 마우스의 입력을 캡처해서 창(window)에 출력해주는 원리이다.
X Window System에서 X 서버가 사용자 인터페이스를 제공하면 X 클라이언트들이 이 인터페이스를 통해서 X 서버에 접속하게 된다. X 클라이언트들은 X 서버가 로컬 LAN이나 완전히 다른 네트워크, 혹은 다른 운영체제와 아키텍처에 있더라도 X 디스플레이 프로토콜이 네트워크를 통해서 투명(transparent)하게 서버와 클라이언트 사이에 통신을 실행해서 연결된다.
또 X 서버와 X 클라이언트가 연결되기 전에 SSH 터널링으로 클라이언트가 서버로부터 인증을 받게 함으로써 통신을 보호할 수 있다. 서버와 클라이언트 세션이 시작되면 서버는 클라이언트의 키보드나 마우스 입력을 해석해서 창에 띄우므로 클라이언트는 서버 서비스의 그래픽으로 사용할 수 있게 되는 것이다. 세션이 끝나면 서버는 클라이언트의 연결을 끊는다.
X Window System은 서버가 서비스를 제공하기 전에 필요한 기능과 라이브러리들이 로드되어 있어야 제대로 서버 서비스를 실행할 수 있다. 따라서 X 서버가 제공해야할 특정 장치가 있다면 먼저 해당 장치에 대한 올바른 소스코드를 라이브러리 모듈로 컴파일 한 뒤 이진파일로 변환해서 설치해 주어야 클라이언트들이 서버에서 해당 장치를 사용할 수 있게 된다.
또 X 서버에는 X 폰트 서버(xfs)가 있어야 클라이언트들이 서버에 접속했을 때 해당 폰트를 사용할 수 있게 된다. X 폰트서버가 없으면 텍스트를 필요로 하는 특정 위젯(widget)이 X 클라이언트에서 적절히 표시되지 않거나 서버 응응 프로그램이 실행되어도 X 클라이언트 창에는 서비스는 보이지만 텍스트가 보이지 않는 경우가 있게 된다.
X.Org
X.Org는 X11-based X Window System을 위해서 80년대에 고안되어서 현재까지 사용되고 있는 오래된 구조로써 UNIX와 같은 x86 아키텍처 운영체제에서 그래픽이 실행되게 한다. X.Org의 뿌리는 XFree86 4.4 RC2 지만 X.Org가 Wayland라는 새로운 시스템을 만들어서 서서히 리거시한 XFree86 시스템을 대체해 나아가고 있다.
X.Org는 freedesktop.org 커뮤니티의 협업으로 이뤄졌는데 UNIX/Linux 등의 텍스트 운영체제에서 GNOME, XFCE, 그리고 KDE 등 GUI 데스크 탑 환경이 X.Org 아키텍처의 X Desktop 환경과 호환되게 하는 오프소스 프로젝트에서 시작되었다. 리거시한 X Window System이나 X11과 대조적으로 새로운 X.Org는 모듈로 제공되므로 관리자는 새로운 장치를 위해서 소스를 개발하고 컴파일해서 이진파일로 만드는 리빌드 과정 없이 라이브러리 모듈과 하드웨어 드라이버만 다운받아서 시스템에 설치하면 바로 X Window System에서 X.Org를 사용할 수 있다. CentOS는 X.Org 버전 X11R7을 사용하며 설치과정에서 GNOME이나 KDE를 선택하게하고, 설치 후에는 X.Org의 실행파일인 Xorg가 구성파일인 /etc/X11/xorg. conf 파일을 읽어서 GUI 환경인 런레벨 5에서 실행되게 한다.
정리하면 X window system, X.Org(=X), X11, Xfree86 등은 runlevel 3에 그래픽을 입히는 도구이다. Linux 콘솔에서 X가 들어가면 Graphic으로 변환된다. BackTrack에서도 startx 해서 그래픽으로 간다. 이 X는 현재 Linux에서 GNOME(RedHat 계열)과 KDE(Debian 계열)라는 데스크탑 그래픽을 위한 용도로 개발되었고, 이전에는 고전 게임 등에서 그래픽을 보일 때 사용되었다. 간단히 말해서 X는 원격에서 그래픽으로 접속하게 해주는 도구이다.
Windows 계열은
Windows 98, Windows NT, Windows ME, Windows XP, Windows 7, Windows 10, Windows 11, ....식으로 클라이언트 계열과
Windows NT 4.0, Windows 2000, Windows 2003, Windows 2008, Windows 2016, ....식으로 서버 계열로 구분되어 있다.
Linux 계열은
서버와 클라이언트 버전의 차이가 없다. Linux에 서버 프로그램을 설치하고 서비스를 게시하면 서버가 되고, 그냥 사용하면 클라이언트가 된다. 따라서 GNOME/KDE Desktop에는 클라이언트 사용자를 위한 GUI 프로그램들이 많이 들어 있다. 당연히 서버에서는 이들을 사용할 필요가 없다.
XDMCP(X Display Manager Control Protocol)
X Display Manager(XDM)가 X 클라이언트와 X 서버 연결에서 세션을 시작하거나 끝내는 역할을 한다는 것을 알아보았다. CentOS를 GNOME 환경에서 사용한다면 데스크 탑에 들어가기 위해서 로그인 창을 사용하는데 이 창이 오리지널 XDM을 대체한 GDM(GNOME Display Manager)인데 X 세션에 필요한 요소들을 시작시키는 대신 GDM이 X 세션에 필요한 요소들을 GNOME 데스크 탑 요소들로 프레임시킨다. Windows에서 원격 데스크 탑 연결과 같은 기법이라고 알고 있어도 된다.
￭ gdm은 GNOME의 그래픽 데스크 탑을 말하고
￭ xdm은 전통적인 Xorg에 의한 X11 그래픽 연결방식을 말하는데 로그온 창을 담당한다. 원 격에서 로그온하려면 이 프로그램이 있어야 한다.
GDM은 또한 XDMCP(X Display Manager Control Protocol)를 사용해서 이미 X 서버가 실행되고 있는 세션 안에 또 다른 세션을 시작시킬 수 있다. XDMCP를 사용하면 원격 서버의 GNOME 세션을 자신의 컴퓨터에 끌어다 놓은 것처럼 자신의 컴퓨터에서 작업하면 원격 서버의 데스크 탑에서 작업하는 것이 된다.
Linux