웹서버 다운시 알려주는 UptimeRobot

낮에 블로그에 접속해보니 연결이 되지 않았다. ssh 접속해서 상태를 보니 아파치만 다운 상태.

$ sudo /opt/bitnami/ctlscript.sh status
php-fpm already running
apache not running
mysql already running

얼른 실행시켜놓고 시스템 로그와 에러 로그를 뒤적거려보니 못찾은건지 없는건지, 워드프레스에 스패머들이 코멘트 자동으로 쏟아부으려다가 DB쪽에서 뱉어낸 에러메세지만 수두룩하다. 정확한 원인 파악까지는 능력부족. 그렇다 하더라도 다운되는 시점을 알면 얼른 다시 띄울 수 있으니 데몬 죽었을 때 알림을 주는 방법을 찾아보았다. 서버쪽에서 도는 모니터링 데몬이든 스크립트도 있을 것이고 AWS니까 웹서비스 모니터링 프로그램도 제공하지 않을까 싶다. 제일 쉬운 방법으로 찾은 것이 외부에서 한번씩 웹페이지를 열어서 http 상태코드를 체크해서 문제시 알려주는 서비스를 이용하는 것.

5분간격 체크까지 무료로 제공하고 있는 UptimeRobot를 이용해보기로 했다.

63.143.42.252 – – [01/Oct/2019:03:55:43 +0000] “HEAD / HTTP/1.1” 302 –
63.143.42.252 – – [01/Oct/2019:03:55:43 +0000] “HEAD / HTTP/1.1” 200 –

IP목록에서 찾아 대조해보니 정해진 체크 시간 간격마다 잘 다녀가고 있다.

n개월마다 비밀번호를 강제로 변경하게 하는 사이트들

