타사 Paperless-ngx 앱이 Compose 파일에서 잘못된 Tika 이미지를 참조해 실패한다면, 동일하게 문제가 있는 Compose를 반복해서 재설치하기보다 앱 정의를 수정하거나 유지 관리되는 패키지를 사용하세요. 원래 스레드에서는 Coolstore 패키지가 사용자가 잘못되었다고 판단한 Tika 이미지를 가리키고 있었으며, 반면 BigBear 패키지는 여러 번 시도한 끝에 결국 성공적으로 설치되었습니다.
이전 BigBear 시도가 실패한 이유는 스레드에서 확인되지 않았으므로, IP 섹션만 변경하면 항상 해결된다고 말하는 것은 부정확합니다. 지속 가능한 접근 방식은 타사 Compose를 현재 Paperless-ngx 업스트림 요구 사항과 비교하는 것입니다.
Tika는 선택 사항인 Paperless 서비스입니다
최신 Paperless-ngx 구성 참고 자료에 따르면 Tika와 Gotenberg는 Office 문서 및 이메일 구문 분석에 사용되는 선택적 서비스입니다. 해당 통합을 활성화한 경우 Paperless는 연결 가능한 엔드포인트로 구성해야 합니다.
따라서 핵심 Paperless 컨테이너 정의가 그 외에는 유효하더라도, Tika 서비스 이미지에 문제가 있으면 통합을 활성화한 설치가 중단될 수 있습니다.
Coolstore와 BigBear를 타사 패키지로 취급하세요
커뮤니티 답변에서 Coolstore가 타사 앱 소스라는 점을 정확히 지적했습니다. 해당 패키지의 이미지 참조가 잘못되었다면 이를 ZimaOS의 핵심 결함으로 해석하지 말고 유지 관리자에게 보고해야 합니다.
한 스토어 패키지가 오래된 경우 업스트림 Paperless Docker 예시나 다른 유지 관리 패키지와 비교하세요. 스택을 변경하기 전에 기존 데이터 경로를 보존하세요.
Compose를 신중하게 수정하거나 다시 가져오세요
최신 ZimaOS에서는 사용자 지정 Docker Compose 정의를 가져올 수 있습니다. 앱 스토어 정의에 잘못된 이미지나 지원되지 않는 필드가 포함된 경우에는 사용자 지정 Compose 문제 해결 가이드를 이용하는 편이 안전합니다.
ZimaOS 1.7.1의 최신 릴리스 노트에도 YAML 저장 호환성이 개선되었다고 나와 있습니다. 하지만 이 개선 사항이 타사 저장소의 잘못된 이미지 참조를 자동으로 수정해 주는 것은 아닙니다.
Paperless를 다시 설치하기 전에
- Paperless 데이터, 미디어 및 데이터베이스 위치를 백업하세요.
- 모든 이미지 참조가 실제로 존재하며 유지 관리되고 있는지 확인하세요.
- Paperless, 데이터베이스, Redis, Tika 및 Gotenberg가 의도한 Compose 네트워크에 연결되어 있는지 확인하세요.
- 성공한 수정 사항을 식별할 수 있도록 한 번에 하나의 장애 원인만 변경하세요.
스레드에서처럼 여러 번 재시도한 후 설치가 갑자기 성공하더라도 원인을 지어내지 마세요. 원래 실패 원인은 해결되지 않은 상태로 두고, 결과를 사용자가 확인한 성공으로 표시하세요.
