아파치 웹서버를 새롭게 다시 설치하지 않고, 기존의 웹서버 데몬에 포트 번호와
그룹권한만을 변경하여 복사한후 설정 파일만으로 또 다른 웹서버를 운영하는 방법이다.

* 전제 조건
- 기존의 웹서버에 8080 포트 기반 가상 호스트를 운영하고 있지 않다.
- 웹서버를 두 개 운영할 만큼 충분한 메모리가 있다.
- 그룹(또는 유저)을 nobody 권한이 아닌 다른 그룹 권한으로 운영하고 싶다.

[과정1] 현재의 아파치 설정 파일을 httpd-8080.conf 파일로 같은 위치에 복사한다
#pwd
/usr/local/apache/conf
# cp httpd.conf httpd-8080.conf
[과정2] httpd-8080.conf 파일을 열어 다음과 같이 포트 번호는 8080으로
그룹은 원하는 그룹으로 지정하고, 필요에 따라 섹션과 MinSpareServers ,MaxSpareServers,
StartServers 수를 80 포트로 운영하는 서버보다 적게 수정한다.

port 8080
user nobody
group san2

[과정3]수정한 설정 파일에 대해서 웹서버를 가동한다. '-f'옵션 다음에
시스템 절대경로나 ServerRoot(예:/usr/local/apache)를 기준으로 수정한
httpd-8080.conf파일을 지정한다.

#pwd
/usr/local/apache/conf
#../bin/httpd -f conf/httpd-8080.conf

[과정4] ps -aux | grep httpd 명령이나 웹브라우저로 직접확인해본다

http://www.domain.com:8080/

가능합니다. 이때는 각각 독립된 웹서버가 있어야 합니다. 네임서버에서는
A레코드로 같은 이름에 대해서 다른 IP주소를 지정하십시요. 각각 지정한 IP주소로
각각 독립된 호스트(서버)에 부여합니다.

예)

/var/dolmuri.db
@ IN SOA dol.dolmuri.pe.kr. root.dolmuri.pe.kr.
2003022400 ; serial
28800 ; refresh
14400 ; retry
300000 ' expire
86400 ; minimum

IN NS dol.dolmuri.pe.kr.
IN A 210.100.203.88
IN NS muri.dolmuri.pe.kr.
IN MX 10 mail.dolmuri.pe.kr.

www IN A 210.100.203.88
www IN A 210.100.203.89
www IN A 210.100.203.90
www IN A 210.100.203.91

#nslookup www.dolmuri.pe.kr
...
Name : www.dolmuri.pe.kr
Addresses : 210.100.203.88, 210.100.203.89, 210.100.203.90, 210.100.203.91
#

기본적으로 cgi-bin 디렉토리는 ScriptAlias 지시자로 지정해줍니다. 즉 이 디렉토리에 있는 모든 파일을
실행하려고 하기때문에 그림 이미지가 깨지게 됩니다. 꼭 cgi-bin 디렉토리에 그림 이미지를 넣고 싶다면
, ScriptAlias 지시자 대신 Alias 지시자로 설정해 주십시요. 대신 ExecCGI 옵션은 들어가 있어야 합니다.

예)

#ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
Alias /cgi-bin/ "/usr/local/apache/cgi-bin/"
또는
Alias /cgi-bin/ "/home/httpd/cgi-bin/"

그리고 cgi-script Handler도 주석을 제거해 주십시오(cgi-bin 디렉토리 외에도 사용가능)

AddHandler cgi-script .cgi
또는
AddHandler cgi-script .cgi .pl

2. 파일 관리


2.1 파일시스템 모두 복사하기 , 장범수(bschang@kldp.org) - 2000.05.16

파일 시스템 전체나 디렉토리 트리 구조를 동일하게 복사하기
위해서는 다음의 명령어를 쓴다.

# mkdir /home/bc/destination
# cd /targetdir
# find . -depth -print | cpio -pmdvl home/bc/destination

이러면 /targetdir의 모든 것이 /home/bc/destination으로 복사된다.


2.2 깨진 타 (tar) 파일 복구 시도 , 장범수(bschang@kldp.org) - 2000.05.16

기껏 다운 로드를 열심히 한 후에 보면 가끔 타 뭉치가 조금
깨져 있는 경우가 있다. 이 때에는 다음의 방법을 써서 복구를
"시도"해 본다.

$ cat [tar-filename] | tar -xvf -장소

장소는 스텐다드 아웃풋.


2.3 특정 사용자 소유의 모든 파일을 찾을때는? , 관리자 - 99.10.7

특정 사용자 소유의 모든 파일을 찾을때는?
find / -user "사용자 ID" -print


2.4 tar와 bzip2 , Kapsoo Jeon - 99.04.27

요즘 GNU tar는 bzip2를 지원합니다.
tar Ixvf package.tar.bz2
이런식으로 I 옵션을 사용하면 됩니다.
debian 2.1과 redhat 5.2에 포함된 tar에서 확인


2.5 짜증나는 tarball , 관리자 - 99.04.15

가끔 다운 받은 파일을 untar하다 보면 해당 디렉토리가 생기지 않고
현재 디렉토리에 모든 파일이 풀려버려 정신없을때가 있는데...
이럴때 rm 'tar ftz stupidpackage-1.0.0.tar.gz' 하면 해당파일만
지워진다.


2.6 파일 크기 0로 만들기 , 관리자 - 99.04.15

파일의 크기를 0으로 만들어야 할때가 있다.
가령 /var/log 속에는 관리해주지 않으면 끝없이 커지는 로그파일들이
들어있다 이럴때는
cp -f /dev/null /var/log/messages
또는 > /var/log/messages


2.7 gzip대신 bzip2쓰기 , 관리자 - 99.04.14
gzip대신 bzip2를 tar와 같이 쓰고 싶을땐? 다음과 같은 스크립트나 alias를 만든다.


----------------------------------------------------

$ cat tarx-bzip2
#!/bin/sh
tar --use-compress-program bunzip2 -xvp -f $1

$ cat tarc-bzip2
#!/bin/sh
tar --use-compress-program bzip2 -cvf $1.tar.bz2 $2


----------------------------------------------------

core라는 파일은 실행되던 프로그램이 비정상적으로 종료되었을때 생기는
파일 입니다.
종료되기 직전에 커널은 실행되는 프로세스의 메모리 이미지 자체를 파일에
쓰고 종료하게 되는 거죠.

결국 core는 본질적으로 프로세스가 죽기직전의 메모리의 모습이죠.
그래서 디버깅(gdb같은 프로그램을 통해서) 할때 사용할수 있게 되는 겁니다.

실행되는 프로그램이 비정상적으로 종료되는 경우라면 커널은 종료되기 직전
에 core dump를 하게되죠 그게 바로 메모리 이미지를 파일에 쓰는 작업이
됩니다.

간혹 core파일의 크기가 커져서 디스크 스페이스를 크게 차지하는 경우가
있어서 체크후 삭제 하셔도 무방합니다.

시각의 설정

리눅스에서는 1초간에 수백회 카운터를 갱신한다. 1970년 1 월 1 일 이후 경과한 초수를 기록하는 것으로 일짜를 만들어 낸다.

시각을 보기 위한 가장 기본적인 명령어는 date 이다. 쉘 prompt에서 date를 입력하면 리눅스는 다음과 같이 표시한다.

Wed May 5 18:56:36 BST 1999.

리눅스는 카운터를 설정하기 위해 시각을 안다. 다음과 같이 date를 사용해 시각과 일짜를 설정하는 것도 간단하다.

date -s 'Wed May 5 19:00 BST 1999'

통상 사전의 date 명령어로부터 수정 출력을 사용해 시각를 설정하는 것이 편리하다.

Zoned Out

매사추세츠주 캠브리지가 오전 2시 때, 영국의 캠브리지 에서는 오전 7시 이다. 어느 쪽에도 리눅스 시스템이 있는 경우는, 실제로 몇시 인지를 아는데는 문제가 없다. 리눅스는 최근의 운영체제 시스템과 같이, 협정세계시(UTC)로부터 시간을 관리해 결정하는 시스템을 채용하고 있다.

