Zimbra "LDAP 서버 응답 없음" 부팅 실패 해결: 실용적인 복구 가이드

Zimbra가 시작 중에 와 같은 오류와 함께 실패할 때 LDAP server not responding, 중요한 질문은 단순히 오류 메시지를 없애는 것이 아닙니다. 진정한 목표는 정상적인 LDAP 종속성을 복원하고, Zimbra가 다시 구성을 읽을 수 있는지 확인하며, 근본 원인이 아직 밝혀지지 않은 동안 관련 없는 서비스를 변경하지 않는 것입니다.

이 가이드는 해당 결과에 초점을 맞춥니다. 서비스 상태, LDAP 검사, 로컬 구성, 인증서 확인 및 다중 서버 LDAP URL에 대해 Zimbra에서 제공하는 명령어를 사용합니다. 예제에서는 와 같은 자리 표시자 호스트 이름을 사용하며 ldap1.example.com, 실제 배포 환경에 맞는 값으로 바꿔야 합니다.

성공적인 회복의 모습은 어떤 것일까요?

무엇을 변경하기 전에 최종 목표를 명확히 하세요. 다음과 같은 모든 조건이 충족될 때 비로소 만족스러운 개선이라고 할 수 있습니다.

• ldap statusslapdLDAP 노드에서 실행 중인 프로세스를 보고합니다 .
• zmcontrol status영향을 받는 호스트에서 LDAP 및 종속 Zimbra 서비스가 실행 중이라고 보고합니다.
• LDAP 호스트 이름은 문제가 발생한 Zimbra 노드에서 예상되는 주소로 확인됩니다.
• 설정된 LDAP 포트에 접속할 수 있습니다.
• TLS가 관련된 경우 인증서 체인이 유효성 검사를 통과하고 이전의 TLS 오류가 사라집니다.
• 다중 서버 배포 환경에서 의도한 순서대로 유효하고 활성화된 LDAP 호스트를 포함합니다 ldap_url.ldap_master_url
• 재시작 후에는 /var/log/zimbra.log더 이상 LDAP 연결 실패 오류가 반복적으로 발생하지 않습니다.

이러한 검사 중 하나라도 실패하면 전체 Zimbra 스택을 반복적으로 재시작하는 대신 해당 계층에 대한 문제 해결을 계속하십시오.

빠른 참조: 증상 및 다음 검진

1. LDAP 자체에 문제가 있는지 확인합니다.

사용자 권한으로 상태 확인을 실행합니다 zimbra.

su - zimbra
zmcontrol status
ldap status

Zimbra의 LDAP 문제 해결 문서에서는 slapd프로세스가 실제로 실행 중인지 확인하고 Zimbra에서 이를 인식하는지 확인하는 것을 권장합니다 ldap status. LDAP이 로컬에서 실행되고 있지 않다면 사서함, MTA, 프록시 또는 웹 서비스 문제를 해결하기 전에 LDAP 프로세스를 먼저 조사하십시오. LDAP은 핵심 구성 요소이므로 하위 서비스는 구성 데이터를 읽을 수 없기 때문에 오류가 발생할 수 있습니다.

참고: Zimbra LDAP 문제 해결 문서 및 Zimbra zmcontrol 명령 참조 .

2. 서비스를 변경하기 전에 LDAP URL을 확인하십시오.

해당 노드에서 로컬 LDAP 엔드포인트를 검사하십시오.

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

Zimbra 10 멀티 서버 문서에서 `< ldap_urlLDAP 서버 이름>`은 노드가 쿼리해야 하는 LDAP 서버를 식별하고, ` ldap_master_url<마스터 엔드포인트 이름>`은 쓰기 작업에 사용되는 마스터 엔드포인트 또는 마스터 세트를 식별합니다. 또한 Zimbra 문서에서는 복제본 URL이 일반적으로 마스터 URL보다 먼저 표시되어야 하며 ldap_url, 마스터는 목록에 유지된다고 설명합니다.

이 점검은 서버 마이그레이션, LDAP 교체, IP 주소 변경, 재해 복구 또는 롤링 업그레이드 후에 특히 중요합니다. LDAP 서버가 완벽하게 정상 작동하더라도 더 이상 사용되지 않는 호스트 이름에 연결을 시도하는 Zimbra 노드는 도움을 받을 수 없습니다.

