V9.5 까지는 OS 환경변수 설정하여 SSL을 구성하였으나, V9.7부터 DBM 구성변수로 SSL 설정 변수들이 포함되었다.

최근에 보안 사고로 인해 각종 보안 조치사항들이 취해지다 보니 DB 쪽의 SSL 구성 요건도 생기는 듯 하다.

 

오래된 버전에서는 SSL 관련 라이브러리를 별도 설치를 했었어야 되는 것 같은데, V9.7부터 DB2 설치 시 SSL 관련 라이브러리(IBM GSKit)들이 설치된다.

 

1. 설치 경로

    - DB2_엔진경로/gskit

    - 인스턴스_홈/sqllib/gskit

 

2. DB2 서버 쪽의 설정

   인스턴스 경로를 /db2user/inst97로 가정한다.

   (1) 환경변수 설정 (.profile)

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/db2user/inst97/sqllib/gskit/bin
export PATH=$PATH:/db2user/inst97/sqllib/gskit/bin

 

   (2) 인스턴스 홈에 SSL 디렉토리 생성

$> mkdir ~/SSL

 

  (3) 키 생성

$> cd ~/SSL
$>

gsk8capicmd_64 -keydb -create -db "key.kdb" -pw "password" –stash

 

  (4) 인증서 추가

$> gsk8capicmd_64 -cert -create -db "key.kdb" -pw "password" -label "DBCNI" -dn "CN=ssl.dbcni.com,O=dbcni,OU=dbcni db2,L=GANGNAM,ST=SEOUL,C=KR"

     - CN= common name

     - O = organization

     - OU= orgnaization unit

     - L = location

     - ST=state,province

     - C = country

     - DC= domain component

 

  (5) 인증서 추출

$> gsk8capicmd_64 -cert -extract -db "key.kdb" -pw "password" -label "DBCNI" -target "key.arm" -format ascii -fips

 

  (6) 유효성 검증

$> ls

      key.arm, key.crl, key.kdb, key.rdb, key.sth

 

   (7) DBM CFG 설정

db2 update dbm cfg using SSL_SVR_KEYDB /db2user/inst97/SSL/key.kdb
db2 update dbm cfg using SSL_SVR_STASH /db2user/inst97/SSL/key.sth
db2 update dbm cfg using SSL_SVR_STASH /db2user/inst97/SSL/key.sth
db2 update dbm cfg using SSL_SVR_LABEL DBCNI
db2 update dbm cfg using SSL_SVCENAME 50602

 

   (8) Registry 설정

db2set db2comm=ssl,tcpip

 

2. 클라이언트 설정

    (1) SSL 디렉토리 생성 (AIX 기준)

$> mkdir ~/SSL

     (주의) DB2 서버에서 생성된 key.arm 파일을 SSL 디렉토리 하위에 넣어 둘것

 

   (2)  key 디비 생성

$> cd ~/SSL
$> gsk8capicmd_64 -keydb -create -db "keyclient.kdb" -pw "password" -stash

 

   (3) 인증서 서명

$> gsk8capicmd_64 -cert -add -db "keyclient.kdb" -pw "password" -label "DBCNI" -file key.arm -format ascii -fips

 

   (4) dbm cfg 설정

db2 update dbm cfg using SSL_CLNT_KEYDB /db2/instance/db2inst/SSL/keyclient.kdb
db2 update dbm cfg using SSL_CLNT_STASH /db2/instance/db2inst/SSL/keyclient.sth


   (5) 카탈로스 설정

$> db2 catalog tcpip node 노드별명 remote IP server 50602 security ssl
$> db2 catalog db 디비명 as 디비SSL at node 노드별명
$> db2terminate

   (참고) TCPIP 통신 설정을 위해서는 카탈로그 작업이 한번 더 진행되어야 한다. 

 

   (6) 접속 테스트

$> db2 connect to 디비SSL user ID using PWD

 

DB2COMM 설정에 TCPIP도 있기 때문에 DB2 서버의 SVCENAME의 설정값을 통하여 TCPIP 방식의

DB 접속도 가능하다. (TCPIP 용 , SSL용 2가지 방식으로 통신이 됨)

 

참고로 V10.5의 경우 FixPack3a가 올라왔다. SSL관련하여 bug 발생으로 긴급 패치가 이뤄졌다.

이외 V10.1, V9.x 버전도 마찬가지로 보안관련 패치가 된 것으로 보인다.

SSL 설정 작업 시 각 버전의 APAR 등을 참고해야 될 것 같다.

'Note' 카테고리의 다른 글

[관리] 메모리 부족  (0) 2014.11.21
[보안] authentication 과 srvcon_auth  (0) 2014.07.14
[관리] db2gcf  (0) 2014.05.19
[복구] 경로재지정 복구  (0) 2014.04.15
[관리] Backup Pending 풀기  (0) 2014.03.31

Linux 나 AIX 환경이 아닌 unix 환경에서는 kernel parameter 값을 설정해 주어야 한다.

( Linux 및 AIX 경우는 DB2 실행 시 동적으로 kernel parameter 값이 설정되는 것으로 알고 있다)

 

Solaris 나 HP-UX 환경에서 kernel parameter 값을 설정하지 않아도 설치 및 인스턴스 구성, 인스턴스 실행 시 오류가 발생하지 않아 설정하지 않는 경우가 종종 있다.