리눅스머신의 시간대를 변경하고 싶다라면 DEBIAN 리눅스 상에 tzconfig를 닮은 프로그램이 있다. 그러나 리눅스 머신을 가지고 온 세상을 이동할 필요가 없을 경우에는 설치때에 한 번 설정하는 것만으로 좋다.

hwclock

커널로부터의 시각을 기록하고 있는 카운터를 리눅스가 실행하고 있지 않은 경우 카운터를 체크하는 프로그램은 작동하지 않는다. 컴퓨터는, 배터리로 가동하는 저출력 시계를 사용해 시각을 보관 유지 한다. 배터리가 부족하거나 문제가 발생했을 때, 리눅스를 부트 했을 때에 이상한 시각이나 일짜가 표시 될 때는 하드웨어 시각을 조정할 필요가 있다. 저자는 통상 처음에 date로 올바른 일짜와 시각을 설정하고 나서, 이하의 명령어를 입력한다.

hwclock

--systohc

이것에 의해, 배터리로 백업된 시각이 리눅스 시각에 돌아온다.

A Time, C time, 및 M Time, 「Touch」파일

리눅스 시스템상의 파일 모두에는 시각이 표시되어 있다. 이렇게 표시해주는 스탬프의 종류에는, 작성시각, 변경시각, 액세스시각의 3종류가 있다. 이러한 스탬프는 「Epoch 이후의 초수」형식으로 내부적으로 보관되지만 프로그래머가 아닌한 걱정할 필요는 없다. 시각 스템프는 모든 조작에 대해서 자동적으로 실시된다. 다만 시계는 고장났지만, 파일에 일시를 표시하고 싶을 때는 touch 명령어를 사용해 스탬프를 자유롭게 변경 할 수 있다.

touch filename

이 명령어는, filename의 시각 스탬프를 현재 시각에 변경한다.

동기화를 통한 시각 설정

시각을 공유 시키고 싶은 복수의 머신이 있을 때, 또 단지 시각을 정확하게 맞추고 싶은 경우에 동기를 하는 방법이 있다.

xntp

xntp는, 모든 최신판 리눅스 패키지에서 사용 가능하다. xntp를 사용해 머신이 네트워크의 컴퓨터에서 시각을 읽어내도록 설정하면 된다.

이것을 하기에는, 파일 /etc/ntp.conf 를 편집해, 다음과 같은 행을 마지막에 추가한다.

server ntp0.ja.net

그 외의 서버행은 제거한다. 「ntp0.ja.net」는 자신의 로컬 xntp 서버이다. xntp 도큐먼트패키지가 작성한 /usr/doc 내의 디렉터리를 참조해, 가까운 xntp 서버를 찾아내는 것.

내부 머신을 타임서버로서 기능하도록 지정하는 것도 할 수 있다. 또, 1대의 컴퓨터로 올바른 시각을 표시하는 것도 가능하다. 여기에 대한 자세한 자료는 도큐먼트 패키지로 자세한 내용이 들어가 있다.


결과 값을 CMOS로 업데이트 하려면 다음과 같이 입력한다.

clock

#tar cpf - 묶을디렉토리절대경로|gzip>sample.tgz
#tar cpf - ./상대경로|gzip>sample.tgz
#gunzip -c sample.tgz|tar xpf -

화면상에 출력되는 내용 중에서 원하는 문장을 따로 뽑아내기 위해 가장 일반적으로 사용하는 명령어가 "grep" 일 것입니다. SE치고 "grep"을 사용해 보지 않은 사람은 아마 없을 정도로 많이 사용되는 명령어지만 "grep"이 갖고 있는 치명적인(?) 단점이라면 바로 해당 라인만 뽑아낸다는 것입니다. 가령,
1111111111111111
2222222222222222
3333333333333333
4444444444444444
3333333333333333
와 같은 내용의 "output" 화일에서 "22222" 라는 문자가 들어간 문장에서 "44444"라는 문자가 들어간 문장까지를 뽑고자 한다면 어떻게 할 수 있을까요?
이 때에서 다음과 같이 "awk" 명령어를 이용하면 간단하게 해결됩니다.

# cat output | awk '/22222/,/44444/'

리눅스 서버에서 가장 빈번히 엑세스 되는 디렉토리는
일반적으로 /usr /home 그로고 swap정도 입니다.
만약 다른 하드디스크에 격리해서 사용한다고 가정한다면
위의 디렉토리를 격리 하는게 좋은 방법일 수 있습니다.

그 외에 웹서버와 DB 서버로 사용하는 경우라면 Document
root가 있는 디렉토리와 DB가 있는 디렉토리를 격리해서
사용하는 것이 좋은 방법입니다..

TAR(Tape ARchive) 아카이브 파일은 1970년대 자기테이프에 백업 & 검색하기
위하여 유래되었다고 합니다만 지금은 주로 여러 개의 파일을 묶어 전송하기
위하여 사용됩니다. 기본적으로 TAR 아카이브는 여러 개의 파일을 전혀
압축하지 않은 상태로 단지 하나의 파일로 묶어주는 역할만을 합니다.
우리가 보통 유닉스에서 제공하는 tar 유틸리티를 이용할 때 z 옵션을 지정하여
주면 압축까지 하는 것을 볼 수 있습니다. 그러나 이는 tar 유틸리티에서
압축해 주는 것이 아니라 tar 유틸리티와는 별개로 작성되어 있는
gzip 유틸리티를 불러다가 압축하게 되지요.

PHP에서의 상황을 보면 zlib 함수(gz로 시작하는 함수들)를 통해 파일을
압축할 수 있습니다. 그러나 zlib 함수는 기본적으로 하나의 파일만 다룰 수
있습니다. 웹상에서 여러 파일을 압축하고 해제하는 것이 다소 위험하여
그런지는 알 수 없으나 웹 스크립트에서는 TAR 아카이브를 잘 다루지 않는 것
같습니다. 생각해 보면 위험하기도 하겠습니다. 무슨 파일이 포함되었는지도
모르는 압축파일을 서버에 올려서 풀어버린다면 그 위험성은 상상하고도
남겠지요. 또한 내가 아닌 누군가가 나의 웹서버의 내용을 통째로 압축하여
가져가 버린다면...... 소름끼치는 상상이 될 수도 있겠지요. 그러나 구더기
무서워 장 못담그겠습니까? 서버상의 여러 개의 파일을 하나로 묶어서
다루어야 할 경우는 너무 많기때문에 TAR 아카이브를 다룰 수 있는 함수는
꼭 있어야 겠지요. 그리고 TAR 아카이브를 다룰 때 발생할 수 있는 여러가지
위험성을 충분히 고려하여 사용하기만 한다면 별(?) 문제 없을 것입니다.

현재 PHP에서 일반적으로 웹상에서 여러개의 파일을 압축하기 위해서는
exec() 또는 system()와 같은 함수와 리눅스에서 제공하는 tar 유틸리티를
이용하게 됩니다. 그러나 이러한 방법은 서버 상황에 따라 때로는 제대로
동작되지 않을 경우도 있으며 또한 윈도우 서버의 경우에는 해결방법이
될 수가 없습니다. 결국 가능한한 서버 환경에 관계없이 웹상에서
TAR 아카이브를 다루기 위해서는 TAR 아카이브를 직접 처리하는 것이
좋을 것 같습니다.

