FreeBSD 7.0부터는 오픈솔라리스의 ZFS(Zettabyte File System)을 사용할 수 있다. ZFS는 파일시스템과 볼륨관리자가 통합되어 있는 장점을 최대한 살려 한두개의 과정만으로 파일시스템을 바로 사용할 수 있다. 또한 마치 찰흙을 붙였다 떼었다 하는 듯한 느낌으로 볼륨 관리의 유연성을 맛 볼 수 있다. 그러나 FreeBSD에서는 아직 실험적으로 동작중이며, IO 성능 또한 만족스럽지 못하다. 결국 FreeBSD에서 만큼은 미래를..
성능은 따로 측정한 적이 없습니다.
다만, 우분투에서 사용할 경우 상당한 불안정성을 보입니다.
ls, cd 등의 명령을 사용할 때 파일시스템 전체가 멈춰 버리는 문제가 있습니다. 그것도 심각할 정도로 자주 멈춥니다. aacraid 드라이버와 충돌하는 것 같아 보이는데요, 증상이 나타나는 패턴이 일정하지 않아 왜 그런지는 모르겠습니다.(로그조차 남지 않아요) 다만 삼바를 통해서 사용하는 경우에는 멈춤 현상이 없습니다.
파일시스템이 한 번 멈춰 버리면 재부팅하는 것 외에는 해결 방법이 없습니다. 아무리 프로세스를 죽이고 다시 올려도 마운트를 할 수가 없습니다.
결론은 아직 우분투에서 zfs는 시기상조라는 겁니다.
금요일까지 멀쩡했던 것 같은데, 오늘 웹 서버에 접속이 안 되더군요. SSH는 다행히 살아있어서 웹서버를 재가동시켰습니다. 서버에 순간적인 부하가 걸렸던 것 같은데, 그것 때문에 아파치가 죽은건지 아니면 아파치가 갑자기 이상 동작을 해서 부하가 걸린 건지는 알 수 없습니다. 해킹 시도 같진 않고요, 그냥 저번에 설치했던 프로그램과 살짝 충돌이 있었던 것 같습니다. 이거이거, 웹서버는 반쯤 죽어서 골골대고 있는데 저는 잠이나 퍼질러 자고 있었다니... 이곳 미국에서 사용할 적당한 모니터링 도구가 없었다는 게 핑계가 될 지는 모르겠지만 하여튼 서버관리자로서 부끄럽군요. 매일 제가 서버를 모니터링하긴 하는데, 하필 모니터링을 안 하는 주말에 이런 일이 생기다니 참... 어쨌든 복구했습니다.
IDC에서 제공하는 서비스로 지속적으로 접속이 가능한지 여부를 체크하다가 접속 오류가 발생하면 문자메시지로 통보해주는 시스템이 있었는데 몇 달 무료로 제공하다가 어마어마(당시 제가 느끼기에는;;한 금액의 유료 서비스로 바뀌었더근요. (-_-)
IDC말고 유료ASP 업체가 없을라나요. 꽤 유용할 듯 싶은데.
무료문자 서비스를 훔쳐서(?) 사용하는 방법이 있습니다.
저는 그 방법을 얼마 전까지 사용했습니다.(지금은 미쿡에...)
메일 서비스 회사 중에서는 메일 도착 알림을 문자메시지로 보내 주는 서비스가 있습니다. 그 중 파란메일 같은 데서는 특정 편지함으로 오는 메일에 대해서만 문자메시지로 전송해 주게 돼 있는데요, 이 기능을 사용했습니다.
먼저, 서버에 MTA를 설치합니다. 메일 서버를 설치하는 게 아닙니다. 리눅스라면 그냥 exim4같은 것만 깔아도 되고, 윈도우라면... 커맨드 프롬프트 상에서 이메일을 쓰는 프로그램을 구해 보세요. 하나쯤 있으리라 생각됩니다만, 없으면 뭐... cygwin깔면 되죠 ㅎㅎㅎ
그 다음, 무한반복 쉘스크립트 또는 cron job을 등록합니다. cron job을 추천합니다. 이 cron job은 특정 서버의 특정 서비스가 가능한지를 체크하는 간단한 쉘스크립트로 되어 있습니다. wget으로 특정 웹사이트의 문서를 다운로드하고 그것의 성공 여부를 검사한다거나... 방법은 많습니다.
실패하면, 미리 정의된 이메일 주소로 메일을 발송합니다.
메일이 발송되면, 이제부터는 메일 서비스 회사의 일이 됩니다. 메일 서비스 회사에서는 고객의 필터 규칙에 따라 우리의 프로그램이 전송한 이메일을 특정 편지함으로 이동시킵니다. 그리고 해당 편지함의 문자 전송 서비스를 가동시켜서 최종적으로는 문자가 옵니다.
구글 gmail에서는 아예 모바일 gmail이 가능한 것 같은데, 이 서비스를 노려보는 것도 괜찮겠네요. gmail에다가 평생 한 번도 안 쓸 메일 계정 하나 트고, 이것에다가 특정 서버에서 오는 메일만 수신하도록 필터 설정해 놓은 다음에 모바일 등록하면 딱이네요.
도움이 되었나요? 이것으로 모자라면 다시 댓글 써 주세요. 리눅스에 한한 솔루션이지만 제가 사용했던 스크립트를 보여드리겠습니다.
음, 오늘은 좀 피곤한 날이었는데, 집에 와서 생각지도 못한 잡일을 처리하게 되고 말았습니다. 제 블로그에 23일에서 24일에 걸쳐 스팸 트랙백 공격이 있었습니다. IP주소는 랜덤으로 보이는데, 66.249.67 대역이 의심스러워 차단했습니다. 스패머들의 blog name을 보니까 특정 단어들이 자주 보이던데(뭐 porn이라거나, hot 이라거나), 지금은 아쉽게 그냥 스팸트랙백을 지운 뒤라서 수집할 수는 없겠고, 다음에 또 공격당하면 이름 기반의 필터를 추가할 생각입니다. 정상적인 사람이라면 외국 블로거라고 할지라도 블로그 제목에 porn이나 gay따위를 넣지는 않겠죠.
티스토리는 알아서 필터링을 추가하는 것 같네요.
서비스형이라 관리되고 있는 블로그가 한 두개가 아닌만큼 즉각적인 대처가 가능한 듯 합니다.
종전에 설치형 블로그였을 때는 플러그인을 사용해도 걸러내기가 여간 까다로운게 아니었는데 지금은 따로 신경쓰지 않아도 별도의 수고가 필요 없습니다.
이런 면에서는 설치형보다 좋네요.
하드디스크를 완전히, 완벽하게 지워야 할 일이 생겼습니다. 하드디스크에서 파일을 삭제한다고 해도 dump 명령을 사용하면 파일을 복구할 수 있다는 사실은 익히 알고 계시죠? 하드디스크 복구업체에서는 바로 이 점을 이용합니다. 그렇다면, 자... 중요한 데이터가 들어 있는 하드디스크가 있습니다. 그런데 더 이상 쓰지 않는 디스크입니다. 근데, 뽀개버리기는 너무 아깝고 다른 용도로 쓰려고 합니다. 어떻게 하면 될까요?
가능한 한 가지 방법은, 포맷을 한 다음에 대용량 CD이미지나 영화 파일을 마구잡이로, 용량이 다 찰 때까지 복사해 넣는 방법이 있습니다. 가장 무식한 방법이기도 하고요. 좀 더 세련된 방법으로 dd 명령을 사용하는 방법이 있습니다.
# dd if=/dev/zero of=/dev/sdk
이게 정석적인 방법이긴 하지만, 좀 불완전하게 지웁니다. 복구 경험이 많고 장비가 좋은 복구업체라면 저 방식으로 지운 하드디스크를 복구할 수 있습니다. 하드디스크의 헤드보다 더 민감한 특수 헤드를 사용해서 플래터의 자기 스핀을 읽어내는 방식으로 복구한다고 하네요.
리눅스에서는 원래 이 용도로 쓰는 프로그램이 아니지만 완전히 하드디스크를 청소해 버리는 유틸리티가 있습니다. 그것이 바로 badblocks 입니다.
원래 badblocks는 하드디스크의 배드 블록을 체크합니다. 보통은 read test만 하는데, 여기에 -w 옵션을 주면 write테스트도 하며, 이 write 테스트 중에 하드디스크의 모든 자료가 삭제됩니다.
0x00 0xff 0x55 0xaa등의 패턴으로 모든 블록의 모든 섹터에 쓰기 테스트를 하기 때문에, 이 테스트가 끝난 뒤에는 하드디스크가 완전히 갈아 엎어지게 됩니다. 이건 자기 스핀을 1로 만들었다가 0으로 만들었다가 하면서 여러 번 뒤집어 엎기 때문에 제아무리 경력이 많은 복구업체라도 복구가 불가능합니다.
경고! 마운트 해제된 하드디스크에 사용할 것 경고! 엔터친 다음에는 돌이킬 수 없으므로 장치명을 두 번 세 번 확인할것!("실행할까요?" 하고 묻지 않는다!)
예제는
# badblocks -w /dev/sdk1 sdk1 파티션에 대하여 badblocks 수행
그리고, iptables가 어느 글에서 stateless 방화벽이라고 하는데, stateful 방화벽이 맞는 것 같습니다. -m state 라는 매칭 모듈이 존재하니까요. OpenBSD 에서 만들어진 pf (Packet Filter)라는 프로그램이 stateful방화벽이라면서 ipfw보다 진보됐다고 하는 글을 봤는데, 이 글에는 또한 iptables보다도 진보됐다고 쓰여 있더군요. 도대체 얼마나 진보됐길래 그러는지 pf 를 써봐야 하겠습니다 ^^; 리눅스의 발전속도는 무척 빠르니, iptables가 pf의 모든 기능을 흡수했을 수도 있고... 아무튼 써봐야겠네요.
뭐, 거창한 것은 아닙니다. 서버를 사설 IP대에 물려놓고 사용하려다가 제 노트북이 방화벽에 걸려서 간단히 찾아본 꼼수입니다. 일종의 DMZ 비슷한 것이죠.
# iptables -A INPUT -m mac --mac-source 00:12:34:56:78:9a -j ACCEPT
이런 식으로 호스트의 MAC주소 기반 필터링을 수행할 수 있습니다. 물론 복잡하게 해서 특정 호스트의 SSH접근을 거부하게 할 수도 있지요.
# iptables -A INPUT -p tcp --dport 22 -m mac --mac-source 01:23:45:67:89:ab -j DROP
이렇게 하면 01:23:45:67:89:ab 라는 MAC주소를 가진 호스트는 SSH접근이 차단됩니다. 단, 이 방화벽 룰이 기존에 있는 iptables -A INPUT -p tcp --dport 22 -j ACCEPT 라는 룰 앞에 있어야 합니다. 아니면 저 룰에 걸려서 통과하겠죠.
-m 에 사용할 수 있는 매칭 모듈에는 참 여러 가지가 있습니다. 위의 mac도 있고, string이라고 패킷의 내용 기반 필터링도 할 수 있고, 패킷의 입력량을 조절할 수 있는 limit, hashlimit, 최근에 필터링된 IP에 대한 검사를 수행하는 recent 모듈 등... 무궁무진합니다.
이전에는 iptables을 어떻게 써야 할 지 몰라 이런 고급 모듈은 사용할 수 없었는데, 이것이 SQL 쿼리문과 닮은 면이 있다는 것을 깨달으면서부터 일은 매우 쉬워졌습니다.
access.log의 내용 중 첫 번째 컬럼을 추출하고, 정렬한 뒤 중복된 숫자를 세어 내림차순 정렬하는 작업을 매 10초마다 수행한다. 라는 뜻입니다. watch에 넣어 줄 명령은 꼭 따옴표로 묶어 주셔야 합니다. 안 그러면 watch의 출력물을 파이프로 전달하려고 해서 아무 것도 출력되지 않습니다. watch 명령 자체가 무한 루프를 돌기 때문입니다. awk의 $1 부분에서 \$1을 사용한 이유는... 쉘스크립트가 $1을 해석하지 않게 하려고 이스케이프한 것입니다. $1에 대한 해석은 awk안에서 되어야지 그 전에 쉘이 해석해 버리면 안되거든요.
watch명령의 자세한 형식은 맨 페이지를 참조하시되, 쓸만한 옵션이라고는 하나뿐입니다. -n 옵션이죠. 얼마만큼의 시간간격(초단위)으로 명령을 실행할지 결정합니다. -d 옵션이라고, 바뀐 부분을 강조하는 옵션이 있긴 한데, 개인적으로 좀 난잡해 보여서 별로 좋아하지는 않습니다.
사실 watch명령은 뒤에 나오는 파라메터의 내용을 반복적으로 실행할 뿐입니다. 이걸 응용해서, 어떤 디렉토리의 내용을 매 분마다 옮길 수 있습니다.
# watch -n60 "mv /home/user1/* /home/user2/"
이런 식으로요. 물론 출력으로는 아무 것도 안 나옵니다. 하지만 매 분마다 /home/user1 디렉토리 아래의 모든 파일을 /home/user2 로 옮길 겁니다. user1에게 ftp를 열어주되, 한 번 업로드한 파일을 다시 다운로드할 수 없게 만들고 싶다거나 할 때 유용하게 쓸 수 있습니다.
간단한 cron 이라고도 할 수 있지요.
단, watch 명령은 명령이 수행되는 시간은 계산에 넣지 않습니다. 만약 수행시간이 10초 걸리는 작업을 watch 명령으로 수행한다면, 매 12초마다 명령을 수행할 겁니다. (10초+watch의 기본 시간 간격) 즉, 정교한 시간 간격으로 어떤 스크립트를 실행하고자 한다면 watch는 그다지 탁월한 선택이 아닙니다.
연구실에 고정되어 있는 서버들은 공용 파일서버(NAS)에 NFS로 연결이 되어 있습니다. 여러분도 아시다시피, NFS는 /etc/exports 라는 파일에 공유 호스트 정보를 적게 되어 있는데요, 이 방식은 호스트 기반 인증이라서 고정되지 않는 서버에는 적용하기 곤란하다는 단점이 있습니다. 제가 예전에 소개해 드렸던 Samba Over SSH 팁에서는 파일 공유를 위해 SSH를 사용합니다. sshfs는 NFS Over SSH라고 할 수 있습니다. 서버측에서는 아무 것도 설치할 필요가 없고요, 클라이언트(리눅스여야 합니다)에서만 sshfs를 설치하면 됩니다.
우분투에서는
# aptitude instal sshfs
로 간단히 설치가 끝납니다. 설정 파일은 /etc/fuse.conf인데, 건드릴 내용은 없습니다. 일반 유저도 마운트할 수 있게 하시려면
여기 FAQ를 보면 그런 경우를 해결하는 방법이 적혀 있습니다. SSH 계정만 있으면 어떤 서버든지 자유롭게 마운트할 수 있다는 것이 큰 매력이고, 모든 트래픽이 암호화되니까 안전하다는 장점도 함께 누릴 수 있습니다. 마운트한 디렉토리를 또 마운트하는 경우에는 여러 문제가 생긴다고 되어 있지만, 그런 경우는 그다지 많지 않으리라 생각합니다.
여기에 설명이 있습니다. 이 두 개의 솔루션이 있으면, 거의 서버실에서 작업하는 것과 별 차이 없는 제어 환경을 갖출 수 있게 되는 겁니다. 서버실에 가게 되는 경우는... 서버 하드웨어의 고장, BIOS로도 못 들어가는 경우, 그리고 서버를 업그레이드할 때 정도? 제가 원하던 거의 이상적인 솔루션이네요. 근데 이걸 내돈으로 살 순 없지... 정말 IDC에 취직해야 할까요?
한 금액의 유료 서비스로 바뀌었더근요. (-_-)
