2021. 6. 19. 13:42ㆍRS Team Develop
안녕하세요. 알에스팀 개발2팀 팀장 허윤입니다.
"[우당탕탕] 서버이전 회고록 1편" 에 이어 2편을 작성해보고자 합니다.
위기
부제 - 놓치고있었던 FTP 설정
저희회사는 기본적으로 외부에서 서버 및 계정에 대한 접근을 제한합니다.
따라서 FTP 설정이나 기타 User 설정을 진행하지 않습니다.
하지만 이번 외부서비스같은경우에는 FTP 접근을 요청하셨었기 때문에 기존서버에서도 FTP 연결을 허용하였었습니다.
이 부분을 놓치고 있다가 해당 사실을 알게 된 저는 곧바로 User 생성을 하였습니다.
하지만 기존서버와 Lightsail 에는 하나 차이점이 있었습니다.
- 기존서버는 FTP 접속
- Lightsail은 SFTP 접속
이 두가지 접속에는 생각지 못한 차이점이 있었습니다.
FTP 접속을 통했을 시에는 vsftpd 설정을 통해 상위폴더 접근제한이 가능하기 때문에 손쉽게 기타 프로젝트 제한이 용이했습니다.
하지만 SFTP 는 SSH를 통한 접속으로 상위 폴더 접근제한을 위해서는 Chroot 를 설정해야했습니다. 해당 설정에는 처음이었던 저는 개발자의 영원한 선생님 Google님과 함께 Chroot 세팅작업을 시작했습니다.
- 계정 생성
- 비밀번호 세팅
- SSH 설정 변경()
- SSH 재시작
- 폴더권한 및 소유자 변경
사실 이렇게 간추리면 정말 간단한 작업이지만 사실 실제작업을 할 당시 너무 왜 그랬는지는 모르겠지만 굉장히 당황스럽고 어려웠습니다..
(Lightsail 에서 위 Chroot 세팅하는 방법은 별도로 블로그 포스팅을 해보도록 하겠습니다.)
이 간단한 작업을 하면서 여러가지 오류가 발생했습니다.
첫번째 문제
오류 : FATAL ERROR: Connection reset by peer
하... 도대체 무엇이 문제였는지 알 수 없었습니다. 분명히 세팅하라는대로 세팅하였는데 말이죠.
검색해가며 알게된 사실이지만 이것은 폴더 Permission 오류였습니다.
프로젝트 폴더들이 모여있는 폴더 즉 $home 디렉토리 소유자가 bitnami 로 설정되어있어 발생한 오류였습니다.
sudo chown root:root home폴더이름
을 통해 해결되었습니다.
두번째문제
오류 : open for write: permission denied
이젠 접속을 했는데 파일 생성조차 되지 않습니다.. Hㅏ....
하지만 이 문제도 소유자, 권한 문제였습니다.
이부분도 새로운 폴더를 생성하고, 소유자, 권한을 설정해준 결과
이렇게 의도한대로 정상작동이 됩니다!!
이렇게 해당 업체에 이부분을 안내하고 접속테스트도 끝났고~
다음날 아침 신나는 기분으로 출근을했어요~~
절정
이제 다음날이 되어 출근을 해 자잘한 수정사항이 있어 SSH를 연결했습니다~
?????????
접속이 안된다?
문제를 정리해보자면
1. test(가칭) 라는 새로운 유저를 생성하고, test라는 그룹을 부여했습니다.
2. Chroot 적용을 위해 abc라는 그룹의 유저가 접속을 하면 test 디렉토리에만 귀속이 되도록 세팅을 하였습니다.
3. 관리자(Bitnami) 계정에서도 해당 유저의 파일을 수정하려면 test라는 그룹에 속해있으면 관리가 가능하겠지라고 생각하고 abc그룹을 추가해주었습니다.
네 Chroot 적용시킨 계정은 SSH를 사용할 수 없습니다.
SSH를 사용할 수 없다 => SSH작업 및 서버 파일 관리조차 아무것도 할 수 없다.
정말 큰일났다. 이 서버는 일단 실 운영중인 외부서비스가 있을 뿐더러 회사 자사서비스와 회사 홈페이지가 돌아가고있는 서버이다.
더 큰일인점은 이 서버에서 외부서비스의 데이터베이스 또한 작동되고있다.
심지어 외부에서 데이터베이스 연결을 위해서는 보안을 위해 SSH연결이 필수이다.
따라서 정말 큰일이다.
해결방법은 몇가지가 있었는데
1. 어떻게든 비밀번호로그인이던 다른계정을 찾는다.
Lightsail 에서 제공되는 관리자 계정은 Bitnami 와 Root 이다.
Root 계정같은경우에는 sshd_config 파일에서 접속을 허용해주지 않으면 죽었다 깨어나도 접속할 수 없다.
이걸 보안상으로라도 Root 계정 접속을 허용했을 리 없고, 다른 접속할 수 있는 계정은 없었다.
2. 스냅샷을 뜨고, 이 스냅샷으로 새롭게 서버를 생성한다.
아 근데 이미 ssh config가 삐꾸이기 때문에 새로 서버를 생성해도 상황은 똑같다..
3. 서버이전을 한지 10시간가량밖에(?) 되지 않았기 때문에 모든 정보를 포기하고 새로 서버이전을 한다...
아 이건 진짜 아무리 생각해도 회사 서비스 제공차원에서도 절대안된다. 이것은 정말 최후의 수단으로도 절대 안된다...
4. AWS 지원 센터에 문의한다
고객센터 페이지에 들어가보면 알겠지만,, 한국어로 문의할 수 없다.
못먹어도 본전이다 영어로 부딪혀보자
일단 문의를 해보았다.
채팅으로 해당 문의내용을 해결하기로 했고 채팅을 진행하였다.
구글 번역기를 써가면서라도 어떻게든 해결해보자
Wut?? Voice Chat?
구글번역기도 아니고 빠른 문제 해결을 위해서 외국인과 영어 채팅을 하게됐다.
사람은 궁지에 몰리면 뭐던 하게된다. 그것이 내가 자신있던 없던 상관없다.
ps. 자세히 보면 알겠지만 Voice Chat 의 문구가 채팅문구가 올라오고 1분 20초 후에 답변이 달리는데, 뭐,,,,, 그렇다.
다행히도 간단한 언어와 고등학생때 익힌 영어듣기 실력덕분인지 꽤나 매끄럽게 대화가 된것같고, 30여분동안의 기나긴 대화와 테스트 끝에 해결방안까지 나오게 되었다.
상담원이 이것저것 방법을 제시해주고 해당 방법에 대해 테스트를 이것저것 해보면서 결국에 해결방안이 나오게 되었다.
해결방안은 이러하다.
1. 문제가 생긴 서버의 스냅샷을 뜬다.
2. 해당 스냅샷을 통해 "새 인스턴스 생성" 버튼을 누른다.
3. 평소 인스턴스(서버) 생성할 때에는 눈여겨 보지 못했던 부분이 있는데,
시작 스크립트 추가라는 항목이 있다.
이 부분은 서버가 생성되면서 Root 계정의 권한으로 해당 스크립트가 작동되는데, 이때 sshd_config를 복원시키는것이다.
다행히도 라이트세일 서버 내부에는 복원용 sshd_config 파일이 있었고, 단순히 해당파일로 sshd_config 파일을 바꿔치기 해주기만 하면 해결되는것이었다.
cp /usr/share/openssh/sshd_config /etc/ssh/sshd_config
해당 스크립트문을 통해 sshd_config 파일을 바꿔치기 해주니 다행히도 정상작동을 하게 되었다.
결말
정말 다행히도 회사에 큰 손실이 발생할 수 있었던 문제가 발생했지만, 대표님, A팀장님 부장님 등 모든분들께서 보채거나 불안해 하지 않고 믿고 기다려주신 덕분에 안전하게 잘 복원할 수 있었다.문제해결을 잘 해내는것도 좋지만 가장 좋은것은 서버이전시 조금 더 꼼꼼하게 작업하여, 이런 문제를 일으키지 않는것이 중요하다.서버 파일을 수정할때는 신중하도록 하자..그리고 뭐던 적용시킬시에는 단순히 검색해서 적용하기보다는 이해를 끝내고 적용시키자.. 화이팅
'RS Team Develop' 카테고리의 다른 글
centos + tomcat + ssh + docker, install & setting (0) | 2021.08.18 |
---|---|
[홀리몰리의 엉금엉금 js 여행기] setp .1 - javascript란 (0) | 2021.05.21 |
[우당탕탕] 서버이전 회고록 1편 (2) | 2021.05.21 |
[신입 개발자의 사소한 이야기] 나의 첫 서비스 (0) | 2021.05.21 |
[우당탕탕] 협업툴의 기본 Git 도입기1 (0) | 2021.05.18 |