1.
*. ESXi 5.5 이후 네트워크 드라이버 자체지원 안 함
https://vibsdepot.v-front.de/wiki/index.php/List_of_currently_available_ESXi_packages
여기 들어가서 NIC 드라이버 맞는 거 찾은 다음 *.vid 파일 다운로드

2.
https://my.vmware.com/kr/group/vmware/details?productId=352&downloadGroup=PCLI550
여기에서 vSphere PowerCLI 다운 받아 설치하고

https://www.v-front.de/p/esxi-customizer-ps.html
여기에서 ESXi-Customizer-PS.버전.ps1 다운로드

3.
vSphere PowerCLI 실행
(만약 안 되면 윈도우 파워쉘 관리자 권한으로 실행한 뒤 Set-ExecutionPolicy RemoteSigned 입력 후 걍 엔터)
다시 vSphere PowerCLI 실행

4.
경로\ESXi-Customizer-PS.버전.ps1 -pkgDir 1번vid파일디렉토리절대경로 — 실행
(시간이 조금 걸림)

5.
vid 파일 디렉토리로 가면 iso 파일이 생성되어 있음

6.
unetbootin 이용해서 iso 파일을 usb에 굽기

7.
본체에 꽂고 ESXi 설치

해당 서버에 root 권한으로 접속 후

yum remove python-requests python-urllib3
pip uninstall requests urllib3
pip install requests==2.11.1 urllib3
yum install certbot

 

기존에 설치되어 있는 python 관련 패키지가 충돌이 나는 것 같다. (requests 부분인 듯?)

2.11.1 버전으로 재설치 후 다시 certbot 재설치하니 문제 해결.

 

출처 : https://github.com/certbot/certbot/issues/3944#issuecomment-268450209

Django 프로젝트를 Nginx 웹서버에 올리기 위해 uWSGI를 연동해야 한다.

구글에 검색되는 수많은 연동 관련 글을 보고 그에 맞게 웹서버를 설정했지만

404, 500, 502 3가지 에러가 마구 튀어나오며 실패했다.

원인을 알고 싶었지만 도무지 해결책이 나오지 않았다.

난 분명 스택오버플로우나 Django, Nginx, uWSGI 관련 문서들을 참고하며

그대로 적용했지만 그래도 결과는 똑같았다.
결국 수많은 삽질을 해가며 해결책을 찾았다.

이에 잊지 않기 위해 글로 남긴다.
* 설정에 필요한 파일 목록

1. 프로젝트 설정 파일
– /{Project Directory}/{Main}/settings.py

2. 프로젝트 Nginx 설정 파일
– /{Project Directory}/{Project Name}_nginx.conf

3. 프로젝트 uWSGI 설정 파일
– /{Project Directory}/{Project Name}_uwsgi.ini
* 예제

– /{Project Directory}/{Main}/settings.py
(…)
STATIC_URL = ‘/static/’   – A
STATICFILES_DIRS = [os.path.join(BASE_DIR, ‘devel_static‘)]   – B
STATIC_ROOT = os.path.join(BASE_DIR, ‘service_static‘)   – C
(…)

– /{Project Directory}/{Project Name}_nginx.conf
(…)
upstream django {
# /tmp 디렉토리에 소켓 파일을 지정할 경우 – 502 에러 발생
server unix:///run/{Project Name}.sock;   – D
}

server {
(…)
location /static {   – E
alias /{Project Directory}/service_static;   – F
}
(…)
}
(…)

– /{Project Directory}/{Project Name}_uwsgi.ini
(…)
socket = /run/{Project Name}.sock – G
(…)
* 디렉토리명 설명