본인도 PHP에서 다중파일 다운로드 클래스를 만들다보니 여러 개의 파일을
다운로드하기 위해서는 결국 여러 개의 파일을 하나의 파일로 묶은 후에
이 파일을 다운로드 받은 것이 가장 좋겠다는 생각은 되었으나 현재 공개된
해결책으로는 위에서 언급한 리눅스의 tar 유틸리티를 이용하는 방법 외에는
눈에 띄는 것이 없었습니다. 그래서 인터넷을 검색하기 시작하였고
이를 통해 C로 작성된 tar 유틸리티의 소스 및 TAR 아카이브 구조에 관한
기술자료를 얻을 수 있었습니다. 이러한 자료를 통해 리눅스의 tar 유틸리티와
같은 기능을 수행하는 TAR 아카이브 클래스를 작성하게 되었으며
이를 공개하려고 준비하는 중에 PHPSCHOOL.COM 친구 여러분들도 꼭 다운로드가
아니더라도 다중 파일 백업과 같은 기능을 웹에서 구현하려고 하는 분들이
많이 있을 것 같아 TAR 아카이브를 직접 다룰 수 있는 기술 자료를 정리하여
올리게 되었습니다. 이 자료만 잘 습득하시면 여러분도 TAR 아카이브를
다루는 함수를 작성하는데 별 어려움이 없을 것으로 보입니다.

그러면 본론으로 들어가서 아래의 내용들에 대하여 하나씩 살펴보겠습니다.


◆ TAR 아카이브 구조
◆ 헤더 구조
◆ 본문 구조
◆ TAR 아카이브 후미에 붙여지는 블록
◆ TAR 아카이브 관련 PHP 소스



1. TAR 아카이브 구조


TAR 아카이브는 512바이트를 1블록으로 하여 다루게 됩니다. 따라서 TAR
아카이브의 크기를 보면 512 * n 바이트임을 알 수 있습니다. TAR 아카이브는
여러 개의 파일이 하나로 묶여있으므로 각 멤버파일마다 본문 내용에 앞서
파일에 대한 정보를 기록하게 되는 1블록의 헤더가 반드시 나타나며 그 뒤를
이어 n블록의 본문 내용이 나타납니다. 때에 따라서는 하나의 디렉토리에 있는
파일뿐만 아니라 다른 디렉토리에 있는 파일들도 하나의 TAR 아카이브에 묶을
때도 있을 것입니다. 이러한 경우에는 디렉토리에 대한 정보도 기록하여야
하는데 이 경우에도 파일 헤더와 같이 1블록의 디렉토리 헤더를 가지게 됩니다.
디렉토리의 경우에는 파일과는 달리 본문 내용이 없으므로 각 디렉토리마다
1블록의 디렉토리 헤더만이 존재합니다. 파일 및 디렉토리에 관한
모든 정보(헤더 및 본문)가 다 기록된 후에는 마지막으로 아스키 0으로 채워진
1블록 이상의 빈블록(empty block)들이 붙여지게 됩니다.

이젠 몇가지 실예를 들어 전체 구조가 어떻게 구성되는지 살펴보겠습니다.


1) 동일한 디렉토리에 있는 파일들(디렉토리 정보를 기록하지 않을 때)


s1.txt
s2.txt
s3.txt


s1.txt, s2.txt, s3.txt 파일이 모두 동일한 디렉토리에 존재하며 이를 묶을
때
디렉토리 정보를 전혀 기록하지 않는다면 TAR 아카이브의 전체 구조는 아래와
같을 것입니다.


+--------------------+
| s1.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s1.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| 빈블록 | n 블록(512*n 바이트)
+--------------------+


2) 동일한 디렉토리에 있는 파일들(디렉토리 정보를 기록할 때)


sub/s1.txt
sub/s2.txt
sub/s3.txt


s1.txt, s2.txt, s3.txt 파일이 모두 동일한 디렉토리 sub에 존재하며 이를
묶을 때 디렉토리 정보 sub를 기록한다면 TAR 아카이브의 전체 구조는 아래와
같을 것입니다.


+--------------------+
| sub 디렉토리 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s1.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s1.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| 빈블록 | n 블록(512*n 바이트)
+--------------------+


3) 여러 개의 디렉토리에 있는 파일들


s1.txt
s2.txt
sub1/s3.txt
sub1/sub2/s4.txt
sub1/sub2/s5.txt
sub1/sub2/sub3/s6.txt
sub4/s7.txt


s1.txt, s2.txt, s3.txt 파일이 여러 개의 디렉토리에 분산되어 존재하며 이를
묶을 때 이들 디렉토리 정보를 함께 기록한다면 TAR 아카이브의 전체 구조는
아래와 같을 것입니다.


+--------------------+
| s1.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s1.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s2.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| sub1 디렉토리 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s3.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| sub2 디렉토리 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s4.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s4.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| s5.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s5.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| sub3 디렉토리 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s6.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s6.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| sub4 디렉토리 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s7.txt 파일 헤더 | 1 블록(512 바이트)
+--------------------+
+--------------------+
| s7.txt 파일 본문 | n 블록(512*n 바이트)
+--------------------+
+--------------------+
| 빈블록 | n 블록(512*n 바이트)
+--------------------+



2. 헤더 구조


TAR 아카이브의 포맷을 보면 이전의 유닉스 호환 포맷(UNIX-compatible formats)과
POSIX (IEEE P1003.1) 기준으로 새로이 정의된 USTAR 포맷(USTAR format)이
있습니다. 새로이 정의된 USTAR 포맷은 유닉스 호환 포맷보다 더 많은 정보를
저장할 수 있으며 더 긴 파일 패스명을 지원합니다. 그러나 어느 포맷이
되었든지 512바이트 크기의 1블록으로 구성되어 있습니다.

우선 이전의 유닉스 호환 포맷에 의한 헤더 구조를 보면 아래와 같습니다.


----------+------+------+-------------------------
FIELD NAME OFFSET SIZE MEANING
----------+------+------+-------------------------
name 0 100 name of file
mode 100 8 file mode
uid 108 8 owner user ID
gid 116 8 owner group ID
size 124 12 length of file in bytes
mtime 136 12 modify time of file
chksum 148 8 checksum for header
link 156 1 indicator for links
linkname 157 100 name of linked file
......
----------+------+------+-------------------------


link 필드에는 링크 파일(linked file)이면 1, 심볼릭 링크(symbolic link)
이면 2, 기타일 때는 0이 기록됩니다. 디렉토리의 경우에는 링크명에
슬래시(/)가 붙게되지요.

새로운 USTAR 포맷에 의한 헤더 구조는 아래와 같습니다. magic 필드에는
null 문자로 종료되는 문자열 "ustra"이 기록되며 magic 필드 이전의
모든 필드는 typeflag 필드를 제외하고는 모두 이전의 유닉스 호환 포맷과
동일합니다. 유닉스 호환 포맷에서의 link 필드가 USTAR 포맷에서는
typeflag 필드로 변경되었습니다.


----------+------+------+-------------------------
FIELD NAME OFFSET SIZE MEANING
----------+------+------+-------------------------
name 0 100 name of file
mode 100 8 file mode
uid 108 8 owner user ID
gid 116 8 owner group ID
size 124 12 length of file in bytes
mtime 136 12 modify time of file
chksum 148 8 checksum for header
typeflag 156 1 type of file
linkname 157 100 name of linked file
magic 257 6 USTAR indicator
varsion 263 2 USTAR version
uname 265 32 owner user name
gname 297 32 owner group name
devmajor 329 8 device major number
devminor 337 8 device minor number
prefix 345 155 prefix for file name
......
----------+------+------+-------------------------


이와 같이 어느 포맷이 되었든지 파일명, 파일크기 등 파일 정보에 관한
내용이 저장되는 헤더는 1블록(512바이트)로 구성되어 있습니다.
이 문서에서는 USTAR 포맷을 중심으로 살펴보겠습니다.

TAR 아카이브를 다룰 때 name 필드부터 typeflag 필드까지만 정확히 다루게
된다면 윈도우를 포함한 어느 시스템에서나 정상적으로 동작하는 것
같습니다. 즉 여러분이 PHP를 이용하여 작성된 TAR 아카이브를 가지고
유닉스 또는 리눅스의 tar 유틸리티를 이용하여 풀 수 있으며, 또한
윈도우에서 알집이나 window commander에서 풀 수도 있습니다.

