[Solaris] 인터넷에서 모은 SUN시스템 관리 관련 팁

시스템 관리자들은 다년간의 경험에서 획득한 나름대로의 요령과 팁들을 갖추고 있기 마련이다. 이러한 지식을 개인의 노하우로 국한시키지 않고 널리 공개해 다른 시스템 관리자들과 공유한다면 그 가치가 더욱 커질 것이다. 이번 Sun Lesson 코너에서는 시스템 관리 및 운영, 성능, 보안과 관련해 인터넷에서 모은 팁들을 소개한다.

시스템 관리

● 시동 스크립트의 디버깅

셸 스크립트의 명령어 실행 시 모든 셸 스크립트의 앞에 set -x 명령어를 추가하면, 모든 명령의 진행 상태를 확인할수 있다. 이것은 특히 시스템 시동(startup) 스크립트에서 유용하다. 즉, 부팅 시 시스템이 중단되는 경우에 도움이 된다.

● 시스템 상태 스크립트의 활용

시스템에 문제가 있는 경우 system status 셸 스크립트를 활용한다. 예를 들어, 시스템이 메모리가 부족한 상태에서 실행되거나 중단되는 경우 <리스트 1>과 같이 시스템 상태를 캡처하는 스크립트를 실행하면, 원인 분석에 도움이 된다.
여기서 iostat나 vmstat에서 사용된 2 값은 명령에 대한 반복횟수를 나타낸다. 특히 ‘2’라는 값에 주의해야 한다. 왜냐하면 첫 번째 값은 시스템이 마지막으로 재부팅된 이후의 변화된 값을 모두 표현하므로 실제로 유효한 값은 두 번째 값부터이기
때문이다.

● 수정 전의 저장

시스템 파일을 변경하기 전에 백업 카피를 만든다. 이때는 변경한 사람의 신원과 변경 날자를 포함하는, 표준 이름 부여원칙을 이용한다. 예를 들면, 다음과 같다.

# cp /etc/vfstab /etc/vfstab.pbg.250599


● 루트 디스크를 백업 디스크로 자동 카피

루트 디스크를 백업 디스크에 자동으로 카피한다. <리스트 2>는 샘플 스크립트이다. 단, 이 스크립트를 활용할 때는 반드시 실제 사용 환경에 맞도록 변경해 사용해야 한다.

● RAID 컨트롤러 기반 스토리지에서 캐시 상태의 확인

SPARCStorage 어레이와 RSM 2000(A3000) 및 A3500 스토리지에서 예고 없이 캐시 메모리의 기능이 억제되는 경우가 있다. 따라서 ssaadm과 rm6를 사용해 이들 스토리지 유닛의 캐시 상태를 정기적으로 확인한다. 또 일종의 버그로,
RSM 2000에서 캐시가 작업중인 경우에도 기능이 중단되었다는 리포트가 나오는 경우도 있다. 그러므로 더욱 더 캐시의 활동 상태를 잘 감시해야 한다.

● SWAP 공간이 부족한 경우

가끔씩 SWAP 공간 부족으로 인해 소프트웨어가 동작하지 않는 경우 아래와 같은 방법으로 SWAP 공간을 늘려 사용한다.

% su
password: *******
# mkfile 10m /SWAP-file
# swap -a /SWAP-file
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t3d0s1 32,25 16 262640 59808
# mkfile 10m /SWAP-file
# swap -a /SWAP-file
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t3d0s1 32,25 16 262640 59888
/SWAP-file - 16 20464 20272


그리고 SWAP-file을 SWAP 공간에서 제거할 경우 아래와 같이 하면 된다.

# swap -d /SWAP-file
# swap -l swapfile dev swaplo blocks free
/dev/dsk/c0t3d0s1 32,25 16 262640 59888


● 미궁에 빠지면 truss 사용

프로세스가 중단되거나 제대로 통제가 안되면, truss를 사용해 문제의 원인을 알아본다. 일례로, backoutpatch가 중단되어 즉시 truss를 이용했다. 그러자 CD-ROM과 연관된 곳에서 멈추었고 CD를 빼자 문제가 해결되었고 그 패치도 제거되었다.

● 셸 히스토리의 동기화

로그인 간의 csh 디렉토리 스택을 관리하고 이를 여러 윈도에서 자동으로 공유하기 위해 <리스트 3>과 같은 에일리어스를 사용한다. 이것은 .cshrc에도 해당된다. 내부적으로 디렉토리 스택을 지원하지 않는 구형 csh와
ksh에도 유사한 코드를 사용할 수 있다.

● 시스템 서비스 중지는 주의깊게

확신하기 전에는 원하는 작업을 수행하기 위해 함부로 'etc/init.d/something stop’을 해서는 안된다.

# cd /etc/init.d
# grep -l stop * | wc -l 19
# ls -l | wc -l 43


