문제가 발생하는 과정
파일을 열고 자신의 사본을 편집하는 동안 다른 관리자, 구성 관리 작업, 패키지 업그레이드 또는 애플리케이션 자체가 원본에 쓸 수 있습니다. 이때 저장하면 오류 없이 다른 쪽의 변경이 사라집니다. 로컬에서 편집한 뒤 SFTP로 업로드하는 방식은 특히 취약합니다. 읽기와 쓰기 사이의 시간이 길고 일반 업로드는 아무것도 비교하지 않기 때문입니다.
시작하기 전에 상태 기록
파일을 다운로드할 때 체크섬과 마지막 변경 시간을 기록하세요. 업로드 직전에 다시 확인하세요. 체크섬이 다르면 파일이 변경된 것이므로 내용을 살펴보지 않고 덮어쓰면 안 됩니다.
sha256sum /etc/example.conf
stat -c '%y %U %G %a' /etc/example.conf변경 사항 비교 및 병합
편집한 사본을 새 이름으로 보관하고 현재 버전을 가져와 편집을 시작했던 버전 및 자신의 버전과 비교하세요. 그런 다음 현재 버전을 덮어쓰는 대신 그 버전에 자신의 변경을 적용하세요. diff3 명령으로 세 버전을 함께 볼 수 있습니다.
diff -u example.conf.orig example.conf.current
diff -u example.conf.orig example.conf.mine
diff3 example.conf.mine example.conf.orig example.conf.current파일을 변경하는 원인 확인
파일이 계속 바뀐다면 다시 편집하기 전에 원인을 찾으세요. 누가 파일을 열고 있는지 확인하고 journal과 패키지 이력을 살펴보세요. 구성 관리 도구가 파일을 관리한다면 그곳의 템플릿을 변경하세요. 그렇지 않으면 다음 실행 시 편집 내용이 교체됩니다.
sudo lsof /etc/example.conf
sudo journalctl --since "1 hour ago" --no-pager | grep example.conf
grep example.conf /var/log/dpkg.log경고는 잠금이 아님
vim이나 nano 같은 편집기는 파일이 열린 뒤 변경되면 경고하지만 다른 프로세스가 쓰는 것을 막지는 않습니다. 체크섬 비교도 마찬가지입니다. 저장 직전에 검사하면 충돌이 발생할 수 있는 시간은 매우 짧아지지만 완전히 없어지지는 않습니다. 여러 사람이 작업하는 서버에서는 구성 원본을 버전 관리하는 것이 어떤 편집기보다 더 나은 보호를 제공합니다.
CH-J Server Manager의 저장 보호
File Manager 편집기는 저장할 때 파일을 다시 검사합니다. 내용, 권한 또는 링크 대상이 바뀌었다면 저장을 중단하고 원본을 그대로 둡니다. 이후 서버에서 현재 버전을 불러올 수 있지만 저장하지 않은 변경 사항이 버려지므로 먼저 자신의 텍스트를 다른 곳에 복사하세요. 편집기는 버전을 대신 병합하지 않습니다. 파일 전송 시 앱은 변경되었거나 이미 존재하는 대상을 교체하기 전에 확인을 요청하며, 전송 중 원본이 바뀌면 처음부터 다시 시작하라고 안내합니다.