Sun Java System Messaging Server 6.3 관리 설명서

20장 메시지 저장소 관리

이 장에서는 메시지 저장소와 메시지 저장소의 관리 인터페이스에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

20.1 개요

메시지 저장소는 특정 Messaging Server 인스턴스에 대한 사용자 메일함을 포함합니다. 메일함, 폴더 및 로그 파일 수가 늘어나면 메시지 저장소의 크기가 늘어납니다. 메일함의 크기(디스크 할당량)를 제한하고 허용되는 총 메시지 수의 한도를 지정하며 저장소의 메시지에 대한 에이징 정책을 설정하여 저장소 크기를 제어할 수 있습니다.

시스템에 다른 사용자를 추가하면 디스크 저장소 요구 사항이 증가합니다. 서버가 지원하는 사용자 수에 따라 메시지 저장소는 하나 또는 여러 개의 물리적 디스크가 필요할 수 있습니다. 이러한 추가 디스크 공간을 시스템에 통합하는 방법에는 두 가지가 있습니다. 가장 쉬운 방법은 메시지 저장소 분할 영역을 추가하는 것입니다( 20.10 메시지 저장소 분할 영역 구성 참조).

마찬가지로 여러 호스트된 도메인을 지원하는 경우 하나의 큰 도메인에서 서버 인스턴스를 전담하도록 할 수 있습니다. 이 구성을 사용하면 특정 도메인에 대한 저장소 관리자를 지정할 수 있습니다. 또한 다른 분할 영역을 추가하여 메시지 저장소를 확장할 수 있습니다.

Messaging Server는 메시지 저장소의 관리를 위해 표 20–1에 설명된 일련의 명령줄 유틸리티를 제공합니다. 이러한 유틸리티 사용에 대한 자세한 내용은 20.11 메시지 저장소 유지 관리 절차 수행Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

표 20–1 메시지 저장소 명령줄 유틸리티

유틸리티 

설명 

configutil

저장소의 구성 매개 변수를 설정 및 수정합니다. 

deliver

메일을 IMAP 또는 POP 메일 클라이언트가 액세스할 수 있는 메시지 저장소로 직접 전달합니다. 

hashdir

특정 사용자의 메시지 저장소를 포함하는 디렉토리를 식별합니다. 

imsconnutil

메시지 저장소의 사용자 액세스를 모니터합니다. 

imexpire

관리자가 지정한 기준(예: 기간)에 따라 메시지 저장소에서 메시지를 자동으로 제거합니다. 

iminitquota

LDAP 디렉토리에서 할당량 제한을 다시 초기화하고 사용 중인 디스크 공간을 다시 계산합니다. 

imsasm

사용자 메일함의 저장과 복구를 처리합니다. 

imsbackup

저장된 메시지를 백업합니다. 

imsexport

Messaging Server 메일함을 UNIX /var/mail 형식 폴더로 내보냅니다.

imsrestore

백업된 메시지를 복원합니다. 

imscripter

IMAP 서버 프로토콜 스크립트 도구입니다. 명령이나 명령 시퀀스를 실행합니다. 

mboxutil

메일함을 나열, 작성, 삭제, 이름 변경 또는 이동을 수행하고 할당량 사용을 보고합니다. 

mkbackupdir

백업 디렉토리를 만들어 메시지 저장소의 정보와 동기화합니다. 

MoveUser

한 메시징 서버에서 다른 메시징 서버로 사용자의 계정을 이동합니다. 

imquotacheck

메시지 저장소의 각 사용자에 대한 총 메일함 크기를 계산하고 이 크기를 지정된 할당량과 비교합니다. 현지화된 버전의 imquotacheck 알림은 % 및 $ 기호를 잘못 변환합니다. 인코딩을 수정하려면 메시지 파일에서 모든 $와 %를 각각 \24와 \25로 바꿉니다.

readership

공유 IMAP 폴더에서 readership 정보를 수집합니다. 

reconstruct

손상된 메일함을 다시 구성합니다. 

stored

백그라운드 및 일상 작업을 수행하고 디스크에 저장된 메시지를 정리 및 삭제합니다. 

20.2 메시지 저장소 디렉토리 레이아웃

그림 20–1에는 서버 인스턴스의 메시지 저장소 디렉토리 레이아웃이 나와 있습니다. 메시지 저장소는 메일함 내용을 신속하게 액세스할 수 있도록 설계되었습니다. 저장소 디렉토리는 표 20–2에 설명되어 있습니다.

그림 20–1 메시지 저장소 디렉토리 레이아웃

이 그림은 메시지 저장소 디렉토리 레이아웃을 보여 줍니다.

메시지 저장소는 여러 메일함 데이터베이스 및 사용자 메일함으로 구성됩니다. 메일함 데이터베이스는 사용자, 메일함, 분할 영역, 할당량 및 기타 메시지 저장소 관련 데이터에 대한 정보로 구성됩니다. 사용자 메일함은 사용자의 메시지와 폴더를 포함합니다. 메일함은 전적으로 메시지 저장소를 저장하는 디스크 분할 영역의 한 영역인 메시지 저장소 분할 영역에 저장됩니다. 자세한 내용은 20.10 메시지 저장소 분할 영역 구성을 참조하십시오. 메시지 저장소 분할 영역은 디스크 분할 영역과 다르지만 유지 관리가 용이하도록 각 메시지 저장소 분할 영역에 대해 하나의 디스크 분할 영역을 가지는 것이 좋습니다.

INBOX와 같은 메일함은 store_root에 위치합니다. 예를 들어, 샘플 디렉토리 경로는 다음과 같을 수 있습니다.

store_root/partition/primary/=user/53/53/=mack1

아래 표에서는 메시지 저장소 디렉토리를 설명합니다.

표 20–2 메시지 저장소 디렉토리 설명

위치 

내용/설명 

msg-svr-base

기본값: /opt/SUNWmsgsr

서버 프로그램, 구성, 유지 관리 및 정보 파일을 포함하는 Messaging Server 시스템상의 디렉토리입니다. 

store_root

msg-svr-base/data/store

메시지 저장소의 최상위 디렉토리입니다. mboxlist, userpartition 하위 디렉토리를 포함합니다.

./store.expirerule

자동 메시지 제거 규칙(만료 규칙)을 포함합니다. 이 선택적 파일의 위치는 다를 수 있습니다. 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법을 참조하십시오.

store_root/dbdata/snapshots

stored가 정기적으로 만드는 메시지 저장소 데이터베이스 백업 스냅샷입니다.

store_root/mboxlist/

메일함 및 할당량 관련 정보를 저장하는 메일함 데이터베이스(Berkeley DB)를 포함합니다. 

folder.db는 메일함이 저장된 분할 영역의 이름, ACL, store.idx의 일부 정보 복사본 등을 비롯하여 메일함에 대한 정보를 포함합니다. folder.db에는 각 메일함별로 한 개의 항목이 있습니다.

quota.db는 할당량 및 할당량 사용에 대한 정보를 포함합니다. quota.db에는 각 사용자별로 한 개의 항목이 있습니다.

lright.db는 acl 조회 권한별 폴더에 대한 색인입니다.

peruser.db는 사용자별 플래그에 대한 정보를 포함합니다. 이 플래그는 특정 사용자가 메시지를 보았거나 삭제했는지 여부를 나타냅니다.

subscr.db는 사용자 가입에 대한 정보를 포함합니다.

store_root/session/

활성 메시지 저장소 프로세스 정보를 포함합니다. 

store_root/user/

사용되지 않습니다. 

store_root/partition/

메시지 저장소 분할 영역을 포함합니다. 기본 primary 분할 영역이 만들어집니다. 정의하는 다른 모든 분할 영역을 이 디렉토리에 넣습니다.

store_root/partition/primary/=user/

분할 영역의 하위 디렉토리에 모든 사용자 메일함을 포함합니다. 메일함은 빠른 검색을 위해 해시 구조에 저장됩니다. 특정 사용자의 메일함을 포함하는 디렉토리를 찾으려면 hashdir 유틸리티를 사용합니다.

.../=user/hashdir/ hashdir/userid /

아이디가 userid인 사용자에 대한 최상위 메일 폴더이며,사용자의 받은 메일함입니다. 기본 도메인의 경우 useriduid이고 호스트된 도메인의 경우 useriduid@domain입니다. 받는 메시지는 이 메일 폴더로 전달됩니다.

.../userid/folder

Messaging Server의 사용자 정의 폴더입니다. 

.../userid/store.idx

/userid/ 디렉토리에 저장된 메일에 대해메시지 수, 이 메일함에 사용된 디스크 할당량, 메일함이 마지막으로 추가된 시간, 메시지 플래그, 헤더 및 MIME 구조를 비롯한 각 메시지의 변수 길이 정보, 각 메시지의 크기 등과 같은 정보를 제공하는 색인입니다. 이 색인은 또한 각 사용자에 대한 mboxlist 정보와 할당량 정보의 백업 복사본을 포함합니다.

.../userid/store.usr

폴더에 액세스한 사용자 목록을 포함합니다. 목록의 각 사용자에 대해 사용자가 폴더에 액세스한 마지막 시간, 사용자가 본 메시지 목록 및 사용자가 삭제한 메시지 목록에 대한 정보를 포함합니다. 

.../userid/store.sub

사용자 가입에 대한 정보를 포함합니다. 

.../userid/store.exp

정리되었지만 디스크에서 제거되지는 않은 메시지 파일의 목록을 포함합니다. 이 파일은 정리된 메시지가 있는 경우에만 나타납니다.  


.../userid/nn/
or
.../userid/folder/nn/

nnmessage_id.msg 형식의 메시지를 포함하는 해시 디렉토리입니다. nn은 00에서 99 사이의 숫자가 될 수 있으며 message_id도 숫자입니다. 예: 1에서 99 사이의 메시지는 .../00 디렉토리에 저장됩니다. 첫 번째 메시지는 1.msg이고 두 번째 메시지는 2.msg, 세 번째 메시지는 3.msg입니다. 100에서 199 사이의 메시지는 01 디렉토리에 저장되고 9990에서 9999 사이의 메시지는 99 디렉토리에 저장되며 이와 같이 10000에서 10099 사이의 메시지는 00 디렉토리에 저장됩니다.

20.2.1 유효한 폴더 이름 및 유효하지 않은 폴더 이름

다음은 유효한 IMAP 폴더 문자와 유효하지 않은 IMAP 폴더 문자입니다.

유효한 IMAP 폴더 문자: <space> ! " # $ & ' ( ) + , - . / 0-9 : ; < = > @ A-Z [ \ ] ^ _ ` a-z { | } ~

유효하지 않은 IMAP 폴더 문자: % * ?

public/이라는 폴더와 같이 특정 문자 순서가 거부될 수도 있습니다. 또, 이 제한은 영어 로켈을 사용하는 경우에 적용됩니다. 일본어 등의 다른 언어에서는 인코딩된 문자 세트를 사용합니다.

20.3 메시지 저장소에서 메시지를 제거하는 방법

메시지는 메시지 저장소에서 다음 세 단계를 거쳐 제거됩니다.

  1. 삭제. 클라이언트가 메시지 플래그를 삭제로 설정합니다. 이 시점에 메시지가 제거 표시되지만 클라이언트는 삭제 플래그를 제거하여 메시지를 복원할 수 있습니다. 두 번째 클라이언트가 있을 경우 삭제된 플래그는 바로 두 번째 클라이언트부터 표시되지 않을 수 있습니다. configutil 매개 변수 local.imap.immediateflagupdate를 설정하여 즉시 플래그 업데이트를 사용할 수 있습니다.

  2. 정리. 메일함에서 메시지가 제거됩니다. 기술적으로는 메시지가 메시지 저장소 색인 파일 store.idx에서 제거되는 것입니다. 메시지 자체는 여전히 디스크상에 존재하지만 메시지가 정리되고 나면 클라이언트가 더 이상 메시지를 복원할 수 없습니다.

    만료는 특수한 경우의 정리를 의미합니다. 메시지 크기, 기간 등과 같은 관리자가 정의한 일련의 제거 기준을 따르는 메시지가 정리됩니다. 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법을 참조하십시오.

  3. 제거. imexpire 유틸리티는 기본적으로 매일 오후 11시에 정리된 메시지를 디스크에서 제거합니다. 이는 메시지 만료 일정을 제어하는 local.schedule.expire와 제거 유예 기간(그 전까지 메시지가 제거되지 않는 기간)을 제어하는 store.cleanupage로 구성할 수 있습니다. 오래된 버전의 MTA 로그 파일을 정리하는 imsimta purge 명령 및 configutil 매개 변수 local.schedule.purge와는 다릅니다.

20.4 저장소에 대한 관리자 액세스 지정

메시지 저장소 관리자는 사용자 메일함을 보고 모니터링하며 메시지 저장소에 대한 액세스 제어를 지정할 수 있습니다. 저장소 관리자는 모든 서비스(POP, IMAP, HTTP 또는 SMTP)에 대한 프록시 인증 권한을 가지므로 모든 사용자의 권한을 사용하여 모든 서비스에 인증될 수 있습니다. 이러한 권한을 사용하여 저장소 관리자는 저장소 관리를 위한 일정한 유틸리티를 실행할 수 있습니다. 예를 들어, 저장소 관리자는 MoveUser를 사용하여 사용자 계정과 메일함을 특정 시스템에서 다른 시스템으로 이동할 수 있습니다.

이 절에서는 Messaging Server 설치의 메시지 저장소에 대한 저장소 권한을 허가하는 방법에 대해 설명합니다.


주 –

다른 사용자가 저장소에 대한 관리자 권한을 가질 수도 있습니다. 예를 들어, 일부 관리자가 이러한 권한을 가질 수 있습니다.


다음 하위 절에 설명된 대로 관리자 작업을 수행할 수 있습니다.

Procedure관리자 항목 추가 방법

  1. 명령줄: 명령줄에서 관리자 항목을 추가하려면 다음을 수행합니다.

    configutil -o store.admins -v "adminlist"

    여기서 adminlist는 공백으로 구분된 관리자 아이디 목록입니다. 여러 관리자를 지정할 경우 목록을 따옴표로 묶어야 합니다. 또한, 관리자는 서비스 관리자 그룹의 구성원이어야 합니다(LDAP 사용자 항목에서 memberOf: cn=Service Administrators,ou=Groups,o=usergroup).

Procedure관리자 항목 수정

  1. 명령줄. 명령줄에서 메시지 저장소 관리자 UID 목록의 기존 항목을 수정하려면 다음을 수행합니다.


    configutil -o store.admins -v "adminlist"

    여기서 adminlist는 공백으로 구분된 관리자 아이디 목록입니다. 여러 관리자를 지정할 경우 목록을 따옴표로 묶어야 합니다. 또한, 관리자는 서비스 관리자 그룹의 구성원이어야 합니다(LDAP 사용자 항목에서 memberOf: cn=Service Administrators,ou=Groups,o=usergroup).

Procedure관리자 항목 삭제

  1. 명령줄. 명령줄에서 저장소 관리자를 삭제하려면 다음과 같이 관리자 목록을 편집할 수 있습니다.


    configutil -o store.admins -v "adminlist"

    여기서 adminlist는 공백으로 구분된 관리자 아이디 목록입니다. 여러 관리자를 지정할 경우 목록을 따옴표로 묶어야 합니다. 또한, 관리자는 서비스 관리자 그룹의 구성원이어야 합니다(LDAP 사용자 항목에서 memberOf: cn=Service Administrators,ou=Groups,o=usergroup).

20.4.1 관리자에 의한 경우를 제외하고 메일함 삭제 또는 이름 바꾸기 차단

관리자에 의한 경우를 제외하고 일부 메일함을 삭제하거나 수정하는 것을 차단할 수 있습니다. 다음 절차에서 이 작업 방법에 대해 설명합니다. 관리자가 아닌 사람이 보호된 메일함을 삭제 또는 수정하거나 이름을 바꾸려고 하면 mailbox is pinned라는 오류 메시지가 표시됩니다.

다음 형식을 사용하여 local.store.pin configutil 변수를 설정합니다.


configutil -o local.store.pin -v "mailbox1"%"mailbox2"%"mailbox 3"

여기서 mailbox1, mailbox2mailbox 3은 보호할 메일함이고(메일함 이름에 공백을 사용할 수 있음) %는 각 메일함 사이의 구분자입니다.

20.5 공유 폴더 정보

그룹 또는 공유 폴더는 지정된 사용 권한에 따라 다른 사용자와 그룹이 읽고 삭제하며 메시지를 추가할 수 있다는 점을 제외하고 다른 모든 메일 폴더와 같습니다. 일반적인 끌어서 놓기, 시브(Sieve) 필터 또는 다음 형식으로 직접 메시지를 보내 공유 폴더에 메시지를 추가할 수 있습니다. uid+folder@domain.

아래의 예는 carol.fanning@siroe.com에서 소유한 개인 공유 폴더, crafts_club으로 전자 메일을 보내기 위한 주소입니다.

carol.fanning+crafts_club@siroe.com

다음 예는 tennis@siroe.com이라는 공개 공유 폴더로 전자 메일을 보내기 위한 주소입니다.

public+tennis@siroe.com

공유 폴더는 특정 주제에 대한 지속적인 전자 메일 대화를 시작, 공유 및 보관하는 데 유용합니다. 예를 들어, 한 그룹의 소프트웨어 개발자가 특정 프로젝트의 개발을 논의하기 위해 mosaic_voices라는 공유 폴더를 만들 수 있습니다. 메시지를 보내거나 mosaic_voices 폴더에 넣으면 공유 폴더에 대한 사용 권한이 있는 모든 사용자(개별 주소나 그룹 주소로 사용 권한을 추가할 수 있음)가 이 메일함을 열고 메시지를 읽을 수 있습니다.

공유 폴더는 사용자의 메일함에서 Shared Folders라는 폴더 아래에 표시됩니다. 예를 들면 다음과 같습니다.

그림 20–2 메일 클라이언트에서 본 공유 메일 폴더 목록의 예

이 그림은 클라이언트 공유 메일 폴더 목록의 예를 보여 줍니다.

공유 폴더에는 다음 두 종류가 있습니다.

일반적으로 공유 폴더는 특정 메시지 저장소의 사용자만 사용할 수 있습니다. 그러나 Messaging Server에서는 여러 메시지 저장소에서 액세스할 수 있는 특수한 공유 폴더를 만들 수 있습니다. 이러한 폴더를 분산 공유 폴더라고 부릅니다. 자세한 내용은 20.6.4 분산 공유 폴더 설정을 참조하십시오.

20.6 공유 폴더 작업

이 절에서는 공유 폴더와 관련된 다음 관리자 작업에 대해 설명합니다.

Procedure개인 공유 폴더의 공유 속성 지정

  1. 개인 공유 폴더는 사용자가 만듭니다.

    많은 메일 클라이언트에서 개인 공유 폴더 만들기를 지원합니다. Communications Express에서 시도해 볼 수 있습니다.

  2. 개인 공유 폴더의 공유 매개 변수를 설정합니다.

    다음 configutil 매개 변수가 지원됩니다.

    store.privatesharedfolders.restrictanyone - 활성화되면(1) 일반 사용자는 개인 공유 폴더에 대한 권한을 anyone으로 설정할 수 없습니다. 기본값: 0

    store.privatesharedfolders.restrictdomain - 활성화되면(1) 일반 사용자는 개인 폴더를 도메인 외부 사용자와 공유할 수 없습니다. 기본값: 0

    store.privatesharedfolders.shareflags - 0이면 여러 사용자들 간에 플래그를 공유할 수 없습니다. 1이면 여러 사용자들 간에 플래그를 공유할 수 있습니다. 기본값: 0

    store.publicsharedfolders.user - 공개 공유 폴더 소유자의 사용자 아이디입니다. 보통 public입니다. 기본값: NULL(설정되지 않음)

Procedure공개 공유 폴더 만들기

공개 폴더는 LDAP 데이터베이스와 readership 명령에 대한 액세스가 필요하기 때문에 시스템 관리자가 만들어야 합니다.

  1. 모든 공개 폴더의 컨테이너 역할을 수행하는 public이라는 LDAP 사용자 항목을 추가합니다( 20.5 공유 폴더 정보 참조).

    예:


    dn: cn=public,ou=people,o=sesta.com,o=ISP
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: inetUser
    objectClass: ipUser
    objectClass: inetMailUser
    objectClass: inetLocalMailRecipient
    objectClass: nsManagedPerson
    objectClass: userPresenceProfile
    cn: public
    mail: public@sesta.com
    mailDeliveryOption: mailbox
    mailHost: manatee.siroe.com
    uid: public
    inetUserStatus: active
    mailUserStatus: active
    mailQuota: -1
    mailMsgQuota: 100
                      
  2. mboxutil 명령줄 유틸리티를 사용하여 public 계정 내에 폴더를 만듭니다.

    예를 들어, gardening이라는 공개 폴더를 만듭니다.


    mboxutil -c user/public/gardening
  3. 폴더의 이름을 설정합니다.

    보통 public으로 지정합니다. 다음은 폴더 이름을 public으로 설정하는 명령입니다.

    configutil -o store.publicsharedfolders.user —v public

  4. 사용자와 공유 폴더에 대한 액세스 권한을 지정합니다.

    readership 명령을 사용하여 사용자와 해당 액세스 권한을 지정합니다. 예를 들어, 다음 명령은 gardening 공개 폴더에 대한 조회, 읽기 및 게시 권한을 sesta.com의 모든 사용자에게 할당합니다.

    readership -s user/public/gardening anyone@sesta.com lrp

    readership 사용 방법에 대한 자세한 내용은 20.6.2 공유 폴더의 액세스 제어 권한 설정 또는 변경을 참조하십시오.

20.6.1 전자 메일 그룹을 사용하여 공유 폴더 추가

공유 폴더는 일반적으로 Communications Express를 사용하여 공유 폴더 목록에 사용자를 추가하거나 앞에서 설명한 것처럼 공개 공유 폴더를 만들어 작성합니다. 그러나 그룹에 속한 모든 사용자가 공유 폴더에 액세스할 수 있도록 공유 폴더 목록에 전자 메일 그룹(메일 배포 목록)을 추가할 수도 있습니다. 예를 들어, tennis@sesta.com이라는 그룹에 25명의 구성원이 있으며 공유 폴더를 만들어 이 그룹 주소로 전송된 모든 전자 메일을 저장하기로 결정했습니다.

Procedure공유 폴더에 전자 메일 그룹을 추가하는 방법

공유 폴더에 전자 메일 그룹을 추가하려면 시스템 관리자 권한이 필요합니다.

  1. 폴더를 만듭니다. (이미 폴더를 만든 경우에는 이 단계를 건너뜁니다. )

    일반적으로 이 작업은 그룹의 구성원 중 한 명이 수행해야 합니다. 그렇지 않으면 다음 명령을 사용하여 대신 폴더를 만들 수 있습니다.

    mboxutil -c user/gregk/gardening

    gregk는 공유 폴더 소유자의 uid입니다. gardening은 공유 폴더의 이름입니다.

  2. 이 그룹 공유 폴더를 액세스할 모든 구성원의 사용자 항목에 속성-값 쌍인 aclGroupAddr group_name@domain을 추가합니다.

    위의 예를 사용하면 공유 폴더에 대한 액세스 권한을 할당할 각 사용자 항목에 다음 속성-값 쌍을 추가합니다.

    aclGroupAddr: tennis@sesta.com

    그룹 항목에 memberURL 속성을 사용하여 동적으로 그룹을 만든 경우에는 해당 구성원에 이미 이 속성이 있습니다. 이 속성의 URL 값은 다음과 같습니다.


    memberURL: ldap:///o=sesta.com??sub?(&(aclGroupAddr=tennis@sesta.com)
    (objectclass=inetmailuser))

    (인쇄상의 이유로 샘플 항목에서는 줄 바꿈되었지만 실제 항목은 한 행에 표시됩니다.)

  3. 그룹과 공유 폴더에 대한 액세스 권한을 지정합니다.

    readership 명령을 사용하여 이 작업을 수행할 수 있습니다. 위의 예를 사용하면 다음 명령은 gardening 공개 폴더에 대한 조회, 읽기 및 게시 권한을 tennis@sesta.com의 구성원에게 할당합니다.

    readership -s user/gregk/tennis tennis@sesta.com lrp

    readership 사용 방법에 대한 자세한 내용은 20.6.2 공유 폴더의 액세스 제어 권한 설정 또는 변경을 참조하십시오.

20.6.2 공유 폴더의 액세스 제어 권한 설정 또는 변경

사용자는 Communications Express 인터페이스를 사용하여 공유 폴더에 대한 액세스 제어를 설정하거나 변경할 수 있습니다. 관리자는 readership 명령줄 유틸리티를 사용하여 공유 폴더에 대한 액세스 제어를 설정하거나 변경할 수 있습니다. 이 명령의 형식은 다음과 같습니다.

readership -s foldername identifier rights_chars

여기서 foldername은 권한을 설정할 공개 폴더의 이름이고 identifier는 권한을 할당하는 개인 또는 그룹이며 rights_chars는 할당할 권한입니다. 각 문자의 의미는 표 20–3을 참조하십시오.


주 –

anyone은 특수 식별자입니다. anyone에 대한 액세스 권한은 모든 사용자에게 적용됩니다. 마찬가지로 anyone@domain에 대한 액세스 권한은 동일한 도메인의 모든 사용자에게 적용됩니다.


표 20–3 ACL 권한 문자

문자 

설명 

l

lookup– 사용자가 공유 폴더를 보고 가입할 수 있습니다. (허용되는 IMAP 명령: LISTLSUB).

r

read– 사용자가 공유 폴더를 읽을 수 있습니다(허용되는 IMAP 명령: 폴더에서 SELECT, CHECK, FETCH, PARTIAL, SEARCH, COPY).

s

seen– 세션에서 사용자가 본 정보를 보관하도록 시스템에 지시합니다. (IMAP STORE SEEN 플래그 설정).

w

write– 사용자가 read로 표시하고 메시지를 삭제할 수 있습니다. (SEENDELETED가 아닌 IMAP STORE 플래그 설정).

i

insert– 사용자가 한 폴더에서 다른 폴더로 전자 메일을 복사하고 이동할 수 있습니다. (허용되는 IMAP 명령: 폴더로 APPEND, COPY).

p

post– 사용자가 공유 폴더 전자 메일 주소로 메일을 보낼 수 있습니다. (IMAP 명령이 필요하지 않음). 

c

create– 사용자가 새 하위 폴더를 만들 수 있습니다. (허용되는 IMAP 명령: CREATE).

d

delete– 사용자가 공유 폴더에서 항목을 삭제할 수 있습니다. (허용되는 IMAP 명령: EXPUNGE, STORE DELETED 플래그 설정)

a

administer– 사용자에게 관리 권한이 있습니다. (허용되는 IMAP 명령: SETACL).

20.6.2.1 예