테이블에 나타난 바와 같이 각 필드마다 그 위치와 크기가 고정되어 있습니다.

magic, uname, gname 필드는 마지막 코드는 반드시 null(아스키문자 0)이
나타나는 null 종료 문자열(null-terminated character strings)입니다.
name, linkname, prefix 필드는 마지막 코드가 반드시 null일 필요는 없으나
정해진 필드크기가 다 채워지지 않았다면 이 공간을 반드시 null로 채워야
합니다. name 필드의 예를 들어보면 만약 파일명이 "s1.txt"라면 name 필드에
기록될 때는 "s1.txt" . str_repeat(chr(0), 100 - strlen("s1.txt")) 에서
얻은 값으로 기록됩니다.

USTAR 포맷에서 uname, gname 필드는 각각 로그인 사용자명과 그룹 사용자명을
기록합니다.

mode, uid, gid, chksum, devmajor, devminor 필드의 마지막 코드는 반드시
null이 기록되어야 하나
size, mtime, version 필드는 반드시 null로 종료할 필요는 없으나
일반적으로 null이 기록되는 것 같습니다. 따라서 숫자를 나타내는 이들
필드는 모두 null로 종료한다고 생각하시면 될 것입니다. 이와 같이 숫자를
나타내는 필드들은 모두 null로 종료되므로 실제로 숫자가 기록되는 장소의
크기는 테이블에 정하여진 SIZE-1이 됩니다. 예를 들어 uid의 경우를 보면
필드 크기는 8바이트이지만 실제로 OFFSET 108부터 114까지의 7바이트에만
기록되며 마지막 OFFSET 115에는 null이가 기록됩니다. 숫자 필드에서
한가지 주의할 것은 기록되는 숫자는 10진수가 아니라 8진수로 기록된다는
것이지요. 그리고 기록되는 숫자의 자리수가 필드 크기보다 작을 때는
앞쪽으로 남는 자리수만큼 "0"으로 채워지게 됩니다. 만약 uid 값이 8이라면
uid 필드에는 "0000008"이 기록됩니다.

어떤 필드가 되었든지 헤더에서는 사용되지 않는 공간은 모두 null로
채우도록 되어있습니다. 이제는 각 필드별로 다른 특징을 살펴보지요.

"name" 필드는 파일명 또는 디렉토리명이 기록되는 곳으로 총 100자까지
기록될 수 있습니다. 파일명이 100자가 되지 않아 비워있는 곳은 모두
null 값으로 채워집니다. 여기에 기록되는 파일명에는 패스명이 포함됩니다.


USTAR 포맷의 경우를 보면 prefix 필드의 값이 null이 아니라면 100자가
넘는 파일명이 가능하도록 name 필드 앞에 붙게 됩니다. 그러나 이전의
유닉스 호환 포맷이나 윈도우 시스템에서 TAR 아카이브를 만들 수 있는
윈도우커맨더 등과의 호환성을 생각한다면 prefix 필드를 null로 남겨두는
것이 좋을 듯하며 100자가 넘는 파일명인 경우 뒷쪽을 짤라내어
100자까지만 name 필드에 저장하는 것이 좋을 듯합니다.

USTAR 포맷에서만 사용하고 있는 typeflag 필드는 이전의 유닉스 호환
포맷의 link 필드와 호환성을 유지한 채 확장시킨 것입니다. 아래는
typeflag 필드에 기록될 수 있는 값들이며 이 중에 0, 1, 2까지는
이전의 유닉스 호환 포맷과 호환성을 유지합니다.


----------+--------------------------------------
TYPE FLAG FILE TYPE
----------+--------------------------------------
0 or null Regular file
1 Link to another file already archived
2 Symbolic link
3 Character special device
4 Block special device
5 Directory
6 FIFO special file
7 Reserved
A-Z Available for custom usage
----------+--------------------------------------


"typeflag"는 파일 형식을 나타내는 필드로 디렉토리일 때는 "5"가
기록되면 파일일 경우에는 "0"이 기록됩니다.


"mode" 필드는 파일 모드가 기록되는 곳으로 8진수로 기록됩니다. 예를
들면 0755, 0644와 같지요. "mode" 필드에서 사용할 수 있는 크기는
총 7자입니다. 이 경우 보통 "0000755"와 같이 남는 공간은 앞쪽에
"0"으로 채우게 됩니다. 그러나 이러한 기록 방법은 프로그램에 따라
약간씩 차이가 나기도 하네요. 윈도우 유틸리티인 windows commander에서
TAR 아카이브를 만들게 되면 "000755 " 또는 "000644 "와 같이 6자만
8진수로 만들어 주고 7번째 자리에는 " "로 채우게 됩니다. 윈도우에서야
원래 파일 모드라는 개념이 없으니까 관계가 없다고 생각할지 모르겠으나
윈도우에서 압축한 TAR 아카이브를 리눅스에서 풀 때는 생각한다면 이를
적절히 처리하는 것이 좋을 것 같습니다.

"uid"와 "gid"도 "mode"와 같이 8진수로 기록되며 총 7자리를 만들게
됩니다. 빈 공간은 앞쪽에 "0"을 채우게 되지요.

"size"는 바이트 단위의 파일 크기를 나타내며 8진수로 기록됩니다.

"mtime"는 파일을 수정한 시간을 나타내며 이에 해당하는 php 함수는
filemtime()입니다.

"magic" 필드는 압축 알고리즘의 이름과 버전을 나타내며 보통 "ustar"
또는 "gnutar" 등이 기록됩니다. 8자가 안되는 부분은 " "로 뒤쪽에
채워지게 됩니다.

"linkname", "uname", "gname", "devmajor", "devminor", "prefix",
"noname" 필드는 모두 chr(0)으로 채워넣습니다.

위와 같이 "chksum" 필드를 제외한 필드를 모두 기록한 후에 마지막으로
"chksum" 필드를 기록합니다. "chksum" 필드는 묶여진 파일이 정상적인가를
확인하는데 이용하는 체크섬 필드입니다. 8진수로 기록되며 채워지지 않는
부분은 앞쪽으로 "0"으로 채우게 됩니다. 체크섬 값은 아래와 같은
방법으로 구하게 됩니다. 이 때 변수 $HEADER에는 "chksum" 필드를 제외한
필드가 위에서 기술한 방법대로 먼저 기록되어 있다고 가정합니다.


function get_checksum() {
$sum = 0;

for ($i=0;$i<512;$i++) {
if ($i < 148 || 156 < $i) {
$sum += ord($HEADER[$i]);
} else {
$sum += ord(" ");
}
}

return $sum;
}


만약 기록하고자 하는 것이 파일이 아니라 디렉토리라면 파일과 같은
내용은 없기 때문에 512바이트의 헤더만 존재합니다. 한번 디렉토리
정보가 기록되면 그 뒤의 파일들은 앞에서 나타난 디렉토리에 속하게
됩니다. 따라서 디렉토리가 변경되는 부분에서만 단 한번 디렉토리 정보가
기록됩니다. 앞에서도 설명하였지만 파일 헤더와 다른 점이라면 "typeflag"
필드값이 "5"라는 것과 "name" 필드에는 파일명 대신에 패스명이
기록됩니다. 예를 들면 "sub1/sub2/"와 같지요. 다른 필드는 파일일 때와
같습니다.



3. 본문 구조


파일 헤더가 완성되었으면 뒤이어 파일 내용이 들어가게 됩니다. 파일
내용은 512 바이트의 배수로 기록됩니다. 만약 파일크기가 1바이트부터
512 바이트사이라면 1블록(512바이트)을 사용하고 513바이트부터
1024바이트까지는 2블록(1024바이트)을 사용하는 식입니다.

결국 TAR 아카이브에서의 파일 내용 부분이 차지하는 크기는 아래와 같은
식으로 구할 수 있습니다.


