직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글191 SSH Too many authentication failures 해결: agent 키·IdentitiesOnly·실제 설정 확인 올바른 키가 있는데 Too many authentication failures로 연결이 끊기면, 먼저 ssh-agent가 제공하는 키 목록과 클라이언트의 실제 IdentityFile 설정을 확인하세요. 필요한 호스트에 IdentitiesOnly yes와 맞는 키를 지정하는 것이 출발점입니다. 이 오류를 해결하려고 서버의 인증 제한을 무조건 높이거나 호스트 키 검증을 끄지 않습니다.원인: 목적지 키에 도달하기 전에 다른 인증 후보가 시도될 수 있다ssh-agent에는 여러 서비스용 키가 등록될 수 있습니다. 클라이언트 설정·에이전트가 제시하는 후보와 서버의 접속당 인증 제한이 만나면 원하는 키로 인증하기 전에 연결이 종료될 수 있습니다. 다만 모든 동일 문구가 agent 때문이라고 단정하지 말고 실제 로그.. 2026. 10. 17. Docker COPY checksum not found 해결: 빌드 컨텍스트·dockerignore·스테이지 확인 COPY 단계의 failed to calculate checksum 또는 not found 오류는 먼저 빌더가 해당 소스 파일을 볼 수 있는지 확인해야 합니다. docker build의 마지막 경로인 컨텍스트, 그 안의 .dockerignore, COPY --from의 스테이지를 순서대로 대조하세요. Dockerfile이 있는 폴더와 COPY의 기준 폴더가 항상 같은 것은 아닙니다.원인 구분: 파일이 없음·범위 밖·제외됨·다른 스테이지이 글은 로컬 파일을 쓰는 Linux 컨테이너 빌드와 Compose V2를 기준으로 합니다. 예를 들어 저장소에 dist가 있어도 빌드 컨텍스트가 다른 폴더거나 ignore 패턴으로 제외되면 COPY 소스로 전달되지 않습니다. 로그에 checksum이라는 단어가 있다고 곧바.. 2026. 10. 17. S3 presigned URL과 CloudFront 서명 URL 비교: 비공개 다운로드 권한·캐시 선택 임시 다운로드를 S3에서 직접 제공하면 S3 presigned URL을, 여러 지역의 이용자에게 CDN 캐시를 쓰면서 접근을 제한하려면 CloudFront 서명 URL을 검토하세요. OAC는 CloudFront의 S3 원본 접근을 제어하며 이용자의 다운로드 자격을 대신 확인하지 않습니다. 두 서명 방식을 같은 URL에 섞기 전에 어느 서비스가 요청을 검증할지 정해야 합니다.혼동의 원인: 이용자 권한·서명·원본 접근을 한 설정으로 보기애플리케이션은 로그인한 사람이 해당 파일을 받을 수 있는지 판단합니다. 그 다음 허용된 파일과 기간에 한정해 URL을 발급합니다. 파일 저장소를 비공개로 만들었다는 사실만으로 이 애플리케이션 권한 검사가 생기지는 않습니다. 반대로 앱 화면에서 버튼을 숨겨도 이미 유출된 유효 .. 2026. 10. 17. PostgreSQL 이전: pg_dump와 AWS DMS 선택, 중단 시간·CDC·검증 기준 전체 복사와 복원에 필요한 쓰기 중단을 감당할 수 있다면 pg_dump·pg_restore를 먼저 검토하고, 복사 중에도 변경을 받아야 한다면 AWS DMS의 CDC를 비교하세요. 결정 기준은 데이터 크기 하나가 아니라 허용 중단 시간, 스키마 범위, 변경률과 되돌림 가능성입니다. DMS를 켠다고 무중단 이전이나 완전한 객체 이전이 자동 보장되지는 않습니다.선택이 어려운 원인: 한 번의 복사와 지속 동기화를 같은 작업으로 보기pg_dump는 실행 시점의 일관된 데이터베이스 덤프를 만들지만 이후 변경을 계속 전달하는 도구는 아닙니다. 덤프 중 쓰기를 허용할 수 있다는 점과, 서비스 전환 때 누락 없이 최신 상태를 만들 수 있다는 점을 구분해야 합니다. 마지막 쓰기를 멈춘 뒤 덤프·전송·복원을 진행하는 단순.. 2026. 10. 17. Docker·CI Git dubious ownership 해결: UID·마운트·safe.directory 점검 Docker나 CI에서 detected dubious ownership in repository가 나오면 Git 실행 사용자와 저장소의 실제 소유자를 먼저 비교하세요. UID·GID와 마운트 설계를 맞추는 것이 우선이며, 의도적으로 공유하는 신뢰된 저장소만 정확한 경로의 safe.directory 예외로 검토합니다. 모든 저장소를 신뢰하는 와일드카드 설정은 사용하지 않습니다. 이 글은 Git 소유권 검사이며 Docker 소켓 권한이나 파일 쓰기 권한 오류와는 별도입니다.원인: 쓰기 권한과 저장소 소유권 검사는 다르다호스트의 저장소를 컨테이너에 bind mount하면 컨테이너가 보는 경로와 실행 사용자가 호스트 작업 환경과 다를 수 있습니다. 파일을 읽거나 쓸 수 있어도 Git이 다른 소유자의 저장소를 신.. 2026. 10. 16. SSH Host key verification failed 해결: 지문·포트·known_hosts 확인 순서 Host key verification failed가 나오면 known_hosts를 통째로 지우지 말고, 실제 접속할 호스트·포트와 서버 호스트 키 지문을 신뢰 가능한 별도 경로에서 먼저 확인하세요. 정당한 서버 교체가 확인된 뒤 해당 항목만 갱신합니다. 이 오류는 서버 신원 확인 문제이며 사용자의 개인 키로 로그인하는 Permission denied (publickey)와 해결 순서가 다릅니다. 아래는 OpenSSH를 쓰는 Linux·macOS·CI 환경의 문서 기반 절차입니다.원인 구분: 새 서버·바뀐 키·잘못된 접속 대상서버 재설치로 호스트 키가 바뀌었을 수도 있지만 DNS·프록시·포트 설정 때문에 다른 서버에 닿았을 수도 있습니다. 경고는 공격 가능성도 포함하므로 “오래된 캐시”로 단정하지 않습니.. 2026. 10. 16. 이전 1 2 3 4 ··· 32 다음
