서버호스팅 O/S 세팅 참 일관성이 없습니다.

그냥 뻘글입니다. 쓸데없이 길고 전문용어로 점철되어 있어서 머리아플 수 있습니다.

1.

대부분의 국내 업체들은 서버호스팅을 신청하면 자동으로 O/S가 설치되는 것이 아니라, 사람이 직접 O/S를 설치하고 이런저런 설정을 만져주곤 합니다. 회사에서 제공하는 모니터링이나 백업 서비스와 연동하는 설정을 추가하기도 하고, 고객의 편의를 위해 이런저런 프로그램들을 기본으로 설치해 주기도 합니다.

그런데 이게 사람이 하는 작업이다보니 일관성이 없습니다. 지난 수년간 100대 이상의 서버 세팅을 대행해 드리다 보니 똑같은 업체에서 신청한 똑같은 모델, 똑같은 O/S라도 그때마다 네트워크 설정 방식, 방화벽 설정, 기본으로 설치된 프로그램 등이 제각각인 경우를 자주 봅니다. 정해진 매뉴얼이나 스크립트가 없고 그때그때 내키는 대로 세팅하거나, 작업자 개인의 취향이 반영된다는 얘기지요. 신청하지도 않은 관리 서비스에 사용되는 스크립트가 여기저기 널브러져 있기도 하고, 새로 받은 서버에 root로 로그인하자마자 휘황찬란하게 반짝이는 프롬프트를 마주할 때도 있습니다. 자동차를 샀는데 딜러가 무단으로 튜닝해서 양카를 만들어 버린 느낌입니다. ㅋㅋㅋ

서버호스팅도 점점 클라우드처럼 아무 때나 신청하고 아무 때나 해지할 수 있는 상품으로 변해 가고 있습니다. 동일 사양, 동일 세팅으로 여러 대를 운영하는 고객도 많을 것입니다. 고객은 새 서버에서 실행할 스크립트를 이미 가지고 있을지도 모릅니다. 그런데 호스팅 업체에서 제공하는 세팅이 그때마다 달라진다면 (불가피한 O/S 보안패치를 제외하면) 고객에게 일관성있는 경험을 제공할 수가 없습니다.

2.

더 심각한 문제는 설치를 요청한 O/S와 버전의 특성을 무시하고 그냥 자기가 익숙한 O/S에 준하여 세팅하거나, 아예 대놓고 다른 O/S에서 사용하는 방식을 갖다붙이는 것입니다. 호스팅 업체는 많지만 전세계적으로 가장 많이 사용하는 "센토스"와 "우분투"의 구조 차이를 제대로 이해하는 작업자는 많지 않은 것이 현실입니다. 센토스를 꽤나 써본 사람이라도 5~6 시절의 습관을 7~8에 그대로 들고 오는 경우가 허다합니다. 다행히 센토스 개발팀이 하위호환성에 꽤 신경써 주기 때문에 그렇게 해도 일단 작동은 합니다. 그러나 인터넷에 나오는 최근 매뉴얼들은 최근 버전에서 권장하는 세팅을 기준으로 되어 있기 때문에, 다른 방식으로 세팅해 놓으면 나중에 뭔가를 수정해야 할 경우 많은 불편이 따르게 됩니다.

센토스에서 모든 프로그램은 rpm 기반의 yum이나 dnf로 패키지 설치하는 것이 원칙입니다. 우분투에서는 deb 기반의 apt를 사용합니다. 일반적으로 많이 사용하는 웹서버용 프로그램이라면 검증된 저장소에서 최신 버전의 rpm이나 deb을 구하는 것이 어렵지 않습니다. 반면, 아파치나 PHP 등 쉽게 구할 수 있는 프로그램들을 굳이 소스컴파일해 놓았거나, 기본값이 아닌 /opt, /usr/local 등의 경로에 설치해 놓았다면 일단 뭔가 크게 잘못된 겁니다. 긴급 보안패치라도 나오면 그걸 적용하는 데 100배는 더 오래 걸리거든요. 게다가 아파치를 이 따위로 설치해 놓는 사람들 중 O/S에서 기본 제공하는 init 시스템(현재는 대부분 systemd를 사용함)과 제대로 연동해 놓는 경우는 단 한 번도 본 적이 없습니다. 뭔가 대단한 장점이 있어서 색다른 방식으로 설치하는 게 아니라, 배운 게 그것뿐이고 더 배울 생각도 없다는 결정적인 증거입니다.