sesta 도메인에 있는 모든 사용자에게 golftournament라는 공개 폴더에 대한 조회, 읽기 및 전자 메일 표시 권한(게시 권한 제외)을 주려면 다음 명령을 실행합니다.

readership -s User/public/golftournament anyone@sesta lwr

메시지 저장소에 있는 모든 사용자에게 동일한 액세스 권한을 할당하려면 다음 명령을 실행합니다.

readership -s User/public/golftournament anyone lwr

조회, 읽기, 전자 메일 표시 및 게시 권한을 그룹에 할당하려면 다음 명령을 실행합니다.

readership -s User/public/golftournament group=golf@sesta.com lwrp

이 폴더에 대한 관리자 및 게시 권한을 개별 사용자 jdoe에게 할당하려는 경우 다음 명령을 실행합니다.

readership -s User/public/golftournament jdoe@sesta.com lwrpa

공개 폴더에 대한 개별 사용자 또는 그룹 액세스를 거부하려면 userid에 접두어 대시를 사용합니다. 예를 들어, jsmith에 대한 조회, 읽기 및 쓰기 권한을 거부하려면 다음 명령을 실행합니다.

readership -s User/public/golftournament -jsmith@sesta.com lwr

개별 사용자 또는 그룹 액세스를 거부하려면 ACL 권한 문자에 접두어 대시를 사용합니다. 예를 들어, jsmith에 대한 게시 권한을 거부하려면 다음 명령을 실행합니다.

readership -s User/public/golftournament jsmith@sesta.com -p


주 –

uid+folder@domain 주소를 사용하여 공유 폴더에 메시지를 게시하려면 readership 명령과 함께 p(post) 액세스 권한을 사용해야 합니다. 20.6.2 공유 폴더의 액세스 제어 권한 설정 또는 변경을 참조하십시오.


20.6.3 공유 폴더 목록을 사용 가능 또는 사용 불가능하게 하기

서버는 구성 옵션 local.store.sharedfolders의 설정에 따라 LIST 명령에 응답할 때 공유 폴더를 반환하거나 반환하지 않습니다. 이 옵션을 비활성화하려면 off로 설정합니다. 기본적으로 이 옵션은 활성화됩니다(on으로 설정).

SELECTLSUB 명령은 이 옵션의 영향을 받지 않습니다. LSUB 명령은 공유 폴더를 비롯하여 가입한 모든 폴더를 반환합니다. 사용자는 자신이 소유하거나 가입한 공유 폴더를 SELECT할 수 있습니다.

20.6.4 분산 공유 폴더 설정

일반적으로 공유 폴더는 특정 메시지 저장소의 사용자만 사용할 수 있습니다. 그러나 Messaging Server에서는 여러 메시지 저장소에서 액세스할 수 있는 분산 공유 폴더를 만들 수 있습니다. 즉, 분산 공유 폴더에 대한 액세스 권한은 메시지 저장소 그룹 내의 모든 사용자에게 부여될 수 있습니다. 단, 웹 메일 클라이언트(Messenger Express와 같은 HTTP 액세스 클라이언트)는 원격 공유 폴더 액세스를 지원하지 않습니다. 사용자는 폴더를 나열하여 가입할 수 있지만 내용을 보거나 변경할 수는 없습니다.

분산 공유 폴더는 다음이 필요합니다.

원격 메시지 저장소(공유 폴더를 보유하지 않는 메시지 저장소)는 표 20–4에 나열된 구성 변수를 설정하여 프록시 서버로 구성해야 합니다.

표 20–4 분산 공유 폴더 구성을 위한 변수

이름 

값 

데이터 형식 

local.service.proxy.serverlist

메시지 저장소 서버 목록 

공백으로 구분된 문자열 

local.service.proxy.admin

기본 저장소 관리자 로그인 이름 

문자열 

local.service.proxy.adminpass

기본 저장소 관리자 비밀번호 

문자열 

local.service.proxy.admin.hostname

특정 호스트의 저장소 관리자 로그인 이름 

문자열 

local.service.proxy.adminpass.hostname

특정 호스트의 저장소 관리자 비밀번호 

문자열 

20.6.4.1 분산 공유 폴더 설정—예

그림 20–3은 StoreServer1, StoreServer2 및 StoreServer3이라는 세 메시지 저장소 서버의 분산 폴더 예를 보여 줍니다.

그림 20–3 분산 공유 폴더—예

이 그림은 분산 공유 폴더의 예를 보여 줍니다.

이러한 서버는 표 20–4에 나온 변수의 설정을 통해 서로 간에 피어 프록시 메시지 저장소로 연결됩니다. 각 서버에는 개인 공유 폴더 golf(Han 소유), tennis(Kat 소유) 및 hurling(Luke 소유)이 있습니다. 또한 press_releasesAnnouncements라는 두 개의 공개 공유 폴더가 존재합니다. 세 서버의 사용자는 이러한 세 개의 공유 폴더에 액세스할 수 있습니다. 그림 20–2는 Ed의 공유 폴더 목록을 보여 줍니다. 다음은 이 구성의 각 서버에 대한 ACL의 예입니다.


$ StoreServer1 :> imcheck -d lright.db
Ed: user/Han/golf 
Ian: user/Han/golf 
anyone: user/public/press_releases

            

$ StoreServer2 :> imcheck -d lright.db
Jan: user/Kat/tennis
Ann: user/Kat/tennis
anyone: user/public+Announcements user/public+press_releases

            

$ StoreServer3 :> imcheck -d lright.db
Tuck: user/Ian/hurling
Ed: user/Ian/hurling 
Jac: user/Ian/hurling 
anyone: user/public/Announcements

            

20.6.5 공유 폴더 데이터 모니터 및 유지 관리

readership 명령줄 유틸리티를 사용하면 folder.db, peruser.dblright.db 파일에 보관되는 공유 폴더 데이터를 모니터 및 유지 관리할 수 있습니다. folder.db는 ACL의 복사본을 보유하는 각 폴더에 대한 레코드를 가집니다. peruser.db는 각 사용자 및 메일함에 대한 항목을 가지며 이 항목은 다양한 플래그 설정과 사용자가 임의 폴더에 마지막으로 액세스한 날짜를 나열합니다. lright.db는 모든 사용자와 사용자가 조회 권한을 가진 공유 폴더를 나열합니다.

readership 명령줄 유틸리티에는 다음 옵션이 있습니다.

표 20–5 readership 옵션

옵션 

설명 

-d days

지정된 날짜 동안 해당 폴더를 선택한 사용자 수에 대한 보고서를 공유 폴더별로 반환합니다. 

-p months

지정된 개월 수 동안 공유 폴더를 선택하지 않는 사용자에 대해 peruser.db에서 데이터를 제거합니다.

-l

lright.db의 데이터를 나열합니다.

-s folder_identifier_rights

지정된 폴더에 대한 액세스 권한을 설정합니다. folder.dblright.db를 업데이트합니다.

다양한 옵션을 사용하여 다음 기능을 수행할 수 있습니다.

20.6.5.1 공유 폴더 사용 모니터

공유 폴더를 액세스하는 활성 사용자 수를 확인하려면 다음 형식의 명령을 실행합니다.

readership -d days

여기서 days는 검사할 일 수입니다. 이 옵션은 활성 사용자 목록이 아니라 그 수를 반환한다는 점에 주의하십시오.

예: 마지막 30일 이내에 공유 폴더를 선택한 사용자 수를 확인하려면 다음 명령을 실행합니다.

readership -d 30

20.6.5.2 사용자 및 사용자의 공유 폴더 나열

사용자와 사용자가 액세스할 수 있는 공유 폴더를 나열하려면 다음 명령을 실행합니다.

imcheck -d lright.db

출력 예는 다음과 같습니다.

$ imcheck -d lright.db
group=lee-staff@siroe.com: user/user2/lee-staff
richb: user/golf user/user10/Drafts user/user2/lee-staff user/user10/Trash
han1: user/public+hurling@siroe.com user/golf
gregk: user/public+hurling@siroe.com user/heaving user/tennis

20.6.5.3 비활성 사용자 제거

지정된 기간 동안 공유 폴더에 액세스하지 않은 비활성 사용자를 제거하려면 다음 명령을 실행합니다.

readership -p months

여기서 months는 검사할 개월 수입니다.

예: 지난 6개월 동안 공유 폴더에 액세스하지 않은 사용자를 제거합니다.

readership -p 6

20.6.5.4 액세스 권한 설정

새 공유 폴더에 대한 액세스 권한을 할당하거나 현재 공유 폴더에서 액세스 권한을 변경할 수 있습니다.

이 명령으로 액세스 권한을 설정하는 방법의 예는 20.6.2 공유 폴더의 액세스 제어 권한 설정 또는 변경을 참조하십시오.

20.7 메시지 유형 관리

이 절은 다음 내용으로 구성되어 있습니다.

20.7.1 메시지 유형 개요

통합 메시징 응용 프로그램은 텍스트 메시지, 음성 메일, 팩스 메일, 이미지 데이터 및 기타 데이터 형식을 포함하여 여러 유형의 메시지를 받고, 보내고, 저장하고, 관리할 수 있습니다. 메시지 저장소를 사용하면 서로 다른 메시지 유형을 63개까지 정의할 수 있습니다.

메시지를 유형별로 조작하는 방법 중 하나는 메시지를 개별 폴더에 유형별로 구성하는 것입니다.

메시지 유형 기능을 사용할 수 있기 때문에 서로 다른 여러 메시지 유형을 개별 메일함 폴더에서 유지 관리할 필요가 없습니다. 메시지 유형을 구성하고 나면 저장 위치에 관계 없이 메시지 저장소에서 확인할 수 있습니다. 따라서 같은 폴더에 서로 다른 메시지 유형을 저장할 수 있습니다. 또한 다음 작업을 수행할 수 있습니다.

20.7.1.1 메시지 유형 구성 계획

통합 메시징 응용 프로그램에서 이질적인 형식의 데이터에는 Messaging Server가 데이터를 저장 및 관리할 수 있도록 표준 인터넷 메시지 헤더가 지정됩니다. 예를 들어 최종 사용자의 전화로 음성 메일을 전송하면 전화 프런트엔드 시스템이 받는 음성 메일에 메시지 헤더를 추가하여 메시지 저장소로 전달합니다.

서로 다른 여러 유형의 메시지를 인식하고 관리하려면 통합 메시징 시스템의 모든 구성 요소에서 같은 메시지 유형 정의와 헤더 필드를 사용하여 메시지를 식별해야 합니다.

메시지 유형을 지원하도록 메시지 저장소를 구성하려면 먼저 다음을 수행해야 합니다.

예를 들어, 응용 프로그램에 전화 메시지가 포함된 경우 이 메시지 유형을 "multipart/voice-message"로 정의하고 내용 유형 헤더 필드를 사용하여 메시지 유형을 확인할 수 있습니다.

그런 다음 메시지 저장소로 전달되는 각 전화 메시지에 다음 헤더 정보를 추가하도록 전화 프런트엔드 시스템을 구성합니다.

Content-Type: multipart/voice-message

다음으로는 뒤의 절에 있는 설명에 따라 multipart/voice-message 메시지 유형을 인식하도록 메시지 저장소를 구성합니다.

20.7.1.2 메시지 유형 정의 및 사용

multipart/voice-message와 같은 고유한 정의를 지정하여 메시지 유형을 정의합니다. 기본적으로 메시지 저장소는 내용 유형 헤더 필드를 읽고 메시지 유형을 결정합니다. 원하는 경우 다른 헤더 필드를 구성하여 메시지 유형을 식별할 수 있습니다.

메시지 저장소에서는 대소문자를 무시하고 내용 유형(또는 기타 지정된) 헤더 필드를 읽습니다. 즉, 헤더의 대소문자 조합이 예상된 조합과 다른 경우에도 메시지 저장소에서 헤더 필드를 유효한 것으로 승인합니다.

메시지 저장소는 헤더 필드에 있는 메시지 유형 이름만 읽습니다. 추가 인수 또는 매개 변수는 무시합니다.

메시지 유형을 정의하려면 configutil 유틸리티를 사용하여 store.messagetype 매개 변수의 값을 설정합니다. 자세한 지침은 메시지 유형을 구성하는 방법을 참조하십시오.

메시지 유형을 구성하면 메시지 저장소에서 지정된 유형의 메시지를 식별하고 조작할 수 있습니다. 이 단계가 통합 메시징 응용 프로그램에서 메시지 유형을 관리하기 위해 필요한 첫 단계입니다.

메시지 저장소에서 제공하는 메시지 유형 기능의 장점을 모두 활용하려면 다음 작업 중 일부 또는 전부를 수행해야 합니다.

이러한 작업에 대한 요약은 다음 절을 참조하십시오.

Procedure메시지 유형을 구성하는 방법

메시지 유형을 구성하려면 configutil 유틸리티를 사용하여 메시지 유형을 정의하고 식별하는 store.messagetype 매개 변수 값을 설정합니다.

  1. store.messagetype.enable 매개 변수를 on으로 설정하여 메시지 유형을 활성화합니다.

    configutil 매개 변수를 사용하면 메시지 저장소에서 메시지 유형을 식별 및 조작할 수 있습니다. 개별 메시지 유형을 구성하려면 먼저 이 매개 변수를 설정해야 합니다.

    예를 들어, 다음 명령을 입력합니다.


    configutil -o store.messagetype.enable -v 1
  2. store.messagetype. x 매개 변수를 설정하여 메시지 유형을 정의 및 식별합니다.

    변수 x는 메시지 저장소에서 이 특정 메시지 유형을 식별합니다. 변수 x는 0보다 크고 64보다 작은 정수여야 합니다. 고유한 정수를 사용하여 반복적으로 이 매개 변수를 구성하면 메시지 유형을 63개까지 정의할 수 있습니다.

    유형을 설명하는 텍스트 문자열을 사용하여 메시지 유형의 값을 정의합니다.

    예를 들어 텍스트 메시지 유형을 정의하려면 다음 명령을 입력합니다.


    configutil -o store.messagetype.1 -v text/plain

    음성 메시지 유형을 정의하려면 다음 명령을 입력합니다.


    configutil -o store.messagetype.2 -v multipart/voice-message
  3. store.messagetype. x.flagname 매개 변수를 설정하여 메시지 유형에 플래그 이름을 지정합니다.

    이 매개 변수는 메시지 유형을 식별하는 고유한 플래그를 만듭니다. 이 유형의 메시지가 처음 메시지 저장소에 도착할 때마다 플래그가 자동으로 설정되며 제거될 때까지 메시지와 연결된 상태로 남습니다. 플래그 이름 값은 메시지 유형을 설명하는 텍스트 문자열입니다. store.messagetype. x 매개 변수로 설정한 값과 같은 필요는 없습니다.

    변수 xstore.messagetype. x 매개 변수로 정의한 메시지 유형의 정수 아이디입니다.

    예를 들어 앞의 단계에서 구성한 메시지 유형에 플래그 이름을 정의하려면 다음 명령을 입력합니다.


    configutil -o store.messagetype.1.flagname -v text
    
    configutil -o store.messagetype.2.flagname -v voice_message
  4. store.messagetype.x.quotaroot 매개 변수를 설정하여 메시지 유형의 할당량 루트 이름을 구성합니다.

    이 매개 변수를 사용하면 할당량 기능에서 이 메시지 유형의 할당량 루트를 식별 및 관리할 수 있습니다. 매개 변수 값은 이름, 즉 메시지 유형을 설명하는 텍스트 문자열입니다. store.messagetype.x 매개 변수로 설정한 값과 같을 필요는 없습니다.

    변수 xstore.messagetype.x 매개 변수로 정의한 메시지 유형의 정수 아이디입니다.

    이 매개 변수가 구성되어 있으면 지정한 메시지 유형에 적용되는 할당량을 설정할 수 있습니다. 자세한 내용은 20.7.4 메시지 유형별로 할당량 관리를 참조하십시오.

    예를 들어, 앞의 단계에서 구성한 메시지 유형에 대해 할당량 루트 사용을 활성화하려면 다음 명령을 입력합니다.


    configutil -o store.messagetype.1.quotaroot -v text
    
    configutil -o store.messagetype.2.quotaroot -v voice
  5. 메시지 유형을 식별하기 위한 대체 헤더 필드를 구성하려면 store.messagetype.header 매개 변수를 설정합니다.

    기본적으로 메시지 저장소는 내용 유형 헤더 필드를 읽고 메시지 유형을 결정합니다. store.messagetype.header 매개 변수는 메시지 유형 식별을 위해 다른 헤더 필드를 사용하려는 경우에만 구성합니다. 이 매개 변수 값은 텍스트 문자열입니다.

    예를 들어 X-Message-Type이라는 필드를 사용하려면 다음 명령을 입력합니다.


    configutil -o store.messagetype.header -v X-Message-Type

20.7.2 IMAP 명령의 메시지 유형

메시지 유형에 store.messagetype.x.flagname 매개 변수를 구성할 때, 메시지 유형을 식별하는 고유 플래그를 만듭니다. 이 플래그는 최종 사용자가 수정할 수 없습니다.

Messaging Server는 메시징 유형 플래그를 IMAP 클라이언트에 사용자 플래그로 제공합니다. 메시지 유형을 사용자 플래그에 매핑하면 메일 클라이언트에서 간단한 IMAP 명령을 사용하여 메시지 유형별로 메시지를 조작할 수 있습니다.

예를 들어, 다음 작업을 수행할 수 있습니다.

메시지 유형 사용자 플래그는 읽기 전용입니다. IMAP 명령으로 수정할 수 없습니다.

다음 예에서는 아래에 표시된 값으로 메시지 유형 configutil 매개 변수를 구성하는 경우를 가정합니다.


store.messagetype.enable = yes

store.messagetype.1 = text/plain
store.messagetype.1.flagname = text
store.messagetype.1.quotaroot = text

store.messagetype.2 = multipart/voice-message
store.messagetype.2.flagname = voice_message
store.messagetype.2.quotaroot = voice

예 20–1 메시지 유형 configutil 구성을 기반으로 한 IMAP FETCH 세션

다음 IMAP 세션에서는 현재 선택한 메일함의 메시지를 불러옵니다.


2 fetch 1:2 (flags rfc822)
* 1 FETCH (FLAGS (\Seen text) RFC822 {164}

Date: Wed, 8 July 2006 03:39:57 -0700 (PDT)
From: bob.smith@siroe.com
To: john.doe@siroe.com
Subject:  Hello
Content-Type: TEXT/plain; charset=us-ascii


* 2 FETCH (FLAGS (\Seen voice_message) RFC822 {164}

Date: Wed, 8 July 2006 04:17:22 -0700 (PDT)
From: sally.lee@siroe.com
To: john.doe@siroe.com
Subject:  Our Meeting
Content-Type: MULTIPART/voice-message; ver=2.0

2 OK COMPLETED

앞의 예에서는 두 개의 메시지를 불러오며, 하나는 텍스트 메시지이고 하나는 음성 메일입니다.

메시지 유형 플래그는 store.messagetype.*.flagname 매개 변수를 사용하여 구성한 형식으로 표시됩니다.

내용 유형 헤더 필드는 메시지 유형을 식별합니다. 메시지 유형 이름은 받는 메시지에서 받은 그대로 표시됩니다. 여기에는 대문자와 소문자를 혼합하여 사용하며 charset=us-ascii와 같은 메시지 유형 인수를 포함합니다.



예 20–2 메시지 유형 configutil 구성을 기반으로 한 IMAP SEARCH 세션

다음 IMAP 세션에서는 현재 선택한 메일함의 음성 메시지를 검색합니다.


3 search keyword voice_message
* SEARCH 2 4 6 
3 OK COMPLETED

앞의 예에서 메시지 2, 4, 6은 음성 메시지입니다. 검색에 사용되는 키워드는 store.messagetype.2.flagname 매개 변수 값인 voice_message입니다.


20.7.3 메시지 유형에 해당하는 알림 메시지 전송

알림은 텍스트 메시지, 음성 메시지 및 이미지 데이터 등의 여러 메시지 유형에 대해 상태 정보를 전달할 수 있습니다. Messaging Server에서는 Sun Java System Message Queue를 사용하여 메시지 유형에 해당하는 알림 정보를 보냅니다. Message Queue용 JMQ 알림 플러그 인 구성에 대한 자세한 내용은 Message Queue 22 장, JMQ 알림 플러그 인을 구성하여 Message Queue에서 사용할 메시지 생성을 참조하십시오.

JMQ 알림 플러그 인에서 특정 메시지 유형을 인식할 수 있게 하려면 store.messagetype.x.flagname 매개 변수를 포함한 store.messagetype 매개 변수를 구성해야 합니다. 자세한 내용은 메시지 유형을 구성하는 방법을 참조하십시오.

메시지 유형을 구성하고 나면 JMQ 알림 메시지에서 특정 메시지 유형을 식별할 수 있습니다. 메시지 유형별로 알림 메시지를 해석하고 각 유형에 대한 상태 정보를 메일 클라이언트로 전달하도록 Message Queue 클라이언트를 작성할 수 있습니다.

JMQ 알림 기능에서는 현재 메일함에 있는 메시지의 수를 메시지 유형별로 계산합니다. 수 값이 하나 전달되는 대신 각 메시지 유형의 수를 지정하는 배열이 알림 메시지와 함께 전달됩니다.

예를 들어, NewMsg 알림 메시지는 새 음성 메일 메시지 7개와 새 텍스트 메시지 4개가 사용자의 받은 메일함에 있다고 알리는 데이터를 전달할 수 있습니다.

메시지 유형별 알림 전송에 대한 자세한 내용은 22.3.3 특정 메시지 유형의 알림을 참조하십시오.

20.7.4 메시지 유형별로 할당량 관리

메시지 유형에 대해 할당량을 설정할 경우 해당 값을 할당량 루트에 포함합니다. 할당량 루트는 사용자에 대한 할당량을 지정합니다. 여기서는 특정 메시지 유형 및 메일함 폴더에 다른 할당량을 지정할 수 있으며, 유형으로 정의되지 않은 모든 나머지 메시지 유형, 폴더 및 메시지에 적용되는 기본 할당량을 지정할 수 있습니다.

할당량 설정 및 관리에 대한 자세한 내용은 20.8.2 할당량 작동 원리를 참조하십시오.

20.7.4.1 메시지 유형 할당량을 설정하기 전에

메시지 유형에 할당량을 설정하기 전에 다음 매개 변수를 구성해야 합니다.

20.7.4.2 메시지 유형 할당량 설정 방법

다음 중 한 가지 방법을 사용하여 메시지 유형의 할당량을 설정합니다.

configutil 매개 변수나 위에 표시된 LDAP 속성을 사용하여 메시지 유형에 대한 할당량을 설정하는 경우 store.messagetype.x.quotaroot 매개 변수를 사용하여 지정한 할당량 루트를 사용해야 합니다.

20.7.4.3 메시지 유형 할당량 루트의 예

이 절에 설명된 예에서는 사용자 joe에 대해 다음 할당량을 설정합니다.

이 할당량 루트는 다른 모든 폴더 및 메시지 유형을 합한 것보다(60M) Archive 폴더에 더 큰 저장소(100M)를 허용합니다. 또, Archive 폴더에는 메시지 제한이 없습니다. 이 예에서 아카이브에 문제가 되는 것은 저장소 제한 뿐입니다.

메시지 유형에는 저장소 및 메시지 수 할당량이 모두 있습니다.

메시지 유형 할당량은 Archive 폴더에 저장되었는지 또는 다른 폴더에 저장되었는지에 관계 없이 해당 유형의 모든 메시지를 합한 것에 적용됩니다.

기본 메일함 할당량은 텍스트 또는 음성 메시지 유형이 아니고 Archive 폴더에 저장되지 않는 모든 메시지에 적용됩니다. 즉, 메시지 유형 할당량과 Archive 할당량은 기본 메일함 할당량의 일부로 계산되지 않습니다.

이 예에서 할당량 루트를 설정하려면 다음 단계를 수행합니다.

  1. 다음과 같이 store.messagetype.x.quotaroot 매개 변수를 구성합니다.


    store.messagetype.1.quotaroot = text
    
    store.messagetype.2.quotaroot = voice
  2. 다음과 같이 사용자 joe에 대해 mailQuota 속성을 구성합니다.


    mailQuota: 20M;#text%10M;#voice%10M;Archive%100M
  3. 다음과 같이 사용자 joe에 대해 mailMsgQuota 속성을 구성합니다.


    mailMsgQuota: 5000;#text%2000;#voice%200

getquotaroot IMAP 명령을 실행하면 다음과 같이 결과 IMAP 세션에 사용자 joe의 메일함에 해당되는 모든 할당량 루트가 표시됩니다.


1 getquotaroot INBOX
* QUOTAROOT INBOX user/joe user/joe/#text user/joe/#voice
* QUOTA user/joe (STORAGE 12340 20480 MESSAGE 148 5000)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)
* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

2 getquotaroot Archive
* QUOTAROOT user/joe/Archive user/joe/#text user/joe/#voice
* QUOTA user/joe/Archive (STORAGE 35424 102400)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)

* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

20.7.5 메시지 유형별 메시지 만료

만료 및 제거 기능을 사용하면 만료 규칙에 정의된 기준에 따라 메시지를 한 폴더에서 다른 폴더로 옮기고, 아카이브에 보관하고, 메시지 저장소에서 제거할 수 있습니다. 이 작업은 imexpire 유틸리티를 사용하여 수행합니다.

imexpire 유틸리티는 관리자가 실행하기 때문에 할당량 적용을 무시합니다.

만료 규칙을 작성하고 imexpire 유틸리티를 사용하는 방법에 대한 자세한 내용은 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법을 참조하십시오.

각기 다른 기준에 따라 다른 유형의 메시지가 만료되도록 만료 규칙을 작성할 수 있습니다.

만료 기능은 만료 기준 설정에 선택할 수 있는 많은 옵션을 제공하여 매우 유연합니다. 이 절에서는 서로 다른 기준에 따라 텍스트 및 음성 메시지가 만료되는 한 가지 예에 대해 설명합니다.

이 예에서는 다음과 같이 텍스트 및 음성 메시지 유형을 구성한 경우를 가정합니다.


store.messagetype.1 = text/plain

store.messagetype.2 = multipart/voice-message

또한 메시지 저장소가 내용 유형 헤더 필드를 읽고 메시지 유형을 결정하도록 구성된 경우를 가정합니다.


예 20–3 서로 다른 메시지 유형을 만료하는 샘플 규칙


TextInbox.folderpattern: user/%/INBOX
TextInbox.messageheader.Content-Type: text/plain
TextInbox.messagedays: 365
TextInbox.action: fileinto:Archive


VoiceInbox.folderpattern: user/%/INBOX
VoiceInbox.messageheader.Content-Type: multipart/voice-message
VoiceInbox.savedays: 14
VoiceInbox.action: fileinto:OldMail

