Collabora의 활성 문서 보기용 유휴 타이머 설정

열려 있는 Collabora 뷰가 비활성화된 상태로 유지되다가 비활성화되고 업데이트 수신이 중단되는 시간을 변경하려면 다음 값을 조정하세요 per_view.idle_timeout_secs. 현재 상위 coolwsd.xml템플릿에서는 이 뷰 수준 타이머를 900초(15분)로 설정합니다. 예를 들어 30분으로 설정하려면 1800으로 설정하세요. 이 타이머는 로그아웃 타이머나 유휴 문서 언로드 시간 초과와는 다릅니다.

어떤 타이머를 변경하는지 알아두세요.

뷰 는 사용자가 브라우저에서 열어 놓은 문서의 보기입니다. coolwsdCollabora Online을 제공하는 웹 데몬에서 이 per_view설정 idle_timeout_secs은 비활성 사용자 보기가 흐려지고 업데이트가 중지되기까지의 시간(초)을 나타냅니다. 브라우저 탭에 포커스가 유지되는 동안에도 이 상태가 유지됩니다. 현재 업스트림 템플릿은 기본값으로 900초를 제공합니다. 사용자의 패키지 또는 관리형 서비스에서 이 값을 재정의할 수 있으므로 배포 환경에서 실제로 사용되는 구성을 확인하십시오.

설정유휴 상태가 되는 것현재 업스트림 템플릿 기본값
per_view.idle_timeout_secs집중 보기에서 사용자 활동900초(15분)
per_view.out_of_focus_timeout_secs탭의 포커스가 사라진 후의 브라우저 화면300초(5분)
per_document.idle_timeout_secs언로드하기 전에 활성 뷰가 없는 문서3600초(1시간)

첫 번째 설정은 사용자가 읽거나 일시 중지하는 동안 집중 편집 보기가 더 오래 유지되도록 하려는 경우에 사용합니다. 두 번째 설정은 배경 탭이 너무 빨리 어두워지는 경우에만 사용합니다. 세 번째 설정은 문서에 활성 보기가 없을 때 서버 측에서 수행하는 정리 작업입니다. 이 설정을 변경해도 열려 있는 보기의 비활성 동작은 변경되지 않습니다. 자동 저장 및 유휴 저장 설정은 수정된 콘텐츠가 저장되는 시점을 제어하는 ​​것이지, 보기가 활성 상태로 유지되는 시간을 제어하는 ​​것이 아닙니다.

out_of_focus_timeout_secs를 300으로, idle_timeout_secs를 900으로 설정한 per_view를 보여주는 예시 XML 편집기입니다.
두 개의 뷰별 타이머는 서로 다른 유형의 비활성 상태를 처리합니다. 하나는 포커스가 없는 탭이고, 다른 하나는 포커스가 있는 탭에서 비활성 상태인 사용자입니다.

타임아웃 시간을 선택하고 구성을 준비하세요.

워크플로에 맞는 기간을 선택한 다음 초 단위로 변환하세요. 20분은 1200초, 30분은 1800초, 45분은 2700초입니다. 아래 예시에서는 30분을 사용했지만, 이는 단지 예시일 뿐이며 모든 경우에 적용되는 권장 사항은 아닙니다. 더 긴 값을 사용하면 유휴 보기의 유지 시간이 길어지고 문서 처리 및 업데이트 활동도 더 오래 보존될 수 있습니다.

편집하기 전에 Collabora가 어떻게 설치되었는지 확인하십시오. Docker CODE, Linux 패키지, Helm 배포 및 호스팅 제공업체에 따라 구성에 접근하는 방식이 다를 수 있습니다. 현재 사용 중인 구성을 백업하거나 Compose 파일의 사본을 저장해 두십시오. 통합 도구가 서버를 관리하는 경우 컨테이너의 임시 파일 시스템을 편집하는 대신 통합 도구에서 지원하는 구성 메커니즘을 사용하십시오.

뷰별 유휴 시간 제한을 설정하세요

Compose를 사용한 Docker CODE

extra_paramsCollabora 서비스의 기존 값에 옵션을 추가합니다 .

services:
  collabora:
    environment:
      extra_params: "--o:per_view.idle_timeout_secs=1800"

이미 옵션이 있는 경우 extra_params, 키를 두 번 정의하는 대신 동일한 값에 이 옵션을 추가하세요. 기존 SSL, 프록시 및 호스트 설정은 그대로 유지하세요. Docker 이미지는 --o:옵션을 전달합니다 coolwsd. 공식 CODE Docker 문서에서 이 구성 방법을 설명합니다.