function calc_blocksize($realsize) {
return ceil($realsize / 512) * 512;
}


파일크기가 0바이트인 파일인 경우에는 디렉토리인 경우와 마찬가지로
파일 헤더만 존재하며 본문은 기록되지 않습니다.



4. TAR 아카이브 후미에 붙여지는 빈블록


TAR 아카이브를 구성하는 멤버 파일 및 디렉토리에 관한 모든 정보(헤더 및
본문)가 다 기록된 후에는 마지막으로 파일 내용과 관계없이 null로 채워진
1블록 이상의 빈블록(empty block)들이 붙여지게 됩니다.



5. TAR 아카이브 관련 PHP 소스


TAR 관련 PHP 소스는 그리 흔한 것 같지 않습니다. 저도 관련 소스를
검색하여 보았으나 www.phpclasses.org에서 단 하나 발견하였을 뿐입니다.
본인도 이 소스를 참조하여 제 나름대로 TAR 아카이브를 다루는
클래스(hTarFile)를 작성하여 제 홈페이지에 공개하였습니다. 관심있는
분은 관련 소스들을 참조하시고 혹시 모르니 여러분도 인터넷을 더 검색해
보시기 바랍니다.


- tar Class
Josh Barger
joshb@npt.com
http://www.phpclasses.org

- hTarFile class
hwooky
hwooky@phpclass.com
http://www.phpclass.com


TAR 아카이브는 아니지만 zip 파일을 만들어 주는 소스가 보이네요. 소스는
TAR 아카이브를 다루는 것보다 훨씬 간단하구요.
저도 실험해 보지는 않았지만 꽤 쓸모있는 소스인 것 같네요. 참조하세요.


- class zipfile
Eric Mueller
eric@themepark.com
http://www.zend.com/codex.php?id=696&single=1

유닉스 시스템에서는 피치못할 이유로 SUID, SUDO등을 이용해 일반 사용자계정이 root권한을 얻어야 할경우가 있습니다.

그 경우 빈번히 쓰는것이 chmod를 이용한 SUID를 설정하는 방법입니다만..
예전 시스템들 (레드햇 5.2이전, 솔라리스7이전)은 잘 되지만 최근 시스템들은 SUID를 설정하여도 잘되지 않습니다.

보안상의 문제점으로 많이 막아놓고 있는데요...

이럴경우 SUDO는 손쉽게 설정파일을 통한 제어를 가능하게 해줍니다.

먼저 SUDO패키지를 설치하고..

/etc/sudoers파일을 visudo를 이용해 편집합니다.
반드시 visudo를 이용해야 하며 sudo를 이용하면 안됩니다.

간단히 popori계정이 ftp데몬을 실행시킬경우

popori ALL=/etc/init.d/proftpd start,/etc/init.d/proftpd stop
와 같이 적어주고
/usr/local/bin/sudo /etc/init.d/proftp start/stop명령으로 가능합니다.

하지만 nobody와 같이 특별한 계정은 위의 명령외에 NOPASSWD란 옵션이 추가로 필요합니다.
아마도 시스템계정이라 그런것 같은데요...

nobody ALL=NOPASSWD: /etc/init.d/httpd restart
와 같이 적어주고 sudo를 통해 apache의 restart/start/stop이 가능합니다.

이런 패키지들은 보안상의 많은 문제점을 만들고 있지만.. 아주 유용하게 사용이 가능하고..
아래와 같은 주의사항을 지켜 만들어서 사용하면 좋지 않을까한다.

*주의*
sudo와 함께 사용하기 위한 명령어는 신중하게 선택되어야 한다. 특히 쉘 스크립트 사용하지 말고 인터랙티브 프로그램(편집기나 게임)을 실행하는 쉘 명령어를 실행하기 위한 shell escape를 제공하는 유틸리티도 사용하면 안된다.

개별 패키지 설치는 한두개 의존성만 해결하면 손쉽게 설치할 수 있지만
만약 KDE이나 GNOME을 설치 안했다가 설치할려면 골치좀 썩습니다.
이런 문제를 redhat 9.0에서는 완전히 해결했습니다.

1. 시디를 가지고 있을때
이건 간단한데 redhat-config-packages 를 실행하면 됩니다.

2. 하드디스크에 iso이미지를 가지고 있을때
실제 제가 열려드리고 싶은 부분은 이부분인데 위의 redhat-config-packages을 콘솔에서 실행합니다.
# redhat-config-packages --isodir=PATH

다음 과정은 1과 같습니다.
redhat-config-packages는 실제 /usr/share/redhat-config-packages/MainWindow.py를 구동시킵니다.
redhat-config-packages는 단지 MainWindow.py에 실행퍼미션을 주고 실행시키는 역활을 합니다.

프로그램을 데몬처럼 실행하고 싶을 때는 다음과 같이 하면 됩니다.

명령어 &

여기서 '&'는 백그라운드로 실행하라는 뜻입니다.
그런데, 로그아웃하면 프로그램이 함께 끝나 버리게 됩니다.

이럴때에는 nohup 이란 명령어를 사용하면 됩니다.

nohup 명령어 &

이렇게 하면 로그아웃을 하더라도 프로그램은 백그라운드로 계속 실행됩니다.

시스템 관리를 하다보면 유닉스상에서 메일을 보내야 할 경우가 가끔 생깁니다.
메일을 보내기 위해선 기본적으로 제공되는 mail 명령어를 많이 사용하지만,
sendmail 명령어도 많이 합니다.
아래는 간단히 mail 명령어를 이용하여 메일을 보내는 방법 입니다.

■ 커맨드 상에서 내용을 직접 입력할 때

# mail -s "제목" 수신자이메일
메일 내용
.
#

위에서 "." 은 끝을 의미합니다. "." 대신 ^D를 사용하기도 합니다.

■ 스크립트상에서 내용을 직접 입력할 때

#!/usr/bin/ksh

mail -s "제목" 수신자이메일 << EOF
메일내용
EOF

exit 0

■ 스크립트상에서 파일내용을 메일로 보낼 때

#!/usr/bin/ksh

mail -s "제목" 수신자이메일 < 화일명

exit 0

■ 스크립트상에서 첨부화일로 보낼 때

#!/usr/bin/ksh

uuencode 파일명 동일화일명 | mail -s "제목" 수신자이메일

exit 0

참고로 sendmail 명령어를 사용할 땐, 다음과 같이 하면 됩니다.

# sendmail -f송신자이메일 수신자이메일
From: 송신자이메일
To: 수신자이메일
Subject: 제목
메일내용

ls 명령에 관해서 자주쓰는 옵션을 제외한 몇가지 중요한 \
옵션을 나열하였습니다.

명령:ls [-ABCFGHLPRTWabcdfgiklnoqrstu1] [file ...]

-a .(설정파일)을 포함한 모든 파일네임을 보여주는 옵션

-i 각 파일및 디렉토리의 inode를 알려준다

-l 파일 리스트에 파일의 각 특징및 상태를 같이 출력

-F 파일의 타입을 알려준다.

@ :링크파일
/:디렉토리파일
*:실행파일

-G 파일의 성격에 따라서 파일 네임에 색상을 입혀서 출력한다

-L 파일의 참조링크를 출력하지 않는다.

-P 파일의 참조링크파일을 출력한다

-T 시간을 자세히 출력.

-n 유저및 그룹넘버를 출력해준다.

"amd" :
마운트를 자동으로 해주는 데몬입니다. 이 항목은 네트워크 정보가 잘못 입력되었을 경우 부팅될 때 문제를 일으킬 수 있으므로 별다른 경우가 아니라면 꺼놓는 것이 좋습니다. 네트워크 설정이 정상적이거나 아예 사용하지 않는 겨우라면 선택해도 무방합니다.

"atd" :
백그라운드 작업을 해주거나 각종 예약 명령을 처리하는 작업을 합니다. 기본적으로 선택되어 있으며, 별다른 문제를 일으키지 않으므로 선택하도록 합니다.