3.

센토스에서 방화벽은 firewalld가 기본입니다. 다른 방화벽도 있지만 레드햇에서 이게 기본이야!! 땅땅!! 해놨으니까 오피셜이 맞습니다. 우분투에서는 특별히 정해놓은 것은 없지만 10여년 전부터 ufw를 밀고 있습니다. 그런데 기본 설치된 방화벽을 굳이 꺼놓고 자기가 고집하는 방식대로 iptables를 설정해 놓는 업체가 무척 많아요. (무시한 것이 아니라 일부러 껐습니다. 흔적이 남아요...) 심지어 기본값을 DROP으로 해놓아서 사용자가 뭔가 바꿔보려고 iptables -F 하는 순간 서버가 먹통이 되기도 합니다. 고객이 이걸 변경할 필요가 있을 거라는 생각 자체를 안 하는 거죠... 그렇다고 firewalld나 ufw에서 지원하지 않는 고급 규칙을 쓰기 위해 어쩔 수 없이 iptables이 의존하는 것도 아닙니다. 그냥 새로운 툴을 배우기 싫은 겁니다.

센토스7에서 서버 시간 동기화는 chronyd가 기본값입니다. 우분투에서는 systemd-timesyncd를 씁니다. (센토스8도 우분투를 많이 닮아가고 있습니다만, 곧 지원 종료 예정이라 논외로 하고...) 이런 기본값을 무시하고 호랑이 담배피던 시절에나 쓰던 rdate 방식으로 당당하게 크론탭 설정을 해놓는 업체도 봤습니다.

센토스7에서는 DNS 캐시 용도로 dnsmasq를 기본 제공합니다. 우분투는 systemd-resolved를 제공합니다. 둘 다 약간씩 설정이 필요하지만, 외부 접속을 막고 로컬 캐시 용도로만 사용한다면 둘 다 안전합니다. 그런데 127.0.0.1:53 포트를 사용하는 데몬이 있다는 이유만으로 (외부 접속이 가능한지 그 잘난 iptables 확인도 안 해보고) 공격을 당할 수 있으니 막으라고 권하는 이상한 업체도 있습니다. 그래 놓고 서버 보안점검이랍시고 돈을 받습니다.

fail2ban을 쓸 줄 아는 업체도 있습니다. 그런데 거기까지입니다. 공식적으로 권장하는 방식대로 local 설정 파일을 만들어서 실행해 놓고 보안점검을 맡기면, 설정이 안 되어 있다면서 기본 제공되는 설정 파일을 임의로 수정하라고 권합니다. 설정 파일을 수정할 줄만 알고, 공식적으로 권장하는 세팅이 어떤 것인지에는 관심이 없어요. 아파치 등 다른 프로그램을 설정할 때도 마찬가지입니다. 어디든지 설정을 입력해 놓기만 하면 그럭저럭 돌아가는 것이 리눅스입니다만, 그래도 무엇을 어디에 넣는다는 관례라는 것이 있고 사실상의 표준이라는 것이 있습니다. 그걸 지켜야 나중에 다른 작업자가 현황을 파악하기 쉽습니다.

메모리 사용량이 적은 것처럼 눈속임하기 위해 일정 시간 간격으로 버퍼와 캐시를 모두 비우는 스크립트를 구석에 숨겨놓은 업체도 봤습니다. 성능에 악영향을 주고 디스크 부하를 높일 뿐, 아무 도움이 되지 않습니다.