이런 경우 특정 작업을 하다가 오류가 발생해서 원인이 못찾고 헤매게 되는 경우가 있다.

 

보안 상 고객사의 진단로그 메시지들을 메모하지 못하고 나와서 그 오류 메시지를 글에 넣을 수는 없지만,

기억나는 오류 코드는 SQL0902C, 디바이스 부족 정도였던 것 같다.

 

db2diag.log를 보면서 맨 처음 의심이 드는 것은 restore 시 필요한 경로의 disk 가용 공간이 부족해서 생긴 문제로 보여, disk 가용 공간을 확인해 봤지만 문제점은 찾을 수 없었다. (고객사의 문제는 restore 시 SQL0902C 에러로 실패하면서 작업 진행을 하지 못하는 상황이였다)

나중에 로그의 특정 메시지를 통해서 kernel parameter 를 설정하지 않아서 생긴 것으로 원인을 파악하게 되었다.

 

kernel parameter 관련 technote를 소개해 본다.

 

1. the db2diag.log is reporting an ENOSPC (28) error message

    URL: http://www-01.ibm.com/support/docview.wss?uid=swg21407281

 

2009-11-15-16.18.55.210069+330 E25334773A223 LEVEL: Error (OS)
PID : 47785 TID : 4198246823968PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-17762 APPID: 9.142.38.82.23748.034005560721
AUTHID : DB2INST1
EDUID : 75 EDUNAME: db2agent (DB1) 0
FUNCTION: DB2 UDB, oper system services, sqloNLCKLock, probe:150
MESSAGE : ZRC=0x8300001C=-2097151972
CALLED : OS, -, semget

 

2.  SQL0902C A system error (reason code = "") occurred.  Subsequent SQL statements cannot be processed.

     URL: http://database.ittoolbox.com/groups/technical-functional/db2-l/sql0902c-a-system-error-3974926

 

2011-01-11-11.48.54.138210-300 I29339688A484 LEVEL: Error
PID : 21872 TID : 1 PROC : db2agent (VPLANDB) 0
INSTANCE: db2vplan NODE : 000
APPHDL : 0-40 APPID: 128.209.72.162.45433.1101111648
AUTHID : VPLANADM
FUNCTION: DB2 UDB, buffer pool services, sqlbinit, probe:550
MESSAGE : ZRC=0x850F0081=-2062614399=SQLO_SSEM_EXCEED_MAX
"Requesting too many semaphores"
DIA8336C Requested too many semaphores

 

3. Severe system error occurs with SQLO_NORES, DIA8336C and DIA8532C messages in db2diag.log

     URL: http://www-01.ibm.com/support/docview.wss?uid=swg21406633

2009-10-08-11.35.20.600704-320 I5639725A439 LEVEL: Severe
PID : 25196 TID : 7 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000
EDUID : 7 EDUNAME: db2ipccm 0
FUNCTION: DB2 UDB, global services, sqzEDUObj::StartEDU, probe:10
RETCODE : ZRC=0x870F00F2=-2029059854=SQLO_NORES

 

Solaris 나 HP-UX 환경에서는 꼭 kernel parameter를 설정하고 DB2 설치 작업을 하는 것이 좋다.

db2gcf 명령어는 이중화하는 경우에 주로 사용된다.

V9.5부터 TSA (Tivoli System Automation) 클러스터가 도입이 된 후 이중화 관련 tsa의 script를 보면 db2 제어를 위해 db2gcf가 사용됨을 확인할 수 있다.

 

인스턴스 시작(u), 중지(d), 상태(s) 를 확인할 수 있고, 강제로 자원을 정리하는 k 옵션도 제공한다.

Unix 환경이나 Linux 환경에서 DB2 인스턴스가 패닉 상태에 놓인 경우 db2stop 명령어로 인스턴스가 중지되지 않아, db2_kill 이라는 명령어를 사용한다. 그러나 윈도우 환경에서는 db2_kill 이라는 명령어는 제공되지 않는다.

 

윈도우 작업관리자에서 정리를 할 수 밖에 없기 때문에 db2_kill 같은 명령어의 필요성이 느껴질 수 있다.

이때 db2gcf –k 를 사용하면 db2_kill과 같은 효과를 얻을 수 있으니 다급한 상황이 발생한 경우는 db2gcf 를 사용하는 것이 도움이 될 듯 하다.

 

주의 사항은 DB 활성화 시  crash recovery가 진행되므로, 만약의 경우를 대비하여 복구에 필요한 백업 이미지, 아카이브 로그 등을 확인 후 작업해야 할 것이다.

 

참고: http://www-01.ibm.com/support/knowledgecenter/?lang=ko#!/SSEPGG_10.5.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0010986.html?cp=SSEPGG_10.5.0%2F3-5-2-6-56

'Note' 카테고리의 다른 글

[보안] authentication 과 srvcon_auth  (0) 2014.07.14
[보안] SSL 설정  (0) 2014.06.18
[복구] 경로재지정 복구  (0) 2014.04.15
[관리] Backup Pending 풀기  (0) 2014.03.31
[구성] Federation MS-SQL Server  (0) 2014.03.20

+ Recent posts