VoiceOldMail.folderpattern: user/%/OldMail
VoiceOldMail.messageheader.Content-Type: multipart/voice-message
VoiceOldMail.savedays: 30
VoiceOldMail.action: fileinto:Trash

Trash.folderpattern: user/%/Trash
Trash.savedays: 7
Trash.action: discard

이 예에서 텍스트 메시지와 음성 메시지는 서로 다른 방식으로 만료되며 다음과 같이 서로 다른 일정을 따릅니다.

주: savedays 규칙을 사용하면 메시지를 저장한 후 지정된 일 수가 지났을 때 메시지가 만료됩니다. 일반적인 음성 메일 시스템에서 사용자는 음성 메일 메뉴로 음성 메일을 저장할 수 있습니다. 텍스트 메시지의 경우 메시지는 폴더로 이동하면 저장됩니다. messagedays 규칙을 사용하면 메시지가 메시지 저장소에 처음 도착한 후 지정된 일 수가 지나면 메시지가 저장된 폴더나 이동 빈도에 관계 없이 만료됩니다.


20.8 메시지 저장소 할당량 정보

전자 메일과 음성 메일이 폭주하면 IMAP 메일함이 매우 커질 수 있습니다. 사용자 또는 도메인에서 보관할 수 있는 메시지의 수나 메시지에 사용할 수 있는 디스크 공간에 대한 메시지 저장소 할당량 제한, 즉 할당량이 특정 폴더 또는 특정 메시지 유형에 대해 지정됩니다. 할당량은 메시지 저장소 사용을 제한하거나 줄이기 위해 사용됩니다. 이 절은 다음 내용으로 구성되어 있습니다.

자세한 내용은 20.11.4 할당량 제한 모니터를 참조하십시오.

20.8.1 할당량 개요

할당량은 특정 사용자 또는 도메인에 대해 설정할 수 있으며 메시지 수 또는 바이트 수를 기준으로 설정할 수 있습니다. 특정 폴더 및 메시지 유형에 대해 설정할 수도 있습니다. 메시지 유형 할당량을 사용하면 메시지 유형에 대해 제한을 지정할 수 있습니다. 예를 들어 음성 메일과 전자 메일이 있습니다. 폴더 할당량은 사용자의 폴더 크기를 바이트 수 또는 메시지 수로 제한합니다. 예를 들어, Trash 폴더에 할당량을 설정할 수 있습니다. Messaging Server를 사용하면 도메인과 사용자의 기본 할당량과 사용자 정의 할당량을 설정할 수 있습니다.

할당량을 설정하고 나면 할당량을 초과했거나 할당량에 도달해 가는 사용자 또는 도메인에 대해 시스템이 응답하는 방식도 구성할 수 있습니다. 응답 중 한 가지로 사용자에게 할당량 알림을 보내는 것이 있습니다. 다른 응답으로는 할당량을 초과한 경우에 메시지 저장소에 대한 메시지 전달을 중지하는 것이 있습니다. 이를 할당량 적용이라고 하며 보통 지정된 유예 기간이 지난 후에 발생합니다. 유예 기간은 적용이 일어나기 전에 메일함이 할당량을 초과한 상태로 유지될 수 있는 기간을 말합니다. 할당량 초과로 인해 메시지 전달이 중지되는 경우 받는 메시지는 다음 중 하나가 발생할 때까지 MTA 대기열에 남아 있습니다.

사용자가 메시지를 삭제 및 정리하거나 서버에서 설정된 만료 정책에 따라 메시지를 삭제하면 디스크 공간을 사용할 수 있게 됩니다( 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법 참조).

20.8.1.1 Telephony Application Server 예외 사항

통합 메시징 요구 사항을 지원하기 위해 Messaging Server는 메시지 저장소에서 부과한 할당량 제한을 무시하는 기능을 제공합니다. 이 기능은 TAS(Telephony Application Server)라는 특정 에이전트에서 받은 메시지가 전달되도록 합니다. TAS가 받은 메시지는 할당량 제한에 상관 없이 메시지가 저장소로 전달되도록 하는 특수한 MTA 채널을 통해 라우팅됩니다. 난해한 용법이기는 하지만 전화 통신 응용 프로그램에 사용할 수 있습니다. TAS 채널 구성에 대한 자세한 내용은 Sun 메시징 담당자에게 문의하십시오.

메시지 유형별 할당량은 통합 메시징을 사용하는 전화 통신 응용 프로그램에 유용합니다. 예를 들어 대화 텍스트 및 음성 메일이 섞인 메시지가 사용자의 메일함에 저장되어 있는 경우 관리자는 다른 유형의 메시지에 대해 다른 할당량을 설정할 수 있습니다. 사용자의 전자 메일에 할당량이 하나 지정되고, 음성 메일에 다른 할당량이 지정될 수 있습니다.

20.8.2 할당량 작동 원리

사용자 정의된 사용자 및 도메인 할당량은 LDAP 사용자 및 도메인 항목에 할당량 속성을 추가하여 지정합니다. 할당량 기본값, 알림 정책, 적용 및 유예 기간은 configutil 매개 변수에 지정되거나 imquotacheck 유틸리티를 사용하여 지정됩니다.

사용자가 할당량을 초과하는지 확인하기 위해 Messaging Server는 우선 개별 사용자에 대한 할당량이 설정되었는지 검사합니다. 할당량이 설정되지 않은 경우 Messaging Server는 모든 사용자에 설정된 기본 할당량을 확인합니다. 사용자의 경우 할당량은 사용자의 폴더 전체에 있는 바이트 또는 메시지 수를 모두 누적한 값에 적용됩니다. 도메인의 경우 할당량은 특정 도메인에 있는 모든 사용자의 바이트 또는 메시지 수를 모두 누적한 값에 적용됩니다. 메시지 유형의 경우 할당량은 해당 메시지 유형의 바이트 또는 메시지 수를 모두 누적한 값에 적용됩니다. 폴더의 경우 할당량은 사용자의 폴더의 바이트 또는 메시지 수를 모두 누적한 값에 적용됩니다.

사용자의 메일함 트리에 다음과 같은 할당량 값을 지정할 수 있습니다.

사용자에 대해 여러 할당량 값을 지정하는 경우 다음 지침이 적용됩니다.

할당량 속성과 configutil 매개 변수의 변경 사항은 자동으로 적용되지만 정보가 캐시에 저장되기 때문에 즉시 적용되는 것은 아니며, 변경 사항이 완전히 적용될 때까지 시간이 걸릴 수 있습니다. Messaging Server에는 변경 사항을 즉시 업데이트하는 Sun Java System Messaging Server 6.3 Administration Referenceiminitquota 명령이 있습니다.

imquotacheck 유틸리티를 사용하면 지정된 할당량을 기준으로 메시지 저장소 사용을 확인할 수 있습니다.

20.8.3 메시지 저장소 할당량 속성 및 매개 변수

이 절에서는 주요 메시지 저장소 할당량 속성과 configutil 매개 변수를 나열합니다. 이는 기능 인터페이스의 개요를 제공하기 위한 것입니다. 이 속성과 매개 변수에 대한 자세한 내용은 해당 참조 설명서를 참조하십시오.

다음 표에는 할당량 속성이 나열되어 있습니다. Sun Java Communications Suite 5 Schema Reference를 참조하십시오.

표 20–6 메시지 저장소 할당량 속성

속성 

설명 

mailQuota

사용자의 메일함에 허용되는 디스크 공간(바이트)입니다.  

mailMsgQuota

사용자에게 허용되는 최대 메시지 수입니다. 이 값은 저장소에 있는 모든 폴더에 대한 누적 개수입니다.  

mailUserStatus

메일 사용자의 상태입니다. 가능한 값에는 active, inactive, deleted, hold, overquota 등이 있습니다.

mailDomainDiskQuota

허용되는 디스크 공간(바이트)으로 도메인에 있는 모든 메일함에 대한 누적 개수입니다.  

mailDomainMsgQuota

도메인에 허용되는 최대 메시지 수 즉, 저장소에 있는 모든 메일함에 대한 개수 합계입니다. 

mailDomainStatus

메일 도메인의 상태입니다. 값 및 기본값은 mailUserStatus와 동일합니다.

다음 표에는 할당량 매개 변수가 나열되어 있습니다. 자세한 최신 내용은 Sun Java System Messaging Server 6.3 Administration Reference의 3 장, Messaging Server Configuration을 참조하십시오.

표 20–7 메시지 저장소 configutil 매개 변수

매개 변수 

설명 

store.quotaenforcement

할당량 적용을 활성화합니다. Off이면 할당량 데이터베이스가 계속 업데이트되 지만 메시지가 항상 전달됩니다. 기본값: On입니다. 

store.quotanotification

할당량 알림을 활성화 합니다. 기본값: OFF입니다. 

store.defaultmailboxquota

저장소 기본 할당량(바이트)입니다. 기본값: -1(제한 없음)입니다. 

store.defaultmessagequota

저장소 기본 할당량(메시지 수)입니다. 숫자 값입니다. 기본값: -1(제한 없음)입니다.  

store.quotaexceededmsg

할당량 경고 메시지입니다. 이 값이 없으면 알림을 보내지 않습니다. 기본값: 없습니다. 

store.quotaexceededmsginterval

할당량 초과 알림을 보내는 간격(일)입니다. 기본값: 7 

store.quotagraceperiod

메일함이 할당량 초과된 후 메일함의 메일을 보낸 사람에게 돌려보낼 때까지 허용된 시간(시)입니다. 시간 수입니다. 기본값: 120입니다. 

store.quotawarn

할당량 경고 임계값. 클라이언트에게 할당량 경고를 보내기 전에 초과한 할당량 비율입니다. 기본값: 90입니다. 

local.store.quotaoverdraft

Netscape Messaging Server에서 마이그레이션된 시스템과의 호환성을 제공하는 데 사용됩니다. ON인 경우 디스크 사용량이 할당량을 초과하는 메시지 전달을 허용합니다. 사용자가 할당량을 초과하면 메시지가 지연되거나 바운스되고 할당량 경고 메시지가 발송되며 할당량 유예 기간 타이머가 시작됩니다. 기본값은 메시지 저장소가 임계값에 도달할 때 할당량 경고 메시지를 보냅니다. 기본값: Off입니다. 하지만 store.overquotastatus가 설정된 경우에는 on으로 간주되며 그렇지 않은 경우에는 사용자가 할당량을 초과할 수 없고 overquotastatus 가 사용되지 않습니다.

local.store.overquotastatus

메시지가 MTA의 대기열에 포함되기 전에 할당량 적용을 활성화합니다. 그렇게 하면 MTA 대기열이 가득 차지 않습니다. 설정하는 경우 사용자가 아직 할당량을 초과하지 않았지만 받는 메시지로 인해 사용자가 할당량을 초과하게 되면 메시지가 전달되지만 mailuserstatus LDAP 속성이 overquota로 설정되므로 MTA에서 더 이상의 메시지를 수락하지 않습니다. 기본값: off입니다. 

메시지 저장소 할당량에는 두 개의 유틸리티도 포함되어 있습니다. Sun Java System Messaging Server 6.3 Administration Referenceiminitquota는 할당량 설정을 초기화합니다. 즉, 할당량 속성과 configutil 매개 변수는 이 명령을 실행하고 나면 자동으로 적용됩니다. 이 명령을 실행하지 않아도 변경 사항이 적용되기는 하지만, 정보가 캐시에 저장된 후 실제로 적용될 때까지 약간의 시간이 걸리기 때문에 즉시 적용되지는 않습니다.

imquotacheck 유틸리티를 사용하면 지정된 할당량을 기준으로 메시지 저장소 사용량을 확인할 수 있습니다.

20.8.4 메시지 저장소 할당량 구성

이 절에서는 다음 작업에 대해 설명합니다.

20.8.4.1 기본 사용자 할당량 지정

기본 할당량은 LDAP 항목에 개별 할당량이 설정되지 않은 사용자에게 적용됩니다. 이 프로세스는 두 단계로 구성됩니다. 1) 사용자 기본 할당량을 지정한 다음 2) 기본 할당량에 바인드되는 사용자를 지정합니다. 다음 예에서는 기본 사용자 할당량을 설정하는 방법을 보여 줍니다. 자세한 매개 변수 정보는 Sun Java System Messaging Server 6.3 Administration Reference의 3 장, Messaging Server Configuration을 참조하십시오.

메시지 크기에 대한 기본 사용자 디스크 할당량(바이트)을 지정하려면:

configutil -o store.defaultmailboxquota -v [ -1 | number ]

여기서 -1은 할당량이 없는 것을 나타내고(메시지 사용 제한 없음) number는 바이트 수를 나타냅니다.

전체 메시지 수에 대한 기본 사용자 할당량을 지정하려면:

configutil -o store.defaultmessagequota -v [ -1 | number ]

여기서 -1은 할당량이 없는 것을 나타내고(메시지 제한 없음) number는 메시지 수를 나타냅니다.

특정 사용자의 기본 할당량을 지정하려면:

기본 메시지 저장소 할당량을 사용하는 사용자 항목에서 mailQuota 속성을 -2로 설정합니다. mailQuota가 지정되어 있지 않으면 시스템 기본 할당량이 사용됩니다.

20.8.4.2 개별 사용자 할당량 지정

사용자에 개별 할당량을 지정할 수 있습니다. 사용자별 할당량을 설정하려면 사용자의 LDAP 항목에 Sun Java Communications Suite 5 Schema ReferencemailQuota 또는 Sun Java Communications Suite 5 Schema ReferencemailMsgQuota 속성을 설정합니다(자세한 내용은 Sun Java System Messaging Server 6.3 Administration Referenceconfigutil Parameters 참조). 다음 예에서는 사용자 할당량을 설정하는 방법을 보여 줍니다.

시스템 기본 할당량을 지정하려면 LDAP 항목에 mailQuota를 추가하거나 –2로 설정하지 마십시오.

할당량을 1,000개의 메시지로 설정하려면 mailMsgQuota1000으로 설정합니다.

할당량을 2MB로 설정하려면 mailQuota2M 또는 2000000으로 설정합니다.

할당량을 2GB로 설정하려면 mailQuota2G 또는 2000000000 또는 2000M으로 설정합니다.

할당량을 2GB로, 음성 메일 할당량을 20MB로, Archive 폴더 할당량을 100MB로 지정하려면 다음을 수행합니다.

mailQuota: 2G;#voice%20M;Archive%100M

2GB의 할당량은 사용자의 메일함에서 명시적으로 할당량이 지정되지 않은 모든 폴더를 나타냅니다. 이 예에서는 Archive 폴더에 있는 메시지와 voice 유형의 메시지가 제외됩니다. 100MB의 할당량에는 Archive 폴더에 속한 모든 폴더의 메시지가 포함됩니다.

20.8.4.3 도메인 할당량 지정

도메인에 디스크 공간 또는 메시지 할당량을 설정할 수 있습니다. 이 할당량은 특정 도메인에 있는 모든 사용자에 대한 바이트 또는 메시지 수를 모두 누적한 값입니다. 도메인 할당량을 설정하려면 원하는 LDAP 도메인 항목에서 Sun Java Communications Suite 5 Schema ReferencemailDomainDiskQuota 또는 Sun Java Communications Suite 5 Schema ReferencemailDomainMsgQuota 속성을 설정합니다. .

할당량을 1,000개의 메시지로 설정하려면 mailDomainMsgQuota1000으로 설정합니다.

할당량을 2MB로 설정하려면 mailDomainDiskQuota2M 또는 2000000으로 설정합니다.

할당량을 2GB로 설정하려면 mailDomainDiskQuota2G 또는 2000000000 또는 2000M으로 설정합니다.

Procedure할당량 알림 설정 방법

할당량 알림은 사용자가 할당량에 가까와질 때 경고 메시지를 보내는 프로세스입니다. 이 기능을 사용하려면 세 가지 단계를 수행해야 합니다.

  1. 할당량 알림 활성화

    명령줄에서 다음을 실행합니다.

    configutil -o store.quotanotification -v [ yes | no ]

    메시지가 설정되지 않은 경우 할당량 경고 메시지가 사용자에게 보내지지 않습니다.

  2. 할당량 경고 메시지 정의

    경고 메시지는 디스크 할당량을 초과하려 하는 사용자에게 전송되는 메시지입니다. 명령줄에서 할당량 경고 메시지를 정의하려면 다음을 수행합니다.

    configutil -o store.quotaexceededmsg -v ’message

    메시지는 RFC 822 형식이어야 합니다. 즉, 메시지는 최소한 제목 줄이 들어있는 헤더를 포함하고 그 뒤에 $$와 메시지 본문이 와야 합니다. ’$’는 새 행을 나타냅니다. 사용 중인 쉘에 따라 $의 특수한 의미를 이스케이프하기 위해 $ 앞에 \를 추가해야 할 수 있습니다. $는 일반적으로 해당 쉘의 이스케이프 문자입니다. 예:

    configutil -o store.quotaexceededmsg -v ”Subject: WARNING: User quota exceeded$$User quota threshold exceeded - reduce space used.’

    또한 다음 변수가 지원됩니다.

    [ID] - 사용자 아이디

    [DISKUSAGE] - 디스크 사용

    [NUMMSG] - 메시지 수

    [PERCENT] - store.quotawarn 비율

    [QUOTA] - mailquota 속성

    [MSGQUOTA] - mailmsgquota 속성

    다음은 이러한 변수를 사용한 예입니다.

    configutil -o store.quotaexceededmsg -v ”Subject: Overquota Warning$$[ID],$$Your mailbox size has exceeded [PERCENT] of its alloted quota.$Disk Usage: [DISKUSAGE]$Number of Messages: [NUMMSG]$Mailquota: [QUOTA]$Message Quota: [MSGQUOTA]$$-Postmaster’

  3. 경고 메시지를 보내는 빈도 지정

    다음 매개 변수를 설정합니다.

    configutil -o store.quotaexceededmsginterval -v number

    여기서 number는 일 수를 나타냅니다. 예를 들어, 3은 메시지가 3일마다 보내진다는 것을 의미합니다.

  4. 할당량 임계값 지정

    할당량 임계값은 클라이언트에서 경고를 보내기 전에 초과되는 할당량의 비율입니다. 사용자의 디스크 사용량이 지정된 임계값을 초과하면 서버에서 사용자에게 경고 메시지를 보냅니다.


    주 –

    local.store.quotaoverdraft=on이면 store.quotawarn으로 설정한 임계값에 상관없이 사용자의 디스크 사용량이 할당량의 100%를 초과할 때까지 전자 메일 알림이 트리거되지 않습니다.


    클라이언트가 IMAP ALERT 기법을 지원하는 IMAP 사용자의 경우 사용자가 메일함을 선택할 때마다 사용자의 화면에 메시지가 표시되고 IMAP 로그에 메시지가 기록됩니다.

    명령줄에서 할당량 임계값을 지정하려면 다음을 수행합니다.

    configutil -o store.quotawarn -v number

    여기서 number는 허용되는 할당량의 비율을 나타냅니다.

20.8.4.4 할당량 적용 활성화 또는 비활성화

기본적으로 사용자 또는 도메인은 할당량 초과 알림을 받는 것 외에(설정된 경우) 다른 효과 없이 할당량을 초과할 수 있습니다. 할당량 적용은 디스크 사용량이 할당량 수준 이하로 떨어질 때까지 추가 메시지를 받지 않도록 메일함을 잠급니다.

할당량 적용을 활성화 또는 비활성화하려면 다음을 수행합니다.


configutil -o store.quotaenforcement -v [ on | off]

할당량 초과 메시지가 MTA 대기열에 저장되고 보낸 사람에게 메시지가 배달되지 않았지만 나중에 다시 배달 시도가 있을 것임을 나타내는 알림이 전송됩니다. 유예 기간이 만료되어 모든 메시지가 보낸 사람에게 되돌아가거나, 디스크 사용량이 할당량 아래로 떨어지고 메시지가 MTA 대기열에서 제외되고 메시지 저장소로 배달될 수 있을 때까지 배달 재시도가 계속됩니다. 메시지 대기열로 보내기 전에 할당량을 초과한 메시지를 돌려보내려면 다음 명령줄을 사용합니다.


configutil -o store.overquotastatus -v on

도메인 수준에서 할당량 적용을 활성화하는 방법

특정 도메인에 할당량을 적용하려면 다음 명령을 사용합니다.

imquotacheck -f -d domain

모든 도메인에 대해 사용하려면 -d 옵션을 제외합니다. 도메인이 할당량을 초과하면 maildomainstatus 속성이 overquota로 설정되어 해당 도메인에 대한 모든 전달이 중지됩니다. 도메인이 overquota가 아닌 경우 값은 active로 설정됩니다.

할당량 적용 비활성화

할당량을 비활성화했지만 사용자 할당량이 적용되는 것으로 표시되는 경우 다음 매개 변수를 확인합니다.

다음 configutil 매개 변수가 off이거나 설정되어 있지 않아야 합니다.

store.overquotastatuson일 경우 store.quotaoverdraft는 항상 on인 것으로 간주됩니다. 그렇지 않을 경우 사용자가 할당량을 초과하여 거부를 트리거하는 일이 없습니다. 또한 store.quotaoverdrafton이면 할당량보다 작은 하나의 메시지만 사용자에게 허용됩니다. 즉, 사용자의 할당량보다 큰 메시지는 허용되지 않습니다.

이 매개 변수를 변경한 후에는 메시징 서비스를 다시 시작해야 합니다.

다음 메시지 저장소 속성을 활성화해야 합니다.

할당량 적용 구성에 상관없이 메일함 할당량보다 큰 메시지는 바운스됩니다.

20.8.4.5 유예 기간 설정

유예 기간은 메시지를 보낸 사람에게 다시 바운스하기 전까지 메일함이 할당량(디스크 공간 또는 메시지 수)을 초과할 수 있는 기간을 지정합니다. 유예 기간은 메시지가 메시지 대기열에 보관되는 기간이 아니라 메시지 대기열에 있는 메시지를 비롯하여 모든 받는 메시지가 바운스되기 전까지 메일함이 할당량을 초과할 수 있는 기간입니다. 자세한 내용은 20.1 개요를 참조하십시오. 유예 기간은 사용자가 할당량 임계값에 도달하여 경고를 받으면 시작됩니다. 할당량 알림 설정 방법을 참조하십시오.

명령줄에서 할당량 유예 기간을 지정하려면 다음을 수행합니다.

configutil -o store.quotagraceperiod -v number

여기서 number는 시간을 나타냅니다.

20.8.4.6 Netscape Messaging Server 할당량 호환 모드

Netscape Messaging Server에서는 디스크 사용량이 할당량을 초과한 경우 메시지 전달을 지연 또는 바운스하고 할당량 초과 알림을 보낸 다음 유예 기간을 시작했습니다. Messaging Server는 이 동작을 유지하는 local.store.quotaoverdraft 매개 변수를 제공합니다.

ON으로 설정하면 디스크 사용량이 할당량을 초과할 때까지 메시지가 전달됩니다. 할당량을 초과하면 메시지가 지연되고(메시지는 MTA 메시지 대기열에 보관되지만 메시지 저장소로 전달되지 않음) 할당량 초과 경고 메시지가 사용자에게 보내지며 유예 기간이 시작됩니다. 유예 기간은 할당량 초과 메시지가 바운스될 때까지 메일함의 할당량이 초과되어 있는 기간을 결정합니다. 기본값은 메시지 저장소가 임계값에 도달할 때 할당량 경고 메시지를 보냅니다. 이 매개 변수의 기본값은 Off입니다.

20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법

자동 메시지 제거 기능(만료 및 제거라고도 함)은 관리자가 정의한 일련의 기준을 기반으로 메시지 저장소에서 메시지를 자동으로 제거합니다. 이전 메시지가나 과도하게 큰 메시지, 보았거나 삭제한 메시지, 특정 Subject: 행을 가진 메시지 등을 자동으로 제거하는 데이 기능을 사용할 수 있습니다. 이 기능은 다음 제거 기준을 허용합니다.

이 기능은 메시지를 정리 및 제거하는 imexpire 유틸리티에 의해 수행됩니다. 메시지 제거 프로세스에 대한 자세한 내용은 20.3 메시지 저장소에서 메시지를 제거하는 방법을 참조하십시오.


주 –

서버는 경고 없이 메시지를 제거하므로 자동 메시지 제거 정책을 사용자에게 알리는 것이 중요합니다. 메시지가 갑작스럽게 제거되면 사용자와 관리자가 매우 당황할 수 있습니다.


20.9.1 imexpire 작동 원리

imexpire는 명령줄에서 호출하거나 imsched 데몬에 의해 자동으로 실행되도록 예약할 수 있습니다. 관리자는 store.expirerule 이라는 파일에 만료 규칙 집합을 지정합니다. 이 파일은 메시지 제거 기준을 지정합니다. 각각 규칙 범위와 관련된 디렉토리에 저장된 여러 개의 파일이 있을 수 있습니다. 즉, 전체 메시지 저장소에 전역적으로 적용되는 규칙과 특정 분할 영역에 적용되는 규칙, 그리고 사용자에 적용되는 규칙이 각각 다른 디렉토리에 저장됩니다.


주 –

configutil 명령과 store.expire.attribute 매개 변수를 사용하여 전역 만료 규칙을 지정할 수도 있지만 store.expirerule을 사용하여 규칙을 지정하는 것이 더 좋습니다. configutil을 사용하여 너무 많은 규칙을 만들면 성능 문제가 발생할 수 있습니다.


imexpire는 시작 시에 모든 만료 규칙을 로드합니다. 기본적으로 imexpire는 분할 영역 당 하나의 스레드를 만듭니다. 각 스레드는 할당된 분할 영역 아래의 사용자 폴더 목록을 거치는 과정에서 로컬 만료 규칙 파일을 로드합니다. 이 만료 기능은 각 폴더에 적용 가능한 만료 규칙에 대해 해당 폴더를 검사하고 필요에 따라 메시지를 정리합니다. 메일함 디렉토리에 store.exp 파일이 있고 store.cleanupage 구성 매개 변수에 지정된 시간보다 오래 정리/만료된 메시지가 있을 경우 제거 기능은 메시지 해시 디렉토리의 모든 메시지 파일을 영구적으로 제거하고 store.exp 파일에서 UID 레코드를 제거합니다.

또한 msg-svr-base/config/에 있는 expire_exclude_list라는 파일에 한 행씩 사용자 아이디를 추가하여 지정된 사용자를 만료 규칙에서 제외할 수 있습니다.

20.9.2 자동 메시지 제거 기능 배포