"bootparamd" :
리눅스 서버를 통해 연결된 워크스테이션이 리눅스의 서버 정보를 통해 부팅을 하는 데몬입니다. IP를 지정하는 역할이라고 생각하면 되는데 최근에는 BOOTP와 DHCP가 많이 사용되며 워크스테이션이나 다른 서버가 연결되지 않은 컴퓨터라면 꺼놓도록 합니다.BOOTP와 DHCP를 사용할 때에도 켜놓을 필요가 없습니다.

"crond" :
리눅스에 등록된 명령어들을 정기적으로 수행하는 데몬입니다. 즉, 멀티 태스킹으로 동작하는 리눅스 체계에서 받은 메일의 스풀러 정리라든지 각종 명령어들을 실행하는 항목으로 중요한 데몬입니다. 반드시 선택하도록 합니다.

"dhcp" :
네트워크로 구성된 상태에서 리눅스 서버의 정보를 이용하여 부팅될 자신의 IP주소와 네트워크 정보를 가질 수 있게 하는 데몬입니다. 네트워크에 서버로 사용되는 리눅스라면 BOOTP와 DHCP가운데 하나를 선택해야 하는데, 정적IP를 부여한 네트워크 환경에서 선택해야 하는 데몬입니다. 네트워크 구성이 되지 않는 일반 PC에 리눅스가 설치된 경우라면 굳이 선택할 필요 없습니다.


"gpm" :
리눅스로 부팅된 다음 텍스트 상태에서 마우스를 사용하여 영역을 선택하거나 복사가 가능하도록 해주는 데몬입니다. 이 서비스는 PS/2 마우스의 경우 X윈도에서 충돌할 수 있습니다. 따라서 X윈도를 실행시켰을 마우스가 움직이지 않는다면 이 옵션을 끄도록 합니다.

"httpd" :
아파치 웹 서버입니다. 웹 서버로 사용되는 PC가 아니라면 선택할 필요가 없습니다. 부팅될 시간이 많이 걸리는 데몬 중의 하나 입니다.

"int" :
telnet, FTP, rlogin등의 서비스를 요청할 때 사용되는 데몬입니다.역시 독립 PC일 경우에는 선택할 필요가 없으며, 네트워크 환경이나 인터넷 환경에서 자신의 PC를 서버 개념으로 사용할 때 필요한 데몬입니다.

"innd" :
리눅스 서버를 뉴스 서버로 사용할 때 지정하는 데몬으로 유즈넷 뉴스의 서버 입니다.

"kerneld" :
운영체제의 핵심인 커널 기능을 동작시키는 중요한 서비스입니다. 반드시 선택하도록 합니다.

"keytable" :
부팅될 때 키보드의 정보를 설정하는 옵션입니다.

"lpd" :
프린터를 관리하는 데몬으로 프린터가 없다면 선택할 필요가 없습니다.

"named" :
도메인 네임 서버로, 역시 독립 PC일 때에는 지정할 필요가 없습니다.

"network" :
네트워크에 관련된 각종 설정을 활성화 하는 데놈입니다. 속도에는 그리 영향을 끼치지 않는 중요한 선택 옵션이므로 체크하도록 합니다.

"nfs" :
NFS 서버 데몬입니다. NFS는 네트워크 파일 시스템 (Network File System)이며, 네트워크상에서 파일이나 폴더를 공유할 수 있도록 하는 데몬입니다.

"nfsfs" :
네트워크 파일 시스템을 사용할 수 있게 해주는 스크립트입니다.

"portmap" :
원격 프로시저 호출(RPC: Remote Procedure Call)을 위한 데몬으로 네트워크상에서 클라이언트 서버 개념이 적용되지 않는 시스템에서는 실행할 필요가 없는 데몬이지만 네트워크상에서 NFS, NIS, amd등의 원격 프로시저 호출을 하는 프로그램을 사용할 겨웅에는 반드시 선택해야 하는 데몬입니다.

"routed" :
자동IP라우터로 역시 독립 시스템에서는 따로 실행할 필요 없습니다.

"sendmail" :
메일 전송 서버입니다. 메일 서버로 시스템을 운영하는 경우가 아닐 에는 꺼 놓도록 합니다.

"smb" :
마이크로소프트의 네트워크 파일/프린터 공유 서버입니다. 파일 서버로 운영 하여 다른 PC들이 윈도에서 파일이나 프린터를 공유할 경우 실행해야 하는 데몬이지만 그렇지 않을 경우에는 꺼놓도록 합니다. 네트워크 설정이 올바르지 않을 때에는 매우 긴 시간을 잡아먹게 되므로, 네트워크 설정을 제대로 지정한 다음 켜놓도록 합니다.

"sound" :
리눅스가 부팅될 때와 종료될 때 사운드의 믹서 설정을 복구하거나 저장하는 스크립트입니다.

"syslog" :
시스템에서 발생하는 각종 사건을 시록하는 데몬입니다. 작업 내용이나 로그온 정보 등이 필요할 경우 켜놓도록 합니다.

"ruserd":
네트워크 사용자를 추적할 수 있는 데몬으로 특정 사용자의 위치를 확이 할 수 있습니다.


"rwhod" :
원격 접속을 한 사용자들의 목록을 볼 수 있는 로그 정보를 가진 데몬입니다.

"snmp" :
네트워크 프로토콜의 하나로 단순 네트워크 관리 프로토콜(SNMP:Simple Network Management Protocol) 의 약어입니다.

"ypbind" :
NIS 네트워크 클라이언트에 관련되는 서버입니다. NIS를 사용하지 않는 서버에서는 지정할 필요가 없습니다.

"yppasswd" :
NIS에 관련되는 것으로 클라이언트 사용자가 패스워드를 변경할 수 있도록 해주는 서버측의 데몬 입니다.

"ypserv" :
NIS/YP 네트워킹 프로토콜의 서버입니다.

유닉스나 리눅스 서버에서 서버의 이상이나 갑작스런 종료로 인해서 시스템의
파일시스템 이상으로 재부팅시 파일시스템이 마운트 되지 않는 경우가 종종 발생합니다.
위와 같은 경우 가장 많이 사용하는 명령어인 fsck에 관한 자세한 설명 입니다.

1. 파일시스템 점검 및 복구
부적절한 시스템의 중지(shutdown을 이용하지 않고 시스템 을 강제 종료하거나 정전에 의한 시스템의 예기치 않은 정지등의 이유)나 하드웨어상의 문제 발생시 파일시스템은 손상을 입게 된다. 이러한 경우 다시 시스템을 부팅하여 사용하기 이전에 "fsck" 명령 을 사용하여 시스템상의 모든 파일시스템을 점검하여 조치를 취하여야 한다.
* fsck 명령어의 점검사항
fsck 명령어는 다음과 같은 사항을 점검한다. fsck가 점검하는 부분이, 파일 시스템 전 체를 점검하기 때문에 fsck는 각 부분의 점검 (super block, i-node, indirect block, data block. free block 등)을 단계별로 나누어서 점검하게 된다. 비정상적인 시스템의 종료로 인한 정상적인 파일 시스템의 관리가 진행되지 못하였을 때는 이의 복구를 우선하여야 한다. 이러한 일련의 점검은 그 효 율을 증대하기 위하여 부분별로 나누어져 각 단계별로 진행된다.

| haitai# fsck /dev/rdsk/c0t3d0s7
| ** /dev/rdsk/c0t3d0s7
| ** Currentyly Mountes on /home
| ** Phase 1 - Check Blocks and Size
| ** Phase 2 - Check Pathnames
| ** Phase 3 - Check Connectivity
| ** Phase 4 - Check Reference Counts
| ** Phase 5 - Check Cly groups
| 314 file,14585 free (82 frags, 172 blocks, 0.3% fragmentation)