사이트에 로그인하다보면 6개월마다 비밀번호를 변경하라는 안내문구가 뜨는 경우가 있다. 다음에 변경하기 버튼을 눌러 이번에 변경하지 않도록 해줄 수 있는 사이트면 다행인데 강제로 변경하게 하는 사이트들이 문제다. 새로 비밀번호를 지정하지 않으면 서비스를 이용할 수 없게한다. 대체 왜 이걸 강제하는 것일까. 자기네 사이트 회원정보가 털렸고 비밀번호는 암호화하지 않고 보관하고 있던 것일까? 비밀번호 관리 프로그램을 쓰는 사람들은 다 그렇겠지만 모든 사이트와 모든 앱에서 같은 비밀번호를 쓰는 경우란 없으며 비밀번호 또한 h94oFqb{MmismwUk 라든가 NCErhC9fCzxjZ9&Q 같은 무작위 영문대소문자,특수문자,숫자를 혼합하여 사용한다. 사전 데이터로 대입할 수 없으며 유추가 불가능한 비밀번호다. 이런 사이트들의 특징은 기존 사용하던 비밀번호와 동일하게 재지정 할 수 없게할 뿐더러 심지어 기존 비밀번호와 일정 자리수이상 겹쳐도 안되게 해놓았다. 결국 완전히 다른 문자열로 지정하게 하는 것인데, 이걸 사람이 기억해둘 도리가 없다. 결국 어딘가에 적어두거나 기억하기 쉬운 비밀번호로 지정하는, 역효과를 낳게 할 수 있다.

어제 겪은 모 공공기관 사이트의 비밀번호 변경 캠페인은 사용자를 매우 짜증나게 만들었는데.

일단 로그인 했더니 비밀번호 변경 안내문이 나왔다. 권장이라고 하지만 강제였다. 확인을 누르면 비밀번호 변경화면으로 가는 것이 아니라 생뚱맞게 아이디, 비밀번호 변경 화면으로 이동한다. 수동으로 개인정보변경 메뉴로 이동하였다.

비밀번호는 영문+숫자+특수문자=9자리이상 조합이어야하고 특수문자는 3자리 이상이어야 한단다.

규칙에 맞게 비밀번호를 입력하고보니 입력 규칙이 틀렸단다.

아니, 모든 특수문자가 가능한것이 아니라면 사용이 허용된 특수문자를 미리 알려줘야지 사용자가 무슨 수로 허용되는 특수문자와 허용되지 않는 특수문자를 알수 있단 말인가. 숫자 1~5까지와 함께 있는 특수문자 5개만 입력가능한것이면 6~0까지는 물론 슬래쉬, 물음표, 꺽쇠괄호, 네모괄호, 파이프, 쉼표 등 더 많은 특수문자는 불가능하단 이야기인데 그렇다면 규칙에 맞는 특수문자보다 그렇지 않은 특수문자가 훨씬 많다. 즉 웬만하면 틀린다는 이야기다. 심지어 입력폼에서는 9자 이상이라더니 경고창에서는 8~20자 이상으로 문자열의 최소,최대길이가 변했다. 특수문자도 3개에서 2개 이상으로 바뀌었다.

더 웃긴 것은 비밀번호 문자열에 사용할 수 있는 특수문자를 %, $, #, @, ! 이렇게 다섯가지라며 보여줬는데 실제 변경때는 다른 &를 넣어도 변경이 가능했다.ㅎㅎ IT업체라면 QA부서든 기획부서든 검증을 했겠지만 공공기관이라 그런가 누구도 체크하는 사람은 없나보다. 이게 끝이 아니다. 이 코메디는 우여곡절끝에 비빌번호를 변경하고 저장하고 로그아웃 한 뒤 다시 로그인 하면 그 절정을 보여준다.

빙금 비밀번호를 변경했지만 6개월이 넘었다며 비번 변경창를 띄운다. 다시 시작이다.

해당 기관 고객센터에 전화하여 문제점을 이야기하고 홈페이지 개발 담당자에게 전달해달라고 하였다. 약 20분 뒤에 전화가 왔는데, 오류가 있었고 수정되었으니 다시 로그인하면 변경창이 나오지 않을 것이라 하였다. 확인해보니 제대로 고쳐놓았다. 특수문자 규칙에 대한 이야기까지는 하지 않았다. 알면 고쳤을테고 알아도 못고쳤다면 그럴 여유나 역량이 없었을테고 몰랐을 지언정 그걸 고객이 전화통 붙잡고 알려주는건 피곤한 일이고 알려줬다 하더라도 고치는 건 또 다른 문제고.

매직트랙패드2 페어링이 끊겼을 때 다시 붙이기

맥북프로를 뚜껑 닫고 쓰는 클램쉘 모드로 두고 매직키보드와 매직트랙패드2를 사용하는 중인데 가끔 트랙패드의 연결이 끊기는 현상이 생긴다. 잠자기에서 깨어날때나 맥북에서 케이블을 다 분리해서 다른 장소에서 쓰다가 다시 연결했을 때 일어나지 않았나 싶다. 5월 중순 구입 이후 2번째다. 키보드는 끊기는 일이 없었다.

이때 해본 시도는 아래와 같았는데 이 방법들은 성공하지 못했다.

  • 트랙패드 뒷편의 전원 스위치를 껐다 켜기
  • 시스템환경설정의 블루투스를 껐다 켜기

맥북의 전원을 껐다키면 정상적으로 다시 연결되긴하나 작업했던 환경으로 다시 돌아가기 번거로운 일이다. 리부팅하지 않고 블루투스 장치에서 제거했다가 페어링하면 복구가 가능하다. 키보드만으로 작업하기엔 익숙하지 않은 일이긴하다.

  1. Spotlight에서 bluetooth 라고 쳐서 시스템환경설정 -> bluetooth 를 실행한다.
  2. 연결되지 않음 이라고 나온 트랙패드 항목을 탭키와 화살표 키로 이동하여 찾아간 후 스페이스바를 누른다.
  3. 장치를 제거할것이냐는 창이 나오면 “제거”
  4. 트랙패드 뒷편 전원 스위치를 껐다가 켠다.
  5. 블루투스 장치에 새로 나타단 트랙패드를 선택하고 스페이스 바를 누르면 연결된다.

티스토리에서 AWS 프리티어로 이전한 이유, 경과

이 블로그말고 얼마전 티스토리에 블로그를 하나 더 만들었다. 도메인 연결하고 하나둘씩 글을 채워가면서 10여개 글을 쓰다보니 아쉬운 점들이 보였다. 검색엔진에서 잘 가져갈 수 있도록 문서 구조를 XML형식으로 만들어서 구글에 등록해야 하는데 티스토리에서는 이 sitemap을 제공하지 않았다. 방법을 찾아보니 이러했다.

  1. 사이트맵을 만들어주는 외부 서비스를 이용한다. 이 서비스는 사이트 주소를 넣으면 분석해서 sitemap.xml 파일을 다운로드 받을 수 있게 해준다.
  2. 티스토리에서 비공개 글을 작성한 후 첨부파일로 이 xml 파일을 올리고 주소를 딴다. 이렇게 하기 위해서는 티스토리의 구버젼 편집기로 돌아가야 한다.
  3. 구글 웹마스터 도구에서 이 xml 파일을 업로드 한다.
  4. 티스토리에 새 글이 작성되면 1번부터 이 과정을 반복한다.

글 하나 쓸 때마다 이 기묘하고 번거로운 작업을 해야한다는걸 감당할 수 없다는 것이 첫번째 이유.

두번째는 백업을 제공하지 않는것이다. 찾아보니 예전에는 제공했던 것 같은데 2013년에 복원기능이 없어지고 2016년에 백업기능도 종료되었다. 곰곰히 생각해보니 내가 글을 쓰는 것은 먼 미래를 봤을 때 계속 매몰시키고 있는 것은 아닌가 싶었다. 공교롭게도 어제 낮에 우연히 싸 뭐시기 월드에 들어가봤더니 그때도 그랬지만 백업은 해주지 않되, 유료로 사진을 PDF로 저장해주는 서비스를 하고 있었다. 뭐라 할 말이 없다. 덕분에 데이타를 서비스에 쌓으면 매몰일뿐 아니라 서비스 제공자의 장사를 위한 인질까지 되는것이 아닌가 싶다. (PDF고 책이고 됐고, 내가 올린 사진 폴더로 묶어 zip으로 내려보내주시라고요.)

워드프레스의 할아버지격인 b2부터 워드프레스를 써오다보니 한두번 클릭으로 되던 기능이 매우 어렵게 바뀌거나 또는 불가능해진 서비스에 계속 시간과 정성을 들이는 것이 견디기 어려웠다. 10여개까지의 글을 마지막으로 더이상 업데이트를 중단하고 새 블로그 플랫폼을 찾기 시작했다.

이리보아도 저리보아도 결론은 워드프레스인데, 저렴이 호스팅으로 갈까 하다가 이미 AWS 프리티어에 이 워드프레스를 돌리고 있으므로 여기에 추가적으로 virtual host를 적용해서 돌리고자 하였다. 워드프레스 하나 더 돌리자고 인스턴스를 새로 시작하는건 말도 안되는 낭비다. 마치 사람 탈려고 승용차 한대 구입했는데 책가방 하나 들고 갈려고 트럭 한대 더 사는 격이니까 말이다. 원래 차에는 사람수, 짐의 무게와 부피만 초과하지 않는다면 서너명 더 태울 수도 있고 배낭도 싣고 박스도 싣는다. 인스턴스를 더 생성하면 비용도 비용이고 유지보수까지 생각해야 한다. 버츄얼 호스트는 웹호스팅 서비스에서 한 서버에 수백개씩 돌리고 있는 것이라 기술적으로는 어려운게 아니다. 그렇다고 쉽단 이야기는 아니지만. 다만 AWS와 bitnami에 초심자인다데가 누구네 서버에 더부살이하는 입장이면 관리자한테 물어라도 볼텐데 AWS는 내가 루트고 나혼자 쓰고 있으니 물어볼 이도 마땅치 않았다. 채팅으로 H선배가 열심히 도왔으나 첫날은 실패하고 말았다.

수일간 틈틈이 깨작거려봤지만 번번히 실패. 어제 밤에 단단히 마음먹고 다시 도전했다. 이번에 안되면 웹호스팅으로 찌그러지던가, 주변에 아쉬운 소리 할 사람을 좀 찾아봐야겠다…라는 각오로.

같은 작업을 하면서 다른 결과가 나올 수는 없는 법이어서 계속 불안하게 작업하다가, 2번째 블로그가 설치될 디렉토리를 1번째 html 홈디렉토리의 서브디렉토리로 변경해보는 시도가 적중. 403에러가 나던 부분을 잡고 차근차근 설정해나갈 수 있었다. 아직 남은 과제들과 추가로 설정할 것들이 남았지만 두 사이트 모두 큰 탈없이 (=잔잔한 오류와 함께) 돌게 되었다.

설치 후 티스토리에서 10개의 글을 수작업으로 옮겨왔고 sitemap.xml 을 등록했다. 글을 쓰면 글만 나오고 사진도 추가하면 사진도 나오는 테마로 변경했다. 티스토리에서 쓰던 테마는 사진을 넣지 않으면 글씨가 채워지는게 아니라 회색 네모칸이 그 자리를 차지하는 테마였다. 따라서 텍스트만으로 이루어진 글이라도 목록에서 회색 상자 대신 보여질 배너같은 이미지를 –이게 뭐하는 짓인가 하는 혼잣말을 하며– 하나씩 만들어 넣어줬는데 이젠 그 일에서도 해방되었다.

페이지 로딩 속도도 상당히 개선되었다.

AWS프리티어에 워드프레스 2개 돌리기

AWS 프리티어에 워드프레스를 2개 돌리려던 시도를 실패한 후 몇번 다시 해보려다가 어제 다시 시도해서 성공했다. 지난번 실패의 이유는 두번째 워드프레스(든 버츄얼호스트든) 홈 디렉토리를 기존 워드프레스 홈 디렉토리의 하부 디렉토리에 설정하지 않아서이다. 즉 2nd 워드프레스 폴더를 /opt/bitnami/apps/wordpress/2nd 로 지정하려고 했었는데 기존 /opt/bitnami/apps/wordpress/htdocs 아래인 /opt/bitnami/apps/wordpress/htdocs/2nd 로 사용해야 했다. 처음 시도와 다르게 이번에는 별도의 DB생성없이 기존 DB를 그대로 이용하여 설치하였다.

  1. https 리다이렉트를 위해 설정한 부분 주석처리 /opt/bitnami/apache2/conf/bitnami/bitnami.conf
    #RewriteEngine On
    #RewriteCond %{HTTPS} !=on
    #RewriteCond %{HTTP_HOST} !^(localhost|127.0.0.1)
    #RewriteRule ^/(.*) https://example.com/$1 [R,L]
  2. virtual host 설정 (Help setting up apache2 virtual host config for bitnami wordpress for two sites (Not multisite) 참조)
  3. /opt/bitnami/apps/wordpress/conf/httpd-vhost.conf
    <VirtualHost *:80>
    ServerName hof.pe.kr
    ServerAlias www.hof.pe.kr
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
    </VirtualHost>
    <VirtualHost *:80>
    ServerName 2번째도메인.kr
    ServerAlias www.2번째도메인.kr
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs/2nd"
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
    </VirtualHost>

  4. /opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf 에서 아래 행 추가 (또는 주석 제거)
  5. Include "/opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf"

  6. 2번째 도메인의 DNS 설정에서 기본도메인과 WWW 도메인을 AWS서버 IP를 향하도록 지정
  7. /opt/bitnami/apps/wordpress/htdocs 아래에 2nd 폴더 생성
    /opt/bitnami/apps/wordpress/htdocs/2nd

  8. 워드프레스 최신버젼을 다운받아서 이 폴더에 올림.
  9. 원래 워드프레스 홈 디렉토리에 있던 wp-config.php 파일을 2nd 디렉토리로 복사 ( 워드프레스 설정파일 값 세팅하기 ( WordPress wp-config.php) 참조)
  10. DB의 prefix 를 원래 워드프래스와 다르게 지정
  11. $table_prefix = 'wp2_';

  12. https://api.wordpress.org/secret-key/1.1/salt/ 에서 생성된 키를 wp-config.php 에서 해당 부분 찾아 대체.
  13. 아파치 재시동
  14. sudo /opt/bitnami/ctlscript.sh restart apache

  15. 2nd 워드프레스 디렉토리를 웹브라우저로 접근하여 워드프레스 설치
  16. 여기부터는 Generate And Install A Let’s Encrypt SSL Certificate For A Bitnami Application 참조

  17. 워드프레스 기본 설치 페이지가 나온 것을 확인 후 SSL 키 생성을 위해 아파치 중지
  18. sudo /opt/bitnami/ctlscript.sh stop

  19. 키 생성
  20. sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run

  21. /opt/bitnami/letsencrypt/certificate 에 두번째 도메인의 .crt와 .key 등이 생성되었는지 확인
  22. virtual host 설정에서 https 설정하도록 함. 아래 설정한 디렉토리에 맞게 키 파일 이동
  23. 원래 있던 *80 설정 아래에 각각 아래 내용을 도메인에 맞도록 추가

    <VirtualHost *:443>
    ServerName hof.pe.kr
    ServerAlias www.hof.pe.kr
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
    SSLEngine on
    SSLCertificateFile "/opt/bitnami/apps/wordpress/conf/certs/hof.pe.kr.crt"
    SSLCertificateKeyFile "/opt/bitnami/apps/wordpress/conf/certs/hof.pe.kr.key"
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
    </VirtualHost>

    2번째 도메인용

    <VirtualHost *:443>
    ServerName 2번째도메인
    ServerAlias www.2번째도메인
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs/2nd"
    SSLEngine on
    SSLCertificateFile "/opt/bitnami/apps/wordpress/conf/certs/2번째도메인.crt"
    SSLCertificateKeyFile "/opt/bitnami/apps/wordpress/conf/certs/2번째도메인.key"
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
    </VirtualHost>

  24. 아파치 시작
  25. sudo /opt/bitnami/ctlscript.sh start

남은 과제

  • hof.pe.kr 과 2번째 도메인으로 들어오는 http 접속을 https 로 강제 리다이렉션이 잘 안됨. 도메인 하나일때와 버츄얼 호스팅일때 설정 방법이 다른지 확인. –> 해결. /opt/bitnami/apache2/conf/bitnami/bitnami.conf 에 있던 리다이렉션 설정을 /opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf 에서 지정 (via Force HTTPS Redirection With Apache )
  • SSL 인증서를 임의로 옮긴 후 버츄얼호스트에서 경로를 지정해주긴 했는데 나중에 수동이든 자동이든 갱신하고나서 또 매번 이동해줘야하는지 아니면 갱신 스크립트가 지정하는 폴더로 이동시키고 그 위치를 버츄얼 호스트에서 지정해줘야 할지 확인해야 함.

기타 설정

  • pretty permalink를 위해 http://recreationcoach.kr/&post_id%/로 지정했고 아래 내용을 /opt/bitnami/apps/wordpress/conf/htaccess.conf 에 등록했다. (그런데 hof.pe.kr 은 이 방식 주소가 예전부터 써오던것을 aws로 이사온 뒤로도 자연스럽게 되니 갸우뚱)
  • <Directory "/opt/bitnami/apps/wordpress/htdocs/2nd">
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    </Directory>