이름 확인 및 TCP 연결 가능성을 확인하세요.

getent hosts ldap1.example.com
nc -zv ldap1.example.com 389

DNS에서 잘못된 주소가 반환되면 먼저 이름 확인 문제를 해결하십시오. DNS는 올바르지만 포트에 연결할 수 없는 경우 네트워크 라우팅, 호스트 방화벽, 보안 그룹 또는 LDAP 데몬 리스너를 조사하십시오. TCP 연결 시간 초과가 발생했다는 이유만으로 LDAP 암호를 변경하지 마십시오. 시간 초과는 바인딩 자격 증명이 평가되기 전에 발생합니다.

Zimbra의 최신 v10 멀티 서버 가이드에서는 LDAP를 사용하지 않는 노드가 구성 중에 LDAP 마스터에 연결해야 한다고 명시적으로 요구하며, 서버에 연결할 수 없는 경우 설치를 진행할 수 없다고 안내합니다. 자세한 내용은 Zimbra Daffodil v10 멀티 서버 설치 가이드를 참조하십시오 .

3. 수리할 부분을 결정하기 전에 로그를 읽어보세요.

Zimbra 중앙 로그를 사용하여 오류 유형을 식별하십시오.

tail -n 100 /var/log/zimbra.log

한 줄짜리 오류 메시지보다는 패턴을 찾아보세요. 일반적인 범주로는 연결 시간 초과, 연결 거부, 호스트 이름 오류, 바인딩 실패 또는 TLS 유효성 검사 오류 등이 있습니다. 각 범주마다 해결 방법이 다르기 때문에 범주를 파악하는 것이 중요합니다.

• 타임아웃 또는 경로 없음: DNS, 라우팅, 방화벽 또는 호스트 오류에 집중하세요.
• 연결이 거부되었습니다. 호스트에 연결할 수는 있지만 구성된 포트에서 연결을 수락하는 프로세스가 없거나 로컬 방화벽에서 연결을 차단하고 있습니다.
• TLS/SSL 유효성 검사 오류: 인증서 및 신뢰 체인을 확인하십시오.
• 인증 또는 바인딩 오류가 발생한 경우에만 LDAP 암호 또는 복제 자격 증명을 조사하십시오.

인증서가 문제일 때

Zimbra는 루트 또는 중간 CA가 만료되어 LDAP 통신이 실패하는 사례를 문서화했습니다. 상용 인증서의 유효성을 확인하는 데 유용한 명령어는 다음과 같습니다.

/opt/zimbra/bin/zmcertmgr verifycrt comm   commercial.key commercial.crt commercial_ca.crt