*phase 1 - Check Blocks and Sizes
파일시스템에 존재하는 파일에 대한 정보를 담고 있는 i-node 영역을 점검하는 단계로서 파일 유형의 이상 유무, 파일의 내용이 있는 디스크 블록의 주소, 파일의 크기, 파일의 링크여부를 점 검한다.

| Haitai# fsck /dev/rdsk/c0t3d0s7
| ** Last Mounted on /home
| ** Phase 1 - Check Blocks and Sizes
| PARTIALLY ALLOCATED INODE I=5
| CLEAR? Y
|
| UNKNOWN FILE TYPE I=768
| CLEAR? Y
|
| 5 DUP I=2306
| 6 DUP I=2306
| 7 DUP I=2306
| 8 DUP I=2306
| 9 DUP I=2306

부적절하게 할당된 i-node를 점검한다. 즉, i-node 리스트들이 점검되어진다.
파일 유형이 없을때 (i-node 768, 종종 디렉토리에서 발생) fsck는 파일시스템에 존재하는 파일에 대하여 i-node의 정보중 링크 계수가 '0'인 경우는 다음과 같은 메세지를 내보낸다.

| LINK COUNT TABLE OVERFLOW
| CONTINUE?

i- node에 의해 요구되어진 블록을 점검하는 동안 불량블럭, 중복 블록등이 발견될 경우 다음 메시지를 출력한 다.
| xxx BAD I=I 또는 yy DUP I=L
여기서 xxx은 잘못된 블록 주소 로서 이러한 잘못된 데이터 디스크 블록을 가지고 있는 파일을 점검할 때 나타난다. 여기에서 는 단지 메시지 출력만 있을 뿐 운용자에게 응답을 요구하지 않는다. 그러나 운용자는 이 i-node 번 호를 기억해 두는 것이 좋다.
나중에 중복 블록에 대한 파일의 점검시에 제거할 수 있는 파일을 결정해야하기 때문이다.


*Phase 2 - Check Pathname
화일시스템에 디렉토리 를 점검한다. 루트 디렉토리하의 모든 디렉토리에 대하여 디렉토리의
구조를 점검하여 각 화일 들의 이름과 i-node 링크에 대한 이상 유무를 검진한다.

| - Phase 2 - Check Pathname
| UNALLOCATED I=768 OWNER=root MODE=0
| SIZE=0 MTIME=Jul 15 16:18 1992
| NAME=/test
|
| REMOVE? y

디렉토리 엔트리들이 점검되어진다. 루트 디렉토리부터 시작하여 각 디렉토리 엔트리를 계층적으로 점검해 나간다. Phase 1에서 수집한 정보와 여기서 디렉토리 엔트리를 점검한 정보와 비교하면서 비교에서 어긋남이 있으면 에러 메세지 를 출력한다. 점검을 시작하는 i-node는 2번(root directory)부터 시작한다. 루트 파일시스템의 i- node 모드와 상태, 디렉토리 파일 내용의 이상 유무, 잘못된 i-node 링크수 등을 검사한다.
비 록 할당된 i-node를 가지고 있을지라도 루트가 디렉토리 유형이 아니고 일반적인 파일의 유형이라던 지 다른 4가지 형태라면 계층구조인 화일시스템에서는 각 경로들을 찾아갈수가 없을 것이다. 이러한 경우 출력되는 메세지는 다음과 같다.

| ROOT INODE NOT DIRECTORY
| FIX?

이러한 경우의 선택은 당연히 'y'가 되어야 할것이다. 그러면 fsck는 루트의 파일 유형을 디렉토리 파일의 유형으로 변환시켜 줄것이다. 이 상황에서 루트 i-node 에 문제가 발생했다면 다음 메시지를 출력시킨다.

| DUPS/BAD IN ROOT INODE
| CONTINUE?

Phase 1과 Phase 1B에서 루트 i-node에서 이 중블럭이나 잘못된 블록이 발견 되어진 결과로 발생하는 메시지이다. 여기서 'y' 라고 입력하 여 그것을 없애 버린다.

Phase 2 동안 계층적으로 찾아 들어가고 있는 동안 Phase 1에서 나타났던 잘못된 블록이나 중복된 블록을 가지고 있는 i-node를 발견시 그때의 메시지 출현은 다음 과 같다.

| DUP/BAK I=00 OWNER=0 MODE=M SIZE=S
| MTIME=T FILE=/important
| REMOVE?

Phase 1에서 불량/중복 블록 주소를 기록하지 않았다면 이 i-node가 불량인지 중복인지 구별할 수가 없다. 여기 서 운영자는 신중한 결정을 해야한다. 데이터를 보존하여 둔 것이 있었으면 당연히 없애버리고 다시 회복 시킬수가 있지만 그렇지 않을 경우에는 'n'이라고 입력한 뒤에 백업을 받고 fsck를 다시 실행시 키는 것이 좋을 것 같다.
그것이 잘못된 블록이라면 cp명령어가 소용 없게 된다. cp명령어는 잘 못된 블록의 주소를 가지고는 더 이상 진행하지 못하기 때문이다.
만일 fsck 수행중 i-node넘버 만 알 수 있고 그 파일의 이름을 모르는 경우에는 ncheck 명령으로써 파일 이름을 확인할 수있 다.

*Phase 3 - Check connentivity
파일시스템에 디렉토리를 점검하여 만약 디렉토 리의 구조가 잘못되어 파일 이름과 i-node 링크 항목의 디렉토리 항목이 없을시 이를 복구한 다.

| **Phase 3 - Check Connectivity
| UNFER DIR - =769 OWNER=root MODE=40775
| SIZE=512 MTIME=May 12 15:27 1991
| RECONNECT? Y
|
| DIR I=769 CONNECTED. PATENT WAS I=768
| UNFER DIR I=1536 OWNER=root MODE=40775
| SIZE=512 MTIME=Jun 8 10:42 1991
| RECONNECT? Y
|
| DIR I=1536 CONNECTED. PARENT WAS I=768
|
| DUP/BAD I=2306 OWNER=987 MODE=100640
| SIZE=4096 MTIME=May 11 10:43 1991
| FILE/lost+found#1536/ASA/test11
| REMOVE? Y

Phase 2 에서 계층적으로 찾아들어가는 동안 발견 못했던 디렉토리 i-node에 대한 이름 을 만드는 즉, 디렉토리 연결자체와 관계되는 부분이다. 참조할 수 없는 디렉토리 또는 lost+found 디 렉토리에 연결할 수 없는 것 등에 의한 오류등이다.

i- node에 대해 디렉토리 엔트리를 더 한다. 그러한 i-node를 발견하였을 때의 메시지는 다음과 같다.

| UNREF DIR I=769 OWNER=root MODE=40775
| SIZE=512 MTIME=May 12 15:27 1991
| RECONNECT?

여기서 'n'라고 입력하면 현 오류상태가 무시된 다. 이때는 항상 다음 Phase에서 UNFER 오류를 발생한다. 되도록 'y'라고 답하는 것 이 좋을 것이다.
만일 그 i-node가 비어있다면 요구상황 없이 그 파일을 없애버린 다.
Lost+found 디렉토리에 연결이 무사히 진행되었으면 CONNECTED라고 메시지가 다음과 같 이 출력된다. 추후에 lost+found 디렉토리를 점검하여 조치를 취해야 한다.

| DIR I=769 CONNECTED. PARENT WAS I=768


*Phase 4 - Check Reference Counts
파일시스템 관리 정보를 담고 있는 슈퍼 블록내의 파일 할당 수와 디렉토리 들을 점검하여 조사된 파일들의 수를 비교, 이상 유무를 검진하여 복구한다.

| Phase 4 - Check Reference Counts
| LINK COUNT DIR I=2 OWNER=root MODE=40775
| SIZE=512 MTIME=May 13 15:53 1991
| COUNT 4 SHOULD BE 3
| ADJUST? Y
|
| UNREF DIR I=787 OWNER=root MODE=100644
| SIZE=728 MTIME=Jun 13 13:42 1991
| REVONNECT? Y
|
| UNREF DIR I=788 OWNER=root MODE=100644
| SIZE=1126 MTIME=Apr 23 09:31 1991
| RECONNECT? Y
|
| DUP/BAD I=2306 OWINER=987 MODE=100640
| SIZE=4096 MTIME=May 11 10:43 1991
| FILE=/lost+found/#1536/ASA/test11
| CLEAR? y