리눅스가 워낙 다양해서 한 가지 방법으로 일괄 적용해줄 수밖에 없다고요? 정해진 스크립트를 일괄적으로 따른다면 차라리 그 말을 믿겠습니다. 그런데 매번 사람이 수동으로 세팅하면서 그런 핑계를 댑니다. 일반적인 업체들이 지원하는 O/S 종류가 그다지 많은 것도 아닙니다. 요즘 잘나가는 것은 기껏해야 센토스 7, 우분투가 전부입니다. 하다못해 데비안이라도 지원하면 제가 말을 안 해요...

4. [발암주의]
 

이름난 업체에 서버 관리를 맡겼는데 MySQL이 설치되어 있지 않으니까 멋대로 설치하는 븅X도 봤습니다. 설치되어 있지 않은 것을 왜 굳이 설치해서 관리하려는 건지... 거기까지였다면 그냥 사서고생하는구나 싶었겠지만, 문제는 그 서버에 MariaDB가 설치되어 있었다는 겁니다. 당연히 충돌이 나겠죠? 충돌나니까 MariaDB를 지워버립니다. 이건 정말 븅X이라고밖에 말할 수가 없습니다. 서버 관리 서비스를 결제하자마자 사이트 DB가 날아갔으니까요. ㄷㄷㄷ

5. [추가됨]

내가 쓸 서버와 다른 사람에게 제공할 서버를 구분하지 못하는 것이 이런 문제의 원인 중 하나가 아닐까 합니다. 내 서버라면 내 스타일대로 세팅해서 써도 상관없습니다. 그러나 다른 사람이 사용하고 관리할 서버라면 내 습관과 취향보다 사용자의 편의가 우선입니다. 설치를 요청받은 O/S에서 통용되는 일반적인 관례와 표준을 최대한 지켜서 세팅해 드려야 나중에 누가 관리하더라도 탈이 나지 않을 것입니다. 센토스에서 아파치 설정 파일은 당연히 /etc/httpd 아래에 있어야 하고, 업계 표준인 systemctl 명령으로 컨트롤할 수 있어야 하며, 우분투에서 PHP 최신 버전은 당연히 PPA를 추가한 후 apt로 설치해야 한다는 말입니다.

패키지 설치는 초보자들이나 하는 거라는 인식을 가진 꼰대들이 아직도 남아 있는지 모르겠으나, 현실은 정반대죠. 수많은 서드파티 repo들 중 무엇이 가장 빠르고 안정적인지, 설정을 어디에 넣는 것이 최근 표준인지, 하루가 멀다하고 새로운 보안취약점이 발견되는 상황 속에서 고객이 오랫동안 안전하게 서버를 운용할 수 있으려면 무엇을 어떻게 준비해 놓아야 하는지 아는 것이 실력입니다. 오래 전에 만들어둔 스크립트를 바꾸지도 않고 새로 배울 생각도 없이 복붙하기만 하는 것은 실력이 아닙니다.

기술을 오래 다뤄본 사람이라면 누구나 자기 분야에 대해 고집과 습관이 생기곤 합니다. systemd를 혐오하는 사람도 있고, rpm에 크게 데여본 사람도 있을 것입니다. 좋은 습관과 이유있는 고집은 고객의 자산과 개인정보를 지키는 데 도움이 되기도 합니다. 그러나 대부분의 경우에는 고객 스스로 이 상품을 사용하는 데 어려움이 없도록 살피는 일이 먼저입니다. 포기는 배추를 셀 때나 쓰는 말이고, 원칙은 기계가 아닌 사람을 대함에 있어 지켜야 하는 것입니다.

6.

위의 사건들 모두 국내에서 다섯(열?) 손가락 안에 든다고 하는 메이저급 업체에서 일어난 일입니다.

국내 호스팅업체 서버 세팅 담당자분들 모두 AWS, Linode 같은 글로벌 업체들이 O/S 기본 세팅을 어떻게 해서 고객에게 제공하는지 좀 보고 배우셨으면 좋겠습니다. 물론 서버호스팅은 하드웨어의 차이가 있기 때문에 클라우드처럼 완벽하게 똑같은 세팅을 구현하기는 어렵겠지만, 명확한 매뉴얼 없이 개인의 노하우와 취향에 따라 오락가락하는 것보단 낫잖아요?