자동 메시지 제거는 다음 세 단계로 구성됩니다.

  1. 자동 메시지 제거 정책을 정의합니다. 자동으로 제거할 메시지는 무엇입니까? 메시지가 자동으로 제거될 사용자, 폴더, 도메인 및 분할 영역은 무엇입니까? 제거 기준을 정의하는 크기, 메시지 기간 및 헤더는 무엇입니까? 제거할 메시지 범위를 정의합니다. 20.9.2.1 자동 메시지 제거 정책 정의을 참조하십시오.

  2. 이 정책을 구현하기 위한 imexpire 규칙을 지정합니다. 20.9.2.2 자동 메시지 제거 정책을 구현하는 규칙 설정 방법을 참조하십시오.

  3. imexpire 일정을 지정합니다. 20.9.2.3 자동 메시지 제거 및 로깅 수준 예약을 참조하십시오.

20.9.2.1 자동 메시지 제거 정책 정의

제거 기준을 지정하여 자동 메시지 제거 정책을 정의합니다. imexpire에서는 다음 기준을 제거에 사용할 수 있습니다.

메시지 기간. X일보다 오래된 메시지를 자동으로 제거합니다(속성: messagedays).

메시지 수. X개의 메시지를 초과하는 폴더의 메시지를 자동으로 제거합니다(속성: messagecount).

크기를 초과하는 메시지의 기간.Y일의 유예 기간 후에 X바이트를 초과한 메시지를 자동으로 제거합니다(속성: messagesizemessagesizedays).

조회 삭제됨 메시지 플래그. 조회 또는 삭제됨 플래그가 설정된 메시지를 자동으로 제거합니다. 이 기준은 "and" "or"로 설정할 수 있습니다. or로 설정된 경우 메시지의 조회/삭제 플래그는 다른 기준에 상관 없이 메시지를 자동으로 삭제합니다. and로 설정된 경우 다른 모든 기준을 충족하면서 메시지의 조회/삭제 플래그를 설정해야 합니다. (속성: seendeleted).

메시지의 헤더 필드. 메시지 제거 기준으로 사용할 헤더와 문자열을 지정할 수 있습니다(예: "Subject: Work from Home!").

메시지 폴더. 메시지를 제거할 폴더를 지정할 수 있습니다(속성: folderpattern). 이 속성은 수정된 UTF-7 문자 세트만 사용합니다.


주 –

imexpire에서는 메시지를 읽은 후로 경과한 시간에 따라 메시지를 삭제하거나 보존하도록 허용하지 않습니다. 예를 들어, 200일 동안 읽지 않은 메시지를 제거하도록 지정할 수 없습니다.


자동 메시지 제거 정책의 예

예 1: 1,000개의 메시지를 초과하는 폴더에서 365일이 지난 모든 메시지를 제거합니다.

예 2: siroe.com 도메인에서 180일이 지난 메시지를 제거합니다.

예 3: 삭제됨으로 표시된 모든 메시지를 제거합니다.

예 4: 조회 표시가 있고 30일이 지났으며 100KB보다 크고 폴더의 메시지 수가 1,000개를 초과하며 X-spam 헤더가 있는 메시지를 sesta.com에서 제거합니다.

20.9.2.2 자동 메시지 제거 정책을 구현하는 규칙 설정 방법

이전 절에서 정의한 자동 메시지 제거 정책을 구현하려면 imexpire 규칙을 설정해야 합니다. store.expirerule 파일에 규칙을 포함하면 규칙이 설정됩니다. 다음은 두 개의 전역 store.expirerule 규칙을 보여 주는 예입니다.


Rule1.regexp: 1
Rule1.folderpattern: user/.*/trash
Rule1.messagedays: 2
Rule2:regexp: 1
Rule2.folderpattern: user/.*
Rule2.messagedays: 14

            

이 예에서 Rule 1은 휴지통 폴더의 모든 메시지가 2일 후에 제거되도록 지정합니다. Rule 2는 메시지 저장소의 모든 메시지가 14일 후에 제거되도록 지정합니다.

이 절은 다음과 같은 하위 절로 구성되어 있습니다.

만료 규칙 지침

이 절에서는 store.expirerule 파일 규칙에 대한 지침을 설정합니다.


주 –

이전의 Messaging Server 릴리스에서는 configutil 매개 변수 store.expirerule.attribute를 사용하여 만료 규칙을 설정할 수 있었습니다(Sun Java System Messaging Server 6.3 Administration Referenceconfigutil Parameters 참조).이는 여전히 유효하지만 헤더 제약 조건을 사용하는 만료 규칙(예: 특정 제목 줄을 가진 메시지를 만료하는 것)은 지원되지 않습니다. 어떤 경우에서든 store.expirerule을 사용하여 모든 만료 규칙을 지정하는 것이 가장 좋습니다.


표 20–8 imexpire 속성

속성 

설명(속성 값) 

action

만료 규칙에 걸린 메시지에서 수행할 작업을 지정합니다. 가능한 값은 다음과 같습니다. 

discard는 메시지를 삭제합니다. 기본값입니다.

report 작업은 메일함 이름과 uid-validity 및 uid를 stdout에 출력합니다.

archive는 Sun Compliance 및 Content Management System에 메시지를 아카이브로 보관한 다음 메시지를 삭제합니다.

fileinto: folder 작업은 메시지를 특정 폴더에 넣습니다. 공유 폴더 접두사를 사용하면 메시지를 다른 사용자가 소유한 폴더에 넣을 수 있습니다.

exclusive

해당 규칙이 배타적인지 여부를 지정합니다. exclusive로 지정된 경우 해당 규칙만 지정된 메일함에 적용되며 다른 모든 규칙은 무시됩니다. 둘 이상의 배타적인 규칙이 존재할 경우 마지막으로 로드된 규칙이 사용됩니다. 예를 들어, 전역 및 로컬 배타적인 규칙을 지정할 경우 로컬 규칙이 사용됩니다. 둘 이상의 배타적인 전역 규칙이 있을 경우 configutil에서 나열한 마지막 전역 규칙이 사용됩니다. (1/0)

folderpattern

해당 규칙의 영향을 받는 폴더를 지정합니다. 형식은 store_root /partition/*/ 디렉토리를 나타내는 user/로 시작해야 합니다. 표 20–9를 참조하십시오. (POSIX 정규 표현식).

messagecount

폴더의 최대 메시지 수입니다. 추가 메시지가 전달되면 가장 오래된 메시지가 정리됩니다. (정수) 

foldersize

추가 메시지가 전달되었을 때 가장 오래된 메시지가 정리되기 전까지의 최대 폴더 크기입니다. (바이트 단위 정수) 

messagedays

메시지가 정리되기 전까지의 메시지 기간(일)입니다. (정수) 

messagesize

메시지가 정리되는 것으로 표시되기 전까지의 메시지의 최대 크기(바이트)입니다. (정수) 

messagesizedays

유예 기간입니다. 크기를 초과한 메시지가 폴더에 남아 있어야 하는 일 수입니다. (정수) 

messageheader.header

제거할 메시지를 표시하는 헤더 필드와 문자열을 지정합니다. 값은 대소문자를 구분하지 않으며 정규 표현식은 인식되지 않습니다. 예: Rule1.messageheader.Subject: Get Rich Now!

ExpiresExpiry-Date 헤더의 경우 imexpire는 이러한 헤더 필드로 지정한 날짜 값이 messagedays 속성보다 오래 되었으면 메시지를 제거합니다. 여러 개의 만료 헤더 필드를 지정한 경우에는 가장 이른 만료 날짜가 사용됩니다. (문자열)

regexp

규칙 작성에 UNIX 정규 표현식을 사용 가능하게 합니다. (1 또는 0) 지정하지 않으면 IMAP 표현식이 사용됩니다. 

savedays

메시지가 정리될 때까지 폴더에 저장되는 시간(일 수)입니다. 

seen

seen은 사용자가 메시지를 열었을 때 시스템에 의해 설정되는 메시지 상태 플래그입니다. seen 속성이 and로 설정된 경우 메시지를 보는 것 외에도 다른 기준을 충족해야 규칙이 적용됩니다. seen 속성이 or로 설정된 경우 메시지를 보았거나 또는 다른 기준을 충족하면 규칙이 적용됩니다. (and/or)

sieve

메시지 선택 기준을 지정하는 시브(Sieve) 규칙입니다. 예: Rule17.sieve: header :contains “Subject” “Vigara”

deleted

deleted는 사용자가 메시지를 삭제했을 때 시스템에 의해 설정되는 메시지 상태 플래그입니다. deleted 속성이 and로 설정된 경우 메시지를 삭제한 것 외에도 다른 기준을 충족해야 규칙이 적용됩니다. deleted 속성이 or로 설정된 경우 메시지를 삭제했거나 또는 다른 기준을 충족하면 규칙이 적용됩니다. (and/or)

현지화된 메일함 이름

IMAP 프로토콜은 메일함 이름에 수정된 UTF-7 인코딩을 사용하도록 지정합니다. Messaging Server는 메일함 이름을 현지화할 수 있도록 외부 인터페이스에서 현지화된 문자 세트를 지원합니다. 하지만 내부에서 시스템은 현지화된 이름을 UTF-7로 변환합니다. 따라서 클라이언트에 현지화된 메일함 이름이 있는 폴더는 그에 해당되는 UTF-7로 된 메일함 파일 이름을 가집니다(IMAP 오류 메시지에서는 메일함 이름을 현지화된 문자 세트가 아닌 UTF-7로 출력)

일반적으로 메일함 이름이 필요한 대부분의 메시지 저장소 유틸리티는 현지화된 문제 세트로 된 이름을 사용하지만 다른 문자 세트를 사용할 수 있는 옵션 플래그가 있을 수도 있습니다. 이러한 유틸리티에는 reconstruct, mboxutil, imsbackup, imsrestorehashdir가 있습니다. 하지만 imexpirefolderpattern 속성으로 지정되는 메일함 이름이 UTF-7로 되어 있어야 합니다. 현지화된 이름은 사용할 수 없습니다.

imexpire에 적절한 folderpattern을 얻으려면 현지화된 메일함 이름을 수정된 UTF-7 이름으로 변환해야 할 수도 있습니다. mboxutil -E 명령을 사용하여 다음과 같이 수행하면 됩니다.

현지화된 파일 이름과 수정된 UTF-7 파일 이름을 보여 주는 mboxutil

첫 번째 mboxutil은 현지화된 파일 이름을 나타냅니다. 두 번째 mboxutil은 수정된 UTF-7의 파일 이름을 나타냅니다. IMAP list 명령을 사용할 수도 있습니다.

IMAP list 명령

텍스트 형식으로 imexpire 규칙 설정

자동 메시지 제거 규칙은 store.expirerule 파일에서 규칙을 지정하여 설정합니다. store.expirerule 파일에는 한 행에 하나씩 만료 기준이 있습니다. 전역 규칙 구성 파일(msg-svr-base/data/store/store.expirerule)의 만료 기준 형식은 다음과 같습니다.

rule_name.attribute: value

사용자 또는 메일함 규칙 구성 파일의 만료 규칙 형식은 다음과 같습니다.

attribute: value

예 20–4에서는 msg-svr-base/config/store.expirerule의 전역 만료 규칙 집합을 보여 줍니다.

Rule 1은 다음과 같이 전역 만료 정책(즉, 모든 메시지에 적용되는 정책)을 설정합니다.

Rule 2는 호스트된 도메인 siroe.com에서 사용자에 대한 자동 메시지 제거 정책을 설정합니다. 이 규칙은 메일함 크기를 1MB로 제한하고 삭제된 메시지를 제거하며 14일이 지난 메시지를 제거합니다.

Rule 3은 f.dostoevski 사용자의 inbox 폴더에 있는 메시지에 대한 자동 메시지 제거 정책을 설정합니다. 이 규칙은 제목 줄에 "On-line Casino" 라는 표현이 있는 메시지를 제거합니다.


예 20–4 imexpire 규칙 예


Rule1.regexp: 1
Rule1.folderpattern: user/.*
Rule1.messagesize: 100000
Rule1.messagesizedays: 3
Rule1.deleted: or
Rule1.Subject: Vigara Now!
Rule1.Subject: XXX Porn!
Rule1.messagecount: 1000
Rule1.messagedays: 365
Rule2.regexp: 1
Rule2.folderpattern: user/.*@siroe.com/.*Rule2.exclusive: 1
Rule2.deleted: or
Rule2.messagedays: 14
Rule2.messagecount: 1000
Rule3.folderpattern: user/f.dostoevski/inboxRule3.Subject: *On-line Casino*
                  

imexpire 폴더 패턴 설정

POSIX 정규 표현식을 사용하여 imexpire 속성 regex를 1로 설정함으로써 폴더 패턴을 지정할 수있습니다. 지정하지 않으면 IMAP 표현식이 사용됩니다. user/로 시작되고 뒤에 패턴이 나오는 형식이어야 합니다. 표 20–9에서는 다양한 폴더의 폴더 패턴을 보여 줍니다)

표 20–9 정규 표현식을 사용한 imexpire 폴더 패턴

폴더 패턴 

범위 

user/userid/.*

userid의 모든 폴더에 있는 모든 메시지에 적용됩니다.

user/userid/Sent

Sent 폴더에 있는 userid의 메시지에 규칙을 적용합니다.

user/.*

메시지 저장소 전체에 규칙을 적용합니다. 

user/.*/trash

모든 사용자의 trash 폴더에 규칙을 적용합니다.

user/.*@siroe.com/.*

호스트된 도메인 siroe.com의 폴더에 규칙을 적용합니다. 

user/[^@]*/.*

기본 도메인에 있는 폴더에 규칙을 적용합니다. 

20.9.2.3 자동 메시지 제거 및 로깅 수준 예약

자동 메시지 제거는 imsched 예약 데몬에 의해 활성화됩니다. 기본적으로 imsched는 매일 23시에 imexpire를 호출하여 메시지를 정리 및 제거합니다. 이 일정은 표 20–10에 설명된 configutil 매개 변수 local.schedule.expirestore.cleanupage를 설정하여 사용자 정의할 수 있습니다.

메시지 저장소가 큰 경우 만료와 제거를 완료하는 데 시간이 걸릴 수 있으므로 이러한 프로세스를 실행하는 빈도를 실험하여 결정하는 것이 필요할 수 있습니다. 예를 들어, 만료/제거 주기가 10시간일 경우 만료 및 제거를 하루에 한 번씩 실행하도록 기본 일정을 세우지는 않을 것입니다. 일정은 imexpire 명령 및 자동 작업 예약 매개 변수를 사용하여 만료 및 제거됩니다( 4.6 자동 작업 예약 참조). 예를 들면 다음과 같습니다.


configutil -o local.schedule.expire -v "0 1 * * 6 /opt/SUNWmsgsr/sbin/imexpire -e"
configutil -o local.schedule.mspurge -v "0 23 * * * /opt/SUNWmsgsr/sbin/imexpire -c"

이 예에서 메시지는 토요일 오전 1시에 만료되고 매일 밤 11시에 제거됩니다. 제거 일정이 설정되어 있지 않으면 imexpire에서 만료 후에 제거를 수행합니다.

표 20–10 만료 및 제거 configutil 로그 및 예약 매개 변수

매개 변수 

설명 

local.schedule.expire

imexpire를 실행하는 간격입니다. 다음 UNIX crontab 형식을 사용합니다. minute hour day-of-month month-of-year day-of-week

값은 공백이나 탭으로 구분하며 각각 0-59, 0-23, 1-31, 1-12 및 0-6(0=일요일)의 값을 사용할 수 있습니다. 각 시간 필드에는 별표(유효한 모든 값), 쉼표로 구분된 값 목록 또는 하이픈으로 구분된 두 값의 범위를 사용할 수 있습니다. 날짜는 일과 요일 모두를 사용하여 지정할 수 있지만 둘 다 일치하는 경우가 매우 드물기 때문에 일반적이지 않습니다. 일과 요일을 모두 지정한 경우에는 둘 다 필요합니다. 예를 들어, 17일과 화요일을 설정하면 두 값이 모두 true가 되어야 합니다. 

imexpire-e-c 플래그를 사용하여 각각 만료만 하도록 또는 제거만 하도록 할 수도 있습니다. Sun Java System Messaging Server 6.3 Administration Referenceimexpire를 참조하십시오.

간격 예:

1) 오전 12:30 , 8:30 및 오후 4:30에 imexpire를 실행합니다.

30 0,8,16 * * * /opt/SUNWmsgsr/sbin/imexpire

2) 주중 아침 3:15에 imexpire를 실행합니다.

15 3 * * 1-5 /opt/SUNWmsgsr/sbin/imexpire

3) 월요일에만 imexpire를 실행합니다.

0 0 * * 1 /opt/SUNWmsgsr/sbin/imexpire

기본값:  

0 23 * * * /opt/SUNWmsgsr/sbin/imexpire

비활성화하려면local.schedule.expire.enableNO로 설정합니다.

store.cleanupage

만료 또는 정리된 메시지가 purge에 의해 영구적으로 제거된 전까지의 기간(시간)입니다.

기본값: 없음 

local.store.expire.loglevel

다음과 같이 로그 수준을 지정합니다. 

1 = 전체 만료 세션의 요약을 기록합니다.  

2 = 만료된 메일함별로 하나씩 메시지를 기록합니다.  

3 = 만료된 메일별로 하나씩 메시지를 기록합니다. 

기본값: 1 

imexpire 로깅 수준 설정

imexpire는 완료 시에 기본 로그 파일에 대한 요약을 기록합니다. 명령줄에서 만료가 호출될 경우 -v(verbose) 및 -d(debug) 옵션을 사용하여 자세한 상태/디버그 메시지를 stderr에 기록하도록 imexpire에 지시할 수 있습니다. imexpireimsched에 의해 호출될 경우 configutil 매개 변수 local.store.expire.loglevel을 여러 다른 로깅 수준에 대해 1,2 또는 3으로 설정할 수 있습니다. Loglevel 1은 기본값으로 전체 만료 세션의 요약을 기록합니다. Loglevel 2는 만료된 메일함별로 하나씩의 메시지를 기록합니다. 마지막으로 Loglevel 3은 만료된 메시지별로 하나씩의 메시지를 기록합니다.

자동 메시지 제거에서 지정된 사용자 제외

msg-svr-base /config/에 있는 expire_exclude_list라는 파일에 한 행씩 사용자 아이디를 추가하여 지정된 사용자를 만료 규칙에서 제외할 수 있습니다. 또는 사용자의 메일함에 배타적인 더미 만료 규칙을 구성합니다.

20.10 메시지 저장소 분할 영역 구성

메일함은 전적으로 메시지 저장소를 저장하는 디스크 분할 영역의 한 영역인 메시지 저장소 분할 영역에 저장됩니다. 메시지 저장소 분할 영역은 디스크 분할 영역과 다르지만 유지 관리가 용이하도록 각 메시지 저장소 분할 영역에 대해 하나의 디스크 분할 영역과 하나의 파일 시스템을 가지는 것이 좋습니다. 메시지 저장소 분할 영역은 특별히 메시지 저장소로 지정된 디렉토리입니다.

사용자 메일함은 기본적으로 store_root/partition/ 디렉토리에 저장됩니다( 20.2 메시지 저장소 디렉토리 레이아웃 참조). partition 디렉토리는 하나 또는 여러 개의 분할 영역을 포함할 수 있는 논리 디렉토리입니다. 시작 시에 partition 디렉토리는 primary 분할 영역이라는 하위 분할 영역을 포함합니다.

필요에 따라 분할 영역을 partition 디렉토리에 추가할 수 있습니다. 예를 들어, 단일 디스크를 분할하여 다음과 같이 사용자를 구성할 수 있습니다.


store_root/partition/mkting/
store_root/partition/eng/
store_root/partition/sales/

디스크 저장소 요구 사항이 늘어나면 이러한 분할 영역을 다른 물리적 디스크 드라이브에 매핑할 수 있습니다.

한 디스크의 메일함 수를 제한해야 합니다. 여러 디스크로 메일함을 분산시키면 메시지 전달 시간이 향상됩니다(SMTP 수락율을 변경할 필요는 없음). 디스크별로 할당하는 메일함 수는 디스크 용량과 각 사용자에게 할당되는 디스크 공간에 따라 다릅니다. 예를 들어, 사용자별로 더 적은 디스크 공간을 할당할 경우 디스크별로 더 많은 메일함을 할당할 수 있습니다.

메시지 저장소에 여러 개의 디스크가 필요한 경우에는 RAID(Redundant Array of Inexpensive Disks) 기술을 사용하여 편리하게 여러 디스크를 관리할 수 있습니다. RAID 기술을 사용하면 일련의 디스크에서 데이터를 분산시킬 수 있지만 디스크가 하나의 논리 볼륨으로 나타나므로 관리가 간단해집니다. 또한 오류 복구 목적으로 저장소를 복제하기 위해(즉, 중복을 위해) RAID 기술을 사용할 수도 있습니다.


주 –

디스크 액세스를 향상시키려면 메시지 저장소와 메시지 대기열이 별개의 디스크에 상주해야 합니다.


20.10.1 분할 영역 추가

분할 영역을 추가할 때에는 디스크상에 분할 영역이 저장되는 절대 물리 경로와 논리 이름(분할 영역 별명이라고 함)을 지정합니다.

분할 영역 별명을 사용하면 물리 경로에 상관 없이 사용자를 논리 분할 영역 이름에 매핑할 수 있습니다. 사용자 계정을 설정하고 사용자의 메시지 저장소를 지정할 때 분할 영역 별명을 사용할 수 있습니다. 입력하는 이름은 소문자를 사용하는 알파벳 이름이어야 합니다.

분할 영역을 작성 및 관리하려면 서버를 실행하는 데 사용되는 사용자 아이디가 물리 경로에 지정된 위치에 쓸 수 있는 권한을 가져야 합니다.


주 –

분할 영역을 추가한 후에 서버를 중지했다가 다시 시작하여 구성 정보를 갱신해야 합니다.


Procedure메시지 저장소 분할 영역 추가 방법

  1. 명령줄, 명령줄에서 저장소에 분할 영역을 추가하려면 다음을 수행합니다.

    configutil -o store.partition.nickname.path -v path

    여기서 nickname은 분할 영역의 논리 이름이고 path는 분할 영역이 저장되는 절대 경로 이름을 나타냅니다.

    기본 주 분할 영역의 경로를 지정하려면 다음을 수행합니다.


    configutil -o store.partition.primary.path -v path
    

20.10.2 메일함을 다른 디스크 분할 영역으로 이동

기본적으로 메일함은 primary 분할 영역에 만들어집니다. 분할 영역이 가득 차면 추가 메시지를 저장할 수 없습니다. 이 문제는 다음의 여러 방법으로 해결할 수 있습니다.

볼륨 관리 소프트웨어를 사용하여 시스템에 다른 디스크 공간을 추가하는 것이 사용자에게 가장 투명한 절차이기 때문에 가능하면 이 방법을 사용하는 것이 좋습니다. 그러나 메일함을 다른 분할 영역으로 이동할 수도 있습니다.

Procedure메일함을 다른 디스크 분할 영역으로 이동

  1. 마이그레이션하는 도중에 사용자가 메일함과 연결되지 않게 합니다. 이렇게 하려면 사용자에게 로그오프하고 메일함을 이동하는 동안 메일함을 사용하지 않도록 지시하거나 사용자가 로그오프한 후에 POP, IMAP 및 HTTP 서비스를 허용하지 않도록 mailAllowedServiceAccess 속성을 설정합니다. Sun Java Communications Suite 5 Schema ReferencemailAllowedServiceAccess를 참조하십시오.


    주 –

    POP, IMAP 및 HTTP 액세스를 허용하지 않도록 mailAllowedServiceAccess를 설정해도 메일함에 대한 열린 연결이 끊기지 않습니다. 따라서 메일함을 이동하기 전에 모든 연결이 닫혔는지 확인해야 합니다.


  2. 다음 명령을 사용하여 사용자 메일함을 이동합니다.

    mboxutil -r user/<userid>/INBOX user/<userid>/INBOX < partition_name>

    예:

    mboxutil -r user/ofanning/INBOX user/ofanning/INBOX secondary

  3. 이동한 사용자의 LDAP 항목에서 mailMessageStore 속성을 새 분할 영역의 이름으로 설정합니다.

    예: mailMessageStore: secondary

  4. 이제 메시지 저장소 연결이 허용된다는 것을 사용자에게 알립니다. 해당하는 경우 mailAllowedServiceAccess 속성을 변경하여 POP, IMAP 및 HTTP 서비스를 허용합니다.

20.10.3 기본 메시지 저장소 분할 영역 정의 변경

기본 분할 영역은 사용자를 만들 때 사용자 항목에 mailMessageStore LDAP 속성을 지정하지 않은 경우에 사용되는 분할 영역입니다. 기본 분할 영역이 필요하지 않도록 사용자의 메시지 저장소 분할 영역을 지정하는 mailMessageStore LDAP 속성을 모든 사용자 항목에 지정해야 합니다. 또한 로드 균형 조정이나 기타 이유 때문에 기본 분할 영역을 변경하면 안 됩니다. 기분 분할 영역 정의에 의존하는 사용자가 있는 상태에서 기본 분할 영역을 변경하는 것은 적절하지 않으며 위험합니다.

기본 분할 영역을 꼭 변경해야 할 경우에는 configutil 매개 변수 store.defaultpartition을 사용하여 기본값 정의를 변경하기 전에 이전의 기본 분할 영역(남겨진 것)의 모든 사용자가 mailMessageStore 속성을 현재 분할 영역(더 이상 기본값이 아닌)으로 설정해야 합니다.

20.11 메시지 저장소 유지 관리 절차 수행

이 절에서는 메시지 저장소의 유지 관리 및 복구 작업을 수행하는 데 사용되는 유틸리티에 대해 설명합니다. 관리자는 항상 포스트마스터 메시지를 읽어 서버가 보낼 수 있는 주의와 경고를 확인해야 합니다. 또한 로그 파일에서 서버의 작동 상태에 대한 정보를 모니터해야 합니다. 로그 파일에 대한 자세한 내용은 25 장, 로깅 관리을 참조하십시오.

이 절은 다음 내용으로 구성되어 있습니다.

20.11.1 메시지 저장소에 물리적 디스크 추가

Messaging Server 메시지 저장소는 특정 Messaging Server 인스턴스에 대한 사용자 메일함을 포함합니다. 메일함, 폴더 및 로그 파일 수가 늘어나면 메시지 저장소의 크기가 늘어납니다.

시스템에 다른 사용자를 추가하면 디스크 저장소 요구 사항이 증가합니다. 서버가 지원하는 사용자 수에 따라 메시지 저장소는 하나 또는 여러 개의 물리적 디스크가 필요할 수 있습니다. Messaging Server를 사용하면 필요에 따라 저장소를 추가할 수 있습니다. 저장소를 추가하는 한 가지 방법은 저장 장치를 사용하는 것입니다. Messaging Server를 사용하여 Network Appliance 저장 장치를 구성하는 방법에 대한 자세한 내용은 Using NetApp Filers with Sun Java System Messaging Server Message Store를 참조하십시오.

20.11.2 메일함 관리

이 절에서는 mboxutil, hashdir, readership과 같은 메일함 관리 및 모니터링 유틸리티에 대해 설명합니다.

