PMA(PhpMyAdmin)를 설치하라!

회사의 테스트 서버가 위치하고 있는 사무실을 비워주게 되면서 그간 사용하던 테스트 서버를 철수하게 되었다. 개발자들이 개발에 사용하던 테스트 DB와 기타등등 필요한 것들을 다른 서버에 옮겨서 설치를 해주어야 했는데 마땅히 생각나는 서버가 없었다. 현재 사이트를 운용하는데 사용되는 웹서버들도 이래저래 필요에 의해 다른 용도로 활용하다보니 더이상 뺄 만한 여력도 없고...

그래서 처음 생각한 것이 PC한대에 리눅스를 설치하고 서버로 활용하는 것이었는데 리눅스 설치까지 완료했으나 패키지를 다운받을 수 있는 mirror사이트에 접속이 안되면서 슬슬 일이 꼬이기 시작했다. 인터넷은 연결되어 있었고 같은 repo정보를 가지고 있는 서버들은 괜찮은데 유독 이놈만 mirror 어쩌고 저쩌고 하면서 당췌 패키지를 다운 받지 못한다. 개발과 디버깅등등의 작업이 밀려있었기 때문에 빨리 문제를 해결하거나 다른 방법을 찾아야했는데 현재 사용중이지 않은 웹서버 한대가 번뜩 떠올랐다. 사양이 다른 서버들보다 안좋아서 웹서버로 활용하기에는 무리가 있어서 그냥 내버려둔 서버였는데 그게 마침 생각난 것이다.

"테스트서버는 그전에 입고되었던 서버로 하겠습니다."

라고 보고를 드린다음 테스트 서버에서 사용하던 PMA관련 설정값들(PMA설정, nginx.conf, site-enabled에 있던 PMA 설정, php.ini)을 그대로 가지고 와서 적용했으나 PMA가 되지 않는다-_-...후...한번에 될리가 없지.

본격적으로 자리를 잡고 원인을 추적해가기 시작하려 했으나 반나절동안 이삿짐을 옮기고 퇴근시간이 훌쩍 넘은지라 그냥 퇴근-_-...주말에는 PMA를 쓸 일이 없다는 사장님의 말에 그냥 퇴근해버렸다. 찝찝한 마음을 가지고 말이다.

주말내내 어떤게 문제일까 생각하기도 하고 서버에 접속해보기도 하면서 시간을 보냈다. 하지만, 너무 문제해결에 빠지지 않게 내 자신을 어느정도 컨트롤 했다. 경험상, 너무 문제에 깊게 빠져있다보면 주변에서 찾을 수 있는 단서를 놓치는 경우가 많기 때문이다. 그래서 문제 해결의 주체이기는 하면서도 관조적으로 바라 볼 수 있는 그런 포지션을 유지하기 위해 너무 여기에 매달린다 싶으면 TV를 보거나 딸아이랑 놀아주는 방법으로 적당히 거리감을 두었다. 그리고 

'이 문제는 월요일에 출근해서 오후3~4시까지는 완료하고 퇴근할 때 쯤에는 홀가분한 마음이 될 것이다.'

라는 마인드 컨트롤을 병행했다. 예전에 책에서 읽은 건데 이런 마인드 컨트롤은 문제 해결에 아주 큰 도움을 준다고 한다.

월요일 아침.

출근하자마자 노트북을 연결하고 서버에 접속했다. 확실히 지난 금요일보다 눈에 보이는게 많았고 그것들을 단서로하여 문제 해결방법을 찾아가기 시작했다.

1. pma에 접속이 되지 않는다. -> 웹서버엔진을 먼저 살펴보자.

 - 가장 먼저 한 일이다. 502 bad gateway 에러메시지가 계속 나오는 것을 보고 웹서버 엔진인 nginx를 먼저 의심했다. conf파일에서 뭔가 실수 한 것이 없는지, site-enabled에 등록한 pma설정 파일에 문제가 없는지 살펴보았다.

2. 문제의 원인 발견

 - public_html 폴더에 index.html 이라는 파일을 만들어 접속해 보았다. 정상적으로 접속이 된다. 그다음 index.php라는 파일을 만들어서 접속해 보았다. 어라? 접속이 되지 않는다. php와 관련하여 문제가 발생한 것이라는 단서를 발견 했다.

3. php와 관련된 변수 체크

 - 일단 suhosin을 삭제했다. 예전에도 이녀석이 pma에 접근하는 것을 차단한 적이 있다. 그리고 nginx와 관련된 php-fpm의 설정을 살펴보았다.

4. 문제의 해결, 그러나 또다른 문제의 시작

 - 기존 테스트서버에서 정상적으로 작동하는 설정파일들을 현재 작업중인 서버에 적용하였는데 여기에서 간과한 점이 하나 있었다.  그건 바로 내부 아이피(Virtual IP)의 존재. 기존 서버는 이 내부IP를 fastcgi pass로 설정해서 사용했었는데 테스트서버는 그냥 localhost를 fastcgi pass로 설정해놓았던 것이다. 이 설정의 차이 때문에 nginx는 php를 활용하기 위한 php-fpm을 정상적으로 가동시키지 못했고 그 때문에 php기반의 pma가 정상작동을 하지 않았던 것이다. fastcgi pass를 변경한 후 테스트 서버의 pma가 정상적으로 작동이 되었다. 하지만 여전히 실DB서버들로의 pma접속은 되지 않았다. 오류 메세지는 502 bad gateway에서 504 time out으로 바뀌었다.

5. 오류메세지를 바탕으로 원인 추적.

 - 504 time out은 보통 접속 직전까지 갔으나 최종단계에서 무언가가 접속을 막고 있는 것이라고 생각한 후 서버에서 접속을 막을만한 설정들이 있는지 생각해보았다. 그때 문득 떠오른 방화벽!! 우리 서버들은 iptables를 쉽게 활용할 수 있게끔 하는 apf를 방화벽으로 쓰고 있는데 이 apf의 설정을 찾아 보기로 했다.

OK!!찾았다. apf의 설정값을 보니 새롭게 테스트 서버로 활용되는 서버의 접근이 허용되지 않고 있었다.

으흐흐흐흐흐흐흐흐흐흐!!안풀리던 문제를 해결했을 때의 쾌감이란!!allow host에 새로운 테스트서버의 IP를 넣어주고  apf를 재시작 했다. 그 결과 실DB서버로의 pma접속이 잘 된다 ㅠ

월요일 오후 3시경 접속 테스트 및 외부접속 mysql 유저 생성등을 끝으로 작업을 마무리 지었다. 마인드 컨트롤을 했던 것처럼 문제가 제떄 해결된 것이다. 후아~

물론 퇴근도 기분좋게 하면 좋겠지만 새로운 개발 프로젝트의 구상때문에 개발자와 끙끙 앓다가 진이 다 빠진채로 퇴근한 건 함정 ㅠ