Solaris 기초에서 중급까지

Solaris 기초에서 중급까지 - Copywrite 2001. 10 for Hackers lap

Part One

Solaris8 설치

Chapter Solaris 8
Intel Platform Edition 개요
서 언
1998년 11월 Sun Microsystems에서 발표한 솔라리스(Solaris) 7은 X86계열의 인텔 CPU사용자도 사용할 수 있는 Intel 플랫폼이 Sparc 플랫폼과 함께 발표되었다. 스팍 서버의 전용 운영체제로만 알고 있던 솔라리스를 인텔기반 PC에서 사용할 수 있다는 소식은 많은이들의 관심을 불러일으켰고 실제로 많은 매니아들이 이를 사용해보며 그간 궁금하기만 하던 솔라리스에 대한 갈증을 해소할 수 있었다.

그로부터 1년이 지나지 않은 99년 9월, 솔라리스 8 베타판이 제한된 테스터들에게 공개되었고 2000년 3월, 솔라리스 8 정식제품이 발표되었다. 아직 이를 사용해보지 않은 많은 리눅서들은 솔라리스에 대한 막연한 궁금증도 가지고 있었을 것이다. 대체 어떤 운영체제일까?

인텔 플랫폼과 스팍 플랫폼의 차이점
솔라리스 7 발표당시 한국 썬은 " 솔라리스 7은 스팍(SPARC) 프로세서와 인텔 프로세서를 위해 단일 코드를 제공한다. 즉, 인텔 플랫폼 상에서도 스팍 기반의 시스템에서와 동일한 성능을 제공한다"고 하였다. 그러나 솔라리스 8이 발표된 현재까지 각 플랫폼은 다음과 같은 차이가 존재한다.

우선, 스팍 플랫폼이 CPU에 따라 32비트 혹은 64비트 커널 운영체제로 동작하는데 비하여 인텔플랫폼은 당연히 32비트커널 운영체제이다. (차기 인텔 플랫폼에서는 64비트 운영체제로 개발할 것이라고 한다)

또 한가지, 제공되는 소프트웨어 및 솔라리스에서 사용할 수 있는 유틸리티를 비교해보면 스팍 플랫폼이 인텔플랫폼에 비하여 훨씬 다양하다. 어찌보면 당연하겠지만 응용 프로그램은 스팍서버용과 인텔 용으로 따로이 구성되어 있다.

solutions.sun.com에 가보면 솔라리스에서 사용할 수 있는 다양한 프로그램을 다운로드받을 수 있다. 이중 solaris 인텔 플랫폼을 위한것은 찾기가 쉽지 않다. 대부분이 sparc용으로 개발된 것들이다.

그러나 이를 보완해주기라도 하듯 Sun Microsystems와 lxrun 개발팀의 협력하에, Lxrun이라는 유틸리티가 개발됨으로써 인텔 플랫폼 솔라리스 사용자들은 리눅스 프로그램을 솔라리스에서 곧바로 실행시킬 수 있는 잇점을 누리게 되었다. (모든 리눅스용 프로그램이 100% 실행가능한 지는 아직 확인해보지 않았다.) 아뭏든 Lxrun덕분에 Quake 2 게임도 솔라리스에서 실행시키는 것이 가능한 현실이 되었다. Lxrun 유틸리티는 솔라리스 8과 함께 제공되는 Companion CD안에 포함되어 있다.

이러한 점을 제외하면 두 플랫폼간의 사용상 차이점은 거의 없다고 보아도 무리가 없다. 이제부터 Solaris 8 Intel Platform Edition을 솔라리스8로 줄여서 적도록 하겠다.

솔라리스 8의 특징
많은 기업에서 굳이 솔라리스를 고집해온 이유는 무엇일까? 오랜 세월 버전업을 거치면서 구축한 시스템의 안정성 및 보안성을 꼽고 있다. 기계가 없어서 필자는 시도해보지 못했지만 64개의 CPU, 4노드 클러스터까지 지원하는 뛰어난 확장성도 자랑하고 있다. Intel 플랫폼 에디션의 또 다른 특징은 PCI 및 SCSI 장치 핫 플러그 지원으로, 핫 플러그 기능을 가진 Intel 아키텍처 기반 시스템이 계속 실행 중인 가운데 PCI 어댑터 및 SCSI 장치를 추가 또는 제거할 수 있다고 한다.

솔라리스를 처음 접했을 때 리눅서들이 느끼는 점은 바로 사용의 편리성일 것이다. 마우스를 통한 파일의 Drag and Drop이 솔라리스 파일관리자에서도 구현된다. 파일의 속성이나 소유자 변경도 마우스 오른쪽 버튼을 click여 변경할 수 있다. vi나 emac을 대신하여 윈도우의 노트패드와 같은 텍스트 에디터가 제공되므로 텍스트 파일 편집도 아주 쉽게 할 수 있다.

8GB 이상의 고용량 하드디스크도 실린더수에 관계없이 곧바로 사용가능하다. 이밖에 아주 중요한 점 한가지... 바로 한글 사용문제이다.

리눅스 시스템에서 한글을 사용하기 위하여 얼마나 많은 국내 고수들이 노력을 기울여 왔던가. 솔라리스 8은 운영체제 차원에서 거의 완벽한 한글을 지원해준다.

그러나 함께 제공된 Star Office 5.1에서는 여전히 한글을 사용할 수 없었다. (사실 이는 솔라리스에서뿐만 아니라 Windows와 같은 다른 운영체제하에서도 마찬가지이다) MS 워드, 엑셀, 파워포인트등의 데이터를 그대로 가져와서 사용할 수 있는 스타오피스에서 한글사용이 가능해질 경우, 그 파급효과는 엄청날 것이라 생각된다. (스타 오피스는 현재 무료로 다운로드를 받을 수 있다)

솔라리스 8을 설치하고 나면 사용자도 모르는 사이에 기본적으로 설치되는 프로그램들이 있다. 그중에는 Apache 1.3.9 웹서버, Perl, Samba, ftp, telnet등 웹서버나 네트워크 서버로 운영하는데 꼭 필요한 유틸리티도 포함되어 있다. 물론 JAVA의 원조답게 최신 JRE 및 JDK 1.2.1도 포함되어 있다. 웹 브라우저로서는 넷스케이프가 설치된다. MPEG, QUICKTIME등 멀티미디어 파일 재생을 위한 JAVA 기반의 PLAYER도 지원된다.

솔라리스 8의 보다 자세한 제품특성은 한국 Sun의 웹사이트에도 자세히 소개되어 있기에 여기서는 다루지 않겠다.
(http://www.sun.co.kr/products/software/os_platforms/solaris/solaris.html)

솔라리스의 구입
솔라리스 8은 CD로 공급된다. 다국어판의 경우 유틸리티를 포함하여 자그마치 9장의 CD로 구성되어 있다. 국내에서는 구할 수 없고, 유일한 구입방법은 인터넷을 통하여 미국 썬의 웹사이트 (http://www.sun.com/software/solaris/binaries/)에 주문하는 것이다.

필자도 신용카드를 이용하여 인터넷을 통해 구입하였다. (주문후 세관통관을 거쳐 제품을 수령하기까지 10일이 걸렸다. DHL을 이용한 배달일 경우, 제품구입에 따른 총 소요비용은 13만원이 조금 넘는다)

인텔 솔라리스8은 1 COPY당 8개의 CPU까지 설치가 가능하다.

솔라리스 8의 구성
솔라리스 8은 다국어 (Multi-lingual) 판이 준비되어 있다. 솔라리스 다국어판은 37개국의 언어를 지원한다. 물론 한국어판도 어엿이 포함되어 있다. 솔라리스 8 아시아판 CD는 다음과 같이 구성되어 있다.

Solaris 8 Installation CD
Solaris 8 Operating Environment Software CD (2장)
Solaris 8 Languages (지원언어 : 한국어, 영어, 프랑스어, 독일어, 이탈리아어,
스페인어, 스웨덴어, 일본어, 중국어(간자포함)
Solaris 8 Documentation CD (2장, 아시아판 및 유럽판)

보너스 소프트웨어
StarOffice 5.1(현재 썬 사이트에서 최신 5.2버전을 다운로드받을 수 있다)
Solaris Software Companion CD
(솔라리스에서 사용할 수 있는 많은 유틸리티 프로그램이 들어있다.)
Oracle 8i 엔터프라이즈 Full Version for Solaris Intel
(오라클 DB의 모든 기능이 들어있지만 라이센스는 개발자용이다)

Chapter Solaris 8
Intel Platform Edition 설치
요즘 나오는 리눅스의 경우 과거와는 달리 설치과정이 오히려 윈도우보다 더 쉽다는 말도 나올 정도로 편리하게 되어 있다. 솔라리스 8의 경우도, 설치과정에서부터 필요한 유틸리티를 추가설치할 때까지 과거 리눅스와는 다른, 어떤면에서는 윈도우 운영체제와도 같은 편의성을 보여준다.

시스템 설치전 유의사항
솔라리스8은 설치할 주변기기의 사양을 선택함에 있어서 그리 까다롭지는 않다. 그러나 Network 카드에 있어서는 매우 까다롭다. 필자 역시 Windows 98, NT, Linux등에서는 별 문제없이 사용해오던 Realtek 카드를 설정하려다 결국은 포기하였다. 카드를 Intel Pro 100 PCI로 바꾸자, 단번에 인식해 버린다.

VGA카드도 세비지 3D는 전용 드라이버가 없는 관계로 기본 VGA사양 (800X600, 16색) 으로 설정되었다. 그러나 ATI VGA CARD는 저가형 모델임에도 볼 만한 해상도 (1024X768, 256색) 로 지원된다.
교훈 한가지, 주변기기가 인식이 되지 않걸랑 여기에 힘을 소모하지 말자는 것이다. 인텔 솔라리스8을 공식적으로 지원하는 하드웨어 목록은 썬 솔라리스 사이트(http://soldc.sun.com/support/drivers/hcl/8/600/BOOK.htm)에 명시되어 있다.

그러나 여타 주변기기, 예를들어 CD-ROM, HDD등은 솔라리스 8이 지원하는 하드웨어 목록에 나타나 있지 않은 제품이더라도 대부분 잘 인식되었다.

필자의 설치 사양은 다음과 같았다.
Intel Pentium III 550 CPU
Intel BX chipset을 탑재한 메인보드
2개의 128MB PC-100 Memory (삼성) (총 256MB)
Fujitsu 9GB IDE HDD
Fujitsu 9GB Ultra Wide-2 SCSI HDD (LVD방식)
Adaptec 2940 UW SCSI Card
ATI RAGE iiC AGP VGA Card
LG 40배속 CD-ROM 드라이브
Intel Pro 100 PCI Ethernet Card

올 봄 사무실에 새로 도입된 행정전산망 규격 PC에 SCSI 카드 및 HDD, 메모리를 추가하였고 랜카드는 교체한 것이다. 위 주변기기는 모두 정상적으로 인식되었다.

Solaris 8 인텔 플랫폼 설치를 위하여 권장하는 시스템의 최소사양은 다음과 같다.

- Intel Architecture (32-bit)플랫폼
- Disk 공간: 2.4 Gbyte
- 메모리: 64 Mbytes

참고로 CPU와 메모리를 변경하면서 오라클 데이타베이스 설치를 각각 진행해 본 적이 있다.

펜티엄 III 550 CPU와 128MB 메모리, 그리고 펜티엄 II 셀러론 366과 256MB 메모리. 과연 어떤 것이 시스템 운영 및 프로그램 설치에 더 유리할까? 답은 후자였다. CPU를 펜티엄 III에서 셀러론으로 격하(?)시킴과 동시에 메모리는 두 배로 늘려 준 편이 오히려 시스템 성능 향상 및 프로그램 설치시간을 단축해 주었다. 메모리의 중요성을 실감하는 순간이었다.

설치과정
필자는 솔라리스8을 웹서버 운영체제로 사용하고자 설치하였기에 두가지 운영체제를 한 대의 PC에 설치하는 Dual OS는 시도해보지 않았다. (솔라리스에서 제공하는 도움말에는 Dual booting system을 구성하는 방법도 나와있다.) 여기서는 솔라리스 한가지만을 처음 설치하는 것으로 설명을 국한한다.

솔라리스 8은 다음 그림처럼 Web Start Installation이라는 JAVA 기술을 이용한 그래픽 환경의 설치방식을 구현하고 있다. CD-ROM부팅을 통하여 솔라리스 커널을 구동시키며, 초기의 주변기기 검색 및 디스크 초기화 작업이 끝나면 곧바로 그래픽 환경에서 상세한 설치정보를 제공해준다. 설치하는 과정도 한국어를 선택하면 한글 메시지를 보며 진행할 수 있다.

이제 구체적인 설치과정에 들어가 보자. 설치는 아래 순번대로 진행하면 된다.

우선 PC를 CD-ROM에서 부팅가능토록 BIOS를 설정을 해둔다. 그후 Solaris 8 Installation CD를 통하여 시스템을 부팅하자.

Device configuration Assistant menu가 나온다. 운영체제가 PCI 버스 및 시스템에 설치된 주변기기를 검색하는 과정이다. F2를 눌러서 설치된 하드웨어를 스캔토록 한다. 드라이버 리스트를 구축하면서 하드웨어 검색이 빠른 속도로 진행될 것이다.

검색된 하드웨어 목록이 화면에 나타난다. 이화면을 주의깊게 살펴보자. 자신의 하드웨어 목록과 비교하여 누락된 것이 없는가를 살펴보자. 특히 Network카드는 꼭 살펴보자. 여기에 나와있지 않다면 그 주변기기는 인식되지 않은 것이다. 솔라리스가 인정하는 품목으로 하나 새로 장만토록 한다. 이상이 없으면 F2를 눌러서 계속 진행시키면 된다.

SOLARIS KERNEL이 들어있는 곳을 선택하는 메뉴가 나온다. source와 destination을 착각하여 하드 디스크를 선택하기도 한다. 그러나 여기서는 현재 부팅할 운영체제가 있는 곳을 선택하는 것이다. 아직 설치하기 전이므로 당연히 CDROM을 선택한다.

기본값, 즉 다른 옵션이 없는 부팅으로 솔라리스 커널을 부팅시키자. (설치후 솔라리스를 운영하다보면 상황에 따라 여러 가지 옵션으로 시스템을 부팅할 수 있다. 예를 들어, 갑작스런 정전으로 시스템이 다운된 이후 디스크 무결성 검사를 할 때에는 boot -s 옵션으로 single user로 부팅한다.) 이제 솔라리스 Web Start Installer가 구동되기 시작한다.

설치 언어 선택 : 여기서 Korean을 선택하면 설치과정이 우리말로 안내된다.

푸른 화면으로 바뀌며 다음 사항이 화면에 나타난다.

1-IDENTIFY PERIPHERAL DEVICE
2-IDENTIFY YOUR SYSTEM
3-IDENTIFY SOLARIS S/W
F2를 눌러서 계속 진행시킨다.

KMDCONFIG 메뉴가 등장한다. 여기서는 솔라리스가 현재 인식한 비디오 및 모니터 해상도, 키보드, 마우스타입을 보여주고 이를 확인 및 수정하는 곳이다. 만일 자신의 비디오카드 해상도를 좀더 고해상도로 조절하려 한다면 여기서 해당항목을 선택후 수정해주면 된다.

원하는 대로 수정을 마쳤거나 자신의 시스템과 비교하여 맞다고 판단되면 NO CHANGE NEEDED를 선택한다.

이제 위에 설정한 비디오 해상도가 맞는가를 테스트하는 윈도우 화면이 나온다. 윈도우 화면이 뜨면서 여러 가지 색상과 함께 메시지가 나오면 OK를 눌러준다. (8번과정에서 하드웨어의 한계치를 초과하는 고해상도 설정을 하였을 경우, 화면에 아무것도 나타나지 않을 수도 있거나 # 프롬프트만 나올 것이다.)

** 설치도중 이상이 생겨서 콘솔모드로 전환되면서 # 프롬프트만 껌벅일 때가 있다. 이때는 이상의 원인이 무엇인가를 파악한 이후 'init 6' 명령어를 수행시키면 시스템이 리부팅된다. 이후 설치를 다시 시작할 수 있다.

솔라리스 오픈 윈도우화면으로 전환된다. 솔라리스 2.x 사용자들은 반가울 것이다.

설치프로그램을 넣을 위치를 하드디스크에서 찾게 된다. (하드디스크에 리눅스등 다른 운영체제가 설치되어 있어서 부트섹터를 점거하고 있다면 설치할 공간을 찾을 수 없다는 메시지와 함께 명령어 모드로 전환되면서 설치가 중단될 것이다. 이때 역시 init 6 명령어로 시스템을 리부팅시킨후 하드디스크에 설치된 이전 운영체제를 말끔히 제거해준다. 이후 설치를 다시 시도하면 된다)

FDISK 실행여부를 묻는다. YES라고 하면 기존 데이터는 몽땅 삭제된다. 필자는 YES라고 하였다. 기존 데이터가 없었으므로...

SWAP FILE SIZE를 묻는다. 기본값 512 (MB)로 입력하면 된다.

교체조각을 시작부분에서 시작토록 함. 즉, 하드디스크 첫 번째 실린더부터 사용토록 한다는 것이다.

화면에 아래와 같이 디스크 정보가 나타난다.

필자의 화면 예.
디스크조각 : /dev/dsk/c1t15d0
크기 : 512 MB (스왑디스크 크기)
시작실린더 : 1

경고 : 디스크의 모든 정보가 지워집니다.

이후 설치할 파일이 아래와 같은 메시지를 계속 나타내며 복사된다.

설치중 메시지 : 미니 루트를 지역 디스크에 복사중.
플랫폼 사양 복사중.

파일 복사가 끝나면 '재시동후 설치를 계속할 준비중입니다' 라는 메시지 나타난다. 부트매체를 제거하고 ENTER키를 누르십시오.라는 메시지가 나오면 ENTER키를 누른다.

잠시후 시스템이 자동으로 리부팅되면 임무를 완수한 Installation CD-ROM을 꺼내준 후 하드디스크로 부팅되도록 BIOS를 바꿔주자.

SOLARIS WEB START INSTALLATION이 다시 진행된다.

화면에 다음 메시지가 나온다.
Configuring devices..
Configuring /dev and /devices
Using RPC Bootparams for network configuration information. ( 네트웍 환경 검색)

화면이 그래픽 환경으로 바뀌면서 환영메시지와 시스템정보모음 박스가 나오면 '다음'을 선택한다.

네트워크 연결 옵션박스가 나타난다. 가정에서 사용하지 않는 이상 대부분 솔라리스 사용자들은 네트워크 사용자들일 것이다. => '네트워크로 연결' 선택

DHCP 사용 => 고정 IP를 사용하면 '아니오'를 선택한다. 그러나 DHCP사용자라면 당연히 '예'를 선택.

HOST 이름 입력 : 네트워크상에서 자신의 서버를 식별할 수 있는 고유 서버명칭을 입력한다. (예. deskpia)

ip address : 설치할 서버가 사용할 고유 ip address를 입력한다.

net mask : 대부분 255.255.255.0라 생각되는데...

ipv6사용여부 문의 => 자신이 ipv6 사용자라면 '예', 아니면 '아니오'

이름 서비스 : DNS 설정부분이다. 여기서 설정이 안되는 경우가 자주 발생한다. ('이름서버가 잘못되었다' 는등 이해할 수 없는 메시지가 나올 것이다) 이름서비스 항목에서는 '없음'을 선택한후 다음으로 넘어간다. 그렇다면 웹 서비스를 포기하는 것인가? 아니다. 기본 설치를 마친후 네트워크 부분을 다시 설정해줄 것이기에 아무 문제가 없다.

지리적 영역 : 자신이 살고 있는 지역을 선택하면 된다.

루트 계정으로 사용할 암호를 입력한다.

프록시 서버 구성 -> '인터넷 직접 연결' 혹은 자신이 사용하는 프록시 서버 정보 입력.

정보확인 => 이제껏 설정한 값이 화면에 나타난다. '확인'을 누른후 시스템을 설정값으로 구성하는 동안 잠시 기다리면 된다.

화면에 솔라리스 로고가 뜨고난 후 환영메시지박스가 다음처럼 예쁜 모습으로 나타난다.

운영체제 환경 소프트웨어 설치에 들어간다. solaris 1of 2 CD를 삽입해달라는 요청 메시지가 나오면 넣어주면 된다. CD 삽입후 enter(주의 : 착각하여 1of2 대신 2 of 2를 넣을 경우, 설치를 처음부터 다시해야 하는 불상사가 발생한다고 한다.)

시스템 초기화가 다음 그림처럼 진행된다. 그후 설치유형을 묻는다. -> 처음 솔라리스를 설치하는 경우라면 '기본선택'을 선택하자.(사용자 설치를 선택하면 디스크 구성등 세부적인 사항을 자신의 시스템에 맞게 구성할 수 있다)

설치공간 확인후 설치될 소프트웨어 정보가 나타난다. '지금설치'를 선택한다.

이제 할 일은... 맛있게 식사하러 갔다 오거나 옆방에 가서 커피를 한잔 하며 잠시 휴식을 취한다. 어떤 것들이 설치될까 하고 궁금하신 분은 지켜보고 계셔도 된다. 인내심을 가지고. (필자의 시스템으로 대략 25분남짓 걸렸다)

이후부터는 설치화면에서 요구하는대로 2 of 2 CD, Language CD, Documentation CD를 차례로 넣어주면 된다.

주의사항 : Documentation CD는 ASIA판과 EUROPE판 두 가지가 있다. 유럽판이 필요한 분은 설치하면 되고 그렇지 않으면 건너뛰어서 아시아판만을 설치하면 된다.

기본 선택 옵션으로 설치를 마치고 나면 뭔가 빠진 느낌이 들게된다. 제공된 CD중 보너스팩(Star Office, Companion CD등)을 설치하는 과정이 없기 때문이다. 이건 언제 설치해야 하는가. 기본 설치가 끝나면 아무때고 아주 간단하게 설치할 수 있다. (이에 관한 내용은 따로 설명한다)

Chapter 시작 (로그인)
위에 설명한 내용대로 제대로 설치가 되었다면 Rebooting후 login을 해보자. 솔라리스 특유의 아름다운 초기화면을 감상할 수 있다. 혹시 login하는 방법을 모르는 분이 계시는가? 시스템이 재부팅되면 다음 메시지 상자가 나타난다.

리눅스 사용자라면 입력해야할 정답을 금방 알 수 있다. 그러나 윈도우 환경에만 익숙한 이들의 경우 이곳에다 열심히 자기 이름이나 별명, 심지어 PC통신 ID까지 입력하기도 한다. 그러나 소용이 없다. 리눅스와 마찬가지로 처음 LOGIN시 사용자 이름은 단 하나. 바로 'root'이다. 그리고 암호는 설치시 지정한 암호를 입력하면 된다.

만일, 너무 정신없이 설치하다보니 암호를 잊었다면.... 다른 방법도 있지만 솔라리스에 처음 입문한 분들은 처음부터 다시 설치하는 것이 오히려 수월할 것이다.

login 전에 옵션을 선택할 수 있는데 이중 세션 항목에서 '공통 데스크탑 환경(Common Desktop Environment)'과 'Open Windows Desktop '을 선택할 수 있게 되어있다. Sun에서는 Solaris 8 이후의 플랫폼부터는 Open Windows 데스크탑 환경을 더 이상 지원하지 않는다고 한다.

가능한 한 공통데스크탑 환경에 익숙해지도록 하자. 공통 데스크탑 환경은 마치 윈도우 9x를 사용하는 듯한 기분이 들 정도로 메뉴구성이 세심하게 되어있다.

사용언어 선택도 이곳 옵션항목에서 간단히 지정할 수 있다. 한번 지정하면 다시 바꿔주지 않는 한 계속 환경이 유지된다.

Network 설정을 위한 기본 메뉴 이해
화려한 공통 데스크탑 환경에 들어왔는가? 화면에서 이것 저것 클릭해보며 처음 대하는 OS와 친숙해지려고 할 것이다. 그러나 아직 때가 이르다. 서버 본연의 기능을 수행하기 위한 기본조건이자 아주 중요한 대목인 네트웍 설정을 마치지 않았기 때문이다.

네트워크 설정을 마무리하기 전까지는 솔라리스와의 감격적인 만남을 잠시 뒤로 미루자. 이것이 없이는 하다못해 웹 브라우저 하나 제대로 띄울 수 없기 때문이다.

리눅서들의 경우, 네트웍 설정이라면 우선 Control Panel부터 찾을 것이다. 그러나 솔라리스는 리눅스처럼 Control Panel이 있는 것이 아니라 필요한 파일을 하나 하나 찾아서 수정하거나 만들어가며 세심하게 지정해주어야 한다.

솔라리스가 네트웍 카드를 인식하고 있다면 아래 명시된 파일들을 찾아서 에디터를 이용하여 다음 내용대로 파일을 수정하거나 추가해준다. 어떤 방법으로 파일을 수정하거나 만들어야 할까?

이를 위하여 솔라리스의 가장 기본적인 사항을 몇가지 이해하고 넘어가자.

콘 솔
화면 아래쪽에 아이콘들이 정렬된 메뉴바가 보인다. 오른쪽 하단의 cpu disk라고 되어있는 버튼을 누르면 그림과 같이 호스트 메뉴가 보인다. 여기서 콘솔을 선택하면 된다. 이것은 리눅스로 치자면 터미널 기능이다. 이 콘솔화면상에서 시스템 운영에 필요한 모든 Unix 명령을 내릴 수 있다. 루트로 로긴하면 화면에는 명령어 입력을 받아들일 준비가 되었다는 prompt로서 #표시가 나타난다. 유닉스 계열 환경에 익숙한 이들은 금방 친숙해질 수 있다.

파일관리자
솔라리스는 Windows 계열 운영체제처럼 아주 편리한 기능의 파일관리자를 제공한다. 마우스의 오른쪽 버튼을 누르면 메뉴바가 나타나는데 여기서 파일을 선택하면 된다.

파일관리자 기능으로는 마우스 클릭만으로 원하는 디렉토리로의 이동은 물론, 파일의 복사, 삭제, 이동 및 파일의 속성까지도 변경시킬 수 있다. 전통적으로 유닉스 시스템에서 파일의 속성이나 소유자를 변경하려면 chmod나 chown 명령을 사용해왔다. 그러나 파일관리자를 이용하면 개별 파일의 속성 및 소유자도 마우스 오른쪽버튼 클릭 및 간단한 키보드 입력으로 변경할 수 있다.

텍스트 에디터
Windows 계열 운영체제의 노트패드를 연상케 하는 유틸리티이다. vi처럼 명령어를 일일이 외우지 않고도 아주 편하게 사용할 수 있는 에디터이다. 텍스트 파일을 새로이 생성하려면 텍스트에디터에서 내용을 입력 후 원하는 디렉토리에 새로운 파일명을 주어 저장하면 된다.

이제 네트워크 설정에 들어간다.

가. 파일관리자를 이용하거나 cd 명령어를 통하여 etc 디렉토리로 가보자. 아래 설명하는 파일들은 모두 etc 디렉토리안에 있는 파일들이다.

hostname.xxx : 디렉토리 안에 hostname.xxx(인텔 Pro100의 경우, hostname.ibrb0 라고 되어있다) 라는 파일이 생성되어 있을 것이다. 여기서 파일 확장자 xxx는 자신의 네트웍 카드의 종류에 따라 다른 이름이 붙게 된다. 이 파일을 열어서 자신의 ip address를 입력한다. (예. 203.242.219.16) 이곳에 ip address가 아닌 도메인 명을 입력하면 안된다.

** 아무리 살펴보아도 hotsname.xxx라는 파일이 보이지 않는다면... 네트워크 카드가 제대로 인식되지 아니한 것이다. 방법은 카드를 교체하는 것외에는 없다.

nodename : 솔라리스가 설치된 시스템의 고유 호스트 name(예. deskpia)을 입력한다.

netmasks 설정(맨끝줄이 아래와 같이 되어있나 확인한다)

예 : 203.242.219.16 (자신의 ip) 255.255.255.0 (netmask)

hosts : 아래와 같은 예로 설정해준다.

(순서 설명 : ip address, domain name, server name 그리고 loghost 순이다.)

defaultrouter : 자신의 서버가 속한 네트워크의 GATEWAY를 설정해준다.

예 : 203.242.219.254 (자신의 gateway 설정)

resolv.conf : 자신의 도메인 및 네임서버를 설정해준다.

nsswitch.conf : 'dns'라는 단어를 해당 라인에 추가해준다.

hosts: files dns <- 이것(dns)을 추가함.
이것으로 네트워크 사용을 위한 모든 설정을 끝마쳤다. 시스템을 리부팅해 주면 이제껏 설정된 값이 그대로 적용되어 서버로서의 활동을 시작한다. 그러나 아직 한가지가 더 남아있다.
전세계 리눅서들의 사랑을 한몸에 받고 있는 웹서버, 바로 아파치 웹서버 최신버전인 1.3.9가 솔라리스 8에서 기본적으로 제공되어 이미 여러분의 시스템에 설치가 되어 있을 것이다.
이것까지 설정을 마쳐보자. 리눅서라면 웃음을 띄워가며 간단히 설정을 끝낼 것이다. 왜, 아파치는 설정이 모두 똑같으므로.

나. Apache webserver 설정

아파치 서버의 환경을 설정해주는 파일은 httpd.conf파일은 etc/apache/ 에 있다. etc/apache/httpd.conf 파일을 열어서 해당사항을 수정해준다.

아파치 웹서버는 솔라리스 부팅과 함께 자동으로 구동되도록 설정되어 있다.

아파치 웹서버까지 설정이 끝났으면 이제껏 설정된 값을 시스템에 반영시키자.

그후 system을 rebooting해준다. (console에서 root 권한으로 init 6 명령을 내린다.)

기타 유틸리티 설치
네트워크 설정까지 마무리된 상태에서 리부팅을 하면 솔라리스는 비로소 제 모습을 드러낸다. 공통 데스크탑 환경으로 들어왔으면 아직 설치하지 않은 보너스 팩 CD를 한번 설치해보도록 한다.

먼저 COMPANION CD를 드라이브에 삽입해보자. CD를 읽는 소리가 나면서 잠시후 화면에는 파일관리자가 저절로 나타나 있을 것이다. 파일관리자 화면에는 COMPANION CD의 최상위 디렉토리가 보인다. 여기서 installer 파일을 click하면 곧바로 설치마법사에 의해 설치가 진행된다.

(Companion CD에는 Intel용과 Sparc용 프로그램 두 가지가 함께 들어있다.그러나 설치마법사가 시스템에 맞추어 알아서 올바른 것을 설치해줄 것이다)

잠시후 설치될 프로그램의 목록이 화면에 나타난다. 이중 필요없다고 생각되는 유틸리티가 있으면 마우스를 클릭하여 표시를 지워주면 된다.

스타 오피스 5.1 설치방법도 편리하다. CD를 삽입하면 여러개의 디렉토리가 보인다. 이중 선택해야 할 곳은 /English/Solarisi/Office51/에 있는 Setup 파일이다.(위에서 언급하였지만 스타 오피스는 아직 한글버전이 없다. 제공된 CD에는 영문이외에 프랑스, 독일, 이탈리어, 포르투갈어판이 함께 있다) Setup 파일을 click하면 설치가 진행된다.

오라클 엔터프라이즈 8i는 조금 까다로운 설치방법을 요구한다. 이에 관하여는 기회가 되면 따로이 설명하겠다.

제대로 된 첫 만남
CDE 화면을 바라보자. 하단에 예쁜 그래픽 아이콘들이 자신을 선택해주기만 학수고대하는 모습이 보일 것이다. 하나 하나 마우스로 클릭해보면 금방 기능을 알 수 있다. 스타오피스 5.1을 추가설치하면 하단 메뉴에 스타오피스를 바로 실행할 수 있는 또 하나의 아이콘이 생성된다.

화면상에서 마우스 오른쪽 버튼을 누르면 솔라리스 데스크탑에서 사용할 수 있는 팝업 메뉴가 나타난다.

솔라리스 8의 사용을 위한 기본 유틸리티중 가장 처음 다루어야 할 유틸리티가 바로 관리도구 (Admintool)이다. 신규 사용자 및 그룹을 여기서 추가, 수정, 삭제할 수 있다. 프린터 설정, 신규 프로그램 추가도 여기서 할 수 있다.

리눅스와 윈도우 환경에 익숙한 이들이라면 솔라리스의 CDE화면과도 금방 친숙해 질 수 있다. 필자는 현재 솔라리스 8 운영체제와 아파치 서버로 개인 웹 서버를 운영중이다. 아파치의 성능이야 이미 공인된 것이고, 솔라리스 8 역시 아직까지 아무탈없이 본연의 임무를 수행해주고 있다. 서버를 운영하면서 동시에 콘솔모드에서 여러 작업을 진행하여도 불만없이 버텨주는 것을 보면, 그간 들인 공이 아깝지 않다는 생각이다.

Chapter 새로운 하드웨어 추가
Solaris 8에서 새로운 디스크 추가
열심히 시스템을 운영하며 이것 저것 설치하다보면 디스크 남은 용량이 얼마 남지 않았음을 깨닫게 된다. 해서 새로이 디스크를 장만하여 시스템에 추가하고 싶을 때...

이번에는 IDE 방식의 디스크를 사용하던 사용자가 시스템에 SCSI방식의 디스크를 추가하는 것을 예로 들어본다.

하드디스크와 SCSI 컨트롤러 선택 : 이제껏 여러종류의 하드디스크 (삼성, IBM, 후지쓰, 퀀텀)를 사용하여 왔으나 Solaris에서 문제가 발생한 경우는 없었다. 아래 설치방법은 ADAPTEC 2940 UW SCSI Card 및 후지쓰 UW2(LVD방식) 하드디스크 (용량 8.37GB)를 사용한 예이다.

시스템을 정지시키고 새로운 SCSI 콘트롤러 카드 및 디스크를 장착한다.

시스템을 켠후 (필요하다면 SCSI BIOS SETUP을 통하여 디스크를 설정해 준 기존에 Solaris 시스템이 설치된 디스크를 Primary Boot Disk로 설정해준다. 기존 시스템에 하나의 디스크만 장착되어 있었다면 기존 디스크는 C, 추가된 SCSI 디스크는 D로 설정되어 부팅될 것이다.

Solaris가 구동되면서 '새로운 하드웨어를 추가하였으면 Esc키를 누르라'는 메시지가 나올 것이다. 이때 Esc키를 누르면 새로 장착된 SCSI 카드를 검색한다. 이후 부트소스는 기존의 하드디스크를 선택하여 부팅한다.

부팅 옵션 화면이 나온다. 새로 설치된 디스크를 시스템에 인식시켜 주어야 하므로 다음 옵션으로 부팅한다.

root로 login후, 혹은 일반사용자로 로긴하여 su 권한을 가진후, 콘솔화면에서 format 명령을 실행한다.

format 유틸리티는 시스템 관리자가 디스크를 각각의 slice로 나눌 수 있도록 해주는 기능도 갖고 있다. 명령을 실행하면 현재 디스크에 설치된 디스크가 각각 0번부터 선택될 수 있도록 아래와 같이 나타날 것이다. 여기서 새로 설치한 디스크의 번호를 선택한 후 enter를 친다.

아래 예는 기존 IDE 하드디스크(0번)와 새로 추가된 SCSI 하드디스크(1번)을 보여주는 예이다.

위에서 나타나는 c0d0 혹은 c2t15d0와 같은 디스크의 device name을 잘 기억해두자.

** 처음 Solaris 시스템에 사용코자 하는 디스크라면 우리가 일반적으로 알고 있는 디스크 포맷 과정을 거쳐야 한다. 디스크 초기화를 위한 포맷을 하려면 format > 프롬트에서 다시 format 명령어를 실행하면 된다. 그러면 디스크에 있는 모든 정보가 깨끗이 지워지면서 Solaris에서 사용가능한 포맷이 된다.

** 잘 아는 내용이겠지만 Solaris가 설치된 시스템 디스크를 포맷하는 일은 없도록 해야 한다.

포맷전에 해야할 일... 바로 fdisk이다. 새로 설치한 디스크가 이전에 windows 98 혹은 linux등 다른 OS환경에서 사용하던 것이라면 Solaris에서 사용하기 위한 디스크로 변환시키는 과정이 fdisk이다.

여기서는 새로 설치한 디스크 전체를 Solaris 시스템으로 변환하는 과정을 다룬다. 다음 순서로 진행해보자.

다시 format> 프롬트 상태로 돌아왔다. 이제는 Solaris 시스템으로 사용할 수 있도록 준비된 디스크를 깨끗이 포맷하는 일이 남아있다.

선택한 디스크의 format> 프롬트가 다시 화면에 나타나면 partition 이라고 입력후 enter

prompt가 partition>으로 변경되면 print 명령을 주어서 현재의 디스크 상태 및 용량을 확인해 본다.

위 디스크 상태를 보면 2번 part가 전체 디스크의 용량을 보여 주며, 전체 디스크 용량은 8.37GB이고 10327개의 cylinder를 가지고 있음을 알수 있다

**중간에 적힌 wm, wu등은 다음 의미를 가지고 있다.

wm : writable and mountable
wu : writable and unmountable
rm : read only and mountable

사용할 slice(part)와 각 slice에 할당할 디스크 사이즈를 결정하고 아래와 같이 선택을 한다.

전체 디스크 용량을 2개의 slice로 나누고 4과 5번 slice를 사용하고자 할때;

** 다음의 예는 총 8.37 GB의 SCSI 하드디스크를 각각 4.07 GB, 4.31 GB로 나눈 것이다. 실린더의 수를 입력한 부분을 주의깊게 살펴보자.

partition 이 끝나면 label 명령을 입력한다. .

label 작업을 계속 할 것인지를 물어 보면 "yes" 라고 치고 label 작업이 다 끝나면 "quit" 을 2번 쳐서 format 프롬트에서 빠져 나온다.

아래와 같이 newfs를 실행하여 UNIX filesystem을 새 디스크의 각 slice에 만든다

** c#t#d#s#" 번호 명명법
c#t#d# : format명령을 주었을 때 자동으로 시스템에서 주어진 값을 사용하면 된다.
s# : 새 디스크의 각 slice에 해당하는 디바이스 이름을 쓴다.

위의 예에서 사용된 필자의 하드디스크 경우는 c2t15d0s4와 c2t15d0s5가 되었다. (새 디스크가 coltroller 2에 연결되어 있고 targer 번호 15을 사용하고 있다)

newfs 작업이 끝나면 새 filesystem을 mount하여 사용한다. 마운트하는 방법은 /etc/vfstab파일에 새로운 디스크의 정보를 아래와 같이 적어주는 것이다.

그후 반드시 mount명령을 내려주어야 한다.

이후 시스템을 rebooting시키면 새로 생성된 디스크가 자동 mount될 것이다. 새로 생성된 디스크가 제대로 마운트되어 있는지를 알아보려면

이렇게 명령해주면 좌악 나온다.

** 새로 설치한 디스크를 항상 마운트시키지 않고 필요할 때마다 마운트시켜서 사용하려면 다음 명령어를 이용하면 된다.

Solaris 8에서 DVD-ROM Drive 추가
솔라리스에서 DVD-ROM Drive를 장착할 수는 없을까 ? 결론은 가능하다는 것이다.

DVD 파일포맷은 국제 산업규격인 UDF file system을 사용한다. 솔라리스에서는 DVD에서 사용하는 UDF 파일 포맷을 access할 수 있다. 그러나 UDF file format이 아닌 DVD-RAM이나 UFS components등은 인식하지 못한다.

UDF 파일 시스템을 솔라리스에서 사용하려면 Solaris 7 (99년 11월 버전) 혹은 Solaris 8이 필요하다. (스팍버전이나 인텔 버전 둘다 가능함)

아래 방법은 DVD-ROM Drive를 장착하는 순서이다. 매우 간단함.

1. su 권한을 가진후, 콘솔화면에서 /reconfigure 파일 생성.
# touch /reconfigure

2. 시스템을 셧다운 시킨후 전원을 내린다.
# init 0

3. DVD-ROM Drive를 시스템에 설치한다.

4. Solaris가 구동되면서 '새로운 하드웨어를 추가하였으면 Esc키를 누르라'는 메시지가 나올 것이다. 이때 Esc키를 누르면 새로 장착된 DVD-ROM Drive를 검색한다. 이후 부트소스는 기존의 하드디스크를 선택하여 부팅한다.

5. 부팅 옵션 화면이 나온다. 새로 설치된 디스크를 시스템에 인식시켜 주어야 하므로 다음 옵션으로 부팅한다.
b -r ( r 이 옵션값 )

6. 로긴한다.

7. DVD-ROM device가 제대로 mount되었는지를 확인해보자.
$ ls /cdrom

** 만일 시스템에 이미 CD-ROM Drive가 설치되어 있다면 기존 CD-ROM Drive는 /cdrom/cdrom0 로 나타나고 DVD-ROM Drive는 /cdrom/cdrom1 으로 나타난다.
시스템에 DVD-ROM밖에 없다면 ? DVD-ROM Drive는 /cdrom/cdrom0로 나타난다.

8. DVD-ROM에 디스크를 넣고 내용을 확인해보자.
$ ls /cdrom/cdrom1

디스크의 내용이 화면에 나타났다면 성공적으로 설치를 마친 것이다.

다음은 UDF FILE system 의 기본적인 사용방법이다.

1) UDF 파일 시스템 파라메터를 보거나 생성.
# mkfs -F udfs -m /dev/rdsk/device-name
(device-name은 /cdrom/cdrom1 혹은 /cdrom/cdrom0등 시스템에 따라 다르다)

2) UDF 파일 시스템을 마운트
# mount -F udfs /dev/dsk/device-name /mount-point

# ls /mount-point (제대로 마운트되었나 확인)

3) UDF 파일 시스템으로 되어있는가를 구분하려면
# fstyp -v /rdev/dsk/device-name

4) UDF 파일 시스템의 integrity등을 점검
# fsck -F udfs /dev/rdsk/device-name

Chapter Solaris 8용 GNU
gcc compiler 2.95.2
개척정신이 강한 대부분의 솔라리스 유저들은 기본적으로 시스템에 설치된 사양에 만족하지 않는 것이 공통점이다.

새로운 것이 나오면 한번쯤 시스템에 설치해보아야만 직성이 풀린다. DB, Webserver등 많은 것들의 소스파일, 혹은 Binary file을 다운받아 시스템에 설치해본후 사용을 해보아야 잠이 오는 사용자들... 바로 매니아들이다.

이때 꼬옥 필요한 것이 바로 컴파일러.. 리눅스 운영체제에서도 명성을 날렸던 gcc compiler는 솔라리스 운영체제에서도 그 명맥을 계속 이어간다.

솔라리스 8 에서 제공하는 companion CD를 설치하면 함께 설치되는 것이 인텔 플랫폼에서 사용할 수 있는 gcc 컴파일러 2.95.2버전이다. 그런데 실제 사용할때 많은 문제점을 경험하게 되는데 그 이유는 설치되는 디렉토리 때문이다.

컴퍼니언 CD에 들어있는 대부분의 프로그램들이 설치되는 곳은 opt/sfw/bin이라는 아주 후미진 곳에 위치한다. 예를 들어 설치를 모두 마친후에 which gcc 해보면 못찾겠다는 메시지만을 보게된다. 왜냐하면 PATH에 /opt/sfw/bin을 지정해놓지 않았을테니까.

이래 저래, 문제점을 경험하신분들은 다음과 같이 GCC Compiler를 한번 자신의 구미에 맞게 재설치해보자.

먼저 다음 링크를 클릭하여 파일을 다운받는다.

ftp://ftp.sunfreeware.com/pub/freeware/intel/8/setup_sfw_gcc_2952x.class

자신의 네트웍 상황에 따라 다르겠지만 크기가 17MB에 달하므로 인내심을 가져야 한다.

다운을 받은 분은 다음 사항에 따라 설치를 하면 된다. 모든 사항은 루트계정으로 실행하여야 한다.

** 주의 : 시스템에 이미 gcc compiler가 설치되어 있다면 본 프로그램을 설치하기에 앞서서 admintool을 이용하여 기존의 설치된 것을 제거하여 주어야 하는 것이 필수.

1) 프로그램을 다운받은 디렉토리로 간다.

2) 다음과 같이 자바를 실행한다.
java setup_sfw_gcc_2952s(주의 : 확장자명 .class는 입력하지 않음)

3) 자바 인스톨러가 실행되면 사용자 설치를 선택.

4) 설치디렉토리를 정한다. 필자의 경우는 /usr를 선택하였음.

이경우 컴파일러 실행파일은 /usr/bin에, 문서파일은 /usr/document에 각각 설치된다.

이제는 따로 path를 지정하지 않아도 compiler를 error없이 실행할 수 있다. 정말 간단하지 아니한가.

이렇게 쉽게 설치한 gcc compiler는 지우기도 쉽다. 다음 방법으로 하면 간단히 제거된다.

1) 컴파일러 설치 디렉토리로 간다. (위의 경우 /usr)

2) 다음 java명령어를 입력한다.

java uninstall_GCC_Compiler_Collection_2_95_2

3) 자바 언인스톨러가 나오면 화면지시에 따라 프로그램을 제거한다.

Chapter 웹서버구축하기
(아파치+PHP+mysql 받기)
본 문서는 아파치+PHP+mysql을 연동하고자 하는 일반 사용자와 시스템 관리자를 위한 설치와 적용에 대한 요약이다.
아래는 설치하고자 하는 소프트웨어의 버전과 시스템 사양이다.

시스템 사양 : Solaris 8 Intel Version or LINUX
mysql Ver 3.22.32
apache Ver 1.3.12
php Ver 4.0.2

본 문서에서는 Solaris 8을 기준으로 설명하겠지만 특별히 LINUX에 관련되어 차이를 보이는 부분에 대해서는 부연 설명을 하겠다.

프로그램 다운 받기.
설치 전에 필요한 소프트웨어의 소스 패키지를 아래 URL에서 다운 받아 놓자.

http://www.mysql.com/Downloads/MySQL-3.22/mysql-3.22.32.tar.gz
http://www.apache.org/dist/apache-1.3.12.tar.gz
http://www.php.net/

mysql 설치
mysql 컴파일 및 인스톨
GNU tar를 사용하여 소스 패키지를 디렉토리에 풀자 이때, GNU tar가 설치되지않은 시스템에서는 gunzip과 tar를 사용하면 되겠다.

$ tar xvzf mysql-3.22.32.tar.gz

특별히 다른 옵션을 주지 않고 소스 패키지를 풀었다면 풀린 디렉토리 이름은 다음과 같은 이름을 가질 것이다.

mysql-3.22.32

먼저 mysql의 소스 디렉토리로 이동한다.

mysql이 설치될 디렉토리를 지정하여 컴파일 한다.
mysql은 버전마다 조금씩 에러가 발생하는 파일의 위치가 조금씩 차이가 나지만 대부분의 경우 mysql.cc에서 include 하는 헤더파일의 위치를 지정해주면 대부분 해결된다.
Solaris 8 intel 의 경우 make 시 에러가 발생하는 파일을 다음과 같이 수정하자.

문제의 파일 : /SRC/mysql-3.22.32/client/mysql.cc
#include 을 #include /opt/sfw/include/term.h"로 수정.

Solaris의 경우 Companion CD까지 모두 인스톨되어 있어야 한다 그러나 리눅스의 경우엔 에러 없이 컴파일 되므로 위의 과정은 생략한다.

mysql이 설치될 디렉토리는 "/usr/local/mysql"이다. 아래 옵션을 적용하여 compile 환경을 설정해 주고 컴파일한다.

에러 없이 컴파일이 되었다면 다음 섹션으로 넘어간다. 만일 에러가 발견되었으면 에러를 수정하고 다시 위 과정을 반복한다.

mysql 테스트
앞 절에서 mysql이 설치하였으면 이젠 mysql 소프트웨어가 제공하는 스크립트를 수행하여 최초의 database를 생성해야 한다.
먼저 mysql 설치 디렉토리로 이동하자. 스크립트가 상대 디렉토리 패스를 사용하기 때문에 반드시 이동해야 한다 (..과 같은)

이동하였으면 이제 기본 데이터 베이스를 설치하는 스크립트를 수행한다.

mysql daemon을 시작한다.

daemon이 수행되었는지 확인한다.

mysql의 관리자 패스워드를 변경한다. 이 패스워드는 시스템의 root가 사용하는 패스워드와는 다르다. 이 패스워드는 mysql 데이터 베이스에 저장되어 mysql만 인식할 수 있는 것이다. 그러므로 보안을 위해 가능하다면 시스템의 login 패스워드와는 다르게 지정한다.

new-password에 새로운 패스워드를 입력한다. 패스워드가 1234라면 다음과 같이 하면 되겠다.

이제 mysql 서버 접속하여 스크립트가 생성한 DB가 잘 동작하는지 다음과 같이 테스트를 수행하자.

테스트가 성공적으로 수행되었으면 mysql daemon의 실행을 중지해 보자.

mysql 사용자 및 DB 설정
새로운 데이터 베이스 생성과 사용자 추가 및 데이터 베이스를 사용자에게 할당.

이 절에서는 webdb_yjchu라는 새로운 데이터 베이스를 생성하고 yjchu라는 새로운 사용자를 생성하여 새로 생성한 데이터 베이스를 할당해 주도록 하겠다.

먼저 앞 절에서 중지시킨 mysql daemon을 시작하고 mysql 데이터 베이스에 root로 로그인한다.

먼저 현재까지 등록된 database를 보자.

새로운 데이터 베이스 생성, 데이터 베이스 이름은 "webdb_yjchu"로 한다.

이제는 사용자 데이터 베이스 테이블(user)에 새로운 사용자 추가 및 패스워드를 할당한다.
새로운 사용자 login name : yjchu
새로운 사용자 password : yjchu

먼저 mysql 서버에 root로 로긴 하고 사용자들에 대한 정보를 갖고 있는 mysql 데이터 베이스로 이동하였다. 그런 다음 우리가 추가하고 싶은 데이터 베이스 사용자를 추가해 주었다. 마지막은 사용자가 추가되었는지 확인한 것이다.

위에서 설정한 정보를 전체 데이터 베이스 시스템에 반영한다, 새로운 설정을 한 후 반드시 해주도록 한다.

특정 사용자(yjchu)에게 데이터 베이스(web_yjchu)에 대한 권한을 설정해 준다.

mysql 테이터 베이스 시스템의 데이터 베이스에 대한 정보를 갖는 테이블 db에 새로 생성한 데이터 베이스(webdb_yjchu)를 사용자(yjchu)에게 할당해주고 권한을 할당해주자.

이제는 새로운 사용자(yjchu)와 할당된 데이터 베이스(webdb_yjchu)를 사용하여 간단한 테이블을 만들고 값을 입력해 보겠다.

위와 같이하여 새로운 사용자(yjchu)에게 새로운 데이터 베이스(webdb_yjchu)와 패스워드 그리고 데이터 베이스에 대한 권한을 부여해 주었다.

자세한 설명이 부족하지만 위의 과정을 그대로 해도 mysql에 사용자를 추가하고 새로운 데이터 베이스를 등록 관리하는데에는 무리가 없을 것이다.

이제 다음절에서는 설치된 mysql과 php+apache를 연동하여 설치해 보겠다.

php 설치
php 설치 전 반드시 해야 할 일
php를 설치하기 전에 반드시 먼저 apache 소스 패키지를 다운 받아 시스템에 압축을 풀어놓고 약간의 작업(?)을 해야 한다. (꼭. 꼭. 꼬....옥) 왜냐하면 apache의 경우 컴파일 전에 컴파일 환경설정을 미리 해야 하기 때문이다.

GNU tar를 사용하여 소스 패키지를 디렉토리에 풀자 이때, GNU tar를 설치되지 않은 시스템에서는 gunzip과 tar를 사용하면 되겠다.

$ tar xvzf apache_1.3.12.tar.gz

특별한 옵션을 주지 않고 소스 패키지가 풀었다면 풀린 디렉토리 이름은 다음과 같은 이름을 가질 것이다.
apache_1.3.12

이제부터는 현재 디렉토리를 다음과 같이 하겠다.
/SRC/apache_1.3.12

먼저 apache의 소스 디렉토리로 이동하자.

$ cd apache_1.3.12$ pwd/SRC/apache_1.3.12

설치될 디렉토리를 지정하여 configure script 수행

$ ./configure --prefix=/usr/local/apache

여기까지 apache에 대한 php 설치전 준비는 끝났다. php 설치한 후 다시 이 디렉토리로 와서 나머지 컴파일 및 설치 과정을 수행하도록 하고 잠시 잊어 버리자.

php 설치하기
GNU tar를 사용하여 소스 패키지를 디렉토리에 풀자 이때, GNU tar가 설치되지 않은 시스템에서는 gunzip과 tar를 사용하면 되겠다.

$ tar xvzf php-4.0.2.tar.gz

특별한 옵션을 주지 않고 소스 패키지가 풀었다면 풀린 디렉토리 이름은 다음과 같은 이름을 가질 것이다.
php-4.0.2

이제부터는 현재 디렉토리를 다음과 같이 하겠다.
/SRC/php-4.0.2

먼저 php의 소스 디렉토리로 이동하자.

$ cd php-4.0.2$ pwd/SRC/php-4.0.2

이제 php를 컴파일하자.

configure의 옵션으로 주는 것이 매우 복잡하다. 중요한 것만 간단히 살펴보자.

--with-mysql=/usr/local/mysql : mysql의 설치된 디렉토리를 php에게 알려준다 이 부분은 나중에 php가 mysql을 접근하기 위해 꼭 필요하다.
--with-apache=/SRC/apache_1.3.12 : php가 apache의 모듈로 삽입될 것이기 때문에 이 라인은 반드시 필요하다. 모듈로 삽입되는 위치는 소스 파일들이 풀린 디렉토리 "/SRC/apache_1.3.12/src/module"에 php4라는 디렉토리가 새로 생성 되어 그 안에 파일로 존재하게 된다.
--with-config-file-path=/usr/local/apache/conf : 파일 php.ini 를 복사해 넣을 디렉토리를 지정하는 옵션이다. 여기 저기 설정 파일을 놓기 보다 한 곳에 위치하도록 하는 것이 좋을 것 같이 이렇게 지정했다 이 옵션을 사용하지 않으면 "/usr/local/lib"에 복사해 넣어야 한다.
--without-gd : gd 라이브러리를 사용하지 않도록 하는 옵션이다. Solaris의 경우 gd 라이브러리가 설치되어 있지 않거나 설치되어 있다고 해도 자꾸 에러가 나서 일부러 사용했다. LINUX에서는 사용하지 않아도 에러 없이 컴파일 할 수 있다.
나머지 옵션은 그냥 사용하든지 빼든지 사용자의 몫으로 남겨 놓겠다.

"make install" 하면 디렉토리 /usr/local에 약간의 파일이 생성되고 또한 위의 옵션 의 지정에 의해 apache의 소스 디렉토리의 서브 디렉토리(/SRC/apache_1.3.12/src/module/php4)에 모듈이 복사된다.

apache 설치
먼저 apache 소스 디렉토리로 이동한다.

$ cd /SRC/apache_1.3.12

apache 컴파일 및 인스톨

여기서는 apache의 DSO 기능을 사용하도록 컴파일하고 인스톨하겠다.

configure의 각 옵션의 설정은 다음과 같다.
--prefix=/usr/local/apache : apache가 설치될 디렉토리 지정
--activate-module=src/modules/php4/libphp4.a : php 모듈을 컴파일시키기 위한 옵션, 아파치 Version 1.2.X 대에서는 src 디렉토리의 Configuration 파일의 일부를 수정하여 모듈을 인식 시켰으나 1.3.X 대에서는 위의 옵션만 사용해도 가능하다.
--enable-shared=max : DSO를 적용하는 옵션, 최대한 모듈화를 시키기 위해 사용한다. 이 옵션을 사용하면 Shared library 파일이 생겨 나중에 다른 모듈의 업그레이드 시에도 소프트웨어를 유지 보수하기 편하다.

php 및 apache 설정
먼저 php 소스 디렉토리에 있는 php.ini 파일을 복사해온다.
$ cp /SRC/php-4.0.2/php.ini-dist /usr/local/apache/conf/php.ini

파일 httpd.conf 수정

다음 두 줄의 주석 제거

컴파일했더 서버가 acacia.sangmyung.ac.kr이었기 때문에 수정해 준 것이다. 만일 여러분의 시스템에서 컴파일 했다면 수정할 필요가 없을 것이다.

apache 시작 및 php 테스트
먼저 에디터를 사용하여 php용 테스트 파일을 만들자
$ cat /usr/local/apache/htdocs/test.php

단 한 줄이지만 시스템에 설치된 php에 관한 정보를 자세히 보여 주는 내용이다.

apache 데몬을 시작하자. apache는 시작 스크립트를 지원한다.

다음은 스크립트에 아무 옵션도 주지 않고 수행해 본 예이다.

apache 데몬 시작.
$ /usr/local/apache/bin/apachectl start

Solaris 8의 경우 위의 과정에서 특별히 주의할 사항을 기술해보면 다음과 같다.

1. 반드시 Companion CD를 설치해야한다.

2. 라이브러리 패스는 /usr/local/lib부터 시작하지 말아야 한다.
LD_LIBRARY_PATH=/opt/sfw/lib:/usr/openwin/lib:/usr/local/lib ()
LD_LIBRARY_PATH=/usr/local/lib:/opt/sfw/lib:/usr/openwin/lib ()

3. 실행 패스는 /usr/local부터 시작하지 말아야 한다.
PATH=.:/bin:/usr/bin:/usr/ucb:/sbin:/usr/sbin:/usr/ccs/bin:
/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin:/usr/local/bin ()

PATH=.:/usr/local/bin:/bin:/usr/bin:/usr/ucb:/sbin:/usr/sbin:/usr/ccs/bin:
/usr/dt/bin:/usr/openwin/bin:/opt/sfw/bin ()

4. 중간에 잘 안 된다 싶으면 뒤도 돌아보지 말고 php와 apache 소스 디렉토리를 지우고 4장(php 설치 전 반드시 해야할 일)부터 다시 시작한다.

참고 참고 문헌
[1] 장진호, PHP Web-DB Pogramming Guide, 동일 출판사
[2] http://www.phpschool.com/php_loveme
[3] http://www.apache.kr.net
[4] http://kldp.org
[5] 각 소스 패키지에 있는 INSTALL 파일
[6] http://kldp.org/KoreanDoc/html/ApacheMySQLPHP_Guide-KLDP/ApacheMySQLPHP_Guide-KLDP-9.html

Chapter Sun Solaris8
(intel 플랫폼)에서 Oracle 8i 설치
Sun 솔라리스 8 (intel 플랫폼)을 처음 받았을 때 함께 들어있는 Oracle 8i 데이터베이스 CD를 보노라면 웬지 뿌듯한 느낌을 받게 된다. 전세계 DB시작을 석권한 오라클에서 리눅스용에 이어 선 솔라리스 사용자들을 위한 제품까지 만들어서 서비스를 시작한 것이다. 사실 오라클 DB의 가격은 결코 만만치 않다. 선 엔터프라이즈용 오라클 DB의 가격을 아는 이들이라면 이렇게 운영체제와 함께 제공되는 오라클 CD에 대해 묘한 감정을 느낄 것이다.

동봉된 오라클 DB는 개발자용이다. 그러나 서버용 DB로도 훌륭히 수행된다.

한가지... 처음 DB를 다루는 분들께는 오라클 이외에 다른 제품을 권하고 싶다. 설치부터가 만만한 제품이 아니기 때문이다. 필자의 개인적 경험상 사용하기 무난한 제품으로는 MS의 MS-SQL Server 7.0을 권하고 싶다. 그러나 이미 어느정도 DB에 대한 지식을 쌓은 분이라면, 그래서 SQL문법에 능통한 분이라면 오라클은 결코 지나칠 수 없는 제품이리라.

작년 (1999년) 초, 리눅스용 오라클을 설치했을 때 몇시간을 헤매던 생각이 났다. 잡지에 나온 대로 설정을 시도했으나 몇 번의 실패끝에 결국은 나름대로의 방식대로 설정하여 겨우 DB가 startup 되는 모습을 볼 수 있었다. 이에 반해 NT용 오라클 서버는 그리 까다롭지 않은 설치방식을 제공한다. 운영체제에 따라 설치방식이 극과 극을 달리는 듯 하다.

사실 이번 솔라리스용 오라클 8i 역시 몇 번의 시행착오를 거친 끝에 설치를 할 수 있었다. 특히 환경변수 설정이 무엇보다 중요하다. 유닉스나 리눅스에 대한 기본 지식이 없이는 시도하지 말 것을 당부한다.

자 준비가 되었으면 설정에 들어간다. 아래 글은 읽는 이들이 어느정도 유닉스나 리눅스에 대하여 기본 지식이 있음을 전제로 작성하였다.

설치를 위한 기본 환경
   - 메모리 권장 : 128 MB 이상
   - HDD : 1 GB정도의 빈 공간.
   - CPU : Celeron 366 혹은 펜티엄 II 350 이상 .

위의 사양은 말 그대로 설치를 위한 최소사양이다. 위 내용중 메모리는 256MB를 장착하면 쾌적하게 오라클을 설치하여 사용할 수 있다. 128MB와 256MB의 차이점은 오라클 설치에 필요한 소요시간에서도 명확히 나타난다.

ROOT 권한하에서 할 일.
ORACLE 계정 등록
- 오라클 설치 및 운영을 위한 USER 계정을 새로 만든다.(admintool을 이용하는 것이 편하다) 아래와 같이 설정해주면 된다.

* 사용자명 : oracle (임의로 설정가능)
* Primary Group : oinstall
* Secondary Group : dba
* 홈 디렉토리 : /ora (임의로 설정 가능. 단 오라클 홈 디렉토리와는 절대로 일치시키지 말 것. 과거 리눅스용은 오라클 홈 디렉토리로 사용자 홈 디렉토리를 설정하였으나 솔라리스용은 다르다)
* Login Shell : Bourne shell (/bin/sh)

솔라리스 커널 Parameter 설정
/etc/system 파일 맨 밑부분에 아래 내용을 삽입한다.

   set shmsys:shminfo_shmmax=4294967295
   set shmsys:shminfo_shmmin=1
   set shmsys:shminfo_shmmni=100
   set shmsys:shminfo_shmseg=10
   set semsys:seminfo_semmni=100
   set semsys:seminfo_semmsl=100
   set semsys:seminfo_semmns=200
   set semsys:seminfo_semopm=100
   set semsys:seminfo_semvmx=32767

** 상기 사항을 입력할 때 주의하세요. 오타가 나면 부팅시 에러메시지가 나타납니다.

환경변수 설정
- oracle user의 환경변수를 설정해준다. oracle user의 홈 디렉토리안에 있는 .profile을 수정해주면 된다.
* DISPLAY=deskpia(자신의 워크스테이션 이름):0.0
* ORACLE_HOME=/export/home/OraHome1
* PATH=/usr/bin:/usr/ccs/bin:/usr/ucb:/etc:$ORACLE_HOME/bin:/bin:/opt/bin
* TMDIR=/var/tmp
* umask=022
* ORACLE_OWNER=oracle

** 주의사항 : oracle 계정은 위에 언급한 대로 Bourne shell을 사용한다. C shell과는 달리 Bourne shell이나 Korn shell에서는 환경변수를 지정한후에는 반드시 export 명령을 주어야만이 변수가 적용된다.

예를 들어 위에서 설정한 ORACLE_HOME=/export/home/OraHome1 의 경우에도 밑줄에 export ORACLE_HOME 을 추가로 설정해 주어야 된다.

여기까지는 oracle을 인스톨하기 전에 만들어준다.

oracle 홈디렉토리의 사용권한 설정

- oracle user가 새로이 생성될 오라클 홈디렉토리에 쓰기권한을 가질 수 있도록 해주는 것이다. 만일 오라클 홈디렉토리가 위에 지정한 것처럼 /export/home/OraHome1이라면..

# chown oracle:oinstall /export/home

이렇게 지정해주면 된다.

oracle 사용자로서 할 일
root 권한하에서 할 일을 마쳤으면 이제 새로 생성한 oracle user로 다시 login하여 다음 작업을 수행해주자.

umask 값 확인

- umask라고 쉘에서 입력했을 때 0022값이 나오면 된다. 다른값이 나왔다면 .profile에서 umask 설정을 잘못해준 것이다.

oracle 데이터베이스 설치
아래 내용은 모두 oracle 사용자로 로긴하여 수행해야 하는 일이다. 절대 root로 login하지 말기 바란다.

로긴시 언어설정
가장 애를 먹은 부분이다. 이제껏 기본적으로 한글 (Korean) 환경에서 솔라리스를 수행하여 왔을 것이다. 그러나 Oracle database를 설치할 때 만큼은 영어환경에서 설치를 해주도록 하자. 그 이유는.... 한글환경에서 설치를 해보면 안다. Oracle Database Configuration Assistant를 수행할 때 나오는 원인모를 에러.. 그리고 멈춤. 이것 때문에 며칠을 허송세월하였다. 결국 오라클 사용자모임의 게시판에서 해답을 얻을 수 있었다.

Oracle 8i CD 삽입
다 아는 내용이겠지만 솔라리스는 CD를 삽입함과 동시에 자동으로 CD를 마운트 해준다. 오라클 CD를 넣으면 CD의 루트 디렉토리에 있는 파일들이 파일관리자 화면에 보일 것이다. 여기서 아래에 흰색으로 표시된 runInstaller 파일을 수행시키면 된다. 마우스로 더블클릭 해보자. JAVA를 기반으로 한 멋진 GUI환경의 Universal Installer Program이 실행된다.

Oracle 8i 설치
설치 프로그램 화면을 따라가면서 설치를 수행하자.
설치도중 tmp/OraInstall/orainstRoot.sh 스크립트 파일을 root 권한으로 수행하라고 나온다. (물론 새로 root로 로긴하라는 것이 아니고 잠시 su를 이용 root권한을 가지고 하면 된다)

File location 지정화면은 특별한 이유가 없는 이상 시스템에서 기본적으로 지정하는 위치에 설치하면 된다.

설치하는 유형을 선택하는 메뉴는 다음 3가지로 나뉜다.

1) Oracle Enterprise Edition 8.1.5 : Oracle db server와 관련된 모든 프로그램
2) Oracle 8i Client 8.1.5 : client용 프로그램
3) Oracle Programmer 8.1.5 : 기본적인 클라이언트 프로그램 (Net8, SQL*Pluse) 및
프리 컴파일러, 도움말등.

위에서 자신에게 알맞는 사항을 선택후 Next 버튼을 누르면 설치유형 선택화면이 나온다. 여기서 Custom을 선택하여야만 프로그램 및 데이터베이스에서 사용할 언어를 선택할 수 있다.

다음 화면은 설치가 가능한 각 프로덕트가 박스안에 나열된다. 상단의 'Product Language'를 클릭하면 설치할 언어를 선택할 수 있다. 기본적으로는 'English'로 되어있겠지만 이것을 'Korean'으로 변경한다.

Java Runtime Applicaiton의 경로설정 및 보안인증방법 (Authentification Methods) 설정부분은 그냥 Next 버튼을 누르면 기본값으로 설정된다.

Oracle Home Directory는 기본적으로 export/home/OraHome1으로 되어있을 것이다. 설정된 기본값 그대로 하면 된다.

오라클 소프트웨어를 갱신할 수 있는 UNIX 그룹을 지정하라고 나오면 oinstall을 입력한다.

설치에 필요한 파일이 복사되는 과정이 진행된다.

Net8 Configuration
네트웍 설정부분이다. 이곳을 click하면 자세한 사항이 나온다.

** 설치중 정해주어야 할 값.
Oracle SID: 4-5자정도의 짧은 알파벳 이름을 지어준다. 이값은 추후 .profile에도 설정해
주어야 하므로 잊지 않도록 한다. (Default : ORCL)
DB 명 : 역시 자기마음에 드는 이름을 지어준다

데이터베이스 생성
설치 후반부로 가면 자동으로 수행에 필요한 데이터베이스 생성으로 들어간다. (Oracle Database Configuration Assistant) 데이터베이스 생성 옵션으로서는 설치 CD에 있는 데이터베이스 파일 복사를 선택하면 된다. 데이터베이스 생성작업에 소요되는 시간은 시스템 메모리 크기에 따라 차이가 있을 것이다. (메모리가 클수록 소요시간은 짧아진다)

root.sh 실행
필요한 파일 설치가 끝나고 링크작업이 완료되면 Oracle Home 디렉토리에 있는 root.sh를 root권한으로 실행하라는 메시지가 나온다. 이것을 실행시켜도 실행이 되지 않을 경우에는 chmod 명령을 사용하여 root.sh의 속성을 실행가능 파일로 바꿔준다.

실행후 ORACLE_OWNER, ORACLE_HOME, ORACLE_SID의 설정값이 나오면 이것을 확인해둔다. local bin 디렉토리의 full path명은 자신의 시스템에 설정된 값으로 고쳐준다.(예. /usr/bin)

모든 설치가 끝나게 되면 아래와 같은 엔딩 화면을 보게된다. 이걸 보기위하여 얼마나 많은 노력을 하였는가.... 라고 생각하면 안된다. 아직 확인해야 할 일이 많다.

설치후 해야할 일
환경변수 추가 설정
- oracle user의 환경변수를 추가로 설정해준다. 설치하기 전과 마찬가지로 oracle user의 홈 디렉토리안에 있는 .profile을 수정해주면 된다.

* ORACLE_SID= 아까 설정한 값을 넣어준다. (예 : ORCL등)
* CLASSPATH=/export/home/jre/1.1.7/bin:$ORACLE_HOME/jlib
* LD_LIBRARY_PATH=$ORACLE_HOME/lib

** 참고로 필자의 oracle 계정에 설정한 .profile값을 공개한다. 여기서 DISPLAY 변수에 나오는 서버명(deskpia)은 여러분의 시스템에 맞게 수정해야 한다. 나머지 사항은 대체로 동일하게 설정해도 되는 사항들이다.

tty istrip
DISPLAY=deskpia:0.0
export DISPLAY
ORACLE_HOME=/export/home/OraHome1
export ORACLE_HOME
PATH=/usr/bin:/usr/ccs/bin:/usr/ucb:/etc:$ORACLE_HOME/bin:/bin:/opt/bin
export PATH
TMDIR=/var/tmp
export TMDIR
umaks=022
export umask
ORACLE_OWNER=oracle
export ORACLE_OWNER
ORACLE_SID=ORCL
export ORACLE_SID
CLASSPATH=/export/home/jre/1.1.7/bin:$ORACLE_HOME/jlib
LD_LIBRARY_PATH=/usr/java/lib:$ORACLE_HOME/lib

이제 시스템을 rebooting후 oracle user로 새로이 login한다.

오라클 구동 확인
이미 path가 지정되어 있으므로 곧바로 아래와 같이 쉘에서 입력해보자.

$ svrmgrl

아래와 같이 화면이 나타나면 1차 성공이다.

이제 데이터베이스에 연결해본다.

SVRMGR> connect internal

Connected 라고 나오면 된다. 여기서 Connected라는 메시지와 함께 어떤 error 메시지가 나온다면 오라클 db가 정상적으로 설치되지 못한 것이다.

다음으로는 데이터베이스를 구동시킨다.

SVRMGR> startup

잠시후 아래와 같이 메시지가 나오면 성공적으로 데이터베이스가 구동되고 있는 것이다.

** 아래 수치는 시스템에 따라 다를 수 있음 **

내친김에 데이터베이스에 있는 테이블들을 살펴보자.

SVRMGR> select * from tab;

수많은 테이블들이 주욱 나오면서 마지막에 다음 메시지가 나올 것이다.

1433 rows selected.

이제 오라클 데이터베이스 설치라는 기나긴 여정이 끝났다. 남은 일은 dba로서 해야 할 일이다. 항상 끝마칠 때 shutdown을 잊지 않으면 아무런 문제없이 oracle DB를 사용할 수 있을 것이다.

p.s. http://technet.oracle.com으로 가면 오라클 데이터베이스에 관한 아주 많은 자료들이 체계적으로 정리되어 있다. 이것을 이용하려면 회원으로 가입하면 된다. 회비는 무료이다. 물론 모든 자료는 영어로 되어 있다.

Oracle 8i 설치를 위한 네트웍 설정
Database 설치에 웬 네트웍 ? 하실지도 모르겠다. 오라클은 클라이언트/서버 환경에서 수많은 고객을 만족시켜온 데이터베이스이다. (지금도 많이 쓰이고 있지만).

서버에 설치된 하나의 오라클 엔터프라이즈 에디션만 있으면 클라이언트는 아주 경량화된 클라이언트 component만을 자신의 PC에 설치해서 오라클을 기반으로 한 응용 프로그램을 실행시킬 수 있다. 이때 서버와 클라이언트간의 연결은 네트웍을 통하여 이루어지게 된다.

이러한 Client/Server간의 통신을 위하여 설정해주어야 하는 부분이 바로 네트웍 설정이다.

본격적인 설정에 앞서서 네트웍 설정에 나오는 용어 몇가지를 정리하도록 해보자.

1) listener.ora : 클라이언트가 db에 접속하려 한다고 서버에게 말하면 서버는 그 요청을 들어야 한다. 이 요청을 놓치지 말고 귀담아 듣도록 서버와 클라이언트간 통신 환경을 설정해주는 파일이라고 생각하면 쉬울 것이다. 당연히 서버에 있어야 하겠고.
client측이 오라클 서버로 접속할 수 있도록 필요한 프로토콜 및 포트번호(주로 1521) 를 설정해 주는 파일로서 서버에 위치한다. protocol로서는 주로 tcp/ip가 사용될 것이다.

2) tnsnames.ora : client측에서 오라클 서버로 접속할때 필요한 프로토콜 및 포트번호, 서버주소, 인스턴스등을 설정해주는 파일로서 클라이언트에 위치한다.

** linstener.ora와 tnsnames.ora는 둘다 Net8 configuration 작업을 해주면 자동으로 설정된 값에 의거하여 만들어지는 파일들이다. 위에서 명시한바와 같이 둘의 이름은 다를지언정 추구하는 목적은 똑같다. (listener는 서버용, tns는 클라이언트용)

만일 A라는 서버가 B라는 서버에 접속하려 한다면 어떻게 해야할까 ? 이때 A라는 서버는 비록 이름은 서버지만 접속하려는 순간에는 B의 클라이언트가 된다. 그러므로 역시 접속하기 전에 tnsnames.ora를 만들어주어야 한다.
이제 오라클 DB 설치도중 나오는 Net8 Configuration 설정과정을 예로 들면서 하나씩 알아보도록 한다. 오라클을 설치하다보면 Configuration tools라는 그래픽 박스가 나타나면서 이 과정이 수행된다.

Net8 Configuration
제일 먼저 화면에는 Listener configuration과 Naming Method configuration을 시작하고자 한다는 정중한 메시지가 나온다. 말 그대로 Listner와 Naming Method를 설정하는 부분이다. Next 버튼을 클릭하면 Listener의 이름을 지어달라고 부탁하는 화면이 나올 것이다. 여기서 Listener의 이름 작명에 머리아파하지 말자. 기본값으로 LISTNER라고 나올 것이다. 이걸 그대로 사용하면 된다. (물론 사용자가 자기 이름으로 변경해도 된다.)

다음으로는 리스너 프로세서가 사용할 통신 프로토콜을 설정하자. 이부분은 자신의 시스템이 사용하는 프로토콜을 선택하면 된다. (일반적으로 TCP/IP라 생각되는데...)

TCP/IP Client Type 화면에서는 선택된 프로토콜이 어떤 클라이언트 유형에 적용될지를 선택할 수 있다. 일번적인 C/S환경에서는 'Net8 Client'를 선택한다. 인터넷과 관련된 클라이언트 유형이라면 IIOP Clients를 선택할 수 도 있다.

다음 화면에서는 사용할 TCP/IP Port number를 지정하게 된다. 기본값은 1521이 된다. 여기서 한가지 주의사항이 있다. 지정된 포트를 제대로 사용하려면 솔라리스의 etc/services 파일에 'listener 1521/tcp'라는 값이 설정되어 있어야 한다. 물론 여러분이 처음 오라클을 설치하였다면 설정이 되어있을리 만무하다. 오라클 설치를 모두 마친후에, 파일을 열어서 꼭 설정해주도록 하자. (설정후에는 시스템을 리부팅해주어야 한다)

만일 여러분이 설치한 오라클 서버에 수많은 사용자들이 동시에 접속해야 한다면 리스너 프로세서 하나만으로는 모자라는 경우가 생길 수 있다. 이 경우에는 리스너를 하나이상 설치해 주어야 한다. 'More Listner ?' 화면에서는 이러할 때를 대비하여 복수 리스너를 설치할 수 있도록 해준다. 그러나 일반적으로는 하나의 Listner로도 충분하므로 'No'를 선택하자.

리스너 설치가 완료되면 다음으로는 Naming Method 설치메뉴가 나온다. 여러분이 속해있는 네트워크에 여러개의 데이터베이스가 설치되어 운영중이라면 Named Server를 설치하여 오라클 데이터베이스에 접속할때의 환경을 만들어 주어야 한다. 그렇지 않고 오라클 데이터베이스만을 사용한다면 이것 역시 'No'를 선택하고 넘어가면 된다.

이것을 마치면 Net8 Configuration Assistance 설치가 모두 완료되었다는 화면이 나온다.

리스너 동작상태 확인
** 주의 : 아래 사항은 오라클 데이터베이스 설치를 모두 마친후 오라클 사용자로 로그인하여 확인해야 한다. 설치도중에 시도하면서 안된다고 고민하지 말것..

이제껏 설치한 서버의 리스너가 잘 동작하는지 동작상태를 확인해보자.

$ lsnrctl status 라는 명령을 주면 된다.

만약 protocal adapter error니 no listener니 하는 에러메시지가 잔뜩 나오면서 작동을 하지 않고 있으면 ... 실망하지 말고 아래 명령어를 실행해보자.

$ lsnrctl start listener

작동을 멋지게 시작할 것이다.

그래도 작동을 하지 않는다면... 위에서 언급한 etc/services 파일에 'listener 1521/tcp'라는 값이 설정되어 있는지를 확인해보자. 대부분 이것이 제대로 설정되어 있지 않아 일어나는 불상사이다.

Part Two

Solaris8 강좌

Chapter 솔라리스 기초
솔라리스 기본 명령어
솔라리스를 능숙하게 다루고 ,친해지기 위해서는 우선적으로 명령어에 익숙해 져야한다. 이러한 명령어는 솔라리스 뿐만 아니라 거의 모든 유닉스 시스템에서 사용되어지는 것으로 기본적으로 꼭 알아야할 것 들이다.

계정명령어

유닉스에 접속과 접속종료에 관계되는 명령어와 사용자 계정에 관한 명령어에 대해서 알아보자.

시스템에 접속하기 위해서는 사용자마다 고유의 계정이 있어야한다. 일반 사용자들은 시스템관리자에게 연락하여 자신이 원하는 ID로 계정을 발급받자. 처음 솔라리스(유닉스)에 접속하면 다음과 같은 화면이 나온다.

사용자는 계정ID와 암호를 정확하게 입력하여야한다. 시스템에 성공적으로 접속이 이루어지면, 마지막 login, 전자우편메시지나, 시스템관리자로부터의 메시지 등의 정보가 나온다, 다음은 성공적으로 로긴(login)한 예이다.

패스워드(Passwd) 바꾸기

시스템에 접속하기 위해서는 매번 로긴과 패스워드를 입력하여야 한다. 만일 기억력감퇴나, 부득이한 사정으로 패스워드를 잊었다면 시스템관리자에게 연락하자.
사용자에게 있어 패스워드는 자신의 시스템에 대한 1차적인 보안수단이다. 따라서 정기적으로 바꾸어주는 것이 좋다.
패스워드를 바꾸기 위해서 간단히 passwd 명령을 실행시키면 된다.

만일 기존에 사용했던 패스워드와 새로운 패스워드 사이에 적어도 3글자 이상 차이가 없다면 다음과 같은 메시지가 나온다.

그럼 다시 새로운 패스워드를 입력하자. 자신만의 고유하고, 외우기쉬운 패스워드로...

디렉토리 및 파일 정보 보기

파일 정보 보기
ls
ls -flag [filename] [directoryname]

유닉스 명령어 중 가장 많이 쓰이는 명령어를 꼽으라면 당연히 ls 명령어 일것이다. 윈도우에서 쓰이는 탐색기와 같은 것으로 도스에서는 dir 명령어로 이해하면 될 것이다. 다음은 루트(/) 디렉토리에 있는 파일들을 ls 를 이용하여 출력하여보자.

유닉스에서 사용하는 명령어들은 굉장히 많은 옵션을 가지고 있다. 그렇다고 이 모든 옵션을 다 알 필요는 없다. 단지, 자주 사용하는 몇가지 옵션만 알면된다. 다음은 가장 일반적으로 많이 쓰이는 ls의 옵션들을 살펴보자.

디렉토리네의 숨겨진 파일 보기 [-a]
-a - 숨겨진파일(파일이름이 .으로 시작되는 파일)의 리스트를 보여준다.
기본적으로 ls 명령어로는 . 으로 시작되는 파일들은 숨은 파일로 출력되지 않는다.

[-a]를 쓰면 숨겨진파일까지 포함해서 모든파일과 디렉토리를 표시한다.
위에서 보았듯이 파일과 디렉토리들은 이름순으로 출력하여 보여준다. 마지막으로 변경된 시간에 따라, 최근 작업한 파일들을 알고 싶으면 [-t] 플래그를 쓰면된다.

여러가지 방법으로 보기
좀더 다양한 플래그를 활용하여, 파일과 디렉토리에 대해서 살펴보자.

상세히 보기
기본적인 정보이외에 자세한 파일에대한 정보를 보려면 [-l ]옵션을 사용하면 된다. [-l]은 파일과 디렉토리에 대하여 권한, 링크의수, 소유자, 그룹, 크기, 마지막변경시간 등 상세한 정보를 보여준다.

구분하여 보기
디렉토리를 구분하여 보고싶으면 [?p]를 쓰면된다.

콤마(,)로 나누어 보기
현재 디렉토리의 파일과 디렉토리들의 이름들 사이에 콤마(,)로 나누어 보려면 [-m] 을 쓴다.

하위 디렉토리 보기
디렉토리의 모든파일들과 하위디렉토리의 모든파일들까지 보고싶을땐 [-R]을 쓰면된다.

이제까지 ls명령어에 대한 몇가지 중요한 옵션들을 살펴 보았다. 더 자세한 내용들은 다음의 ls 옵션 정리에서 간략하게 정리하였다.

ls 옵션 정리

파일의 종류 알아내기
file

유닉스 시스템에서는 파일의 확장자가 없기 때문에 파일의 속성을 간혹가다 모를떄가 있다. 이때 쓰이는 명령어가 file 명령어이다.

test1은 디렉토리이고, /etc/hosts 파일은 일반 텍스트 파일, /bin/ls 는 실행명령어임을 알 수 있다.

파일 내용 보기
여러가지 방법으로 파일 보기
cat

파일안에 무슨 내용이 들어있는지 보는 가장 간단한 명령어가 cat 명령어이다.

cat 옵션정리

파일내용 한 화면 씩 보기
more
파일의 내용이 너무 길 경우 출력되는 화면이 너무 빨리지나가 끝에만 보게 될때가 있다. 이때 유용하게 쓰이는 명령어가 more 명령어이다. 기본적은 more명령어는 한화면의 출력이 끝냐면 다음으로 넘어가기 전 멈춘다. 이때, 스페이스바[Space]를 누르면, 다음화면이 출력되고, 엔터[Enter] 키를 누르면 한줄씩 출력이 된다.

/usr/include/에 있는 glob.h 파일을 more를 이용하여 보자.

more 명령어는 다른명령어의 결과를 출력할떄 파이프(Pipe)로 연결하여 사용하는 경우가 대부분이며, 파이프에(Pipe)에 대해서는 다음에 더 자세히 설명할 것이다

more 옵션정리

less
more명령어와 비슷하게 파일을 출력하지만, less는 기본적으로 출력된 파일의 내용을 앞과 뒤로 자유롭게 볼 수 있다. /etc/inittab 파일을less명령어로 써서 보자.

파일 끝에(END) 표시를 볼 수 있을 것이다. 파일의 끝을 나타내며, more 명령어와는 달리 쉘로 빠져나가지 않는다. q 또는 Q를 입력하여야만 나갈 수 있다. 잠시 쉘 프롬프트 상태로 나갈려면 !를 누르고 다시 less명령어 상태로 오려면 exit을 입력하면된다.

less 옵션정리

파일 내용 처음과 끝 지정해서 보기
head
head -flag [filename] : head 명령어는 파일전체가 아닌 처음 n개의 행을 화면으로 출력한다. n은 기본으로 10행이 지정된다.

head 옵션정리

tail
head 명령어와는 반대로 파일의 마지막 10줄을 출력한다.
tail +/- n [ filename ]

tail 옵션정리

파일 찾기
파일 찾기
find
어떤 파일이 어디 있는지를 알고 싶을 때 find 명령어를 이용하여 찾으면 된다. find 명령어는 파일의 이름, 크기, 속성, 권한 등의 다양한 방법으로 파일을 찾을 수 있다.

find [path] [expression]

일반적으로 파일의 이름으로 찾는 경우가 제일 많이 활용되는데, 이름으로 찾을 경우에는 [-name]옵션을 써주면 된다. /etc 디렉토리에 있는 i 로 시작하는 파일을 찾아보자.

/etc 밑의 하부디렉토리까지 i로 시작되는 파일들은 모두 출력하여 준다. 만일 파일의 위치를 모르고 test라는 파일이름만 알 경우 다음과 같이 해주면 된다.

파일 찾기 뿐 아니라 파일의 리스트로 볼 수 있는데 현재 디렉토리와 하부디렉토리까지의 모든 파일의 리스트를 보려면 다음과 같이 간단히 실행하면 된다.

find 옵션 정리

명령어 찾기
which
which 명령어는 유닉스 시스템의 PATH에 설정되어 있는 경로에서 명령어가 있는지 찾는데 쓰이는 명령어이다. which 명령어가 어디에 있는지 찾으려면 다음과 같이 하면 된다.

파일검색 할 때 자주 쓰이는 ls 명령어가 어디에 위치하는지 찾아보자.

whereis
whereis 명령어는 검색경로에 사용자가 지정해준 명령어가 있는지 찾을 때 쓰이는 명령어이다.whereis 명령어가 어디 있는지 찾으려면 다음과 같이 하면 된다.

find 명령어가 어디있는지 whereis 명령어로 찾아보자.

파일 조작 하기
파일 다루기
파일 및 디렉토리 복사하기 : cp
파일 및 디렉토리 복사할 때 cp 명령어가 쓰인다. 하나의 파일을 복사할 수 도 있고, 여러 개를 동시에 복사 할 수 도 있다. 현재 위치에서 test 파일을 test_cp 파일로 복사하여 보자. 아무런 옵션없이 간단하게 파일을 복사하는 방법이다.

# cp test test_cp

test_cp라는 파일이 이미 존재하고 있다면, test_cp파일을 덮어쓴다. 그러나 중요한 파일을 덮어쓰는 실수를 방지하기 위하여 [-i] 옵션이 있다. [-i] 옵션은 파일을 복사하기 전 만약 이미 그 파일이 존재하면 확인을 위해 물어본다.

디렉토리 및 그 하부 디렉토리까지 통째로 복사할려면 [-r]옵션을 주면 된다.
다음은 test1 디렉토리를 test_dir_cp로 복사하여 보자.

파일 이동하기 : mv
기존의 파일을 다른위치에 옮기거나, 파일명을 다시 바꾸고자 할 때 mv 명령어를 쓴다.

mv ?flag [filename 1] [filename 2] or [directory 1] [directory 2]

파일 이름바꾸기
Solaris.txt 파일을 Solaris_8.txt로 이름을 바꿔보자.

# mv Solaris.txt Solaris_8.txt

디렉토리 이름 바꾸기
test1 디렉토리를 test1_mv 디렉토리로 변경시켜 보자.

# mv test1 test1_mv

파일 및 디렉토리 지우기: rm

rm ?flag [filename] or [directoryname]

여러 가지 작업을 하면서, 시간이 지날수록 쓸모없는 파일들도 늘어나고 디스크 공간만 쓸데없이 차지하는 경우도 생기게 된다. 이럴땐 필요없는 파일들을 지우고 디렉토리를 정리하여야 된다. rm 명령어는 파일 및 디렉토리를 영구적으로 지워버리는 역할을 한다. 윈도우의 휴지통처럼 다시 복원할 수 있는 기회가 없기 때문에 이 명령어를 쓸때는 신중해야한다.
파일을 지우려면 그 파일에 쓰기 권한이 있어야 지울 수 있다. 파일에는 읽고, 쓰고, 실행할 수 있는 권한이 있는데, 이것에 대해서는 ^^ 파일 소유권 및 권한 에서 더 자세히 다룬다.

현재위치에서 test로 시작되는 파일들은 모두 지우려면 다음과 같이 하면된다.

[*]과 같은 와일드 카드는 조심해서 사용해야한다. 만일 [ rm test *] 이렇게 잘못입력하면 모든 파일이 지워지기 때문이다.
이러한 실수를 피하기 위해서 지울 때 마다 일일이 물어보는 [- i]옵션을 사용하는 것이 안전하다.

rm 옵션 정리

디렉토리 다루기
디렉토리 만들기 : mkdir

mkdir ?flag [directoryname]

디렉토리를 한 개 만들수도 있고, 파일처럼 여러 개를 한꺼번에 만들 수 있다. /ebee디렉토리 밑에 solaris_dir 디렉토리를 만들려면 다음과 같이 하면 된다.

만일 /ebee/solaris_dir 가 이미 존재한다면 다음과 같은 메시지가 나온다.
"mkdir: Failed to make directory "solaris_dir"; File exists "

새로운 디렉토리를 만들면서 디렉토리에 대한 권한을 지정해 줄 수 있는데 [- m] 옵션과 권한을 써주면 된다.

디렉토리 지우기 : rmdir

rmdir ?flag [directoryname]

solaris 디렉토리를 지우려면 다음과 같이 하면된다.

디렉토리를 지울때는 디렉토리내에 하부디렉토리 및 파일이 없어야 지울 수 있다. 만일 하나라도 파일이 있을 경우 다음과 같은 메시지가 나온다
rmdir: directory "solaris": Directory not empty

이럴경우 디렉토리내의 모든 파일을 먼저 지우고 solaris 디렉토리를 지워야한다.

입출력 방향 변경 & 파이프
(redirection & Pipe)
입출력 방향 변경(redirection)
유닉스 시스템에서 명령어의 수행은 키보드와 모니터로 이루어진다. 그러나 특정기호를 사용하여 명령어의 입출력 방향을 변경 할 수 있다. 쉘 명령어를 사용해서 사용자가 원하는 파일이나 다른장치로부터 입력을 받을 수 있고, 모니터 화면이 아닌 다른 파일이나 다른장치로 출력을 전환할 수 있다.

입력 리다이렉션 [ < filename ]
표준입력으로 파일 filename을 이용한다. inputfile을 표준입력으로 받아 cat으로 파일을 출력한다.

출력 리다이렉션 [ > filename ]
표준출력을 파일 filename에 저장한다. 만일 filename이 존재하지 않으면, 새로 파일을 만든다. 그러나 기존에 같은 이름을 가진 파일이 있을 경우 덮어쓰게 된다. ls ?l 을 입력으로 받아 ouputfile로 표준출력하려면 다음과 같이 하면 된다.

추가 리다이렉션 [ >> filename ]
기존에 파일이 존재하면, 기존내용뒤에 새로운 결과출력을 추가한다. 만일 파일이 존재하지 않으면, 새로운 파일을 생성한다.
outputfile 에 date를 추가시켜보자.

파이프 (Pipe)

명령어1 | 명령어2 |

한 명령의 결과를 다른 명령의 입력에 넣고 싶을 때 파이프를 사용한다. 파이프라인이란 일련의 명령들 간을 | (Pipe) 기호에 의해 연결해 선행하는 명령어 실행결과를 뒤에오는 명령어의 입력으로 이용한다. ls 명령어의 결과를 한 페이지씩 볼 수 있는 more 명령어의 입력으로 이용하려면 다음과 같이 하면된다.

Pipe 파일의 내용을 cat 출력하는데 있어서, blonde 라는 단어가 있는 모든 라인 출력하려면 다음과 같이 하면 된다.

파일 압축 명령어
파일 압축하고 풀기

tar
tar는 여러 개의 파일을 하나의 파일로 묶어주며, 이들 가운데 선택적으로 파일을 풀거나 또 새로운 파일을 추가할 수 있다.

tar -flag [tarfilename] [filename1, filename2..]

먼저 여러 개의 파일을 하나의 tar파일로 묶어보자.

[-c] 옵션은 새로운 tar파일을 생성할 때 쓰이고, [-v]는 tar의 작업진행상황을 보여준다.
[-f] 옵션은 다음의 매개변수를 tar 파일 이름으로 지정한다.

files.tar로 생성된 tar파일에 새로운 파일을 추가하고 싶으면 [-r]옵션을 쓰면된다.

현재 생성된 tar파일의 리스트를 보고 싶다면 [-t] 옵션을 쓰면된다.

files.tar 파일을 원래의 파일로 복구하려면 [-x ] 옵션을 써서 다음과 같이 하면된다. 주의할 것은 기존의 file1, file2, file3, file4 가 존재하면 files.tar를 파일을 풀경우 덮어쓰게 된다. 만일 file1, file2, file3, file4가 내용이 추가되고 변경되었다면, 파일의 이름을 바꾸고 files.tar를 파일을 풀던가 아니면, 다른위치에서 풀어야 한다.

tar 옵션 정리

compress
compress -flag [filename]

compress 를 이용하여 파일을 압축하게 되면 압축된 파일이름뒤에 .Z가 붙게 된다. 압축된 파일도 원래 파일들의 권한 및 시간 등의 모든 속성은 계속 유지된다.
compressfile을 압축하기 위해서는 다음과 같이 하면된다.

압축된 파일을 원래 상태로 다시 풀기위해선 [-d] 옵션을 써서 다음과 같이 하면된다.

compress 옵션 정리

gzip & gunzip
gzip -flag [filename]
gunzip -flag [filename]

gzip으로 파일을 압축하게 되면, .gz 확장자를 갖는 압축파일을 생성한다. 파일의 소유권, 권한, 수정시간등 속성들은 그대로 보존된다.

tar 명령어는 원래의 원본파일도 남겨두면서, 새로운 tar파일을 생성하는데 반해, gzip 으로 압축을하면, 원래의 파일이름이 압축파일내에 저장되어 .gz 파일만 남게 된다.
압축된 파일은 [ gzip ?d ] 또는 gunzip 명령어를 이용하여 복구할 수 있다.

gunzip 명령어는 .gz 또는 .Z 확장자를 가진 압축파일을 복구하며, compress나 pkzip을 이용하여 압축된 파일도 복구한다.

gzip 옵션 정리

문서 편집기
유닉스를 사용하는 모든 유닉서들은 유닉스사용의 70% 이상을 문서편집기를 이용할 것이다. 유닉스의 문서편집기는 단순한 문서작업만 하는 것이 아니기 때문이다. 간단한 텍스트작성부터, 프로그래밍에까지 다양하게 활용되고 있다. 초보 유닉서들은 처음에는 낯설고 여러가지 사용법을 익혀야 하지만 익숙해 지면 이처럼 편한 것이 없다고 느낄 것이다.

이번 강좌에서는 문서 편집기의 양대 산맥을 이루는 vi 편집기와 Emacs 편집기에 대해서 살펴 보겠다.

vi 문서 편집기
유닉스의 문서편집기를 대표할 수 있는 것이 vi 편집기다. vi 는 거의 모든 종류의 유닉스에 기본적으로 포함되어 있으며, 그 활용범위도 다양하고 다른 어플리케이션과도 상호교류로 인하여 더 풍부한 기능을 제공하는 작고도 강력한 어플리케이션이다. vi 를 사용하면서 마우스는 찬밥취급을 당하게 된다. 왜냐하면 거의 모든 아니 모든 vi 사용이 키보드하고만 인터페이스를 하기 때문이다. 사람들에 따라서는 이것에 불편할 지 모르나, 조금만 vi에 익숙하다보면 훨씬 빠르고 편하게 느낄 수 있다. (어쩌면 필자의 생각인지도 모르겠다)

vi 시작하기
vi [ filename ]

vi의 시작은 간단하다. vi 옆에 자신이 만들고자 하는 파일명을 써주고 엔터키만 입력하면 된다. test라는 텍스트 파일을 만들어보자.

vi 를 시작하면 텍스트 입력을 하기 전의 초기 상태 즉 명령보드 상태로 맨 왼쪽 상단에 커서가 깜박거리고 있다. 맨 밑에는 test라는 새로운 파일 만드는 것을 나타내주고 있다.

vi 모드
vi 에는 입력모드, 명령모드, ex모드 세가지 모드가 있다. Vi를 처음 접하는 사람들은 이런 세가지 모드로 이루어진 것에 익숙치 않을 것이다. 가끔씩 지금 내가 어떤 모드 인지를 착각도 하게 된다. 그럴때면 무조건 다른 모드로 넘어갈 때 ESC 키를 먼저 누르고 시작 하면된다. ESC 키는 명령모드와 입력모드 사이를 전환할 때 쓰인다.
명령모드는 텍스트의 입력을 제외한 이동, 수정 및 찾기 등의 다양한 vi의 명령기능을 수행하는 모드이다. 입력모드는 말 그대로 텍스트를 입력하는 상태를 뜻한다. 입력모드 상태에서는 텍스트의 입력과 편집을 할 수 있다. ex모드는 파일의 저장 및 종료할 때 쓰이는 모드로 다음에서 자세히 설명하도록 하겠다.

입력하기
초기 명령모드 상태에서 입력모드 상태로 가기 위해서 i (insert)를 누르고 입력을 시작하면 된다. test 파일에 다음과 같은 텍스트를 입력하여보자.

하나의 문장을 입력하고 다음 줄로 넘어갈려면 엔터키를 누르면 된다. 쓰다가 틀리면 간편하게 백스페이스키()를 사용하면 지워진다.i명령어 이외에도 텍스트 입력모드 명령은a명령어가 있다.a(append)는 현재 위치 다음부터 입력을 시작한다.

만일 (4)번과 (5)번 사이에 새로운 문장을 삽입하고 싶다면, (4) 번째 줄 위치에서 o을 입력하면 된다. o(open) 명령어는 현재 커서가 있는 다음 줄 맨 앞부터 입력을 한다.

이동하기
vi 에서 이동명령어는 명령모드 상태에서 이루어진다.

한 칸씩 이동하기
가장 기본적인 이동명령어는 화살표이다. 키보드의 상,하,좌,우 를 누르면 한 칸씩 이동하게 된다. 만일 다른 유닉스 시스템에서 키보드 화살표로 이동을 할 수 없을 수도 있다. 이때는 한 칸씩 이동하는 vi의 명령어를 사용하면 된다.

단어 단위로 이동하기
단어를 하나의 단위로 이동한다. 백스페이스나 한 칸 단위로 이동할떄 보다 훨씬 쉽게 조금 먼 거리를 이동할 수 있다.

행의 처음과 끝 이동하기

한화면씩 이동하기

패턴 찾아서 이동하기
/pattern

찾고자 하는 단어가 문서가 길거나 양이 많을 경우 일일이 커서를 움직혀 찾는 것은 불편하다. vi 에서는 원하는 단어나 패턴을 찾아 바로 이동할 수 있다. 정확한 단어를 모를 경우 와일드 카드 문자를 이용하여 쉽게 찾을 수 있다. 다음은 test_solaris 파일에서 URL 을 찾는 것으로 보여준다.

맨 아래에 /URL 를 입력하고 엔터키를 치면 URL 단어에 처음으로 커서가 이동한다.
찾고자 하는 단어의 단어를 정확하게 모를 때 와일드 카드 문자를 이용하여 쉽게 찾을 수 있다. solaris 단어가 정확치 않을 때 /solar* 라고 입력하면 된다.

커서가 처음에 나오는 solaris단어 처음으로 이동한다. 엔테키를 누르면 다음줄로 이동하고
n 을 누르면 다음에 나오는 solaris 를 찾아 이동한다.
/ 은 기본적으로 처음부터 검색을 한다. 뒤부터 검색하고자 할때는 ? 를 쓰면 된다.

원하는 행으로 이동하기
행 numberG

만일 10번째 행으로 바로 이동하고 싶다면 10G 라고 치면 된다.
파일의 끝으로 바로 이동하고 싶으면 G 명령을 수행하면 된다. 이러한 이동명령은 명령모드에서 수행되어지고 찾기 명령과 달리 화면에 표시되는 것이 없다.

수정하기
문서를 작성하다 보면 수정을 상황이 발생한다. 이때 vi에서는 한글자 뿐만 아니라 자기가 원하는 범위를 빠르게 찾아서 수정할 수 있다.

한글자 삭제하기
명령모드에서 지우고자 하는 글자에 커서를 갖다놓고 x 를 치면 간단하게 지워진다. x 명령어는 한번에 한글자씩 지우는 기능을 한다. 철자가 틀린 글자를 고치고자 할 때 틀린 글자를 x 로 지운 후 a 를 눌러 입력모드로 전환한 후 맞는 글자를 삽입하면 된다.

한 줄 지우기
한 줄 전체를 지울때는 dd 명령을 사용하면 된다. dd 명령은 지우고자 하는 행 앞에 커서를 갖다 놓고 d를 두번 누르면 된다. dd를 이용하여 행을 지울 경우 지워진 행 만큼 문서가 당겨진다.

Undo
만일 잘못하여 실수로 지웠을 경우에는 p, P 명령을 이용하여 복원할 수 있다.
p명령은 현재 행뒤에 삭제된 행을 복원시켜주고 대문자 P 명령은 삭제된 행을 현재 행 앞에 복원하여 삽입한다.
P,p 명령어 외에 복원 명령어로는 u명령어가 있다. u 명령어는 최근에 변화된 내용을 되돌려준다. 입력모드에서 장문의 긴 텍스트를 입력한 후 명령모드로 빠져나온 상태에서 u 명령어를 입력하면, 지금까지 입력된 내용이 취소된다.

단어삭제하기
철자가 잘못 입력된 단어를 지울 때 x 명령을 이용하여 지우게 되면 계속해서 키보드를 누르고 있어야한다. 이럴때 편리한 명령어는 dw 명령어이다. 지우고자 하는 단어 앞에 커서를 갖다놓고 dw를 치면 커서아래 놓인 단어가 삭제된다.

파일의 저장,종료 와 vi 빠져나오기
앞서 ex모드에 대해서 언급하였을 것이다. vi 에서 파일에 관한 명령을 실행하기위해서는 ex모드로의 전환이 필수적이다. 입력모드 상태에서 [ESC] 키를 입력하여 명령모드 상태로 전환한 후 [:]키를 누르면 ex 모드로 들어가게 된다,
다음은 ex모드 상태를 보여준다.

이때 :w 를 입력하면 파일이 저장된다. 파일의 저장,종료,vi 끝내기등의 명령을 실행하려면 ex모드 상태에서 이루어져야 한다. 파일의 저장과 함께 vi를 빠져나오려면 :wq 를 치면된다. 만일 파일을 저장하지 않고 vi를 끝내려면 :q!를 치면된다. 그냥 :q 명령의 사용은 파일이 저장되었을 때만 정상적으로 vi를 종료할 수 있다. 만일 저장하지 않고 :q 명령을 치면 다음과 같은 메시지가 나온다.

저장하지 않고 강제로 빠져나오려면 :q! 명령을 수행하면 된다. :q! 명령어에서 ! 은 강제로 명령을 실행될 때 사용된다.

다음은 슈퍼유저가 중요한 파일을 수정한 후 저장과 함께 vi를 끝내려고 하는 것을 보여준다. /etc/passwd 파일을 사용자의 패스워드를 관리하는 중요한 파일이다

:wq 명령을 써서 파일을 저장하고 vi를 빠져나오려는데, 맨밑에 읽기전용이라는 표시와 함께 명령을 실행 할 수 없다는 메시지가 나오는 것을 볼 수 있다. 이때도 !를 사용하여 강제로 저장하고 vi를 나올 수 있다. 하지만 주의할 점은 이러한 메시지를 보여주는 파일은 대단히 중요한 파일임으로 슈퍼유저(root)라 할지라고 조심해서 다루어야 한다.

Emacs란 무엇인가?
유닉스에 많은 편집기들이 존재 하지만 vi 와 Emacs 가 문서편집기의 양대 산맥을 이루고 있다. Emacs 는 vi와 같은 문서 편집기 이다. 하지만 출발부터 vi와는 다르다. Emacs는 리눅스의 아버지라 불리는 GNU 소프트웨어의 제작자인 Richard stallman의 산물이다. 많은 종류의 Emacs가 있는데 그 중 가장 인기있는 emacs 는 GNU Emacs 이다. Emacs는 작고 강력한 vi에 비해 거대한 소프트웨어이다. vi 에 오랫동안 익숙해 온 사람들은 Emacs 와 같은 복잡한 편집기를 기피하는 경향이 있다. 두 편집기 나름대로 장.단점이 존재하여 어느 편집기가 더 좋다고 딱 잡아 말하기는 어렵다. 가장 큰 Emacs의 특징은 지금까지 나온 유닉스 소프트웨어 중 무수히 많은 기능을 갖춘 거대한 시스템이다. 컴파일, 디버깅, X 윈도우 시스템 지원, 전자우편기능 및 LISP 언어엔진으로 Emcas만의 확장기능을 만드는 등 다양한 역할을 할 수 있다.

Emacs가 vi와 다른점은 Ctrl, Meta(Alt) 키를 사용하여 여러 편집기의 확장기능을 수행한다. Emacs의 명령기능은 Ctrl, Meta(Alt) 키와의 조합으로 이루어진다. 또한 Emacs의 가장 큰 특징 중 하나는 자체 적으로 온라인 도움말과 설명문서가 내장되어 있다.

본 강좌에서는 가장 인기 있고 유명한 GNU Emasc를 가지고 설명하겠다.

Emacs 시작하기
emacs [ filename]

Emacs의 시작은 간단하다. vi와 마찬가지로 emacs 옆에 만들고자 하는 파일이름을 적어주면 된다.

시작하면부터 vi 와는 다르다는 것을 알 수 있을 것이다. GNU Emacs의 간략한 소개가 나온다. 맨위에는 메뉴바가 있는 것이 특징적이다. 하단에는 Emacs의 현재 상태를 나타내는 미니버퍼가 있다.

emacs_test 텍스트 파일을 만들어 보자

화면 하단에 파일명과 현재시각, 맨 오른쪽에 ALL은 현재 지금 파일을 보고 있다는 것을 뜻한다. 솔라리스 콘솔에서 Emacs를 실행할 경우 위와 같이 편리한 메뉴기능을 사용할 수 있다. Ctrl키나 Alt키가 익숙치 않을 사용자라면 메뉴바는 작업하는 데 훨씬 효율적일 수 있다.

일반적으로 다수의 사용자들은 원격 접속인 telnet을 사용하여 시스템에 접근할 것이다. 이때는 직접 콘솔에서 Emacs 작업과 똑같이 할 수 없다. 마우스를 이용하는 메뉴의 사용에 약간의 제약을 받는다.

간단한 텍스트 파일을 만들고자 한다면 emcas를 실행시키고 바로 텍스트를 입력하면 된다. vi 에서 처럼 입력모드로 들어가기 위해 i, a, o 명령을 수행할 필요없이 Emacs는 바로 입력하면 된다. emacs_test 파일을 하나 만들어 보자.

문장을 입력하고 파일을 저장하기 위해선 Ctrl + x,s 를 연달아 입력하면 된다. 화면 하단에 보면 경로명과 함께 파일이 저장되었다는 표시가 나타난다.

Emacs 모드
emacs 에서는 다양한 편집모드가 있다. emacs를 시작하면 화면 하단에 미니버퍼에서 현재 emacs의 모드상태를 표시해 준다. 기본적인 모드상태는 fundamental-mode 이다.

미니버퍼는 모드라인이라고도 불리며, 여러가지 정보를 표시해 준다. 맨 왼쪽에 나오는 --|-- 편집상태를 나타내는데, 별표(**)가 표시되면 수정상태이고 %%가 있으면 읽기전용상태를 뜻한다. 그 다음은 현재 파일명을 표시해주고, 파일명 옆으로 현재의 시간을 나타낸다. 시간 옆 괄호안에는 emacs의 모드 상태를 나타내고, L과 C는 지금 커서의 행과 줄의 위치를 표시한다. 맨 오른쪽에 All은 내용전체가 화면에 표시될 때를 나타내고, 파일의 꼭대기가 화면에 있으면 Top이라고 표시된다. 반대로 끝일경우에는 Bot라고 표시된다.

emacs의 모드는 주모드와 부모드로 나누어 진다.

주모드

부모드

이러한 여러가지 모드 중 자신이 사용할 모드를 적절히 골라 사용할 수 있다. 만일 모드를 바꾸고 싶다면, M-x 모드명 을 적고 엔터키를 치면 된다. 현재 fundamental 모드에서 text모드로 바꿔보자. M-x text-mode 를 적고 엔터키를 치면 text 모드로 전환된다.

그림 fundamental모드에서 text 모드로의 전환

Emacs 종료하기
앞서 Emacs 명령은 Ctrl, Meta(Alt) 키의 조합이라고 설명했을 것이다. 거의 모든 명령이 그렇게 이루어 진다고 보면 될 것이다. Emacs를 종료하고 빠져 나오기 위해서 C-x C-c를 연속적으로 입력하면 된다. (C-x와 C-c 란 Ctrl+x와 Ctrl+c를 의미하며 앞으로 나오는 Emacs의 명령은 이와 같은 형식으로 표시한다. Alt키와의 조합은 예) A-p 와 같이 나타낸다.)

Emacs help
Emacs 편집기가 약간 복잡하게 느껴질 것이다. 이것은 다양하고 풍부한 기능을 가진 Emacs 단점일 수도 있다. Emacs 는 자체적으로 방대한 온라인 도움말을 가지고 있다. Emacs에 대한 모든 명령 및 사용법을 배울 수 있다.

Emacs를 실행한 다음 C-h 키를 눌러보자

C-h 를 누르면 화면 하단의 미니버퍼 밑에 ? 입력하라고 나온다. ?를 입력하고 엔터키를 치면 다음과 같은 화면이 나온다.

Space 바와 Del 키를 이용하여 화면을 스크롤 하면서 help옵션에 대해서 읽어보자. help옵션 중 t 를 입력하여 Tutorial 를 선택해서 Emacs에 대한 기능을 공부하여 보자. 솔라리스 콘솔화면에서는 메뉴바의 help 를 선택하여 Emacs Tutorial를 누르면 바로 간다.

Emacs를 쓰면서 모르는 것은 그때 그때 Tutorial를 보면 많은 도움을 얻을 수 있을 것이다.

문서편집하기
이동하기
앞서 작성했던 emacs_test 파일을 열어보자.

가장 기본적인 커서의 이동은 화살표 키를 사용하는 것이다. 대부분의 유닉스시스템이 화살표키를 지원하지만 만일 어떠한 시스템이 화살표키를 지원하지 않을 때는 자체적인 emacs 이동명령을 사용한다.

오른쪽으로 한 칸 이동하려면 C-f 명령을 쓰면 된다. 왼쪽으로 한 칸 이동할 경우에는 C-b 를 입력하면 된다. 단어의 앞과 뒤로 이동하려면 M-f(A-f)와 M-b(A-b) 를 쓰면 된다. Alt키가 사용하기 불편한 경우에는 ESC 키를 누르고 나서 f나 b 를 입력하면 된다. ESC 키는 Alt 키를 누르는 것과 똑 같은 역할을 한다.

위의 emacs_test 파일을 만들고 상,하,좌,우로 마구 이동명령연습을 해보자.

다음은 Emacs의 이동명령을 정리해 놓은 것이다.

Emacs 이동명령어

한 화면씩 이동하기
파일의 길이가 긴 경우 한 화면씩 이동하여 파일의 내용을 볼 수 있다. C-v 전체 화면을 앞쪽으로 이동한다. ESC v 명령은 전체 화면을 뒤쪽으로 움직이다. C-l 명령을 한번 실행 해 보자. 이 명령은 화면을 지우고 모든 글자를 다시 화면에 표시하면서 커서가 중앙에 오게 하는 명령어이다.

삭제하기
간단한 삭제방법은 백스페이스()키를 사용하는것이다. 만일 백스페이스 명령이 적용 안될 때는 Del 키를 누르면 텍스트가 지워진다. Del키는 커서 앞의 한글자를 지운다. 커서 바로위의 글자를 지우기 위해서는 C-d 를 입력하면 된다.

Emacs도 vi와 마찬가지로 삭제방법이 다양하다. 줄, 단어, 문장 단위로등 여러가지 방법이 있다. 단지 명령어가 Ctrl과 Meta(Alt)키와 함께 이루진다는 것 뿐이다. 행 단위 삭제는 C-k로 그 줄의 끝까지 지운다. 단어 단위 삭제는 A-d(M-d)와 M-Del(A-Del)로 전자는 커서 다음에 나오는 단어를 삭제하고, 후자는 커서 앞에 나오는 단어를 지운다. 현재 위치에서 문장 끝까지 지우려면 M-k(A-k) 명령을 쓰면된다. 커서 위치부터 시작해서 이전문장까지의 삭제명령은 C-x를 누른후 Del를 바로 입력하면 된다.

Emacs 삭제 명령어

Undo
파일을 편집할 때 실수로 지우거나 입력하였을 경우 emacs 에서는 C-x u 명령으로 취소할 수 있다. C-x u 명령은 하나의 명령에 의해 하나씩 취소한다.

C-x u 명령을 한번 실행해 보자. 한번에 한글자씩 지우기 명령이 취소됨으로 s 자가 다시 복원된다. 미니버퍼 아래에 보면 지금실행하고 있는 Undo! 명령에 대한 상태를 보여준다

solaris 글자가 다 복원될 때 까지 C-x u 명령을 계속하여 여러 번 실행시켜보자.
C-x u 명령이 타이핑치기가 힘들다면 C- (C/)의 또 다른 Undo 명령이 있다. C-와 C/ 명령은 같은 것인데 단말기에 따라 적용되는 명령을 사용하면 된다.
emacs_test 파일에서 (2) 행의 I love solaris school 를 C-k 명령을 이용하여 삭제해 보자.
그리고 C- (C/) 명령을 실행시켜 보자. I love solaris school 이 복원되는 것을 볼 수 있을 것이다.

삽입하기
vi 와 달리 Emacs는 처음 시작부터 삽입모드가 실행된다. 달리 지정해 줄 필요가 없다. 삽입대신 덮어쓰기를 하려면 Overwrite모드를 사용하면 된다.
Emacs에서 특수문자를 삽입하려면 C-q 명령을 상용하면 된다. 예를 들어 Ctrl 를 삽입하려면 C-q 를 누른 다음 Ctrl 키를 삽입하면 된다.

파일 불러오기(찾기)
윈도우에서 저장되어 있는 다른 파일을 열려면 메뉴바의 파일의 열기(open)를 선택하면 된다. Vi 에서는 :e 파일이름 을 입력하면 된다. Emacs 에서는 C-x C-f 명령을 이용하면 된다. 콘솔에서 작업할 경우는 메뉴바에서 open file를 선택하면 된다.

open file를 선택하고 엔터키를 치면 emaca 아래 미니버퍼에 [ fild file:~/ ]메시지가 뜬다.

emacs_test파일을 불러와 보자.

C-x C-f 명령도 마찬가지이다. C-x C-f 명령을 입력하면 emacs 아래 미니버퍼에 [ fild file:~/ ]메시지가 뜨고 찾고자 하는 파일명을 써주고 엔터키를 치면된다. 이때 만일 찾는 파일명이 없으면 새로운 파일을 만든다.

Chapter 시스템 관리 I
NFS란?
NFS란 Network File System의 약자로서 1980년대에 썬 마이크로시스템즈에서 처음 개발되었고, 현재 리눅스나 솔라리스와 같은 유닉스를 비롯하여 윈도95/98과 윈도2000과 같은 운영 체제에서 널리 사용되고 있다. 그럼 NFS란 무엇인가? 간단히 말해서 어떤 한 시스템(클라이언트)에서 다른 시스템(서버)의 자원을 자신의 자원처럼 사용이 가능하도록 하는 것을 말한다. 이렇게 사용함으로써 자원의 낭비를 줄이고 효율적인 운영을 할 수 있기 때문이다. 리눅스를 어느 정도 다루었던 사람들은 NFS에 대한 개념을 쉽게 잡을 수 있을 것이다. 솔라리스에서의 NFS도 다를 바가 없다. 다만 설정상에 약간 차이가 있을 뿐이다.

NFS에 대한 개념도를 [그림 1]에 나타내었다. 그림에서는 NFS서버의 공유된 자원으로 디스크를 예로 설명된 것이다. 물론 디스크가 아니라 CD-ROM과 같은 것도 가능하다. NFS를 사용하려면 서버와 클라이언트 양쪽에서 몇 가지 설정이 필요하다. 서버의 설정이 완료되면 지정된 클라이언트에서는 단지 마운트를 통해 NFS서버의 자원을 자신의 자원인양 똑같이 사용하는 것이 가능하다. 이러한 NFS는 좋기만 한 것은 아니다. NFS로 서버와 클라이언트가 연결되어 있으면 NFS서버의 자원에 접근할 때마다 네트웍 트래픽이 걸리므로 속도면에서 많은 손실을 감안해야 한다는 점이다.

NFS는 여러 명이 같이 사용되는 대용량 프로그램이나 데이터들을 하나의 호스트에 넣어 두고 각 클라이언트들은 이 호스트의 데이터가 들어있는 디렉토리를 마운트하여 사용한다. 따라서 디스크 공간 면에서도 많은 절약을 가져올 수 있으며 각 각의 클라이언트마다 동일한 프로그램을 설치할 필요성도 없어지므로 관리면에서도 매우 편리해 진다. 그럼 NFS를 운영하기 위해서 NFS서버와 클라이언트에 필요한 데몬에 대해서 살펴보면 다음과 같다.

NFS 서버에서 사용되는 데몬

클라리언트가 NFS서버에 접근 요청을 하면 제일 먼저 mountd 데몬이 수행되어 /etc/dfs/sharetab파일을 참조한다. nfsd가 돌고 있다면 mountd를 꼭 데몬으로 실행해 주어야 정상적으로 NFS서버를 운영할 수 있다.

위의 데몬들은 모두 NFS서버를 사용하기 위해서는 필수적인 데몬들이며 run level 3에서 /etc/rc3.d/S15nfs.server라는 스크립트를 통해서 실행되며 이는 /etc/init.d/nfs.server와 같은 스크립트이다.

NFS 클라이언트에서 사용되는 데몬

위의 데몬들 또한 NFS서버에 접근하기 위해서 필수적인 NFS 클라이언트 데몬들이다. 이들은 모두 run level 2에서 /etc/rc2.d/S73nfs.client라는 스크립트를 통해서 실행되며 이 파일은 /etc/init.d/nfs.client와 같은 것이다.

NFS 서버
NFS 서버란 공유목적으로 파일 시스템과 같은 자원을 원격 호스트에게 네트웍을 통하여 제공하는 시스템을 말한다. NFS 서버를 세팅하기 위해서는 우선 공유하고자 하는 파일 시스템을 선택하고 이를 클라이언트가 NFS로 사용하도록 공유를 해줘야 한다. 공유하는 방식에 따라 수동 공유와 자동 공유가 있다.

수동 공유
수동 공유 설정은 'share'(/usr/bin/share)라는 명령어를 사용하며 'share'에 대한 사용법은 다음과 같다.

share [-F FSType] [-o specific_options] [-d description] [pathname]

-F : 파일 시스템 형태를 적어준다. 기본적으로 nfs로 인식한다. 따라서 command에서는
생략 가능하다.
-o : 클라이언트가 서버의 공유자원에 접근할 때 사용제한에 대한 옵션을 적어준다.

rw=client[:client]... ; 읽기와 쓰기 가능, client에는 네트웍 호스트 이름이나 ip를 입력
ro=client[:client]... ; 읽기만 가능
root=client[:client]... ; 지정된 클라이언트에게 root 퍼미션으로 해당 자원을 공유
anon=uid ; 지정된 uid로 해당 자원을 공유
-d description : 공유 자원을 설명하는 주석
pathname : NFS 서버측 공유자원의 절대 경로명

클라이언트의 루트 사용자가 만일 NFS 서버의 공유 자원에 쓰기를 하면 어떠한 UID와 GID로 기록이 될까? 언뜻 생각하면 보통과 같이 root:other(0:1)이라고 생각하기가 쉽지만 실제로 해보면 이렇게 기록이 되질 않는다. NFS 서버측에서는 클라이언트의 root를 nobody(uid=60001)로 인식을 하기 때문에 nobody:other로 기록이 된다. 만일 root의 uid가 0인 상태로 NFS서버로 접근하기를 원한다면 위에서 기술한 anon=0이라는 항목을 추가하면 된다.

다음 예는 share와 unshare에 대한 가장 간단한 사용법을 설명한 것이다. 여기서는 임시적으로 /data라는 디렉토리를 만들어 공유를 하였다. 공유 옵션은 사용하지 않았지만 기본적으로 rw옵션이 설정된다. 단순히 share라는 명령을 실행시키면 공유정보를 출력시켜준다. 하지만 아직 NFS 서버가 동작하는 것은 아니다. NFS 서버상에 현재 공유가 수행되는지에 대한 정보를 보려면 dfshares라는 명령어를 사용하면 된다. 아직 NFS 서버 데몬이 실행이 안되었으므로 dfshares 명령어를 실행하면 프로그램이 아직 등록이 안되었다고 나올 것이다. /etc/init.d/nfs.server start라는 명령어로 NFS 서버 데몬을 실행시키면 이제부턴 NFS 클라이언트에서 마운트를 통해 서버의 공유 자원을 사용할 수가 있게 된다. 공유가 더 이상 필요하지 않게 되면 unshare라는 명령어로 공유를 해지하고 데몬을 없애는 것은 /etc/init.d/nfs.server stop라고 하면 된다.

share명령어로 NFS 서버의 자원을 공유하면 해당 정보가 /etc/dfs/sharetab에 자동 저장되며 클라이언트가 접근을 하면 이 파일을 참조하여 허용 여부를 판단한다. 또한 share를 아무 옵션 없이 사용하면 자신의 공유 정보를 화면에 나타내 준다. 다음 표는 공유와 관련된 명령어들을 요약 정리한 것이다.

명령어 기능

옵션을 사용한 NFS 공유는 나중에 다시 다룰 것이다.

자동 공유
지금까지는 기본적으로 share라는 명령어를 사용하여 직접 공유를 수행하였다. 이렇게 수행된 자원 공유는 재부팅이 되면 공유된 정보가 사라지게 된다. 따라서 재부팅이 되어도 자동으로 공유가 되도록 하기 위해서는 /etc/dfs/dfstab파일에 공유 정보를 입력해주면 된다. 그럼 run-level 3로 들어갈 때에 dfstab 파일의 정보를 참조하여 공유를 수행한다.
dfstab파일에 공유 정보 입력은 위에서 share명령어를 사용했던 문장을 그대로 입력해 주면 된다. 다만 -F nfs옵션은 꼭 써주어야 한다. 위에서 설명한 예를 가지고 dfstab파일을 작성해 보면 다음과 같다.

이렇게 작성된 공유는 아직 NFS 클라이언트에서 마운트를 할 수 없다. 위에서 설명한 shareall이라는 명령어를 사용하여 자원을 공유해줘야 한다. shareall은 /etc/dfs/dfstab에 들어있는 공유 정보를 가지고 공유를 실행한다. 수동 공유때와 마찬가지로 공유를 수행한 다음 만일 현재 NFS 서버 데몬이 실행중이 아니라면 /etc/init.d/nfs.server start라는 명령어로 데몬을 실행시켜주어야 한다.

NFS 클라이언트에서 할 일
수동 마운트
NFS 서버의 공유 내용들을 클라이언트에서 사용하려면 서버에서 공유된 자원을 마운트해야 한다. 마운트할 때 사용되는 명령어는 mount이며 기본 사용법은 다음과 같다.

mount [ -F nfs ] [ -r ] [ -o specific_options ] server:pathname mount_point
-r : 읽기만 가능하게 마운트
-o : 일반적인 마운트 옵션 외에 NFS에서만 적용되는 옵션을 기술

마운트가 수행되면 해당 정보는 /etc/mnttab에 저장이 되며 마우트를 수행하는 시스템(NFS 클라이언트)에서는 해당 디렉토리에 접근할 때에 위의 파일내용을 참조한다.
간단한 마운트에 대한 예제를 전 장에서 설명된 NFS 서버에서 설정된 사항을 바탕으로 설명하겠다. NFS 서버의 도메인을 sola라 하고 공유된 디렉토리는 /data라고 하면, 다음 예와 같이 마운트를 하면 된다. 여기서 sola 대신에 NFS서버의 ip주소를 입력해도 무관하다.

마운트 대상 디렉토리는 로컬 시스템에서 항시 비어있어야 한다. 만일 내용이 있는 디렉토리를 마운트를 하면 에러가 발생할 수도 있으며 순조롭게 마운트가 수행되는 경우도 있다. 이것은 해당 디렉토리에서 어떠한 작업이든 사용중이면 장치 사용 중이라는 메시지가 나오며 마운트가 실패 된다. 만일 장치가 사용중이 아니라면 마운트는 수행이 되며 원래의 디렉토리에 들어있던 내용은 보이질 않게 된다. 하지만 지워지는 것은 아니니 안심해도 된다. 나중에 umount를 사용해서 마운트를 해제하면 원래의 파일들을 다시 볼 수 있을 것이다.

자동 마운트
수동으로 마운트 된 것은 시스템을 재부팅하면 마운트 정보가 사라지게 된다. 재부팅이 되어도 마운트 정보를 보존하고자 하면 /etc/vfstab라는 파일에 해당 마운트 정보를 입력하면 된다. /etc/dfs/dfstab과는 달리 여기에는 명령형태로 입력하는 것이 아니라 입력 방식이 따로 있다. 해당 파일을 열면 아마도 기존의 마운트 정보가 입력되어 있을 것이며, NFS 마운트 정보를 다음 예와 같이 추가 하면 된다. 입력시 주의할 점은 각 간격을 모두 tab으로 해야 한다는 점이다.

NFS 설정 예제
이번 절은 이제까지 설명된 내용을 바탕으로 몇 가지 옵션을 주고 NFS 서버와 클라이언트를 실제로 설정을 해보도록 하겠다. 다음 표는 예제로 사용될 NFS 서버와 클라이언트에 대한 정보이다.

NFS 서버
서버에서의 공유 자원으로는 /data/user1, /data/user2, /data/user3, /data/user4로 하며 모든 작업은 root권한으로 한다. 각 디렉토리는 서로 다르게 공유 옵션을 주었으며 해당 옵션에 대한 설명은 아래 표에 하였다.

/data/user1
/data/user2
/data/user3
/data/user4

sola2
읽고 쓰기 가능
읽기만 가능
읽고 쓰기 가능

root 권한으로 작업 가능
읽고 쓰기 가능

root 권한으로 작업 가능

sola3
읽고 쓰기 가능
읽고 쓰기 가능
읽고 쓰기 가능
읽고 쓰기 가능

root 권한으로 작업 가능

기타
공유 가능
공유 불가
공유 불가
공유 불가

/data/user1 디렉토리는 아무 옵션을 주지않고 공유를 한 것이다. 이러한 경우는 기본적으로 rw옵션이 제공되는 것이며 어느 클라이언트라도 공유하는 것이 가능하므로 이러한 설정은 가능하면 안하는 것이 좋다. /data/user2 디렉토리는 sola2에게는 읽기만 가능하게 설정을 하였고 sola3에게는 읽고 쓰기가 가능하게 설정한 것이다. 호스트를 구체적으로 지정하였으므로 sola2와 sola3 호스트를 제외하고는 NFS 서버의 공유 자원을 사용할 수 없다. /data/user3와 /data/user4는 NFS 클라이언트에서 root권한(UID=0)으로 작업하는 것이 가능하도록 한 것이며 다만, /data/user3는 sola2만 root권한 작업이 가능하고 /data/user4는 sola2와 sola3 둘 다 root권한으로 작업하는 것이 가능하다. 마찬가지로 호스트를 구체적으로 지정하였으므로 다른 클라이언트에서는 마운트해서 사용하는 것이 불가능 하다.
이렇게 설정을 하고 NFS 클라이언트에서 마운트해서 쓰려고 하면 가능할까? 정답은 불가능 하다이다. 그 이유는 처음 디렉토리를 생성하면 디렉토리 퍼미션이 755로 되어있는데 이 퍼미션으로는 루트를 제외하고는 쓰기가 불가능하다. 즉 sola2는 /data/user3와 /data/user4에서 루트로만 쓰기가 가능하며 다른 계정으로는 쓰기가 불가능하고, /data/user1과 /data/user2에서는 클라이언트에서 루트로 사용을 하려고 해도 uid가 nobody로 되기 때문에 쓰기가 불가능하다. 이 부분은 각자 실제로 그렇게 되는지 한번 테스트 해보도록 하고 이를 정상적으로 사용하기 위해서는 디렉토리 퍼미션을 777로 바꾸어주기 바란다.

NFS 클라이언트
NFS 클라이언트에서 해주어야 할 일은 각 디렉토리(마운트 포인트)를 만들고 NFS 서버에서 공유된 자원을 마운트 해주어야 하는 일이다. 여기서는 수동 마운트와 자동 마운트에 대해서 설명할 것이다. sola2는 수동 마운트를 사용하였으며, sola3는 자동마운트를 사용하였다. 둘 다 어느 것을 사용하여도 상관은 없다.

수동 마운트
수동 마운트는 mount라는 명령어를 사용하여 단순히 서버측 호스트와 공유디렉토리를 명시하여 주고, 클라이언트 쪽에 마운트 포인트만 지정하여 주면 된다.

자동 마운트
자동 마운트는 /etc/vfstab이라는 파일에 직접 마운트할 내용을 써주어서 /etc/init.d/nfs.client start라는 명령어를 통해 마운트가 실행이 된다. 또한 재부팅이 된다 하여도 부팅시 /etc/vfstab라는 파일을 참조하여 각 디렉토리를 마운트하게 된다. /etc/vfstab에는 기존의 파일시스템에 대한 마운트 내용이 들어있으므로 가능하면 손대지 말고 마지막 줄에 추가 내용만 써주도록 하면 된다.

패키지 개요
패키지에 대한 소개
각 OS마다 설치를 쉽게 해주는 툴들이 있다. 리눅스 레드헷에서는 rpm이라는 툴을 사용하며 MS 윈도우에서는 install.exe혹은 setup.exe를 통하여 설치를 쉽게 해주는 것처럼 솔라리스에서도 이와 비슷한 툴을 제공한다. 솔라리스에서는 패키지라고 하여 pkgadd나 pkgrm가 같은 명령어를 사용하여 패키지를 설치하거나 지우곤 한다. 이러한 OS에서 응용프로그램들을 패키지 단위로 만드는 가장 큰 목적은 설치와 제거를 쉽게 하기 위해서이다. 응용프로그램의 소스를 컴파일하여 설치를 할 경우 설치된 곳에 다른 응용프로그램도 같이 들어있을 가능성이 크다. 나중에 이러한 프로그램을 다시 삭제할 필요가 생겼을 때 해당 응용프로그램만 지운다는 것은 거의 불가능에 가깝다고 볼 수 있다.
하지만 이러한 패키지를 이용한 설치가 항상 좋은 점만 있는 것은 아니다. 우선 패키지의 배포수가 미비하다는 점이다. 자신이 필요로 하는 프로그램이 항상 패키지로 제공이 된다고 보장할 수는 없는 노릇이기 때문이다. 솔라리스를 사용하는 사람이라면 자주 애용하는 사이트가 있다. 패키지와 그에 해당하는 소스를 제공해주는 사이트인데 주소는 http://www.sunfreeware.com 이다. 이곳에 들어가 보면 알겠지만 리눅스에서 제공되고 있는 패키지(rpm)에 비하면 그 양이 매우 미비하다. 하지만 자주 사용되는 왠만한 패키지는 갖추고 있으므로 잘 이용하면 유용한 사이트다.

두 번째로 패키지가 갖고 있는 한계점이라고 할 수 있는 것이 있다. 패키지는 패키지 제작자가 자신의 환경에 맞게 제작을 한 관계로 사용자가 마음대로 그 환경을 바꿀 수가 없다. 예를 들면 설치경로를 마음대로 지정해줄 수가 없다는 점이다. 솔라리스 Companion CD에 있는 패키지를 설치해본 사람은 알겠지만 여기에서 제공되는 패키지는 모두 /opt/sfw 밑에 설치가 되며 위에서 언급한 사이트에서 제공되는 패키지들은 /usr/local 밑에 설치가 된다. 이렇듯 약간 일관성이 없는 면이 있다. 만일 사용자가 특정 옵션이나 혹은 특정 설치 경로를 원한다면 소스를 직접 컴파일 해야 한다. 만일 이러한 프로그램이 자주 사용되거나 여러 컴퓨터에 설치하고자 한다면 나중에 설명될 패키지 제작을 익혀서 본인만의 패키지를 만들어보는 것도 좋은 방법이 될 것이다.

패키지 구성요소
패키지를 설치하는 방법을 설명하기에 앞서 우선 패키지가 어떻게 구성되는지를 알아볼 필요가 있다. 본 절에서는 이러한 패키지 구성요소에 대해서 설명한다. 패키지는 크게 필수적인 구성 요소와 선택적인 구성 요소로 나누어진다. 필수적인 구성 요소에는 패키지의 주된 내용물인 패키지 오브젝트, 패키지의 정보를 가지고 있는 파일(pkginfo), 패키지 오브젝트의 파일 정보 및 설치 위치에 대한 정보를 가지고 있는 파일(prototype)이 있다. 선택적인 구성요소에는 compver, depend, space, copyright등과 같은 정보제공 파일과 설치 시 수행되는 스크립트파일인 request, checkinstall, Procedure, Class Action등이 있다. [그림 1]은 이러한 패키지의 구성요소에 대해 잘 요약한 것이다.

필수적인 패키지 구성요소
패키지 오브젝트
패키지 오브젝트란 실행파일을 포함하여 소스를 컴파일할 때 생성되는 모든 파일과 디렉토리를 지칭하는 것이다. 따라서 패키지를 구성하는 요소로서 가장 중요하며 설치가 될 실제 파일들이다. 패키지 오브젝트에 있는 주된 내용물은 실행 파일, 데이터 파일, 디렉터리, named pipe, 링크, 디바이스 파일 등 여러 파일들이 있다. [그림 2]는 EB2Igftp라는 패키지의 오브젝트 파일의 구조를 보여주고 있다.

pkginfo 파일
패키지에 대한 전반적인 어떤 파라미터 값들을 정의한 파일로 여기에 사용되는 파라미터는 PKG, ARCH, NAME, VERSION, DESC, VENDOR, BASEDIR, CATEGORY, CLASSES 등이 있다.

이밖에도 사용자가 임의적으로 pkginfo파일에 어떤 내용들을 정의해줘도 상관은 없다. 실제 패키지에 사용된 pkginfo파일을 다음 예에 나타내었다. 밑의 예제는 EB2Igftp라는 패키지의 pkginfo를 나타낸다.

prototype 파일
패키지가 구성하고 있는 파일들에 대한 리스트로 각 각의 위치와 속성 및 타입을 기술하고 있다. prototype파일에 들어가는 내용의 양식은 다음과 같다.

part ftype class path major minor owner group

part : 패키지 오브젝트들을 그룹화를 해주는 번호를 입력하는 것으로 기본 값은 1이며 옵션이다.
ftype : 이 필드에는 한 문자만 입력하는 것으로 패키지 오브젝트의 타입이 입력된다.
종류는 아래 표를 참조하길 바란다.
class : 패키지 오브젝트가 지니는 class를 입력해준다. 일반적으로 none이 입력된다.
path : 절대 경로 혹은 상대 경로가 입력된다.
major : block 혹은 character special device에 대한 major device number가 입력된다.
minor : block 혹은 character special device에 대한 minor device number가 입력된다.
mode : 오브젝트 파일의 mode, 예를 들면 0755와 같이 입력된다.
owner : 패키지 오브젝트의 소유자, 예를 들면 root와 같이 입력된다.
group : 패키지 오브젝트의 그룹, 예를 들면 bin과 같이 입력된다.

그럼 실제로 prototype 파일이 어떻게 생겼는지 아래에 있는 예제 표를 보면서 이해하길 바란다. 아래 예는 EB2Igdb 패키지에 대한 prototype파일을 나타낸다. 실제 내용은 여기서 나타낸 것보다 더 길다.

선택적인 패키지 구성요소
패키지 구성요소 중에서 패키지를 구성하는데 꼭 필요한 요소는 아니지만 어떠한 정보나 설치를 도와주기 위한 것들이 있는데 이러한 것들에는 설치하려는 패키지와의 의존 관계에 대한 정보를 지니는 depend 파일, 버전에 대한 정보를 지니는 compver 파일, 소스 파일들에 대한 copyright정보를 지니는 copyright 파일 등이 있다. 이러한 정보를 제공해 주는 파일 이외에 설치 스크립트를 제공해줌으로써 설치할 때 설치자로부터의 어떠한 입력을 필요로 하거나 할 때에 사용되는 패키지 설치 스크립트라는 것이 있다. 이들 정보 파일이나 설치 스크립트들은 패키지 설치에 어떠한 정보나 옵션을 제공해 주며 패키지 구성에 반듯이 필요한 것은 아니다.

depend 파일
depend파일은 패키지의 의존성을 나타내주는 파일로 여기에 입력된 정보는 단순히 패키지 설치 시에 정보를 출력시켜줄 뿐이다. depend파일에서 사용되는 형식은 다음과 같다.

type pkg-inst pkg-name

type : 디펜던시 타입을 정의해준다. 여기에는 P(prerequisite package), I(incompatible
package) 및 R(reverse dependency)중 하나가 지정 되야 한다. 일반적으로 P가 보통
사용된다.
pkg-inst : 패키지의 인스턴스명을 적어주는 곳으로 EB2Igftp와 같은 이름이 들어간다.
pkg-name : 패키지의 이름을 적어주는 곳으로 pkginfo파일의 NAME의 값을 써준다.

다음 예는 EB2Igftp의 depend파일을 나타낸다. gftp는 EB2Igtk+라는 패키지가 있어야 실행이 되므로 depend라는 파일을 통해서 설치자에게 해당 정보를 제공해 줄 수 있다. EB2Igftp의 depend파일은 다음의 예와 같이 쓸 수 있다. 이렇게 정의를 하면 패키지 설치지 경고 메시지가 나타나지만 패키지 설치하는 사람은 이 경고 메시지를 무시하고 설치할 수가 있다.

compver 파일
compver파일은 현재 패키지의 이전 버전을 정의해주는 파일이다. 버전의 정의는 이미 설치된 패키지의 pkginfo파일에서 VERSION정보를 참조하여 같은 형식으로 써준다.

다음 예는 임의로 만든 compver파일을 나타낸다.

위의 수치들은 모두 해당 패키지 pkginfo파일의 VERSION에서 정의된 값을 뜻한다.

space 파일
prototype 파일에 정의된 오브젝트를 위한 공간 이외에 목표 시스템에 필요한 디스크 공간을 정의해 주는 파일이다. depend파일에서 사용되는 형식은 다음과 같다.

pathname blocks inodes

pathname : 디렉토리 경로명을 정의해준다.
blocks : 필요한 디스크 공간을 512바이트의 배수로 정의한다.
inodes : 필요한 inodes의 수를 정의한다.

위의 예는 목표 시스템의 /usr/local이라는 경로에 한 개의 inode와 3000*512바이트의 block수를 정의한 것이다.

패키지 사용 방법
패키지 설치
pkgadd
맨 처음 인터넷을 통해 패키지를 다운로드받으면 아마도 filename-version-sol8-arch-local.gz이라는 파일형식을 갖고 있을 것이다. gz는 알다시피 gzip으로 압축된 것을 의미하며 local은 파일이 패키지 형태를 지니고 있다는 의미이다. arch는 머신의 종류를 의미하며, 보통 intel과 sparc 두 가지가 있다.

다운로드 받은 패키지를 설치하려면 우선 gzip을 이용하여 압축을 풀고 pkgadd 명령어를 사용해서 설치한다. 유일하게 gzip으로 압축되지 않은 패키지가 하나 있다. 그것은 gzip패키지이다. 그 이유는 gzip패키지를 압축해놓으면 어떻게 gzip을 풀 수 있겠는가.

pkgadd에 대한 여러 옵션 중에서 가장 기본적이며 많이 쓰이는 것은 -d옵션이다. 이를 사용하지 않으면 패키지를 설치하지 못한다. pkgadd에 대한 설치 옵션을 살펴보면 다음과 같다.

pkgadd -d device-name [-R root_path] [pkginst]

-d device-name : 패키지의 위치를 기술한다. device-name은 tape, floppy disk, 삭제 가능한
디스크의 절대 경로 또는 identifier를 기술한다. 만일 패키지의 위치를
기술하지 않을 경우 default spool directory(/var/spool/pkg)에서 찾는다.
-R root_path : root 경로로 사용하기 위한 디렉토리의 full path name을 정의한다.
-s spool : 패키지를 설치하는 대신 패키지 인스턴스를 spool 디렉토리에 설치한다.
pkginst : 설치할 패키지 인스턴스나 인스턴스의 리스트를 써준다.

그럼 실제 예를 통해서 패키지를 설치해보도록 하자. gdb-5.0-sol8-intel-local.gz이라는 패키지 파일이 가 자신의 디렉토리인 /export/home/ebee에 있다고 가정을 하자. 물론 자신의 컴이 스팍일 경우에는 gdb-5.0-sol8-sparc-local.gz 이라는 패키지 파일을 설치해야 할 것이다.

copyright와 설치정보가 화면에 나타나면서 설치되는 상황을 볼 수 있을 것이다. 설치 경로는 패키지를 제작한 사람이 어떻게 패키지를 만들었느냐에 따라 다르지만 보통 /opt밑이나 /usr/local에 설치가 되는 것이 기본이다. 설치중 무슨 메시지가 나타나면 잘 읽어보고 yes나 no혹은 quit를 선택하면 된다. 일반적으로는 그냥 엔터를 치면 ok다.

위의 패키지를 설치를 했는데 gdb라는 명령어가 실행이 안된다면 무슨 이유일까? 그건 자신의 환경설정 파일에 해당 경로명을 정의해주지 않았기 때문이므로 설정을 수행해주면 잘 실행이 될 것이다.

패키지 설치시 한가지 더 주의할 점은 비록 설치되는 패키지가 사용자의 현재 디렉토리에서 작업을 할지라도 패키지 설치와 제거는 root만이 할 수 있는 명령어이다. 따라서 ebee라는 계정을 가진 사용자가 pkgadd명령어를 사용하여 패키지를 설치하려고 하면 다음과 같은 에러메시지가 나타날 것이다.

이와 같은 설치는 일반적인 경우이며(인터넷이나 ftp로 패키지 파일을 다운로드 받은 경우) 후에 설명될 패키지 제작에서 나오는 패키지 파일 이전 단계인 패키지 인스턴스를 설치하는 방법도 알아둘 필요가 있다. EB2Igdb라는 패키지 인스턴스를 설치하는 방법은 다음과 같다.

위의 예에서는 /export/home/ebee라는 디렉토리 밑에 EB2Igdb와 EB2Igftp라는 두 패키지 인스턴스가 존재하는 경우에 설치하는 예를 보여준 것이다. 예에서 보다시피 패키지 인스턴스가 두 개가 있으면 어느 것을 설치할 것인지 아니면 둘 다 설치할 것인지를 물으며 이 때 사용자는 설치하고자 하는 패키지의 번호를 입력하거나 모두 설치하고자 하면 all을 입력하고 엔터를 누르면 된다. 옵션에서 -d다음에 .을 입력하였는데 그것은 현재의 디렉토리를 의미하는 것이며 만일 디렉토리 경로를 표시하지 않으면 /var/spool/pkg에서 패키지 인스턴스를 찾는다. .다음에 패키지 인스턴스명을 써주지 않은 경우에는 위와 같이 어떠한 패키지를 설치할 것인지를 묻는다. 이러한 질문이 귀찮으면 경로명(.)다음에 해당 패키지 인스턴스명을 써주면 된다. 이렇게 패키지 인스턴스를 설치하는 경우는 보통 패키지가 여러 개이면서 설치 순서가 중요한 경우에(의존성 때문에) 사용된다. 일례로 썬사에서 제공되는 SDK와 같은 경우가 좋은 예이다. 뒤에 SDK의 설치에 대해서 다루었다.

패키지 정보 보기
pkgchk
pkgchk라는 명령어는 설치된 파일의 정확성을 검사한다. 검사 대상으로는 file permission, ownership, block 또는 character의 major/minor, file size, checksum, modification date등이 있다. 명령어 사용시 -l옵션을 사용하면 설치된 패키지의 모든 파일에 대한 정보를 화면에 출력한다.

pkgchk [-l | -v] [-R root_path] [pkginst]

-l : 패키지가 설치된 파일들에 대한 자세한 정보를 제공한다.
-v : 검사한 파일의 리스트를 제공한다.
-R root_path : root 경로로 사용하기 위한 디렉토리의 full path name을 정의해준다.
Pkginst : 패키지 인스턴스 이름이나 인스턴스의 리스트로 만일 생략할 경우 모든 가능한
패키지를 체크한다.

여기서 -v옵션과 -l옵션은 같이 사용할 수 없다. 두 개의 옵션을 사용하여 나온 결과를 보면 다음과 같다.

pkginfo
pkginfo는 설치된 패키지의 데이터 베이스로부터 정보를 화면에 출력시키는 명령어이다. 앞에서 설명된 pkginfo파일은 패키지를 구성하는데 사용되는 정보 파일이며 여기서 설명되는 pkginfo는 명령어이다. pkginfo를 옵션없이 사용할 경우 시스템에 설치된 모든 패키지 인스턴스와 카테고리 등의 정보를 출력한다.

pkginfo [-x | -l] [pkginst]

-x : extracted format의 패키지 정보를 출력한다.
-ᅵ : long format의 패키지 정보를 출력한다.

pkgparam
pkgparam이라는 명령어는 명령어 줄에 기술한 파라미터의 값을 출력해주며 출력되는 값은 패키지 인스턴스에 있는 pkginfo라는 파일의 내용에 있는 값이다. 명령어 줄에 파라미터 값을 기술하지 않을 경우에는 패키지에 대한 모든 파라미터 값을 출력한다.

pkgparam [-v] pkginst [param]

-v : 파라미터의 이름과 값을 출력한다. 이 옵션을 사용하지 않으면 값만 출력된다.
param : 값을 출력할 하나 이상의 파라미터를 기술한다.

패키지 삭제
pkgrm
pkgrm은 설치된 패키지를 지우는 명령어이다. 이 명령어는 제거할 패키지가 다른 패키지와 의존 관계를 가지고 있는지 의존성 검사를 하고 의존 관계를 가지고 있을 경우에는 admin파일에 정의된 작업을 수행한다. pkgrm 명령을 쓸 때 대상으로는 항상 패키지 인스턴트명(package instance name)이 와야 한다. 즉 EB2Igftp와 같은 것을 써줘야 한다. 일반적으로 pkginfo 명령어를 사용해서 지우고자 하는 패키지의 인스턴스명을 알아낸 다음에 지운다.

pkgrm [-d device-name] [-R root_path] [pkginst]
or
pkgrm -s spool [-d device-name] [pkginst]

-d device-name : 제거할 패키지의 위치를 기술한다.
-R root_path : root 경로를 사용하기 위한 디렉토리의 full path name을 정의한다.
-s spool : spool된 패키지의 제거를 위한 디렉토리를 기술한다.

다음의 예는 gdb라는 패키지를 지우는 방법을 예를 들어 설명한 것이다.

사용자 계정 관리
관리자가 해야할 일 중에 가장 기본적이라고 할 수 있는 것이 바로 사용자의 계정을 관리하는 것이다. 관리자는 필요한 계정을 등록 해야하고 필요하면 삭제도 해야한다. 여기서는 이러한 계정 등록과 삭제에 관한 내용을 살펴볼 것이다.

사용자 계정 등록하기
사용자 계정을 등록하는 방법에는 여러 가지가 있지만 그 중에서 두 가지를 여기서 설명하겠다. 먼저 GUI환경에서 제공해주는 admintool이라는 명령어를 이용하여 등록이 가능하며 useradd라는 터미널 상에서의 명령어를 사용해서 계정을 등록할 수도 있다. 일반적으로 관리자는 admintool은 한 두 명의 사용자를 등록하기에는 편리하지만 여러 명의 계정을 등록하려면 아무래도 useradd명령어를 사용해서 하는 것이 더 편리하다.

admintool
admintool을 사용하는 것은 해당 메뉴를 보면 사용하기가 쉬울 것이다. Admintool을 수행하면 3개의 풀다운 메뉴가 보일 것이다.
File은 하위 메뉴로 종료(Exit)하는 기능의 메뉴가 있으며
Edit는 창에 있는 항목을 선택하여 추가(Add), 수정(Modify), 삭제(Delete)하는 기능의 메뉴가 있고
Browse 메뉴가 어떠한 기능을 제공하는지 다음 표에 나와있다.

useradd
useradd는 터미널 모드에서 사용하는 명령어로써 자주 사용되는 옵션은 숙지하여야 한다.
useradd [-c comment] [-d dir] [-e expire] [-f inactive] [-g group]
[-G group [, group...]] [-m [-k skel_dir]] [-u uid [-o]] [-s shell]
[-P profile [, profile...]] login

useradd 명령어의 사용 예를 보자.

일반적으로 사용되는 옵션을 이용해서 사용자를 등록한 예이다. -m 옵션은 홈 디렉토리가 존재하지 않을 경우 생성시키는 옵션이다. 모든 옵션을 생략하고 다음과 같이 간단히 사용자를 등록할 수도 있다.

이렇게 하면 단지 ebee라는 사용자 계정만 만들어질 뿐이고 홈디렉토리는 만들어지지 않는다. UID는 가장 큰 UID다음번호가 등록이 되며 GID는 1(other)로 등록이 된다. 그리고 쉘은 본쉘(/bin/sh)이 기본적으로 세팅이 된다.

등록해야할 사용자가 많을 경우에는 간단한 쉘 스크립트를 사용하여 사용자 등록을 자동적으로 해줄 수도 있다. /etc/passwd에 단순히 편집모드에서 사용자를 추가했을 경우에도 계정 등록이 가능하다 하지만 /etc/shadow에도 추가되어야 하므로 다음과 같은 명령어를 사용하여 /etc/shadow에도 추가해준다.

pwconv(/bin/pwconv)명령어는 /etc/passwd파일을 참조하여 /etc/shadow파일을 갱신해준다.

사용자 계정 삭제하기
유효기간이 지난 사용자나 필요 없는 사용자가 존재하면 가능하면 보안상 즉시 삭제를 해주는 것이 좋다. 삭제하는 방법은 마찬가지로 admintool을 사용할 수도 있지만 여기서는 userdel이라는 명령어를 사용하겠다.

-r 옵션은 사용자가 사용했던 홈 디렉토리까지 삭제하라는 옵션이다.

삭제 후 제대로 삭제되었는지를 확인하려면 /etc/passwd와 /etc/shadow를 확인해서 해당 login id가 존재하는지를 확인해보면 된다.

그룹 추가하기
그룹추가도 마찬가지로 적은 수의 그룹 관리이면 admintool을 사용해도 무난하다. 만일 그룹수가 많아지면 groupadd라는 명령어를 사용한다.

groupadd [-g gid [-o]] group

'-g gid'옵션은 GID(정수)를 써주는 부분이며 -o 옵션은 GID의 중복 사용을 허용해주는 옵션이다.

이렇게 solaris라는 그룹이 100이라는 GID로 등록이 되며 이는 /etc/group에 저장이 된다.
/etc/group이라는 파일을 보면 네 개의 필드가 존재한다. 첫 번째 필드는 그룹명, 두 번째 필드는 passwd, 세 번째 필드는 그룹의 실제 ID(GID), 네 번째 필드는 해당 그룹의 사용자 목록이다.

그룹 삭제하기
그룹 삭제는 groupdel이라는 명령어를 사용하면 된다. 사용법은 다음과 같다.

groupdel group

여기서 group은 그룹명을 적어주면 된다.

사용자 패스워드
패스워드 파일(/etc/passwd)은 사용자들에 대한 정보를 지닌 파일로 각 라인마다 7개의 필드로 구성되어 있다.

[사용자 계정]:[암호]:[사용자 ID]:[그룹 ID]:[주석]:[홈 디렉토리]:[로그인 쉘]

위에서 ebee라는 계정을 만들었을 때 /etc/passwd에는 다음과 같이 추가가 된다.

여기서 암호필드에 x라고 되어있는데 이는 shadow 파일을 사용하겠다는 의미이다. 예전에는 이곳에 사용자 암호를 암호화한 내용이 들어있었지만 보안상의 문제로 요즘에는 보통 /etc/shadow에 넣어둔다. 그리고 이 shadow파일은 일반사용자는 열람이 불가하게 기본 설정이 되어있다. 나머지 필드는 이해하는데 별 어려움이 없을 것이다. 참고로 주석(comment) 필드는 생략 가능하다.
passwd파일에서 UID가 0이면 root(관리자)를 의미하며, UID와 사용자 계정은 중복해서 사용할 수가 없다. 또한 UID, GID는 항상 숫자로 나타내어야 한다.

솔라리스 부팅 과정의 이해
유닉스 부팅의 개요
부팅이란?
컴퓨터에서 부팅 이란 시작한다는 뜻으로 통용되는 용어이며, Bootstrapping 의 줄임말이다. Bootstrap이란 장화(부츠)를 손쉽게 신기 위해 잡아당길 수 있도록 되어 있는 손잡이가죽을 말하며, 결국 bootstrapping은 장화를 신듯이 시스템이 운영할 수 있는 준비를 하는 것을 뜻한다.

boot 과정
일반적인 UNIX의 부팅 과정에서 진행되는 일은 다음과 같다.

- Kernel의 loading 과 initialization
- Device detection 과 configuration
- System process 의 생성
- Operator intervention(single-user boot에서만 가능함)
- System 시작 스크립트 수행
- Multi-user operation

x86 계열의 부팅과정으로, 보다 구체화 시키면 다음과 같다.

- 전원이 들어오면 일단 BIOS가 시스템 하드웨어에 문제가 없는지 테스트한다.
- 첫번째 하드 디스크의 MBR(Master Boot Record)의 프로그램이 Partition Table을 검사하여 활성화(active)된 파티션의 부트 섹터를 읽어 그 코드를 실행한다. 해당 코드는 커널을 메모리로 읽어 들이는 역할을 한다.
- 커널은 자료구조를 초기화하고 필요한 커널 모듈을 읽어 들인다.
- Root file system 을 mount 한다.
- init 프로그램을 수행한다(init 프로그램이 다양한 스크립트를 수행하여 multi-user mode로 전환하게 된다).

초기 프로세스의 생성
커널이 메모리에 올라오고 초기화 작업이 끝나는 시점에서 사용자 메모리 영역에 몇 개의 자발적(spontaneous) 프로세스(fork와 같은 방법으로 만들어지는 것이 아닌 프로세스)를 만든다. BSD계열에서는

- swapper : process 0
- init : process 1
- pagedaemon : process 2

등이며, System V 계열에서는

- sched : process 0
- init : process 1
- memory handler(각 시스템마다 차이가 있음)

등의 이름을 가지고 있다. 몇몇 초기 프로세스의 생성이 끝나면, 부팅 에 관한 커널의 임무는 여기서 끝나고 나머지 부팅 과정은 init process 가 주도한다.

시작 스크립트
init 는 각종 스크립트를 수행하여 시스템 운영 환경을 구축한다. 스크립트의 수행구조는 BSD계열과 System V 계열이 약간 차이가 있다.
BSD계열은 /etc 하위에 rc 로 시작하는 파일들이 수행되는 스크립트이며, System V계열은 /etc/init.d 하위에 시작 스크립트들이 존재하고 이중 필요한 것들이 /etc/rc0.d, /etc/rc1.d 등의 디렉토리에 링크되어 사용된다.
어떤 시스템이든 시작 스크립트는 대략 다음과 같은 일들을 한다.

- 컴퓨터의 이름 setting
- time zone setting
- 시스템의 디스크들을 mount
- network interface를 configuration
- 각종 daemon 과 network service 를 시작

우리는 솔라리스가 따르고 있는 System V 방식의 시작 스크립트에 대해 자세히 알아보도록 하겠다.

run level
System V 계열의 init daemon 은 run level 이라는 것을 지원한다. Run level은 시스템 자원을 서로 다르게 조합하여 운영하는 것을 가능케 하는데 시작 스크립트도 이에 따라 여러 부분으로 나누어져 있다.

System V에서는 다음과 같이 8개의 run level 을 제공한다.

솔라리스의 부팅
솔라리스 부팅의 개요
솔라리스는 다음과 같은 네 단계를 거쳐 부팅이 수행된다. 일단 BIOS 단계에서 시스템의 하드웨어적인 이상유무를 판단하고, MBR을 읽어 들이고, 커널을 인식시킨 후에 init 프로세서를 통해 부팅을 마무리 하게 된다. 그럼 각 과정에 대해 조금 더 깊이 들어가 보자.

BIOS 단계
시스템의 전원을 켰을 때 BIOS 는 시스템에 H/W와 메모리를 검사하기 위해 Self-test를 실시한다. 에러가 발견되지 않았을 경우, BIOS는 첫번째 부트 섹터(MBR)에 저장된 mboot를 메모리에 적재하고 수행한다.

boot program 단계
mboot는 활성화(active)된 파티션을 찾아서, pboot를 메모리에 적재하고 수행시킨다. 그리고 pboot는 디스크 안에 있는 secondary boot program을 메모리에 적재하기 위한 primary boot proram인 bootblk을 메모리에 적재한다. 기본적으로 파란 화면에서 10초간 기다리도록 설정되어 있는데, 부팅 가능한 파티션이 여러 개라면 이 화면에서 선택하여 부팅을 할 수 있다. Bootblk는 secondary boot program 인 boot.bin 이나 ufsboot 를 찾아 수행하는데, boot.bin 이나 ufsboot는 /etc/bootrc 스크립트를 수행하기 위해 command interpreter를 시작한다.

커널 인식 단계
core kernel 이 메모리에 올라온 이후 자신의 데이터 구조를 초기화하고, 모듈들을 메모리에 적재한다. 필요한 모듈을 불러온 이후에 커널은 /sbin/init 프로그램을 수행한다.

init 단계
커널에서 init 를 호출한 이후부터는 init 프로세스가 /etc/inittab 파일의 내용을 바탕으로 마지막 부팅 작업을 하기 시작한다.

각 run level 별로 수행되는 디렉토리와 파일을 알아보고, 특히 우리가 일반적으로 사용하는 run level 3 이 수행되는 경우에 대해서 심층있게 알아보도록 하자.
/etc/ 디렉토리 아래에는 다음과 같은 파일들이 존재하는데 그림으로 알아보도록 하자.

run level 들이 명시되어 있는 파일인 /etc/inittab 파일을 조금만 살펴 보도록 하자.

sS:s:wait:/sbin/rcS >/dev/msglog 2<>/dev/msglog
s0:0:wait:/sbin/rc0 >/dev/msglog 2<>/dev/msglog
s1:1:respawn:/sbin/rc1 >/dev/msglog 2<>/dev/msglog
s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog
s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog
s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog
s6:6:wait:/sbin/rc6 >/dev/msglog 2<>/dev/msglog

위의 내용은 /etc/inittab 파일의 중간 부분을 발췌한 것이다. 눈치가 빠른 사람은 금방 알아챘겠지만, s3로 시작하는 부분이 run level 3일 경우에 관련된 부분이다. 따라서 run level 3일 경우에 /sbin/rc3를 실행하게 된다.
물론 inittab 파일 안에 보면 전후에 실행되는 default 필드들이 있으나 여기서는 생략하도록 하겠다.

그럼 /sbin/rc3 파일을 살펴보도록 하자.

위의 파일 역시 중간 부분을 발췌하였다. 이 부분은 /etc/rc3.d 디렉토리의 여러 데몬들을 구동시키는 스크립트인데, 보는 바와 같이 /etc/rc3.d 디렉토리의 파일들 중에 S로 시작하는 파일에는 start 인수를 넘겨서 시작하도록 하고, K로 시작하는 파일들은 stop 인수를 넘긴다. 한번 자신의 /etc/rc3.d 디렉토리를 살펴보고 파일명을 살펴보도록 하자.

run level 바꾸기

run level 을 바꾸는 방법에는 여러가지가 있다. 그 중에 유용하게 쓰이는 init 명령을 살펴보도록 하자.
지금 우리가 디스크에 문제가 생겨서, single-user mode 로 부팅을 했다고 가정하자. 문제를 해결하고 원래대로 부팅을 하고 싶은데 우리는 reboot 작업을 거쳐야 할까? 물론 아니다. 다음과 같이 명령을 내리면 된다.

위의 명령으로 run level 3로 들어가게 할 수 있다.
숫자 부분에 올 수 있는 인수로는 0, 1, 2, 3, 4, 5, 6, s 가 있다.

CDE 개요
초기 Unix는 컴퓨터에 엑세스하는 방식으로 커맨드 형식을 사용한 텍스트 환경이었다. GUI(Graphic User Interface)는 이러한 커맨드 액세스 방식이 아니라 컴퓨터와 사용자가 대화하는 방식의 인터페이스를 말한다. GUI는 미국 제록스사의 스타워크스테이션이 처음 도입하였고, 1984년에 애플사의 매킨토시가 PC에 탑재하는 것을 계기로 GUI환경의 컴퓨터가 보급되기 시작하였다. MS에서는 윈도라는 이름으로 GUI환경의 OS를 개발하였고, Unix에서는 X-window라는 것을 기반으로 하여 여러 데스크탑에 적용되어져 왔다. 현재는 거의 대부분의 OS가 GUI환경이기 때문에 PC사용자들은 GUI가 어떤 것인지 감은 잘 올 것이다.

리눅스에서는 주로 KDE(K Desktop Environment)아니면 GNOME(GNU Network Object Model Environment)을 데스크탑 환경으로 사용하고 있으며 일반 사용자들이 보기에 이 둘은 매우 유사하게 느껴질 것이다. 하지만 KDE는 QT 툴킷을 기초로 하여 개발되었고 GNOME은 오픈소스인 GTK+ 툴킷에 기초하여 개발되었다는 점에서 차이를 지니고 있다.

솔라리스에서 사용하고 있는 데스크탑 환경은 CDE(Common Desktop Environment)라고 하는 공통 데스크탑 환경이다. CDE는 1993년 COSE(Common Open Software Environment)가 UNIX를 위한 공통의 인터페이스를 만들기 위해 나온 것이며, 여기에 참여한 업체는 Sun을 주축으로 하여 IBM, NOVELL, HP들이었다. 당대 최고의 기술력을 집합시켜 만든 것이 바로 CDE다. 현재 솔라리스 8에 사용되는 CDE 구조의 핵심을 이루고 있는 것은 Motif2.1과 X11R6.4이다. 솔라리스에서는 특히 CDE 말고 여러 테스크탑 환경을 사용하는 것이 가능하다. 이것은 윈도우즈에서는 볼 수 없는 유닉스만의 특징이라고 볼 수 있다. 솔라리스에 CDE를 제외하고 기본적으로 설치되는 데스크탑 환경은 Openwindows Desktop이 있지만 이는 솔라리스 8이후 버전에서는 더 이상 지원을 안 할 예정에 있다. 또한 사용자는 CDE말고 리눅스(물론 FreeBSD와 같은 다른 유닉스환경에서도 사용되어진다)에서 사용되어지고 있는 KDE나 gnome를 사용하고자 한다면 솔라리스에 포팅해서 사용할 수가 있다. 현재 솔라리스 8 10/00버전에서는 Companion CD에서 gnome과 KDE를 패키지로 제공하고 있다. 하지만 특별한 이유가 없는 한 CDE를 사용하지 않고 다른 데스크탑을 사용한다는 것은 큰 손해라고 할 수 있다. 첫째 이유로는 gnome과 KDE를 단순한 윈도우 메니저로만 사용한다면 그다지 문제가 없지만 시스템과 관련된 기능들이 아직 완전히 지원을 하지 못하고 있다. 두 번째로 CDE에는 솔라리스 8에서 제공되는 많은 기능들이 있는데 이러한 기능들을 다 포기하고 gnome이나 KDE를 쓴다면 많은 손실을 감안해야 한다는 점이다.

데스크탑 세션
데스크탑 세션의 시작 및 종료
데스크탑 로그인
CDE 데스크탑을 시작하기 위해서 사용자는 로그인 화면에서 로그인 과정을 거쳐야한다. 사용자는 사용자 계정과 암호를 입력하면 데스크탑에서 세션관리자를 구동시켜 세션 상태에 따라 해당 세션이 실행된다.
사용자는 로그인 화면에서 사용자 계정을 입력하고 확인을 누른 다음 암호를 입력하면 CDE 데스크탑으로 로그인 과정이 수행된다. 사용자 계정이나 암호를 잘못 입력하였을 경우에는 처음부터 다시를 눌러 로그인 과정을 다시 거치면 된다. 만일 관리자가 사용자에게 암호를 부여하지 않은 상태라면 화면에 암호를 설정하라고 나온다. 거기서 새로이 암호를 만들고 다시 로그인 과정을 수행하면 된다. 로그인 과정을 마치고 나면 이제부터 세션이 시작되는 것인데 만일 사용자가 처음 로그인을 하는 거라면 세션관리자는 사용자에게 어떤 데스크탑 종류를 사용할 것인지를 묻는다. 디폴트로 공통 데스크탑 환경(CDE)을 선택하도록 되어 있으며 사용자는 OpenWindows 데스크탑이나 기타 다른 데스크탑 환경을 선택하여도 된다. 이 설정은 나중에 세션 관리자에서 바꿀 수 있다.

데스크탑 로그아웃
CDE 데스크탑 환경에서 로그아웃을 하는 방법은 마우스 오른쪽 버튼을 이용한 메뉴선택에서 로그아웃을 선택하거나 밑에 있는 프론트 패널에서 EXIT를 선택하면 된다. 그럼 로그아웃을 할 것인지를 묻는 메시지가 뜰 것이다.
데스크탑에서 로그아웃을 하면 세션 관리자는 사용자의 현재 사용했던 세션에 대한 정보를 저장한다. 이 정보는 나중에 그 사용자가 다시 로그인을 하면 세션관리자가 사용자의 마지막 세션을 복구하는데 사용된다. 하지만 데스크탑 응용 프로그램이 아닌 것들은 저장이 되지 않을 수도 있으니 유의하기 바란다.

비상 안전(Failsafe)세션 시작
비상 안전(Failsafe)세션은 CDE데스크탑 세션에 로그인하기 전에 사용자가 몇 가지 명령을 수행할 필요가 있을 경우 사용된다. 이 세션에서는 사용자에게 단지 단일 터미널 창만을 제공해준다. 이곳에서는 몇 가지 기능상에서 제약을 받지만 일반 원격 터미널로 사용하는 것보다는 많은 기능을 제공한다. 일례로 넷스케이프와 같은 프로그램도 사용할 수가 있다. 단일 터미널 창에서 사용자가 필요한 작업을 수행한 후 다시 CDE데스크탑 화면으로 돌아가기 위해서는 exit명령을 수행하면 된다.

명령줄 로그인
명령줄 로그인 모드는 이제까지 설명된 다른 세션과는 달리 데스크탑 세션이 아니다. 이 모드를 선택하게 되면 데스크탑은 일시적으로 중단이 되며 사용자는 창이 없이 전체화면으로 로그인 과정을 거치게 될 것이다. 처음 명령줄 로그인을 선택하면 데스크탑 로그인을 일시적으로 중지시킨다는 메시지와 함께 콘솔 로그인 프롬프트로 들어가기 위해서는 Enter를 누르라고 나온다. Enter를 누르면 사용자는 콘솔 로그인 명령줄을 볼 수 있을 것이다. 콘솔에서의 작업이 모두 완료되면 비상 안전 세션에서와 마찬가지로 exit명령을 수행하고 다시 Ctrl+R을 누르면 다시 원래의 CDE 데스크탑 로그인 화면으로 돌아간다.

프론트 패널 사용
프론트 패널 정의
사용자의 작업을 좀더 수월하게 해주기 위해 데스크탑에는 작업장과, 조절도구, 메뉴, 그리고 프론트 패널이 있다. 작업장은 Workspace라고 하여 사용자가 필요에 따라 작업창들을 놓는 영역이며, 조절도구에는 다양한 선택항목이 있어 각각에 해당하는 정보를 입력할 수 있다. 메뉴는 사용자가 창을 관리하고 응용프로그램을 작동하기 위해 사용하는 명령을 제공한다. 마지막으로 프론트 패널이란 각 작업장에서 자주 사용되는 조절 도구들의 모음이라고 할 수 있다.

프론트 패널 구성
공통 데스크탑 환경으로 로그인을 하면 화면 밑에 창이 하나 보일 것이다. 이것이 바로 프론트 패널이라고 하는 것인데 사용자의 작업을 편하게 해주기 위해 각종 유용한 유틸리티들을 아이콘 형태로 링크 시켜놓은 것이다. 프론트 패널은 두 개의 주요 구성요소로 나눌 수가 있는데 하나는 아이콘 형태로 보이는 기본 패널이고 두 번째는 하위에 속해있는 부속 패널이다. 기본 패널과 부속 패널 둘 다 자주 사용되는 응용프로그램들을 링크 시켜놓은 것으로 이해하면 쉬울 것이다. 기본 패널과 부속 패널에 링크된 응용프로그램들은 각 패널로 서로 이동이 가능하다.

기본 패널
기본 패널은 CDE화면에서 아래에 위치한 수평으로 길게 놓여진 창이다. 이 기본 패널에는 사용자가 평소에 자주 쓰는 작업장 바꾸기나 메일관리, 프린트관리, 도움말 항목 등 여러 조절도구가 위치하고 있다. 총 10가지 항목이 기본적으로 존재하는데 왼쪽부터 간단히 설명하면 다음과 같다.

열쇠모양은 화면 잠금 기능을 작동시키는 것이며 EXIT라고 되어있는 것은 사용자 로그아웃을 실행키는 아이콘이다.

공통 데스크탑 환경에서의 배경화면은 일반적으로 윈도나 리눅스에서와 마찬가지로 마우스나 기타 사용법이 매우 흡사하다. 따라서 여기서는 그러한 사용법에 대한 언급을 생략하였다.

배경화면에서 마우스 오른쪽 버튼의 팝업 메뉴를 보면 작업공간 메뉴라고 하여 여러 도구모음이 나타난다. 여기에는 여러 응용프로그램을 실행시킬 수 있는 여러 아이콘들이 있다. 각 각의 응용프로그램에 대한 사용법은 독자들이 직접 수행해봄으로써 익숙해지길 바라며, 몇 가지 응용프로그램이나 조절 도구에 대해서는 차츰 언급할 것이다. 이밖에도 기본패널에 있는 아이콘들은 마우스 오른쪽 버튼의 팝업 메뉴를 이용하여 해당 부속패널을 없앨 수 있으며 추가, 이동 및 삭제도 가능하다.

부속 패널
기본패널의 조절도구 위에 삼각형 모양의 탭이 있는데 그걸 클릭하면 해당 부속패널이 나타난다. 부속패널에는 기본적으로 있는 응용프로그램들뿐만 아니라 사용자가 선택적으로 추가 및 삭제할 수가 있다. 사용자가 부속패널에 넣고자 하는 응용프로그램이 있으면 다른 화면에서 해당아이콘을 끌어다가 놓으면 되며. 없애고자 하는 응용프로그램은 마우스 오른쪽 버튼의 팝업 메뉴에서 없애기를 클릭하면 된다. 부속 패널을 닫기 위해서는 부속 패널에 있는 창 메뉴 버튼을 클릭하여 닫기를 선택하면 된다. 혹은 더블 클릭을 하거나 탭을 한번 더 클릭을 함으로써 부속 패널을 닫을 수 있다. 부속 패널은 팝업 메뉴와는 달리 닫기를 선택하지 않으면 계속 데스크탑에 보여진다.

프론트 패널 사용하기
기본 패널에 응용프로그램 추가 및 삭제
기본 패널에 응용프로그램을 추가하기 위해서는 우선 패널에 아이콘을 먼저 추가해야 한다. 아이콘을 추가하는 방법은 프론트 패널 중에서 스위치영역(작업공간 버튼이 차지하지 않는 영역)에서 마우스 오른쪽 버튼의 팝업 메뉴 중 아이콘 추가 버튼을 누르면 된다. 이와 같은 작업을 수행한 다음 추가하고자 하는 응용프로그램을 추가한 아이콘에 Drag & Drop을 하여 놓으면 기본 패널에 응용프로그램이 추가가 된다. 보통은 응용프로그램 관리자에 있는 아이콘들 중에서 추가를 하며 사용자가 원하면 다른 곳에 있는 파일들을 추가할 수 있다. 부속 패널에 응용프로그램을 등록시키기 위해서는 원하는 응용프로그램을 아이콘 설치라는 곳에 Drag & Drop을 하면 설치가 된다. 처음에는 다른 윈도우 메니저와 달라 익숙치가 않을지 모르지만 조금만 사용하면 꽤 편리하다.

작업장 사용하기
데스크탑 환경에서 많이 사용되고 있는 것 가운데 하나가 바로 작업장 바꾸기이다. 리눅스와 마찬가지로 솔라리스에서도 작업장을 여러 개 두어서 사용자의 작업창들이 많을 경우 여러 작업장에 분할하여 놓음으로써 작업의 효율성을 높여준다. 작업장은 기본적으로 4개로 설정되어 있고 각 작업장간에 이동은 ALT+ ->혹은<- 를 선택하거나 해당 작업창을 직접 선택할 수도 있다.
사용자가 더 많은 작업장을 갖길 원한다면 늘릴 수도 있다. 작업장 수를 늘리는 방법은 간단하게 작업장을 나타내어주는 곳에 마우스를 갖다 대고 오른쪽 버튼을 누른 다음 작업장더하기를 선택하면 새 작업장이라는 항목이 새로 생긴다. 이것의 이름을 바꾸고자 하면 다시 오른쪽 버튼을 누르고 메뉴에서 이름 바꾸기를 선택한 다음 원하는 작업장 이름으로 바꾸어주면 된다.

이렇게 사용자에 의해서 설정된 프론트 패널은 처음의 디폴트 상태로 복구가 가능하다. 프론트 패널을 처음의 상태로 복구하기 위해서는 응용프로그램 관리자에서 데스크탑 제어기를 선택한다.(혹은 기본 패널에 있는 데스크탑 스타일을 선택) 있는 데스크탑 제어기를 선택한다. 이곳에 추가라는 항목이 있을 것이다. 항목을 선택한 다음 여러 아이콘들이 있는데 그 중에 프론트 패널 복구라는 것이 우리가 찾고자 하는 것이다. 이 프론트 패널 복구를 실행시키면 사용자에 의해 만들어진 프론트 패널에 관한 설정 사항들을 원래대로 복구 시킨다.

스타일 관리자
스타일 관리자란?
데스크탑의 여러 환경 설정들을 바꾸기 위해서는 스타일 관리자라는 것을 사용하면 쉽게 조정할 수가 있다. 스타일 관리자에는 다음 그림에서와 같이 색상, 글꼴, 백그라운드, 키보드, 마우스, 경보음, 화면, 창, 그리고 시작에 대한 환경설정을 할 수 있는 관리자들이 있다.

색상
색상 스타일 관리자는 작업장 화면의 색상을 변경하는 기능을 제공해준다. 기본적으로 데스크탑에서 사용되고 있는 팔레트는 Default이다. 팔레트는 네 가지 색으로 그 종류가 나뉘어 지며, 각 각의 색깔은 사용자가 변경 가능하다. 또한 팔레트는 사용자가 임의로 추가 혹은 삭제가 가능하다. 팔레트를 추가하면 $HomeDirectory/.dt/palettes라는 디렉토리에 palette_name.dp라는 파일이 생성되고, desc.palettes라는 파일에 파일 리스트가 추가된다. 팔레트를 삭제하면 스타일 관리자는 팔레트 이름 앞에 ~이 붙는다.(~palette_name.dp)

삭제된 팔레트는 복구가 가능하다. 사용자가 만든 팔레트를 삭제한 경우와 기본적으로 시스템에서 제공된 팔레트를 삭제했을 때에 복구 방법이 조금 다르다. 시스템에서 제공된 팔레트를 복구할 경우에는 ~palette_name.dp를 단지 삭제하기만 하면 된다. 만일 사용자가 새로 만든 팔레트를 복구할 경우에는 ~palette_name.dp에서 ~을 없애고 palette_name.dp로 변경하면 된다.

글꼴
글꼴 스타일 관리자에서는 데스크탑에서 사용되고 있는 글꼴들의 크기나 문자세트 등을 설정하는데 사용되어진다. 여기서 선택하는 글꼴 그룹과 크기는 제목, 메뉴 표시줄, 창 레이블 및 텍스트에서 사용된다. 사용자가 새롭게 글꼴 그룹을 등록하거나 변경을 가하면 현재의 창들은 이러한 사하을 반영하지 않고 새로 시작되는 응용프로그램이나 창들에게만 반영된다.
미리보기는 변경된 사항들을 나타내줌으로 자신의 스타일에 맞은지 판단한 다음 최종적으로 확인을 선택하면 된다.

백그라운드
백그라운드 혹은 배경 스타일 관리자는 데스크탑에 나타나는 배경화면의 패턴을 변경할 때 사용되는 관리자이다. 각 각의 작업장마다 다른 배경을 제공해줄 수 있다. 솔라리스 8에서는 기본적으로 7개의 배경화면이 제공되고 있으며 사용자가 자신만의 그림 파일을 이용하여 배경화면을 구성할 수도 있다.

시작
시작 스타일 관리자란 사용자가 데스크탑으로 로그인을 하였을 때 어떤 스타일로 로그인과정을 거칠지에 대한 여러 설정 사항들이 있다. 그 밖에 로그아웃 확인 대화상자는 로그아웃시 나오는 로그아웃 확인 메시지를 보여줄 것에 대한 선택이다. 그리고 홈 세션 설정은 현재 사용하고 있는 세션을 홈 세션으로 설정한다는 의미이다. 홈 세션 설정은 사용자가 가장 보편적으로 사용되는 세션으로 설정하는 것이 좋다.

현재 세션 계속
사용자가 마지막으로 세션에서 설정한 환경이나 자원 등을 포함하여 작업공간의 내용을 그대로 복구하여 다음 세션에서 계속 사용한다는 것을 의미한다

홈 세션으로 복귀
홈 세션으로 복귀는 특정한 세션에 대한 내용들을 홈 세션으로 설정한 경우에 설정된 홈 세션으로 복귀하는 것을 의미한다. 만일 홈 세션이 기존에 설정되어 있지 않은 경우 시스템은 기본 세션을 사용하여 시작한다. 홈 세션을 설정하는 메뉴는 시작 스타일 관리자 하단에 있고, 이 홈 세션 설정을 선택하면 현재의 세션을 홈 세션으로 사용한다는 것을 의미한다. 홈 세션에 대해 설정이 되면 $HomeDirecotry/.dt/sessions에 home이라는 디렉토리가 생성되면서 해당 세션에 대한 설정 사항들을 저장한다. 홈 세션을 설정하면 기존의 current 내용이 current.old로 카피되어 지고 home디렉토리가 생성된다. 만약 홈 세션을 설정하지 않았다면 기본적으로 /usr/dt/config/ko 디렉토리 밑에 있는 파일들을 참조한다.

로그아웃할 때 지정
로그아웃할 때 지정은 로그아웃을 할 때 현재 세션을 다시 시작할 것인지 아니면 홈 세션을 복구할 것인지를 묻도록 하게 하는 것이다.

로그아웃 확인 대화상자
이것이 설정으로 되어있으면 사용자가 로그아웃할 때 로그아웃을 정말 원하는지에 대한 물음이 나온다. 기본적으로 설정으로 되어있다.

이밖에도 배경, 키보드, 마우스, 경보음, 화면, 창 스타일 관리자가 있으며, 위에서 설명했던 것과 비슷하게 설정을 해주면 된다.

Chapter 시스템 관리 II
디스크의 백업 및 복구
백업의 필요성
여러분의 시스템에는 거의 매일 많은 양의 새로운 데이터가 생성되고 있을 것이다. 이 데이터들은 무슨 이유에서든지 전부 가치 있는 것들이다. 만일 이 데이터들의 일부 혹은 전부를 잃어버렸다면 이 데이터를 살리기 위해서는 노력과 시간 혹은 돈을 들여야 할 것이다. 어떤 경우에는 잃어버린 데이터는 영영 복구 불가능한 것일 수도 있다. 어떤 데이터든지 생성된 순간부터 그것을 잃지 않도록 준비를 해야만 한다.

따라서 시스템 관리자의 가장 중요한 임무중의 하나는 시스템의 데이터를 시스템 장애, 자연적으로 발생하는 재난 그리고 우발적으로 일어날 손실로부터 시스템을 보호하는 것이다.

기본적으로 데이터를 잃어버리게 되는 요인은 다음과 같다.

   우연한 파일 삭제
   시스템 내부 장애
   시스템 외부 장애

사람은 언제나 믿을 수 없는 존재이다. 언제 실수를 저지를 지 모를 뿐 아니라 고의로 데이터를 망치려는 경우 또한 많이 있을 것이다. 하드웨어 또한 완전히 믿을만한 것은 아니다. 중요한 데이터가 보관되는 하드웨어중 가장 핵심적인 것은 하드 디스크일 것이다. 그렇지만 하드디스크 드라이브에는 움직이는 부분이 있어, 가끔 이런 부분에서 장애가 발생한다. 이런 시스템 내부 문제뿐 아니라 화재, 정전 등 우리의 외부에는 언제 어떤 재앙이 있을지 알 수 없는 일이다.

백업이란 보통 파일이 이동되거나 제거되었을 때 원본을 손실하게 될 경우를 대비하여 복사해 두는 것을 의미한다. 이런 재앙에 대해 미리미리 대비를 하기 위해 주기적으로 데이터를 여러 개 복사해 둔다면 시스템의 갑작스런 재앙에 대해 당황하지 않아도 될 것이다.

일반적인 백업 및 복구 이론
백업 매체 선택
현재 가장 많이 쓰이는 백업 매체는 테이프, 디스크 드라이브, 플로피 디스켓, Zip 드라이브, 다시 쓸 수 있는 CD 등이 있다.

어떤 매체를 선택할 것인지에 대해서는 고려해야 할 많은 사항들이 있는데, 먼저 비용면을 고려해 보면 같은 비용으로 더 많은 양의 데이터를 저장할 수 있는 쪽이 백업에는 유리 할 것이다. 이유는 물론 저장할 데이터의 양이 많은 것도 문제가 되지만 보통 백업은 일주일에 한번씩 전체 백업을 하고 하루에 한번씩 새로 추가된 부분만 백업을 하는 것이 보통이다. 그래서 평균 6개 정도의 매체를 가지고 일주일의 분량을 백업하는데 사용하고 다음주에 새로 그 위에 덮어 씌우는 식으로 백업을 수행한다. 만약 6개 이상의 매체가 있다면 더 오래된 시점의 백업 자료를 보관할 수 있기 때문에 최근의 전체 백업 자료가 파손이 되어도 많은 데이터의 손실은 피할 수 있을 것이다.

이 외에도 매체를 선택하는데 고려해야 할 사항은 이식성, 사용의 편의성, 전송속도 등이 있고 무엇보다도 가장 중요한 것은 신뢰성을 고려해야 한다. 백업 데이터가 다른 시스템에서는 사용가능하지 않다면 문제가 있을 것이다. 또한 백업을 하는데 얼마나 쉽게 할 수 있는 지도 문제가 될 것이다. 백업하기가 지겨울 정도로 쓰기 불편하다면 곤란 할 것이다.

이런 사항들을 고려해 볼 때 가장 많이 사용되는 매체로 테이프가 있다. 테이프는 값이 적당하고 상당히 신뢰성이 좋으며 속도도 상당히 빠르며 편리하기까지 하다.

Standard Solaris 툴
솔라리스에서 백업을 수행하는 데에 가장 많이 사용되는 tool로는 tar, dd, cpio. ufsdump와 ufsrestore 가 있다

tar 사용하기
tar는 tape archive를 만들거나 tape archive에 포함된 파일을 뽑아내는데 사용된다. tar를 사용하면 단일 혹은 다중 파일을 한 디렉토리 구조에 백업 할 수 있다.
tar 에는 다양한 많은 옵션들이 있다. 옵션에 대한 설명을 보려면 man tar하여 알아보면 된다.

다음은 /opt/totalnet package의 file 들을 tar 로 만드는 예이다.
먼저 du 명령어를 사용해서 만들어질 tar 파일의 잠재적인 size를 체크 한다.

tar 로 만들어질 파일의 크기는 15,387 블록이다. du -s 를 사용하면 세부 디렉토리를 제외한 전체의 크기만을 볼 수 있다.
이제 opt/totalnet 의 모든 서브디렉토리의 내용을 /tmp/로 tar 파일을 만들어 넣어보자.

여기서 옵션을 사용할때는 -를 사용하지 않아도 된다. c는 새로운 저장 파일을 만든다는 의미이고 v는 백업이 되고있는 파일의 목록을 보여주는 역할을 하고, f는 그 다음의 인자가 생성할 저장 파일(또는 장치)의 이름이라는 것을 나타낸다.

tar 파일에서부터 내용을 다시 꺼내오기 위해서는 c 옵션 대신 x(extract 의미) 를 사용하면 된다.

솔라리스에서 tar 파일은 디폴트로 압축이 되지 않는다. 압축을 하기 위해서는 solaris에서는 compress 명령어를 사용한다.

위와같이 실행하고 나면 file.tar.Z 이라는 압축된 tar 파일이 생성된다.
compress 대신 GNU gzip 을 사용 하면 종종 더 좋은 압축율을 얻을 수도 있다. gzip을 사용하면 file.tar.gz 이라는 압축파일이 생긴다.

Solaris 에 tar가 있지만 GNU tar 를 다운받아 설치하면 tar 파일을 압축하는데 훨씬 편리하게 될 수 있다. GNU tar 를 설치하면 다음과 같이 z 옵션을 써서 한번에 tar.gz파일을 만들수 있다.

file.tar.gz 파일을 다시 풀기 위해서는 다음과 같이 실행한다.

그러나 백업에 있어 압축을 사용하는 것은 그다지 좋은 일이 아니다. 압축한 파일의 한 비트만 못쓰게 되면 전체 파일을 모두 잃게 된다. 따라서 압축을 하려면 파일을 몇 개로 분할해서 백업을 해 주는 것이 좋다.

cpio 사용하기

cpio는 표준 입력으로부터 파일의 이름을 구하고, 표준 출력으로 목록명을 얻어서 하나 또는 복수개의 파일을 압축하는데 사용된다.
cpio 는 3개의 다른 모드로 사용될 수 있다.

copy-in : cpio -i , 표준 입력으로 들어온 파일들을 extract 한다.
copy-out : cpio -o, 표준 입력으로부터 파일을 얻어서 이들 파일을 가지고 그들의 pathname 과 함께,
새로운 파일을 생성한다.
copy-pass : cpio -p, copy-out 모드와 같다. 다만 새로운 파일이 생기는 것이 아니라 디렉토리 구조를
그대로 copy 한다는 것만 다르다.

그 외의 옵션으로는

B - 입력/출력 레코드 블록을 5120bytes로 정하지만, 이는 -p 옵션을 사용할 때는 지원되지 않는다.
c - 다른 플랫폼으로 이식할 수 있는 아스키 문자 형식으로 헤더 정보를 읽거나 쓴다.
t - cpio의 내용에 관한 테이블 목록.
v - 파일명 목록을 출력한다. t 옵션과 함께 사용하면 ls -l 과 그 출력 양식이 같다.

cpio를 사용 예를 보면 아래와 같다.

위의 명령어는 현재 디렉토리의 모든 파일의 이름을 표준출력으로 받아 a.list 하나로 묶인다. 여기서 a.list 파일 대신 /dev/rmt/0 같은 백업을 위한 이름을 주어도 된다.

위를 실행하면 a.list 에 묶인 파일의 목록들이 ls -l결과처럼 출력된다. 다음은 a.list로 묶인 파일을 다시 복구 시켜준다.

아래 명령은 현재 디렉토리의 내용을 디렉토리구조 그대로 directory 라는 곳의 아래에 복사한다.

dd 사용하기
dd명령은 가장 낮은 레벨의 데이터복사 명령어로서, 복사뿐 아니라 물리적인 레벨의 장치의 데이터 처리가 가능하다. (섹터, 블록, 트랙, 실린더, 장치 전체)
dd를 사용하기 위해서는 필요한 옵션들이 있다. 이 옵션들은 옵션=값의 짝으로 주어진다. if 는 입력 파일을 명시하기위한 옵션이고, of 는 출력파일 명시, bs 는 입력과 출력 블록 크기를 설정한다(기본은 모두 512bytes).

예를들어 /dev/dsk/c1t0d0s0의 / 파티션을 /dev/dsk/c1t4d0s0 로 복사하기 위해서는
dd의 또 다른 사용은 하나의 tape 에서 다른 tape 으로 data를 백업하는 것이다. 이것은 백업 테이프를 재 생성하는데 유용할 것이다.

예를 들어 테이프 drive 0(dev/rmt/0) 에서 drive 2(/dev/rmt/2)로 copy 하기 위해서는
다음과 같은 명령어를 사용한다.

ufsdump 와 ufsrestore 사용하기
ufsdump 와 ufsrestore 는 Unix 파일 시스템을 백업하고 복구하기위한 표준 application이다. 백업은 파일시스템 전체나 개별적인 파일과 디렉토리의 전체 또는 추가 백업으로 할 수 있다. 기본적으로 ufsdump 는 mount 된 파일시스템을 백업할 수 있지만, 백업하고자 하는 파일 시스템을 unmount 시키고 사용하는 것이 현명할 것이다. 파일시스템을 fsck를 사용해서 check 한후 백업을 수행 하도록 한다.

ufsrestore 는 시스템이 붕괴된 후 single-user-mode 에서 사용한다.

ufsdump의 기본적인 개념은 레벨별로 구별해서 백업을 할 수 있다는 점이다.

ufsdump에서 full backup은 레벨 0 로 표현한다. 그리고 1에서 9까지는 마음대로 incremental backup 레벨로 할당해서 사용할 수 있다. 다만 한가지 제한은 높은 숫자는 매일 정상적인 incremental backup 을 수행하고 백업처리의 프로세스가 재시작 한다는 것을 명시하기 위해 한 주에 한번은 낮은 숫자를 놓는다.

예를 들면 일요일의 backup은 레벨 0을 수행하고, 월요일에서 금요일까지는 각각 5,6,7,8,9의 레벨을 가지고 백업을 수행하고, 백업 사이클의 끝을 알리기 위해 토요일에는 1부터 4까지의 숫자 중 하나를 이용한다.

ufsdump는 종종 cron 을 사용해서 시스템의 부하가 적은 저녁에 수행될 수 있도록 예약해서 사용된다. cron의 사용은 프로세스관리부분을 참조하라.

시스템의 부하가 적은 일요일쯤에 전체 백업(full backup)을 수행하고, 나머지 주중에는 증가부분에 대해서만 백업(incremental backup)을 수행하면 백업의 속도면에서도 이익을 볼 수 있고, 하나의 테이프에 각각의 날들의 작업을 분리시켜 저장할 수 있게 되므로, 원하는 날의 백업파일을 다시 복구 시킬 수 있다.

실제로 백업을 수행하기 전에 백업을 하고자 하는 파일 시스템의 size를 체크할 필요가 있다. 실제 테이프의 남은 양과 비교해서 백업이 안전하게 수행 될 수 있는 지 점검해야 할 것이다.

위와 같은 경우 백업을 위해서 대략 테이프에 49Mbyte 의 공간이 필요하다

실제로 x86의 파티션(/dev/rdsk/c0d0s0)를 레벨 0으로 전체백업을 수행하기 위해서는
ufsdump 의 파라미터 0은 레벨 0을 나타내고, c는 모든 카트리지 테이프 드라이브의 블로킹 인수를 126으로 설정한다. u는 /etc/dumpdates 의 파일에 dump record를 update 하라는 옵션이다. 이 dump record는 각각의 파일 시스템의 마지막 dump날짜를 유지하고 있다.

ufsdump는 멀리 떨어진 테이프 장치로 백업이나 복구를 수행할 때도 사용할 수 있다. 원격 백업을 수행하기 위해서는 /.rhosts 파일의 엔트리를 가진 시스템에(테이프 장치를 가진) 접근할 수 있는 권한이 있어야 하고, ufsdump나 ufsrestore 명령어 라인에서 server:tatp_drive를 명시한다.

예를 들어 카트리지 테이프를 사용하여 멀리 떨어진 host1의 테이프 장치에 /export/home 파일 시스템을 전체백업(레벨 0)을 하려면 아래와 같이 한다.

ufsdump 를 사용해서 백업을 한 후에 ufsrestore 를 사용하여 백업한 데이터를 다시 복구할 수 있다.

/dev/rmt/0의 테이프에서 다시 데이터를 복구하기 위해서는 다음과 같이 한다.

y를 입력하면 모든 파일들을 복원할 수 있다. 만약 복원되는 리스트를 보기위해서는 아래와 같이 입력한다

ufsrestore 는 대화식 모드로 사용할 수 있다.

위와 같은 상태에서 help를 입력하면 사용 가능한 commend를 볼 수 있다.
여기서 ls를 하면 덤프의 디렉토리들이 나열된다. cd 를 이용해서 덤프안의 디렉토리를 자유롭게 이동 할 수 있고, add 를 사용해 복원할 파일의 목록을 추가하고, delete 를 사용해서 목록에서 다시 삭제를 한다

그리고 extract 를 치고 엔터를 치고 나면 add로 추가한 목록들이 모두 복원이 된다. 모든 복원을 끝마치고 나서 quit를 사용해서 ufsrestore 의 대화식 모드를 빠져나간다.

위의 과정을 예를 들면 아래와 같다

위와 같이 하면 선택한 .Xauthority 가 복원된다.

그외 유용한 툴

AMANDA( Advanced Maryland Automatic Network Disk Archiver)
AMANDA는 multiple client를 위해 서버가 중앙에서 백업하도록 지원을 해주는 freesoftware 백업 시스템이다.

이 시스템에서는 기본적으로 단일 테이프 드라이브를 사용하도록 하고 있으나, multiple tape 이나 다른 디바이스를 사용하도록 configuration이 가능하다.
AMANDA를 사용함으로써 백업에서 얻을 수 있는 이점은 기존의 솔라리스 백업과 복구 명령으로 관리를 할수 있다는 점이다. 즉 AMANDA로 백업한 파일들은 일반 tar로 볼 수 있는 tar 파일이다. 이것은 AMANDA가 어떤 이유로 사용 불가하거나, 설치되지 않은 서버에서도 복구가 가능하다는 이점을 가져온다.

http://amanda.org에서 다운받아 설치할 수 있으며, FAQ 는 http://www.ic.unicamp.br/~oliva/snapshots/
amanda/FAQ 에서 찾을 수 있다.
이 시스템에서는 데이터를 백업 디바이스로 직접 전송하지 않고 백업준비파일형태로 존재하여 실제로 기록하는 프로세스가 따로 이것을 기록한다. 이것은 CD-R 테크닉을 쓸 때 유리하다. CD-R 디바이스는 쓸 준비를 빠르게 하지 못한다. 따라서 write track 이 잘못되었을 경우 새로운 디스크를 사용해야 하기 때문에 백업준비파일과 실제 기록 프로세스와의 분리는 이런 디스크의 낭비를 막아 줄 수 있다.

AMANDA의 또 다른 이점은 효율적인 dump 스케줄링을 제공한다는 점이다.
dump cycle이란 개념을 사용했는데, 특정 파일을 dump 하는데 드는 시간을 평가해서, dump의 전체 횟수를 최소화 한다. 지난 백업을 기반으로 해서 서로 다른 백업들의 시간의 균형을 맞추어서 백업을 실행한다.

이외에 AMANDA는 제한점도 가지고 있다.
이것은 단일 백업 매체보다 더 큰 양의 파일시스템을 할 수 없다. 이것은 즉, 큰 디스크만(최신의 DAT 나 DLP 테이프 같은)을 사용해서 백업을 해야 한다는 단점이 된다.

시스템 프로세스 관리
유닉스 시스템 사용자라면 누구나 현재 수행되고 있는 프로세스들이 무엇이고 어떤 상태인지 보고 싶은 적이 있을 것이다. 여기서는 수행되고있는 프로세스들을 어떻게 볼 수 있으며, 이들을 제어하는 방법에 대해 설명하고, 이러한 반복적인 작업을 자동화하는 방법에 대해서 설명한다.

프로세스 보기와 끝내기
프로세스들의 속성을 보기 위한 명령어로는 ps 와 pgrep 을 사용하고, 프로세스를 끝내는데 사용되는 명령어로는 kill 과 pkill 이 있다

ps와 kill 사용하기
ps는 현재 활동하고 있는 프로세스들의 정보를 보여주는데 사용된다. 많은 관리자들은 kill 을 사용해 프로세스를 죽이기 위해서는 프로세스의 id(PID)를 알아야 하기 때문에 ps 를 사용해서 PID를 알아낸다.

ps에는 많은 옵션들이 있어 프로세스의 정보를 여러 원하는 형태로 출력되도록 사용이 가능하다. 사용 가능한 옵션들은 아래와 같다.
-A와 -e 는 모든 프로세스를 출력
-a는 터미널과 관련되지 않은 프로세스와 프로세스 그룹 리더를 제외한 모든 프로세스를 출력
-g프로세스그룹ID 는 특정 프로세스그룹의 프로세스들을 출력
-G그룹ID 는 특정 그룹에 속한 user 들의 프로세스만 출력
-f 는 full 리스트 형식으로 출력
-l 는 long 리스트 형식으로 출력
-j 는 프로세스의 세션ID 와 프로세스 그룹ID 를 출력
-t 터미널디바이스패스 는 특정 터미널 디바이스 패스와 연관된 프로세스들만 출력
-u USER ID 는 특정 user 의 프로세스만 출력

ps 사용 예를 보자.
옵션 없이 ps명령어만 사용한 기본 출력형태는 아래와 같다.

여기서 나타나는 PID 는 프로세스의 ID 를 나타내고 TTY는 터미널 디바이스를, TIME 는 수행시간을 CMD 는 프로세스가 수행하는 프로그램이나 명령어를 나타낸다.
몇 가지 사용 예를 더 살펴보자.

위의 명령은 터미널 디바이스 pts/5 에 관련된 프로세스들의 목록을 보여준다.

-f 옵션을 사용한 full 리스트는 위와 같이 출력되며 여기서의 UID는 user ID 이고, PPID 는 parent PID 를, C는 소모한 프로세서의 이용시간을 나타내고 STIME 은 프로세스 시작날짜를 나타내 준다.

kill 명령어를 사용하면 ps를 통해서 알아낸 PID 를 가지고 프로세스에게 시그널을 보내 프로세스를 중지시킬 수 있다. 사용 방법은 kill ?signal값 PID 와 같이 사용한다.

kill 명령어를 사용해서 프로세스에게 보낼 수 있는 시그널의 종류는 다음과 같고, 모든 시그널을 받았을 때 프로세스는 기본적으로 프로세스를 끝내는 것으로서 시그널에 응답한다.

kill 명령어로 프로세스에게 시그널을 보낼 때는 시그널의 symbol 이나 Value 둘 다 사용 가능하다. 아래의 예는 둘 다 같은 결과를 가진다.

pgrep 과 pkill 사용하기
ps 와 kill 외에 프로세스를 보고 프로세스에게 시그널을 보내는 명령어로 pgrep 과 pkill 이 있다. 이 명령어 들은 UID 나 GID 같은 특정 attribute 들에 속하는 프로세스들의 목록을 볼 수 있을 뿐 아니라 regular expression을 사용해서 특정패턴을 가지고 특정 프로세스들을 보거나 종료 시킬 수 있다.

예를 들면 ps를 사용해서 adimintool 을 실행하고 있는 프로세스를 찾기 위해서는 다음과 같이 한다.

이것을 pgrep을 사용하면 아래 같이 간단하다.

다만 pgrep 을 사용하면 PID 만이 출력된다. 프로그램의 이름까지 출력하고자 할 경우 -l 옵션을 사용하면 PID 와 프로그램이름을 같이 볼 수 있다.

이 외에도 pgrep 에서 사용되는 옵션으로는 -f 하면 패턴을 프로그램의 이름에서만 매치시키는 것이 아니라 모든 argument 에서 패턴과 매치되는 프로세스들을 출력시켜준다.

-n은 매치되는 프로세스들 중에서 가장 최근에 생긴 프로세스 하나만을 보여주고, -x는 패턴과 정확히 매치된 프로세스만 보여준다.

특정 ID 를 가진 프로세스를 찾기 위해서 사용하는 옵션들은 ?g(Process Group ID), -G(Real Group ID), -P(Parent Process ID), -s(Process Session ID), -t(Terminal Device Path), -U(Real User ID) 등이 있다.

그리고 pgrep 이 PID를 출력할 때는 디폴트로 한 줄에 하나의 PID 를 출력한다. 많은 프로세스들이 출력될 때는 한꺼번에 화면이 빠르게 넘어가기 때문에 보기가 불편할 것이다. 이럴때 -d 옵션을 사용하면 유용하다. d옵션 뒤에 표시된 것을 구분자로 해서 PID 가 출력된다.

pkill 명령어도 pgrep 명령어와 사용법이 유사하다. 다만 PID 를 출력해주는 대신에 매치되는 프로세스들을 SIGTERM(15) 를 사용해서 종료시켜 준다. SIGTERM 대신에 특정 signal을 명시해서 사용해도 무방하다.

사용되는 옵션들은 pgrep 과 같다. 다음은 user ID 가 dla 인 프로세스들을 종료시켜준다.

프로세스 Scheduling
cron 사용하기
시스템 관리자와 사용자들은 주기적으로 일어나는 작업에 대해서 매일매일 수동으로 수행하기 보다는 때가 되면 자동으로 원하는 작업이 정기적으로 실행되길 원한적이 있을 것이다.

cron 은 미래에 실행할 작업을 주기적으로 수행하도록 스케줄할 수 있게 해준다.
cron은 시스템이 부팅될 때 시작되는 데몬이다. cron 데몬은 crontab 파일을 참조해서 파일 안에 명시된 작업을 규정된 시간에 수행한다. crontab 파일은 /var/spool/cron/crontabs 디렉토리에서 읽어서 수행한다.
다른 시스템과 마찬가지로 cron 의 행위를 setting 할 수 있는데, 이들 setting 들은 /etc/default/cron 파일에 명시되어 있다.

cron 명령은 디폴트로 로그파일을 기록하도록 아래와 같이 /etc/default/cron 파일에 설정되어 있다.

이것이 설정되어 있으면 cron 의 모든 활동에 대한 로그를 /var/cron/log 파일안에 저장한다. log를 기록하고 싶지 않으면 YES 를 NO로 변경하면 된다.

이 외에도 /etc/default/cron 파일에 설정할 수 있는 내용은 cron 작업들의 PATH 와 SUPATH 를 아래와 같이 setting 시킬 수 있다.

cron 데몬은 /var/spool/cron/crontabs/ 아래의 파일들을 읽어서 예약해놓은 작업들을 실행한다. 이 디렉토리에는 시스템과 유저의 파일들을 포함하고 있는데, 파일의 이름은 유저의 이름과 동일하게 생성된다.

다음은 default 로 생성된 root 의 crontab 파일이다.

파일 안에는 space 또는 tab으로 분리된 6개의 엔트리를 가진다. 각 엔트리와 해당 값은 다음과 같다.

분(0-59), 시간(0-23), 일(1-31), 달(1-12), 요일(0-6: 일요일=0), 명령어

하나의 엔트리에는 2개 이상의 값을 표현할 수가 있다. 만약 1,2,3 월에 계속 하고 싶은 작업이라면 달에 해당 하는 값을 1-3으로 표시하거나, 컴마로 구분해서 1,2,3 과 같이 표현하는 것도 가능하다. * 는 모든 값에 다 해당한다는 표현이다.

그럼 이제부터 자신의 작업을 스케쥴링 해보자.

만약 guest 라는 user account 를 가진 사람이 일요일마다 12시 정각에 자신의 홈 디렉토리에 있는 test 명령을 실행 하도록 나의 crontab 파일을 만들어보자.

하고 입력하면 현재 세팅되어 있는 나의 crontab 파일의 내용이 출력된다.
물론 아무 내용이 없다면 출력되지 않을 것이다.
그럼 위의 작업을 스케쥴하려면

을 하고 나면 입력이 가능 하도록 되며 여기에 작업내용을 입력한다.

라고 입력하고 Ctrl+D를 입력하면 나의 /var/spool/cron/crontabs/guest 파일이 생성된다.

이 파일은 root 만이 볼 수 있고 수정할 수 있다.
내 crontab 파일을 수정하기 위해서는 아래와 같이 한다.

위와 같이 실행하고나면 사용자의 crontab 파일이 vi 편집기로 열린다. 여기서 수정을 하면 된다.

이렇게 작업을 예약하고 나면 알아서 cron 데몬이 해당되는 시간에 예약된 작업들을 수행시켜 준다. 만약 수행할 결과의 output 이 있다면 사용자에게 메일로 전달된다.

-r 옵션을 사용하면 사용자의 crontab 파일이 삭제된다.

crontab 파일에 접근허가는 /etc/cron.d/ 아래에 있는 cron.allow 와 cron.deny 2개의 파일로 컨트롤할 수 있다. 각 파일들에는 접근을 허락하기위한 또는 거절하기 위한 user account 이름을 한 줄에 하나씩 열거한 텍스트가 들어있다.

처음 시스템을 설정하고 나면 기본적으로 cron.allow 파일은 없고 cron.deny 파일만 존재한다.

at 사용하기

이 명령어는 특정시간에 명령 혹은 스크립트를 수행하게 하며, 단지 한번 수행된다는 점이 crontab 파일과는 다르다.

$ at [-m] [-r 작업] 시각 [날짜]

-m 옵션을 사용하면 작업이 끝난후에 사용자에게 메일을 보내준다. -r 옵션은 at명령어로 예약해 놓은 작업큐에서 작업을 삭제하기 위해 사용한다. 시각은 아래와 같이 여러 방법으로 규정될 수 있다.

간단한 예로 12시에 ls 를 수행하도록 작업을 예약하기 위해서는

이렇게 하면 975034800.a 라는 작업이 큐에 쌓이게 된다. 만일 오늘이 12시가 지났다면 다음날 12시에 수행하도록 작업이 설정된다. 큐의 내용을 확인하려면 atq 명령어를 사용한다.

큐의 작업을 삭제하려면 at -r 작업번호를 입력한다.

at 명령어도 역시 /usr/lib/cron/at.allow 와 /usr/lib/cron/at.deny 파일들에 의해서 접근을 컨트롤 할 수 있다.

프로세스의 자세한 정보 보기
솔라리스 프로세스의 핵심적인 특징중의 하나는 /proc 파일시스템으로 마운트되는 프로세스 파일 시스템이다. /proc 파일 시스템에는 PID를 이름으로 가진 현재 활동중인 프로세스의 이미지를 담고 있다. 예를 들면, 먼저 guest 라는 사용자의 프로세스에서 현재 shell 프로세스의 이미지를 살펴보자.

여기서 bash 의 PID 는 25909 이다. 이 프로세스의 이미지를 보기위해서는 /proc/25909 디렉토리로 가면 볼 수 있다.

이 디렉토리에는 프로세스의 상태 정보 등을 포함하고 있는 서브디렉토리들을 포함하고 있다. 서브디렉토리안에 있는 정보를 해석하기위한 tool 로 proc tool이 있다. 이것은 각 프로세스의 특징들을 출력시켜주는 역할을 한다.

proc tool 사용하기
proc tool들은 /proc 파일시스템 안에 있는 데이터들을 다루기 위한 것이다. 이 툴에 있는 유틸리티들로는 pflags, pcred, pfiles, pldd, pmap, psig, pstack, pstop, ptime, ptree, pwait, pwdx 가 있고, 모든 유틸리티들은 argument로 PID 를 사용한다.
각각이 하는 일이 무엇인지 하나씩 살펴보도록 하자.
pflags는 해당 PID 의 자세한 데이터 모델과, flag에 대한 정보를 보여준다.
위의 bash 쉘에 대한 사용 예를 보면 아래와 같다.

pcred 는 수행되는 프로세스의 effective, real, saved UID 와 GID 를 보여준다. pmap 은 프로세스의 메모리 세그먼트 사이즈와 address space 를 보여준다. 그리고 pldd 명령어는 각 프로세스에 링크된 dynamic libraries 를 보여준다.

pfile은 proc tool 중에 많이 쓰이는 명령어 중 하나이다. 이것의 역할은 각 프로세스의 모든 open 파일들을 출력해 준다. 출력내용은 파일이 저장되어 있는 파티션의 inode 번호, UID, GID, 접근허가 정보 등이다.

이 외에도 psig 는 각 프로세스의 signal action 리스트를 보여주고, pgrep 과 pkill 은 앞에서 언급했던 것처럼 프로세스의 목록을 보고 프로세스에게 시그널을 보내는 역할을 해준다. prun 은 process 를 running 시키고, pstop 은 kill 명령어와 같은 유사한 방법으로 프로세스를 중지시켜준다.

pstack 은 프로세스 thread 의 stack trace 를 보여주고, ptree 는 프로세스가 생성된 tree 를 process ID 를 통해 나타내준다.

프로세스의 시간 정보를 보기위해 사용되는 명령어로는 ptime 이 있고, pwait 는 프로세스가 끝나기를 기다리도록 하는 명령어이고, pwdx 는 프로세스의 working directory를 보여준다.

lsof 사용하기
lsof 는 list open file을 나타낸다. 이 명령어는 프로세스에 의해 현재 open된 파일들의 정보를 보여준다. 이 명렁어는 Solaris에 포함되어 있지는 않으나, ftp://vic.cc.purdue.edu/pub/tools/unix/lsof에서 최신 버전을 다운 받아서 사용할 수 있다. lsof 가 얼마나 유용한지에 관한 것은 얼마나 파일과 프로세스에 관련된 문제들에 많이 직면하는지에 달려 있다.

관리자들은 프로세스가 현재 사용하고 있는 파일이 무엇이고, 특정 디렉토리에서 어떤 파일들을 사용하는지 알고 싶을 때가 있을 것이다. 만약 어떤 파일이 다른 프로세스에 의해 사용되고 있어서 lock 되었을 경우, 그 파일을 사용하는 다른 프로세스는 파일을 사용할 수 없을 것이다. 후자의 프로세스를 수행시키고자 할 경우 전자의 프로세스의 PID 를 찾아서 이를 중지시킨 후 파일을 사용할 수 있을 것이다.

lsof 를 사용하면 디렉토리안에 파일들이 어떤 프로세스에 의해 사용되고 있는지 알 수 있다. 다음과 같이하면 /tmp 파일시스템에 있는 파일들이 어떤 프로세스에 의해 사용되는지 볼 수 있다.

파일시스템을 마운트하는 제한사항 중에 하나는 만일 파일시스템에 open 된 파일이 존재한다면 이 파일시스템은 unmount 시킬 수 없을 것이다. 그 이유는 파일시스템이 unmount 된다면 파일에 대한 변화된 정보를 기록할 수 없기 때문이다.

파일시스템을 unmount 하려고 했다가 실패를 한 경우, lsof 를 사용해 파일시스템 안의 파일중 open 된 파일의 리스트를 얻어서 해당 프로세스를 중지시키면 파일시스템을 무사히 unmount 시킬 수 있다.

디스크 관리
Windows 에 너무 익숙해져 있는 사람들은 앞부분부터 차근차근 읽도록 하고, 어느 정도 유닉스 파일 시스템(ufs)을 다뤄본 사람이라면, 앞부분은 대충 읽어나가도록 하자. 본 내용은 solaris x86를 기준으로 설명할 것이다. Disk 관리에 잇어서는 SPARC과 별다른 차이가 없으니, 모든 경우에 적용된다고 보아도 좋겠다.

솔라리스에서의 디스크 이름
솔라리스에서는 논리적 디바이스 이름(logical device name)으로 물리적 디바이스 이름(physical device name)에 링크를 걸어 사용을 한다. 아마도 리눅스의 hda1, sda1 등에 익숙한 사람들은 약간 어색할 것이며, freebsd 사용자의 경우는 그래도 조금 친근할 것이다.

Logical device names
Logical device name 은 우리가 알아보기 쉽도록 표시한 것을 말하며, 디스크의 경우 대부분 c0t0d0s7처럼 영문과 숫자의 조합으로 표시된다. 그럼 그 영문과 숫자의 의미를 알아보자.

- c0 : controller number가 0번임을 의미한다. 숫자는 OS에서 할당하기 때문에 우리는 그냥 쓰기만 하면 된다.
- t0 : target number가 0번임을 의미한다. IDE 에는 존재하지 않으며, SCSI의 경우는 id 번호가 된다.
- d0 : disk number가 0번이다.
- s7 : slice number가 7번이다. 슬라이스란 일반적으로 우리가 일컫는 파티션을 말하며, 이 숫자까지 와서야 비로소 우리가 정할 수 있다. Format 명령으로 파티션을 조직할 때 1부터 7번까지의 슬라이스 번호를 매길 수 있는데 그 중에 우리가 7번을 사용하고 있는 것이다.

Logical name 은 /dev/dsk(block device names) 와 /dev/rdsk(raw device names) 디렉토리에 존재하며, 실제로는 /devices 디렉토리의 복잡한 디바이스 이름에 링크되어 있다.

Physical device names
우리가 부팅을 할 때, kernel은 시스템에 부착된 디스크를 인식하고, /devices 디렉토리에 여러 문자로 이루어진 노드로 표현된다. 노드라 불리는 이 full device pathname 은 속성, 데이터 종류, 디스크 연결 방식에 관한 여러가지 정보를 담고 있다. 그 full device pathname 의 형식은 다음과 같이 이루어진다.

driver-name 은 device name 을 나타낸다.
@unit-address는 device 의 physical address를 나타내는데, 부모 주소 공간 안에서 부여가 된다.
:device arguments 에는 각 device 에 해당하는 소프트웨어를 위한 추가적인 정보가 정의된다.

예를 들어 다음의 device 명을 살펴 보면 SPARC 시스템의 스카시 드라이버의 한 슬라이스를 나타낸다는 것을 알 수 있다.

위의 내용을 보면, 1f,0 의 메인 시스템 버스 주소를 가지고 sbus 에 연결되어 있다. 그리고 esp 장치(scsi bus)에 0번 슬롯, 4000번 옵셋에 부착되어 있으며, SCSI target 번호가 3, 논리적 유닛 번호가 0인 sd 장치(scsi disk)라는 것을 알 수 있다.
조금 골치 아픈 얘기이기는 하지만 공부해 두도록 하자.

유용한 명령어들
백견이 불여일타 라고, 백번 읽어 봤자 소용없다. 직접 솔라리스 시스템에 앉아(또는 접속하여) 직접 다음의 명령어들을 수행해 보도록 하자.

디스크 마운트하기 - mount
디스크의 마운트 부분은 다른 부분을 참고하기 바란다.
LINK TO ...

디스크의 이용 상태 보기 - df
df 명령은 각 파일 시스템에 기초하여, 여분의 블록과 파일의 수를 리스트로 보여주는 명령이다. df를 실행시켰을 경우 다음과 같이 나타난다.

디스크 사용량 보기 - du
du 도 df와 마찬가지로 disk useage 를 보여주는 명령어인데, df가 마운트를 기준으로 보여준다고 하면, du 는 원하는 위치의 사용량을 알 수 있다.

우리는 주로 ?k 옵션을 사용하는데, 이것은 읽기 쉽게 kilo 단위로 표현해 주기 때문이다.

파일시스템 체크 - fsck
파일 시스템은 내부, 외부의 악조건으로 인해, 에러가 생기거나, 꼬이거나, 부서질 수 있다. fsck 는 filesystem check 를 위한 명령어로서, 아주 유용하게 쓰이는 유틸리티이다. 다음의 내용은 fsck 를 실행 시켜본 결과이다.

위에서 보인 예는 아무런 문제가 없는 파일 시스템 체크를 보여준 것이다. 5가지의 과정을 거치면서 하나하나 검사해 나간다. ** 참고로 검사를 원하는 슬라이스는 꼭 마운트를 풀어준 후 실행해야 한다. 그렇지 않다면 yes, no 를 묻는 경고가 나오겠지만, 꼭 마운트를 풀고 하도록 하자. fsck 는 일반적으로 시스템이 부팅되면서 실행이 되며, 관리자가 살펴봐야 할 정도로 심각한 이상이 보이면, single mode 로 들어가 fsck 를 실행해 볼 것을 권장하는 글이 출력된다.

새 디스크 추가하기 1
하드 디스크가 비싸던 그 옛날 옛적에는 필요하다고 무턱대고 구입하여 늘일 수 없었지만 지금은 필요하다면 raid로 묶어 몇 백 기가 바이트씩 사용하는 시대이다. 그만큼 디스크의 이동이나 교체 등이 잦은 작업이 되기 쉬운데, 그래서 꼭 알아야 하는 작업 중 하나이다.
솔라리스(x86 solaris 8)를 기준으로 디스크 추가 작업을 순서대로 알아보자.

시스템 reconfigure
시스템을 shutdown 한 후에 disk 를 설치한다. 하드웨어를 연결하는 일은 그다지 어려운 일이 아니므로 설명을 생략하도록 하겠다. 디스크 설치 후에 그냥 부팅을 한다면 시스템은 인식을 하지 못한다. 그래서 필요한 작업이 reconfigure 수행이다.

Reconfigure 방법엔 여러 가지가 있다.
/reconfigure 파일을 만들어 준 후 reboot 을 한다.
부팅 후 init에서 불러 들이는 rc.sysinit 파일에서는 root 디렉토리에 reconfigure 라는 파일의 존재를 파악해서 시스템이 변경된 부분이 있는지 kernel 을 rebuild 하게 한다. 참고로 / 디렉토리는 root 만이 쓸 수 있으니 반드시 root로 로그인해야 한다.

이때 만들어진 reconfigure 파일은 재부팅 시 rebuild 후 자동으로 삭제된다.
부팅 후 쉘 상태에서 다음과 같이 입력한다.

부팅 시 옵션을 입력한다.
x86 버전의 경우 부팅 후 (b)oot (i)nterprete 를 고르는 부분이 있는데, 이곳에 b ?r을 입력한다.
PROM 프롬프트 에서는 boot ?r 을 입력한다.
위와 같은 방법을 거쳐 booting 이 된 후에야 다음 작업을 할 수 있다.

새 디스크 추가하기 2
Format
설치할 디스크 고르기
Format 명령을 하면 커널에서 인식하고 있는 디스크들을 나열한다.

위의 출력을 통해 ide 하드 디스크를 2개 가지고 있다는 것을 알 수 있다. 새로 설치한 디스크가 1번이라 가정하고 다음으로 넘어가자. 주의할 점은 이 명령 역시 디스크를 다루는 명령으로서 마운트가 되어 있으면 안된다. 물론 새로 산 디스크를 마운트 했을 리는 없지만, 예를 들자면, re-partitioning 할 경우에 주의해야 한다.

위의 메뉴는 고른 디스크에 대해 작업할 수 있는 format menu 이다. 우리는 우선 fdisk 를 통해 솔라리스 파일 시스템으로 만들어 주어야 한다.

파일 시스템 결정 및 저장
fdisk 를 입력하면 다음과 같은 메시지가 뜬다.

필자의 디스크인데, 이미 ufs 로 포맷하여 사용하고 있기 때문에 사용량 등등에 관한 정보가 나온다. 만약 디스크 자체를 새로 구성하고 싶다면(re-partition이 아니다, re-partition 은 이 다음에 할 수 있다) 솔라리스 파일 시스템을 지우는 3번을 선택하고 지우면 된다. 저장 후 다시 메뉴로 나가기 위해서는 4. Exit 를 선택하여야 하는데, 만약 새 디스크라면 1. Create a partition 에서 100% solaris 파티션을 설정해 준 뒤에, 4. Exit 를 선택하도록 하자.

파티션 나누기
이제 100% 솔라리스 파티션인 이 디스크를 여러 슬라이스로 나눌 차례이다.
partition 을 입력해 보자.

위에서 볼 수 있듯, 8개의 슬라이스가 있다. 하지만 우리가 건드릴 수 있는 것은 7개이다.
이 상태에서 print 명령을 통해 현재 디스크의 슬라이스 상태를 알아보자.

필자는 이미 0번과 1번의 슬라이스를 만들어 두었다. 만드는 것은 쉽다. 변경하고 싶은 슬라이스 번호를 입력하여 용량이나 실린더 수 등으로 partitioning이 가능하다. 위에서 s2(두번째 슬라이스)에 tag 가 backup 인 것을 유심히 보자. 이것은 기본적으로 쓰이지 않는 슬라이스이며, 디스크의 전체 용량을 나타낸다. 2번 슬라이스는 건드리지 않도록 하자.
다 했다면 quit 입력으로 format 메뉴로 빠져 나온다.

relabel
format 메뉴에서 빠져 나오기 전에 꼭 해줘야 할 명령이 있다. relabel 작업인데, 지금까지 슬라이스를 나눈 정보를 저장하는 작업이다. 만일 제대로 안 해준다면 다시 한번 위의 작업을 복습해야 하는 좋은 기회(?)가 될지도 모르겠다. 하지만 우리는 시간도 없는데 그런 짓은 하지 말자. 그냥 label 을 입력하여, 가볍게 yes 를 눌러주자. 그런 다음 quit 를 입력하여 shell 상태로 나오자.

새 디스크 추가하기 3
newfs
이제 디스크의 각 부분들이 자리를 잡았다. 각 슬라이스 별로 newfs 명령을 통해 파일 시스템을 재구성해줘야 한다.
우선 format 한 상황을 종합해 보자. c0d1 인 디스크에서 s0번과 s1번의 두개의 슬라이스로 나누었다. 앗 윗장에서 다 설명한 것들이 아닌가! 역시 뭐든 공부해 두면 다 써먹게 되어 있다. 윗장을 읽었음에도 잘 기억이 안 나는 사람은 자신의 머리와 부모님을 원망해가며 다시 한번 정진하도록 하자. 아무나 다 유닉스를 쓴다면, 난 유닉스를 쓰지 않았을 것이다. 라는 유닉스 유저도 꽤 있다. 만만하게 보지 말자.

다음과 같이 명령을 내려줘야 할 것이다.

이 작업에서 super block 의 지정 등 여러 작업이 이루어지며 드디어 우리가 마운트 할 수 있는 디스크가 생긴 것이다.

Chapter 네트워크 관리
라우팅
서로 다른 machine들간의 통신은 routing을 통한 data packet 전달로 이루어진다. 여기서 routing이란 서로 다른 두 host간 통신에 사용되는 data packet을 목적지로 전달하기 위해서 보낼 path를 찾는 Internet Protocol의 중요한 기능 중 하나이다.

두 host가 같은 네트워크에 존재하거나중간에 수많은 host들이 연결되어 있거나 기초적인 원리는 모두 같다.

네트워크 인터페이스
네트워크 인터페이스 확인
ifconfig 명령은 네트워크 인터페이스를 설정하거나 네트워크 인터페이스에 address를 할당할 때 사용된다.

elxl0: 인터페이스 이름.
UP: 인터페이스 사용가능.
BROADCAST: Ethernet과 같은 broadcast를 지원해 주는 네트워크에 연결되어 있음.
NOTRAILERS:
RUNNING: 현재 동작 중.
mtu: 최대 전송 단위

현재 네트워크 인터페이스의 상태를 확인하기 위해서는 netstat 명령을 사용한다.
-n 옵션을 사용할 경우 결과를 숫자 형태로 보여준다.

Net/Dest: network destination field는 인터페이스가 접근을 제공하는 네트워크나 목적지 host를 보여준다.
lpkts: input packets field로 수신된 손상 packet의 수를 보여준다.

lerrs: input errors field로 손상된 packet의 수를 보여준다.
Opkts: output field로 전송한 packet 수를 보여준다.
Oerrs: output packet field로 전송한 손상 packet 수를 보여준다.
Collis: ethernet 충돌 횟수를 보여준다.
Queue: queue에 대기 중인 packet의 수를 보여준다.

인터페이스 parameter 변경
네트워크 인터페이스 parameter를 수정하는 방법은 두 가지가 있다.
- ifconfig 명령은 네트워크 인터페이스 parameter들을 수정하고인터페이스를 on-line("up) 또는 down("down) 할 수 있다.
- ndd 명령은 네트워크 인터페이스 parameter를 TCP/IP 전송에 맞추기 위해 사용할 수 있다.

ifconfig

ndd
ndd 명령은 네트워크 인터페이스 parameter들을 TCP, IP, UDP와 ARP 네트워크 프로토콜들에 맞게 설정하기 위해 사용된다. ndd 명령은 IP 전송과 routing관련 parameter들을 설정 및 수정하기 위해 사용된다. 다음은 TCP 전송을 위해 설정된 parameter들이다.

라우팅 확인과 설정 방법
어떤 packet을 전송할 때 packet이 host와 router, router와 router간에 어떤 경로로 전송되는지를 확인해 볼 수 있다. 다음은 traceroute 명령어로 packet 전송을 처리하는 path를 알아보고현재 사용되고 있는 routing 프로토콜과 routing을 설정하는 방법을 알아본다.
routing을 설정하는 방법은 static routing과 dynamic routing으로 분류하는데 static routing은 보통 소수의 host들로 이루어진 단순한 네트워크의 연결에 사용되고 dynamic routing은 보다 큰 네트워크에 더 알맞다.

traceroute
traceroute 는 ping과 비슷한 역할을 하지만, 좀 더 자세한 정보를 알려준다. 자기가 원하는 host에 도달하기까지 시간과 지나가는 host들, 즉 path를 보여준다.
만일 중간의 host가 지정 받았던 시간에 연락을 취하게 될 수 없으면, 에러 메시지가 보고 된다.
hops의 최대 숫자(보통 30)는 목적지까지 거치는 gateway의 숫자를 나타내는 데 사용할 수 있는 path를 찾지 못했을 경우 traceroute 실행에 대한 무한 루핑을 막기 위해 지정한다.

정적 라우팅
static routing은 시스템 관리자가 route" 명령으로 수작업을 해야 한다.
/etc/defaultrouter file을 만들어 그 안에 default router의 IP address를 적는다. 이렇게 하면 system booting시 아래와 같은 명령에 의해 defaultrouter를 설정한다.

만일 /etc/defaultrouter file안에 여러 개의 defaultrouter가 정의되어 있으면 위의 명령이 여러 번 수행되어 여러 개의 defaultrouter가 설정된다.

in.routed daemon에 의해 static routing을 설정할 수도 있는데, 이를 위해서는 /etc/gateways file에 routing에 관한 설정을 하면 된다.

- active: 지정된 gateway로부터 일정시간(30초)동안 새로운 routing 정보를 update 받지 못하면 routing table에서 없어진다.
- passive: routing table에서 지워지지 않고 계속 보존된다.

라우팅 테이블
routing table은 네트워크의 router들과 local host에서 이용할 수 있는 router들의 index를 가지고 있다. route는 RDISC를 사용해 동적으로 정할 수 있고 route 나 ifconfig명령을 사용해 수동으로 추가할 수도 있다.

route의 종류에는 3가지가 있다.
- host route: local host에서 다른 host로의 path를 map으로 만든다
- network route: local host에서 다른 host로 packet을 전송한다.
- default route: router의 route를 찾는 작업을 거친다.

dynamic routing은 booting 후에 자주 routing table을 변화시킨다. booting시 최초의 routing table은 daemon이 관리하지만 이후에 각 네트워크 인터페이스는 ifconfig 명령어사용에 따라 추가 또는 변경될 수 있기 때문이다.

라우팅 테이블 확인
netstat -r 명령은 현재의 routing table을 보여준다. route는 항상 어떤 gateway를 통해서 local server와 remote machine을 연결한다.

routing table에서 flag의 의미는 다음과 같다.
U: 목적지와 gateway사이에 route를 사용할 수 있음을 나타냄.
G: route가 gateway를 통해 나가는 것을 나타냄.
H: route가 host에 연결되는 것을 나타냄.
D: 다른 gateway가 목적지에 도달하기 위해 더 좋다고 여겨질 때, redirect을 사용하여 동적으로 host에게 알려줌.

아래 table에 표기된 번호는 route를 순서대로 표시한 것이다.

rount 명령에 의한 route 추가
route 명령은 수동으로 routing table을 조작하기 위해 사용한다. 만일 dynamic routing이 정확히 수행되고 있으면, 사용할 필요가 없지만 static routing이 사용되고 있거나 RDISC daemon이 어떤 route들도 발견하지 못하면, 수동으로 route들을 추가해야 한다. 인터페이스 변경을 제외하고routing table을 수동으로 수정했을 경우, 모든 변경이 끝난 후엔 반드시 routing daemon을 다시 시작해야 한다.

- host route 추가
사용법: route add ?host destination_ip local_ip -interface interface

- network route 추가
사용법: route add -net destination_network_ip local_ip -netmask mask

- default route 추가
사용법: route add default hostname -interface interfce

동적 라우팅
dynamic routing의 전제 조건은 /etc/defaultrouter file이 비어 있어야 한다.
시스템이 booting될 때, /etc/defaultrouter file이 없으면 /usr/sbin/in.rdisc daemon이 실행되면서 local network상에 routing 정보를 알려주고 있는 시스템 또는 router를 default router로 설정한다.
시스템이 booting되면서 먼저 /etc/defaultrouter file을 확인하고 없는 경우에는 시스템에 사용중인 네트워크 인터페이스를 확인한다. 사용중인 인터페이스가 하나일 때, IP 관련 parameter중 ip_forwading의 값을 0으로 설정하고 in.rdisc daemon은 multicast를 이용하여 network상에 3번의 solicitations 메시지를 보내서 이에 응답하는 시스템을 default router로 설정한다.

daemon이 -s 옵션으로 실행된 경우 default router를 찾지 못하면 실행이 종료되고 만일 두 개 이상의 default router를 찾게 되면 이들 모두를 default router로 설정해서 routing table에는 여러 개의 default router가 존재하게 된다.
in.rdisc daemon이 default router를 찾지 못했을 때에는 in.routed daemon이 -q 옵션으로 실행되어 네트워크 연결이 생길 때마다 routing table에 routing정보를 만든다.

-q 옵션을 사용할 경우 daemon은 가지고 있는 routing정보를 외부로 알리지 않는다.

다음으로 네트워크 인터페이스가 두 개 이상일 경우 IP관련 parameter중 ip_forwading의 값을 1로 설정하여 하나의 인터페이스에서 보내진 packet이 다른 인터페이스로 전달될 수 있게 한다. routing 정보를 다른 시스템과 교환할 수 있도록 -s옵션으로 daemon이 수행된다.

-s 옵션으로 in.routed가 수행되면 자신이 가지고 있는 routing정보를 다른 시스템과 교환할 수 있다.

먼저 in.rdisc daemon이 -r 옵션으로 실행되어 default router를 찾아 설정하고, 자신도 네트워크상에서 router discovery advertise메시지를 뿌려서 다른 시스템들이 자신을 default router로 설정할 수 있도록 한다.

라우팅 프로토콜

Routing Information Protocol(RIP)와 Router Discovery Protocol(RDISC)는 TCP/IP 네트워크를 위한 표준 routing 프로토콜로 Solaris에서는 이 두 가지를 모두 지원하고 있다.
RIP는 routing daemon in.routed에 의해 실행되고in.routed는 routing table에 모든 네트워크 연결에 대한 routing 정보를 준다. 그리고 이 routing 정보를 다른 시스템에 통지하는 것은 옵션으로 선택할 수 있다. RIP는 interior routing 프로토콜로서, 현재 가장 널리 사용되어지는 프로토콜 중 하나이며, RIP에서는 도달할 목적지까지 몇 개의 gateway를 거치는가를 측정하기 위해서 hops를 사용한다. 어떤 인터페이스에 직접 연결되어 있을 때 hops는 0, 통신을 할 수 있는 최대의 hops는 15로 목적지 네트워크까지 16을 초과 할 때는 통신을 할 수가 없다. RIP는 Distance Vector 방식을 채용하고 있는 대표적인 프로토콜로서 각각의 router가, 인접하고 있는 router와 routing 정보를 교환하여 30초마다 router로 전달하여 routing 하도록 하는 방법이다.
host는 router에서 routing에 관한 정보를 수집할 때 RDISC daemon (in.rdisc)을 사용한다. RDISC는 router와 host들 사이에서 실행되어야 하는데 일반적으로 요청에 대응하는 각 router를 위해 in.rdisc는 default route를 설정한다. 이 router는 동적인 네트워크 환경 변화에 적응하기 위해서 RDISC가 가능한 host를 중심으로 한다.

IP Filtering
IP filtering은 TCP와 UDP port의 access 권한과 선택의 제한을 둔다. IP filtering은 일반적으로 두 가지 목적에 의해 사용되는데 첫째로 외부로부터의 네트워크 침입을 방지하고 둘째는 내부 네트워크에서 허가되지 않은 자료가 밖으로 전달되는 것을 막는 것이다. 예를 들어 telnet 같은 어플리케이션을 사용하여 시스템에 침입을 시도하거나 클라이언트 어플리케이션으로부터 발생하는 SQL 명령에 의해 database에서 data를 얻으려고 할 수 있다. 이런 이유로 많은 사이트에서 특정 port를 제외한 외부로부터의 들어오는 traffic을 제한하고 있다.
아래는 일반적으로 허가되는 port들과 firewall 같이 packet filtering을 하는 router의 역할을 요약한 그림이다.

- Secure shell (ssh): port 22
- Secure copy(scp): port 24
- Mail server(sendmail): port 25
- WWW server(apache): port 80

IPFilter는 freeware로 Solaris를 위한 firewall package로 아래의 site에서 download 할 수 있다.

http://coombs.anu.edu.au/~avalon/

IPFilter는 configuration file에서 아래의 명령들로 지정되는 rule에 의해 모든 traffic을 처리한다.

- block: 특정 source에서 destination까지 packet들의 traffic을 막는다.
block in quick from 178.222.0.0/16 to any
- pass: packet들이 firewall을 통과하도록 허가한다.
pass in all
- from/to: packet들의 출발지와 목적지를 지정한다.
- out/in: 외부로 나가는 것과 들어오는 것을 제한한다.
block out quick from 10.222.1.0/24 to any
block in quick from 10.222.1.0./24 to any

DNS(Domain Name Service)
DNS란?
인터넷상의 모든 host간의 통신은 TCP/IP 프로토콜과 각 host마다 가지고 있는 32bits의 IP address를 기반으로 한다. 사용자가 어떤 host에 접속하고자 할 때 IP address만을 사용한다면, 이 address안의 내용을 알아 보거나 기억하기가 어렵기 때문에 기억하기 쉽도록 영문으로 사용하는 것이 domain name이다. 하지만 domain name은 사용자를 위한 것으로 host가 인지할 수 있도록 IP address로 바꿔 주는 작업이 필요하다. 이러한 역할을 하는 것이 DNS(Domain Name Service/System)이다.

과거에는 이러한 역할을 관리하는 방법으로 수백개의 host정보들을 가지고 있는 HOST.TXT file을 사용했다. 이 file은 각 network관리자가 host정보를 SRI-NIC에 보내면 HOST.TXT file에 저장되고 새로운 host가 추가될 때마다 ftp로 보내져 download하여 사용했다. 그러나 이러한 시스템은 HOST.TXT file이 변경될 때까지 전체 network에 포함될 수 없고, host정보가 증가함에 따라 HOST.TXT file이 커져 network traffic을 증가시키며, 다른 IP에 같은 이름이 사용되는 현상 등의 문제를 발생시켰다.

이런 문제점 때문에 local network관리자에 의해 data 수정이 쉽고, host정보를 가진 하나의 server에 대한 traffic을 분산시키며, 계층적 name space를 유지할 수 있는 방법이 필요했다. DNS는 이러한 환경에서 출현하게 되었고 /etc/hosts file은 HOST.TXT file의 역할을 한다.

DNS의 Domain Structure

DNS의 name space는 unix의 file sytem과 유사한 계층적 구조로 이루어져 있다. tree의 level은 최대 127개까지 가능하고 모든 node는 최대 63개의 문자로 이루어지는 label을 가지며 tree의 root는 특별한 node로 null label을 갖는다.

top-level domains
top-level domain들은 root domain아래 organizational 과 geographical 두 가지 형태로 위치한다. (예: us, com, org, net 등)
organizational top-level domain은 미국의 특별한 기관에서 사용하는 domain이고 geographical domain은 특정 국가의 domain이다. 국가 기관 domain을 사용할 경우 기관 domain의 표기가 아래 표와 같이 달라진다.

domain name의 형식: host명.단체명.기관domain.국가domain

의미 국가 domain 미사용 국가 domain 사용 예
상업기관 .com .co cisco.com
교육기관 .edu .ac berkeley.edu
정부기관 .gov .go nasa.gov
군사기관 .mil - navy.mil
네트워크 .net .nm bbnplanet.net
연구기관 - .re kordic.re.kr
그외 다른 기관 .org .or pbs.org
주소를 역으로 찾기 위해 사용 .arpa - sri-nir.arpa

subdomains
domain은 매우 많은 host들이 있을 때 혼란스럽게 되기 시작한다. subdomain은 물리적 위치 또는 비즈니스 기능에 의해서 관계가 있는 host들을 그룹화하기 위해 만들어질 수 있다. 이것은 subdirectory 생성과 유사하다. 만일 특별한 directory가 너무나 많은 파일들을 포함하면 subdirectory를 만들 수 있고 조직화된 file system을 유지하기 위해 관련된 파일들을 옮기게 된다. 새로운 subdomain들은 DNS tree에서 언제라도 만들어질 수 있고 domain과 그 subdomain parent-and-child 관계가 된다. parent가 subdomain을 만들 때 parent는 child의 name server의 address만을 알고 있고 그 subdomain에 대한 권한을 위임하게 된다. 이렇게 한 subtree에 대해 권한을 가질 때 그 subtree로 구성되는 공간을 zone이라고 한다. subdomain들은 모두 zones에 속해 있는데 이것들은 단지 특별한 name server의 통제 아래에 이름을 가지고 있는 tree의 한 부분이다.
위의 tree에서는, bosland.us domain은 tree subdomain들을 가지고 있는 것을 볼 수 있다. bosland.us를 위한 name server와 rem.bosland.us는 같은 시스템으로 하나의 zone에 있다.

DNS Queries

아래 그림은 DNS client에 의해 요청된 host name www.yahoo.com에 대해 그것의 IP address를 응답으로 받게 되는 과정을 순서대로 나타낸 것이다.

DNS Client Configuration
DNS를 구성은 DNS client와 server를 configuration하는 두 부분으로 나뉜다.
대부분의 host들은 DNS 서비스를 요청하는 client형태이기 때문에 resolver 기능만을 이용하여 name service를 받는 DNS client로 설치하면 된다.
구성방법은 /etc/resolv.conf과 /etc/nsswitch file만 수정하면 된다.

"/etc/resolv.conf" 파일
resolve.conf file은 domain, nameserver, search, sortlist 등의 명령어로 구성되어 있고 comment를 할 수 있다.

domain
자신의 domain 이름을 적는다.
domain sangmyung.ac.kr

nameserver
자신의 domain을 위한 name server의 IP address를 적는다.
nameserver 203.237.168.1

search
host의 domain을 자동으로 search하기 위해 사용한다.
main domain안에 다른 subdomain들을 6개까지 list로 줄 수 있다.
search sangmyung.ac.kr
search sangmyung.ac.kr pine.sangmyung.ac.kr

sortlist
다른 name server에 연결된 두 network에 대해서 응답순서를 정할 수 있다.
만일 네트워크들 중의 하나가 subnet이라면 네트워크 주소와 subnet 주소를 지정할 수 있다.

comment
resolv.conf file에 ;로 시작하는 line에는 comment를 추가할 수 있다.

DNS Server Configuration
DNS server configuration시 필요한 file은 /etc/resolv.conf, /etc/named.conf, /etc/nsswitch.conf file이며, name server daemon /usr/sbin/in.named이 필요하다. configuration시 name server를 master, slave, 또는 hint name server로 실행시킬 수 있다.

master name server는 한 domain에 속해 있는 host의 name들을 가지고 있는 server로 domain name service를 수행한다. slave name server는 master name server에 이상이 생겨서 외부로부터의 query에 응답할 수 없을 때 대신하여 작업을 한다.

name sever의 configuration은 name server configuration file을 만드는 것과 domain에 대한 정보를 포함하고 있는 zone database를 만드는 것으로 나뉜다.

Solaris 8에서 name server configuration file은 /etc/named.conf에 있다. 여기서는 대부분 공통적으로 사용되는 옵션들에 대해 설명하므로 더 자세한 내용을 원한다면 in.named의 man page나 online configuration guide를 참고하면 된다.

http://www.isc.org/view.cgi?/products/BIND/docs/config/index.phtml

"/etc/named.conf" 파일
/etc/named.conf의 기본적인 형식은 아래와 같다.

여기서, 우리가 작성할 directive는 options와 zone이며 parameter는 한 줄에 하나씩 주고 줄의 끝은 ;으로 끝낸다.
두 가지 directive의 작성 예는 다음과 같다.

options directive 예:

options directive의 작성 예에서 directory parameter는 zone database file들이 저장되는 directory를 지정하고, pid-file parameter는 수행중인 name server의 process ID를
포함하고 있는 파일의 위치를 directory로 지정하면 된다.

zone directive 예:

zone directive에서 bosland.us는 master name server의 domain이고 file parameter db.bosland은 지정 받았던 domain bosland.us을 위한 database를 포함하고 있는 file의 pathname이다. 마지막으로 type parameter에서 master name server임을 지정했다.
만일 slave name server를 위한 zone directive는 다음과 같이 작성한다.

bosland.us는 slave name server의 domain이고 file parameter의 master name server의 경우와 같이 bosland.us를 위한 database 를 포함하는 file의 pathname이며 type을 slave로 지정한다. 그리고 bosland.us domain을 위한 master name server의 IP address를 masters parameter에 지정해주면 된다.

master, slave에 이어 type이 hint인 zone을 작성한다. .은 root-domain으로 root zone에 대한 server들을 지정한다.

다음은 차례대로 bosland.us domain의 master name server와 slave name server를 위한 named.conf file의 예이다.

zone database files
zone database file을 만드는 것은 resource record의 기능과 형식에 관해 알고 있으면 쉽게 할 수 있다.

database file을 만드는 것은 zone database를 보관하려는 directory(/var/named)에 db.domain, db.network 와 db.127.0.0 database file을 만드는 것이다. file을 만들 때 db.cache file은 간단하게 ftp://ftp.rs.internic.net/domain/named.root file을 가지고 와서 db.cache file로 바꾸면 된다.

resource record라 불리는 database file의 field는 아래와 같다.

{name} {ttl} class RecordType RecordSpeicific data
name: domain name을 나타내며 생략될 수 있다.
ttl: time-to-live field, 얼마나 오랫동안 cache data를 보관하는가를 지정하며 생략될 수 있다.
class: record의 class 지정. TCP/IP protocol에서는 IN을 사용한다.
type: type은 아래 표와 같다.

Type Name 기능
SOA Start Of Authority zone의 authority정의
NS Name Server name server의 정의
A Address name to address 변환
PTR Pinter address to name 변환

MX Mail Exchanger e-mail routing 제어
CNAME Canonical Name host의 nickname
HINFO Host Info hardware와 os 정보
RP Responsible Person host 관리자 정보

SOA 의 형태

name : zone의 이름
origin : database file이 있는 host의 이름.
person_in_charge : name server를 관리하는 사람의 메일 주소.
serial : database file의 버전. file 내용을 update하면 반드시 이 값을 바꿔야 한다.
refresh : slave server가 master server에게 update된 내용이 있는지 check하는 시간 간격.
expire : slave server가 refresh check를 실패했을 때 얼마 후 다시 재시도 할 것인지 지정.
minium : ttl 값이 지정되어 있지 않을 때 default time to live의 값.

db.domain

지정된 domain(bosland.us)의 host들에 관한 정보를 담고 있는 bd.domain file로 작성할 file name은 db.bosland이다.

db.network
지정된 domain(bosland.us)을 위한 bd.network file로 작성할 file name은 db.10.0.0이다. 이 file은 bosland.us domain에서 host의 IP address를 host name으로 mapping하기 위한 정보를 담고 있는 file이다.

db.127.0.0.0.

db.cache

db.cache file은 ftp://ftp.rs.internic.net/domain/named.root file을 download한 후 db.cache file로 바꾼다. 이 file은 root domain(.)에 대한 server들을 지정하는 file 이다.

그 외 파일들

- /etc/resolv.conf
domain bosland.us
nameserver 10.0.0.2

- /etc/nsswitch.conf
hosts: files dns

name server의 starting과 stopping
name server의 daemon은 /usr/sbin/in.named이고 system이 booting 시에 설정 파일인 /etc/named.conf file이 있으면 자동적으로 실행된다.
수행중인 name server를 중지하거나 재 시작할 때 kill 명령을 사용한다.

name server test
name server 설치가 제대로 됐는지 확인하는 방법으로 host를 nslookup 명령을 사용하여 확인해 본다.

위와 같이 하여 두 명령이 지정 host의 IP address를 보여주면 name server의 설치가 완료된 것이다.

DHCP(Dynamic Host Configuration Protocol)
인터넷이 처음으로 실용화 되었을 때에는 대부분의 컴퓨터가 특정한 위치에 고정되어 있는 것이었으며 IP 주소 공간 또한 충분했기 때문에 특정 IP를 고정적으로 할당하는 것이 간단했다. 그러나 오늘에는 쉽게 가지고 다닐 수 있는 노트북 컴퓨터 등의 사용이 일반화되어 그러한 컴퓨터에 대해 고정 IP를 부여하고 네트워크을 옮길 때 마다 일일이 IP를 해당 네트웍에 맞도록 다시 지정해준다는 것은 무척 불편한 일이 아닐 수 없다.

DHCP는 네트워크상의 특정 서버로부터 정보를 받아 자신의 IP를 동적으로 정해주도록 하는 방법이다.

DHCP란?
DHCP는 Internet Engineering Task Force(IETF)의 Dynamic Host Configuration Working Group에서 만들어 졌으며, IP 네트워크 상의 각 컴퓨터가 DHCP 서버로부터 configuration을 받아내도록 설계되었다. DHCP 서버는 기본적으로 각 컴퓨터(DHCP 클라이언트)에 IP 주소를 할당하는 일을 하며, 그 외의 각종 네트워크 변수들 ? 서브네트 마스크, default 라우터, DNS 서버 등도 제공한다.
DHCP는 Bootstrap Protocol(BOOTP-네트웍 상의 diskless 컴퓨터를 부팅하기위한 방법)로부터 출발하였기 때문에 BOOTP와 어느 정도의 호환성을 유지하고 있다. 그러나 수시로 네트워크에 추가되는 호스트에 IP를 동적으로 부여하는 일은 DHCP 고유의 특징이라고 할 수 있다. DHCP는 자신이 속한 네트워크 뿐만 아니라 라우터로 연결된 다른 네트웍의 클라이언트에게 IP를 부여할 수도 있다.

DHCP의 작동
DHCP는 다음 그림과 같이 작동한다.

먼저 DHCP 클라이언트가 자신의 네트워크상에 있는 DHCP 서버를 찾는다. 서버에서는 IP 주소와 configuration 정보를 해당 클라이언트에 보낸다. 클라이언트에서는 이중 하나를 선택하여 선택된 정보를 보내온 서버에게 DHCP를 요구하는 메시지를 보낸다. 해당 서버는 클라이언트에게 확인 메시지를 보내며 이에 따라 클라이언트의 설정이 마무리된다.
DHCP 서버가 해당 IP를 영원히 내어주는 것이 아니기 때문에 임대한 시간(lease time)이후에도 계속 사용하기 위해서는 renewal 절차를 거쳐야 한다. 이 절차도 그림에 보는 것과 같이 클라이언트가 renewal 을 요청하고 서버가 이를 확인해 줌으로서 이루어 진다.
추후 클라이언트의 사용이 끝나면 IP를 DHCP 서버에게 반환함으로써 모든 과정이 끝나게 된다.

DHCP의 단점
비록 DHCP가 동적으로 IP를 지정하는데 있어 빠르고 또한 사용자가 관여할 필요가 없는 편리한 방법이기는 하지만 클라이언트가 특정한 호스트 이름을 요청할 수 없고 서버가 고장이 나는 경우에 대한 대비책이 없는 단점을 가지고 있다.

DHCP 서버 configuration
서버 설정에서 해야 할 일은 다음과 같은 세 단계이다. 우선 DHCP에 의해 할당 되어질 IP 주소의 범위를 정해야 한다. 다음으로 dhcpconfig 명령을 사용하여 몇 개의 DHCP 서버를 설정해야 하고, 마지막으로 DCHP daemon을 부트 시에 자동적으로 start하도록 boot 프로세스에 포함하여야 한다.

IP 주소 공간의 할당
일단 네트웍 상에서 몇 개의 IP를 관리해야 하는지 명확하게 알고 있어야 하며 이를 기반으로 정적으로 IP를 할당할 호스트의 수와 DCHP를 사용하여 동적으로 IP를 할당할 호스트의 수를 결정한다. 일반적으로 UNIX, NT 등 서버에 해당하는 기계와 라우터, 네트워크 스위치 등의 기계는 고정적인 IP를 할당해 주어야 하는 기계들이며 DHCP 서버 역시 마찬가지 이다. 노트북이나 랩탑 컴퓨터 등은 전형적인 동적 호스트이다. 따라서 이들에게는 DHCP를 사용하여 동적으로 IP를 할당하는 것이 가능하다. 일반적으로 동적 호스트의 수가 많을수록 DHCP 서버의 수도 늘려 주어야 전체적인 부하의 안정을 가져올 수 있으며 한, 두 서버가 작동하지 않는 경우에도 대비할 수 있다. 만일 동적으로 할당해야 하는 IP의 수가 50-100정도라면 3-4개의 DHCP 서버를 두도록 하는 것이 바람직할 것이다.

dhcpconfig 사용하기
네트워크의 IP 주소 사용에 대한 계획이 수립되면 비로소 DHCP 서버 설정에 들어갈 수 있다. Solaris 시스템에서는 다음과 같이 dhcpconfig 명령을 사용한다. 물론 루트권한이 있어야 수행 할 수 있다.

이 명령은 다음과 같은 메뉴를 출력한다.

1번이 현재 호스트를 DHCP 서버로 설정하기위한 옵션이고 2번은 DHCP 요청을 다른 서버에 전달하기 위한 목적으로 사용한다. 3번은 현재 작동하고 있는 DHCP 서버를 제거하는 데에 사용한다.

설정을 시작하기 위해서는 1번을 선택한다. 그러면 다음과 같은 물음이 나온다.

새로운 설정을 위해 현재 작동중인 DHCP 서버를 멈추자는 내용이다. Y가 default로 되어있으며 Enter만 누르면 default 선택이 이루어진다.
이후 진행될 과정을 요약하면 다음과 같다.

-DHCP 데이터베이스 설정
-DHCP 서버 옵션 설정
-dhcptab 초기화
-지역 네트워크에서 DHCP 활성
-원격 네트워크에서 DHCP 설정

각 과정은 2-3개정도의 질문과 답으로 이루어 진다.

DHCP 데이터베이스 설정

DHCP 데이터베이스란 IP 주소의 결정을 위해 사용하는 파일을 말한다.

위와 같은 질문에 NIS+를 사용하는 경우에는 nisplus로 그렇지 않은 경우엔 files로 답해 준다. 파일을 선택하면 DHCP 데이터베이스의 위치를 묻는 질문이 나온다.

/var/dhcp 정도가 적당한 위치이지만, 관리의 필요에 따라서는 적당히 바꿔줄 수 있다

DHCP 서버 옵션 설정

첫번째 질문은 다음과 같다.

default 값을 사용하지 않는 경우에는 Y를 선택하고 daemon의 각종 변수들의 값을 주어야 하지만 보통의 경우 N를 선택해도 별 문제는 없다.

dhcptab의 초기화

이 파일은 서버의 활동과 관계가 있는 각종 정보를 가지고 있다. 첫번째 질문은 다음과 같다.

이것은 한번 내준 IP 주소를 얼마간 유지 할 것인가 하는 질문으로 얼마나 자주 새롭게 할 것인가와 밀접한 연관이 있다. 보다 자주 확인하기 위해서는 1-2일로 줄여주어도 된다. 그러나 자주 확인을 하면 할수록 네트워크에는 부담이 된다는 사실을 기억해야 한다.

다음 질문은 클라이언트가 IP의 임대기간을 연장하는 협상을 하도록 허용할 것인가 하는 부분인데 재협상을 허용하면 네트워크의 부하는 줄게 되므로 Y를 선택하도록 한다.

DHCP 활성

지역 네트워크에서 DHCP의 활성여부를 묻는 질문이다. Y로 대답하면 다음 질문을 맞게 된다.

DHCP를 사용하려는 네트워크 주소가 정확한가를 확인하고 Y를 입력한다. 만일 잘못되었다면 N를 입력하고 지역 네트워크의 IP 주소를 바르게 입력한다.

만일 DNS나 NIS, NIS+를 사용하는 경우에는 N를 선택한다. DNS를 사용한다면 DHCP에서 사용할 호스트 이름과 그에 대한 IP의 정보를 DNS 데이터베이스에 넣어 주어야 한다
(DNS 참조). NIS, NIS+를 사용하는 경우에는 DHCP에서 사용하는 호스트 이름을 NIS/NIS+ 호스트 map에 추가한다.
다음은 DHCP로 할당할 IP를 지정해주는 부분이다. 시작 IP와 개수를 적어 준다.

위의 예는 203.237.183.10에서부터 50개의 IP를 DCHP를 통해 할당하겠다는 뜻이다.
이후 ping을 통해 이미 고정적으로 할당된 IP에 대해 확인하지 않겠느냐 질문이 나오고 N를 통해 확인하면 설정된 엔트리의 수를 볼 수 있다.

원격 네트워크에서 DHCP 설정
DHCP는 서버가 속한 네트워크의 호스트들 뿐만 아니라 라우터를 통해 연결된 다른 네트워크의 호스트에도 동적으로 IP를 할당할 수 있다. 연결 라우터를 명시하는 등의 몇 가지 과정만 제외하고는 지역 네트워크에서의 설정과 다름이 없으므로 설명을 생략하기로 한다.

설정 끝내기
서버 설정과정의 마지막 질문은 다음과 같다.

비소로 DHCP 서버가 작동하게 되며, 혹시 N를 선택한 경우라도 추후
# /etc/init.d/dhcp start
명령을 통해 DHCP 서버를 구동할 수 있다.

부트시에 자동으로 DHCP 시작하기
DHCP를 부트 시에 자동으로 실행하기 위해서는 /etc/init.d/dhcp에 대한 링크를 적당한 시스템 부트 디렉토리에 만들어 주어야 한다. 시스템의 수행 레벨 3에서 DHCP가 작동되기를 원한다면 /etc/rc3.d 디렉토리에 다음과 같이 링크를 만들어 주면 된다.

Shutdown 시에 자동적으로 DHCP 서비스를 중지하기위해서는 다음과 같이 한다.

DHCP 클라이언트 configuration
Solaris에서 DHCP 클라이언트를 설정하는 것은 두개의 간단한 과정을 거친다. 먼저 network interface를 설정하고, 다음으로 시스템 부트 시 해당 설정이 작동하도록 만든다.

interface 설정
interface를 설정하는 데에는 ifconfig를 사용한다.
# ifconfig -a
는 사용가능 한 interface를 출력하여 보여준다. 명령의 수행결과는 다음과 같은데 어떠한 기계를 사용하고 있는가에 따라 조금씩 다르다. (네트웍 인터페이스가 le0인 예가 많다)

출력의 각 라인이 나타내는 바에 대해서는 네트워크 인터페이스 확인 부분을 참고하기 바란다.
위의 출력은 elxl0에 이미 IP 주소가 할당되어 있다. 이를 해제하려면

# ifconfig elxl0 unplumb
을 사용한다. 이제 인터페이스를 설정하기 위해

# ifconfig elxl0 plumb
를 사용하고

# ifconfig elxl0 dhcp
를 가지고 해당 호스트를 DHCP 클라이언트로 설정한다.

부팅 시에 자동으로 DHCP 클라이언트로 설정
이를 위해서는
/etc/hostname.interface
/etc/dhcp.interface
와 같은 파일이 있어야 한다. 다음과 같이

# touch /etc/hostname.elxl0 /etc/dhcp.elxl0
파일을 만들어 주면 재부팅 시에 자동으로 DHCP 클라이언트로 설정된다.

Chapter 솔라리스 8 시스템 보안
솔라리스8 시스템 보안 개요
시스템 보안이 필요한 이유
과거에는 사무실에 전기가 나가도 업무를 못하는 경우는 없었다. 타자기가 있었으니...
필자가 처음 직장생활을 시작할 당시 (1985년)에는 적어도 그러하였다. 요즈음 정전이 되면, 모두들 당연한 듯 일손을 놓게된다. 업무전산화가 그 이유임은 누구나 잘 알 것이다.
회사의 모든 기밀 및 정책사항은 철제 캐비넷에서 하드디스크로 옮겨졌다. 그안에는 회사의 미래를 좌우할 수 있는 각종자료가 빼곡히 채워져있다.

시스템의 불법침입은 옛날로 치자면 회사금고가 열리는 형태이다. 더욱 심각한 일은, 회사의 금고가 털린줄도 모른채 무사태평할 수 있다는 것이다.

인터넷의 등장과 함께, 이제 금고안의 서류는 순식간에 태평양을 건너 갈 수도 있다. 이것이 남의 일이 아님은 세계유수 기업들이 심심치않게, 또한 어이없이 당한 뉴스를 보면서 느낄 수 있는 일이다.

물론, 10명의 파수꾼이 한명의 도둑을 막지못한다는 말도 있다. 날고 뛰는 전문해커를 어떻게 감당하겠냐며 그저 하나님께 시스템 보안을 의뢰할 수도 있다. (제발 우리 시스템에는 침입자가 없게 해달라고 기도하며...)

100% 완벽한 보안솔루션을 구축하기란 참으로 어려운 일일 것이다. (어쩌면 불가능할지도 모른다) 그러나 100%에 가까운 보안을 구축하고자 노력하면 할수록 그 틈새를 비집고 침입할 수 있는 확률은 줄어들기 마련이다.

서론이 너무 길었다. Solaris 운영체제는 시스템군에 속해있는 파일, 디렉토리, 주변기기를 보호할 수 있는 우수한 보안체제를 갖추고 있다. 솔라리스 8에서는 이전 버전보다 향상된 보안기능을 제공한다. 본 장에서는 일반적인 유닉스 시스템 보안보다는 솔라리스 8이 갖고 있는 보안 솔루션을 중점적으로 다루도록 하겠다.

솔라리스 8 시스템 보안의 새로운 특징
파일 및 디렉토리의 소유권
- 파일 및 디렉토리에 대한 기본 소유권이 bin에서 root로 변경됨.
- 기본 권한이 775이던 파일 및 디렉토리는 755로 변경됨.
- 기본권한이 664이던 파일 및 디렉토리는 644로 변경됨.
- 기본 시스템 umask는 022로 설정됨.

Role Based Access Control
솔라리스 8 버전부터 새로이 등장한 기능이다.
전통적인 유닉스 보안시스템에서는 전지전능한 수퍼유저와 힘이라고는 전혀 없는 일반사용자만이 존재하였다. 때문에 일반사용자들은 변변한 프로그램 하나 제대로 시스템에 설치할 수 없었다.
RBAC는 일반사용자도 수퍼유저의 힘을 나누어 가질 수 있는 능력을 제공해준다. 물론 무턱대고 권한을 주는 것은 아니다. 필요에 따라 일반사용자에게 수퍼유저 권한을 적절히 배분해주는 아주 유용한 방법이다. 그러나 시스템에 문제를 야기시킬 수 있다고 판단되는 user에게는 절대로 이러한 능력을 주어서는 안된다.
RBAC에 대해서는 뒷장에서 상세히 설명할 예정이다.

Sun Enterprise Authentication Mechanism (SEAM)
SEAM은 네트웍상에서 KDC라는 제 3의 인증서버를 통하여 사용자 인증기능을 제공해주는 클라이언트/서버 구조의 보안기능이다. SEAM은 네트웍상에서 사용자의 인증은 물론 데이터의 무결성 및 기밀성도 보장을 해준다. 이를 이용하여 사용자는 다른 서버에 접속하여 명령어 수행 및 데이터 교환, 파일 전송등을 완벽한 보안속에 행할 수 있다. 이와 함께 SEAM은 시스템 관리자가 서비스 및 서버 사용을 제한할 수 있는 기능도 제공한다.
SEAM이 가진 또하나의 장점은 사용자 인증이 한 세션당 한번만 이루어지면 된다는 것이다. 일단 사용자 인증이 이루어지면 세션이 종료되지 않는한 또다시 패스워드를 입력하지 않아도 된다. (이러한 인증방식은 이제는 대다수의 웹사이트에서 널리 사용되고 있음을 볼 것이다)
SEAM은 MIT에서 개발한 커버로스 (Kerberos) V5 네트웍 인증 프로토콜을 기반으로 한다.
client/server part가 모두 포함되었던 이전과는 달리 솔라리스 8 버전부터는 client쪽 제품만이 포함되어 있다.

솔라리스 8에서의 보안을 위한 유의사항
솔라리스 8 시스템에서 운영 프로그램을 설치시 유의사항.
- 모든 파일 및 디렉토리의 기본 소유자는 root로 한다.
- 디렉토리 및 실행파일의 기본 권한은 555 혹은 755로 설정한다.
- 일반 파일의 기본권한은 644 혹은 444로 설정한다.
- setuid나 setgid를 가진 파일은 파일의 소유자라 할지라도 변경할 수 없도록 쓰기금지를 해놓는다.
(소유자가 root일 경우는 물론 예외이다.)

보안을 위한 기본 사항
운영체제에게만 의존할 수 없는 것이 보안의 기본원칙이다. 다음은 사소한 사항들이기에 관리자가 방심하기 쉬운 사항들이다.

물리적 보안 유지
만일 시스템을 로긴한 상태에서 자리를 비웠다면 잠시라도 그곳에 들른 누구에게나 운영체제 및 네트웍에 접근할 수 있는 통로를 열어준 셈이 된다. 불법 접근 차단을 위한 물리적 보안유지는 시스템보안의 첫 번째 과제이다. (솔라리스 8의 화면잠금장치에 너무 의존하지 말 것. Screen lock이 작동되기 전까지의 시간이 바로 경계해야할 부분이다)

Login 및 Access Control
시스템내 모든 계정은 암호를 가지고 있어야 한다. 암호 없이 사용자 id만으로 접속할 수 있는 계정, ID와 암호가 똑같은 계정은 만인을 위해 열어놓은 시스템 통로나 다름없다. 대부분의 경우, ID는 공개된 사항임을 명심하자. (DB에서도 마찬가지이다. 오라클 DB를 인스톨해 놓은 후 change_on_install 암호를 두 달이 넘도록 변경하지 않은 사례도 본적이 있다. )

파일 및 디렉토리내 접근 제한
부적절한 file 및 디렉토리 사용권한 설정은 시스템 전체에 악영향을 미칠 수 있다. 파일 보안에 대하여는 뒷장에서 상세히 설명하겠다.

네트웍 보안 유지
네트웍을 통한 시스템 침입은 때로는 너무도 쉽게 이루어진다. client측의 허술한 암호관리가 원인이 되어 네트웍을 통해 서버에 침입한 사례는 무수히 발견된다. 회사내에서 intranet이 가동중이라면 firewall은 선택이 아니라 필수다. telnet을 막아놓는 것이 보안의 기본사항이 된 것도 요즘의 현실임을 명심하자.

시스템 사용자 모니터링
시스템 관리자라면 다음사항은 주의깊게 모니터링하는 습관을 길러야 한다.
- 현재 실행중인 프로세서중 이상하게 느껴지는 것은 없는가 ?
- 불필요하게 (?) 시스템에 들어온, 혹은 로그인을 시도한 사용자는 ?
- 시스템에 들어와서 머물다간 사용자의 기록

적절한 경로 설정
한가지 살벌한 예를 들어보자. 시스템 관리자의 profile의 실행경로명에 일반user가 사용 가능한 디렉토리가 뒷부분이 아닌 앞부분에 포함되어 있을 경우, 예를 들자면 다음과 같이 경로설정이 되어 있다면 어떤일이 발생할 수 있을까 ?

PATH=/export/home/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/ccs/bin:

만일 어떤이가 악성 바이러스 프로그램을 su라고 이름을 바꾸어 /export/home/bin 디렉토리에 슬며시 넣어두었다. 물론 바이러스 프로그램은 실행후 스스로 자폭하는 형태이고.

시스템 관리자가 로긴후 평상시대로 su명령을 실행시킨다면 /usr/bin의 su프로그램 대신 바이러스 프로그램이 우선적으로 실행되어 시스템을 일순간 마비시켜버릴 것이다.

여기에 언급되지 않은 일반화된 보안설정 역시 결코 소홀히 할 수 없는 사항임을 유념해야 한다. 경찰청에 설치된 사이버 테러 대응쎈터나 한국정보통신망침해 사고대응팀도 여러분의 시스템을 보호해주는 훌륭한 자문역할을 할 수 있다.

솔라리스 파일 보안
특별권한 설정시 주의사항
파일에 대한 보안이라면 우선적으로 생각나는 것이 무엇일까 ? 행여 내 파일을 누군가 지우거나 변경시키지는 않을까 ? 아니면 비밀스러운 파일을 누군가가 읽어보지는 않을까 하는 것이 대부분이리라. 그러나 파일 하나를 부주의하게 관리함으로서 시스템을 통째로 날릴 수 있다면 과장된 표현일까 ?

솔라리스에서는 실행파일이나 공용 디렉토리에 setuid, setgid, sticky bit 등 세가지 형태의 특별권한을 설정해줄 수 있다. 이중 setuid, setgid와 같은 특별권한이 설정된 파일을 실행시킨 사용자는 파일이 실행되는 동안 실행파일의 소유자, 혹은 소유그룹의 일원으로 인정받는다. 이것이 잘못 사용될 경우, 시스템보안은 매우 위태로운 상황에 빠지게 된다.

한가지 예를 들어보자.
uid가 root로 설정된 프로그램을 실행시킨 일반 사용자는 프로그램이 실행되는 동안 root의 권한을 부여받는다. 사용자가 그틈을 이용하여 자신의 계정에 대한 권한을 root에 버금가도록 만들어버린다면... 시스템의 주인이 바뀌는 상황이 된다.

수퍼유저의 권한을 부여하는 setuid, setgid등의 특별권한을 가진 프로그램의 작동은 수시로 모니터링하여 부적절한 사용을 막도록 하자. (이러한 프로그램의 리스트를 출력하는 방법은 다음단원에 자세히 설명해 놓았다.)

setuid 권한
setuid란
실행파일에만 설정되는 setuid (set-user identification) 권한은 파일의 소유자 (일반적으로 root)가 가지는 것이 원칙이다. 그러나 만일 일반 사용자가 이 파일을 실행시킬 경우에는 파일의 소유자와 동등한 파일 및 디렉토리 사용권한을 획득하게 된다.

setuid 권한이 설정된 passwd명령어를 일반사용자가 실행시켰을 경우, 그 사용자는 프로그램이 수행되는 동안 root의 권한을 획득하여 패스워드를 바꿀 수도 있다. 이 얼마나 엄청난 일인가. 일단 그 사용자가 프로그램 실행중 자신에게 필요한 사항을 모두 마무리지어 놓는다면, 프로그램이 종료된 후에도 여전히 root에 버금가는 권한을 휘두를 수 있으니...

setuid 권한이 설정된 파일의 예

setuid 권한이 설정된 파일을 찾아내는 방법
1) superuser권한을 갖는다.
2) find명령을 이용하여 setuid 권한을 가진 파일을 다음 방법으로 검색한다.

option 설명

기타 특수권한 설정
setgid 권한
set-group identification (setgid) 권한 역시 setuid와 비슷하다. 다른점이 있다면 파일의 소유자가 아닌 소유그룹의 권한이 설정되며 이를 실행시킨 사용자는 해당그룹의 권한을 갖는다는 것이다.

setgid가 설정된 파일의 예
-r-x--s--x 3 root mail 63628 Oct 18 12:27 /usr/bin/mail

setgid 권한이 디렉토리에 적용될 경우, 해당 디렉토리에 생성된 파일들은 프로세서를 수행시킨 사용자의 그룹에 속하는 것이 아니라 디렉토리가 속한 사용자그룹에 속한다. 이 디렉토리안에서 쓰기 및 실행권한을 가진 사용자는 모두 그곳에서 파일을 생성할 수 있다. 그러나 그 파일들은 파일을 생성한 사용자 그룹이 아니라 그 디렉토리를 소유한 그룹에 속하는 것이다.

Sticky bit
sticky bit은 디렉토리안의 파일들을 보호하는 권한이다. 만일 어떤 디렉토리에 이 권한이 적용되었다면 해당파일이나 디렉토리의 소유자, 혹은 root만이 디렉토리안의 파일들은 지울 수 있다. 이 기능은 웹서버의 /public_html과 같은 공용디렉토리나 임시디렉토리 (/tmp) 내의 다른 사용자들의 파일을 보호하기 위하여 존재하는 것이다.
공용디렉토리 설정시에는 sticky bit을 설정해 주어야 함을 유념토록 하자.

umask
처음, 파일이나 디렉토리를 만들면 파일이나 디렉토리에 대한 기본적인 권한이 자동 설정된다. 이 기본 권한은 시스템 파일의 umask에 의하여 결정된다. umask는 .profile, .cshrc, .bashrc, .login과 같은 사용자 프로파일에서 설정한다.

umask는 chmod와는 정반대의 개념으로 사용된다. 예를 들어 chmod 022라는 명령어가 해당그룹 및 다른 사용자들에게 쓰기권한을 부여하는 반면, umaks 022는 해당그룹 및 다른 사용자들에게 쓰기권한을 박탈하는 것이다.
umask값의 증가에 따른 보안등급의 변화

Access Control List (ACL)
ACL의 특징
일반적인 유닉스 파일 권한 설정방법은 사용자를 소유자, 그룹, 기타 사용자 등 세 가지로 분류하여 권한을 부여하는 방식이었다. ACL은 이보다 훨씬 향상된 파일 권한 설정이 가능하도록 해준다. 즉, 소유자, 그룹, 기타사용자등 세가지 범주 이외에 특정 사용자 및 특정 그룹을 추가할 수 있고 이렇게 분류된 5가지 범주에 각각 기본적인 소유권을 설정해줄 수 있다.

예를 들어, 그룹내의 모든 사용자가 파일을 읽을 수 있게 하려면 해당 파일에 대한 그룹의 읽기 권한을 부여하면 될 것이다. 그런데 그 그룹내에서 오직 한사람만이 해당파일을 읽을 수 있는 권한을 주고자 한다면 어떻게 해야 할까 ? 일반 유닉스 시스템에서는 쉽지 않은 일이다. 그러나 ACL에서는 아주 간단히 해결될 수 있는 사항이다.

ACL 엔트리
ACL 엔트리는 파일의 ACL을 규정해주는 방법이다. 이것은 setfacl 명령어로 설정된다. ACL 엔트리는 다음과 같은 필드로 구성되어 있으며 각 필드는 콜론(:)으로 구분된다.

entry_type:[uid | gid]:perms

gildong이라는 사용자에게 읽기/쓰기 권한을 부여하는 ACL 엔트리는 다음과 같이 간단하게 표현된다.

user:gildong:rw-

파일에 대한 ACL 엔트리
아래 표는 사용가능한 ACL 엔트리를 나타낸 것이다. 맨 위의 3가지 ACL 엔트리는 전형적인 유닉스 파일 보호기능과 동일한 것을 제공한다.

ACL 엔트리 descrition
u: : perms 파일 소유자 권한
g: : perms 파일 소유그룹 권한
o: : perms 파일 소유자나 그룹 이외의 기타 사용자 권한
m: : perms ACL 마스크. 마스크 엔트리는 기타사용자 및 그룹에게 허용된 최대한의 권한을 나타낸다. 마스크는 기타사용자 및 그룹의 권한을 신속하게 변경할 수 있다. 예를 들어, 다음과 같은 마스크 엔트리는 쓰기 및 실행권한을 가졌던 기타사용자와 그룹이 읽기권한 이외에는 가질 수 없도록 만드는것이다.
mask:r--
u:uid:perms 특정한 사용자에 대한 파일 소유권 (uid는 사용자명이나 uid 번호등 어떤 것을 사용해도 된다)
g:gid:perms 특정한 그룹에 대한 파일 소유권 (gid는 그룹명이나 gid 번호등 어떤 것을 사용해도 된다)

디렉토리에 대한 ACL 엔트리

아래 표는 디렉토리에 사용가능한 ACL 엔트리를 나타낸 것이다. 맨처음, 특정 사용자나 그룹에 디렉토리에 대한 ACL 엔트리를 설정할때에는 파일 소유자, 그룹, 기타사용자, ACL 마스크 값을 반드시 설정해주어야 한다.

ACL 엔트리 descrition
d:u: : perms 파일 소유자 권한
d:g: : perms 파일 소유그룹 권한
d:o: : perms 파일 소유자나 그룹 이외의 기타 사용자 권한
d:m: : perms ACL 마스크.
d:u:uid:perms 특정한 사용자에 대한 파일 소유권 (uid는 사용자명이나 uid 번호등 어떤 것을 사용해도 된다)
d:g:gid:perms 특정한 그룹에 대한 파일 소유권 소유권 (gid는 그룹명이나 gid 번호등 어떤 것을 사용해도 된다)

Access Control List (ACL)의 설정방법
파일에 ACL을 설정하는 방법.
setfacl 명령어를 이용하여 파일에 ACL을 다음과 같이 설정한다.

$ setfacl -s user: : 사용권한, group: :사용권한,other:사용권한,mask: :사용권한,acl_entry_list filename ...

option 설명
option descrition
-s 파일에 ACL을 설정하는 옵션. 만일 파일에 이미 ACL이 설정되어 있다면 지금 입력하는 새로운 설정값으로 변경된다. 이 옵션을 줄때에는 파일 소유자, 파일그룹, 기타사용자를 함께 입력해야 한다.
user: :사용권한 파일 소유자 권한 설정
group: :사용권한
파일 그룹 권한 설정
other: :사용권한 기타사용자 권한 설정
mask: :사용권한 ACL 마스크 권한 설정. 여기서 마스크값은 기타사용자 및 그룹에 주어지는 최대한의 권한을 의미한다
acl_entry_list 파일이나 디렉토리의 특정 사용자나 특정그룹에 대하여 설정할 하나 이상의 ACL 엔트리 명시. 파일 및 디렉토리에 대한 ACL 엔트리 설정표를 참고하기 바람
filename ACL을 설정할 한 개이상의 파일이나 디렉토리명

ACL값이 제대로 설정되었는가를 확인하는 방법

$ getfacl 확인할 파일이름

ACL 설정 실제

사례 1. mylove.txt라는 파일의 소유자에게는 읽기/쓰기 권한을, 그룹에게는 읽기권한만을, 기타사용자에게는 아무런 권한을 주지않도록 설정한다. 그러나 이렇게 설정하는 것만으로는 ACL의 진가를 발휘할 기회가 없다.

yongsu라는 사용자는 소유자가 아니라 할지라도 파일에 대하여 읽기/쓰기 권한을 가질 수 있고 기타사용자 및 그룹은 실행권한이 전혀 없도록 ACL 마스크 권한을 읽기/쓰기로 설정해보자.

$ setfacl -s user: :rw-,group::r--,other:---,mask:rw,user:yongsu:rw- mylove.txt
$ ls -l
total 476
-rw-r-----+ 1 sknho sysadmin 4128 Dec 20 09:24 mylove.txt
-rw-r--r--+ 1 sknho sysadmin 3157 Dec 20 09:24 true.txt
-rw-r--r--+ 1 sknho sysadmin 7462 Dec 20 09:24 take_me_home.doc
$ getfacl mylove.txt
# file: mylove.txt
# owner: sknho
# group: sysadmin
user: :rw-
user:yongsu:rw- #effective:rw-
group: :r-- #effective:r--
mask:rw-
other:---

사례 2. true.txt라는 파일의 소유자에게는 읽기/쓰기/실행 권한을, 그룹에게는 읽기권한만을, 기타사용자에게는 아무런 권한을 주지않도록 설정한다. ACL 마스크 권한은 읽기전용으로 설정한다. 또한 miran이라는 사용자는 파일에 대하여 읽기/쓰기 권한을 가졌다 할지라도 ACL 마스크 설정으로 인하여 읽기권한만을 갖도록 설정해보자.

$ setfacl -s u: :7,g: :4,o:0,m:4,u:miran:7 true.txt
$ getfacl true.txt
# file: true.txt
# owner: sknho
# group: sysadmin
user: :rwx
user:miran:rwx #effective:r--
group: :r-- #effective:r--
mask:r--
other:---

파일에 설정된ACL값을 다른파일에 복사해주는 방법

한번 설정한 ACL이 아주 마음에 들어서 이것을 다른 파일에도 그대로 적용시키고자 할 때, 파일마다 일일이 setfacl명령어로 복잡한 옵션을 설정해야 할까 ? 그럴 필요가 없다. 아래와 같은 방법으로 간단하게 다른파일에도 적용시킬 수 있다.

$getfacl filename1 | setfacl -f filename2

filename1 : 이미 ACL이 설정되어 있는 파일명
filename2 : ACL을 filename1처럼 설정코자 하는 파일명

ACL의 수정,삭제
파일에 설정된ACL값을 변경하는 방법
한번 설정한 ACL을 변경하고자 할때에도 setfacl명령어를 사용하면 된다.
아래 예는 파일 mylove.txt에 대한 사용자 'minsu'의 access 권한을 읽기/쓰기로 변경해주는 예이다.

$ setfacl -m user:minsu:6 mylove.txt

위와 같이 파일에 대한 ACL을 변경한 이후, 변경이 제대로 되었나를 확인할 때에는 getfacl 명령어를 사용하면 된다. 아래 예는 위에서 변경한 mylove.txt 파일에 대한 확인작업을 한 것이다.

$ getfacl mylove.txt
# file: mylove.txt
# owner: younghee
# group: staff
user: :rw-
user: :minsu:rw- #effective:r--
group: :r- #effective:r--
mask:r--
other:r-

파일에 설정된ACL값을 삭제하는 방법

설정한 ACL을 삭제하고자 할때에는 setfacl명령어에 -d 옵션을 사용한다.
아래 예는 파일 mylove.txt에 대한 사용자 'minsu'의 권한을 삭제하는 예이다.

$ setfacl -d user:minsu mylove.txt

시스템 보안
시스템 보안은 시스템의 불법 침입을 원천봉쇄하는 것이 주목적이다.
우선은 쉬운것부터 점검하자. 행여 콘솔이나 원격 터미널 모드로 로그인을 한후 자리를 비우지는 않는지. 서버가 설치된 곳이 외부로부터 충분히 보호받고 있는지. 이러한 물리적 요인으로부터 안전하다고 판단된다면 이제부터는 다음 사항들을 하나씩 점검해보자.

시스템 보안을 위한 점검사항
암호없는 계정을 가진 사용자 검색
적어도 솔라리스 8에서는 암호없이 시스템을 사용하는 사용자에 대한 걱정은 하지 않아도 좋다. 암호없는 계정을 만들 수는 있어도 그것을 사용할 수 있는 일은 전혀없으니. (텔넷상에서는 물론, 콘솔에서도 암호없이는 로그인을 할 수 없다. 즉, 새로운 암호를 입력해야만 로그인이 가능하다)

그러나 만일, 시스템관리자가 실수로 새 계정을 만든후에, 암호를 집어넣지 않았다면 누구든 그 계정으로 일단 접속하기만 하면 접속자 스스로 암호를 만들어 사용할 수 있다. 일반 사용자의 계정이라도 문제가 되겠지만 그것이 권한있는 관리자계정일 경우에는 중대한 문제가 야기된다.

행여 내 시스템내에 그러한 계정은 없는가 살펴보자.

# logins -p

이렇게 하면 암호없이 등록된 계정이 화면에 나타난다. 사용자에게 속히 연락하여 암호를 새로이 입력토록 조치해주자.

로그인에 실패한 접속기록 살펴보기
일단 시스템에 로그인하는 것을 실패하는 경우는 대부분 입력을 잘못해서 그럴 수 도 있다. 그러나 로그인 입력과정을 다섯번이나 실패했다면 이는 충분히 의심해볼 사유가 된다. 허가받지 않은 이가 불법으로 접속을 시도했을 가능성이 크기 때문이다.

이렇게 비정상적인 로그인 시도 기록은 파일로 보관할 수 있다. 솔라리스 8은 자동으로 이를 기록으로 남겨주지 않는다. 그러나 관리자가 다음파일을 수동으로 직접 만들어 준 이후에는 자동으로 이러한 비정상적 접속기록을 파일로 남겨준다.
/var/adm/loginlog

loginlog파일안에는 다섯번씩 로그인에 실패한 기록이 자동으로 기록된다. 이 파일을 만들때에는 root만이 읽고 쓰기가 가능하도록 권한을 부여해주어야 한다.
(왜 하필 다섯번일까. 텔넷으로 솔라리스에 로그인을 다섯번 실패하면 자동으로 접속이 끊어진다. 이는 기본설정이 그렇게 되어있기 때문이며 /etc/default/login파일에서 RETRIES부분의 주석을 제거하고 값을 변경하여 관리자가 임의로 변경하는 것이 가능하다.)

로그인에 실패한 기록은 다음과 같이 남겨진다.

위에서 보면 로그인에 실패한 사용자의 id, 터미널 명, 접속을 시도한 때 (년,월,일,시각)이 나타난다.

만일 여러분의 시스템에서 loginlog 파일의 크기가 나날이 증가한다면 그것은 여러분의 시스템이 누군가에 의해 끊임없이 침입을 시도당하고 있다는 증거이다.

loginlog 파일은 다음과 같은 방법으로 만들자.

superuser 권한을 갖는다

원격지에서의 root login 제한 및 su
superuser (root) 로서의 로그인 제한하기
수퍼유저는 시스템이라는 세계안에서는 전지전능한 신의 권위를 갖는다. 그의 손가락 하나로 그 세계를 파괴해버리는 것은 그리 어렵지 않다. 이러한 권능이 악의를 품은 제 3자에게 넘어간다면...

제 3자가 접근할 수 없는 안전한 곳에 위치한 콘솔상에서만 root로 로그인하는 것이 가능토록 설정하는 방법은 다음과 같다.

수퍼유저 권한을 갖는다.
/etc/default/login 파일을 편집기로 open한다.
CONSOLE=/dev/colsole 이라고 씌여진 줄 맨앞에 # 표시를 지워준다.

이후로는 원격지 터미널에선 수퍼유저로서 login할 수 없다. (처음 시스템을 설치하였을때 기본적으로 이렇게 설정되므로 확인만 해보기 바람.)

누가 su 명령어를 사용했을까 ?

앞서 이야기했듯 su명령어는 시스템 관리자 이외에는 사용할 수 도 없고, 해서도 안된다. 그러려면 관리자 암호의 철저한 관리 및 주기적인 암호 교체가 최상의 방법이다.

그러나 관리자 암호가 연상되기 쉬운 것으로 설정되어 있거나, 여타의 방법으로 노출되었다면... 그래서 누군가가 원격지 터미널에서 심심풀이로 가끔씩 su 명령을 사용하고 있다면 ...

혹시 이러한 일이 내 시스템에서도 발생하고 있을지도 모를 일이다. 이것을 알아보는 방법은 다음과 같다.

수퍼유저 권한을 취득한다.
/etc/default/su 파일을 편집기로 open한다.
SULOG=/var/adm/sulog 라고 씌여진 줄 맨앞에 # 표시를 지워준다.

이후부터는 su 명령어를 사용한 모든 기록이 sulog 파일에 기록된다. 시스템 관리자 본인이나 su 권한을 허가받은 사용자 이외에 다른이가 su 명령어를 사용한 기록이 없는가를 살펴보도록 하자.

su 명령어를 사용한 사용자는 다음과 같이 적발(?) 가능하다.

수퍼유저 권한을 갖는다.
/etc/default/su 파일을 편집기로 open한다.
CONSOL=/dev/console 이라고 씌여진 줄 맨앞에 # 표시를 지워준다.

이후부터는 su 명령어를 사용한이들이 모두 화면에 출력될 것이다.

su 명령어를 타인이 실행할 수 없게 만드는 방법

su (switch user) 명령어를 시스템 관리자나 몇몇 특정인 이외에는 절대로 사용할 수 없도록 만드는 간단한 방법이 있다. 터미널은 물론이고 콘솔에서조차 사용할 수 없도록...
방법은 좀 단순 무식하다.
/usr/bin에 있는 su 파일을 rename시키는 것이다.
예를 들어 다음과 같이 파일명을 변경시킨다면
mv su pcbee

변경된 순간부터 su명령어대신 pcbee라는 명령어를 수행해야만 switch user 명령어가 수행된다. 물론 새로 rename시킨 명령어는 필요한 몇몇 사람만 알도록 해야하고...

restricted shell 설정
restricted shell
여러분이 시스템 관리자라면 사용자들의 계정 발급시 특정 shell환경을 함께 지정할 것이다.
이때 아무 생각없이 /bin/sh shell을 지정해주지는 않는지 ...
만일 그렇다면 시험삼아 다른 사용자의 계정으로 ftp login후 다른 디렉토리로 이동해보길...
아주 자유롭게 root 디렉토리까지 넘나들며 시스템의 파일을 무한정 다운받을 수 있다는 사실을 알게 될 것이다.

이것을 막기위하여 일반 사용자들에게는 제한된 쉘이란 의미의 rsh (restricted shell) 환경을 제공해 줄 수 있다. rsh는 /usr/lib/rsh shell을 지칭하며, 일반 사용자가 접근할 수 있는 작업 디렉토리의 영역과 사용할 수 있는 명령어를 제한해준다.

restricted shell의 기능은 아래와 같다.
- 사용자는 자신의 home directory에서만 화일을 생성할 수 있다.
- "cd" 명령을 사용하여 다른 directory로 갈 수 없다.
- 사용자는 root가 PATH 변수에 지정한 directory안에 있는 명령만 사용할 수 있다. 물론 지정된 PATH는 사용자가 변경 할 수 없다.
- 사용자는 자신의 home directory와 하위 directory에 있는 화일만 access할 수 있다.
- 사용자는 ">" 혹은 ">>" 를 사용하여 output을 다른 화일로 redirection할 수 없다.

restricted shell 설정하기
- /etc/password 파일을 한번 살펴보자. 여기서 일반사용자중 제한된 쉘을 적용할 이들의 login shell을 /usr/lib/rsh로 변경한다.

- /etc/profile 또는 사용자의 home direcroty에 사용자의 .profile을 만든후 이 파일에 사용자의 PATH를 지정한다. (만일 별도로 PATH를 지정하지 않으면 /usr/bin이 사용자의 경로로 지정된다)

- 사용자의 home directory에 .profile을 만들 때 다음과 같이 permission을 정해준다.
1) owner를 root로 한다. : # chown
2) 사용자가 내용을 변경할 수 없게 한다. : # chmod 755 .profileroot:bin .profile

불필요한 서비스 중단 및 스크립트 제거
불필요한 서비스 중단 및 스크립트 제거
처음 솔라리스8을 설치할 때, 대부분의 사용자들은 CD에 수록된 모든 것을 설치하기 마련이다. 몇 번 사용하지 않거나, 한번도 사용하지 않는 프로그램이 그 가운데는 수두룩하다.

이것은 시스템 성능에도 영향을 미친다. 그러나 여기에만 그치는 것이 아니고 시스템 보안에도 문제를 발생시킬 수 있다.

Solaris 운영체제가 설치된 시스템은 아주 많은 서비스를 제공할 수 있지만 이들 대부분이 보안에는 잠재적인 위험요소이다. 예를 들어 /etc/inetd.conf 에는 35가지의 서비스가 제공되고 있다. 이중 ftp나 telnet을 제외한 나머지 서비스는 관리자조차도 거의 신경을 쓰지 않는 항목들이다.

(gopher 서비스를 생각조차 해본적이 있을까 ? 그러나 엄연히 서비스중인 항목이다) 시스템 관리자가 불필요한 서비스라고 판단되는 항목은 # 주석을 달아 중단시킬 필요가 있다.

다음으로는 /etc/rc2.d 와 /etc/rc3.d 디렉토리에 있는 스크립트 파일들이다. 이들은 시스템이 부팅될때마다 자동으로 실행된다. 그러나 이들중 상당수가 시스템 운영에는 그다지 필요하지 않다. 단지 보안에 있어서 위험요소는 될 수 있다.

이러한 스크립트 파일들의 자동실행을 중단시키려면 스크립트 파일명의 맨 앞자인 대문자 'S'를 소문자 's'로 바꿔주면 된다. 이후, 특정 스크립트 실행이 필요할 때에는 소문자를 다시 대문자로 바꾸어주면 되고... 아래 열거된 스크립트 파일들은 별로 필요치 않으면서도 시스템 보안에는 위험한 요소가 될 수 있는 것들이다.

* 아래 스크립트는 보안에는 도움이 되지 않지만 CDE 구동에 꼭 필요하다. 일반 솔라리스 사용자들에게 있어서 CDE환경은 꼭 필요할 수 있다. 그러나 CDE환경이 필요 없는 시스템도 있다. (웹서버가 대표적인 예일 것이다) 이러한 경우에는 아래 스크립트의 자동실행을 중단시키는 것이 좋다.

/etc/rc3.d 디렉토리

CDE 나 OpenWindows와 같은 GUI환경은 시스템 사용에는 매우 편리하지만 편한만큼 보안성은 떨어진다. 시스템 보안이 우선이라면, 그리고 GUI 인터페이스가 꼭 필요하지 않다면 이러한 GUI 환경은 사용하지 않는 것이 좋다. CDE 구동을 위하여 얼마나 많은 포트와 서비스가 필요한지는 CDE환경에서 다음 명령어를 실행시켜 보면 알 수 있다.

ps -aef | wc - l

만일 S99dtlogin 스크립트 및 S71rpc 스크립트의 실행을 중단시킨 후, 즉 CDE환경을 더 이상 사용하지 않은 이후에 위의 명령어를 다시 한번 실행시켜보면 , 얼마나 많은 서비스가 시스템에서 중단되었는가를 비교해볼 수 있다. 서비스가 적게 실행될수록, 시스템 성능은 물론이고 보안성도 향상된다.

CORE Installation

운영체제를 설치할 때 CORE Installation 이라는 항목이 있다. 시스템 운영을 위한 최소한의 요소만 설치하는 것이다. 이것은 시스템 보안을 위하여 널리 권장되는 항목이다.
만일 Core installation을 선택하여 이미 시스템을 설치하였다면 이제껏 언급된 내용은 걱정하지 않아도 된다. Core installation은 GUI환경을 제공해주지 않기 때문이다.

시스템 보안을 위한 Core installation에 관한 자세한 사항은 Sun Micro System의 공식 bule print 문서를 다운받아서 읽어보길 권한다. 아래 주소에 이에 관한 문서가 있다.
http://www.sun.com/blueprints/1299/minimization.pdf

특정 서비스 중단
시스템에서 현재 제공되는 ftp service나 telnet서비스와 같은 특정 서버 프로그램을 중단하는 방법은 /etc/inetd.conf 파일안에 있는 해당 서비스 항목 앞에 #표시를 붙여주면 된다.

예) ftp와 telnet service를 중단하려면
/etc/inetd.conf 파일을 연다.
다음과 같이 ftp와 telnet 항목 앞에 #표시를 붙여준다.

이후 다음 명령을 수행시킨다.

(inetd-pid는 inetd daemon의 process id로서 ps 명령어로 확인할 수 있다)

ftp 사용자의 제한

ftp 사용자를 제한하는 경우는 다음 두가지가 있다.
첫 번째로 root나 bin 계정과 같은 시스템 계정으로 access하는 것을 방지하는 것이다.
두 번째로는 의심가는 사용자에 대하여 ftp 사용권한을 박탈하는 것이다.

이러한 계정에 대한 ftp 서비스를 중단하려면 /etc/ftpusers 파일에 해당 계정을 적어주면 된다.

아래는 /etc/ftpusers 파일의 한 예이다.

보안을 위한 경고메시지 출력

여러분의 시스템에 텔넷으로 접속할 때마다 경고문구가 나온다면, 크래킹과 같은 이상한 행동을 심리적으로 억제해주는 효과가 있다. 이러한 경고문구가 나오게 하려면 /etc/issue 라는 텍스트 형태의 파일을 작성해준다. 그러면 시스템에 로그인할 때마다 경고 메시지가 화면에 출력된다.

아래는 /etc/issue 파일의 한 예이다.

위 문구는 으시시할 수록 효과적이다.

네트웍 보안 및 Firewall
인터넷(Internet) 은 기본적으로 Open된 네트웍이다. 인터넷의 발달은 전세계 네트웍을 연동시킨 Global network 구축이라는 잇점과 함께, 자사의 정보가 전세계에 공개될 수 있다는 네트웍 보안의 취약점을 동시에 가져왔다.

보안이 전제되지 않은 네트웍, 인터넷이라면 이를 사용할 조직은 아무도 없다. 아무리 좋은 컨텐츠를 담은 서버라 할지라도 인터넷과 연결될 때 '네트웍 보안'은 가장 먼저 고려해야할 사항 중 하나이다. (홍보용 웹서버도 마찬가지이다. 웹사이트 해킹을 생각해보라)

그러나 보안적 측면이 강화될수록, 자유로운 네트웍 이용은 제한을 받게 된다. 즉, 보안문제는 인터넷을 자유롭게 이용하고 싶어하는 이용자의 희망과 항상 반대로 가게 된다. (Firewall의 운영이 대표적인 예이다) 따라서 조직에 따라 외부에 공개할 정보와 공개하면 안될 정보를 명확히 구분할 필요가 있고, 이를 토대로 하여 자신들의 적절한 보안정책을 수립하여야 한다.

본장에서는 방화벽과 같은 물리적 보안시스템 구축과 Dial-up Password, RPC와 같은 네트웍 인증시스템에 대하여 알아본다.

방화벽 (Firewall) 시스템의 설치 및 운영
네트웍 보안 시스템에 있어 가장 널리 쓰이는 방법은 방화벽(Firewall System) 설치이다. Firewall이란 내부 네트웍(인트라넷)과 외부 네트웍의 사이에서 검문소 역할을 수행한다. 내부 네트웍과 외부 네트웍의 모든 통신은 Firewall을 거쳐야 하며, Firewall은 양자간에 오가는 모든 통신을 감시하고, 허용되지 않는 접근을 막는다. 이로써 내부 네트웍은 불법적인 네트웍 침입이나 해킹으로부터 보호된다.

외부에서 네트웍에 접근하면 네트웍 전면에 있는 Firewall만이 보이고, 그 뒤에 놓인 인트라넷은 볼 수 조차 없다. 따라서 Firewall까지가 외부인이 도달할 수 있는 한계이며, 방화벽 뒷편의 인트라넷은 안전하게 격리된다. Firewall 자체에는 중요한 정보를 보관하지 않으며, 외부로부터의 접근도 대부분 차단된다. 내부와 외부간에 이루어지는 모든 통신은 Firewall을 반드시 거쳐야만 되므로 상당 수준의 보안 시스템을 구축할 수 있다.

그러나 이러한 Firewall의 보안수준은 조직의 보안정책으로 결정된다. 똑같은 Firewall시스템이 설치되었어도 어떤 네트웍은 통신을 상당부분 제약하는가하면, 어떤 네트웍은 매우 자유로운 통신을 허용하기도 한다. 제한이 많을수록 보안강도는 높아지겠지만, 외부와의 원활한 통신에 어려움이 생기고 인터넷 사용이 부자유스러울 수도 있다. 반대로 제한이 거의 없는 경우에는 사용자들이 인터넷을 사용하는데 전혀 지장이 없고, 외부와의 통신도 원활하지만 보안강도는 낮아진다. 이러한 보안의 강약을 결정하는 것이 보안정책이다.

Firewall의 한계와 문제점
Firewall은 자신을 거치지 않는 연결에 대해서는 아무런 기능도 수행할 수 없다. 따라서 시스템에 접속할 수 있는 입구가 많은 네트웍이라면 그 입구마다 Firewall을 설치해야 할 것이다. 특히 취약한 부분은 외부로부터의 Dial-up 모뎀을 이용한 연결이다.

기본적으로 네트웍에는 언제나 헛점이 생길 수 있다. 따라서 극비사항의 정보를 담은 시스템은 네트웍 보안 시스템조차 필요치 않다. 가장 좋은 보안정책은 이러한 시스템은 네트웍 자체에 연결하지 않는 것이다. (이것은 외국 기업의 실제 보안 운영사례이다)

단순히 Firewall을 이용한 접근제어만으로는 진정한 보안이라 하기 어렵다. 정상적인 화일 교환을 이용한 바이러스의 침투, E-Mail 가로채기나 변조 등 역시 Firewall로는 제어할 수 없는 부분이다. Firewall 시스템 구축에 의한 접근제어는 네트웍 보안 시스템의 일부일 뿐이다.

Dial-up Password
Dial-up 모뎀을 통한 네트웍 접속시 보안을 위하여 솔라리스 8은 부가적인 암호체계를 가지고 있다. Dial-up password는 시스템에 접속하기 전, 인증을 받기 위한 또하나의 암호이다. 이 Dial-up password는 오직 superuser만이 변경할 수 있다.

Dial-up password를 처음에 만들때에는 /etc/dialups와 /etc/d_passwd라는 두 개의 파일을 함께 만들거나 수정해주어야 한다. /etc/dialups 파일에는 접속시 Dial-up password를 필요로 하는 포트 목록이 포함되어 있다. /etc/d_passwd 파일에는 암호화된 패스워드인 Dial-up password를 필요로 하는 쉘 프로그램의 목록이 포함된다.

/etc/dialups 파일에는 다음과 같은 터미널 디바이스의 목록이 들어있다.
/dev/term/a
/dev/term/b
/dev/term/c

/etc/d_passwd파일은 두 개의 필드를 가지는데 첫째필드는 암호를 필요로 하는 로그인 쉘이고 그다음 필드는 암호화된 패스워드이다.

/usr/lib/uucp/uuciso:암호화된 패스워드:
/usr/bin/csh:암호화된 패스워드:
/usr/bin/ksh:암호화된 패스워드:
/usr/bin/sh:암호화된 패스워드:

이들 파일은 어떤 역할을 할까 ?
사용자가 /etc/dialups 파일 목록에 있는 포트중 하나에서 로그인을 시도하면 로그인 프로그램은 /etc/passwd안에 저장된 사용자의 로그인 엔트리를 우선 점검한다. 이 엔트리들은 사용자가 다이얼업 패스워드로 로그인할 권한이 있는가를 결정한다.

sunja라는 사용자가 dial-up password로 인증을 받아 시스템에 접속하는 순서를 예를 들어보겠다.
사용자 sunja가 /dev/term/b 포트에 로그인을 시도한다.
/dev/term/b login 포트가 /etc/dialups에 있음을 확인한다.
/etc/passwd 파일에서 login shell field를 체크한후 이것이 /etc/d_passwd 에 있는 쉘의 해당 암호와 일치하는가를 점검한다.
/usr/bin/ksh 엔트리의 암호화된 패스워드와 일치함을 확인.
/etc/d_passwd파일에 있는 password를 묻는 prompt를 보냄

/etc/d_passwd 파일의 구성 및 역할
대부분의 사용자들이 login을 할 때에는 shell을 구동한다.

dial-up password를 사용하려면 모든 쉘 (uucico, sh, ksh, csh등) 프로그램은 /etc/d_passwd파일에 엔트리를 만들어 놓으면 된다. /etc/passwd에 만들어 놓은 어떤 사용자의 shell이 /etc/d_passwd에서는 발견되지 않거나, 혹은 /etc/passwd의 로그인쉘 필드가 null값이라면 /usr/bin/sh에 있는 암호를 대신 사용하게 된다.

즉, 이것은 다음과 같이 요약될 수 있다.

- 만일 /etc/passwd에 정의된 사용자의 로그인 쉘이 /etc/d_passwd와 일치한다면 사용자는 dial-up password를 입력하여야 한다.

- 만일 /etc/passwd에 정의된 사용자의 로그인 쉘이 /etc/d_passwd에는 없다면 사용자는 dial-up password대신 default password를 입력하여야 한다. 여기서 default password란 /usr/bin/sh에 있는 entry에 정의된 암호이다.

- 만일 /etc/passwd에 정의된 사용자의 login shell field가 공란(null)이면 사용자는 위 경우와 마찬가지로 dial-up password대신 default password를 입력하여야 한다.

Dial-up Password 생성하는 방법

superuser권한 취득
/etc/dialups 파일을 생성. 이 파일안에는 터미널 디바이스 리스트와 dial-up password 보호를 필요로 하는 모든 포트가 적혀있어야 한다. /etc/dialups 파일은 다음과 같이 만들어준다.
/dev/term/a
/dev/term/b
/dev/term/c

etc/d_passwd파일을 생성. 이 파일안에는 dial-up password를 필요로 하는 모든 로그인 쉘 프로그램과 암호화된 dial-up password를 기입해야 한다.
/etc/d_passwd 파일의 예.
/usr/lib/uucp/uuciso:암호화된 패스워드:
/usr/bin/csh:암호화된 패스워드:
/usr/bin/ksh:암호화된 패스워드:
/usr/bin/sh:암호화된 패스워드:

상기 두 개 파일의 소유권을 root로 한다.
# chown root /etc/dialups /etc/d_passwd

. 상기 두 개 파일의 그룹 소유권을 root로 한다.
# chgrp root /etc/dialups /etc/d_passwd

상기 두 개의 파일의 읽기/쓰기 권한을 root만이 갖게 한다.
# chmod 600 /etc/dialups /etc/d_passwd

부호화된 패스워드를 생성한다.
이를 위하여 우선 junghee라는 임시 사용자를 만들어보자.
# useradd junghee
임시 사용자의 암호를 만든다.
# passwd junghee
New password : xxxxxx <- 새로 입력한 암호
부호화된 암호를 캡춰한다.
# grep junghee /etc/shadow > junghee.temp
junghee.temp라는 임시사용자의 암호파일을 편집한다.
이때 부호화된 암호필드 (두번째 필드) 부분을 제외한 나머지 필드는 모두 삭제한다. 예를 들어 아래의 경우에 암호화된 패스워드 필드 부분은 OZry7GgHNJ가 된다.
junghee:OZry7GgHNJ:11326: : : : :
임시 사용자를 삭제한다.
# userdel junghee

위에서 생성한 junghee.temp 파일에서 암호화된 패스워드를 복사하여 /etc/d_passwd파일안으로 붙여넣는다.

NFS 시스템 보안을 위한 Secure RPC
네트웍 파일 서버는 네트웍을 통해 공유중인 파일에 대한 사용자의 접근을 제어할 수 있다. 어떠한 client PC가 이 파일들을 사용할 수 있는가, 이러한 client들에게 어떠한 형태의 사용권한을 주는가에 관한 적절한 보안레벨을 부여하는 것이다. 일반적으로 파일서버는 읽기/쓰기 권한이나 읽기전용 권한을 모든 client 혹은 특정 client에게 줄 수 있다. 이러한 사용권한은 공유할 자원을 만들때 share 명령어을 사용하여 지정하면 된다.

네트웍상의 client PC들에게 사용가능한 file system의 리스트는 파일서버의 etc/dfs/dfstab파일에서 정의한다.

NFS는 네트웍을 통하여 파일을 공유할 수 있는 편리함을 제공해주는 반면 보안상 아주 좋지 못한 헛점을 드러낼 수도 있다. 이것을 보완하기 위하여 NFS를 사용하기전 인증절차를 거치도록 하는 것이다. 일반적으로 대부분의 NFS는 UNIX 인증 시스템을 사용한다. 그러나 디피-헬만 인증, 혹은 커버로스 인증등을 NFS에 적용할 경우, 보다 강력한 보안대책이 될 수 있다.

유닉스 인증 시스템을 사용할 때 NFS 서버는 사용자를 인증해주는 것이 아니라 요청을 한 컴퓨터에게 파일을 사용할 수 있는 인증을 해준다. 그러므로 사용자는 su 명령어도 실행시킬 수 있고, 파일의 소유자인 것처럼 위장할 수도 있다. 만일 DH인증 시스템을 사용한다면 NFS 서버는 컴퓨터뿐만 아니라 사용자도 인증할 수 있으므로, 이러한 위장은 보다 어려워지게 된다.

네트웍 보안에 대한 최선의 방책은 각각의 응용프로그램에 대한 해결방법을 제시하는 것보다는 모든 응용프로그램을 커버할 수 있는 차원의 향상된 인증 시스템을 제시하는 것이다.

이러한 보안솔루션으로서 솔라리스 운영체제는 Secure RPC (Remote Prcedure Call) 라는 인증시스템을 제공한다. Secure RPC 는 네트웍 환경에서의 보안성을 상당수준 높혔으며 NFS 시스템과 같은 네트웍 파일 서비스를 위하여 또하나의 보안시스템을 추가해준다. Secure RPC 가 제공하는 보안기능을 사용하는 NFS 시스템을 Secure NFS 시스템이라 부른다.

Secure RPC
Secure RPC는 원격 시스템에서 시스템에 접근하고자 하는 사용자를 인증해주는 시스템으로서 네트웍 환경에서의 보안을 강화시켜준다.

RPC 인증 시스템을 이해하기 위하여는 "credential (증명서)"와 "verifier (검증)" 이라는 두가지 용어에 익숙해져야 한다. 예를 들어 보자. ID 카드처럼 credential에는 이름, 주소, 생년월일 등 그 사람임을 증명하는 사항들이 기록되어 있다. verifier는 증명서에 부착된 사진과 같다. 증명서에 부착된 사진 때문에 다른 사람이 그 증명서를 훔쳐가서 사용할 수 없음을 알 것이다. RPC에서 client 프로세스는 RPC의 요청이 있을 때마다 credential과 verifier를 서버로 전송한다. 이후 서버는 확인절차를 마친 후 client에게 verifier만을 돌려준다.

네트웍서비스에서 UNIX 인증시스템만을 사용하게 되면, credential에는 클라이언트의 호스트 이름, UID, GID, group-access list등이 포함되지만 verfier에는 아무것도 수록되어 있지 않다. 그이유는 verifier 자체가 없기때문이며 이 때문에 su등의 명령어를 사용하여 superuser가 적절한 credential을 도용할 수 도 있다.

UNIX 인증시스템의 또다른 문제점은 유닉스 인증이 네트웍상의 모든 컴퓨터를 유닉스 운영체제 컴퓨터로 생각해버린다는 것이다. 유닉스 인증시스템은 여러 운영체제가 뒤섞인 혼성 네트웍에서 다른 운영체제가 접근하였을때에는 접속을 끊어버린다.

이러한 유닉스 인증시스템의 문제점을 해결하기 위하여 Secure RPC는 디피-헬만 인증그리고 뒤에서 설명할 커버로스 인증을 함께 사용한다.

DH (Diffie-Hellman) 인증시스템
DH 인증시스템은 데이터 부호화 표준 (DES) 및 디피 헬만 public-key 암호을 사용하여 네트웍상의 사용자 및 컴퓨터를 인증해준다. 디피 헬만 public-key 암호시스템은 두 개의 키(하나는 공개, 하나는 비밀) 를 가진다. 공개키 및 비밀키는 모두 지정된 사용자 데이타베이스안에 저장되어 있다. NIS에서는 publickey map에 저장을 하고 NIS+에서는 cred table에 이를 저장한다.

DH 인증시스템의 보안체계에서 송신자는 현재시간을 암호화하여 전송해주고, 수신자는 이를 해독하여 자신의 시스템 시간과 비교한다. 현재시간을 기록한 timestamp는 DES방식으로 암호화한다. 이러한 작업은 다음사항이 반드시 전제되어야 한다.

- 송신자, 수신자 모두 서로의 시간을 동일하게 맞춰놓아야 한다.
- 송신자, 수신자 모두 동일한 암호키를 사용해야 한다.

네트웍에서 시각 동기화 프로그램, 즉 네트웍내어서 시스템간의 시각을 맞추는 프로그램이 실행된다면 클라이언트측과 서버의 시간은 자동으로 동일하게 맞춰질것이다. 이것이 없으면 timestamp는 네트웍의 시간대신 서버의 시간을 이용한다.

RPC 세션을 시작하기에 앞서, 클라이언트는 서버에게 현재시각을 물어본다. 그후 자신과 서버의 시간차를 계산한다. 이 시각차를 상계하여 계산함으로서 서버와 클라이언트간 시각을 동일하게 맞출 수 있는 것이다.

네트웍 보안에 있어서 Secure RPC 및 DH 인증시스템은 꼭 필요한 것이기에 간략히 소개하였다. 이를 위한 실제 설정 및 운영에 관하여는 뒤에서 상세히 설명할 예정이다.

Roal-Based Access Control
이제껏 우리가 사용해온 전형적인 UNIX 보안체계는 superuser는 막강한 힘을 발휘하는 반면에 일반 사용자는 자신의 사소한 문제도 해결할 수 있는 힘조차 가질 수 없는 방식이었다.

솔라리스 운영체제는 RBAC(Roal-Based Access Control)라는 방식을 통하여 기존의 superuser 방식의 보안체계, 즉 아니면 라는 방식에 어느정도 융통성을 부여하는 길을 열어주었다. 필요할 경우 특정 사용자에게 새로운 역할를 부여함으로서 수퍼유저의 권한을 적절히 나누어줄 수 있도록 해주는 것이 RBAC의 특징이다.

RBAC에서는 특정 용어가 다음과 같이 사용된다.

권한위임 (authorization) : 사용자 권한으로는 접근할 수 없었던 작업을 수행할 수 있는 새로운 능력을 부여.
실행 profile (Execution profile) : 특정한 속성 (예. 사용자 및 그룹 ID)과 연관된 권한 및 명령어를 함께 명시한 메카니즘.
역할 (Role) : 관리자 작업중 일부를 수행할 수 있도록 고안된 특별한 형태의 사용자계정 (이것 역시 하나의 계정 형태임을 기억하자)

여기서 역할, 즉 role에 대하여 생각해보자.
본 장의 제목이 왜 Role-Based라고 씌어졌을까 ?
그리고 이러한 권한부여가 왜 필요한가 ?
수퍼유저 권한의 일부를 사용자에게 주는것은 보안상 위험한 일이 아닐까 ?

맞는 말이다. RBAC를 잘못 사용하거나 남용하면 시스템은 커다란 혼란기를 겪게 된다. 모험정신(?)이 강한 사용자에게 RBAC를 적용하는것도 위험한 일일 수 있다.

그런데 아래 경우를 한번 상정해보자.

만일 관리자가 일정기간 휴가나 출장을 떠날일이 발생하였다. 그동안 믿을만한 특정 사용자에게 자신의 권한중 일부를 일정기간 부여하고 싶을 때, 즉 그동안 시스템 관리부분의 일부를 대행시키고자 할 때에는 어떤 방법을 사용할 수 있을까 ? 기존의 보안체계에서는 자신의 계정과 암호를 잠시 알려주는 모험에 가까운 방법이 유일한 대안이었다. 아니면 잠시 시스템 관련 작업은 중지하고 있던가.

그러나 RBAC를 활용할 경우, 필요한 일부 권한을 위임(authorization)하여 역할(role)로 만든후 그 역할만을 사용자에게 줄 수 있는 것이다. 이 경우, 사용자는 자연스럽게 일부의 권한을 위임받을 수 있다. 물론 위임받지 못한 역할에 대해서는 전혀 손쓸 수 없을테고.

RBAC는 특정한 권한을 사용자에게 부여할 때 다음 4가지 데이터베이스에 담긴 내용에 따라 작업을 수행한다.
user_attr (사용자 속성 DB) : 사용자, role 및 이들에게 위임할 권한, 그리고 실행 profile을 명시.

auth_attr (권한속성 DB) : 위임 권한 명칭 및 속성을 명시해놓았으며 그에 대한 도움말 파일을 지정.

prof_attr (실행 profile속성 DB) : profile을 명시하고 profile이 지정된 권한을 나열해놓았으며 그에 대한 도움말 파일을 지정.

exec_attr (profile 실행 속성 DB) : profile에 부여한, 특별한 권한을 가지고 있는 작업내용을 명시.

위의 데이터베이스가 RBAC에서 어떤 역할을 할까 ?
user_attr 데이터베이스에서 사용자에게 권한과 실행profile을 지정해줄 수 있다. 이것은 권한을 사용자에게 직접 부여해주는 방식이다.

사용자에게 권한이 아닌 역할(role)을 부여할 수 있다. 이경우, 사용자는 그 역할에 관련된 특별권한을 수행할 수 있는 권한을 갖게 된다. (RBAC를 사용하는 진정한 목적이 바로 이것이다)

실행 profile은 prof_attr DB에 정의되어 있다. 실행 profile은 auth_attr에서 지정한 위임권한 및 exec_attr에서 해당 실행 프로파일에 대하여 지정한 속성과 관련한 명령어를 함께 포함하여 정의할 수 있다. (간단히 표현하면 위임권한과 명령어를 함께 묶어놓았다는 뜻이다)

실행 profile에 지정한 명령어는 profile shell이라고 불리우는 특정 쉘에서만 실행된다. 이 쉘은 pfsh, pfcsh, pfksh라는 이름이 붙어있다. 이들은 각각 Bourne shell (sh), C shell (csh), Korn shell (ksh)에 대응하는 shell로서 각 명칭앞에 pf를 붙였다고 생각하면 된다. (profile shell과 일반 shell은 동일한 것이 아님.)

확장된 사용자속성 DB(user_attr DB)
/etc/user_attr DB는 /etc/passwd 파일과 /etc/shadow 파일을 보조해 주는 역할을 한다. 이곳에는 확장된 사용자 속성 (예. 권한 및 실행 profile등)이 들어있다. 또한 사용자에게 역할을 지정해줄 수 있다.

역할(role)이란 위에서 언급하였듯 관리자밖에 할 수 없는 작업 일부를 일반사용자도 수행할 수 있도록 고안된 특별한 형태의 사용자 계정이다.

역할(role)계정으로 로그인을 하면 사용자는 일반사용자의 계정을 가지고는 실행할 수 없었던 작업을 실행할 권한을 갖게된다.

이러한 권한을 갖게하는 role 계정으로 로그인을 하는 방법은 CDE 로그인과 같은 일반적인 login 과정으로 할 수는 없다. 뒤에서 다시 설명하겠지만 role계정으로 로그인을 하려면 su (switch user) 명령어를 이용하여야 한다.

user_attr DB 는 다음과 같이 콜론(:)으로 각 필드를 구분한다.

user:qualifier:res1:res2:attr

각 필드는 다음과 같은 의미를 갖는다.
- user : passwd DB에 명시된 사용자 이름.
- qualifier : 추후 사용을 위한 예비 필드
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- attr : 사용자가 명령어를 수행할 때 적용할 보안 속성을 명시한 키 값이다. 여러개의 키를 명시할때 각 키는 세미콜론(;)으로 분리하여 표기한다. 사용할 수 있는 키는 아래와 같다.
- auths : auth_attr DB에 명시된 사용권한 중에서 선택한 권한명칭을 콤마( , )로 구분한 목록. 권한명칭은 와일드카드(*)도 사용할 수 있다. 예를 들어 solaris.device.* 라고 표기한 것은 모든 솔라리스 device에 대한 사용권한을 의미한다.
- profiles : prof_attr DB에 명시된 profile중 선택한 profile명칭으로서 서열순으로 표기하고 콤마( , )로 구분한 목록. Profile은 사용자가 실행할 수 있는 명령어와 해당 명령어의 속성을 결정한다. user_attr에 명시된 사용자중 극소수만이 모든 profile을 가질 수 있는 All로 설정해야 한다. (모든 profile을 갖게 되는 All로 설정한다는 것은 속성에 상관없이 모든 명령어를 사용할 수 있다는 뜻이다) profile의 서열 역시 매우 중요하다. 그것은 마치 유닉스의 탐색경로와 같은 원리로 사용된다. 수행될 명령어가 들어있는 목록 첫째 profile은 어떠한 속성이 어떠한 명령어에 적용되는가를 명시한다.
- role : 사용자에게 새로이 부여할 역할이다. 콤마로 구분한 목록형태로 표시한다. 여기서 역할은 user_attr DB에 있는것과 동일해야 하며 이가운데 특정값을 지정하여 결정한다. role 계정에게는 role을 지정할 수 없다. 오직 사용자 계정에게만 지정할 수 있다. (계정은 일반사용자 계정과 role 계정이 있다)
- type : normal이나 role로 지정한다. 만일 일반사용자 계정이면 normal로,
role에 대한 계정이라면 role로 지정한다.

여러분의 시스템에 설치된 user_attr DB를 살펴보면 아래와 같이 기본값이 지정되어 있을 것이다.

위 예를 살펴보면 첫째줄에서는 root에 대하여 모든 권한을 부여한다. 둘째줄은 role 계정이다. sysadmin에 대한 역할을 정의하였다. 다음줄을 일반 사용자 계정이다. 여기서 anne이라는 사용자에게 sysadmin role을 지정하였다.

이렇게 sysadmin 역할을 지정해줌으로써 anne은 Device Management, Filesystem Management와 모든 profile에 대한 profile을 access할 수 있는 막강한 권한을 갖게 된다.

여기까지의 내용을 한번 정리해보자.

역할과 이에 대한 권한을 정의한다.
정의한 역할을 사용자에게 부여한다.
역할을 부여받은 사용자는 이에 대한 권한을 갖게 된다.

Authorizations (auth_attr)
사용자 권한으로는 접근할 수 없었던 작업을 수행할 수 있는 새로운 능력을 부여받는것을 권한위임(authorization)이라 표현하도록 첫장에서 약속한바 있다.

이렇게 위임된 모든 권한은 /etc/security/auth_attr 데이터베이스에 저장된다.

사용자가 이렇게 위임받은 권한을 사용코자 할 때 해당 프로그램은 auth_attr 데이터베이스를 검사하여 위임받은 권한이 있는가를 살펴본후 사용가능 여부를 결정한다. 예를 들어 사용자가 다른 사용자의 crontab 파일을 편집하고자 한다면 solaris.jobs.admin 이라는 권한이 auth_attr에 명시되어 있어야 한다.

사용자 혹은 role이 user_attr 데이터베이스에 명시되어 있으면, 사용자나 role에게 각 권한들을 직접 지정할 수 도 있다. 또한, 실행 profile에 위임할 권한을 지정한후 이것을 다시 해당 사용자에게 넘겨줄 수 있다.

auth_attr 데이터베이스의 각 필드는 콜론으로 구분하여 아래와 같은 형식으로 나타낸다.

authname:res1:res2:short_desc:long_desc:attr

각 필드는 다음과 같은 의미를 갖는다.

authname : 위임받은 권한을 명시함. 단일 문자형 상수로 표현하며 접두사.접미사 형태로 구성한다. 명명법은 바로 아래에 설명해 놓았다.

- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- short_desc : 사용자 인터페이스를 표시하는데 적당한 권한에 대한 간략한 명칭.
- long_desc : 긴 표현. . 이 필드는 사용될 권한과 응용프로그램의 목적, 그리고 그것을 사용하고자 하는 사용자의 형태를 나타내주어야 한다. 응용프로그램의 도움말로 사용하기 적절하게 표현되어야 한다.
- attr : 권한의 속성을 보여주는 옵션 목록으로서 key 워드로 나타낸다. 여러개를 사용할 때에는 세미콜론 (;)으로 구분함.

키워드로서 help를 사용할때 이에 대한 해당 도움말은 html 형태의 도움말로 되어있다. 이 도움말 파일은 이미 /usr/lib/help/auths/locale/C 디렉토리안에 저장되어 있다.

해당되는 도움말 파일 이름만 help=xxxx.html, 이런 형식으로 적어주면 된다.

authname 명명법 : 솔라리스 운영체제를 사용하는 권한은 solaris라는 접두사로 표현한다. 그외 다른 권한은 그 권한을 만들어낸 기관의 인터넷 도메인 이름 순서를 역으로 배열한 접두사를 사용한다. (예 : deskpia.com의 경우에는 com.deskpia)

접미사는 권한을 행사할 수 있는 부분 (예. device) 및 작업 명칭 (예. config, allocate, grant, revoke등) 으로 표현한다.

만일 접미사가 붙지 않고 씌여져 있다면 authname은 권한에 우선하여 GUI 환경에서 해당 응용프로그램을 실행시키던 명칭으로 작동하게 된다. authname solaris.printmgr. 은 이렇게 GUI환경 하에서의 명칭을 사용한 예이다.

authname이 grant라는 단어로 끝났다면, authname은 그 권한을 grant, 즉 양도해준다. 즉, 사용자의 해당 권한(동일한 접두사 및 기능에 관한 권한)을 다른 사용자에게 양도해주는 것이다.

예를 들어, authname solaris.printmgr.grant 라고 표기되었다면 이는 사용자에게 solaris.printmgr.admin 권한과 solaris.printmgr.nobanner 권한을 다른 사용자에게 양도할 수 있는 권한을 부여한 다는 뜻이다.

여기까지 오게되면 이 복잡한 authname을 어떻게 적절하게 구사할 수 있을지 고민스러울 것이다. 그러나 고민할 필요가 없다.

솔라리스 8을 사용하는 여러분의 etc/security 디렉토리 안에는 auth_attr이라는 파일이 들어있다. 이파일의 내용을 보면 솔라리스 운영에 대한 모든 권한 목록을 망라하고 있음을 발견할 것이다. 불필요한 권한 앞에 주석표시(#)를 하면, 여러분이 필요한 권한만 선택하여 사용할 수 있다.

또한 /usr/lib/help/auths/locale/C 디렉토리의 index.html 파일에도 authname으로 사용할 수 있는 솔라리스 운영에 대한 권한 (authorization) 목록 및 그에 대한 설명을 담은 도움말이 있다.

아래는 auth_attr 데이터베이스 예제로서 여러분의 시스템에 기본적으로 지정이 되어 있는 값이다.

auth_attr과 user_attr의 관계는 다음 예제에서 볼 수 있다.

auth_attr DB

auth_attr 데이터베이스에 명시된 solaris.system.date 권한은 시스템의 날짜와 시각을 조정할 수 있는 권한이다. 이 권한이 'auths=solaris.system.date' 라는 문구 한줄로서 아래 예제의 user_attr 데이터베이스에 있는 sunny라는 사용자에게 지정되는 것이다.

user_attr DB

sunny라는 사용자가 solaris.system.dat 권한 및 sysadmin이라는 역할을 위임받았다.

실행 profile DB (prof_attr)
실행 profile은 권한과 명령어를 특별한 속성과 함께 묶어놓은 메카니즘이다. 여기에서 지정한 실행 profile들은 사용자나 role에게 지정할 수 있다. 특별한 속성이란real 및 effective UID, GID를 지칭한다. 가장 일반적인 속성은 real UID 및 effective UID가 root로 지정된 형태이다. 실행 profile의 정의는 etc/security/prof_attr 데이터베이스에 저장되어 있다.

(실행 파일이 수행되면서 프로세스가 만들어질 때, 프로세스를 생성시킨 사용자의 UID를 real UID라 하고, 생성된 프로세스가 가지는 UID를 effective UID라 한다. 일반적으로는 real UID와 effective UID는 같다. 그리고 프로세스는 effective UID의 권한으로 수행된다)

prof_attr 데이터베이스 역시 콜론으로 각 필드가 구분된다.

profname:res1:res2:desc:attr

각 필드에 대한 설명은 다음과 같다.

- profname : profile의 명칭
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- desc : 긴 표현. 이 필드는 프로파일의 목적 및 그것을 사용하고자 하는 사용자의 형태를 나타내 주어야 한다. 응용프로그램의 도움말로 사용하기 적절하게 표현되어야 한다.
- attr : 실행할 대상에 적용할 보안 속성을 보여주는 옵션 목록으로서 key 워드로 나타낸다. 여러개를 사용할 때에는 세미콜론 (;)으로 구분함. 유효한 키워드로는 help, auth 가 있다.

키워드로서 help를 사용할때 이에 대한 해당 도움말은 html 형태의 도움말로 되어있다. 이 도움말 파일은 이미 /usr/lib/help/auths/locale/C 디렉토리안에 저장되어 있다. 해당되는 도움말 파일 이름만 help=xxxx.html, 이런 형식으로 적어주면 된다.

- auth : auth_attr 데이터베이스에 명시된 위임권한 명칭중에서 선택. 여러개를 사용할 때에는 컴마(,)로 구분함. 위임권한 명칭은 와일드카드 (*)를 사용하여 나타낼 수 있음.

아래는 여러분의 시스템에 설정된 prof_attr DB의 예이다.

아래 예제는 prof_attr과 user_attr의 관계를 나타낸 것이다.

Device Management라는 실행 프로파일의 권한과 명령어를 정의하였다.

User Attributes Database 예제

sysadmin이라는 role계정을 만들어서 Device Management 권한을 부여하였다. 이후, prof_attr에서 정의한 Device Management profile이 user_attr에서 정의한 sysadmin role에게 지정되었다.

prof_attr과 auth_attr의 관계는 다음 예제에서 볼 수 있다.

위에서 보면 Device Management profile은 solaris.device. 라는 문자열 상수로 시작되는 모든 권한을 갖는 것으로 prof_attr에서 정의된다. 이러한 권한들은 아래 auth_attr에서 정의된 것이다.

auth_attr Database 예제

실행속성 DB (exec_attr)
실행속성은 profile이 지정된 해당 사용자나 role에 의하여 수행되는 명령어로서 특별한 보안속성을 가진다. 여기서 특별한 보안속성은 UID, EUID, GID, EGID와 같은 속성으로서 명령어가 실행될 때 해당 프로세스에 추가된다.

실행속성이 명시된 내용은 /etc/security/exec_attr 데이터베이스에 저장된다.

exec_attr 데이터베이스 역시 콜론으로 각 필드가 구분된다.
name:policy:type:res1:res2:id:attr

각 필드에 대한 설명은 다음과 같다.

- name : profile의 명칭
- policy : 해당 엔트리에 관련된 보안정책, 현재로는 suser (수퍼유저 정책 모델)만이 유효한 값이다.
- type : 속성이 명시된 엔티티 형태. 현재로는 cmd (command)만이 유효한 값이다.
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- id : 엔티티를 규정한 문자열 상수. 와일드카드 (*)를 사용하여 나타낼 수 있음. 명령어들은 전체 경로 혹은 와일드카드 (*)를 포함하는 경로를 가져야 한다.
- attr : 실행할 엔티티에 적용할 보안 속성을 표현한 옵션 목록으로서 key 워드로 나타낸다. 여러개를 사용할 때에는 세미콜론 (;)으로 구분함. 사용할 수 있는 키워드는 보안정책에 따라 결정된다. 유효한 키워드로는euid, uid, egid, gid등 4개가 있다.

euid 와 uid는 단일 사용자이름이나 숫자로된 사용자 ID를 포함한다. euid를 지정하는 명령어는 지정된 real UID값과 함께 실행된다. 이것은 실행파일에 setgid 값을 설정하는것과 비슷한 과정이다. gid를 지정하는 명령어는 real GID 및 effective GID와 함께 실행된다.

아래는 필자의 exec_attr 데이터베이스에 대한 값중 일부를 나타낸 것이다.
보안관계상 모두 보여드리지 못하지만 여러분의 시스템에서도 찾아볼 수 있다.

다음장에서는 RBAC에서 지정한 role 계정으로 로그인하는 방법을 직접 실습해보고, 그외 관련 유틸리티들을 알아보도록 하겠다.

RBAC 실습 및 관련 유틸리티

이제껏 학습한 RBAC를 직접 실습해보자.

우선 다음과 같이 role 계정을 만들어보자. 이것은 /etc/user_attr파일을 편집하면 된다. (이 파일은 root에게 소유권이 있으며 읽기전용이다. 그러므로 편집을 하려면 파일 속성을 변경해주어야 한다. 편집이 끝난 후에는 다시 원상태로 파일 속성을 돌려놓자)

이렇게 변경한 후, 위에서 만든 sysadmin이라는 role 계정으로 로그인을 해보자.
role 계정으로 로그인할때에는 CDE에서 로그인하는것과는 다르다. 다음과 같이 su 명령어를 사용해야 한다.

이렇게 로그인해보면 어떤 메시지가 화면에 나오는가 ? 아마도 sysadmin이라는 사용자가 없다는 메시지가 나올 것이다. 이유는 잘 아실 것이다. 비록 user_attr에 sysadmin이라는 role계정을 만들었다 해도, sysadmin이라는 사용자계정이 존재하지 않기 때문이다. (user_attr은 passwd 및 shadow 파일을 보충해주는 역할이란 것을 이미 설명한 바 있음)

그렇다면 먼저 해야할 일은 ?

sysadmin이라는 새로운 사용자 계정을 만들어준 후 다시 로그인을 해보자.

이번에는 로그인이 되는가 싶었는데 다시 에러메시지가 나온다. 왜그럴까 ? 위에서 만든 user_attr에는 sysadmin이라는 role계정만 만들었지, 이 role계정을 사용할 수 있는 사용자를 지정하지 않았기 때문이다. 즉, sysadmin이라는 role계정을 부여받은 사용자만이 sysadmin이라는 role 계정으로 login할 수 있는 것이다.

그럼 user_attr을 이렇게 편집해본다.

새로이 추가된 세 번째줄은 sysadmin이라는 role계정을 anne이라는 사용자에게 부여한다는 뜻이다. 여기서 anne이라는 이름은 기존에 이미 등록되어 있는 사용자중 하나를 선택한 것이다. anne대신 자신의 사용자 id를 집어넣어도 된다.

이후 role계정을 부여받은 id로 다시 로그인을 한다. (이때 로그인은 일반 사용자 로그인이다) 그후 위에서 처럼 su를 이용하여 다시 role계정으로 로그인하여보자.

sysadmin이란 계정에 대한 암호를 입력하고 나면 멋지게 role 계정으로 로그인할 수 있을 것이다. 이제 sysadmin에게 부여된 모든 권한을 이 role 계정을 통하여 행사할 수 있다.

솔라리스 8 시스템에는 etc/security 디렉토리에 이미 auth_attr, exec_attr, prof_attr DB가 만들어져 있다. 이들을 가지고 적절히 편집하여 role 및 권한부여를 실습해보면 RBCA의 진가를 느낄 수 있을 것이다.

아래 도구들은 RBAC를 운영하는데 필요한 유틸리티이다.

- auths : 사용자의 위임권한을 표시해줌.
- pfexec : profile 쉘, exec_attr DB안에 명시된 명령어를 속성과 함께 실행시킴.
- policy.conf : 보안정책을 configuring 해준 파일. 부여한 권한을 나열함.
- profiles : 특정 사용자에 대한 profile을 보여줌.
- roles : 사용자에게 부여한 권한을 보여줌.

이상으로 RBAC에 대한 설명을 모두 마쳤다. 쉽지는 않지만 일단 이해하고 나면 매력적인 운영체제가 바로 솔라리스 8이 아닌가 싶다.

암호/인증 시스템의 개요와 구분
솔라리스 운영체제는 시스템 및 네트웍 보안을 위하여 SEAM (Solaris Enterprise Authentication Mechanism), Diffie-Hellman등의 인증 시스템을 제공한다. 본 단원에서는 이가운데 Diffie-Hellman 인증시스템 에 대하여 알아보도록 한다. (SEAM은 다음단원에서 따로이 설명할 예정이다)

암호 시스템
인증시스템에 들어가기에 앞서서 컴퓨터에서 사용하는 암호 시스템에 대하여 살펴보기로 하자.

암호하면 떠오르는 것이 의례 첩보영화나 군사작전일 것이다. 적에게 노출되더라도 비밀이 보장될 수 있도록 평문(plain text)에 보안을 부여하는 것이 암호의 목적이다. 이것은 오늘날 컴퓨터 시스템 보안에도 그대로 적용되고 있다. 물론 암호화 (encryption)기법이 발달할수록 이것을 불필요한 상대방, 예를 들어 해커의 의해 불법적으로 해독 (복호화,decryption)되는 기법도 발전하는 것이 문제이긴 하지만.

오늘날은 암호화하는 방식에 키(key)를 사용한다. 이 키를 운영 방식에 따라 비밀키 암호 시스템과 공개키 암호 시스템으로 나뉜다.

비밀키 암호 시스템
이 시스템은 하나의 비밀키만으로 암호화/ 복호화(해독)를 동시에 수행한다. 전송측과 수신측이 하나의 키를 이용해 암호화와 복호화를 하게 되므로 키를 철저히 관리는것은 이 시스템의 사활이 달린 사안이기도 하다.

비밀키 암호시스템은 공개키 암호시스템에 비해 알고리즘이 단순하여 속도가 빠르고 회로가 간단하다. 비밀키 방식에는 블록 암호 시스템과 스트림 암호 시스템이 있다.

블록 암호 시스템 : 고정된 크기의 입력 블록을 고정된 크기의 출력 블록으로 변형하는 암호 알고리즘을 가지고 암호화 및 복호화 과정을 수행한다. 뒤에서 설명할 DES도 이 시스템중 하나이다.

스트림 암호: 모든 평문에 동일한 암호화 함수가 적용되는 블록 암호와는 달리 비밀키와 현재의 상태 변수(state variable)에서 도출되는 키의 수열(key stream)이 평문과 결합되어 암호문을 생성하는 방식이다.

공개키 암호 시스템
비밀키 시스템에서는 하나의 키만을 사용하므로 그 키가 노출되면 시스템의 소유자가 바뀔 수 있다.

이러한 문제를 해결하기 위하여 개발된 것이 공개키 (public key) 암호 시스템이다.

1976년 미국 스탠포드 대학의 Diffe와 Hellman이 제안한 암호 시스템으로서 모든 사용자는 모든 사람에게 공개되어 있는 공개키(public key)와 자기만의 개인키 (private key 혹은 secret key로도 쓴다) 를 가지고 있다.

공개키는 문서를 암호화할 때 사용하며, 개인키 즉 비밀키는 개인이 보관을 하면서 암호화된 문서를 해독할 때 사용한다. 비밀키만을 사용하는 것에 비해 키를 관리하는 것이 보다 수월해진 것이다.

특히 이러한 개념은 메시지 내용 또는 발신자가 자신이 발송하였음을 부정하는것을 방지할 수 있는 디지털 서명을 가능케 하여 오늘날 전자상거래의 한 축을 담당하고 있다. (개인키는 발신자만이 가질 수 있으므로)

공개키 암호 시스템은 두 개의 키를 사용하느니 만큼, 하나만을 사용하는 비밀키 암호 시스템에 비해 속도가 느리고 키의 길이도 길다.

DES (Data Encryption Standard)
DES (Data Encryption Standard, 데이터 암호화 표준기법) 는 앞서 설명한 비밀키 암호시스템으로서 블록 암호 시스템에 속한다. 이것은 1974년에 미국 통상부의 공식권유에 의하여 IBM이 국가표준국(National Bureau of Standards: 현재의 국가기술표준연구소(NIST))과의 계약에 따라 개발한 시스템이다.

DES는 데이터의 암호화 기법에 56bit key를 사용한다. 두사람의 사용자가 서로만의 비밀문서나 파일을 주고받을 때 둘만의 동일한 DES키를 사용하여 파일내용을 암호화한후 이를 전송할 수 있고, 또한 이를 해독할 수 있다. DES는 전용 DES chip을 사용하거나 소프트웨어적으로도 구현할 수 있다. 또한 하나의 키만을 사용하므로 비교적 빠른 암호화 메카니즘에 속한다.

우리가 사용하고 있는 Unix password 생성도 바로 DES를 이용한 것이다.

그러나 DES도 약점이 있다. 동일한 키를 가진 전문 해커가 파일내용을 가로챌 경우, 동일한 키에 의해 모든 전송내용이 해독될 수 있다. 이러한 이유로 Secure NFS와 같은 보안시스템에서는 사용하는 key를 수시로 변경해준다.

인증 및 절차
네트웍상에서 이루어지는 서버와 클라이언트간의 인증절차는 다음과 같다

클라이언트는,

자신의 공개키/비밀키 짝을 생성하고,
서버를 방문하여 신원증명(credential)을 제시한 후,

공개키에 대응하는 비밀키를 자신이 보유하고 있다는 것을 (비밀키의 공개 없이) 증명한다.

이후, 신원증명이 된 클라이언트와 공개키 사이의 관련을 서버가 확인(verifier)하면 인증절차가 이루어진것이다.

위 절차는 간단하지만 아주 중요한 절차이다. 잘 기억해두도록 하자.

솔라리스 운영체제에서의 Diffie-Hellman 인증법

솔라리스 8에서 제공하는 디피 헬만 인증법은 클라이언트와 서버 양측이 동일한 비밀 키, 즉 공동의 키를 사용하여 서로를 인증해주는 독특한 방식이다. 양측은 서로만이 알 수 있는 암호화/복호화(해독) 기법을 사용하여 보안성이 보장되는 통신을 하게 된다.

이 인증방식은 현재 시각을 암호화한 공동의 키 (common key)를 사용하여 시스템에 전송하는 방식을 골자로 한다. 암호화된 공동의 키를 수신한 시스템은 이를 해독하여 현재시각과 비교하게 된다. 물론 클라이언트와 서버 양측이 사전에 시각을 맞춰놓는 것이 선결조건이다.

여기에서도 물론 공개키(public key)와 비밀키 (secret key)가 사용되는데 이들은 모두 NIS나 NIS+ 데이타베이스에 저장되어 있다. NIS는 publickey map에 키를 저장을 하고 NIS+는 cred table에 키를 저장한다.

공개키와 비밀키는 시스템 관리자가 생성시켜준다. 이가운데 비밀키는 각 사용자의 패스워드안에 암호화되어 저장되며 사용자만이 자신의 비밀키를 알 수 있다. (시스템관리자가 생성시켜준다 하더라도 사용자가 다시 패스워드를 입력하여 비밀키를 바꾸게 된다)

인증 key의 생성 및 활용
Secure RPC가 수행되는 과정에서 사용자를 인증하는 방식을 예를 들면서 각 키가 어떻게 만들어지고 어떻게 활용되는가를 알아보자.

공개키 및 비밀키 생성
시스템관리자는 /usr/sbin에 있는newkey와 /usr/bin에 있는 nisaddcred 라는 두가지 명령어를 이용하여 공개키 및 비밀키를 만들어준다. 키를 변경할때에는 /usr/bin에 있는 chkey 명령어를 사용한다.

처음 로그인시 keylogin이라는 프로그램이 등장한다. 이 프로그램은 로그인 암호가 secure RPC 암호와 동일할 경우에는 사용되지 않는다. 그러나 서로 다를 경우에는 로그인후에 keylogin 이 자동 실행된다.

keylogin의 역할은 다음과 같다.

우선 사용자에게 secure RPC 암호를 물어본후, 답변을 통해 얻게된 암호로 비밀키를 해독한다. 그다음 keyserver라는 프로그램에게 해독한 비밀키를 건네준다. 키서버는 해독된 비밀키를 받아서 저장한후 사용자가 secure RPC transaction을 시작하는 때를 기다리게 된다.

(만일 로그인 암호가 secure RPC 암호와 같은 경우, 로그인 프로세스가 직접 키서버에게 비밀키를 건네준다. 암호가 달라야 할 경우, 사용자는 언제나 keylogin을 구동시켜야 한다. keylogin은 ~/.login, ~/.cshrc ~/profile과 같은 사용자 환경설정 파일 안에 포함되어 있으므로 사용자가 로그인을 할 때마다 자동적으로 수행된다.)

대화키 (conversation key) 생성
사용자가 secure RPC transaction을 시작하면

1. keyserver가 난수를 발생시켜 대화키(conversation key)를 생성한다.
2. 커널은 생성된 대화키를 사용하여 사용자의 현재시각을 암호화시킨 time stamp를 생성한다.
3. keyserver는 공개키 (public key) 데이터베이스에서 서버의 공개키를 찾아낸다.
4. keyserver는 사용자의 비밀키와 서버의 공개키를 사용하여 공동의 키(common key)를 생성한다.
5. keyserver는 공동의 키(common key)로 대화키(conversation key)를 암호화한다.

서버와의 첫 번째 접속
클라이언트는 전송할 자료에 현재시각을 암호화된 time stamp와 암호화된 대화키를 함께 넣어 서버로 전송한다. 전송시 credential과 verifier도 포함된다. ( credential과 verifier의 개념은 네트웍 보안 부분을 참조하기 바란다) credential은 다음 3가지 요소를 포함하고 있다.
- 클라이언트의 망(net) 이름.
- 공동의 키로 암호화된 대화키
- 대화키로 암호화된 window

여기서 window란 서버의 시각과 클라이언트의 time stamp 사이의 시간차이로서 클라이언트가 허용할 수 있는 범위를 말한다. 만일 서버와 클라이언트의 시간 차이가 윈도우보다 커질 경우, 서버는 클라이언트의 요청을 거부할 것이다. 그러나 정상적 상황에서 이러한 일은 벌어지지 않는다. 왜냐하면 클라이언트는 RPC 세션을 시작하기 전에 서버와 자신의 시각을 똑같이 맞추는 동기화작업을 우선적으로 하기 때문이다.

클라이언트의 verifier는 다음 사항을 포함하고 있다.

- 암호화된 time stamp
- 암호화된 윈도우 verifier (1씩 감소함)

윈도우 verifier는 누군가가 사용자로 위장한후 암호화된 credential과 verifier 필드에 난수를 발생시킨 데이터를 채워넣는 방식으로 해킹을 시도할 때 방어용으로 사용된다.

수천번의 시도를 한다 할지라도 해커가 만들어낸 난수로 된 윈도우/타임스탬프 짝이 인증시스템을 통과한다는 것은 매우 힘든일이다. 윈도우 verifier 시스템은 정확한 credential을 추측하기 아주 어렵게 되어있기 때문이다.

대화키 해독과정
서버가 클라이언트로부터 전송자료를 받은후

1. 로칼 keyserver는 공개키 데이터베이스안에서 클라이언트의 공개키를 찾는다.
2. keyserver는 클라이언트의 공개키와 서버의 비밀키를 사용하여 공동키, 즉 클라이언트에 의해 계산된 동일한 공동키를 추론한다. (서버와 클라이언트만이 공동키를 계산해낼 수 있다. 자신이나 상대방의 비밀키를 알아야만 하기 때문이다)
3. 커널은 공동키를 이용하여 대화키를 해독한다.
4. 커널은 keyserver를 호출하여 해독한 대화키를 이용, 클라이언트의 time stamp를 해독한다.

서버에 정보 저장

서버가 클라이언트의 time stamp를 해독한 다음에는 credential table안에 다음 4가지 정보를 저장한다.

- 클라이언트의 컴퓨터 이름
- 대화키

- 윈도우
- 클라이언트의 time stamp

서버는 추후 사용을 위하여 상기 4가지 사항중 클라이언트의 컴퓨터 이름, 대화키, 윈도우 3가지 사항을 저장해둔다. 서버에 저장된 타임스탬프는 누군가가 동일한 타임스탬프로 접근하는 것을 방어해준다. 즉, 서버는 최종적으로 사용된 것보다 시간적으로 큰값을 가진 타임 스탬프만을 받아들이기 때문에 재사용은 불가능하다.

클라이언트로 되돌려주는 verifier
서버는 클라이언트에게 다음사항이 포함된 verifier를 돌려준다.

- 서버가 credential cache에 저장한 기록인 index ID
- 클라이언트의 time stamp에서 1을 뺀 값 (대화키에 의해 암호화된 값임)

time stamp에서 1을 빼는 이유는 time stamp가 클라이언트의 verifier에 의해서 더 이상 사용되어질 수 없도록 하기 위함 이다.

클라이언트가 서버를 인증하는 과정

클라이언트는 서버로부터 verifier를 받은 후에야 서버를 인증하게 된다. 클라이언트는 오직 서버만이 verifier를 전송해줄 수 있음을 알고 있다. 왜냐하면 서버만이 클라이언트가 보낸 time stamp가 무엇인가를 알고 있기 때문이다.

디피 헬만 인증의 실제 구현을 위한 keyserver의 구동

수퍼유저 권한을 갖는다.
keyserver 데몬이 작동중인가를 검사한다.

만일 keyserver가 작동중이지 않으면 이를 실행시킨다.

디피 헬만 인증을 이용한 NIS+ credential 설정방법

NIS+ 클라이언트측의 root를 위한 새로운 키 설정방법

사용자의 네트웍이 NIS+ 환경이라면 아래와 같이 클라이언트 시스템의 설정을 해주면 된다.

. 수퍼유저 권한을 갖는다.

/etc/nsswitch.conf파일을 열어서 다음 사항을 추가한다.

publickey: nisplus

NIS+ 클라이언트를 초기화한다.

# nisinit -cH 호스트이름

위에서 호스트 이름이란 클라이언트에게 서비스를 제공해주는 NIS+ 서버의 이름이다.
물론 호스트서버 이름은 클라이언트의 테이블에 NIS + 서버로 등록되어 있어야 한다.

아래 명령어를 사용하여 cred 테이블에 client를 추가한다.

# nisaddcred local
# nisaddcred des

keylogin 명령어를 사용하여 설정된 내용을 검사한다.

아래 예는 young이라는 호스트를 이용하여 jinhee를 NIS+ 클라이언트로 설정해주는 방법이다. 여기서 네트웍 패스워드를 물어올때에 나오는 경고메시지는 무시해도 된다. keylogin 명령어가 올바로 실행되었다면 jinhee라는 클라이언트는 NIS+ client로 올바르게 설정된 것이다.

NIS+ 사용자를 위한 새로운 키 설정
root의 마스터 서버에 아래 명령어를 입력하여 cred table에 새로운 사용자를 추가시킨다.

# nisaddcred -p unix.UID@도메인이름 -P 사용자이름.도메인이름. des

이 경우, 사용자 이름과 도메인 이름은 도트(.)로 끝나야 한다.

클라이언트로서 로그인하여 설정된 것을 확인한 후 keylogin 명령어를 입력한다.

아래 예는 sunhee라는 사용자에게 DES 보안인가를 해주는 과정이다.

디피 헬만 인증을 이용한 NIS credential 설정방법

NIS 클라이언트측의 root를 위한 새로운 키 설정방법

1. 클라이언트 컴퓨터의 수퍼유저 권한을 갖는다.

2. /etc/nsswitch.conf파일을 열어서 다음 사항을 추가한다.
publickey: nis

3. newkey 명령어을 이용하여 새로운 한쌍의 키를 생성한다.
# newkey -h hostname

위에서 호스트 이름은 NIS 서버가 아니다. 클라이언트 computer 이름을 입력해야 한다.

아래 예는 jinhee라는 클라이언트 컴퓨터를 NIS client 로 설정하는 과정이다.

사용자를 위한 새로운 키 생성방법

관리자가 서버에서 수퍼유저로 로그인한다.

사용자를 위한 새로운 키를 만든다.

newkey -u 사용자이름

시스템은 패스워드를 물어올 것이다. 패스워드를 입력하고 나면 개인키는 암호화되어 패스워드안에 저장된다.

이제 사용자를 부를 차례다. 사용자로 하여금 컴퓨터 앞에 앉아 직접 로그인을 하게 한다. 그후 chkey -p 명령어를 사용하여 개인키를 본인이 직접 다시 암호화시키도록 한다.

위 과정은 junghee라는 사용자가 사용자만이 아는 암호로서 개인키를 다시 암호화시키는 과정이다.

디피 헬만 인증을 이용한 파일공유 및 마운트
NFS는 널리 사용되는 네트웍 서비스이지만 항상 보안이 문제되는 시스템이었다. 솔라리스 운영체제에서 제공하는 Diffie-Hellman 인증을 NFS에 적용시키면 보다 강력한 보안체계를 구축할 수 있다. 이에 대한 실제 적용방법을 알아보자.

파일 공유

수퍼유저 권한을 갖는다.
아래와 같이 share명령어에 F 옵션을 붙여 파일을 공유한다. 그런데 일반적인 NFS 사용때와 다른 옵션이 눈에 띌 것이다. 바로 -o sec=dh라는 옵션이다. 이것은 디피헬만 인증을 사용하여 파일을 공유할때 붙이는 옵션이다.

# share -F nfs -o sec=dh /공유파일경로

파일마운트

수퍼유저 권한을 갖는다.
Mount 명령어에 F 옵션을 붙여 파일을 마운트한다. 이때 디피헬만 인증법으로 파일을 마운트하기 위하여 -o sec=dh 옵션을 붙인다.

# mount -F nfs -o sec=dh 서버명:공유자원 mountpoint

추신. 보안에 있어서 암호화 알고리즘과 키의 길이는 매우 중요이다. 그러나 이에 못지않게 중요한 요소가 바로 보안프로토콜이다.

암호화 알고리즘 기술은 이미 상당한 수준으로 연구, 개발되어있기 때문에 시스템이나 네트웍 보안에 사용할 수 있는 것들을 쉽게 접할 수 있다. 그러나 자료가 암호화되었다고 무조건 안전하다고 마음놓을 수는 없다. 상당수준의 알고리즘으로 암호화되었다 하더라도 제 3자에 의한 보안침해의 가능성은 언제든 발생할 수 있다고 생각해야 한다.

이런 점을 보완해주는 것이 바로 보안 프로토콜이다. 예를 들면 WWW보안에는 SSL(Secure Socket layer) SHTTP 등이 있으며 전자우편에는 PEM, S/MIME 등과 같은 보안프로토콜이 있다.

완벽에 가까운 보안체계 구축을 위하여는 암호화 알고리즘뿐 아니라 보안프로토콜 역시 매우 중요한 요소임을 알아두어야 하겠다.

SEAM 과 Kerberos ver.5
개요
시스템 및 네트웍 보안을 위하여 전세계적으로 사용되는 인증시스템중 하나가 Kerberos 인증 프로토콜이다.

Solaris 운영체제 역시 커버로스를 보안 및 인증 프로토콜로 채택하고 있다. 솔라리스 이전버전에서는 커버로스 버전 4을 제공해주었으나 솔라리스 7부터는 SEAM, 즉 썬 엔터프라이즈 인증 시스템이라는 이름으로 커버로스 최신버전인 ver.5를 제공하고 있다.

혹시, 솔라리스 8을 interactive 방식으로 설치하는 도중, 네트웍 설정과정에서 이 컴퓨터가 kerberos client로 참여할 것인지를 물어보는 메뉴를 본적이 있는지 ? 처음 설치하다 이것을 보고 yes를 선택하면 KDC서버의 ip address를 비롯한 갖가지 서버 옵션을 설정하는 화면이 나오게 된다. 커버로스를 모르면 이 부분에서 매우 당황하게 된다.

물론 처음 설치시에는 커버로스 클라이언트로 설정하지 않아도 나중에 설치를 마친후에 커버로스 클라이언트로 자신의 시스템을 설정할 수 있다.

여기서 커버로스 인증시스템이 무엇이며 어떠한 장점이 있는가를 알아보도록 하자.

Kerberos의 역사
커버로스는 미국 MIT 에서 Athena 프로젝트의 일부로 설계되었다. 이 프로젝트의 목적은 고속의 교육망에 연결된 서버들간에 우수한 데이터 서비스를 제공하기 위한 것이었다. 커버로스는 여기서 사용자, 즉 클라이언트와 서버간에 인증기능을 제공하기 위해서 개발됐다.

Kerberos의 특징
제 3의 인증서버
일반적인 인증시스템은 서버가 모든 클라이언트의 사용자를 직접 인증해주는 방식이다. 그러나 커버로스는 클라이언트와 서버, 그리고 클라이언트의 사용자를 인증해주는 제 3의 서버 이렇게 삼각 관계로 구성되어 있다. 그리고 여기서 등장하는 제 3의 서버, 즉 인증서버를 이용해 사용자의 신분확인이 이루어진다.

신뢰할 수 있는 제 3의 컴퓨터가 서비스를 이용하려는 사용자를 인증해준다면 서버는 클라이언트의 사용자가 올바른 사용자인지를 확인할 수 있으며 서로간 비밀통신이 가능해진다. 이러한 시스템은 현재 인터넷상에서 사용자 인증기법으로 널리 사용되고 있다.

패스워드를 대신한 티켓전송
매번 웹상에서 패스워드를 입력할 때마다 불안한 적이 있었을 것이다. 혹시나 누군가가 이것을 중간에 가로채지는 않을까 하고. 커버로스는 네트웍에서 패스워드 대신 커버로스 티켓(ticket)을 보내는 커버로스 기법을 제공하므로 이러한 걱정을 덜어주는 것이다. (도대체 티켓속에 무엇이 있길래 패스워드 대신 사용이 가능할까 ? 이에 관한 내용은 뒤에서 자세히 설명한다)

타운영체제 보안시스템과의 호환성
Kerberos는 ver. 5가 현재까지의 최신버전이며 많은 운영체제가 네트웍 보안에서의 산업표준으로 커버로스를 채택하고 있다. (윈도우 2000 운영체제도 Kerberos를 채택하였다.)

어디 운영체제뿐이겠는가. 혹시 솔라리스 8용 오라클 8i DB를 설치하였다면 설치하는 도중, 사용자가 DB 접속에 사용할 인증방식을 선택하는 메뉴를 본적이 있을것이다. 여기서 사용가능한 4가지 인증방식중 kerberos를 선택할 수 도 있다.

SEAM 역시 Kerberos V5를 이용하므로 여러 운영체제로 구성된 네트워크에서도 사용할 수가 있다. 게다가 SEAM은 같은 도메인내에서는 물론 서로 다른 도메인과 연결할 때에도 인증 및 보안서비스가 가능하다.

이미 Kerberos 버전 5를 이용하고 있다면 SEAM은 아주 쉽게 이해할 수 있을 것이다.

SEAM 인증체계하에서 사용자는 한 세션당 한번의 인증절차만을 거치면 된다. 이후에 일어나는 세션의 부수적인 처리과정에서는 인증이 자동으로 이루어진다. 일단 인증을 받았다면 password를 다시 입력해야할 일은 없는 셈이다.

SEAM을 사용하게되면 사용자는 철저한 보안환경속에서 다른 컴퓨터에 로그온하여 명령어 실행, 데이터 교환, 파일 송신을 할 수 있다. 또한, 인증서비스를 통하여 시스템 관리자가 사용자의 서비스와 시스템 사용에 적절한 제한을 할 수 있다.

SEAM에서 등장하는 용어
SEAM 및 Kerberos 보안 시스템에서는 새로운 용어들이 많이 등장한다. 이들을 한번 알아보기로 한다.

KDC (키 분배 쎈터)
우선 지난강좌에서 언급한 비밀키와 공개키 방식을 다시 한번 살펴보자.

비밀키 암호시스템에서는 사용자가 100명이라면, 100개의 키를 분배해 놓아야 한다. 이러한 많은 키들을 관리하는 것은 쉽지도 않을뿐 아니라 키의 노출도 쉽게 이루어진다. 이를 해결하기 위해 공개키 암호시스템에서는 각 사용자가 자신의 개인키를 가진다. 보내는 메시지는 받는이의 공개키로 암호화시킨 후 전송을 하고, 받은 메시지는 자신의 개인키로 해독하여 읽으면 된다.

그러나 공개키 알고리즘은 일반적으로 비밀키 알고리즘에 비해 훨씬 느리다. 따라서 실제 사용에 있어서는 공개키와 비밀키를 적절히 혼합하여 사용한다.

보내는이는 자료의 암호화는 비밀키 암호알고리즘을 사용하여 하고, 이 비밀키는 다시 받는이의 공개키로 암호화 하여 암호문과, 암호화된 비밀키를 보낸다. 그러면 수신자는 자신의 개인키를 사용하여 비밀키를 해독하고, 해독된 비밀키를 사용하여 암호문을 다시 해독한다.

그러나 여기서도 어려움이 사라지지 않는다. 공개키 암호 시스템에서는 각 사용자가 다른사용자의 공개키들을 모두 관리해야 되는 것이다. 현실적으로 네트웍에 등록된 모든 사용자에 대한 키를 관리를 한다는 것이 결코 쉽지 않은 일이다. 이런 어려움을 타개하고자 등장한 것이 키 분배센터 (Key Distribution Center, KDC라고 흔히 사용함.)라는 서버이다.

키 분배센터(KDC)는 모든 사용자들의 키를 관리한다. 통신하려는 사용자들이 키를 요청하면 키분배 센터는 키를 암호화 하여 요청한 사용자들에게 나누어 주게 된다. 여기서 키 분배센터가 전체 보안체제에 얼마나 큰 영향을 미치는가를 알 수 있을 것이다.

티켓
티켓이란 사용자가 서버나 서비스에 접속시 사용자 식별 및 인증을 위하여 사용되는 정보 패킷이다. SEAM 시스템은 티켓개념을 중심으로 운영된다. 티켓은 사용자뿐만 아니라 필요할 경우 NFS 와 같은 서비스도 식별해주는 정보의 집합체이다.

티켓에 대한 이해를 쉽게 하기 위하여 운전면허증을 예로 들어보자.

운전면허증에는 사용자의 성명, 주소, 운전할 수 있는 차종, 유효기간 (적성검사를 받아야할 시기)등이 명시되어 있다. 운전면허증은 이 자료를 근거로 운전자의 신원을 증명해주고 어떠한 차종을 운전할 수 있는가를 지정해준다.

티켓에는 서비스의 명칭과 사용자의 명칭, 사용자 호스트의 IP Address, 타임스탬프, 티켓의 유효기간을 명시한 값등이 들어있다. 티켓은 이 자료를 근거로 사용자의 신원을 증명해주고 및 사용자가 어떠한 네트웍 서비스를 사용할 권한이 있는가를 지정해준다.

티켓은 지정된 서버에 대하여 하나의 클라이언트와 하나의 지정된 서비스를 위하여 사용된다. 하나의 티켓으로 두개의 서비스 (예. ftp, telnet) 를 이용할 수 없다는 의미이다.

운전면허증은 유효기간이 있다. 기간이 만료되기전 적성검사를 다시 받아 면허증을 갱신해야 하지만 유효기간까지는 계속 사용할 수 있다. 티켓 역시 일단 만들어지면 유효기간이 만료될때까지 다시 사용할 수 있다.

티켓은 난수형태의 세션키에 의해 생성된다.

credential (서비스를 위한 자격)
credential은 위에서 설명한 티켓과 매칭 세션키가 함께 들어있는 정보패킷이다. credential은 개인키 혹은 서비스키에 의해 암호화된다. 암호화되는 방식은 이것이 어떻게 복호화될것인가에 따라 결정된다.

Client/Server 및 Service

클라이언트 : SEAM에서의 클라이언트는 사용자를 의미하는것이 아니다. 사용자가 워크스테이션에서 사용하는 프로그램 (소프트웨어)를 의미한다.

좀더 생각하면 이 의미를 알 수 있다. 비록 사용자가 서버에 접근하기 위하여 인증을 요청하지만 사용자가 서버에게 직접 인증을 해달라고 말하는것은 아닐 것이다. (서버가 사람의 말을 알아듣지 못하므로). 즉, 사용자는 자신의 프로그램을 실행시켜서, 그 실행된 프로그램을 통하여 서버에게 요청을 하게 된다. 이때 실행된 프로그램이 바로 클라이언트이다.

서버 : SEAM 소프트웨어가 작동되는 물리적인 시스템, 즉 컴퓨터.

서비스 : FTP나 NFS와 같은, 서버가 제공하는 특정한 소프트웨어 (기능).

인증기(authenticator)
티켓을 이용할 때, 인증기는 사용자의 신원확인에 이용된다. 인증기 안에는 사용자 이름, 사용자 호스트의 IP Address, 타임스탬프등이 들어있다.

티켓과 다른점이 있다면 티켓은 다시 사용할 수 있지만 인증기는 서비스를 이용코자 요청을 할때 오직 한번밖에 사용될 수 없다는 것이다. 인증기는 클라이언트와 해당 서버에 대한 세션키를 이용하여 암호화된다.

Principal
SEAM에서의 클라이언트를 구분하는 방법은 해당 principal로 이루어진다.
principal이란 KDC가 티켓을 발급해줄 대상을 식별하는 유일한 단서이다.
principal은 사용자도 될 수 있고 서비스도 될 수 있다.
principal 명칭은 primary, instance, realm등 3가지로 구성된다.

parkjh/admin@PRIME.DESKPIA.COM 라는 명칭을 살펴보자.

parkjh가 primary이며 이것처럼 사용자 이름을 쓰거나, NFS와 같은 서비스 명을 쓸 수도 있다. (서버 이름도 사용할 수 있다)

admin 은 instance이다. instance는 principal이 사용자일 경우, 옵션으로 지정할 수 있지만 서비스일 경우에는 반드시 지정되어야 한다.

parkjh라는 사용자가 시스템 관리자라면 그는 그의 평상시 사용자 증명을 parkjh/admin으로 할 수 있다. 만일 그가 두 개의 다른 호스트에 계정을 가지고 있다면 그는 다른 instance로 두 개의 principal 명칭을 사용할 수 있다. (예를 들면 parkjh/love.deskpia.com 과 parkjh/feel.deskpia.com)
단, SEAM 은 parkjh 와 parkjh/admin을 두 개의 서로 다른 principal로 다룬다.

서비스 principal에서는 instance로서 hostname을 사용하면 된다.
mymachine.knight.deskpia.com 은 그러한 instance의 한 예이다.
그러므로 primary/instance는 nfs/mymachine.knight.deskpia.com 과같이 사용하면 된다.

다음은 principal 명칭의 예들이다.

FEEL.DESKPIA.COM은 SEAM 영역의 한 예로 든것이다.

Realms (영역)
영역이란 하나의 마스터 KDC가 인증서비스를 실시해주는 네트웍상의 시스템 그룹을 지정한 것이다. 즉, SEAM의 인증이 이루어지는 총괄 서비스구역이다. 어떤 영역은 계층적 구조를 이루어 하나가 다른것의 상위에 위치하기도 한다.

Realms (영역) 과 서버
각 영역은 principal DB의 마스터 복사본을 유지, 보관하는 서버를 포함해야 한다. 이것을 마스터 KDC 서버라고 부른다. 또한, 각 realm은 최소한 하나의 slave KDC 서버를 포함해야 하며 이 서버에 principal DB의 제 2 복사본을 저장한다. 마스터 및 슬레이브 KDC 서버 모두 인증을 위한 티켓을 발급한다.

(만일 Slave KDC 서버가 없는 상태에서 마스터 KDC 서버의 DB에 장애가 발생한다면 해당 네트웍에서는 누구도 인증을 받을 수 없는 상황이 발생할 것이다. Slave KDC가 존재하는 이유이다.)

하나의 영역안에 두 개의 부가적인 SEAM 응용프로그램 서버도 위치할 수 있다. SEAM 네트웍 응용 프로그램 서버는 ftp, telnet, rsh와 같은 커버로스 인증을 이용할 수 있는 응용프로그램 사용을 제공한다. 커버로스 인증을 사용하는 NFS 서버도 영역안에 포함될 수 있다.

SEAM의 3가지 키

개인키
이것은 각 사용자에게 기본적으로 주어지며 오직 사용자와 키분배쎈터만이 그 암호를 알고 있다. 사용자에게 있어서 사용자 암호가 개인키의 암호가 된다.

서비스키
서버와 서비스에게 있어서 개인키가 서비스키로 인식된다. 이 서비스키는 개인키와 동일한 목적으로 사용되지만 개인이 아닌, 서버와 서비스가 이용한다는 차이가 있다.

세션키
이 키는 인증서비스 혹은 티켓 발급 서비스에 의해 생성된다. 이 세션키는 클라이언트와 서버간의 보안작업을 위하여 만들어진다.

SEAM에서의 KDC 구성

위에서 언급하였듯, SEAM에서 각 영역은 최소한 2대의 KDC (마스터 KDC 한 대와 한 대 이상의 슬레이브 KDC) 로 구성된다.

SEAM에서의 KDC는 티켓과 매칭 세션키가 들어있는 credentials을 발급하는 책임을 맡는다. 이 credential은 KDC database안에 저장된 정보를 이용하여 생성된다.

키분배쎈터의 마스터키는 stash 파일속에 암호화되어 있다. 네트웍에서 서버가 KDC를 인증해야만 비로소 KDC가 역할을 할 수 있을 것이다. 이 마스터키는 서버가 리부팅된후 KDC를 자동으로 인증할 때 사용된다. 이 stash 파일안에는 마스터키가 들어있으므로 이 파일 및 백업본은 아주 안전하게 보관되어야 한다.

SEAM의 인증과정

SEAM에서는 어떻게 인증절차가 이루어질까 ?

사용자가 원격시스템에 로그온하여 응용프로그램을 사용하려면 자신의 신원을 확인시킬 수 있는 티켓과 매칭 세션키를 제공하여야 한다. 세션키는 사용자와 사용을 하려는 서비스가 지정된 정보를 담고 있다. 티켓과 세션키는 사용자가 처음 로그인할 때 KDC에 의해 생성된다. credential이란 이 티켓과 세션키를 담고 있는 것이다.

다중 네트웍 서비스를 이용하려면 사용자 역시 각 서비스에 필요한 다수의 credential을 가지고 있어야 한다. A라는 서버의 B라는 서비스는 거기에 필요한 특정 credential을 가진 사용자에게만 사용을 허가하기 때문이다.

예를 들어 emerald라는 서버에서 ftp 서비스를 이용하려면 여기에 맞는 credential을 가져야 하며 다른 서버의 ftp 서버스 역시 고유의 credential을 요구한다.

credential이 생성되고 저장되는 과정은 보이지 않게 이루어진다. KDC는 사용자의 요구가 있을 때 credential을 발급해주며 이것은 credential cache에 저장된다.

SEAM에서의 서비스 이용권한 획득
특정 서버의 특정서비스를 이용하기 위해서, 사용자가 얻어야 할 것이 두가지가 있다.

우선 사용자는 '티켓 발급 서비스(Ticket-granting Service)' 자체를 위한 credential을 얻어야 한다. 티켓발급서비스가 credential을 해독하고 난 이후, 서비스는 사용자가 접근하려는 서버의 두 번째 credential을 생성해준다. 서버의 서비스를 이용코자 하는 요청은 여기서 생성된 두번째 credential을 이용하는 것이다.

서버가 성공적으로 두 번째 credential을 해독한 이후에야 비로소 사용자는 해당 서버의 서비스 이용권한을 얻게 된다.

아래 표를 보면 인증과정이 좀더 쉽게 다가올것이다.

등장인물
client, KDC 인증서비스, KDC 티켓발급 서비스, Server

대본

1) client : KDC 인증서비스님, 인증서비스 티켓좀 주세요.
2) KDC 인증서비스 : 잠깐만요. 사용자가 맞나 확인좀 하고요. 아 맞네요. 티켓 여기 있습니다.
3) client : KDC 티켓발급 서비스님, 서버사용에 필요한 티켓이 필요한데요.
4) KDC 티켓발급 서비스 : 잠시만요. 자 여기 티켓입니다.
5) client : 서버님, 제가 사용해도 될까요 ?
6) Server : 세션키를 주세요.
7) client : 제 세션키 여기 있습니다.
8) Server : 예, 맞네요. 어서 들어오세요.

이 과정을 좀더 자세히 알아보자.

티켓발급 서비스를 위한 credential 얻기

인증과정을 시작하면서, 클라이언트는 특정 사용자의 principal을 보내줄 것을 인증서버에게 요청한다. 이 요청은 특별한 보안정보가 없으므로 암호화되지 않고 전송된다.

인증서비스가 이 요청을 접수하고 나면, 사용자의 principal 이름을 KDC 데이터베이스에서 찾는 과정이 수행된다.

principal이 일치하면 인증서비스는 KDC 데이타베이스에서 해당 principal에 대한 개인키를 획득할 수 있다.

인증서비스는 클라이언트가 이용할 세션키, 티켓 발급 서비스 (세션키 1이라 칭함), 티켓 발급서비스를 위한 티켓 (티켓1이라 칭함) 을 발급한다. 이 티켓을 티켓 발급을 위한 티켓 (ticket-granting-ticket, TGT) 이라고 한다.

세션키와 티켓은 에서 획득한 사용자의 개인키로 암호화된 후 클라이언트에게 되돌아간다.

클라이언트는 이 정보를 이용하여 세션키 1과 티켓 1을 복호화하고 개인키를 이용하여 사용자 principal을 복호화한다. 개인키는 오로지 사용자와 KDC 데이터베이스만이 알고 있다. 클라이언트는 이 정보를 credential cache에 저장한다.

보통 이 과정이 수행되는동안 사용자는 자신의 패스워드를 입력하는 작업만 하면 된다.

사용자가 입력한 패스워드가 KDC 데이터베이스에 저장된 개인키에 의해 생성되어 사용된 것과 동일하다면 클라이언트는 인증서비스가 보내준 정보를 성공리에 복호화할 수 있다.

이제 클라이언트는 티켓 발급 서비스와 사용될 credential을 갖게 된다.
클라이언트는 서버에게 credential을 요청할 준비를 마친것이다.

서버 접속을 위한 credential 요청하기
특정서버 접속 요청시, 클라이언트는 먼저 인증서비스로부터 해당서버의 credential을 얻어야 한다.

클라이언트는 그후 티켓발급서비스에게 서비스 principal 이름, 티켓 1, 세션키 1로 암호화된 인증기를 발급해달라는 요청을 하게된다. 티켓1은 원래 티켓발급서비스의 서비스키를 이용하여 인증서비스가 암호화 작업을 해놓은것이다.

티켓발급서비스의 서비스키는 티켓발급서비스 자신이 잘 알고 있으므로 티켓1은 금방 복호화시킬 수 있다. 이 정보에는 세션키와 티켓 1이 담겨있으므로 티켓 발급서비스는 인증기 역시 복호화시킨다. 이시점에서 사용자의 principal이 티켓발급서비스에 의해 인증된다.

인증이 성공적으로 이루어진 후, 티켓발급서비스는 사용자 principal과 서버 (세션키 2)를 위한 세션키 및 서버 (티켓2)를 위한 티켓을 생성한다. 세션키 2와 티켓2는 세션키 1로 암호화된다. 세션키1은 클라이언트와 티켓발급서비스만이 알고있으므로 네트웍상에서도 비밀이 보장된다.

클라이언트가 이 정보패킷을 접수한후, 이것은 credential cache에 저장된 세션키 1을 이용하여 복호화된다. 클라이언트는 서버에서 사용할 credential을 얻게된 것이다.

클라이언트는 서버의 특정서비스를 이용코자 하는 요청을 할 준비를 마치게 된다.

특정 서비스 사용권한 획득하기
특정서비스 이용을 요청하기 위하여, 클라이언트는 먼저 인증서버로부터 티켓 발급서비스 credential을 얻어야 하며 티켓발급서비스로부터 서버 credential을 얻어야 한다.

클라이언트는 서버에게 티켓2 및 다른 인증을 보내달라고 요청한다. 인증기는 세션키 2에 의해 암호화되어있다.

티켓2는 서비스를 위한 서비스키로 티켓발급서비스에 의해 암호화되어있다. 서비스키는 서비스 principal 이 잘 알고 있으므로 서비스는 티켓2를 복호화하여 세션키 2를 얻을 수 있다. 세션키 2는 인증기 복호화에 사용된다.

인증기가 성공리에 복호화되면 클라이언트는 서비스 이용권한을 갖게 된다.

SEAM 구성요소와 파일, 명령어

SEAM 구성요소
SEAM 1.0에는 아래와 같은 프로그램이 들어있다.

키분배쎈터 (KDC)
Database 관리프로그램
티켓획득, 열람, 삭제용 사용자 프로그램
커버로스 보안시스템 적용 프로그램 -- telnet등
관리 utilities등

Solaris 7에는 위의 프로그램이 모두 들어있다. SEAM 클라이언트 기능을 사용하려면 KDC가 운영중인 환경하에서만 가능하다. 티켓을 분배하는 KDC, 즉 제 3의 인증서버 없이 SEAM은 이루어질 수 없으므로...

그러나 Solaris 8에는 SEAM의 클라이언트쪽 소프트웨어만이 제공된다. 고로 상기 프로그램중 KDC를 비롯한 많은 부분이 빠져있다. 솔라리스 8 사용자 입장에서는 섭섭할 수 있다. 왜 KDC를 주지 않을까 ?

지금 이 글을 읽고 계시는 분들중 많은 분들은 자신의 PC 1대에 솔라리스8 인텔버전을 설치하여 사용하고 계실 것이다. 이것만으로는 SEAM에서 요구하는 영역(realm)을 구성할 수 없다. 최소 KDC 2대가 별도로 필요하기 때문이다.

그러나 솔라리스 8이 설치된 PC가 네트웍에 참여하고 있고, 그 네트웍에서 이미 커버로스 5를 운영중이라면 솔라리스 8이 설치된 PC는 SEAM Client 시스템으로 금방 사용할 수 있다. SEAM은 커버로스5의 일원이므로 다른 운영체제의 커버로스 5와도 호환이 된다고 앞장에서 설명한 바 있다.

만일 자신이 몇대의 PC나 워크스테이션을 가지고 있다면, 그리고 네트웍의 일원으로서 DNS에서 자신의 시스템이 도메인명을 받을 수 있다면 직접 SEAM 영역을 구성해볼 수 있다. 이때 KDC 서버는 솔라리스 7 운영체제가 설치된 컴퓨터를 이용하고, 솔라리스 8이 설치된 컴퓨터는 SEAM 인증방식을 사용하는 클라이언트로 사용하면 될 것이다. 이러한 분들을 위하여 KDC를 설정하는 방법을 본단원의 12, 13페이지에 각각 기술해 놓았다.

솔라리스8에 포함된 클라이언트 소프트웨어는 다음과 같다.

티켓획득, 열람, 삭제용 사용자 프로그램 (kinit, klist, kdestroy)
SEAM password 변경 프로그램 (kpasswd)
Key table 관리 유틸리티 (ktutil)
Pluggable Authentication Module (PAM)
GSS_API plug-ins : Kerberos protocol 제공 및 암호화 기능제공
NFS client 및 server 지원프로그램

Solaris 8 에서 사용할 수 있는 SEAM Client 파일 및 명령어, DAEMON은 다음과 같다. 이들에 대한 자세한 내용은 다음부분에 설명해 놓았다.

SEAM 관련 파일
/etc/gss/gsscred.conf : gsscred table의 기본 파일형태
/etc/gss/mech : RPCSEC_GSS 메카니즘
/etc/gss/qop : RPCSEC_GSS 보호 함수
/etc/nfssec.conf : NFS 인증 보안모드를 정의한 구성파일.
/etc/krb5/krb5.conf : Kerberos 영역 구성파일
/etc/krb5/krb5.keytab : network application server의 KEYTAB 파일
/etc/krb5/warn.conf : Kerberos 경고메시지 구성파일
/etc/pam.conf : PAM 구성파일
/tmp/krb5cc_uid : 기본 credentials cache (uid는 사용자의 UID 값)

SEAM 명령어
/usr/bin/kdestroy : 커버로스 티켓 삭제
/usr/bin/kinit : 커버로스 티켓 요청
/usr/bin/klist : 커버로스 티켓 목록 열람
/usr/bin/kpasswd : 커버로스 암호 변경
/usr/bin/ktutil : 키탭 관리 유틸리티
/usr/sbin/gsscred : NFS 서버에서 사용하는 GSS-API 토큰 발급

SEAM Daemon
/usr/lib/krb5/ktkt_warned : 커버로스 경고메시지 데몬
/usr/lib/gss/gssd : GSSAPI daemon

SEAM Client 구성 및 로그인과정

여러분이 솔라리스 8을 사용하고 있다면 , SEAM 서비스가 필요할 경우에는 얼마든지 SEAM client로 시스템을 설정할 수 있다. 이때 필요한 프로그램을 설치하는 과정 및 실제로 SEAM이 설치된 시스템에 로그인 하는 과정을 알아본다.

SEAM Client 구성방법

아래는 SEAM client 구성의 한 예이다.

deskpia.com이라는 도메인을 예로 들어본다.

SEAM client 설치시 사전 준비사항.
솔라리스가 설치된 여러분의 컴퓨터가 KDC가 작동중인 영역안에 있어야 한다. 또한 DNS 서비스를 통하여 여러분의 컴퓨터 이름 (ip address가 아님) 을 도메인에서 사용할 수 있어야 한다.

자신의 컴퓨터의 superuser 권한을 획득한다. 다음으로 해야할 과정은 그간 #을 붙여놓아 서비스를 막아놓았던 커버로스 관련 서비스의 #을 찾아다니며 제거해주는 일이다.

PAM configuration file (pam.conf)을 연다.

Kerberos PAM module 구동을 위하여 아래 여덟개 줄에 붙어있던 #을 제거한다.

NFS 보안서비스 설정파일을 편집기로 연다. (nfssec.conf).
커버로스 서비스를 설명한 라인의 #을 제거한다.

커버로스 구성파일 (krb5.conf)을 편집기로 연다.

영역 (realm) 명칭과 서버의 명칭을 알맞게 변경해준다.

deskpia.com이라는 도메인을 예로 들어본다.

client1 # cat /etc/krb5/krb5.conf

NTP나 다른 시각 동기화 메카니즘을 이용하여 마스터 KDC와 자신의 컴퓨터와의 시간을 맞춰준다. (시간맞추기. 간단한 방법이지만 이것은 SEAM인증의 핵심이다. 다른 서버와 서로 시간을 맞추는 방법은 다음장에서 설명한다)

SEAM 인증시스템의 로그인절차 .
사실 사용자입장에서 볼 때, SEAM은 SEAM 세션이 시작되었어도 정말 시작이 되었는지조차 알 수 없을 것이다. SEAM 세션이 시작되면 로그인 후 커버로스 암호를 입력하는 것 이외에는 별반 특별한 것이 없기 때문이다.

kinit 라는 명령어를 수행시키면 사용자가 자신을 인증할 수 있는 티켓을 키분배쎈터 (KDC)에 요청하는 과정도 포함된다. 키분배쎈터(KDC)는 티켓을 발급해주면서 사용자가 다른 컴퓨터에 접속할 수 있는 권한을 부여한다. 즉, 사용자가 티켓을 요청하는 것은 kinit 명령어의 일부분으로 자동 수행되는 셈이다. 오직 인증을 받은 클라이언트만이 특정서버에 대한 티켓을 얻을 수 있으며 그렇지 못한 클라이언트는 knit 명령어를 사용할 수 없다.

다음은 커버로스 환경에서 로그인하는 과정의 한 예이다.
로그인시에는 kinit -l 사용자이름 순으로 명령어를 입력한다.

omega% kinit -l username

kinit 명령어는 사용자에게 티켓 사용기간 (-l 옵션)과 패스워드를 물어오게 된다.

Kerberos Ticket 목록을 출력하려면 klist 명령어를 사용한다.

kinit나 klist와같은 커버로스 명령어를 사용하려면 SEAM Client가 시스템에 구성되어 있어야 한다. 그렇지 않으면 etc/krb5.conf 파일이 아직 구성되지 않았다는 에러메시지만을 보게 된다.

SEAM principal 설정
아쉽게도 principal을 설정, 운영할 수 있는 도구는 솔라리스 8에 포함된 SEAM Client에서는 제공하지 않는다. 그러나 솔라리스 7에서는 기본적으로 제공이 되므로 이것을 사용할 수 있다.

principal 구성을 위해서는 솔라리스 7에 포함된 SEAM TOOL을 이용하도록 하자.

사용할 수 있는 프로그램은 /usr/krb5/sbin 디렉토리안에 있으며 두가지가 있다.
하나는 GUI 방식의 관리도구로서 gkadmin이라는 명령어를 수행하면 된다.
또하나는 명령어 입력방식으로서 kadmin이라는 파일이다.

principal을 추가, 열람하는 방법은 위에서 언급한 gkadmin을 이용, SEAM TOOL을 이용하는 방법과 명령어를 직접 입력하는 방법이 있다.

SEAM TOOL을 작동시키려면 gkadmin 명령어를 입력하면 된다.

$ /usr/krb5/sbin/gkadmin

화면에 로그인 윈도우가 나타날 것이다.
만일 기본으로 지정된 값을 바꾸고 싶으면 새로운 값을 입력하면 된다.
로그인 윈도우는 자동적으로 기본값이 들어있는 상태로 나타난다. 화면에 나타난 기본 principal 이름은 사용자 환경에서 사용자의 현재 신분을 식별할 수 있는 정보들을 가지고 만들어진 것이다. 또한 기본 영역 및 마스터 KDC 필드는 /etc/krb5/krb5.conf 파일에서 끌어온 것이다.

기본설정값으로 되돌리고 싶으면 Start Over 버튼을 누르면 된다.
지정된 principal 이름의 패스워드를 입력한후 ok 버튼을 누른다.
principal list가 나열된 윈도우가 나타날 것이다.

명령어 이용방법

새로운 principal 생성
아래 예는 park이라는 새로운 principal을 kadmin 명령어로 생성한 예이다. principal의 정책은 testuser로 설정하였다.
kadmin: add_principal -policy testuser park
Enter password for principal "pak@DESKPIA.COM":
Re-enter password for principal "pak@DESKPIA.COM":
Principal "park@DESKPIA.COM" created.
kadmin: quit

리스트 화면에 출력
아래 예는 kadmin 의 list_principal 명령어를 이용하여 test* 라는 와일드카드와 부합되는 모든 principal의 리스트를 화면에 나타내는 방법이다.

kadmin: list_principals test*
test1@DESKPIA.COM
test2@DESKPIA.COM
kadmin: quit

principal 속성 조회
다음은 get_principal 명령어로서 park/admin principal의 속성을 조회하는 예이다.

kadmin: getprinc park/admin
Principal: park/admin@DESKPIA.COM
Expiration date: Fri Aug 25 17:19:05 PDT 2000
Last password change: [never]
Password expiration date: Wed Apr 14 11:53:10 PDT 1999
Maximum ticket life: 1 day 16:00:00
Maximum renewable life: 1 day 16:00:00
Last modified: Thu Jan 14 11:54:09 PST 1999 (admin/admin@DESKPIA.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes: REQUIRES_HW_AUTH
Policy: [none]
kadmin: quit

principal 패스워드 변경
change_password 명령어를 이용하여 sunny 라는 principal의 패스워드를 변경하는 방법은 다음과 같다.

kadmin: change_password sunny
Enter password for principal "sunny":
Re-enter password for principal "sunny":
Password for "sunny@DESKPIA.COM" changed.
kadmin: quit

principal 삭제
delete_principal 명령어를 이용, sunny라는 principal을 삭제하는 예이다.

kadmin: delete_principal sunny
Are you sure you want to delete the principal "sunny@DESKPIA.COM"? (yes/no): yes
Principal "sunny@DESKPIA.COM" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
kadmin: quit

새로운principal 추가
NFS service principal을 생성한다.
nfs/client1.deskpia.com 라는 이름의 principal 생성:.

root principal 생성
root/client1.deskpia.com라는 이름의 principal 생성

host principal 생성.
host/client1.deskpia.com라는 이름의 principal 생성.

keytab file에 root principal 추가.
root/client1.deskpia.com principal 은 keytab file안에 포함됨.

SEAM NFS 서버 설정
NFS 서비스는 UNIX UID를 이용하여 사용자를 식별하지 사용자의 principal을 직접 이용하지는 않는다. principal을 UID로 변환,해석할 때 사용자의 principal을 UNIX UID로 나타내주는 credential table을 생성해야 한다. 이 과정은 SEAM NFS 서버를 설정해주는데 꼭 필요하다.

SEAM NFS Server 설정
SEAM NFS server 설정을 위한 사전 요구사항.
SEAM client software가 설치되어 있어야 한다.
NTP client 혹은 다른 시각 동기화 메카니즘이 설치되어 있어야 함.
마스터 KDC가 설정되어 있어야 한다.

아래 설정사항을 적용하여 사용해보자.

realm name = DESKPIA.COM
DNS domain name = deskpia.com
NFS server = mynfs.acme.com
admin principle = skn/admin

우선 솔라리스 7에 포함된 KDC와 함께 제공된 SEAM TOOL을 이용하여 NFS 서버의 새로운 principal을 추가한다.

서버의 NFS service principal을 생성한다.
nfs/mynfs.deskpia.com 이라는 이름의 principal 생성

root principal 생성
root/mynfs.deskpia.com이라는 이름의 principal 생성

서버의 NFS 서버스 principal을 서버의 keytab파일 안에 추가.
nfs/mynfs.deskpia.com principal 은 keytab file안에 포함되어 있음.

gsscred 명령어를 이용하여 credential table 생성. (아래에 생성하는 방법을 설명해놓음)

커버로스 보안모드를 사용하여 NFS file system 공유

각 클라이언트에서 사용자와 루트의 principal을 인증

gsscred 테이블의 백엔드 메카니즘 변경방법

NFS server의 수퍼유저권한을 획득한다.

/etc/gss/gsscred.conf을 열어서 메카니즘을 수정한다.

다음 back-end mechanisms 중 하나를 사용할 수 있다.
files, xfn_files, xfn_nis, xfn_nisplus, xfn.

Credential Table 생성방법

gsscred credential table은 NFS 서버가 SEAM principal을 UID로 매핑하는데 사용된다. NFS 클라이언트가 커버로스 인증을 이용하여 NFS 서버로부터 파일 시스템을 마운트하기 위해서는 이 테이블이 반드시 생성되어 있거나 사용할 수 있어야 한다.

서버의 수퍼유저 권한을 획득한다.

이 명령어를 수행할 서버 및 명령을 실행할 사용자의 ID는 gsscred 테이블을 지원해주기 위하여 선택한 백엔드 메카니즘에 따라 달라진다. xfn_nisplus를 제외한 모든 메카니즘은 루트만이 사용할 수 있다.

Back-end Mechanism과 그에 따른 결과
files : NFS server상에서 실행.

xfn : 기본 xfn file 세팅값에 근거한 호스트 선택

xfn_files : NFS server상에서 실행.

xfn_nis : NIS 마스터상에서 실행.

xfn_nisplus : NIS+ 데이터를 변경시킬 수 있는 권한이 있는한 어디서나 실행

만일 /var/fn이 존재하지 않지만 xfn 옵션중 하나를 사용하고자 할 때에는 기본 XFN 데이터베이스를 생성해야 한다.
# fnselect files
# fncreate -t org -o org//

gsscred를 이용하여 credential table을 생성하는 방법

이 명령어는 /etc/nsswitch.conf 파일안에 있는 패스워드 엔트리와 함께 모든 소스로부터 정보를 수집한다. 만일 credeintial 테이블에 로칼 패스워드 엔트리를 포함시키고 싶지 않다면 file 엔트리를 임시로 삭제해놓아야 한다.

# gsscred -m kerberos_v5 -a

Credential Table에 단일 엔트리 추가하기

이과정에 앞서서 NFS 서버에 gsscred 테이블이 이미 설치되어 있어야 한다.

NFS server의 수퍼유저 권한을 취득.
gsscred 명령어로 테이블에 엔트리 추가
# gsscred -m [mech] -n [name] -u [uid] -a

mech : 사용될 보안 메카니즘
name : KDC에서 정의된 사용자의 principal 이름

uid : 패스워드 데이터베이스에 명시된 사용자의 UID
-a : principal 이름 매핑에 UID를 추가

단일 엔트리를 크리덴셜 테이블로 변경한 사례
UID 3736으로 매핑된 샌디라는 이름의 사용자를 위하여 엔트리를 추가한 예이다.
명령줄에 포함되어 있지 않을 경우, UID는 패스워드 파일로부터 가져오게 된다.

# gsscred -m kerberos_v5 -n sandy -u 3736 -a

커버로스를 이용한 NFS 보안설정
다중 커버로스 보안모드를 이용한 NFS 보안환경 설정방법

커버로스는 NFS 시스템의 보안환경 설정시 여러가지 보안모드를 동시에 지정할 수도 있고 하나만을 선택하여 사용할 수도 있다. 설정방법은 다음과 같다.

NFS server의 수퍼유저 권한 획득.

서버의 /etc/dfs/dfstab 파일을 열어서 적절한 보안mode를 추가해준다.

# share -F nfs -o sec=mode 공유파일경로

mode : 공유시 사용되는 보안모드. NFS에서 사용되는 share 명령어는 SEAM과 만나면서 더욱 강력한 보안체계을 갖추게 된다. SEAM은 share 명령어에 다음과 같이 3가지 보안모드를 적용하여 쓸 수 있게 해준다.

krb5 Kerberos 인증방식을 선택
krb5i 무결성이 보장된 Kerberos 인증방식 선택
krb5p 무결성과 기밀성이 보장된 Kerberos 인증방식 선택

보안모드가 여러개로 설정되어 있을 때에는 관리자가 특정 보안모드를 선택하지 않는 이상 첫번째로 설정된 모드가 사용된다.

이렇게 설정되면 NFS 공유파일에 접근하기 위하여 모든 클라이언트는 커버로스 인증을 받게 된다.

NFS 서비스가 서버에서 작동중인가를 확인해야 한다.

만일 이것이 사용자가 처음 사용한 공유명령어라면 NFS 대몬은 작동하지 않고 있다는 의미가 된다. 아래 명령어를 이용하여 대몬을 없앤후 다시 restart시키자.

# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

단일 커버로스 보안모드로 파일 시스템을 공유한 예

아래는 krb5 가 /export/home 공유파일 사용을 위한 단일 커버로스 보안모드로 선택된 예이다.

# share -F nfs -o sec=krb5 /export/home

다중 커버로스 보안모드로 파일 시스템을 공유한 예

아래 예는 3개의 커버로스 보안모드가 모두 적용된 것이다. 마운트 요청이 들어왔을 때 보안모드가 지정되지 않으면 나열된 것중 첫 번째 보안모드(아래 예에서는 krb5)를 모든 NFS 클라이언트가 사용한다.

# share -F nfs -o sec=krb5:krb5i:krb5p /export/home

KDC와 SEAM Client간의 시간 맞추기

솔라리스는 서버와 클라이언트간 시간을 똑같이 설정해놓음으로서 이것을 기본으로 서로를 인증하는 수단을 제공한다고 수차례 언급하였다. 다음은 인증의 가장 중요한 수단인 시각 동기화, 즉 시스템간의 시간을 똑같이 맞추는 방법이다.

KDC와 SEAM 클라이언트간 시간을 똑같이 맞추는데 사용되는 도구로서는 네트웍 타임 프로토콜 (NTP)이 가장 적합하다고 한다. 솔라리스는 2.6 버전부터 델라웨어대학에서 나온 NTP 도메인 소프트웨어를 내장하고 있다.

NTP를 사용하게 되면 사용자는 네트웍상에 있는 시스템들의 정확한 시간조정을 할 수 있다. NTP는 기본적으로 클라이언트/서버 방식이다. 사용자는 하나의 시스템을 마스터 클럭 (NTP 서버)로 지정한후 다른 모든 시스템의 시간을 마스터 클럭의 시간과 동일하게 맞추면 된다. 이 작업은 xntpd 라는 대몬을 통해 이루어진다. 이 대몬은 유닉스 시스템 표준시간을 관리, 조정해주는 역할을 한다.

KDC와 SEAM 클라이언트가 시각을 맞추는 작업은 다음과 같다.

먼저 NTP server를 지정한다. (영역내에서 마스터 KDC를 제외한 아무 서버나 NTP 서버로 지정할 수 있다) 그후 NTP 서버에서 다음 작업을 진행한다.

서버의 수퍼 유저 권한을 갖는다.

/etc/inet directory로 간다.

ntp.server라는 file을 ntp.conf라는 file로 복사한다.

# cp ntp.server ntp.conf

/etc/init.d directory로 간다.

xntpd daemon을 구동시킨다.

# ./xntpd start

NTP Client 시각 설정
네트웍상에서 KDC와 SEAM 클라이언트를 설정한것처럼 NTP서버의 NTP 클라이언트도 다음과 같이 설정하면 된다.

수퍼유저 권한을 갖는다.

/etc/inet directory로 간다.

ntp.client file을 ntp.conf file로 복사한다.

# cp ntp.client ntp.conf

/etc/init.d directory로 간다.

xntpd daemon을 구동시킨다.

./xntpd start

다른시스템과 일자 및 시간 맞추기

수퍼유저 권한을 갖는다.

rdate 명령어를 사용하여 다른 시스템과 일자 및 시간을 동기화시킨다.

# rdate 다른시스템 이름

예제 : deskpia라는 시스템과 omega라는 시스템의 시각 동기화 예제

수동으로 시스템 시각 조절하기
아래예는 시스템의 시간을 조절하는 예이다. 대부분의 유닉스시스템과 동일할 것이다.

수퍼유저 권한을 갖는다.

새로운 일자 및 시각을 입력한다.

# date mmddHHMM[cc]yy

순서: 월, 일, 시간, 분, [세기], 연도

예제

Ticket 관리

티켓 생성법
티켓은 보통 사용자가 로그인할 때 자동으로 만들어지므로 특별히 이를 만들기 위한 작업은 필요치 않다.

그러나 티켓유효기간이 만료되었을 때, 혹은 사용자의 principal이 아닌 다른이의 principal을 사용해야 할 때에는 직접 새로 만들어서 사용해야 한다.

티켓을 만들때에는 다음과 같이 kinit 명령어를 사용한다.

% /usr/bin/kinit

이후 해당 패스워드를 입력해주면 된다.

티켓 만들기 실제사례
sunny라는 사용자가 자신의 시스템에 티켓을 생성하는 예이다.

아래는 sunny라는 사용자가 -l 옵션을 이용하여 3시간동안만 사용할 티켓을 만드는 예이다.

다음 예는 sunny가 새로운 인증절차 없이 다른 컴퓨터에서도 본인이 사용할 수 있는, 즉 전송가능(forwardable)한 티켓을 -f 옵션을 써서 만드는 과정이다. 이 전송가능한 티켓으로 사용자는 두번째 시스템에 로그인을 할 수도 있고 3번째 시스템에서 ftp를 이용할 수도 있다.

티켓속성 확인하기
모든 티켓이 동일하지 않다. 어떤 티켓이 전송가능한것이라면 다른 것은 날짜를 연기할 수도 있으며 또 어떤티켓은 두가지 모두의 속성을 가질 수 있다. klist 명령어에 -f 옵션을 사용하면 사용자가 가진 티켓이 어떤 속성을 가지고 있는지를 확인해볼 수 있다.

% /usr/bin/klist -f

아래 기호는 klist 명령어로 티켓을 열람할 때 각 티켓에 부여된 속성을 나타내는 것이다.

F : Forwardable
f : Forwarded
P : Proxiable
p : Proxy
D : Postdateable

d : Postdated
R : Renewable
I : Initial
i : Invalid

티켓이 가진 여러 속성을 표현한 티켓의 종류

soonja라는 사용자가 전송가능하고(F) 날짜를 늦출 수 있지만(d) 아직 유효하지 않은(i) 기본 티켓을 가진예이다.

아래는 정희(junghee)라는 사용자가 다른 호스트에서 그녀의 호스트로 전송된(f) 2장의 티켓을 확인하는 과정이다. 이 티켓들은 (재)전송이 가능한(F) 것들이다.

작업후 확실히 티켓 삭제하기
일반적으로 티켓은 커버로스 명령어 수행이 종료되면서 자동으로 삭제된다. 그러나 이험한 세상에 누구를 믿겠는가 ? 대부분의 사용자들은 커버로스 티켓이 확실히 삭제되었음을 확인하고 싶어한다. 만일 아직 시스템에서 삭제되지 않은 티켓을 누군가가 슬쩍하여 티켓 유효기간이 만료될 때까지 자신의 것인양 사용하고 다닌다면 .... 생각만 해도 아찔하기 때문이다.

확실히 티켓을 삭제할때에는 kdestroy 명령어를 사용하면 된다.

% /usr/bin/kdestroy

작업을 마치면서 티켓을 항상 확실히 삭제하려면 ?
자신의 홈디렉토리 내에 .logout 파일이 있을 것이다. 여기에 kdestory 명령어를 추가시키면 티켓도난 걱정은 끝이다. 시스템 사용을 마치면 자동으로 kdestroy가 수행되므로.

패스워드 관리
SEAM 설치와 함께, 사용자는 두개의 패스워드를 받게 된다. 하나는 솔라리스 일반 패스워드이고 또하나는 커버로스 패스워드이다. 이 둘은 동일하게 설정할 수도 있고 다르게 설정할 수도 있다.

비 커버로스 환경 명령어는, 로그인등에서 인증을 할때, 커버로스와 유닉스 모두 PAM을 통해서 수행을 한다. 만일 다른 패스워드를 사용할 경우, 로그온시 필요한 인증과정은 두개의 패스워드를 모두 요구할 것이다. 그러나 두개의 패스워드가 동일할 경우, 유닉스 로그인시 사용한 첫번째 패스워드가 커버로스에도 그대로 사용된다.

물론 동일한 패스워드는 사용하기에는 편리할 지 모르지만 보안상은 그리 권장할만한 사항이 아니다. 만일 누군가가 사용자의 패스워드를 알게 된다면, 그날부터 사용자의 유닉스 패스워드는 만인의 것이 될 수 있기 때문이다.

그러나, 커버로스를 사용하지 않는것에 비한다면 커버로스의 동일한 암호체계가 훨씬 안전하다고 볼수 있다. 일단 커버로스환경에서의 패스워드는 네트웍을 통해서 전송되는 것이 아니기 때문이다. (대부분의 사이트는 패스워드 설정등에 관한 규정을 정해놓은 자체 보안정책을 가지고 있을 것이다. )

커버로스 패스워드는 커버로스가 사용자의 신원을 확인하는 유일한 수단이다. 만일 해커가 커버로스 패스워드를 알아낸다면 커버로스 보안은 무의미해지게 된다. 해커는 사용자로 위장하여 사용자가 보낸것으로 위장한 e-mail을 보낼 수 있고, 사용자의 파일을 열어보고 편집, 삭제할 수도 있다. 또한 사용자로 위장하여 다른 호스트에 접속할 수도 있지만 누구도 이를 눈치채지 못한다.

사용자의 패스워드는 시스템 관리자에게조차 누설되어서는 안된다. 또한, 사용자의 패스워드는 수시로, 혹은 패스워드가 누설되었다고 판단되었을 경우, 즉시 바꿔주어야 한다.

패스워드 변경시 참조사항

사용자의 패스워드는 컨트롤키와 리턴키를 제외한 어떠한 글자도 포함시킬 수 있다. 좋은 패스워드란 사용자는 쉽게 기억할 수 있지만 다른이는 추측조차 할 수 없는 것이다.

좋지못한 패스워드는 다음과 같다.

1) 사전에서 발견할 수 있는 단어 (패스워드 발생장치를 이용하는 해킹툴이 가장 먼저 검색하는 대상이다)
2) 자신 혹은 가족의 생일
3) 주민등록번호, 운전면허증번호, 여권번호등 신분증 번호
4) 컴퓨터 설명서에 예를 들어 나오는 패스워드 (이걸 그대로 사용하는 사용자를 실제로 본적이 있다)
5) 유명인사의 이름 (특히 외국 영화배우 이름을 사용하는 이들이 많다)
6) 사용자의 이름을 적당히 바꾸어놓은것 (이름을 뒤로 쓰거나 두번 반복해서 쓴것등)
7) 가족 이름
8) #5@6&at.3_*^1g9와 같은 너무 난해한 패스워드 (보안상은 좋지만 어떻게 외울것인가. 어디에 적어두었다가 분실이라도 하면... )

좋은 패스워드는 최소 8자의 길이를 가져야 한다. 또한 대문자와 소문자, 숫자와 특수부호등을 포함해야 한다. 좋은 패스워드의 예는 다음과 같다.

1) SmnSbmw 와 같이 자신만이 아는 약어 (풀이 : So Many night, Sit by my window)
2) 발음하긴 쉬우면서도 아무런 뜻이 없는 단어 (WangTang, shung)
3) 일부러 틀리게 쓴 단어 : 5taimes, mauntinhalla

주의 : 위에 명시된 패스워드를 절대 그대로 사용하지 말기 바람.

패스워드 바꾸기
커버로스 패스워드를 바꾸는 명령어는 passwd와 kpasswd 두가지가 있다.

passwd는 일반 유닉스 명령어다. SEAM을 설치하고 나면, 솔라리스의 passwd 명령어는 자동적으로 새로운 커버로스 암호를 물어올 것이다.

passwd 명령어가 kpasswd 명령어보다 좋은점은 유닉스와 커버로스 패스워드를 동시에 설정할 수 있다는 점이다. 그러나 passwd 명령어를 이용하여 두개의 패스워드를 동시에 바꾸지는 말자. 유닉스 패스워드만 변경하고 커버로스 패스워드는 그대로 둘 수 있다.

kpasswd 명령어는 passwd 명령어와 매우 유사하다. 차이점이라면 kpasswd는 단지 커버로스 암호만을 바꿀 수 있다는 점이다. 유닉스 패스워드를 바꾸려면 반드시 passwd 명령어를 써야한다.

또하나의 차이점은 kpasswd 명령어는 유닉스 사용자들에게는 유효하지 않은 커버로스 principal의 암호를 변경할 수 있다는 것이다. 예를 들어, david/admin은 커버로스 principal이지만 실제 유닉스 사용자는 아니다. 고로 이것을 변경하려면 passwd가 아닌 kpasswd 명령어가 필요하다.

패스워드를 바꾼후 변경한 패스워드가 적용되기 까지는 시스템 설정상태에 따라 수분에서 수시간이 걸릴 수도 있다. 만일 패스워드를 변경한 후 급히 커버로스 티켓발급이 필요할 때에는 우선 변경한 패스워드를 입력해본후, 적용이 되지 않았다면 변경전 패스워드를 사용하면 된다.

Kerberos V5는 시스템 관리자가 각 사용자의 패스워드를 구성하는 방법을 지정해놓을 수 있다. 예를 들어, 패스워드는 최소한 8자의 길이를 가지며 반드시 2개이상의 숫자가 들어있어야 한다고 지정해 놓으면, 사용자들은 숫자가 들어있지 않은 패스워드를 생성할 수 없다.

아래는 kpasswd를 사용하여 패스워드를 변경하는 예이다.

위와 같이 패스워드 범주를 지정해놓으면 그 범주를 벗어난 패스워드는 생성되지 않는다.

아래 예는 soonja라는 사용자가 passwd 명령어를 이용하여 자신의 UNIX 및 커버로스 패스워드를 동시에 바꾼 예이다.

위 예에서 나타나듯 커버로스 보안시스템안에서 passwd 명령어는 유닉스 및 커버로스 패스워드를 함께 물어온다. (만일 try_first_pass 항목이 PAM module에 설정되어 있다면 Kerberos password는 자동적으로 UNIX password와 동일하게 설정된다)

Master KDC Server 구성
SEAM에서 KDC는 가장 중요한 위치에 있다해도 과언이 아니다. 커버로스의 핵심이 바로 제 3의 인증서버이며 이것이 KDC의 역할이기 때문이다. 이것이 구성된 이후에야 비로소 SEAM 클라이언트 프로그램을 비롯한 SEAM 구성요소가 동작할 수 있다.

솔라리스 8에서는 제공되지 않는 기능이지만 여러대의 서버를 사용하여 SEAM을 구성코자 하는 분들을 위하여 KDC 서버 구성방법을 마지막으로 기술하고자 한다.
이미 언급한 바와 같이 KDC 서버 구성을 위하여는 솔라리스 7이 필요하다.

KDC는 1대의 마스터 서버와 1대이상의 슬레이브 서버로 구성하여야 한다. 마스터와 슬레이브의 차이는 무엇일까 ? 마스터가 할 수 있는 데이터베이스 관리작업을 슬레이브는 할 수 없다는 점이다.

예를 들어, 패스워드를 변경한다거나 새로운 principal을 추가하는 일은 마스터에서만 할 수 있다. 이후 작업이 끝난후에야 변경사항들이 슬레이브로 옮겨진다. 그러면 마스터와 슬레이브는 모두 동일한 DB파일을 가지고 있는 셈이 될 것이다.

credential을 발급하는 일은 마스터와 슬레이브 모두 할 수 있다. 설사 마스터에 변고가 발생하였다 할지라도 슬레이브가 계속 credential을 발급할 수 있으므로 더 이상의 비극을 막을 수 있는 것이다.

Master KDC 구성
KDC 구성에 대한 전반적인 예를 들어보기로 하자. 사용자가 KDC 설치를 위한 아무런 사전구성도 하지 않았다는 가정하에서 시작한다.

아래와 같이 환경설정을 해놓았다고 가정한다.

마스터 KDC 구성을 위한 사전 준비사항

우선 KDC 소프트웨어가 시스템에 설치되어 있어야 한다. (당연한 이야기겠지만). 그리고 DNS가 운영중인 네트웍이어야 한다. (마스터와 슬레이브의 호스트네임을 지정해주어야 하므로) 또한 마스터에 변고가 발생했을 경우, 자동으로 슬레이브가 그 역할을 할 수 있도록 마스터와 슬레이브 KDC 호스트 이름이 swapping되어야 한다. (스와핑 방법은 따로이 설명한다)

마스터 KDC 구성순서는 다음과 같다.
마스터 KDC서버 (kdc1 서버) 의 수퍼유저 권한을 갖는다.
커버로스 구성파일(/etc/krb5.conf)을 연다.
필요할 경우, 영역 (realm) 명칭과 서버의 명칭을 변경한다. 이미 SEAM 소프트웨어를 설치하여 사용중이라면 그냥 확인만 해보아야 한다.

위의 예에서는, default_realm, kdc, admin_server, 그리고 모든 domain_realm 라인의 엔트리를 변경하였다. 만일 영역과 도메인의 명칭이 동일하다면 설치과정중 default_realm 엔트리는 자동으로 생성되지 않는다. 그러나 자세한 설명을 위하여 위의 예에 포함시켜 놓았다.
또한 help_url 경로도 적절한 주소로 변경시켜 준다.

KDC 구성파일 (kdc.conf)을 연다.
필요할 경우 영역 명칭을 변경시켜준다. 이것 역시 이미 SEAM 소프트웨어를 설치하여 사용중이라면 그냥 확인만 해보아야 한다.

kdb5_util을 이용, KDC 데이터베이스 생성

kdb5_util 명령어는 KDC 데이터베이스를 생성하는데 사용된다. kadmind와 krb5kdc 데몬이 시작되기 전에 KDC 자신을 KDC가 인증하는데 필요한 stash파일이 있다. 이 stash파일 역시 kdb5_util 명령어에 -s 옵션을 붙여서 생성한다.

Kerberos access control list file (kadm5.acl)을 연다.

/etc/krb5/kadm5.acl 파일안에는 KDC를 관리하는 것이 허용된 모든 principal 명칭이 들어있어야 한다. 첫 번째 엔트리는 다음과 같이 되어있을 것이다.

sunny/admin@DESKPIA.COM *

이 엔트리는 DESKPIA.COM 영역안에 있는 sunny/admin이라는 principal에게 KDC의 principal이나 보안정책을 마음대로 수정할 수 있는 권한을 주는 것이다. 초기 설치과정에서는 모든 admin principal과 일치한다는 * 표시가 포함되어 있을 것이다. 이것은 보안상 위험한 요소이므로 admin principal 리스트를 모두 직접 포함시키는 것이 좋다.

kadmin.local을 시작한다.

다음과정은 SEAM이 사용할 principal을 생성하는 것이다.
kdc1 # /usr/krb5/sbin/kadmin.local
kadmin.local:

kadmin.local을 이용하여 데이터베이스에 모든 관리자 principal을 추가한다.
필요한 모든 관리 principal을 추가하도록 하자. KDC 구성을 마치기 위해서는 최소한 하나의 관리자 principal이 추가되어야 한다. 이 예에서는 sunny/admin principal이 추가되었다. 물론 여러분은 sunny대신 다른 이름을 사용해야 한다. (*주: sunny는 선희라는 사용자였음)

kadmin.local을 이용하여 kadmin의 keytab파일 생성

kadmin.local 명령어는 kadmin과 changepw의 principal 엔트리에 대한 keytab 파일을 생성해주는 것이다. 이 principal들은 kadmind 서버스를 위해서 꼭 필요하다.

필요한 principal을 모두 추가해준 이후 kadmin.local을 종료한다.

kadmin.local: quit

이후 커버로스 대몬을 작동시키자.
kdc1 # /etc/init.d/kdc start
kdc1 # /etc/init.d/kdc.master start

kadmin을 구동시킨다.

여기서, 사용자는 SEAM 관리도구를 이용하여 필요한 principal을 추가해줄 수 있다. 간단하게 설명하기 위하여 커맨드 라인을 사용한 예를 들었다. 이 과정을 수행하기 위해서는 이미 사용자가 만들어놓은 admin principal 명칭중 하나로 log on 해야 한다.

kadmin을 이용하여 마스터 KDC 호스트 principal 생성하기.

호스트 principal은 ftp나 telnet 과 같은 커버로스 서비스나 klist, kprop과 같은 커버로스 응용 프로그램이 사용하는 것이다.

필요할 경우, kadmin 명령어를 이용하여 마스터 KDC의 root principal을 생성한다.
이 principal은 인증된 NFS-mounting에만 사용하므로 마스터 KDC에서는 필요하지 않다.

마스터 KDC의 호스트 principal을 마스터 KDC의 keytab 파일에 추가해준다.
이렇게 추가를 해주면 추가된 principal은 필요할 경우, 자동적으로 사용된다.

kadmin을 종료한다.

kadmin: quit

각 KDC의 엔트리를 propagation 구성파일 (kpropd.acl)에 추가한다.
이미 SEAM 소프트웨어를 설치하여 사용중이라면 그냥 확인만 해보아야 한다.

NTP나 다른 시각 동기화 메카니즘을 이용하여 마스터 KDC의 시각을 맞춘다. 모든 서버의 시각은 krb5.conf 파일의 libdefaults 부분에 명시한 기본 범위내로 설정되어 있어야만 보안인증이 이루어질 수 있다.

여기까지가 마스터 KDC 구성과정이었다. 다음장에서는 슬레이브 KDC 구성과정을 알아보도록 하자.

Slave KDC Server 구성
kdc3라는 이름의 새로운 슬레이브 KDC를 구성하는 것으로 예를 들어보자.
슬레이브 KDC 구성에 대한 전반적인 예를 들기 위하여 사용자가 kdc3 서버를 슬레이브로 설정하기 위한 아무런 사전구성도 하지 않았다는 가정하에서 시작한다.
이번 예에서는 아래와 같이 환경설정을 해놓았다고 가정한다.

slave KDC 구성을 위한 사전 준비사항.

마스터 KDC가 구성되어 있어야 한다.
SEAM slave KDC 소프트웨어가 kdc3라는 서버에 설치되어 있어야 한다.

슬레이브 KDC의 구성 순서는 다음과 같다.

마스터 KDC의 수퍼유저 권한을 갖는다.
마스터 KDC에서 kadmin을 구동시킨다. 이때에는 마스터 KDC를 구성할 때 생성해 놓은 관리 principal 명칭중 하나로 로그인한다.

마스터 KDC에서, kadmin을 이용하여 슬레이브 호스트 principal을 데이터베이스에 추가시킨다. 슬레이브 KDC가 제 기능을 발휘하기 위하여, 슬레이브 KDC는 호스트 principal을 가져야 한다.

필요시 마스터 KDC에서 kadmin을 이용하여 슬레이브 KDC의 root principal을 생성한다. 이 principal은 슬레이브가 인증된 파일 시스템을 NFS-mounting할때에만 사용하면 된다.

kadmin 프로그램을 종료한다.

kadmin: quit

마스터 KDC에서 커버로스 구성파일 (krb5.conf)을 연다.
각 슬레이브의 엔트리를 추가시킨다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.

마스터 KDC에서 database propagation configuration file (kpropd.acl)에 각 슬레이브 KDC의 엔트리를 추가해준다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.

모든 슬레이브 KDC에서 마스터 KDC 서버로부터 KDC 관리파일을 복사해온다.
이 과정은 모든 슬레이브 KDC에서 반드시 필요한 것이다. 마스터 KDC 서버는 모든 KDC가 가지고 있어야 하는 최신의 정보를 항상 가지고 있기 때문이다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다. ftp나 기타 전송 프로그램을 이용해서 마스터로부터 아래 파일을 몽땅 가져온다.

/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl

새로 구성한 슬레이브 KDC에서 kadmin을 이용하여 slave의 host principal을 slave의 keytab file에 추가한다. 이때에는 마스터 KDC를 구성할 때 만들어 놓은 관리 principal 명칭중 하나로 로그온 하여 작업한다. 이 엔트리는 kprop나 다른 커버로스 응용프로그램을 사용할 수 있게 해준다.

마스터 KDC에서 crontab -e 명령어를 실행하여 백업시 자동으로 작동되는 cron job에 슬레이브 KDC 명칭을 추가한다.

각 kprop_script 라인의 끝에 슬레이브 KDC 서버의 이름을 추가한다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.

백업되는 시간을 변경하려면 앞에 써있는 숫자를 바꾸면 된다. 현재 이 구성파일은 매일 오전 3시 10분에 백업과정이 시작되도록 설정되어 있다.

마스터 KDC에서 kprop_script를 이용하여 데이터베이스를 백업하고 슬레이브로 복사해주자. 만일 백업과정이 이미 끝나서 데이터베이스 백업본이 있다면 다시 할 필요는 없다.

새로 구성한 슬레이브 KDC에서 kdb5_util 명령어를 이용 stash파일을 생성한다.

새로 구성한 슬레이브 KDC에서 KDC daemon (krb5kdc)을 시작한다.

새로 만든 슬레이브에서 NTP나 그외 시각설정 프로그램을 사용하여 마스터 KDC와 시각을 맞추도록 한다. 모든 서버의 시각은 krb5.conf 파일의 libdefaults 부분에 명시한 기본 범위내로 설정되어 있어야만 보안인증이 이루어질 수 있다.

이제 모든 과정이 끝났다. 한 대의 마스터 KDC와 한 대의 슬레이브 KDC가 있으면 이제 SEAM 환경에서 여러분의 컴퓨터를 클라이언트로 설정하여 사용할 수 있게 된다.

SEAM의 실제적용과 KDC 보안

시스템 보안을 위한 SEAM의 실제 적용
이제껏 복잡한 SEAM 및 커버로스 인증체계를 알아본 이유는 ? 누군가 시스템에 access할 때 솔라리스 운영체제가 무상제공해주는 SEAM을 이용하여 인증절차를 통과하도록 함으로서 시스템 보안을 향상시키기 위함이었다.

그러면, 실제로 사용자들이 ftp, telnet 서비스 사용시 커버로스 인증절차를 반드시 거치게 하는 방법을 알아보자.

/etc/inetd.conf 파일을 열어서 telnet 부분으로 간다.

텔넷 엔트리에 '-a user' 옵션을 추가한다.

telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a user

ftp 부분으로 가서 ftp 엔트리에도 -a 옵션을 추가한다.

ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd -a

/etc/inetd.conf 파일에 있는 쉘이나 로긴의 엔트리는 모두 주석을 붙이거나 삭제한다.

# shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
# login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

자, 이제부터는 커버로스 인증을 거치지 않은 사용자는 telnet이나 ftp를 절대 사용할 수 없다.

KDC server 보안
보디가드가 아무리 남을 잘 지켜준다 해도, 그 보디가드가 공격을 당해서 쓰러진다면... KDC 서버는 보안상 아주 중요한 위치에 있음을 누차 강조한 바 있다. 그 KDC 서버가 공격대상이 되어 누군가가 침입을 했다면....

우선 다른서버도 그러하겠지만 KDC는 일반 사용자들이 접근할 수 없는 안전한 장소에 위치해 있어야 한다. KDC 데이터베이스의 백업본, 그리고 keytab 파일은 KDC 서버의 디스크나 다른 슬레이브 KDC 디스크에 보관한다. (테이프백업본은 특히 소홀하기 쉬운 부분이다. 서버만큼이나 안전하게 보관되어야 한다.)

KDC로 접근하는 방법은 복도위를 걸어서 오는 방법과 네트웍 선을 타고 오는 방법이 있다. 불필요한 사용자가 네트웍 선을 타고 오는 방법을 차단하는 방법은 KDC 서버의 /etc/inetd.conf 에 있는 서비스중 필요없는것을 중단시키면 된다.

그러나 KDC의 임무를 위하여 중단하면 안되는 것들이 있다. time 서비스, krdb5_prop 서비스는 꼭 필요하다. 또한, loopbak tli ( ticlts, ticotsord, and ticots)를 이용하는 서비스 역시 그냥 둘 필요가 있다.

아래는 새로 수정한 KDC의 inetd.conf 파일이다. 필요없는 대부분의 서비스는 삭제하였다.

위와 같이 변경후에는 KDC서버를 꼭 재부팅해주어야만 효력이 발생한다.

ASET (자동 보안강화 시스템 도구)
개요
기나긴 솔라리스 보안의 마지막 강좌부분이다. 이제껏 우리가 다룬 내용의 대부분은 어떻게 하면 허가받지 않은 이들이 파일 및 시스템에 접근하는 것을 막을 수 있을까 하는것이 주된 사항이었다. 이를 더욱 보강해 줄 수 있는 도구로서 솔라리스 8은 ASET이라는 재미있는 시스템 보안강화 유틸리티를 함께 제공해주고 있다. ASET은 시스템 보안을 자동으로 모니터링하고 제어하는 기능을 제공한다. 시스템 관리자는 ASET이 제공하는 관리도구로 보안등급을 조절하여 시스템을 운영할 수 있다. 관리자가 보안등급을 낮음 (low), 중간 (medium), 높음 (high) 중 하나로 지정해주면 ASET은 이를 시스템보안에 그대로 적용시켜준다.

ASET은 7가지 형태의 작업을 수행한다. 각 작업을 통하여 시스템 파일에 대한 보안 점검 및 접근권한 제어가 가능하다. ASET이 높은 등급으로 적용될 수록 시스템 파일에 접근하기는 더욱 어려워지고 보안에 헛점이 될만한 시스템파일들은 모두 체크되며, 감시대상이 된다.

/usr/aset 디렉토리를 살펴보면 이 안에는 ASET 작업에 필요한 마스터파일, 레포트, 그외 다른 ASET 파일들이 들어있다. ASET이 적용하는 보안등급은 마스터파일에 의해 구성된다. 물론 이들 파일을 적절하게 수정하여 해당 싸이트의 보안정책에 따른 ASET 보안레벨을 결정할 수 있다.

ASET은 작업을 하면서 보안상 약점을 찾아내어 리포트로 남겨놓는다. 뿐만 아니라 높은 보안등급을 적용시켜 놓으면 ASET이 직접 모든 시스템 보안상 약점을 수정, 변경해준다. 만일 그래도 잠재적인 보안 위험요소가 남아있게 되면, ASET은 그 문제를 관리자에게 리포트로 보고해준다. 충직한 보안담당 보좌관인 셈이다.

ASET 세션은 /usr/aset 명령어를 사용하여 필요시 직접 실행시킬 수 있다. 또한 crontab파일에 엔트리를 추가해주면 일정한 시간마다 주기적으로 ASET을 실행시킬 수도 있다.

그런데 ASET 작업은 많은 디스크작업을 수반한다. 보안점검을 위한 파일검사 때문이다. 이는 평상시 시스템 작업에 방해가 될 수 있다. 이로 인한 시스템 성능저하가 우려된다면 시스템 사용상태가 최저일 때 ASET을 구동시키도록 스케줄을 잡으면 된다. (하루 혹은 이틀에 한번꼴로 새벽 2시에 실행이 되도록 하면 되지 않을까 ?)

도대체 ASET의 7가지 작업은 무엇일까 ?
ASET이 작업중 발견한 모든 문제들을 자세히 기록한 리포트는 보안관련 문제해결에 큰 도움을 줄 수 있다. 작업이 완료되면 리포트는 해당파일 안에 기록된다. 그러면, ASET이 하는 작업을 각각 구체적으로 살펴보자.

시스템 파일 사용권한 검증
사용자가 원하는 보안레벨은 회사마다 모두 틀릴 수 있다. 이 작업은 시스템 파일의 사용권한을 원하는대로 설정해준다. 솔라리스 운영체제가 인스톨될 때에도 이것이 수행되지만 (낮은 보안등급으로 기본설정될것이다) 인스톨 후에도 이작업을 다시 실행시켜 보안레벨을 수정할 수 있다. 낮은 보안등급에서는 누구나 시스템에 쉽게 접근할 수 있는 개방형 정보공유 환경으로 설정된다. 그러나 높은 보안등급에서의 시스템 파일 접근은 매우 제한된다. 이 작업을 통해서 이루어지는 시스템 파일의 사용권한이나 파라메터 변경내용은 tune.rpt 파일에 리포트로 기록되므로 어떤 파일이 어떻게 변경되었는가를 쉽게 알 수 있다.

시스템 파일 점검작업
시스템파일을 점검하고 마스터파일에 적힌 내용과 비교해보는 작업이다. 마스터파일에는 관리자가 지정한 보안등급하에서 시스템파일에 대해 점검해야할 체크리스트가 들어있다. 마스터파일은 ASET이 이작업을 최초로 실행할때 생성된다. 점검해야 할 파일들이 들어있는 디렉토리 리스트는 각 보안등급에 따라 정해진다.
사용자는 기본 리스트를 그대로 사용할 수도 있고 그것을 변경시킬수 도 있으며, 각 레벨마다 다른 디렉토리를 지정할 수도 있다.

각 파일에 대하여 다음 사항들이 점검된다.

소유자 및 그룹
사용권한 (permission bits)
크기 및 checksum
링크의 개수
최종적으로 수정된 시간

여기서 마스터파일과 비교하여 일치하지 않는 점은 cklist.rpt파일에 기록된다. 이 파일은 마스터파일에 기록된 시스템파일 크기, 사용권한, checksum값과 비교한 결과가 포함되어 있다.

사용자/그룹 점검
이 작업은 passwd 및 group 파일에 정의된 사용자계정 및 그룹의 무결성(integrity)과 일관성(consistency)을 점검한다. 여기서는 local 호스트컴퓨터와 NIS 혹은 NIS+의 패스워드파일을 점검한다. NIS+ 패스워드 파일에 문제가 발견되면 이것은 리포트로 남겨지지만 패스워드 파일이 수정, 변경되지는 않는다. 이 작업에서는 다음 위반사항을 점검한다.

중복된 이름이나 ID
정확치 않은 포맷 엔트리
패스워드가 지정되지 않은 계정
유효하지 않은 로그인 디렉토리
nobody 계정
null 값의 그룹 패스워드
NIS 혹은 NIS+ 서버의 /etc/passwd 파일안의 +기호

위반된 사항은 모두 usrgrp.rpt 파일에 리포트로 남겨진다.

시스템 구성파일 (configuration file) 점검
이 작업에서는 여러 가지 시스템 테이블을 검사한다. 대부분은 /etc 디렉토리안에 있는 것들이며, 다음 파일들이 검사대상이다.

/etc/default/login
/etc/hosts.equiv
/etc/inetd.conf
/etc/aliases
/var/adm/utmpx
/.rhosts
/etc/vfstab
/etc/dfs/dfstab
/etc/ftpusers

점검후 발견되는 문제점들은 sysconf.rpt file에 기록된다.

환경변수 점검
root 및 일반사용자들의 PATH 및 UMASK 환경변수가 각 사용자의 해당 /.profile, /.login, /.cshrc file안에 어떻게 설정되어 있는가를 점검한다. 점검후 발견되는 문제점들은 env.rpt file에 기록된다.

eeprom 점검
eeprom은 솔라리스 인텔 버전사용자에게는 해당사항이 없는 내용이지만 sparc 서버 사용자에게는 중요한 사항이다. 이 작업은 eeprom의 보안관련 parameter가 적절한 보안등급으로 설정되어있는가를 점검한다. 사용자는 이 값을 none, command 혹은 full로 지정할 수 있다. ASET은 이 값을 변경시키지는 않지만 권장하는 결과는 eeprom.rpt 파일에 기록한다.

Firewall (방화벽) 설정
방화벽에 대해서는 네트웍 보안부분에서 언급한바 있다. ASET은 여러분의 시스템을 그대로 방화벽 시스템으로 만들어줄 수 있다. 방화벽 시스템이 꼭 필요한 이들에게는 ASET이 그 해결책이 될 수 있는 것이다.

ASET으로 이 방화벽 시스템을 설정하게 되면 정말 높은 보안레벨을 시스템에 적용시킬 수 있다. IP 패킷전송도 막을 수 있다. 그러나 이것을 만들기 전에 고려해야 할 사항이 참으로 많다. 일단 적용되고 나면 기존의 환경과는 전혀 다른 상황이 벌어지기 때문이다.

만일 사용자가 높은 보안등급으로 ASET을 실행시키고는 싶지만 방화벽 구축까지는 필요가 없다면 asetenv 파일을 수정하여 firewall 작업을 삭제할 수 있다. 그러면 firewall 작업을 제외한 다른 작업은 그대로 실행된다.

ASET 실행기록 (log) 및 보고서 (Report)
ASET 실행 기록 (log)
ASET을 실행시키면 아래와 같이 작업에 대한 log, 즉 실행기록이 화면에 나타난다. 뿐만 아니라 ASET은 수행된 모든 작업내용을 파일에 기록해준다. aset -n 명령어를 사용하면 이 작업내용이 e-mail로 지정된 사용자에게 전송된다.

4 ASET 실행기록(log) 파일의 예

위 기록의 첫 번째에는 ASET이 수행된 시스템과 시각이 나타난다. 그후 시작된 각 작업의 목록이 나온다.

ASET은 각 작업을 백그라운드로 처리할 수 있다. 백그라운드 처리작업이 시작되었다는 것은 실행로그의 목록에 나타나지만 이것이 종료되었는가는 표시되지 않는다. 백그라운드작업의 상태를 점검하려면 taskstat 유틸리티를 사용하면 된다.

ASET 리포트
ASET 작업과 함께 생성되는 모든 리포트 파일은 /usr/aset/reports directory 밑에 있는 해당 서브디렉토리에 들어있다. 이 서브디렉토리의 구조 및 사용법은 다음과 같다.

리포트가 생성될 때에 붙여지는 이름은 생성된 시간과 일자를 반영한것이다. 이를 통하여 ASET 실행중 시스템 상태의 변동 기록을 살펴볼 수 있다.

아래는 새로 생성된 두 개의 서브디렉토리의 한 예이다.

각 서브디렉토리 이름은 월일_시간:분 (이들 모두 두자리 숫자로 구성)의 형식이다.

lastest 디렉토리는 최신 리포트가 있는 서브디렉토리로 연결되는 심볼릭 링크이다.
고로 ASET이 생성한 최신 리포트를 보려면 /usr/aset/reports/latest directory로 가면 된다. 이곳에는 ASET이 수행한 각 작업중 최근에 실행된것에 대한 리포트 파일이 들어있다.

ASET Report File 형식
각 리포트파일은 해당 작업이 종료되면서 생성된후 이름이 붙는다.
아래는 작업이름과 이에 해당하는 리포트의 목록이다.

시스템 파일 사용권한 검증 (tune) : tune.rpt
System file 점검 (cklist) : cklist.rpt
사용자/그룹 점검 (usrgrp) : usrgrp.rpt
시스템 구성(configuration)파일 점검 (sysconf) : sysconf.rpt
환경변수 점검 (env) : env.rpt
eeprom 점검 (eeprom) : eeprom.rpt
방화벽 설정 (firewall) : firewall.rpt

각 리포트파일 안에는 시작 및 끝을 표시하는 배너표시가 잇다. 정전이 된다던가 하는 불의의 사고로 해당 작업이 비정상적으로 중단될 때, 리포트파일의 끝부분에는 작업이 중단된 이유가 표시된다. (물론, 정전이 되서 작업을 중단한다는등 구체적인 이유가 나오지는 않는다)

아래는 usrgrp.rpt 리포트파일의 예이다.

ASET Report File 점검
ASET을 재구성(reconfiguration)하거나 처음 실행시킨 후에는, 리포트파일을 세밀히 점검해보아야 한다. 재구성할 때에는 마스터 서브디렉토리의 asetenv 파일이나 마스터파일이 수정되기도 하며, ASET 작업이 실행될 보안레벨이 변경되는 수도 있으므로. 리포트 파일에 기록된 모든 오류사항은 재구성될 때 표시된다. 리포트를 세밀히 점검함으로서 시스템에 발생한 모든 문제점에 대응하고 이를 해결할 수 있다.

ASET 관련 파일운영
ASET Master File
/usr/aset/masters 디렉토리안에 있는 tune.high, tune.low, tune.med, uid_aliases등의 파일을 ASET 마스터파일이라고 한다. ASET은 이들 마스터파일을 근거로 시스템의 보안등급을 지정한다.

Tune File
tune.low, tune.med, tune.high 와 같은 파일은 ASET 보안등급을 지정하는 마스터파일이다. 이들은 각 등급에서의 시스템 파일의 속성을 명시해주고 비교나 참고 목적으로 사용된다.

uid_aliases 파일
uid_aliases file은 같은 ID를 공유하는 복수 사용자 계정의 리스트를 가지고 있다.
보통, ASET은 이러한 사용자 계정에 대하여 경고를 해준다. uid_aliases 파일에 있는 exceptions에 목록을 표기해주면 이러한 원칙에서 예외를 허용할 수 있다.
그러나 복수의 사용자계정이 동일한 사용자 ID를 갖는 것은 피해야 하며, 꼭 이를 원할 경우에는 그룹 계정 생성과 같은 다른 방법을 찾아보자.

체크리스트 파일
ASET을 처음 실행시키거나 보안등급을 변경후 실행시킬 때 시스템파일 체크리스트를 이용한 마스터파일이 생성된다. 이작업으로 점검되는 파일은 다음 환경변수로 정의된다.

CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH

ASET 환경 File (asetenv)
asetenv라는 환경파일은 ASET 작업에 영향을 주는 변수 목록을 가지고 있다.
사용자가 원하는대로 ASET 작업을 변경할 수 있도록 이 변수들은 수정이 가능하다.

ASET 구성
ASET은 대부분의 경우 약간의 사용자 관리 및 구성, 혹은 기본값으로 수행시킬 수 있다.
그러나 특정한 ASET에 영향을 미치는 파라메터들을 약간 튜닝해주면 효과를 극대화시킬 수 있다. 기본값을 변경하기 전에 ASET이 어떻게 수행되는가와 이 파라메터들이 시스템의 각 요소들에게 어떤 영향을 미치는가를 알아보자.

ASET은 아래 4가지 구성파일에 의거하여 작업의 특성을 결정한다.

/usr/aset/asetenv
/usr/aset/masters/tune.low
/usr/aset/masters/tune.med
/usr/aset/masters/tune.high

환경 (Environment) File (asetenv) 수정

/usr/aset/asetenv file은 크게 두 부분으로 나뉜다.

사용자 설정 파라메터 section
내부 환경변수 section

사용자는 사용자설정 파라메터 섹션을 수정할 수 있다. 그러나 내부 환경변수 섹션의 설정값은 시스템 내부에서 사용되는 것으로서 바꾸면 안된다.
사용자설정 파라메터 섹션의 엔트리는 아래와 같은 경우에 수정하면 된다.

실행할 작업을 선택할때
체크리스트 작업 디렉토리를 지정할때
ASET 실행 스케줄을 지정할때
aliases 파일을 지정할때
NIS+ 테이블을 확장점검할 때

실행할 작업 선택

대부분의 시스템환경에서 보안시스템은 요구사항이 각각 다르다. 그러므로 해당 시스템에서는 불필요한 작업을 하나 혹은 몇 개정도 삭제해줄 필요가 생길 수 있다.

예를 들어, 모든 시스템이 firewall을 설치할 필요는 없을 것이다.
이럴때 asetenv 파일의 환경변수중 아래 예로 든 TASKS 부분을 수정하여 firewall에 관련된 파라메터를 삭제하면, firewall 없이 ASET을 높은 보안등급에서 실행시킬 수 있다.
여기서는 firewall이라는 환경변수를 삭제하면 된다. 그후 ASET을 수행시키면 firewall은 수행되지 않는다.

Checklist 작업 디렉토리 지정 : CHKLISTPATH

사용자 시스템 디렉토리를 선택하여 그 안에 있는 파일의 속성을 점검하는 시스템 파일 점검작업이다. 사용자는 checklist path 환경변수를 이용하여 어떤 디렉토리를 점검할 것인가를 결정할 수 있다.

CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH

CKLISTPATH_LOW 변수는 낮은 보안등급하에서 점검할 디렉토리를 지정하는 변수이다. 마찬가지로 CHKLISTPATH_MED와 CKLISTPATH_HIGH 환경변수는 각각 중간 및 높은 보안등급하에서 점검할 디렉토리를 지정한다.

가장낮은 보안등급이 적용된 디렉토리 리스트는 다음으로 높은 등급으로 적용된 디렉토리의 subset이 된다. 예를 들어 CKLISTPATH_LOW로 적용된 모든 디렉토리는CKLISTPATH_MED안에 모두 포함되며, CKLISTPATH_MED로 적용된것은 CKLISTPATH_HIGH안에 모두 포함된다.

모든 디렉토리에 대해서 광범위한 점검이 이루어지는 것은 아니다. ASET은 오로지
변수에 지정된 디렉토리에 한해서 점검을 실시한다. 물론 해당디렉토리의 서브디렉토리 역시 점검하지 않는다.

사용자는 변수를 바꾸어줌으로서 점검할 디렉토리를 추가하거나 삭제할 수 있다. 주의할 것은 매일 변동이 발생하지 않는 시스템파일에 한해서만 체크리스트를 적용해야한다는 것이다. 사용자의 홈디렉토리와 같이 수시로 변동되는 것은 체크리스트를 적용하지 않는것이 좋다.

ASET 실행 스케줄: PERIODIC_SCHEDULE
사용자는 interactive하게 ASET을 시작하거나 -p 옵션을 사용하여 지정된 시간에 ASET을 수행시킬 수 있다. 시스템의 요구사항이 적은 시간을 택하여 ASET을 이때마다 주기적으로 실행시킬 수 있다. ASET은 PERIODIC_SCHEDULE에게 자문을 구하여 작업을 얼마나 빈번하게 할지 그리고 언제 작업을 할지를 결정한다.

PERIODIC_SCHEDULE 형식은 crontab 엔트리의 형식을 따른다.

Aliases File 지정 : UID_ALIASES
UID_ALIASES 변수는 사용자 ID를 공유하는 aliases file을 지정한것이다. 기본적으로는 /usr/aset/masters/uid_aliases가 된다.

NIS+ Tables 확장점검: YPCHECK
YPCHECK 환경변수는 ASET이 시스템 구성파일테이블도 점검할 것인가를 결정해준다. YPCHECK은 부울린 변수이다. 사용자는 참값(true)인가 거짓값(false)인가만을 지정할 수 있다. 기본값은 false이며 이렇게 지정되면 NIS+ 테이블 점검은 이루어지지 않는다.

이 변수가 false로 지정되어 있다면 ASET은 로칼 시스템의 passwd 파일을 점검하지만 true로 지정되어 있으면 시스템 도메인의 NIS+ passwd 파일도 점검한다.

ASET이 자동적으로 local 테이블은 복구해주지만 NIS+테이블에 대해서는 잠재적인 문제점을 보고해줄 뿐 내용을 수정하지는 않는다.

aliases 파일을 지정 :UID_ALIASES
사용자 ID를 공유하는 목록인 aliases 파일을 지정하는 변수이다. /usr/aset/masters/uid_aliases 에 기본값이 들어있다.

Tune File 수정
ASET은 3개의 마스터 tune file (tune.low, tune.med, tune.high)을 사용하여 시스템파일의 접근을 쉽게할지 어렵게 할지를 설정한다. 이 마스터파일들은 /usr/aset/masters directory에 있으며 사용자의 환경에 따라 변경할 수 있다.
tune.low file은 기본적인 시스템 설정값에 적합한 사용권한을 설정한다. tune.med file은
tune.low에서 지정한것보다 사용권한이 더욱 제한을 받는다.

ASET으로 변경된 시스템 파일 복구
ASET이 처음 실행될때, 모든 시스템 파일의 원본은 그대로 저장해놓는다. /usr/aset 디렉토리에 있는 aset.restore 유틸리티는 이 파일들을 다시 ASET 실행전 상태인 원상태로 복구해준다. 이 유틸리티를 실행시키면 시스템파일에 적용된 변동사항이 모두 없어진다.

다음과 같은 경우 aset.restore를 실행하면 된다.
1) ASET을 실행시킨후 마음에 들지 않아, 변경된 시스템사항을 원상복구하고 싶을 때.

2) ASET을 일정기간 시험한 후, 다시 시스템 상태를 원상복구할 때.

3) 주요 시스템 기능이 올바르게 동작하지 않고, 그 원인이 ASET이라고 판단될 때.

만일 사용자가 ASET을 앞으로 계속 사용하지 않겠다면, 이미 root의 crontab에 추가되어 있는 aset 명령어를 cron 스케쥴링에서 제거해야 한다. cron을 이용하여 자동실행을 제거하는 것은 다음장에서 설명하겠다.

ASET 환경변수(Environmental variable)
ASET에서 사용되는 환경변수 및 기능은 다음과 같다.

ASETDIR : ASET 작업 디렉토리
ASETSECLEVEL : 보안등급
PERIODIC_SCHEDULE : 작업주기 스케줄
TASKS : 실행할 작업
UID_ALIASES : Aliases file
YPCHECK : NIS 나 NIS+에 대한 확장 점검
CKLISTPATH_LOW : 낮은 보안이 적용된 디렉토리 리스트
CKLISTPATH_MED : 중간 보안등급이 적용된 디렉토리 리스트
CKLISTPATH_HIGH : 높은 보안등급이 적용된 디렉토리 리스트

ASET에서 사용되는 환경변수 목록은 /usr/aset/asetenv 파일안에 있다.

ASETDIR과 ASETSECLEVEL 변수는 옵션사항이며 aset 명령어를 사용하는 사용자의 shell을 통해서만 설정이 가능하다. 다른 환경변수들은 파일을 편집하여 설정할 수 있다. 각 변수의 세부기능을 알아보자.

ASETDIR
ASET의 작업디렉토리를 나타낸다.
C shell 환경에서는 다음과 같이 입력한다.

% setenv ASETDIR pathname

Bourne shell이나 Korn shell에서는 다음과 같이 입력한다.

$ ASETDIR=pathname
$ export ASETDIR

위에서 pathname에는 ASET 작업디렉토리의 전체경로명을 적어준다.

ASETSECLEVEL
ASET 작업이 실행되는 보안등급을 지정해준다.

C shell에서는 다음과 같이 입력한다.

% setenv ASETSECLEVEL level

Bourne shell이나 Korn shell에서는 다음과 같이 입력한다.

$ ASETSECLEVEL=level
export ASETSECLEVEL

위에서 level은 다음중 하나로 지정할 수 있다.

low : 낮은 보안등급으로 설정시
med : 중간 보안등급으로 설정시
high : 높은 보안등급으로 설정시

PERIODIC_SCHEDULE
이중 인용부호로 둘러싸인 5개 필드의 값으로 구성되어 있으며 각 필드는 공백으로 분리한다.

"minutes hours day-of-month month day-of-week"

Periodic_Schedule 변수값

- minutes hours : ASET 시작시간 지정 (분은 0에서 59사이, 시는 0에서 23사이)

- day-of-month : ASET이 실행되어야 할 그 달의 일자를 지정 (1에서 31사이)

- month : ASET이 실행되어야 할 해당년도의 월을 지정 (1에서 12사이)

- day-of-week : ASET이 실행되어야 해당주의 요일을 지정 (0에서 6사이, 0은 일요일임)

TASKS
ASET이 실행되는 작업의 목록을 지정하는 변수이다. 기본값은 7개의 모든 작업 목록이 있는 상태이다.
TASKS="env sysconfig usrgrp tune cklist eeprom firewall"

UID_ALIASES
aliases file을 지정한다. 형식은 아래와 같다.

UID_ALIASES=pathname

위에서 pathname은 aliases file의 전체경로이다.

기본값은 다음과 같이 지정되어 있다.

UID_ALIASES=${ASETDIR}/masters/uid_aliases

YPCHECK
YPCHECK 변수는 시스템 테이블을 NIS 혹은 NIS+ 테이블로 확장시킨다. 부울린 변수로서 true 나 false 로 나타낸다. 기본값은 false이다.

YPCHECK=false

CKLISTPATH_level
세 개의 경로변수는 체크리스트 작업에 의해 점검될 디렉토리의 목록이다. 아래는 기본으로 지정된 것이며 각 등급에서의 변수의 관계를 보여준다.

ASET 파일 예

Tune Files

ASET은 3개의 tune file을 가지고 있다. 엔트리 포맷은 다음과 같다.

pathname 파일의 전체 경로명
mode 설정된 사용권한을 나타내는 5자리 숫자
owner 파일 소유자
group 파일 소유그룹
type 파일 형태

Aliases File
aliases file은 동일한 사용자 ID를 공유하는 aliases의 목록을 가지고 있다.
각 엔트리는 다음 형식으로 되어있다.

uid=alias1=alias2=alias3=...

uid : 공유하는 사용자 ID
alias : 사용자 ID를 공유하는 사용자계정

아래예는 sysadm 그리고 root가 공유하는 사용자 ID 0의 목록이다.

0=root=sysadm

ASET 실제 운영

ASET의 실행
ASET을 Interactive하게 실행하는 방법

superuser 권한을 갖는다.

aset 명령어를 이용, ASET을 interactive하게 수행시킨다.

level : 보안레벨 (기본값은 low).
pathname : ASET의 작업디렉토리 (기본값은 /usr/aset)

모니터화면에 ASET 실행로그가 나타났다면 ASET이 수행되는 것이다.
실행 로그 메시지는 어떤 작업이 현재 수행중인가를 보여준다.

아래예는 기본 작업디렉토리에서 낮은 보안등급으로 실행중인 ASET의 예이다.

ASET을 주기적으로 실행시키는 방법

superuser 권한을 갖는다.

주기적으로 ASET을 실행시킬 시간을 관리자가 선택하여 설정한다.

시스템 요구가 최소인 시간대에 ASET을 실행시키면 시스템 성능에 지장을 주지 않는다. /usr/aset/asetenv file 안에 있는 PERIODIC_SCHEDULE 환경변수를 수정해주면 ASET을 주기적으로 실행시킬 시간이 설정된다.

기본적으로는 매일 심야(사용자가 거의 없는 시간)에 실행되도록 설정되어 있다. 만일 자신의 시스템은 지구 반대편의 외국인들이 많이 사용하므로 밤보다는 낮이 더 한가하다면 낮시간으로 PERIODIC_SCHEDULE 변수를 수정해주면 된다.

aset 명령어를 이용하여 crontab 파일에 엔트리를 추가해준다.

# /usr/aset/aset -p

-p : /usr/aset/asetenv file에 있는 PERIODIC_SCHEDULE 환경변수는 crontab 파일을 실행시킨다. 이것이 실행되면서 ASET이 시작되는 것이다. 이 crontab 파일에 엔트리를 추가해준다.

ASET이 실행되는지를 검사하는 crontab 엔트리를 출력한다.

# crontab -l root

주기적으로 수행되는 ASET작업 중단하기

superuser 권한을 갖는다.

crontab file을 연다.

# crontab -e root

ASET entry를 삭제한다.

저장후 편집기를 빠져나간다.

ASET엔트리가 삭제되었는가를 확인한다.

# crontab -l root

서버에 ASET 리포트 모으기

superuser 권한을 갖는다.

서버에 디렉토리를 설정한다.

- /usr/aset directory로 이동한다.

sunny# cd /usr/aset

- rptdir directory를 생성한다.

sunny# mkdir rptdir

- rptdir directory로 이동하여 client_rpt directory를 생성한다.

sunny# cd rptdir
mars# mkdir client_rpt

- 리포트를 모으는 것이 필요한 각 클라이언트 컴퓨터에도 위의 내용을 그대로 반복한다.

아래 예는 all_reports라는 디렉토리와 study_rpt, sunny_rpt 서브디렉토리를 생성하는 과정이다.

mercury# cd /usr/aset
mercury# mkdir all_reports
mercury# cd all_reports
mercury# mkdir study_rpt
mercury# mkdir sunny_rpt

client_rpt directory들을 /etc/dfs/dfstab 파일에 추가한다.

이 디렉토리들은 read/write 속성만을 가져야 한다.

아래 엔트리들은 dfstab파일 안에 있는것들로서 읽기/쓰기 속성만을 가지고 공유된 것이다.

share -F nfs -o rw=study /usr/aset/all_reports/study_rpt
share -F nfs -o rw=sunny /usr/aset/all_reports/sunny_rpt

클라이언트가 사용할 수 있는 자원을 dfstab file안에 만든다.

# shareall

각 클라이언트에서 클라이언트 서브디렉토리를 서버로부터 마운트한다. 마운트 포인트는 /usr/aset/masters/reports이다.

# mount server:/usr/aset/client_rpt /usr/aset/masters/reports

/etc/vfstab file을 수정해주면 부팅때마다 디렉토리가 자동으로 마운트될 것이다.

Chapter 강좌를 마치며
며칠전 신문에서 눈길을 끄는 기사가 실렸다.

전세계 해커들이 한국의 서버를 자신의 경유지로 적극 활용하고 있다는 것이다.
한국의 서버는 침입하는데 그다지 어려움이 없으므로 서버내에 뒷문을 설치해두고 수시로 이를 이용하여 제 3국의 시스템 공격에 이용하는 셈이다.

공격을 당한 이가 침투경로를 역추적해보면 경유지로 이용당한 한국내 서버가 엉뚱하게 유력한 용의자가 된다.

필자는 작년과 재작년 두번에 걸쳐 외국기관으로부터 강력한 항의메일을 받은 적이 있다. 필자가 재직중인 대학내에 위치한 리눅스 서버가 자신들의 시스템에 불법 침입했거나 침입을 시도한 적이 있으므로 가만있지 않겠다는 것이었다. (FBI에 수사의뢰도 해둔상태였다고 한다)

대학의 영문 웹사이트에 본인이 system administrator로 기재되어 있어서 메일을 보내니 조사후 연락바란다는 내용이었다.

한건은 모 학과의 대학원생이 리눅스를 설치하여 운영중이던 PC였다. 자세히 알아보니 침입했다는 시간은 추석연휴기간이라 당사자는 고향에서 추석명절을 보내던 때였다.

침입기간을 전후로 한 리눅스 PC의 접속 로그파일을 해당기관에 보내주고 전후사정을 설명하여 무마를 시켰다.

또 한건 역시, 학생이 유닉스 학습을 위하여 리눅스를 설치해놓고는 방치해둔 PC였다. 이경우도 접속로그 파일을 해당기관에 보내준후 방치한 PC의 모든 서비스를 막도록 조치하였다. (접속 로그파일을 보내주는 이유는 그쪽에서 로그파일을 근거로, 알아서 범인을 색출하시라는 의미였다.)

근래들어 눈에 띄는 공격은 DDos와 같은 해킹툴을 이용, 수십대, 혹은 백여대의 시스템이 한곳을 타켓으로 정하여 동시에 random packet을 발사한다는 것이다. 공격을 받은 시스템은 파도처럼 밀려드는 패킷 공격에 맥을 못추고 다운되버린다.

작년에 미국에서는 'Usenix 보안 심포지움'이 열렸다. 발표주제 가운데 하나가 'DDoS -- Is There Really a Threat ? ' 였다. 그런데 주제발표 내용을 보면 시스템 공격의 진원지로서 몇개 국가를 꼽고있는데 Korea를 맨 앞에 놓아두었다.

위 내용을 확인하시려면 이곳을 누르세요.

타인이 버젓이 시스템에 침입하여 해킹 프로그램을 설치해놓은 후 공격명령을 내리면 시스템은 일사분란하게 명령을 따르는 것이다. 그 누명은 당연히 타인에게 점령되어 공격에 참여한 시스템이 쓰게 된다. 절대로 나의 일이 아니라고 생각치 말자. 어느날 자신의 시스템이 용의자가 되어 법적 조치 운운하는 살벌한 메일을 받게될 지도 모른다.

참고로 DDos 해킹툴이 자신의 시스템에 설치되어 있는가를 확인 할 수 있는 프로그램을 소개하겠다. 아래 링크를 누르면 이에 대한 상세한 설명과 함께 각 운영체제별로 필요한 해킹툴 탐지 프로그램을 다운로드받을 수 있다.

탐지 프로그램이 솔라리스 sparc 및 intel 버전 모두 친절하게 구비되어 있는것을 보면, 부주의하게 관리된 솔라리스 서버도 공격에 자주 동원되는듯 하다.

해당 site로 가보기

마지막으로 시스템 관리자가 한번쯤 읽어볼만한 내용을 담은 보안관련 싸이트 하나를 소개하고자 한다. 공격을 당한 시스템의 복구에 대한 내용을 포함하여 아주 광범위하고 상세한 보안관련 자료를 제공하는 곳이다.

해당 site로 가보기

100% 완벽한 보안솔루션은 참으로 어려울 것이다. 사실, 보안에 무감각하기까지 한것이 우리의 현실이다.

새로운 유닉스 운영체제를 설치했다면 그때부터 본인은 시스템 관리자가 된다. 조금만 주의를 기울이면 적은 노력으로 큰 재앙을 막을 수 있다. 그것이 아무리 작은 시스템이라도 관리자의 의무가 아닐까 싶다.

Information Technology & Insight

Solaris 기초에서 중급까지

티스토리툴바

Solaris 기초에서 중급까지

관련글

티스토리툴바