20.11.2.1 mboxutil 유틸리티

mboxutil 명령을 사용하여 메일함에 대한 일반적인 유지 관리 작업을 수행합니다. mboxutil 작업은 다음을 포함됩니다.


주 –

mboxutil 프로세스를 실행 도중에 종료해서는 안 된다는 것을 유의하십시오. SIGKILL(kill -9)을 사용하여 중지할 경우 모든 서버를 다시 시작하고 복구를 수행해야 할 수 있습니다.


자세한 구문 및 사용 요구 사항은 Sun Java System Messaging Server 6.3 Administration Referencemboxutil을 참조하십시오.

모든 사용자의 모든 메일함을 나열하려면 다음을 수행합니다.

mboxutil -l

모든 메일함을 나열하고 또한 경로와 ACL 정보를 포함하려면 다음을 수행합니다.

mboxutil -l -x

사용자 daphne에 대해 INBOX라는 기본 메일함을 만들려면 다음을 수행합니다.

mboxutil -c user/daphne/INBOX

사용자 delilah에 대해 projx라는 메일 폴더를 삭제하려면 다음을 수행합니다.

mboxutil -d user/delilah/projx

사용자 druscilla에 대해 INBOX라는 기본 메일함과 모든 메일 폴더를 삭제하려면 다음을 수행합니다.

mboxutil -d user/druscilla/INBOX

사용자 desdemona에 대해 메일 폴더 memos의 이름을 memos-april로 바꾸려면 다음을 수행합니다.

mboxutil -r user/desdemona/memos user/desdemona/memos-april

사용자 dimitria에 대한 메일 계정을 새 분할 영역으로 이동하려면 다음을 수행합니다.

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

여기서 partition은 새 분할 영역의 이름을 지정합니다.

사용자 dimitria에 대해 personal이라는 메일 폴더를 새 분할 영역으로 이동하려면 다음을 수행합니다.

mboxutil -r user/dimitria/personal user/dimitria/personal partition

20.11.2.2 고아 계정 제거

고아 계정(LDAP에 해당 항목이 없는 메일함)을 검색하려면 다음 명령을 사용합니다.


mboxutil -o

명령 출력은 다음과 같습니다.

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

고아 메일함을 삭제하여 스크립트 파일로 변환될 수 있는 고아 메일함을 나열하는 orphans.cmd라는 이름의 파일을 만들려면 다음 명령을 사용합니다.


mboxutil -o -w orphans.cmd

명령 출력은 다음과 같습니다.

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

다음 명령을 사용하여 고아 파일을 삭제합니다.


mboxutil -d -f orphans.cmd

20.11.2.3 hashdir 유틸리티

메시지 저장소의 메일함은 빠른 검색을 위해 해시 구조에 저장됩니다. 결과적으로 특정 사용자의 메일함을 포함하는 디렉토리를 찾으려면 hashdir 유틸리티를 사용합니다.

이 유틸리티는 특정 계정의 메시지 저장소를 포함하는 디렉토리를 식별합니다. 이 유틸리티는 메시지 저장소에 상대적인 경로(예: d1/a7/)를 보고합니다. 이 경로는 사용자 아이디 기반 디렉토리의 바로 앞에 있는 디렉토리 수준에 상대적입니다. 이 유틸리티는 경로 정보를 표준 출력으로 보냅니다.

예를 들어, 사용자 crowe에 대한 메일함의 상대 경로를 찾으려면 다음을 수행합니다.

hashdir crowe

20.11.2.4 readership 유틸리티

readership 유틸리티는 공유 IMAP 폴더의 메시지를 읽은 메일함 소유자 이외의 사용자 수를 보고합니다.

IMAP 폴더 소유자는 폴더의 메시지를 읽는 권한을 다른 사용자에게 부여할 수 있습니다. 다른 사람에게 액세스가 허용되는 폴더를 공유 폴더라고 합니다. 관리자는 readership 유틸리티를 사용하여 공유 폴더를 액세스하는 소유자 이외의 사용자 수를 확인할 수 있습니다.

이 유틸리티는 모든 메일함을 스캔한 후 공유 폴더별로 한 행씩의 출력을 생성하여 읽은 사람 수(뒤에 공백과 메일함 이름이 옴)를 보고합니다.

각 읽은 사람은 이전의 지정된 일 수 동안 공유 폴더를 선택했던 고유한 인증 아이디입니다. 자신의 고유한 메일함을 읽을 때는 사용자가 계산되지 않습니다. 폴더 소유자 외에 최소 한 명 이상의 읽은 사람이 존재하지 않을 경우 개인 메일함은 보고되지 않습니다.

예를 들어, 다음 명령은 마지막 15일 동안에 공유 IMAP 폴더를 선택한 모든 아이디를 읽은 사람으로 계산합니다.

readership -d 15

20.11.3 최대 메일함 크기

메일함의 최대 크기는 약 100만 개의 메시지에 해당됩니다. 메시지가 이보다 많아지면 더 이상 메시지가 사용자에게 전달되지 않으며 메시지 저장소 성능에 문제가 생길 수 있습니다. 자세한 내용은 20.14.4.7 메일함 오버플로 때문에 사용자 메일이 전달되지 않음을 참조하십시오.

20.11.4 할당량 제한 모니터

imqutoacheck를 사용하여 할당량 사용 및 제한을 모니터링한 다음 정의된 할당량과 제한을 나열하는 보고서를 생성하고 할당량 사용과 관련된 정보를 제공합니다. 할당량과 사용량 수치는 KB로 보고됩니다. 이 유틸리티는 메일함 크기를 사용자의 할당량과 비교할 수도 있습니다. 옵션으로 지정된 할당량 비율을 초과한 사용자에게 전자 메일 알림을 보낼 수 있습니다.


주 –

imquotacheck에서 일부 기능이 변경되었습니다. Messaging Server 6.x에서 imquotacheck 유틸리티가 quotacheck 유틸리티를 대체했습니다. Messaging Server 5.x에서는 quotacheck 유틸리티를 사용하여 사용자 목록을 검색할 때 quotacheck가 로컬 mboxlist 데이터베이스를 검색했습니다. 이 기능은 mboxutil 유틸리티의 검색 기능과 중복되었습니다.

Messaging Server 6.x에서는 이 중복된 기능이 imquotacheck 유틸리티에서 제거되었습니다. imquotacheck를 사용하여 사용자 검색을 수행할 경우 로컬 mboxlist 데이터베이스가 아닌 LDAP 디렉토리에 대해 검색이 수행됩니다. 로컬 mboxlist 데이터베이스에서 사용자 목록을 검색하려면 mboxutil 유틸리티를 사용합니다.


할당량이 규칙 파일의 최소 임계값을 초과하는 모든 사용자에 대한 사용량을 나열하려면 다음을 수행합니다.

imquotacheck

도메인 siroe.com에 대한 할당량 정보를 나열합니다.

imquotacheck -d siroe.com

기본 규칙 파일에 따라 모든 사용자에게 알림을 보내려면 다음을 수행합니다.

imquotacheck -n

지정된 rulefile, myrulefile 및 지정된 메일 템플리트 파일 mytemplate.file에 따라 모든 사용자에게 알림을 보내려면 다음을 수행합니다(자세한 내용은 Sun Java System Messaging Server 6.3 Administration Referenceimquotacheck 참조).

imquotacheck -n -r myrulefile -t mytemplate.file

모든 사용자에 대한 사용량을 나열하고 규칙 파일을 무시하려면 다음을 수행합니다.

imquotacheck -i

사용자 user1에 대한 폴더별 사용량을 나열하려면 다음을 수행합니다(규칙 파일 무시).

imquotacheck -u user1 -e

20.11.5 디스크 공간 모니터

시스템이 디스크 공간과 분할 영역 사용을 모니터해야 하는 빈도와 경고를 보내야 하는 상황을 지정할 수 있습니다. 자세한 내용은 27.3.2 디스크 공간 모니터링을 참조하십시오.

20.11.6 stored 데몬

stored 데몬은 메시지 저장소에 대해 다음과 같은 유지 관리 작업을 수행합니다.

임의의 서버 데몬이 충돌된 경우 stored를 비롯한 모든 데몬을 중지했다가 다시 시작해야 합니다.

20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기

한 메시지가 여러 수신자에 전송될 때 해당 메시지는 각 수신자의 메일함마다 놓이게 됩니다. 일부 메시징 시스템에서는 각 수신자의 메일함에 같은 메시지의 복사본을 별도로 저장합니다. 그러나 이와 반대로, Sun Java System Messaging Server에서는 해당 메시지가 있는 메일함의 수에 관계 없이 메시지 사본을 하나만 유지합니다. 이는 해당 메시지를 포함하는 메일함에 메시지에 대한 하드 링크를 작성하는 방법으로 이루어집니다.

다른 메시징 시스템을 Sun Java Messaging Server로 마이그레이션할 때는 마이그레이션 과정을 통해 이러한 여러 메시지 복사본이 복사될 수 있습니다. 이는 규모가 큰 메시지 저장소의 경우 불필요하게 많은 메시지가 중복되는 것을 의미합니다. 또한 일반적인 서버 작업(예: IMAP append 작업이나 기타 소스의 작업)에 같은 메시지 사본이 여러 개 누적될 수 있습니다.

Messaging Server는 과도한 메시지 복사본을 제거하고 하나의 복사본에 대한 하드 링크로 대체하는 relinker라는 이름의 새 명령을 제공합니다.

20.11.7.1 relinker작동 원리

재연결 기능은 이 명령이나 실시간 모드에서 실행할 수 있습니다. relinker 명령을 실행할 때는 이 명령이 메시지 저장소 분할 영역 전체를 스캔하고 MD5 메시지 다이제스트 저장소(하드 링크에 해당)를 작성 또는 업데이트하며 필요한 하드 링크를 만듭니다.

다이제스트 저장소는 메시지 저장소의 메시지에 대한 하드 링크로 이루어져 있습니다. 디렉토리 계층 partition_path/=md5에 저장됩니다. 이 디렉토리는 사용자 메일함 계층 partition_path/=user(그림 20–1 참조)와 병행합니다. 다이제스트 저장소의 메시지는 MD5 다이제스트에서 고유하게 식별합니다. 예를 들어, fredb/00/1.msg의 다이제스트가 4F92E5673E091B43415FFFA05D2E47인 경우 partition/=user/hashdir/ hashdir/=fredb/00/1.msg는 partition/=md5/hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg에 연결됩니다. 다른 메일함에 이와 같은 메시지가 있을 때(예: partition_path/=user/hashdir/hashdir/gregk/00/17.msg) 해당 메시지는 partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg에 대해 하드 링크로 연결됩니다. 그림 20–4에 표시되어 있습니다.

그림 20–4 메시지 저장소 다이제스트 저장소

이 그림은 메시지 저장소를 보여 줍니다.

이 메시지의 경우 링크 수는 3이 됩니다. 두 메시지 모두 fredb 및 gregk의 메일함에서 삭제되면 링크 수는 하나가 되고 해당 메시지를 삭제할 수 있습니다.

relinker 프로세스는 같은 기능에 대해 실시간으로 실행될 수 있습니다. 자세한 내용은 20.11.7.3 실시간 모드에서 relinker 사용을 참조하십시오.

20.11.7.2 명령줄 모드에서 relinker 사용

relinker는 메시지 저장소 분할 영역 전체를 스캔하고 MD5 메시지 저장소(하드 링크에 해당)를 작성 또는 업데이트하며 과도한 메시지 파일을 삭제합니다. relinker가 저장소 분할 영역을 스캔한 후에는 재연결 이전과 이후 해당 분할 영역의 크기와 고유한 메시지의 수에 대한 통계를 산출합니다. 이미 해시된 저장소에서 실행 속도를 높이려면 relinker는 아직 =md5에 있지 않은 메시지의 다이제스트만 계산합니다. 전체 다이제스트 저장소를 지우는 옵션도 있습니다(사용자 메시지함에는 영향을 주지 않음).

이 명령의 구문은 다음과 같습니다.

relinker [-P. partitionname] [-d]

여기서 partitionname은 처리될 분할 영역(기본값: 모든 분할 영역)을 지정하고 -d는 다이제스트 저장소가 삭제됨을 지정합니다. 출력 예는 다음과 같습니다.


# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

특히 저장소에 메시지가 하나도 없는 처음에는 relinker 실행에 시간이 많이 걸릴 수 있습니다. 이는 모든 메시지마다 다이제스트를 계산(relinker 기준이 모든 메시지를 포함하도록 구성된 경우)해야 하기 때문입니다. relinker 기준 구성에 대한 자세한 내용은 20.11.7.4 relinker 구성을 참조하십시오.예를 들어, 100GB의 메시지 저장소를 처리하는 데는 6시간 정도가 걸립니다. 그러나 런타임 재연결을 활성화한 경우( 20.11.7.3 실시간 모드에서 relinker 사용 참조)에는 relinker 명령을 실행할 필요가 없습니다.

relinker 명령줄 모드가 배타적으로 사용되고 런타임 옵션이 아닌 경우에는 다이제스트 저장소( =md5)를 제거해야 합니다. 그 외의 경우에는 저장소에서 제거된 메시지(=user)에 해당 다이제스트 저장소의 연결이 그대로 있으므로(고아 메시지가 됨) 사용 가능한 디스크 공간이 되지 않습니다. relinker를 한 번만 실행할 수 있는 저장소의 일회 최적화를 수행하는 경우(예: 마이그레이션 후)에는 relinker -d를 사용하여 전체 저장소를 삭제합니다. 반복된 제거의 경우(마이그레이션 도중)에는 relinker 명령을 반복적으로 수행하는 것만으로도 충분합니다. 이 명령을 실행할 때마다 만료된 메시지나 고아 메시지를 저장소에서 제거하기 때문입니다.

처리되는 다른 분할 영역마다 병행하여 relinker의 여러 인스턴스를 실행(-p 옵션 사용)하는 것이 안전합니다. 메시지는 같은 파티션 안에서만 재연결됩니다.

20.11.7.3 실시간 모드에서 relinker 사용

relinker 기능은 configutil 매개 변수 local.store.relinker.enabledyes로 설정하면 실시간 모드에서 활성화할 수 있습니다. 실시간 모드에서 relinker를 사용하면 구성된 relinker 기준( 20.11.7.4 relinker 구성)에 맞게 배달된(또는 복원되거나 IMAP 추가된) 모든 메시지의 다이제스트를 계산한 다음 해당 다이제스트가 이미 존재하는지 여부를 저장소에서 확인하게 됩니다. 이 다이제스트가 존재하는 경우에는 해당 메시지의 새 사본을 만들지 않고 그에 대한 링크를 대상 메일함에 만듭니다. 다이제스트가 없을 때는 메시지를 만들고 나중에 그에 대한 링크를 저장소에 추가합니다.

stored는 각 분할 영역의 다이제스트 저장소를 스캔하고 링크 수가 한 개인 메시지(즉, relinker 기준에 맞지 않는 메시지)를 제거합니다. 스캔은 구성 가능한 시간 동안 한 번에 한 디렉토리씩 수행됩니다. 이로써 I/O 로드가 공평하게 분산되고 다른 서버 작업에 별다른 영향을 주지 않게 됩니다. 기본적으로 제거 주기는 24시간이며 이는 저장소에서 메시지가 삭제되거나 구성된 최대 캐시 사용 기간을 초과해도 최대 24시간까지는 그대로 남아 있다는 의미입니다. 이 작업은 relinker 실시간 모드가 활성화되어 있는 경우 사용 가능합니다.

20.11.7.4 relinker 구성

표 20–11은 relinker 기준 설정에 사용되는 매개 변수를 보여 줍니다.

표 20–11 relinker configutil 매개 변수

매개 변수 

설명 

local.store.relinker.enabled

추가 코드 및 stored 제거에서 메시지의 실시간 재연결을 활성화합니다. relinker 명령줄 도구는 이 옵션이 꺼져 있더라도 실행할 수 있습니다. 그러나 stored가 저장소를 제거하지 않으므로 이 작업에서는 relinker -d를 사용해야 합니다. 이 옵션을 설정하면 디스크 공간이 절감되는 대신 메시지 배달 성능이 떨어집니다.

기본값: no

local.store.relinker.maxage

저장소에 메시지가 저장될 최대 캐시 사용 기간(시간)으로, relinker 명령줄에서 고려합니다. -1은 제한이 없다는 뜻으로 저장소에서 고아 메시지만 삭제합니다. relinker의 경우 이는 캐시 사용 기간에 관계 없이 기존 메시지를 처리한다는 의미가 됩니다. 값을 적게 할수록 저장소가 작아지므로 relinker 또는 stored 삭제가 더 빨리 실행되고 디스크 공간을 더 빨리 재생 이용할 수 있습니다. 반면, 값을 크게 할수록 긴 시간(예를 들어, 사용자가 같은 메시지를 며칠 간격으로 저장하거나 며칠 또는 몇 주에 걸쳐 마이그레이션을 실행할 때)에 걸쳐 메시지 재연결이 중복됩니다.

기본값: 24 

local.store.relinker.minsize

런타임 또는 명령줄 relinker에서 고려하는 메시지의 최소 크기. 0이 아닌 값을 설정하면 저장소는 작아지는 대신 규모가 작은 메시지에 대한 relinker 혜택은 늘어납니다.

기본값: 0 

local.store.relinker.purgecycle

전체 stored 삭제 주기의 대략적인 지속 시간. 실제 지속 시간은 저장소의 각 디렉토리를 스캔하는 데 걸리는 시간에 따라 달라집니다. 값이 적을수록 더 많은 I/O를 사용하게 되고 값이 클수록 디스크 공간의 재생 이용이 느려집니다. 0은 디렉토리 사이에 일시 중지 없이 계속적으로 삭제가 실행된다는 의미입니다. -1은 stored에서 제거가 실행되지 않는다는 뜻입니다. 따라서 제거는 relinker -d 명령을 사용하여 수행해야 합니다.

기본값: 24 

20.12 메시지 저장소 백업 및 복원

메시지 저장소 백업 및 복원은 가장 일반적이고 중요한 관리 작업 중 하나입니다. 이 작업은 메시지 저장소의 모든 메시지와 폴더를 백업하는 것으로 구성됩니다. 다음과 같은 문제가 발생했을 때 데이터가 손실되지 않도록 메시지 저장소에 대한 백업 및 복원 정책을 구현해야 합니다.

imsbackupimsrestore 명령줄 유틸리티나 Legato NetworkerTM를 사용하는 통합 솔루션을 사용하여 메시지 저장소 백업 및 복원을 수행할 수 있습니다.

Messaging Server는 단일 복사본 백업 절차를 제공합니다. 특정 메시지를 포함하는 사용자 폴더 수에 상관 없이 백업 도중 메시지 파일은 처음 발견된 메시지 파일을 사용하여 한 번만 백업됩니다. 두 번째 메시지 복사본은 첫 번째 메시지 파일의 이름에 대한 링크로 백업되며 그 다음 복사본도 마찬가지입니다. imsbackup은 메시지 파일의 장치와 색인 노드를 색인으로 사용하여 모든 메시지의 해시 테이블을 유지 관리합니다. 단, 이 방법은 데이터 복원 시 고려해야 할 사항이 있습니다. 자세한 내용은 20.12.5 부분 복원 시의 고려 사항을 참조하십시오.


주 –

모든 메시지 파일과 디렉토리를 백업함으로써 메시지 저장소 백업과 복원을 수행할 수도 있습니다. 20.12.9 메시지 저장소 재해 복구 및 복원을 참조하십시오.


이 절에는 다음과 같은 하위 절이 포함됩니다.

20.12.1 메일함 백업 정책 만들기

백업 정책은 다음 몇 가지 요인에 영향을 받습니다.

20.12.1.1 작업량이 가장 많은 시간대

시스템에 대한 백업 일정을 예약할 때에는 작업량이 가장 많은 시간대에 시스템 로드를 줄일 수 있도록 작업량이 가장 많은 시간대를 피해야 합니다. 예를 들어, 백업은 오전 2시와 같은 새벽에 실행되도록 예약하는 것이 가장 적합합니다.

20.12.1.2 전체 및 증분 백업

증분 백업( 증분 백업 참조)은 변경된 데이터의 저장소를 스캔하고 변경된 사항만 백업합니다. 전체 백업은 전체 메시지 저장소를 백업합니다. 증분 백업과 달리 전체 백업은 시스템이 전체 백업을 수행하는 빈도를 결정해야 합니다. 일반적으로 증분 백업을 일상적인 유지 관리 절차로 수행하면서 일주일에 한 번씩 전체 백업을 수행합니다.

20.12.1.3 병렬 또는 직렬 백업

사용자 데이터를 여러 디스크에 저장할 경우 필요에 따라 사용자 그룹을 병렬로 백업할 수 있습니다. 시스템 자원에 따라 병렬 백업은 전반적인 백업 절차의 속도를 높일 수 있습니다. 하지만 백업이 서버 성능에 미치는 영향을 최소화하려는 경우에는 직렬 백업을 사용합니다. 병렬 백업 또는 직렬 백업 사용 여부는 시스템 로드, 하드웨어 구성, 사용 가능한 테이프 드라이브 수 등에 따라 달라질 수 있습니다.

20.12.2 백업 그룹 만들기

백업 그룹은 정규식에 의해 정의되는 임의의 사용자 메일함 집합입니다. 사용자 메일함을 백업 그룹으로 정리하면 보다 유연한 백업 관리를 정의할 수 있습니다.

예를 들어, 사용자 아이디가 A-L로 시작하는 사용자를 포함하는 첫 번째 백업 그룹, 사용자 아이디가 M-Z로 시작하는 사용자를 포함하는 두 번째 백업 그룹, 사용자 아이디가 숫자로 시작하는 사용자를 포함하는 세 번째 백업 그룹의 세 가지 백업 그룹을 만들 수 있습니다. 관리자는 이러한 백업 그룹을 사용하여 메일함을 병렬로 백업하거나 특정 날짜에 일정 그룹만 백업하고 다른 날짜에 다른 그룹을 백업할 수 있습니다.

백업 그룹과 관련하여 다음 몇 가지 사항에 유념해야 합니다.

  1. 백업 그룹은 메일 사용자의 임의 가상 그룹이며 보기와 달리 메시지 저장소 디렉토리(그림 20–1)에 정확하게 매핑되지 않습니다.

  2. 관리자가 UNIX 정규식을 사용하여 백업 그룹을 정의합니다.

  3. 정규식은 msg-svr-base/config/backup-groups.conf 구성 파일에 정의됩니다.

  4. 백업 그룹은 imsbackupimsrestore에서 참조될 경우 다음 경로 형식을 사용합니다. /partition_name/backup_group

backup-groups.conf의 형식은 다음과 같습니다.


group_name=definition
group_name=definition
.
.
.

위 단락에 설명된 예에 따라 다음 정의를 사용하여 세 개의 백업 그룹을 만듭니다.


groupA=[a-l].*
groupB=[m,-z].*
groupC=[0-9].*

이제 imsbackupimsrestore를 여러 수준에서 사용할 수 있습니다. 다음과 같이 백업 명령을 사용하여 전체 메시지 저장소를 백업/복원할 수 있습니다.

imsbackup -f device /

groupA의 모든 사용자에 대한 모든 메일함을 백업하려면 다음 명령을 사용합니다.

imsbackup -f device /partition/groupA

기본 분할 영역을 primary라고 합니다.

20.12.2.1 미리 정의된 백업 그룹

Messaging Server에는 backup-groups 구성 파일을 만들지 않고 사용할 수 있는 하나의 미리 정의된 백업 그룹이 포함되어 있습니다. 이 그룹은 user라고 하며 모든 사용자를 포함합니다. 예를 들어, 다음 명령은 primary 분할 영역의 모든 사용자를 백업합니다.

imsbackup -f backupfile /primary/user

20.12.3 Messaging Server 백업 및 복원 유틸리티

데이터를 백업 및 복원하기 위해 Messaging Server는 imsbackupimsrestore 유틸리티를 제공합니다. imsbackupimsrestore 유틸리티는 Legato Networker와 같은 일반 용도의 도구에 있는 고급 기능을 포함하지 않습니다. 예를 들어, 이러한 유틸리티는 테이프 자동 변환기에 대한 매우 제한적인 지원을 제공하고 단일 저장소를 동시에 여러 장치에 기록할 수 없습니다. 포괄적인 백업은 Legato Networker와 같은 일반화된 도구에 대한 플러그 인을 통해 실현됩니다. Legato Networker 사용에 대한 자세한 내용은 20.12.6 Legato Networker 사용을 참조하십시오.

20.12.3.1 imsbackup 유틸리티

imsbackup을 사용하면 메시지 저장소에서 선택한 내용을 자기 테이프, UNIX 파이프 또는 일반 파일을 비롯한 모든 직렬 장치에 기록할 수 있습니다. 백업이나 백업의 일부를 나중에 imsrestore 유틸리티를 사용하여 복구할 수 있습니다. imsbackup의 출력을 imsrestore로 파이프할 수 있습니다.

다음 예에서는 전체 메시지 저장소를 /dev/rmt/0으로 백업합니다.


imsbackup -f /dev/rmt/0 /

여기에서는 사용자 아이디 joe의 메일함을 /dev/rmt/0으로 백업합니다.


imsbackup -f /dev/rmt/0 /primary/user/joe
            

다음 예에서는 백업 그룹 groupA에 정의된 모든 사용자의 모든 메일함을 backupfile에 백업합니다( 20.12.2 백업 그룹 만들기 참조).


imsbackup -f- /primary/groupA > backupfile
            

증분 백업

다음 예는 2004년 5월 1일 1:10 PM부터 현재까지 저장된 메시지를 백업합니다. 기본값은 날짜에 상관없이 모든 메시지를 백업하는 것입니다.


imsbackup -f /dev/rmt/0 -d 20040501:131000 /
               

이 명령은 기본 차단 요소 20을 사용합니다. imsbackup 명령의 전체 구문 설명은 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

20.12.3.2 imsrestore 유틸리티

백업 장치에서 메시지를 복원하려면 imsrestore 명령을 사용합니다. 예를 들어, 다음 명령은 backupfile 파일에서 user1의 메시지를 복원합니다.

imsrestore -f backupfile /primary/user1

imsbackup 명령의 전체 구문 설명은 Sun Java System Messaging Server 6.3 Administration Reference를 참조하십시오.

20.12.4 백업 수행 시 대량 메일 제외

백업 작업을 수행할 때 백업에서 제외할 메일함을 지정할 수 있습니다. 중요하지 않은 메시지를 늘릴 수 있는 대량 또는 휴지통 메일함을 제외함으로써 백업 세션을 단순화하고 작업을 완료하는 데 필요한 시간을 줄이며 백업 데이터를 저장하는 데 필요한 디스크 공간을 최소화할 수 있습니다.

