Wiki

첫 로그인 및 초기 설정

초기 admin 비밀번호로 로그인하고 즉시 변경하세요.

설치 후, 서버는 자체 서명 인증서를 사용하여 https://<ip-du-serveur>:8443 에서 HTTPS로 수신 대기합니다. 아래 절차는 한 번만 수행하며, 전적으로 uVersion 데스크톱 클라이언트 에서 진행합니다. 약 5분 정도 소요됩니다.

1. 초기 비밀번호 가져오기

설치 프로그램은 작업 종료 시, 해당 비밀번호가 속한 admin 계정과 함께 이를 표시하며, 일회용임을 다시 알려줍니다.

서버 설치 종료 시 표시되는 요약: admin 사용자와 생성된 비밀번호가 담긴 Initial admin login 블록, 첫 로그인 시 변경하라는 경고, 그리고 포트 8443의 https 서버 주소.

기록해 두지 않았더라도, 서버 시스템에서 확인할 수 있습니다:

설치	명령
Linux (`.deb`)	`sudo cat /var/lib/uversion/initial-admin-password`
Windows	`Get-Content "C:\ProgramData\uVersion\initial-admin-password"`
Docker	`docker compose exec server cat /data/initial-admin-password`

데이터 디렉터리를 옮겼다면 /var/lib/uversion 를 사용자의 경로로 바꾸세요: 이 파일은 데이터 옆에 기록되며, 그 위치는 config.toml 의 [storage].path 에서 파생됩니다.

2. 데스크톱 클라이언트에서 로그인하기

https:// 는 고정되어 있어 입력하지 않습니다: 입력하는 것은 시스템 주소와 포트(기본값 8443)뿐입니다. 그다음 admin 사용자와 1단계에서 가져온 비밀번호를 입력합니다.

3. 서버 지문 확인하기

로그인하는 대신, 클라이언트는 인증서 지문을 표시하는 Verify server identity 창을 열고, 관리자가 전달한 지문과 비교하도록 요청합니다. 여기서 관리자는 바로 당신입니다: 서버에서 이 지문을 확인하는 세 가지 방법은 TLS 지문 에 있습니다. Trust this server 를 확정하면 연결이 스스로 재개되며, 이 창은 이 워크스테이션에서 다시 나타나지 않습니다.

4. 비밀번호 변경하기

초기 비밀번호는 즉시 변경해야 합니다: 클라이언트는 다른 어떤 것도 보여주기 전에 이를 강제하는 전용 페이지를 엽니다. 현재 비밀번호를 다시 묻고, 새 비밀번호는 최소 8자입니다.

첫 admin 로그인 직후에 표시되는 Set a new password 페이지: Current password, New password, Confirm new password 필드, 그리고 Update password 버튼.

변경하면 현재 세션이 취소됩니다: 새 비밀번호로 인증하기 위해 로그인 화면으로 돌아갑니다. 정상입니다.

그러면 서버가 initial-admin-password 파일을 자동으로 삭제합니다(수동 작업 불필요). 파일이 남아 있다면 변경이 아직 수행되지 않은 것입니다.

5. 팀 계정 생성하기

계속 데스크톱 클라이언트에서: 사이드바의 Admin, Users 탭, Create User 버튼. 각 계정은 생성 시 역할을 받으며, 이 역할이 무엇을 할 수 있는지 결정합니다: 사용자 참조. 여기서 입력한 비밀번호는 본인에게 전달되며, 본인이 이후 자신의 설정에서 변경합니다.

관리 패널의 Create User 창: Username, Email, Password 필드, Role 드롭다운, 그리고 Cancel과 Create 버튼.

다음 단계

각 워크스테이션이 확인할 수 있도록 팀과 TLS 지문을 공유: TLS 지문
첫 저장소 생성: 저장소 만들기
팀에 접근 권한 부여: 권한
비활성화된 상태로 제공되는 검증 규칙 활성화: 검증 규칙

서버 업데이트

새 버전이 게시되면, 데스크톱 클라이언트의 관리 패널에 Update now 버튼이 표시됩니다. 클릭 한 번이면 됩니다: 서버가 새 패키지를 다운로드하고 검증한 뒤 설치하고 재시작합니다. 중단은 짧고, 데이터와 데이터베이스는 손대지 않으며, 마이그레이션은 시작 시 적용됩니다(서버가 자신의 데이터베이스 구조를 스스로 업데이트합니다).

‘검증’이 정확히 무엇을 포함하는지, 그리고 양쪽이 같지 않습니다:

Linux (.deb): 서버는 게시 매니페스트를 HTTPS로 읽어, 그 안에서 패키지 주소와 SHA-256 체크섬을 찾고, 그 정확한 패키지를 다운로드하며, 체크섬이 일치하지 않으면 설치를 거부합니다. 서명은 없습니다: 신뢰는 매니페스트와 패키지를 가져오는 HTTPS에 달려 있습니다.
Windows, 버튼으로: 서버는 install.ps1 을 HTTPS로 가져와 업데이트 모드로 실행합니다. 이 모드에서는 스크립트 옆에 로컬 아카이브가 없습니다: 서명 검증을 건너뛴다고 알리고 다운로드의 HTTPS에 의존합니다.
Windows, 수동으로: 압축을 푼 아카이브에서 install.ps1 을 실행하면, 스크립트는 아카이브 옆에서 분리된 RSA-4096 서명을 찾고(없으면 다운로드), openssl로 검증합니다. 그래도 계속 진행하며 이를 알리는 경우가 두 가지 있습니다: 원본 아카이브를 찾을 수 없거나, openssl이 시스템에 설치되어 있지 않은 경우. openssl을 포함하는 Git for Windows를 설치하면 이 검증을 활성화할 수 있습니다.

이 체크섬은 다운로드된 파일 을 검증합니다. 이는 당신 서버의 인증서를 식별하고 클라이언트가 고정하는 서버 지문 과는 아무 관련이 없습니다: 두 개념, 두 용도이며, 이 공통된 단어가 모두를 혼란스럽게 합니다.

컨테이너에서는 서버가 자신의 이미지를 교체할 수 없습니다: 버튼이 이를 알리고 Docker 절차(docker compose pull 그다음 up -d)로 안내합니다.

tar.gz 아카이브 설치: 버튼이 오류를 반환합니다 업데이트 메커니즘이 설치되어 있지 않다고 설명하는 메시지와 함께 거부합니다. 이것은 고장이 아닙니다: 업데이트를 실행하는 유닛은 .deb 패키지에만 포함되므로, 아카이브 설치나 수동으로 실행한 바이너리에는 없습니다. 설치할 때와 동일하게 파일을 교체하여 업데이트하거나, .deb 로 전환하세요.

원한다면 수동으로: 설치할 때와 동일한 명령 (apt install ./uversion-server_*.deb 또는 install.ps1)으로 최신 패키지를 다시 설치하기만 하면 됩니다. 설치 프로그램은 기존 구성과 라이선스를 재사용합니다.