예시 XML 편집기는 per_view idle_timeout_secs 값이 900에서 1800으로 변경되었지만 out_of_focus_timeout_secs 값은 300으로 유지되는 것을 보여줍니다.
30분 동안 집중 보기 상태를 유지하지 않는 임계값을 설정하려면 보기별 값을 1800초로 변경하고 별도의 탭 집중 타이머는 그대로 두십시오.

Linux 패키지 또는 마운트된 XML 구성

활성화된 coolwsd.xml파일을 편집하고 해당 <per_view>섹션 내의 값을 변경하십시오. 주변의 구성 및 파일에 있는 모든 속성은 그대로 유지하십시오.

<per_view>
  <out_of_focus_timeout_secs>300</out_of_focus_timeout_secs>
  <idle_timeout_secs>1800</idle_timeout_secs>
</per_view>

두 번째 블록을 붙여넣거나 실행 중인 구성인 것처럼 <per_view>소스 템플릿을 편집 하지 마십시오 . 올바른 파일 경로와 구성 소유자는 패키지 및 배포 환경에 따라 다를 수 있습니다.coolwsd.xml.in

Collabora 서비스 환경에서 extra_params를 --o:per_view.idle_timeout_secs=1800으로 설정한 예시 Docker Compose YAML 편집기입니다.
CODE Docker 예제는 서비스의 기존 extra_params 설정을 통해 뷰별 값을 전달합니다.

Collabora 서비스를 다시 시작하거나 새로 생성하여 설정을 적용하세요. 일반적인 Compose 서비스 이름의 경우 다음 명령 collabora을 실행합니다.

docker compose up -d --force-recreate collabora

Compose 파일에 있는 서비스 이름으로 바꾸세요. systemd로 관리되는 패키지 설치의 경우, 활성 구성을 편집한 후 서비스를 다시 시작하세요(예: ) sudo systemctl restart coolwsd. 새 브라우저 탭에서 문서를 다시 열어 테스트에서 새로 생성된 뷰를 사용하도록 하세요.

동작을 검증하고 결과를 문제 해결하세요

  1. 위험도가 낮은 테스트 문서를 브라우저 탭에서 열고 시간을 기록하세요. 저장하지 않은 프로덕션 편집본을 타임아웃 테스트에 사용하지 마세요.
  2. 설정된 시간 간격 동안 뷰를 그대로 두십시오. 1800초 후에 뷰 설정에 따라 뷰가 어두워지고 업데이트 수신이 중지되는지 확인하십시오. 이러한 시각적 상태를 사용자가 로그아웃되었거나 문서가 언로드되었다는 증거로 해석해서는 안 됩니다.
  3. 문서로 돌아가서 배포 환경에서 동작이 허용 가능한지 확인하십시오. 그런 다음, out_of_focus_timeout_secs워크플로가 중요한 경우 특정 시간 이상 동안 백그라운드 탭을 전환하여 별도의 백그라운드 탭 사례를 테스트하십시오.

재시작 후 일부 빌드에서는 기본값이 아닌 구성 값 목록이 로그에 기록됩니다. 시작 로그에 해당 내용이 표시되면 per_view.idle_timeout_secs: 1800해당 항목을 확인하십시오. 동작이 여전히 이전 값과 일치하는 경우, 실행 중인 프로세스에서 사용하는 파일 또는 Compose 서비스를 편집했는지, 변경 사항을 적용했는지, 그리고 환경 변수 또는 명령줄 옵션이 XML을 재정의하지 않는지 확인하십시오.

예상되는 30분 유휴 화면 확인 절차를 보여주는 예시 브라우저 문서 및 메모입니다.
새로운 테스트 뷰를 사용하고 설정된 간격 동안 기다리십시오. 이 패널은 측정 결과가 아닌 검사 과정을 보여줍니다.

문서가 열려 있는 뷰가 없는 상태에서 오랜 시간이 지난 후에야 사라지는 경우, 문제를 검토해 보세요 per_document.idle_timeout_secs. 사용자가 로그아웃되는 경우 호스트 플랫폼의 인증 또는 세션 정책을 확인하십시오. 이러한 사항은 서로 다른 계층에 있으며 에서 제어하지 않습니다 per_view.idle_timeout_secs. 뷰가 더 빨리 어두워지도록 문서 언로드 설정을 단축하지 마십시오.