메일함을 제외하려면 configutil 매개 변수 local.store.backup.exclude에 대한 값을 지정합니다.

하나의 메일함이나 “%” 문자로 구분된 메일함 목록을 지정할 수 있습니다. “%”는 메일함 이름에 사용할 수 없는 문자입니다. 예를 들어, 다음 값을 지정할 수 있습니다.

Trash

Trash%Bulk Mail%Third Class Mail

첫 번째 예에서는 폴더 Trash가 제외됩니다. 두 번째 예에서는 폴더 Trash, Bulk MailThird Class Mail이 제외됩니다.

백업 유틸리티는 local.store.backup.exclude 매개 변수에 지정된 폴더를 제외하고 사용자 메일함의 모든 폴더를 백업합니다.

이 기능은 Messaging Server 백업 유틸리티, Legato Networker 및 타사 백업 소프트웨어와 함께 작동합니다.

작업 도중에 전체 논리 이름을 지정하여 local.store.backup.exclude 설정을 대체하거나 제외된 메일함을 백업할 수 있습니다. 휴지통 폴더가 제외되었다고 가정합니다. 다음을 지정하여 휴지통도 백업할 수 있습니다.

/primary/user/user1/trash

그러나 다음과 같이 지정할 경우에는

/primary/user/user1

휴지통 폴더가 제외됩니다.

20.12.5 부분 복원 시의 고려 사항

부분 복원은 메시지 저장소의 일부만 복원하는 것이고 전체 복원은 전체 메시지 저장소를 복원하는 것입니다. 메시지 저장소는 단일 복사본 메시지 시스템을 사용합니다. 즉, 메시지의 단일 복사본만 단일 파일로 저장소에 저장됩니다. 메시지를 여러 메일함으로 보낼 때와 같은 메시지의 다른 인스턴스는 해당 복사본에 대한 링크로 저장됩니다. 따라서 메시지를 복원할 때 고려해야 할 사항이 있습니다. 예를 들면 다음과 같습니다.

다음 예에서는 부분 복원 작업을 수행할 때 여러 사용자가 사용하는 메시지에 발생하는 변화를 보여 줍니다. 세 명의 사용자 A , B 및 C에 속하는 모두 동일한 다음 세 개의 메시지가 있다고 가정합니다.


A/INBOX/1
B/INBOX/1
C/INBOX/1

예 1. 첫 번째 예에서는 시스템이 다음과 같이 부분 백업 및 전체 복원 절차를 수행합니다.

  1. 사용자 B 및 C의 메일함을 백업합니다.

  2. 사용자 B 및 C의 메일함을 삭제합니다.

  3. 단계 1의 백업 데이터를 복원합니다.

이 예에서는 B/INBOX/1C/INBOX/1에 새 색인 노드 번호가 할당되며 메시지 데이터가 디스크의 새 위치에 기록됩니다. 하나의 메시지만 복원되며 두 번째 메시지는 첫 번째 메시지에 대한 하드 링크입니다.

예 2. 이 예에서는 시스템이 다음과 같이 전체 백업 및 부분 복원 작업을 수행합니다.

  1. 전체 백업을 수행합니다.

  2. 사용자 A의 메일함을 삭제합니다.

  3. 사용자 A의 메일함을 복원합니다.

A/INBOX/1에 새 색인 노드 번호가 할당됩니다.

예 3. 이 예에서는 여러 번의 부분 복원 시도가 필요할 수 있습니다.

  1. 전체 백업을 수행합니다.

    B/INBOX/1C/INBOX/1A/INBOX/1에 대한 링크로 백업됩니다.

  2. 사용자 A 및 B의 메일함을 삭제합니다.

  3. 사용자 B의 메일함을 복원합니다.

    복원 유틸리티는 관리자에게 A/INBOX를 먼저 복원할 것을 요청합니다.

  4. 사용자 A 및 B의 메일함을 복원합니다.

  5. 사용자 A의 메일함을 삭제합니다(선택 사항).


    주 –

    부분 복원으로 모든 메시지가 복원되게 하려면 imsbackup 명령을 -i 옵션과 함께 실행합니다. -i 옵션은 필요한 경우 모든 메시지를 여러 번 백업합니다.

    백업 장치를 검색할 수 있는 경우(예: 드라이브 또는 테이프) imsrestoreA/INBOX/1을 포함하는 위치를 검색하여 B/INBOX/1로 복원합니다. 백업 장치를 검색할 수 있는 경우(예: UNIX 파이프) imsrestore는 객체 아이디와 파일에 의존하는(연결된) 객체의 아이디를 기록하며 관리자는 -r 옵션과 함께 imsrestore를 다시 호출하여 누락된 메시지 참조를 복원해야 합니다.


20.12.5.1 증분 백업된 메일함에서 메시지을 복원하는 방법

증분 백업된 메일함에서 메시지를 복원할 때 해당 메일함이 메시지를 복원할 서버에 있는 경우 간단하게 imesrestore를 실행하여 메시지를 복원할 수 있습니다. 그러나 증분 백업된 메일함에서 메시지를 복원할 때 해당 메일함이 더 이상 없는 경우에는 다른 복원 절차를 따라야 합니다.

메시지 저장소 서버에 없는 메일함에 메시지를 복원하려면 다음 절차 중 하나를 사용합니다.

증분 백업을 복원할 때 이러한 지침을 따라야 하는 이유는 다음과 같습니다. 메일함이 삭제되거나 마이그레이션되면 imsrestore 유틸리티는 백업 아카이브에 저장된 메일함 고유 아이디 유효성과 메시지 고유 아이디(UID)를 사용하여 메일함을 다시 만듭니다.

이전에는 imsrestore가 삭제되었거나 마이그레이션된 메일함을 다시 만들 때 새 UID 유효성을 메일함에 할당하고 새 UID를 메시지에 할당했습니다. 이 경우 캐시된 메시지를 가진 클라이언트는 메일함 UID 유효성과 메시지 UID를 다시 동기화해야 합니다. 클라이언트가 새 데이터를 다시 다운로드해야 하므로 서버에서 작업 로드가 증가합니다.

imsrestore 동작의 경우에는 클라이언트 캐시가 동기화된 상태로 유지되며 복원 프로세스가 투명하게 작동하므로 성능에 부정적인 영향이 없습니다.

메일함이 있는 경우 imsrestore는 새 UID를 복원된 메시지에 할당하므로 새 UID와 이미 기존 메시지에 할당된 UID의 일관성이 유지됩니다. UID 일관성을 보장하기 위해 imsrestore는 복원 작업 도중에 메일함을 잠급니다. 그러나 imsrestore는 이제 새 UID 값을 할당하는 대신에 백업 아카이브의 메일함 UID 유효성과 메시지 UID를 사용하므로 증분 백업 및 복원을 수행할 경우 UID가 일관되지 않을 수 있습니다.

imsbackup 유틸리티의 -d 날짜 옵션을 사용하여 증분 백업을 수행할 경우 복원 작업을 완료하기 위해 imsrestore를 여러 번 호출해야 할 수 있습니다. 증분 백업이 수행되었으면 최신 전체 백업과 이후의 모든 증분 백업을 복원해야 합니다.

복원 작업 사이에 새 메시지를 메일함에 전달할 수 있지만 이 경우에는 메시지 UID가 일관되지 않을 수 있습니다. UID의 비일관성을 방지하려면 위에 설명된 작업 중 하나를 수행해야 합니다.

20.12.6 Legato Networker 사용

Messaging Server에는 Legato Networker와 같은 타사 백업 도구와의 인터페이스를 제공하는 백업 API가 포함되어 있습니다. 물리적 메시지 저장소 구조와 데이터 형식은 백업 API 내에서 캡슐화됩니다. 메시지 저장소와 직접 상호 작용하는 백업 API는메시지 저장소의 논리적 뷰를 백업 서비스에 제공합니다. 백업 서비스는 메시지 저장소의 개념적 표시를 사용하여 백업 객체를 저장 및 복원합니다.

Messaging Server는 Legato Networker의 saverecover 명령으로 호출하여 메시지 저장소 데이터를 백업 및 복원할 수 있는 ASM(Application Specific Module)을 제공합니다. 호출된 ASM은 이어서 Messaging Server imsbackup imsrestore 유틸리티를 호출합니다.


주 –

이 절에서는 Messaging Server 메시지 저장소와 함께 Legato Networker를 사용하는 방법에 대해 설명합니다. Legato Networker 인터페이스를 이해하려면 Legato 설명서를 참조하십시오.


ProcedureLegato Networker를 사용하여 데이터를 백업하는 방법

  1. /usr/lib/nsr/imsasm에서 msg-srv-base/lib/msg/imsasm에 대한 심볼릭 링크를 만듭니다.

  2. Sun 또는 Legato에서 nsrfile 이진 파일의 복사본을 얻어 다음 디렉토리에 복사합니다.

    /usr/bin/nsr

    이전 버전 Networker (5.x)를 사용 중인 경우에만 필요합니다. Networker 6.0 이상에서는 nsrfile/usr/bin/nsr에 자동으로 설치됩니다.

  3. 그룹별로 사용자를 백업하려면 다음 단계를 수행합니다.

    1. 20.12.2 백업 그룹 만들기에 설명된 대로 백업 그룹 파일을 만듭니다.

    2. 구성을 확인하려면 mkbackupdir.sh를 실행합니다.

      mkbackupdir.sh에 의해 작성된 디렉토리 구조를 확인합니다. 이 구조는 표 20–4에 나온 것과 비슷해야 합니다.

      backup-groups.conf 파일을 지정하지 않을 경우 백업 프로세스는 모든 사용자에 대해 기본 백업 그룹 ALL을 사용합니다.

  4. 백업 전에 mkbackupdir.sh 스크립트를 호출하기 위해 /nsr/res/ 디렉토리에서 저장 그룹에 대한 res 파일을 만듭니다. 표 20–4에 예가 나와 있습니다.


    주 –

    이전 버전의 Legato Networker에서는 saveset 이름이 64자로 제한됩니다. 이 디렉토리 이름과 메일함의 논리 이름을 합친 것(예: /primary/groupA/fred)이 64자 이상인 경우 mkbackupdir.sh -p를 실행해야 합니다. 따라서 mkbackupdir.sh-p 옵션에 짧은 경로 이름을 사용해야 합니다. 예를 들어, 다음 명령은 /backup 디렉토리 아래에 백업 이미지를 만듭니다.

    mkbackupdir.sh -p /backup

    중요백업 디렉토리는 메시지 저장소 소유자(예: mailsrv)가 쓸 수 있어야 합니다.


    표 20–6에서는 샘플 백업 그룹 디렉토리 구조를 보여 줍니다.


    /backup/primary/groupA/amy
                          /bob
                          /carly
                   /groupB/mary
                          /nancy
                          /zelda
                   /groupC/123go
                          /1bill
                          /354hut

    아래 예에서는 /nsr/res 디렉토리에 있는 IMS.res라는 샘플 res 파일을 보여 줍니다.


    type: savepnpc;
    precmd: "echo mkbackupdir started",
       "/usr/siroe/server5/msg-siroe/bin/mkbackupdir.sh -p /backup";
    pstcmd: "echo imsbackup Completed";
    timeout: "12:00 pm";
    
                         

    이제 다음과 같이 Legato Networker 인터페이스를 실행할 준비가 되었습니다.

  5. 필요한 경우 Messaging Server 저장 그룹을 만듭니다.

    1. nwadmin을 실행합니다.

    2. 사용자 정의 | 그룹 | 만들기를 선택합니다.

  6. 다음과 같이 savepnpc를 백업 명령으로 사용하여 백업 클라이언트를 만듭니다.

    1. saveset를 mkbackupdir로 만든 디렉토리로 설정합니다.

      단일 세션 백업의 경우 /backup을 사용합니다.

      병렬 백업의 경우 /backup/server/group을 사용합니다.

      20.12.2 백업 그룹 만들기에 정의된 대로 이미 group이 만들어졌는지 확인합니다.

      백업 세션 수에 대해서도 병렬을 설정해야 합니다.

      Legato Networker를 사용하여 데이터를 백업하는 방법을 참조하십시오.

  7. 그룹 제어 | 시작을 선택하여 백업 구성을 테스트합니다.

    예: Networker에서 백업 클라이언트 만들기

    Networker에서 백업 클라이언트를 만들려면 nwadmin에서 클라이언트 | 클라이언트 설치 | 만들기를 선택합니다.


    Name: siroe
    Group: IMS
    Savesets:/backup/primary/groupA
       /backup/secondary/groupB
       /backup/tertiary/groupC
             .
             .
    Backup Command:savepnpc
    Parallelism: 4
    
                         

20.12.6.1 Legato Networker를 사용하여 데이터 복원

Legato Networker nwrecover 인터페이스나 recover 명령줄 유틸리티를 사용하여 데이터를 복구할 수 있습니다. 다음 예에서는 사용자 a1의 INBOX를 복구합니다.

recover -a -f -s siroe /backup/siroe/groupA/a1/INBOX

다음 예에서는 전체 메시지 저장소를 복구합니다.

recover -a -f -s siroe /backup/siroe

20.12.7 Legato를 제외한 타사 소프트웨어 사용

Messaging Server는 두 개의 메시지 저장소 백업 솔루션인 명령줄 imsbackup 및 Solstice Backup(Legato Networker)을 제공합니다. 단일 imbackup을 실행하여 전체 메시지 저장소를 백업하는 대량 메시지 저장소는 매우 많은 시간이 소요될 수 있습니다. Legato 솔루션은 여러 백업 장치에서의 동시 백업 세션을 지원합니다. 동시 백업으로 백업 시간을 대폭 단축시킬 수 있습니다(시간당 25GB의 데이터 백업 가능).

타사 동시 백업 소프트웨어(예: Netbackup)를 사용하는 경우 다음 방법을 사용하여 백업 소프트웨어를 Messaging Server와 통합할 수 있습니다.

ProcedureLegato를 제외한 타사 소프트웨어 사용

  1. 사용자를 그룹으로 분할하고( 20.12.2 백업 그룹 만들기 참조) msg-svr-base/config/ 디렉토리 아래에 backup-groups.conf 파일을 만듭니다.


    주 –

    이 백업 솔루션에는 추가 디스크 공간이 필요합니다. 모든 그룹을 동시에 백업하려는 경우 디스크 공간 요구 사항은 메시지 저장소 크기의 2배입니다. 디스크 공간이 충분치 않을 경우에는 사용자를 더 작은 그룹으로 분할한 다음 그룹 집합을 한꺼번에group1 - group5, group6 - group10 등과 같이 백업합니다. 백업 후에 그룹 데이터 파일을 제거합니다.


  2. imsbackup을 실행하여 스테이징 영역에서 각 그룹을 파일로 백업합니다.

    명령은 imsbackup -f <device> /<instance>/<group>입니다.

    여러 imsbackup 프로세스를 동시에 실행할 수 있습니다. 예를 들면 다음과 같습니다.


    # imsbackup -f- /primary/groupA > /bkdata/groupA &
    # imsbackup -f- /primary/groupB > /bkdata/groupB & 
    . . .

    imsbackup은 큰 파일을 지원하지 않으므로 백업 데이터가 2GB 이상일 경우 -f- 옵션을 사용하여 데이터를 stdout에 기록한 다음 출력을 파일로 파이프해야 합니다.

  3. 타사 백업 소프트웨어를 사용하여 스테이징 영역(이 예에서는 /bkdata)에서 그룹 데이터 파일을 백업합니다.

  4. 사용자를 복원하려면 사용자의 그룹 파일 이름을 식별하고 테이프에서 해당 파일을 복원한 다음 imsrestore를 사용하여 데이터 파일에서 사용자를 복원합니다.

    imsrestore는 큰 파일을 지원하지 않습니다. 데이터 파일이 2GB 이상일 경우 다음 명령을 사용합니다.

    # cat /bkdata/groupA | imsrestore -f- /primary/groupA/andy

20.12.8 백업 및 복원 문제 해결

이 절에서는 일반적인 백업 및 복원 문제와 그 해결 방법에 대해 설명합니다.

20.12.9 메시지 저장소 재해 복구 및 복원

재해는 메일함 하나 또는 메일함 집합이 아닌 전체 메시지 저장소에 심각한 문제가 발생한 경우를 말합니다. 즉, 메시지 저장소 서버의 모든 데이터가 손실되는 경우가 이에 해당합니다. 다음의 손실 데이터를 복원하면 메시지 저장소 재해를 완전히 복원할 수 있습니다.

재해 복구를 위해 메시지 저장소를 백업하려면 파일 시스템 스냅샷 도구를 사용하여 파일 시스템의 스냅샷을 만듭니다. 스냅샷은 반드시 한 시점의 파일 시스템 스냅샷이어야 합니다. 그렇지 않으면 mboxlist 백업을 사용할 수 없습니다(전체 데이터베이스 스냅샷에서 mboxlist 데이터베이스를 복원해야 함).

모든 데이터(메시지 저장소 분할 영역, 데이터베이스 파일 등)를 같은 시점에 캡처하는 것이 가장 좋지만 그럴 수 없는 경우에는 다음과 같은 순서로 데이터를 백업해야 합니다.

  1. 데이터베이스 스냅샷

  2. 데이터베이스 파일

  3. 메시지 저장소 분할 영역

  4. 구성 데이터

메시지 저장소 분할 영역과 데이터베이스 파일을 같은 시점의 스냅샷으로 백업하지 않은 경우에는 파일 시스템 스냅샷을 복원한 후에 reconstruct -m을 실행합니다. 그러면 데이터베이스와 저장소 분할 영역이 동기화됩니다.

20.13 사용자 액세스 모니터링

Messaging Server는 IMAP, POP 및 http를 통해 사용자의 메시지 저장소 액세스를 모니터링할 수 있는 imsconnutil 명령을 제공합니다. 또한 사용자의 마지막 로그인 및 로그아웃을 확인할 수 있습니다. 이 명령은 메시지 저장소별로 작동하므로 여러 메시지 저장소에 대해 사용할 수 없습니다.


주 –

이 기능 또는 기타 Messaging Server 기능을 사용하여 사용자의 전자 메일을 모니터링, 읽기 또는 액세스할 때 해당 법률이나 규칙을 위반하거나 고객 정책 또는 계약을 위반할 경우 책임이 따를 수 있습니다.


이 명령을 사용하려면 시스템 사용자(mailsrv)가 루트로 액세스해야 하며 구성 변수 local.imap.enableuserlist, local.http.enableuserlist, local.enablelastaccess를 1로 설정해야 합니다.

IMAP 또는 웹 메일 클라이언트를 통해 현재 로그온한 사용자를 나열하려면 다음 명령을 사용합니다.

# imsconnutil -c

메시지 저장소에 있는 모든 사용자의 마지막 IMAP, POP, 또는 Messenger Express 액세스(로그인 및 로그아웃)를 나열하려면 다음을 사용합니다.

# imsconnutil -a

다음 명령은 1) 지정된 사용자가 IMAP나 Messenger Express 또는 mshttp를 통해 연결된 임의의 클라이언트(POP 사용자는 대개 연결 상태를 유지하지 않으므로 POP는 해당되지 않음)를 사용하여 현재 로그온했는지 확인하고 2) 사용자가 마지막으로 로그온 및 로그오프한 시간을 나열하는 두 가지 작업을 수행합니다.

# imsconnutil -c -a -u user_ID

다음 명령을 사용하여 사용자 목록이 파일에 한 행당 하나씩 입력될 수 있습니다.

# imsconnutil -c -a -f filename

또한 -s 플래그를 사용하여 특정 서비스(imap 또는 http)를 지정할 수도 있습니다. 예를 들어, 특정 사용자 아이디가 IMAP에 로그온했는지 여부를 나열하려면 다음 명령을 사용합니다.

# imsconnutil -c -s imap -u user_ID

-k 옵션은 IMAP IDLE가 구성된 경우에만 작동합니다. imsconnutil 구문에 대한 자세한 설명은 Sun Java System Messaging Server 6.3 Administration Reference imsconnutil을 참조하십시오.

다음은 몇 가지 출력 예입니다.


$ ./imsconnutil -a -u soroork

UID     IMAP last access    HTTP last access    POP last access
=========================================================================
ed   08/Jul/2003:10:49:05   10/Jul/2003:14:55:52  ---NOT-RECORDED---

$ ./imsconnutil -c

IMAP
UID    TIME                AUTH            TO                 FROM
===========================================================================
ed   17/Jun/2003:11:24:03  plain     172.58.73.45:193   129.157.12.73:2631
bil  17/Jun/2003:04:28:43  plain     172.58.73.45:193   129.158.16.34:2340
mia  17/Jun/2003:09:36:54  plain     172.58.73.45:193   192.18.184.103:3744
jay  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.159.18.123:3687
pau  17/Jun/2003:12:23:28  plaintext 172.58.73.45:193   192.18.194.83:2943
ton  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.152.18.123:3688
ani  17/Jun/2003:12:26:40  plaintext 172.58.73.45:193   192.18.164.17:1767
ani  17/Jun/2003:12:25:17  plaintext 172.58.73.45:193   129.150.17.34:3117
jac  17/Jun/2003:12:26:32  plaintext 172.58.73.45:193   129.150.17.34:3119
ton  17/Jun/2003:12:25:32  plaintext 172.58.73.45:193   192.18.148.17:1764
===========================================================================
10 users were logged in to imap.
Feature is not enabled for http.
---------------------------------------------------------------------------

20.14 메시지 저장소 문제 해결

이 절에서는 메시지 저장소를 능동적으로 유지 관리하기 위한 지침을 제공합니다. 또한 이 절에서는 메시지 저장소가 손상되었거나 예기치 않게 종료된 경우 사용할 수 있는 다른 메시지 저장소 복구 절차에 대해 설명합니다. 이 추가 메시지 저장소 복구 절차에 대한 절은 20.14.3 메일함 및 메일함 데이터베이스 복구를 확장한 것입니다.

이 절을 읽기 전에 이 장과 함께 Sun Java System Messaging Server Administration Reference의 명령줄 유틸리티 및 configutil에 대한 장을 검토하는 것이 좋습니다. 이 절은 다음 내용으로 구성되어 있습니다.

20.14.1 표준 메시지 저장소 모니터링 절차

이 절에서는 메시지 저장소의 표준 모니터링 절차에 대해 간략하게 설명합니다. 이러한 절차는 일반적인 메시지 저장소 검사, 테스트 및 표준 유지 관리에 유용합니다.

자세한 내용은 27.7 메시지 저장소 모니터링을 참조하십시오.

20.14.1.1 하드웨어 공간 검사

메시지 저장소에는 충분한 추가 디스크 공간과 하드웨어 자원이 있어야 합니다. 메시지 저장소가 디스크 및 하드웨어 공간의 최대 한도에 가까이 도달하면 메시지 저장소 내에 문제가 발생할 수 있습니다.

디스크 공간 부족은 메일 서버 문제 및 오류의 가장 일반적인 원인 중 하나입니다. 메시지 저장소에 쓰기 위한 공간이 없을 경우 메일 서버에서 오류가 발생합니다. 또한 사용 가능한 디스크 공간이 일정한 임계값 아래로 내려가면 메시지 전달, 로깅 등과 관련된 문제가 발생합니다. stored 프로세스의 정리 기능이 실패하고 삭제된 메시지가 메시지 저장소에서 정리되지 않으면 디스크 공간이 급속도로 줄어들 수 있습니다.

디스크 공간 모니터링에 대한 자세한 내용은 20.11.5 디스크 공간 모니터 27.7 메시지 저장소 모니터링을 참조하십시오.

20.14.1.2 로그 파일 검사

로그 파일을 검사하여 메시지 저장소 프로세스가 구성된 대로 실행되는지 확인합니다. Messaging Server는 지원되는 각각의 주요 프로토콜 또는 서비스(SMTP, IMAP, POP 및 HTTP)에 대한 별도의 로그 파일집합을 만듭니다. msg-svr-base/log/ 디렉토리에서 로그 파일을 볼 수 있습니다. 정기적으로 로그 파일을 모니터해야 합니다.

로깅이 서버 성능에 영향을 줄 수 있다는 것을 유의하십시오. 더 자세한 로깅을 지정할수록 일정한 시간 동안 로그 파일이 차지하는 디스크 공간이 더 많아집니다. 따라서 효과적이면서 실제적인 로그 회전, 만료 및 백업 정책을 서버에 정의해야 합니다. 서버의 로깅 정책 정의에 대한 자세한 내용은 25 장, 로깅 관리을 참조하십시오.

20.14.1.3 원격 측정을 사용하여 사용자 IMAP/POP/Webmail 세션 검사

Messaging Server는 사용자의 전체 IMAP, POP 또는 HTTP 세션을 파일로 캡처할 수 있는 원격 측정이라는 기능을 제공합니다. 이 기능은 클라이언트 문제를 디버깅하는 데 유용합니다. 예를 들어, 사용자가 메시지 액세스 클라이언트가 제대로 작동하지 않는다고 불평할 경우 이 기능을 사용하여 액세스 클라이언트와 Messaging Server 사이의 상호 작용을 추적할 수 있습니다.

POP 세션을 캡처하려면 다음 디렉토리를 만듭니다.

msg-svr-base/data/telemetry/pop_or_imap_or_http/userid

POP 세션을 캡처하려면 다음 디렉토리를 만듭니다.

msg-svr-base/data/telemetry/pop/userid

IMAP 세션을 캡처하려면 다음 디렉토리를 만듭니다.

msg-svr-base/data/telemetry/imap/userid

Webmail 세션을 캡처하려면 다음 디렉토리를 만듭니다.

msg-svr-base/data/telemetry/http/userid

디렉토리는 Messaging Server 사용자 아이디에서 소유하며 쓰기를 수행할 수 있어야 합니다.

Messaging Server는 이 디렉토리에서 세션당 하나의 파일을 만듭니다. 출력 예는 다음과 같습니다.


LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

원격 측정 기록을 비활성화하려면 만들었던 디렉토리를 옮기거나 제거합니다.

20.14.1.4 stored 프로세스 검사

stored 함수는 메시지 데이터베이스의 교착 상태 및 트랜잭션 작업, 에이징 정책 적용, 디스크에 저장된 메시지 정리 및 삭제와 같은 여러 중요한 작업을 수행합니다. stored의 실행이 중지되면 Messaging Server에서 문제가 발생합니다. start-msg가 실행될 때 stored가 시작되지 않을 경우 다른 프로세스는 시작되지 않습니다.

표 20–12 stored 작업

stored 작업 

기능 

stored.ckp

데이터베이스 검사점이 시작될 때 수정됩니다. 약 1분마다 시간이 기록됩니다. 

stored.lcu

데이터베이스 로그가 정리될 때마다 수정됩니다. 약 5분마다 시간이 기록됩니다. 

stored.per

사용자 단위 db 쓰기가 생성될 때마다 수정됩니다. 1시간에 한 번씩 시간이 기록됩니다. 