시스템 운영

● 시스템마다 주요 정보 시트 작성

다음 항목의 정보 시트는 재난 발생 시 큰 도움이 될 것이다.

호스트네임
시리얼 넘버
서비스 계약 번호
서비스 계약 조건
서비스 계약 문의처
부트 디스크의 논리적 디바이스 네임
부트 디스크의 물리적 디바이스 네임
대안 부트 디스크 정보
현재의 패치 클러스터
prtdiag 아웃풋의 카피
네트웍 구성 정보(어드레스, 라우트, dns, nis)
백업 테이프 위치
복구 지시서

원칙

시스템 관리의 황금 법칙을 소개한다(역설적으로 새겨들어야 하는 것도 포함).

■ 미심쩍으면 재부팅한다.
■ 적절하게 예상한다. 즉, 언제 다운될지, 언제 한계에 부딪힐지, 어떻게 문제가 터질지 그리고 그 결과가 어떨지를 예측한다.
■ 문제가 생기면, 케이블을 점검한다.
■ 모든 프로젝트는 예상 기간보다 2배 더 걸린다. 여유있게
■ 계획을 세워라.
■ 테스트가 끝나기 전에는 완료된 것이 아니다.
■ 어떤 경우에는, 문서화되기 전에는 완료된 것이 아니다.
■ 금요일(토요일)에는 어떤 것도 변경하지 말라.
■ 앞의 법칙은 무시하더라도, 휴가 떠나기 전에는 절대
■ 변경해서는 안된다.
■ 이것은 마이크로소프트 제품이 아니다. 재인스톨을 다시 한다고 문제가 해결되지는 않는다.
■ 가능한 한 디폴트를 사용한다.
■ 중요한 변경 작업 전에는 백업을 만든다. 시스템 변경 전에는 전체 시스템을, 파일 변경 전에는 파일을 백업한다.
■ 로그 파일을 정기적으로 점검한다. 아니면 점검을 자동화한다. 작동하는 걸 직접 본 적이 없다면, 아마 작동이 안되는 것일 것이다.
■ 계속해서 발생한 문제의 진압 작업을 펼치고 있다면, 그 문제에 대한 원인들을 찾아내야 한다.
(사람들이 문제를 깨닫기 전에 미리 알아서 문제를 해결해 버린다면, 당신(시스템 관리자)의 능력을 의심하는 사람들이 결코 그 문제를 부풀려 말하지는 않을 것이다(누군가가 문제의 심각함을 알 때 멋지게
해결하라).
■ 자동 툴(tkined, Big Brother, SNMP 등)로 시스템을 자세히 모니터한다. 수작업으로는 하지 말라.
■ 사용자가 변경 사항을 테스트해야 한다면, 오전 10시 이후에 하도록 한다. 즉 사용자가 잠에서 완전히 깼을때. 그리고 시스템 실행에 조금이라도 문제가 있을 것 같으면 사용자 퇴근 즉시 하도록 한다(그래서 문제가
복잡해지면 밤새 해결한다). 이렇게 하면, 사람들이 당신의 혼란 상태를 보지 못할 것이고 모든 문제를 해결할 수 없다는 점에 대해 불만을 나타내지도 못할 것이다.

성능

● /tmp로 성능 향상

/tmp는 가상 메모리(RAM 디스크 같은)에서 만들어지며 성능이 탁월하다. 임시 파일은 이곳에 만들어지며, 재부팅하면 /tmp 밑의 모든 내용은 없어진다. /usr/tmp는 표준 파일시스템으로 재부팅에 구애받지 않고 파일을 보관해야 할 때
이용되는 저장 공간이다. 특히 보관 장소가 적절하게 정해지지 않은 파일의 보관 장소로 이용된다.

● Solaris 2.6에서 개선된 iostat

Solaris 2.6 이상에서는 iostat에 새로운 -n 옵션을 사용한다. 이렇게 하면, 이전의 sd 네임보다 실제적인 디바이스 네임을 얻을 수 있다.

보안

● 루트 로그인 소스와 메소드의 제약

/etc/default/login에서 CONSOLE= 라인을 언코멘트함으로써 시스템 콘솔 외의 모든 곳에서 루트 로그인의 기능을 억제한다. /etc/ftpusers에 root(그리고 다른
시스템 어카운트들)를 추가해 ftp 루트 로그인을 억제한다.

● 모든 범주의 보안 침해 방지

/etc/system에 noexec_user_stack 라인을 추가한 다음 재부팅해 모든 스택 오버플로 보안 침해를 막을 수 있다.

● 시동 스크립트 보안성 증대

몇몇 파일 액세스 보안 문제는 부트 스크립트 처음에 간단한 ‘umask 022’만 추가해도 해결할 수 있다. 이것을 추가해도 부트 스크립트가 멈추는 경우는 전혀 없다