현재 설정 이름 및 상위 기본값에 대한 자세한 내용은 Collabora Online 구성 템플릿을 참조하십시오 . Docker extra_params방식 에 대한 자세한 내용은 CODE Docker 이미지 문서를 참조하십시오 . 기본값 및 구성 전달 방식은 버전 및 패키징에 따라 다를 수 있으므로 실행 중인 버전 및 패키징에 맞춰 정확한 동작을 확인하십시오.

댓글 남기기

Collabora CODE 업데이트 확인 및 원치 않는 연결 비활성화

Collabora CODE 업데이트 확인 및 원치 않는 연결 비활성화

예약된 CODE 업데이트 확인을 중지하고, 선택적 원격 서비스를 검토하고, 문서 편집을 중단하지 않고 아웃바운드 네트워크 제어를 사용하십시오.

Seafile과 Collabora를 올바른 WOPI URL로 연결하세요

Seafile과 Collabora를 올바른 WOPI URL로 연결하세요

Seafile에서 안전한 문서 편집을 활성화하려면 Collabora의 검색 URL, HTTPS 및 WOPI 액세스를 배포 환경에 맞게 구성하십시오.

Collabora와 데스크톱 앱 간 복사 및 붙여넣기 기능 복원

Collabora와 데스크톱 앱 간 복사 및 붙여넣기 기능 복원

시스템 클립보드를 테스트하고, 브라우저 권한을 조정하고, 내장된 Collabora 통합에 iframe 정책 변경이 필요한 시점을 파악합니다.

Collabora CODE Docker에서 사용자 지정 글꼴을 사용할 수 있도록 설정

Collabora CODE Docker에서 사용자 지정 글꼴을 사용할 수 있도록 설정

글꼴 파일을 Docker 및 Collabora의 시스템플레이트에 마운트하여 사용자 지정 글꼴이 편집기에 표시되고 문서에서 올바르게 렌더링되도록 합니다.

배포 변경 사항을 손실하지 않고 Collabora CODE 설정을 복원하는 방법

배포 변경 사항을 손실하지 않고 Collabora CODE 설정을 복원하는 방법

coolwsd.xml 파일과 배포 소스를 백업하고 안전하게 복원한 다음, 사용자가 편집을 재개하기 전에 코드를 검증하십시오.

CODE의 WOPI 호스트 검사 오류를 수정하려면 호스트 출처를 일치시키세요.

CODE의 WOPI 호스트 검사 오류를 수정하려면 호스트 출처를 일치시키세요.

CODE에서 정확한 Nextcloud 또는 기타 WOPI 출처를 허용한 다음 활성 호스트 허용 목록을 확인하고 Nextcloud의 소스 IP 제한과 구분하십시오.

Collabora의 "이건 정말 난감한 상황이네요" 오류 해결하기

Collabora의 "이건 정말 난감한 상황이네요" 오류 해결하기

Collabora의 브라우저, WOPI 및 WebSocket 연결을 추적하여 문서가 열리지 않는 이유를 찾은 다음 Nextcloud 설정에 맞는 해결 방법을 적용하십시오.

Kubernetes 노드에서 Collabora를 온라인으로 실행하세요

Kubernetes 노드에서 Collabora를 온라인으로 실행하세요

Helm을 사용하여 Collabora CODE 복제본을 배포하고, WOPI 어피니티를 통해 각 문서를 하나의 Pod에 유지하며, 인그레스, 노드 배치 및 Nextcloud 편집을 검증합니다.

프록시를 통해 Collabora의 WebSocket 연결을 복원합니다.

프록시를 통해 Collabora의 WebSocket 연결을 복원합니다.

브라우저에서 coolwsd로의 소켓 핸드셰이크 실패를 추적한 다음, 역방향 프록시 경로를 Collabora 버전(CODE 26.04 Apache 변경 사항 포함)과 일치시키십시오.

키, 검색 및 URL을 확인하여 WOPI 증명 오류를 수정하세요.

키, 검색 및 URL을 확인하여 WOPI 증명 오류를 수정하세요.

Collabora WOPI 증명 실패 원인을 키 불일치, 오래된 검색 데이터, 시간 오차 또는 프록시 URL 변경으로 추적할 수 있으며, 이 과정에서 유효성 검사를 약화시키지 않습니다.