stored 프로세스에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference 20.11.6 stored 데몬 장을 참조하십시오.

stored 함수 모니터링에 대한 자세한 내용은 27.7 메시지 저장소 모니터링을 참조하십시오.

20.14.1.5 데이터베이스 로그 파일 검사

데이터베이스 로그 파일은 store_root /mboxlist 디렉토리에 있는 sleepycat 트랜잭션 검사점 지정 로그 파일을 나타냅니다. 로그 파일이 누적될 경우 데이터베이스 검사점 지정이 발생하지 않습니다. 일반적으로 단일 기간 동안 둘 또는 세 개의 데이터베이스 로그 파일이 존재합니다. 파일이 더 많이 있을 경우는 문제가 발생한 것일 수 있습니다.

20.14.1.6 사용자 폴더 검사

사용자 폴더를 검사하려는 경우 모든 사용자 폴더를 검토하고 오류를 보고하는 reconstruct -r -n(재귀적 수정 없음) 명령을 실행할 수 있습니다. reconstruct 명령에 대한 자세한 내용은 20.14.3 메일함 및 메일함 데이터베이스 복구를 참조하십시오.

20.14.1.7 코어 파일 검사

코어 파일은 프로세스가 예기치 않게 종료된 경우에만 존재합니다. 특히 메시지 저장소에 문제가 있을 경우 이러한 파일을 검토하는 것이 중요합니다. Solaris에서는 coreadm을 사용하여 core 파일 위치를 구성합니다.

20.14.2 메시지 저장소 시작 및 복구

메시지 저장소 데이터는 메시지, 색인 데이터 및 메시지 저장소 데이터베이스로 구성됩니다. 이 데이터는 상당히 견고하지만 가끔 시스템에 메시지 저장소 데이터 문제가 발생할 수 있습니다. 이러한 문제는 기본 로그 파일에서 나타나며 그 대부분이 항상 투명하게 수정됩니다. 아주 드물게 로그 파일의 오류 메시지가 reconstruct 유틸리티를 실행해야 한다는 것을 나타낼 수 있습니다. 또한 메시지를 보호하기 위한 마지막 수단으로 20.12 메시지 저장소 백업 및 복원에 설명된 백업 및 복원 프로세스가 사용됩니다. 이 절에서는 stored 의 자동 시작 및 복구 프로세스를 중심으로 설명합니다.

메시지 저장소는 이전에 관리자가 담당하던 많은 복구 작업을 자동화합니다. 이러한 작업은 시작 시에 메시지 저장소 데몬 stored에 의해 수행되며 필요에 따라 데이터베이스 스냅샷 및 자동 고속 복구를 포함합니다. stored는 메시지 저장소의 데이터베이스를 철저하게 검사하여 문제가 감지된 경우 이를 자동으로 복구합니다.

stored는 또한 상태 메시지를 통해 포괄적인 데이터베이스 상태 분석을 기본 로그에 제공하여 메시지 저장소에 대해 수행된 복구 작업과 메시지 저장소를 작동시키기 위한 자동 시도를 보고합니다.

20.14.2.1 자동 시작 및 복구—작동 원리

stored 데몬은 다른 메시지 저장소 프로세스보다 먼저 시작됩니다. 이 데몬은 메시지 저장소 데이터베이스를 초기화하고 필요한 경우 복구합니다. 메시지 저장소 데이터베이스는 폴더, 할당량, 가입 및 메시지 플래그 정보를 보관합니다. 데이터베이스는 로깅 및 트랜잭션 가능하여 이미 복구가 내장되어 있습니다. 또한 일부 데이터베이스 정보는 각 폴더의 메시지 색인 영역에서 중복하여 복사됩니다.

데이터베이스는 상당히 견고하지만 가끔씩 손상될 수 있으며 stored는 대부분의 경우 이 문제를 투명하게 복구합니다. 그러나 stored를 다시 시작할 때마다 기본 로그 파일을 검사하여 추가 관리 개입이 필요하지 않은지 확인해야 합니다. 데이터베이스의 추가 재작성이 필요한 경우 로그 파일의 상태 메시지에 reconstruct를 실행하라는 내용이 나타납니다.

메시지 저장소 데이터베이스를 열기 전에 stored는 무결성을 분석하고 경고 범주에 속하는 상태 메시지를 기본 로그로 보냅니다. 일부 메시지는 관리자에게 유용하며 다른 일부는 내부 분석에 사용되는 코딩된 데이터로 구성됩니다. stored는 문제를 감지하면 데이터베이스를 수정하고 재시작을 시도합니다.

데이터베이스가 열리면 stored는 나머지 서비스를 시작할 수 있다는 것을 알립니다. 자동 수정이 실패할 경우 기본 로그의 메시지는 수행할 작업을 지정합니다. reconstruct가 필요하다는 것을 지정하는 오류 메시지를 참조하십시오.

이전 릴리스에서는 stored에서 복구 프로세스를 구현하는 데 매우 오래 걸려서 관리자가 stored를 "중단"된 것으로 여기기도 했습니다.이제 이러한 긴 복구 유형은 제거되었으며 stored는 1분 이내에 최종 상태를 확인해야 합니다. 그러나 stored가 스냅샷 복구와 같은 복구 기술을 사용해야 할 경우 프로세스는 몇 분 정도가 소요될 수 있습니다.

대부분의 경우 복구가 수행된 후에 데이터베이스는 최신 상태로 업데이트되며 다른 작업은 필요하지 않습니다. 그러나 일부 복구는 메시지 저장소의 중복 데이터를 동기화하기 위해 reconstruct -m이 필요합니다. 이러한 내용도 기본 로그에 표시되므로 시작 후에 기본 로그를 모니터하는 것이 중요합니다. 메시지 저장소가 시작되어 정상적으로 실행되는 것처럼 보이는 경우에도 reconstruct와 같은 요청된 모든 작업을 실행해야 합니다.

로그 파일을 읽어야 하는 또 다른 이유는 처음에 데이터베이스를 손상시킨 원인을 확인하는 데 있습니다. stored는 시스템상의 문제와 무관하게 메시지 저장소를 사용하도록 설계되었지만 데이터베이스 손상이 숨겨진 더 큰 문제의 일부일 수 있으므로 그 원인을 확인하는 것이 필요합니다.

reconstruct가 필요하다는 것을 지정하는 오류 메시지

이 절에서는 reconstruct를 실행해야 하는 오류 메시지 유형에 대해 설명합니다.

오류 메시지가 메일함 오류를 나타내면 reconstruct <mailbox>를 실행합니다. 예:

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

오류 메시지가 데이터베이스 오류를 나타내면 reconstruct -m을 실행합니다. 예:

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

데이터베이스 스냅샷

스냅샷은 데이터베이스의 핫 백업으로 stored에서 손상된 데이터베이스를 몇 분 안에 투명하게 복원하기 위해 사용합니다. 이것은 다른 영역에 저장된 중복된 정보에 의존하는 reconstruct를 사용하는 것보다 훨씬 더 빠릅니다.

메시지 저장소 데이터베이스 스냅샷—작동 원리

mboxlist 디렉토리에 있는 데이터베이스의 스냅샷은 기본적으로 24시간에 한 번씩 자동으로 생성됩니다. 스냅샷은 기본적으로 store 디렉토리의 하위 디렉토리에 복사됩니다. 언제든지 기본적으로 다섯 개의 스냅샷(라이브 데이터베이스 하나, 스냅샷 세 개, 데이터 베이스/제거된 복사본 하나)이 있습니다. 데이터베이스/제거된 복사본이 가장 최신 버전이며 mboxlist 데이터베이스 디렉토리의 removed 하위 디렉토리로 보내지는 데이터베이스의 긴급 복사본입니다.

현재 데이터베이스가 손상된 것으로 확인되어 복구 프로세스에서 이를 제거하기로 결정하면 stored는 가능한 경우 해당 데이터베이스를 removed 디렉토리로 이동합니다. 이렇게 하면 필요에 따라 데이터베이스를 분석할 수 있습니다.

데이터 이동은 일주일에 한 번만 발생합니다. 따라서 이미 데이터베이스 복사본이 있는 경우에는 stored에서 저장소를 만들 때마다 데이터베이스 복사본을 교체하지 않습니다. stored는 removed 디렉토리의 데이터가 1주일보다 오래된 경우에만 교체를 수행합니다. 이것은 문제가 있는 원래 데이터베이스가 계속적인 시작으로 인해 너무 빨리 대체되는 것을 방지합니다.

메시지 저장소 데이터베이스 스냅샷 간격 및 위치 지정

결합된 데이터베이스와 스냅샷의 5배에 해당하는 공간이 있어야 합니다. 관리자는 스냅샷을 별개의 디스크에서 실행되도록 다시 구성하고 시스템 요구에 맞게 조정하는 것이 좋습니다.

stored가 시작 시에 데이터베이스 문제를 감지할 경우 최적의 스냅샷이 자동으로 복구됩니다. 세 개의 스냅샷 변수는 스냅샷 파일 위치, 스냅샷 촬영 간격, 저장되는 스냅샷 수 등과 같은 매개 변수를 설정할 수 있습니다. 이러한 configutil 매개 변수는 표 20–13에 나와 있습니다.

스냅샷 간격이 너무 작으면 시스템에 자주 부담을 주게 되며 데이터베이스의 문제가 스냅샷으로 복사될 가능성이 더 커집니다. 스냅샷 간격이 너무 크면 스냅샷을 가져왔을 때 갖고 있던 상태를 데이터베이스가 계속 보유하는 상황이 발생할 수 있습니다.

스냅샷 간격으로 1일이 권장되지만 시스템상에 문제가 수일 동안 지속되거나 문제가 존재하기 전의 시점으로 되돌아가려는 경우 일주일 이상의 간격이 유용할 수 있습니다.

stored는 데이터베이스를 모니터하여 데이터베이스가 완전하지 않다고 의심될 경우 최신 스냅샷을 거부하며 그 대신에 가장 안정적인 최신 스냅샷을 검색합니다. 하루 전의 스냅샷을 검색할 수 있다는 사실에도 불구하고 시스템은 보다 최신의 중복 데이터가 있는 경우 이를 사용하며 이전 스냅샷 데이터를 무시합니다.

따라서 스냅샷의 궁극적인 역할은 시스템을 가능한 최신 상태로 유지하고 데이터를 즉석에서 재작성하려고 시도하는 시스템의 나머지 부분에 대한 부담을 줄여 주는 것입니다.

표 20–13 메시지 저장소 데이터베이스 스냅샷 매개 변수

매개 변수 

설명 

local.store.snapshotpath

메시지 저장소 데이터베이스 스냅샷 파일의 위치입니다. 기존 절대 경로 또는 store 디렉토리에 대한 상대 경로입니다.

기본값: dbdata/snapshots

local.store.snapshotinterval

스냅샷 간격(분)입니다. 유효한값1 - 46080 

기본값: 분일 

local.store.snapshotdirs

보관되는 다른 스냅샷 수입니다. 유효한값2 -367 

기본값: 3 

20.14.3 메일함 및 메일함 데이터베이스 복구

하나 이상의 메일함이 손상되면 reconstruct 유틸리티를 사용하여 메일함 또는 메일함 데이터베이스를 다시 작성하고 모든 불일치를 복구할 수 있습니다.

reconstruct 유틸리티는 하나 이상의 메일함이나 마스터 메일함 파일을 다시 작성하고 모든 불일치를 복구합니다. 이 유틸리티를 사용하면 메시지 저장소에서 거의 모든 형태의 데이터 손상을 복구할 수 있습니다. reconstruct가 필요하다는 것을 지정하는 오류 메시지를 참조하십시오.

표 20–14에는 reconstruct 옵션이 나열되어 있습니다. 구문 및 사용 요구 사항에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Referencereconstruct를 참조하십시오.

표 20–14 reconstruct 옵션

옵션 

설명 

-e

재구성하기 전에 store.exp 파일을 제거합니다. 이렇게 하면 저장 프로세스에서 정리하지 않은 제거된 메시지에 대한 모든 내부 저장소 레코드가 제거됩니다. -i 또는 -e 옵션은 폴더가 실제로 재구성될 때만 작동하므로 이러한 옵션을 사용할 때 -f 옵션을 사용하는 것도 유용합니다. 마찬가지로 재구성이 아닌 검사를 수행하는 -n 옵션을 사용할 경우 -i-e 옵션이 작동하지 않습니다.

reconstruct가 손상을 감지하지 못하는 경우 reconstruct -e를 실행하면 제거된 메시지가 복구되지 않습니다. -f는 재구성을 실행합니다.

-i

재구성 전에 store.idx 파일 길이를 0으로 설정합니다. -i 또는 -e 옵션은 폴더가 실제로 재구성될 때만 작동하므로 이러한 옵션을 사용할 때 -f 옵션을 사용하는 것도 유용합니다. 마찬가지로 재구성이 아닌 검사를 수행하는 -n 옵션을 사용할 경우 -i-e 옵션이 작동하지 않습니다.

-f

reconstruct를 수행하여 메일함을 수정합니다.

-l

lright.db를 재구성합니다.

-m

일관성 검사를 수행하고 필요한 경우 메일함 데이터베이스를 복구합니다. 이 옵션은 스풀 영역에서 찾은 모든 메일함을 검사하고 메일함 데이터베이스에서 적절하게 항목을 추가 또는 제거합니다. 데이터베이스에서 항목을 추가 또는 제거할 때마다 표준 출력 파일에 메시지가 인쇄됩니다. 특히 folder.db, quota.dblright.db를 수정합니다.

-n

메일함을 수정하지 않고 메시지 저장소만 검사합니다. 메일함 이름을 제공하지 않을 경우 -n 옵션을 단독으로 사용할 수 없습니다. 메일함 이름을 제공하지 않을 때는 -n 옵션을 -r 옵션과 함께 사용해야 합니다. -r 옵션은 -p 옵션과 함께 사용할 수 있습니다. 예를 들어, 다음 명령은 모두 유효합니다.

reconstruct -n user/dulcinea/INBOX

reconstruct -n -r

reconstruct -n -r -p primary

reconstruct -n -r user/dulcinea/

-o

폐기되었습니다. mboxutil -o를 참조하십시오.

-o -d filename

폐기되었습니다. mboxutil -o를 참조하십시오.

-p partition

-p 옵션은 -m 옵션과 함께 사용되며 재구성의 범위를 지정한 분할 영역으로 제한합니다. -p 옵션을 지정하지 않을 경우 reconstruct에서 모든 분할 영역이 기본값이 됩니다. 특히 folder.dbquota.db를 수정하지만 lright.db는 수정하지 않습니다. 이는 lright.db를 수정하려면 메시지 저장소의 모든 사용자에 대한 acl을 스캔해야 하기 때문입니다. 모든 분할 영역에 대해 이 작업을 수행하는 것은 그리 효율적이지 않습니다. lright.db를 수정하려면 reconstruct -l을 실행합니다.

분할 영역 이름을 지정하며 전체 경로 이름을 사용하면 안 됩니다. 

-q

할당량 하위 시스템의 모든 불일치(예: 잘못된 할당량 루트를 가진 메일함 또는 잘못된 할당량 사용이 보고된 할당량 루트)를 수정합니다. 다른 서버 프로세스가 실행되는 동안 -q 옵션을 실행할 수 있습니다.

-r [mailbox]

지정된 메일함의 분할 영역에 대한 일관성 검사를 복구 및 수행합니다. -r 옵션은 또한 지정된 메일함 내의 모든 하위 메일함을 복구합니다. 메일함 인수 없이 -r을 지정할 경우 사용자 분할 영역 디렉토리에 있는 모든 메일함의 스풀 영역이 복구됩니다.

-u user

-u 옵션은 -m 옵션과 함께 사용되며 재구성의 범위를 지정한 사용자로 제한합니다. -u 옵션은 -p 옵션과 함께 사용해야 합니다. -u 옵션을 지정하지 않을 경우 모든 분할 영역이나 -p 옵션을 사용하여 지정한 분할 영역이 reconstruct에서 기본값이 됩니다.

분할 영역 이름을 지정하며 전체 경로 이름을 사용하면 안 됩니다. 

20.14.3.1 메일함 재작성

메일함을 다시 작성하려면 -r 옵션을 사용합니다. 다음 경우에 이 옵션을 사용해야 합니다.

reconstruct -r은 우선 일관성 검사를 실행합니다. 이 검사는 모든 비일관성을 보고하며 문제가 감지된 경우에만 재작성을 수행합니다. 결과적으로 이 릴리스에서 reconstruct 유틸리티의 성능이 향상됩니다.

다음 예에 설명된 대로 reconstruct를 사용할 수 있습니다.

사용자 daphne에 속하는 메일함의 스풀 영역을 다시 작성하려면 다음 명령을 사용합니다.

reconstruct -r user/daphne

메일함 데이터베이스에 나열된 모든 메일함의 스풀 영역을 다시 작성하려면 다음 명령을 사용합니다.

reconstruct -r

대용량 메시지 저장소의 경우 메일함 데이터베이스에 나열된 모든 메일함의 스풀 영역을 다시 작성하는 것이 아주 오래 걸릴 수 있으므로 이 옵션은 신중하게 사용해야 합니다. 20.14.3.3 reconstruct 성능을 참조하십시오. 저장소에 여러 디스크를 사용하는 것이 보다 나은 오류 복구 방법일 수 있습니다. 디스크가 하나가 중지되었다고 전체 저장소가 중지되지는 않습니다. 디스크가 손상된 경우 다음과 같이 -p 옵션을 사용하여 저장소의 일부만 다시 작성하면 됩니다.

reconstruct -r -p subpartition

primary 분할 영역에 있을 경우에만 명령줄 인수에 나열된 메일함을 다시 작성하려면 다음 명령을 수행합니다.

reconstruct -p primary mbox1 mbox2 mbox3

primary 분할 영역에 있는 모든 메일함을 다시 작성할 필요가 없을 경우 다음 명령을 사용합니다.

reconstruct -r -p primary

reconstruct를 실행하여 일관성 검사를 수행하지 않고 폴더를 다시 작성하려면 -f 옵션을 사용합니다. 예를 들어, 다음 명령을 실행하여 사용자 폴더 daphne를 다시 구성합니다.

reconstruct -f -r user/daphne

모든 메일함을 수정하지 않고 검사하려면 다음과 같이 -n 옵션을 사용합니다.

reconstruct -r -n

20.14.3.2 메일함 검사 및 복구

메일함 데이터베이스의 고급 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -m

기본 분할 영역의 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -p primary -m

주 –

-P 및 -m 플래그와 함께 reconstruct를 실행하면 lright.db가 수정되지 않습니다. 이는 lright.db를 수정하려면 메시지 저장소의 모든 사용자에 대한 ACL을 스캔해야 하기 때문입니다. 모든 분할 영역에 대해 이 작업을 수행하는 것은 그리 효율적이지 않습니다. lright.db를 수정하려면 reconstruct -l을 실행합니다.


john이라는 개별 사용자의 메일함에 대한 일관성 검사와 복구를 수행하려면 다음 명령을 사용합니다.

reconstruct -p primary -u john -m

다음 경우에 -m 옵션을 사용해야 합니다.

20.14.3.3 reconstruct 성능

reconstruct가 작업을 수행하는 데 걸리는 시간은 다음 요소에 따라 달라집니다.

reconstruct -r 옵션은 초기 일관성 검사를 수행합니다. 이 검사는 다시 작성해야 하는 폴더 수에 따라 reconstruct 성능을 향상시킵니다.

약 2400명의 사용자와 85GB의 메시지 저장소가 있으며 서버에 동시 POP, IMAP 또는 SMTP 활동이 있는 시스템에서 다음 성능이 확인되었습니다.


주 –

진행 중인 POP, IMAP, HTTP 또는 SMTP 활동을 서버에서 수행하지 않을 경우 reconstruct 작업에는 훨씬 더 적은 시간이 소요될 수 있습니다.


20.14.4 일반 문제 및 해결 방법

이 절에서는 다음과 같은 일반적인 메시지 저장소 문제와 해결 방법에 대해 설명합니다.

20.14.4.1 Linux - Messaging Server 패치 120230-08 IMAP, POP 및 HTTP 서버가 프로세스 당 세션 초과 때문에 시작되지 않음

이 패치를 설치한 후 Messaging Server를 설치하려 하면 IMAP, POP 및 HTTP 서버가 시작되지 않고 다음 예와 같은 오류 로그를 보낼 수 있습니다.


http server - log:
[29/May/2006:17:44:37 +051800] usg197 httpd[6751]: General Critical: Not enough file 
descriptors to support 6000 sessions per process; Recommend ulimit -n 12851 or 87 
sessions per process.

pop server - log:
[29/May/2006:17:44:37 +051800] usg197 popd[6749]: General Critical: Not enough file 
descriptors to support 600 sessions per process; Recommend ulimit -n 2651 or 58 
sessions per process.

Once these values setting in /opt/sun/messaging/sbin/configutil then imap server 
failed to start

imap server - log: 
[29/May/2006:17:44:37 +051800] usg197 imapd[6747]: General Critical: Not enough 
file descriptors to support 4000 sessions per process; Recommend ulimit -n 12851 
or 58 sessions per process.

세 서버 세션 모두에 적절한 수의 파일 설명자를 설정합니다. 다음과 비슷한 행을 /etc/sysctl.conf에 추가하고 sysctl -p를 사용하여 파일을 다시 읽으면 추가 파일 설명자를 사용할 수 있습니다.


fs.file-max = 65536 

또한 다음과 같은 행을 /etc/security/limits.conf에 추가해야 합니다.


*   soft  nofile  65536  
*   hard  nofile  65536

20.14.4.2 메일 페이지를 로드하지 않는 Messenger Express 또는 Communications Express

사용자가 Messenger Express 페이지 또는 Communications Express 메일 페이지를 로드할 수 없는 경우 압축 후에 데이터가 손상되었을 수 있습니다. 이 문제는 시스템에서 오래된 프록시 서버를 배포한 경우에 종종 발생할 수 있습니다. 이 문제를 해결하려면 local.service.http.gzip.staticlocal.service.http.gzip.dynamic0으로 설정하여 데이터 압축을 비활성화해 보십시오. 문제가 해결되면 프록시 서버를 업데이트할 수 있습니다.

20.14.4.3 와일드카드 패턴을 사용하는 명령이 작동하지 않음

UNIX 쉘의 경우 일부는 와일드카드 매개 변수에 따옴표가 필요하지만 일부는 그렇지 않습니다. 예를 들어, C 쉘은 와일드카드(*, ?)를 파일로 포함하는 인수 확장을 시도하며 일치하는 항목이 없으면 실패합니다. 이러한 패턴 일치 인수를 mboxutil과 같은 명령에 전달하려면 따옴표로 묶어야 할 수 있습니다.

예를 들면 다음과 같습니다.

mboxutil -l -p user/usr44*

Bourne 쉘에서 작동하지만 tsch 및 C 쉘에서는 실패합니다. 이러한 쉘에는 다음이 필요합니다.

mboxutil -l -p "user/usr44*"

와일드카드 패턴을 사용하는 명령이 작동하지 않을 경우 해당 쉘의 와일드카드를 따옴표로 묶어야 하는지 여부를 확인합니다.

20.14.4.4 알 수 없거나 잘못된 분할 영역

메일함을 방금 만든 새 분할 영역으로 이동했거나 Messaging Server를 갱신 또는 다시 시작하지 않은 경우 Messenger Express에서 "알 수 없는/잘못된 분할 영역"이라는 메시지가 표시될 수 있습니다. 이 문제는 새 분할 영역에서만 발생합니다. 이제 추가 사용자 메일함을 이 새 분할 영역에 추가할 경우 Messaging Server를 갱신 또는 다시 시작할 필요가 없습니다.

20.14.4.5 사용자 메일함 디렉토리 문제

사용자 저장소 손상이 몇몇의 사용자로 제한되고 시스템에 대한 전역 손상이 없을 경우 사용자 메일함 문제가 존재합니다. 다음 지침은 사용자 메일함 디렉토리 문제를 식별, 분석 및 해결하기 위한 프로세스를 제시합니다.

  1. 로그 파일, 오류 메시지 또는 관찰된 모든 비정상적인 동작을 검토합니다.

  2. 정보와 기록을 계속 디버깅하려면 전체 store_root/mboxlist/ 사용자 디렉토리를 메시지 저장소 외부의 다른 위치로 복사합니다.

  3. 문제를 일으키는 사용자 폴더를 찾으려면 reconstruct -r -n 명령을 실행합니다. reconstruct를 사용하여 폴더를 찾을 수 없는 경우 folder.db에 폴더가 존재하지 않을 수 있습니다.

    reconstruct -r -n 명령을 사용하여 폴더를 찾을 수 없는 경우 hashdir 명령을 사용하여 위치를 확인합니다. hashdir에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Reference의 Messaging Server Command-line Utilities 장에 있는 20.11.2.3 hashdir 유틸리티hashdir 유틸리티를 참조하십시오.

  4. 폴더를 찾은 후에는 파일과 권한을 검사하고 적절한 파일 크기를 확인합니다.

  5. reconstruct -r(-n 옵션 없이)을 사용하여 메일함을 다시 작성합니다.

  6. 관찰된 문제를 reconstruct에서 감지하지 못하는 경우 reconstruct -r -f 명령을 실행하여 메일 폴더를 다시 구성할 수 있습니다.

  7. 폴더가 mboxlist 디렉토리(store_root/mboxlist)에 존재하지 않지만 partition 디렉토리(store_root/partition)에 존재할 경우 전역 불일치가 존재할 수 있습니다. 이 경우 reconstruct -m 명령을 실행해야 합니다.

  8. 이전 단계들로 문제가 해결되지 않을 경우 store.idx 파일을 제거하고 reconstruct 명령을 다시 실행할 수 있습니다.


    주의 – 주의 –

    reconstruct 명령으로 검색할 수 없는 파일에 문제가 있다고 확신하는 경우에만 store.idx 파일을 제거해야 합니다.


  9. 문제가 특정 메시지로 한정된 경우 해당 메시지 파일을 메시지 저장소 외부의 다른 위치로 복사하고 mailbox/ 디렉토리에서 reconstruct -r 명령을 실행해야 합니다.

  10. 폴더가 디스크(store_root/partition/ 디렉토리)에 존재하지만 데이터베이스(store_root/mboxlist/ 디렉토리)에는 확실하게 없을 경우 reconstruct -m 명령을 실행하여 메시지 저장소 일관성을 확인합니다.

reconstruct 명령에 대한 자세한 내용은 20.14.3 메일함 및 메일함 데이터베이스 복구를 참조하십시오.

20.14.4.6 저장소 데몬이 시작되지 않음

stored가 시작되지 않고 다음 오류 메시지가 반환됩니다.


# msg-svr-base/sbin/start-msg

msg-svr-base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