관련 상용 인증서 파일이 있는 디렉토리(일반적으로 /etc /opt/zimbra/ssl/zimbra/commercial//certificate ...

참고: 만료된 루트 CA 및 LDAP TLS 오류에 대한 Zimbra 지침 .

4. 교체 사항을 확인한 후에만 오래된 LDAP 엔드포인트를 수정하십시오.

구성된 호스트 이름이 더 이상 사용되지 않고 올바른 활성 LDAP 서버를 이미 확인한 경우, zimbra사용자 계정으로 로컬 구성을 업데이트하십시오. 예를 들면 다음과 같습니다.

zmlocalconfig -e ldap_url="ldap://ldap1.example.com:389"
zmlocalconfig -e ldap_master_url="ldap://ldap1.example.com:389"

복제본을 사용하는 배포 환경에서는 서버 목록을 하나로 줄이는 대신 환경에 맞게 문서화된 토폴로지를 사용하십시오. Zimbra v10 문서에는 마스터 서버를 포함하면서 읽기 시 복제본을 먼저 나열하는 예제가 나와 있습니다. 마스터 서버가 여러 개인 환경에서는 고유한 순서 요구 사항이 적용됩니다.

이 예시 URL을 그대로 복사하지 마십시오. 프로토콜, 호스트 이름, 포트 및 마스터/복제본 역할을 먼저 확인하십시오. 배포 환경에서 LDAPS 또는 StartTLS를 사용하는 경우, 시작을 성공시키기 위해 일반 LDAP으로 자동 전환하는 대신 보안 설계를 유지해야 합니다.

5. 한 번 재시작한 다음 전체 종속성 체인을 검증하십시오.

실제 원인을 해결한 후 Zimbra를 다시 시작하십시오.

zmcontrol restart

그런 다음 확인하십시오.

ldap status
zmcontrol status

단순히 오류 메시지만 변경하는 재시작으로는 충분하지 않습니다. /var/log/zimbra.log반복적인 연결 실패가 발생하는지 다시 확인하고 서버 역할에 적합한 일반적인 관리자 또는 사용자 작업을 테스트하십시오.

6. 다중 서버 환경에서는 추가적인 복제 검사가 필요합니다.

LDAP 복제본 또는 여러 마스터 서버를 실행하는 경우, 복제 상태가 비정상적일 때에도 서버에 접속할 수 있습니다. Zimbra는 zmreplchk복제 유효성 검사 유틸리티에 대한 문서를 제공합니다.

/opt/zimbra/libexec/zmreplchk

멀티 마스터 시스템의 경우, Zimbra 설명서에서는 정상적인 결과를 오류 코드 0의 동기화 상태로 설명합니다. 정확한 복구 절차는 단일 마스터 복제, 멀티 마스터 복제 또는 마이그레이션 진행 여부에 따라 달라집니다.

Zimbra LDAP 멀티 마스터 복제 지침 및 최신 Zimbra 10 멀티 서버 설명서를 참조하십시오 .

문제 해결 방향을 언제 바꿔야 할까요?

다음 중 하나라도 해당될 경우, 이를 단순한 연결 문제로 취급하지 마십시오.

• slapd호스트 이름과 포트 구성이 올바르더라도 시작되지 않습니다.
• 로그에는 네트워크 오류가 아닌 데이터베이스 백엔드 또는 LDAP 데이터 저장소 오류가 보고됩니다.
• 연결이 복구된 후에도 복제본이 동기화되지 않은 상태로 남아 있습니다.
• 마이그레이션 후 LDAP 마스터 또는 복제본 간에 암호가 다릅니다.
• 구성된 호스트 이름이 더 이상 서버에 속하지 않으므로 LDAP 수신기가 바인딩할 수 없습니다.

이 경우 문제는 단순히 "서버 응답 없음" 문제가 아니라 LDAP 데이터베이스 복구, 복제 자격 증명, 마이그레이션 상태 또는 서버 ID와 관련된 문제일 수 있습니다. Zimbra의 마이그레이션 문서에서는 DNS, 호스트 이름 불일치, 잘못된 로컬 구성 암호, 그리고 이전 LDAP 서버에 대한 오래된 참조 등이 모두 LDAP 시작을 방해할 수 있다고 명시적으로 언급하고 있습니다.

하지 말아야 할 일

• 문제 해결 초기 단계에서 LDAP 데이터베이스 파일을 삭제하지 마십시오.
• 인증 계층이 실패 원인임을 입증하기 전에는 LDAP 암호를 재설정하지 마십시오.
• 복제본 하나가 응답한다는 이유만으로 모든 LDAP URL에서 마스터를 제거하지 마십시오.
• 단순히 연결을 성공시키기 위해 TLS 검증을 비활성화하지 마십시오.
• zmcontrol restart실행 후 로그를 확인하지 않고 반복적으로 실행하지 마십시오 .

최종 복구 체크리스트

• LDAP 호스트 이름이 의도한 호스트로 확인됩니다.
• 영향을 받는 Zimbra 노드에서 LDAP 포트에 접근할 수 있습니다.
• ldap_url그리고 ldap_master_url현재 토폴로지와 일치시킵니다.
• 암호화된 LDAP를 사용하는 경우 TLS 인증서 체인이 유효합니다.
• ldap status보고서가 slapd실행 중입니다.
• zmcontrol status필수 서비스가 실행 중임을 보여줍니다.
• 복제는 가능한 경우 동기화됩니다.
• /var/log/zimbra.log더 이상 반복적인 LDAP 오류가 발생하지 않습니다.

이 절차의 주요 한계는 "LDAP 서버 응답 없음"이 단일 근본 원인이 아니라 종속성 문제의 증상이라는 점입니다. 이는 LDAP 프로세스 중단, 오래된 URL, DNS 오류, 포트 차단, 인증서 오류, 복제 문제 또는 잘못된 자격 증명 등 다양한 원인으로 발생할 수 있습니다. 따라서 가장 안전한 접근 방식은 각 계층이 정상인지 확인하고 문제가 발생하는 계층만 수정하는 것입니다.