static -> 정적파일을 불러올 URL 상의 경로명 (http://example.com/static)
devel_static -> 디버깅 모드일 때 정적파일 가져오는 디렉토리
service_static -> 실제 서비스시 정적파일 가져오는 디렉토리
* 핵심 (볼드&컬러 단어)

A, E 동일 – A 뒤에 슬래시(/) 붙어있는거 주의
C, F 동일
D, G 동일 – /tmp 하위에 생성하지 말 것

  1. Python 2.7.x 소스를 다운 받아 압축을 해제한다.
  2. cd Python-2.7.x
  3. ./configure
  4. make && make altinstall
  5. python -V # 아직 2.6.x 뜰 것이다.
  6. mv /usr/bin/python /usr/bin/python_backup
  7. cp /usr/local/bin/python2.7 /usr/bin/python
  8. python -V # 이제 2.7 뜸

근데 문제는 yum 이 2.6에 맞춰져있어서 yum 도 건드려줘야 한다.. 이거 때문에 한참 헤맴..

  1. cp /usr/bin/yum /usr/bin/yum_backup
  2. nano ‘which yum’
  3. #!/usr/bin/python 에서 python 을 python_backup 으로 수정 (위 6번 참고)
  4. yum update 확인

일반적으로 서버의 SSH 접속하기 위해 사용자의 아이디와 비밀번호가 필요하다. 이 말은 즉슨 대충 ID만 알아도 Brute Force Attack 할 수 있다는 얘기가 된다. 서버 관리자 입장에서 생각해보면 여간 짜증나는 일이 아니다. 로그인이 안 된다 할지라도 해킹이 시도되는 동안 소모되는 서버 자원은 어쩔 것인가 ㄷㄷㄷㄷ

이를 방지하기 위해 Fail2Ban 과 같은 Python 기반의 스크립트를 이용하여 지정된 횟수 이상으로 로그인을 실패하면 해킹으로 판단하여 일정시간 접근을 차단시키는 방법도 있다. 하지만 이 방법도 지정된 횟수 이내로.. 예를 들면 로또보다 더한 확률로 1~2번 시도만에 로그인이 성공하면 낭패다. (그러니 유저들을 추가할 땐 비밀번호 정책을 빡세게 합시다 ㄷㄷㄷ)

하지만 OTP를 이용하게 되면 약간은 안심이 될 것 같다. 1분마다 6자리의 숫자가 갱신이 되고 그 이전의 숫자조합은 무용지물이 되어버리니 이 얼마나 짱짱한가. 몇가지 OTP 서비스들이 있긴 하지만 Google OTP(정확히 말하면 Google Authenticator) 를 이용하기로 했다. 별 거 없다. 왜냐면 구글신이니까..

말머리에서 언급한 바와 같이 SSH 접속하기 위해선 사용자의 아이디와 비밀번호가 필요하지만 Google Authenticator 를 이용하면 그 중간에 OTP 번호를 입력하는 절차가 추가된다.

예를 들면 다음과 같다.

일반적인 SSH 로그인

일반적인 SSH 로그인

 

OTP 이용한 SSH 로그인

OTP 이용한 SSH 로그인

 

세팅하는 방법을 순서대로 나열하겠다. 기존의 타 블로그들에서 작성된 대부분의 Google Authenticator 세팅 방법들은 크게 문제가 없지만 중요한 부분이 빠져있다. 이 글에선 빠지지 않고 모두 작성해놨으니 그대로 차근차근 실행만 한다면 될 것이다.

  • CentOS 6.8 & 7 기준으로 작성
  • root (최고관리자) 권한 기준으로 작성
  • 작업시작 전 모든 패키지들을 업데이트 (하지 않아도 크게 상관 없음)
  1. .ssh 디렉토리 권한 변경
    * 필수 작업 – 0700으로 맞추지 않으면 로그인이 제대로 작동하지 않는다.
  2. Google OTP 패키지 설치에 필요한 필수 패키지 설치
  3. Git 으로 Google OTP 다운로드
  4. 소스 컴파일 작업
  5. Google Authenticator 설정
  6. y 누르고 엔터 (일반적으로 2번)
  7. 스마트 폰에 Google Authenticator 앱 설치 후, 모니터에 나타나는 QR코드 촬영 또는 Secret Key 작성으로 OTP 추가
  8. PAM 설정

    8.1. %PAM-1.0 바로 밑에 다음 내용 추가 (한 줄임)

    8.2 저장
  9. SSH 설정

    9.1. 다음 설정사항들을 모두 yes로 변경

    9.2 저장
  10. SSH 재시작
  11. (옵션) 모든 유저에게 OTP 부여가 완료되었고 더이상 유저 추가 계획이 없을 경우 8.1. 에서 추가된 내용 중 nullok 를 삭제한다.
    nullok 삭제시 해당 서버 SSH에 접근하는 모두가 OTP를 거쳐야 함.

 

위 과정을 모두 마치면 Google Authenticator 를 거쳐 로그인을 할 수 있다. 이렇게 되면 어제 작성했던 Root 비밀번호 자동 변경 쉘 스크립트에서 비밀번호를 좀 더 약하게 생성시켜도 괜찮을 듯 하다.

약 2주간 적용하고 싶은 마음에 수많은 삽질을 했고 결국 성공했다. 별 거 아닌데 뿌듯하다.