이 오류 메시지는 local.servergid에 구성된 UNIX 그룹을 찾을 수 없다는 것을 나타냅니다. Stored 및 다른 유틸리티에서는 해당 gid가 이 그룹으로 설정되어야 합니다. 경우에 따라 실수로 local.servergid에 의해 정의된 그룹이 삭제될 수 있습니다. 이런 경우에는 삭제된 그룹을 만들고 mailsrv를 그룹에 추가한 다음 instance_root와 해당 파일의 소유권을 mailsrv 및 해당 그룹으로 변경합니다.

20.14.4.7 메일함 오버플로 때문에 사용자 메일이 전달되지 않음

메시지 저장소의 store.idx 파일에는 2GB의 엄격한 제한이 적용됩니다. 이는 단일 메일함(폴더)에 약 100만 개의 메시지가 들어가는 정도에 해당됩니다. store.idx 파일이 2GB를 초과하려 할 정도로 메일함이 커지면 사용자는 새 전자 메일을 받지 못하게 됩니다. 또한 imapd, popd, mshttpd와 같이 해당 메일함을 처리하는 다른 프로세스의 성능도 저하될 수 있습니다.

이 문제가 발생하면 mail.log_current에 다음과 같은 오류가 표시됩니다.

05-Oct-2005 16:09:09.63 ims-ms Q 7 ...System I/O error.Administrator, check server log for details.System I/O error.

그 외에도 MTA 로그 파일에는 다음과 같은 오류가 표시됩니다.

[05/Oct/2005:16:09:09 +0900] jmail ims_master[20745]:Store Error:Unable to append cache for user/admin:File too large

사용자의 메시지 저장소 디렉토리에 있는 파일을 조회하거나 imta 로그 파일에서 자세한 메시지를 확인하면 이 문제가 발생한 것을 확실히 알 수 있습니다.

즉시 필요한 조치는 파일의 크기를 줄이는 것입니다. 일부 메일을 삭제하거나 다른 메일함으로 옮기십시오. mboxutil -r을 사용하여 폴더 이름을 변경할 수도 있고 mboxutil -d를 사용하여 폴더를 삭제할 수도 있습니다( 20.11.2.1 mboxutil 유틸리티 참조).

장기적으로는 사용자에게 메일함 크기 제한에 대해 알리거나, 에이징 정책( 20.9 자동 메시지 제거(만료 및 제거) 기능 설정 방법 참조)과 할당량 정책( 20.8 메시지 저장소 할당량 정보 참조)을 구현하거나, local.store.maxmessages를 설정하여 메일함 제한을 설정하거나(Sun Java System Messaging Server 6.3 Administration Referenceconfigutil Parameters 참조), 아카이브 시스템을 설정하거나, 메일함 크기를 제어 범위 내로 유지하기 위한 조치를 취해야 합니다.

20.15 메일함을 새 시스템으로 이동 또는 마이그레이션

한 Messaging Server 시스템의 기존 메일함을 다른 Messaging Server 시스템으로 이동해야 할 수 있습니다. 이러한 경우는 다음과 같습니다.

Messaging Server는 한 시스템의 메일함을 다른 시스템으로 이동하는 여러 가지 방법을 제공합니다. 방법마다 장단점이 있으며, 여기에 대해서는 아래 절에서 설명합니다. 이 방법에 대한 자세한 내용은 다음 절을 참조하십시오.

20.15.1 온라인 상태에서 다른 Messaging Server로 사용자 메일함 마이그레이션

이 절차를 사용하여 메시지 저장소를 이전 버전 Messaging Server에서 최신 버전으로 마이그레이션하거나 메일함을 다른 Sun Messaging Server 메시지 저장소로 이동할 수 있습니다. 이 절차는 iPlanet Messaging Server 5.0 이상에서 수행해야 합니다. 이전 버전 Messaging Server 또는 Sun Microsystems가 아닌 메시지 저장소에서 메시지를 이동할 때는 이 절차를 사용할 수 없습니다.

이 절차로 메일함을 이동할 경우의 장점은 다음과 같습니다.

이 절차로 메일함을 이동할 경우의 단점은 다음과 같습니다.

20.15.1.1 증분 메일함 마이그레이션

증분 마이그레이션은 메시지 저장소를 다른 시스템으로 안전하고 효율적으로 이동하거나 새 시스템으로 업그레이드할 수 있는 등 다양한 이점을 제공합니다. 증분 마이그레이션을 사용하면 이전 백엔드 메시지 저장소와 함께 새 백엔드 메시지 저장소 시스템을 구성할 수 있습니다. 그런 다음 새 시스템을 테스트하고, 친분이 있는 사용자에게 마이그레이션한 다음 새 시스템을 다시 테스트할 수 있습니다. 새 시스템과 구성이 편리하고 마이그레이션 절차에 익숙한 경우 실제 상업용 사용자를 마이그레이션할 수 있습니다. 이러한 사용자를 개별 백업 그룹으로 분할하여 마이그레이션 중에 이 그룹의 구성원만 잠시 오프라인 상태로 전환할 수 있습니다.

온라인 증분 마이그레이션은 업그레이드가 실패할 경우 시스템 전체에서 백아웃을 계획할 필요가 없다는 또 다른 장점이 있습니다. 백아웃은 시스템에 대해 수행한 변경을 취소하여 원래의 작업 상태로 되돌리는 절차입니다. 마이그레이션을 수행할 때 실패에 대한 계획을 수립해야 합니다. 즉, 마이그레이션의 모든 단계에서 이전 작업 상태로 되돌릴 계획을 세워야 합니다.

오프라인 마이그레이션은 모든 마이그레이션 단계를 완료하고 서비스를 다시 실행할 때까지는 마이그레이션이 성공했는지 확인할 수 없다는 문제가 있습니다. 따라서 시스템이 작동하지 않고 빠르게 수정할 수 없는 경우 수행한 모든 단계에 대해 백아웃 절차를 수행해야 합니다. 이 작업은 매우 힘들고 시간이 많이 소요될 수 있으며, 작업을 수행하는 동안 사용자는 오프라인 상태로 유지됩니다.

온라인 증분 마이그레이션에서는 다음과 같은 기본 단계를 수행합니다.

1. 이전 시스템과 함께 새 시스템을 구축하여 두 시스템이 독립적으로 작동할 수 있게 합니다.

2. 이전 시스템이 새 시스템과 공존하도록 구성합니다.

3. 친분이 있는 사용자 그룹을 마이그레이션하고 새 시스템을 테스트하며 이전 시스템과의 공존 상태를 테스트합니다.

4. 이전 시스템의 사용자를 여러 그룹으로 분할하고 원하는 경우 각 그룹을 새 그룹으로 마이그레이션합니다.

5. 이전 시스템을 역어셈블합니다.

두 시스템이 공존하기 때문에 새 시스템으로 마이그레이션하기 전에 새 시스템을 테스트하고 익숙해질 시간이 있습니다. 원하지 않더라도 백아웃 절차를 수행해야 하는 경우에는 2단계와 4단계에 대해서만 계획해야 합니다. 2단계는 사용자의 데이터를 건드리지 않기 때문에 쉽게 반전됩니다. 4단계에서는 백아웃을 수행하여 사용자의 상태를 활성 상태로 되돌리고 메일 호스트 속성을 이전 호스트로 되돌립니다. 시스템 차원의 백아웃이 필요하지 않습니다.

20.15.1.2 온라인 마이그레이션 개요

온라인 상태에서 메일함을 마이그레이션하는 프로세스는 매우 간단합니다. 메일함으로 전송 중인 메시지(MTA 채널 대기열에서 전달을 위해 대기 중)가 마이그레이션 중에 손상되지 않도록 하는 과정은 매우 복잡합니다. 한 가지 해결 방법으로 마이그레이션 과정에서 전송된 메시지를 보관 상태로 유지하고 다양한 채널 대기열의 메시지가 전달될 때까지 대기합니다. 그러나 시스템 문제나 특정 사용자의 할당량 초과로 메시지가 대기열에 고착될 수 있습니다. 그럴 경우 문제를 해결한 다음 메일함을 마이그레이션해야 합니다.

다양한 방법으로 메시지 손실 가능성을 줄이고 메시지가 채널 대기열에 고착되지 않도록 할 수 있지만, 그럴 경우 절차가 복잡해지는 단점이 있습니다.

절차에서 수행되는 단계의 순서와 필요성은 모든 메일함에 전달되는 모든 메시지가 손실되는지 여부와 배포에 따라 다릅니다. 이 절에서는 단계와 관련한 이론과 개념에 대해 설명합니다. 사용자는 각 단계를 이해하고 지정된 배포에 대해 수행할 각 단계와 순서를 결정해야 합니다. 다음은 메일함 이동 프로세스의 개요입니다. 이 프로세스는 배포에 따라 다를 수 있습니다.

  1. 이동 중인 메일함에 대한 사용자 액세스를 차단합니다.

  2. 이동 중인 메일함으로 전달되는 메시지를 임시로 보관합니다.

  3. 메시지가 채널 대기열에 고착되지 않는지 확인합니다.

  4. 사용자의 메일 호스트 속성을 새 메일함 위치로 변경합니다.

  5. 메일함을 새 위치로 이동합니다.

  6. 전달을 위해 보관 중인 메시지를 새 메일함으로 릴리스하고 마이그레이션된 메일함으로 전달할 받는 메시지를 활성화합니다.

  7. 이전 메시지 저장소를 검사하여 마이그레이션 이후에 전달된 메시지가 있는지 확인합니다.

  8. 메일함에 대한 사용자 액세스 차단을 해제합니다.

Procedure온라인 상태로 사용자 메일함을 다른 Messaging Server로 마이그레이션하는 방법

시작하기 전에

이 마이그레이션 유형에 대한 요구 사항은 다음과 같습니다.


주 –

일부 단계는 Messaging Server를 최신 버전으로 업그레이드하는 경우에만 적용됩니다. 이 단계는 다른 메시지 저장소로 메일함 마이그레이션만 수행하는 경우에는 적용되지 않을 수도 있습니다. 전체 시스템 마이그레이션에 적용되는 단계는 별도의 설명이 있습니다.


  1. 원본 시스템에서 backup-groups.conf 파일을 사용하여 이동할 사용자 항목을 동일한 백업 그룹 수로 분할합니다.

    이 단계는 해당 절차의 뒤에 나오는 메일함 마이그레이션 단계 8에 대한 준비 과정입니다. 자세한 내용은 20.12.2 백업 그룹 만들기을 참조하십시오.

    파일에 사용자 아이디를 넣고 imsbackup 명령에 -u 옵션을 사용할 수도 있습니다.

  2. 이동 대상인 사용자에게 이동이 완료될 때까지 메일함에 액세스할 수 없음을 알립니다.

    데이터를 이동하기 전에 이동할 사용자가 메일 시스템에서 로그아웃했는지 확인합니다. ( 20.13 사용자 액세스 모니터링 참조)

  3. 백엔드 메시지 저장소와 MMP 시스템에서 인증 캐시 시간 초과를 0으로 설정하고 MTA에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.

    1. 이동할 메일함이 있는 백엔드 메시지 저장소에서 인증 캐시 시간 초과를 0으로 설정합니다.


      configutil -o service.authcachettl -v 0
      

      이 단계와 단계 7(mailUserStatushold로 변경)에서는 마이그레이션 중에 사용자의 메일함 액세스를 즉시 차단합니다.

    2. 모든 MMP에서 LDAP 및 인증 캐시 시간 초과를 0으로 설정합니다.

      ImapProxyAService.cfgPopProxyAService.cfgLdapCacheTTLAuthCacheTTL을 모두 0으로 설정합니다.

    3. 마이그레이션할 메일함에 메시지를 삽입하는 MTA를 호스트하는 모든 Messaging Server에서 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 0으로 설정합니다.

      마이그레이션 중인 메일함에 메시지를 삽입하는 MTA를 호스트하는 Messaging Server는 일반적으로 백엔드 메시지 저장소입니다. 그러나 시스템에서 LMTP를 사용하는 경우에는 해당 시스템이 인바운드 MTA입니다. 구성을 확인합니다.

      /msg_svr_base /config/option.dat에서 ALIAS_ENTRY_CACHE_TIMEOUT을 재설정하면 MTA가 캐시를 우회하고 LDAP 항목을 직접 조사하므로 중간 채널 대기열(예: conversion 또는 reprocess 채널)에 만료된 캐시 정보가 아니라 이동 중인 사용자의 새 mailUserStatus(hold)가 표시됩니다. ALIAS_ENTRY_CACHE_TIMEOUToption.dat에 있습니다.

    4. 캐시가 재설정된 시스템을 다시 시작합니다.

      변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 4.4 서비스 시작 및 중지를 참조하십시오.

  4. 원본 Messaging Server와 대상 Messaging Server가 모두 실행 중인지 확인합니다.

    원본 Messaging Server는 받는 메시지를 새 대상 서버에 라우팅할 수 있어야 합니다.

  5. 메일함을 이동할 모든 사용자 항목에서 LDAP 속성 mailUserStatusactive에서 hold로 변경합니다.

    속성을 변경하면 받는 메시지가 hold 대기열에 보관되고 IMAP, POP 및 HTTP를 통한 액세스가 금지됩니다. 일반적으로 사용자는 사용자 그룹으로 이동됩니다. 단일 도메인의 모든 메일함을 이동할 경우 mailDomainStatus 속성을 사용할 수 있습니다.

    mailUserStatus에 대한 자세한 내용은 Sun Java Communications Suite 5 Schema ReferencemailUserStatus를 참조하십시오.

  6. 마이그레이션 중인 메일함에 전달된 메시지가 ims-ms 또는 tcp_lmtp* 채널 대기열(LMTP가 배포된 경우)에 고착되지 않는지 확인합니다.

    다음 명령을 사용하여 메시지가 채널 대기열 디렉토리 트리에 있고 마이그레이션할 사용자에 대해 held 상태인지(.HELD 파일을 보려면) 확인합니다.


    imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree
    
    imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree

    대기열에 메시지가 있는 경우 나중에 위 명령을 실행하여 MTA가 해당 메시지를 대기열에서 해제하는지 확인합니다. 대기열에서 해제되지 않은 메시지가 있는 경우 마이그레이션을 수행하기 전에 이 문제를 해결해야 합니다. 이 문제는 드물기는 하지만 수신자 메일함의 할당량이 초과된 경우, 사용자가 로그인한 후 메시지를 이동 중이라서 메일함이 차단된 경우, LMTP 백엔드 서버가 응답하지 않는 경우, 네트워크 또는 이름 서버 문제 등이 원인일 수 있습니다.

  7. 이동할 사용자 항목과 메일 그룹 항목*에서 LDAP 속성 mailHost를 변경합니다.

    ldapmodify 명령을 사용하여 항목을 새 메일 서버로 변경합니다. Messaging Server 또는 Directory Server와 함께 제공된 ldapmodify를 사용합니다. Solaris OS ldapmodify 명령은 사용하지 마십시오.

    * 이전 메일 호스트가 종료된 경우에는 메일 그룹 항목에서 mailHost 속성을 변경해야 합니다. 이 속성을 새 메일 호스트로 변경하거나 속성을 완전히 제거할 수 있습니다. 메일 그룹은 선택적으로 mailHost를 가질 수 있습니다. mailHost를 갖는다는 것은 해당 호스트만 그룹 확장을 수행할 수 있다는 의미이고, mailHost를 생략한다는 것은(보다 일반적인 경우) 모든 MTA가 그룹 확장을 수행할 수 있다는 의미입니다. 메일 그룹 항목에는 마이그레이션할 메일함이 없고 일반적으로 mailhost 속성도 없습니다.

    mailhost에 대한 자세한 내용은 Sun Java Communications Suite 5 Schema ReferencemailHost를 참조하십시오.

  8. 메일함 데이터를 원본 Messaging Server 메시지 저장소에서 대상 Messaging Server 메시지 저장소로 이동하고 시작된 시간을 기록합니다.

    imsbackup 유틸리티를 사용하여 메일함을 백업하고 imsrestore 유틸리티를 사용하여 새 Messaging Server에 복원합니다. 예를 들어, oldmail.siroe.com이라는 Messaging Server 5.2 시스템의 메일함을 newmail.siroe.com으로 마이그레이션하려면 oldmail.siroe.com에서 다음 명령을 실행합니다.


    /server-root/bin/msg/store/bin/imsbackup -f- /instance/group     \
    | rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh   \
    -f- -c y -v 1
    

    여러 백업 및 복원 세션(그룹마다 하나씩)을 동시에 실행하여 새 메시지 저장소로의 전송 속도를 최대화할 수 있습니다. imsbackupimsrestore 유틸리티에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration ReferenceCommand Descriptions 20.12 메시지 저장소 백업 및 복원을 참조하십시오.


    주 –

    나중의 전달 확인을 위해 imsbackup이 실행된 시간의 타임스탬프를 기록합니다.


  9. (시스템 업그레이드를 위한 조건부 단계) 메일함 마이그레이션을 이전 버전 Messaging Server에서 현재 버전으로 업그레이드하는 과정의 일부로 수행하는 경우 현재 버전 Messaging Server를 시스템에 대한 새 기본 Messaging Server로 설정합니다.

    oldmail.siroe.com의 DNS A 레코드를 변경하여 newmail.siroe.com(이전에 oldmail.siroe.com에서 호스트되던 도메인을 담당하는 서버)을 가리키도록 합니다.

  10. 새 메시지 저장소에 대한 사용자 액세스를 활성화합니다.

    LDAP 속성 mailUserStatus 또는 mailDomainStatus(해당하는 경우)를 hold 상태로 변경되기 이전의 값(예: active)으로 설정합니다.

  11. 모든 원본 Messaging Server에서 메시지를 held 상태에서 해제합니다.

    받는 메시지를 보관 중인 시스템은 다음 명령을 실행하여 모든 사용자 메시지를 릴리스해야 합니다.


    imsimta qm release -channel=hold -scope
    

    여기서 scopeall(모든 메시지 릴리스), user(사용자 아이디) 또는 domain(사용자가 있는 도메인)입니다.

  12. 인증 캐시 시간 초과 및 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 기본값이나 원하는 값으로 재설정하고 시스템을 다시 시작합니다.

    이제 마이그레이션해야 할 모든 사용자 메일함을 마이그레이션했습니다. 계속하기 전에 이전 시스템에서 LDAP에 새 항목이 mailhost로 생성되지 않았는지 확인하고, 생성된 항목이 있는 경우 해당 항목을 마이그레이션합니다. 또한 준비 시스템을 수정하여 해당 항목이 만들어지는지 확인합니다.

    preferredmailhost 속성을 새 메일 호스트의 이름으로 변경할 수도 있습니다.

    백엔드 메시지 저장소에 대해 인증 캐시 시간 초과를 다음과 같이 설정합니다.


    configutil -o service.authcachettl -v 900
    

    MMP의 경우 ImapProxyAService.cfgPopProxyAService.cfg에서 LdapCacheTTLAuthCacheTTL 옵션을 900으로 설정합니다.

    MTA의 경우 ALIAS_ENTRY_CACHE_TIMEOUT 옵션을 600으로 설정합니다. ALIAS_ENTRY_CACHE_TIMEOUToption.dat에 있습니다.

    변경 사항을 적용하려면 시스템을 다시 시작해야 합니다. 자세한 내용은 4.4 서비스 시작 및 중지를 참조하십시오.

  13. 사용자 클라이언트가 새 메일 서버를 가리키는지 확인합니다.

    업그레이드가 끝나면 사용자가 메일 클라이언트 프로그램을 통해 새 서버를 가리키도록 합니다. 이 예에서는 oldmail.siroe.com에서 newmail.siroe.com을 가리킵니다.

    대안은 MMP(Messaging Multiplexor)를 사용하는 것입니다. 그러면 사용자가 새 메일 서버를 클라이언트로 직접 가리킬 필요가 없습니다. MMP는 LDAP 사용자 항목에 저장된 mailHost 속성으로부터 정보를 가져와서 클라이언트를 새 서버로 자동으로 리디렉션합니다.

  14. 모든 작업이 완료되면 마이그레이션 이후에 이전 메시지 저장소로 전달된 메시지가 없는지 확인합니다.

    이전 메시지 저장소로 이동한 후 mboxutil -l을 실행하여 메일함을 나열합니다. 마지막 메시지 전달 타임스탬프를 확인합니다. 마이그레이션 타임스탬프(imsbackup 명령을 실행한 날짜 스탬프) 이후에 전달된 메시지가 있는 경우 백업 및 복원 명령을 사용하여 해당 메시지를 마이그레이션합니다. 준비 단계를 수행했기 때문에 마이그레이션 이후에 전달된 메시지가 표시되는 경우는 극히 드뭅니다.

    이론적으로는 메시지가 notices 채널 키워드에 지정된 날짜 또는 시간 동안 대기열에 고착될 수 있습니다( 10.10.4.3 알림 메일 전달 간격 설정 참조).

  15. 새 메시지 저장소에서 중복 메시지를 제거하고 relinker 명령을 실행합니다.

    이 명령은 새 메시지 저장소에서 디스크 공간을 비울 수 있습니다. 20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  16. 마이그레이션한 원본 저장소에서 이전 메시지를 제거하고 이전 저장소의 데이터베이스에서 사용자를 삭제합니다.

    mboxutil -d 명령을 실행합니다. ( 20.11.2.1 mboxutil 유틸리티 참조)

ProcedureIMAP 클라이언트를 사용하여 메일함을 이동하는 방법

메시지를 다른 Messaging Server로 마이그레이션해야 하는 경우 언제든지 이 절차를 사용할 수 있습니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

IMAP 클라이언트를 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

IMAP 클라이언트를 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메시지의 중복 저장으로 인한 새 시스템의 메시지 저장소 크기가 줄어듭니다. 자세한 내용은 20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. 새 Messaging Server에서 사용자를 준비합니다.

    Delegated Administrator를 사용하여 이 작업을 수행할 수 있습니다. 새 시스템에서 사용자가 준비되면 새로 도착하는 메시지가 새 INBOX로 전달됩니다.

  4. 사용자가 메일 클라이언트에서 새 Messaging Server 메일함과 이전 메일함을 모두 표시하도록 구성하게 합니다.

    여기에는 클라이언트에서 새 전자 메일 계정을 설정하는 작업이 포함될 수 있습니다. 자세한 내용은 메일 클라이언트 설명서를 참조하십시오.

  5. 사용자에게 이전 Messaging Server의 폴더를 새 Messaging Server로 끌어다 놓도록 지시합니다.

  6. 모든 메일함이 새 시스템으로 마이그레이션되었는지 사용자에게 확인한 다음 이전 시스템에서 사용자 계정을 종료합니다.

Proceduremoveuser 명령을 사용하여 메일함을 이동하는 방법

메시지를 다른 Messaging Server로 마이그레이션해야 하는 경우 언제든지 이 절차를 사용할 수 있습니다. 이 절차는 Sun Messaging Server가 아닌 시스템의 IMAP 메일함을 Sun Java System Messaging Server로 마이그레이션하는 데 유용합니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

moveuser 명령을 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

moveuser 명령을 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메시지의 중복 저장으로 인한 새 시스템의 메시지 저장소 크기가 줄어듭니다. 자세한 내용은 20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. Messaging Server로 받는 메시지를 중지합니다.

    사용자 속성 mailUserStatushold로 설정합니다.

  4. 필요한 경우 새 Messaging Server에서 사용자를 준비합니다.

    이전 버전의 Messaging Server에서 마이그레이션하는 경우 동일한 LDAP 디렉토리와 서버를 사용할 수 있습니다. moveuser는 각 사용자 항목에서 mailhost 속성을 변경합니다.

  5. moveuser 명령을 실행합니다.

    Directory Server siroe.com의 계정 정보를 기반으로, host1의 모든 사용자를 host2로 이동합니다.


    MoveUser -l \
    "ldap://siroe.com:389/o=siroe.com???(mailhost=host1.domain.com)" \
    -D "cn=Directory Manager" -w password -s host1 -x admin \
    -p password -d host2 -a admin -v password
    

    moveuser 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration ReferenceMoveUser를 참조하십시오.

  6. 새 메시지 저장소에 대한 사용자 액세스를 활성화합니다.

    mailUserStatus LDAP 속성을 active로 설정합니다.

  7. 이전 시스템을 종료합니다.

Procedureimsimport 명령을 사용하여 메일함을 이동하는 방법

이 절차는 특히 UNIX /var/mail 형식 폴더의 메일함을 Sun Java System Messaging Server 메시지 저장소로 이동하는 데 사용됩니다. 그러나 마이그레이션하는 Messaging Server에서 IMAP 메시지 저장소를 UNIX /var/mail 형식으로 변환할 수 있으면 imsimport 명령을 사용하여 메시지를 Sun Java System Messaging Server로 마이그레이션할 수 있습니다. 이 방법으로 메일함을 이동하기 전에 장점과 단점을 고려하십시오.

imsimport 명령을 사용하여 메일함을 이동할 경우의 장점은 다음과 같습니다.

imsimport 명령을 사용하여 메일함을 이동할 경우의 단점은 다음과 같습니다.

  1. 새 Messaging Server를 설치하고 구성합니다.

  2. local.store.relinker를 enable로 설정합니다.

    이렇게 하면 동일한 메시지의 중복 저장으로 인한 새 시스템의 메시지 저장소 크기가 줄어듭니다. 자세한 내용은 20.11.7 동일한 메시지의 중복 저장에 따른 저장소 크기 줄이기를 참조하십시오.

  3. 필요한 경우 새 Messaging Server에서 사용자를 준비합니다.

    Delegated Administrator를 사용하여 이 작업을 수행할 수 있습니다. 아직 새 시스템으로 전환하지 마십시오.

  4. 새 메시지 저장소와 이전 메시지 저장소에 대한 사용자 액세스를 모두 비활성화합니다.

    mailUserStatus LDAP 속성을 hold로 설정합니다. 사용자 메일이 보관 대기열로 전송되고 IMAP, POP 및 HTTP를 통한 메일함 액세스가 차단됩니다. 저장소 서버의 MTA 및 메시지 액세스 서버는 이 요구 사항을 따라야 합니다. 이 설정은 다른 모든 mailDeliveryOption 설정을 대체합니다.

  5. 기존 메일 서버의 메시지 저장소가 /var/mail 형식이 아니면 메시지 저장소를 /var/mail 파일로 변환합니다.

    타사 메일 서버 설명서를 참조하십시오.

  6. imsimport 명령을 실행합니다.

    예를 들면 다음과 같습니다.


    imsimport -s /var/mail/joe -d INBOX -u joe
    

    imsimport 명령에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 Administration Referenceimsimport를 참조하십시오.

  7. 메시지 저장소에 대한 사용자 액세스를 활성화합니다.

    mailUserStatus LDAP 속성을 active로 설정합니다.

  8. 새 메시지 저장소에 대한 사용자 액세스를 활성화합니다.

  9. 이전 시스템을 종료합니다.