이 과정은 Phase 2 에서 디렉토리 엔트리를 찾아가면서 계산되 어진 링크계수와 각각의 i-node에 있는 링크 카운터 값과 일치하여야 하는데 값이 같지 않을 경우 오 류 메시지를 출력하는 것이다.
0이 아난 링크 카운트를 가지지만 디렉토리 엔트리를 계층적으로 찾아갈 때 발견하지 못한 i-node를 발견하였다면 그것을 lost-found 디렉토리에 연결할 것인지 물을 것이다.
(그 i-node가 비워 있지 않을 경우에) fsck는 Phase 2,3 동안 실제 디렉토리 엔트리의 링크 카운트를 계산한다. 두 값의 비교로 같으면 상관없지만 틀릴경우 메시지는 다음과 같 다.

| LINK COUNT DIR I=2 OWNER=root MODE=40775
| SIZE=512 MTIME=May 13 15:53 1991
| SOUNT 4 SHOULD BE 3
| ADJUST?

여기서는 'y'를 입력하여 틀린 링크 카운트를 정확하게 맞추어야 한다.

Phase 4 수행도중 다음과 같은 오류 메시지가 발견되었다고 가정해 보 자.

| UNREF DIR I=787 OWNER=root MODE=100644
| SIZE=728 MTIME=Jun 13 13:42 1991
| RECONNECT?

이 메시지는 디렉토리 엔트리에 의해 참조되지 않은 파일이 존재 한다는 것이다. 즉, i- node 수치가 787인 파일이 디렉토리 엔트리에 연결되어 있지 않는 경우이다.
다시 재연결할것인 지 묻는 것은 이 파일을 lost-found 디렉토리에 연결 시킬것인가를 묻는 것이다. 'y'라는 대답으로 일 단은 lost+found에 옮겨 놓는 것이 좋다.


*Phase 5 - Check Cyl groups :
슈퍼 블록에서 관리하고 있는 프리 블록 리스트(파일의 데이터 생성내지 추가시 할당을 받을 수 있는 파 일 시스템 영역)과 현재 파일의 데이터가 점유하고 있는 디스크 블록들이 중복되는지를 점검하여 진 행한다.

| ** Phase 5 - Check Cyl groups:
| FREE BLK COUNT(S) WRONG IN SUPERBLK
| SALVAGE? Y
|
| 10744 files, 143872 used, 18518 free
| (1422 frage, 2137 blocks, 0.9% fragmentation)
| ***** FILE SYSTEM WAS MODIFIED*****

여 기서의 주임무가 프리블럭 리스트를 점검하는 단계다.
모든 블록들은 i-node에서 주소로 기록되 어 있거나 아니면 free block list에 기록되어 있어야 한다. 프리블럭 리스트 내의 비정상적인 블록 정 보, 프리 블록 리스트의 블록과 파일에 할당된 데이터 블록과의 중복등의 사항을 점검한다. 만약 Phase 4 동안에 어떤 i-node를 제거시켰을 때는 그 i-node를 제거시켰을 때는 그 i-node는 현재 파 일이 있지도 않고 프리블럭 리스트에도 등록이 되어 있지도 않을 것이다.
이럴 경우 하나의 에 러 메시지가 출현할 수 있는 요소가 된다.

1 BAD BLKS IN FREE LIST

중복블럭 이 발생했을 경우도 마찬가지로 진행되며 메시지의 출현은 다음과 같다.

2. DUP BLKS IN FREE LIST

만일 비어있지않는 i-node를 지워버릴 경우에는(fsck에서나 또는 clri를 통하 여) i-node의 주소비트에서 할당되지도 않았고 free block list에도 할당되지 않는 경우가 발생될 수 있다.
그럴 경우에 출현될 수 있는 메시지는 다음과 같다.

00 BLK(S) MISSING

슈퍼 블록내의 프리 블록 리스트를 관리하고 있는 내용이 잘못된 경우 다음과 같 이 나올 수 있다.

| FREE BLK COUNT(S) WRONG IN SUPERBLK
| SALVAGE?

이런 메시지를 발견 했을 경우의 대답은 되도록이면 'y'라고 답 하는 것이 좋다.
슈퍼 블록에 저장되어 있는 free list에서 범위를 벗어난 블록이나 중복된 블록 이 fsck 프로그램에서 허용, 정의한 10개가 초과 했을 경우는 bad, dup block이 excessive(초과) 했 다는 메시지가 출현된다.

| EXCESSIVE BAD BLKS IN FREE LIST
| EXCESSIVE DUP BLKS IN FREE LIST
| CONTINUE?

이때에는 'y'를 선택하면 free block list의 나머지가 무시되고 fsck는 계속 진행된 다.
Phase 5에서 발견된 프리 블록 리스트의 비정상적인 블록, 중복 블록, 중복되지 않은 프리블 럭등에 의해 발생되는 에러에 의하여 항상 나타나는 메세지로서 만일 '-q' 옵션을 지정하면 프리블 럭 리스트는 자동적으로 제거된다.
그렇지 않는 경우는 다음과 같이 나타난다.

| BAD FREE LIST
| SALVAGE?

여기에서 'y'를 입력하 면 실제의 free block list가 새롭게 free block list로 등록된다

유닉스 시스템에서 파일을 삭제했을 경우 별도의 백업 라이브러리가 없거나
백업 서비스를 받지 않는 경우라면 삭제된 파일은 복구가 불가능합니다.

그래서 실수로 인한 파일삭제를 방지하기 위해 다른 방법을 쓰기도 합니다.
가령 rm command를 mv command로 alias로 걸어서 파일을 삭제하면 특정한
디렉토리(Windows의 쓰레기통과 같은)로 일정기간 move시켜 놓은 방법을
쓰기도 합니다. 이런 종류의 utility는 상당히 많이 있고, 또 벤더 자체에서
제공하는 것도 있습니다..

하지만 무엇보다 중요한 것은 유닉스 서버에서 작업을 할 경우에는 항상
작업파일을 이름을 바꾸어서 백업을 해놓거나 그외에 백업디렉토리를 만들어서
백업을 시켜놓으시기 바랍니다.. 하지만 이보다 더 좋은 방법은 따로 백업
솔루션을 구축해 놓는 방법입니다.

유닉스 계열 운영체제의 설계 개념은 기본적으로 레지스터같이
시스템을 관리하기 위한 전역적인 데이터베이스와 맞지 않습니다.

리눅스에서 기본으로 이용되는 ext2 파일시스템이나 ext3 파일시스템은
사용자 레벨에서는 디스크 조각 모음이 필요없는 파일 시스템입니다.

템프폴더 정리나 쿠키 정리는 웹 브라우저 관련 내용이니까
운영체제와는 상관없습니다. 타임아웃 시간만 잘 설정하면 됩니다.

rpm이나 deb같은 패키지 관리 시스템을 사용한다면 손쉽게 프로그램을
설치하고 제거할 수 있습니다.

소스 컴파일 후 make install로 설치한 프로그램들은 make uninstall로
제거가 가능합니다. 물론 소스 컴파일한 디렉토리를 지우지 않아야 합니다.

UNIX 에서 dns lookup 을 하는 dig 에대한 간단한 예제입니다.

기본적인 lookup
#dig @ns.gihc.net inet.co.kr

MX record 확인
#dig @ns.gihc.net -t mx inet.co.kr

모든 정보보기
#dig @ns.gihc.net -t any inet.co.kr

SOA 정보보기
#dig @ns.gihc.net -t soa inet.co.kr

NS 정보보기
#dig @ns.gihc.net -t ns inet.co.kr