Tagged: Linux

Tomcat 7 구조

이 문서는 Tomcat 7  구조 (Architecture) 에 관한 것입니다. 많은 부분을 “Apache Tomcat 7 More about the Cat” 을 참고 했습니다.

Tomcat 7 의 구조는 계층적 구조를 보이며 계층적으로 상속관계에 있습니다. 이를 다이어그램으로 표시하면 다음과 같습니다.

Tomcat Architecture
출처: http://www.ntu.edu.sg/home/ehchua/programming/howto/Tomcat_More.html

이 구조는 Tomcat 의 설정 파일에서도 그대로 나타납니다.

Tomcat 7 디렉토리 구조.

  • bin: Tomcat 의 바이너리 및 스크립트들.
  • conf: 모든 webapp 에 적용되는 글로벌 설정들.
  • lib: 모든 webapp 에서 활용가능한 JAR-file 들. 기본적으로 servlet-api.jar(Servlet), jasper.jar(JSP), jasper-el.jar(EL).
  • logs: 서버 로그 파일들이 있는 디렉토리. Catalina.{yyyy-mm-dd}}.log 는 엔진의 로그이며 localhost.{yyyy-mm-dd}.log 는 호스트 로그.
  • webapps: 디폴트 webapp
  • work: Tomcat 의 java 소스를 컴파일한 class 파일들을 모아놓은 디렉토리.
  • temp: 임시 파일들을  위한 디렉토리.

여기서 중요한 디렉토리는 conf 디렉토리로 Tomcat 의 운영과 webapp 에 영향을 주는 파일들로 총 7개가 있습니다.

  • catalina.policy : 이 파일은 Tomcat 7 에 대한 보안정책권한(Security Policy Permissions)들을 기술해 놓은 것입니다. 이것은 JVM 에 의해서 웹 애플리케이션에 강제적으로 보안정첵권한을 적용 합니다.
  • catalina.properties: 이 파일은 서버가 시작될때에 스캔되어질 필요가 있는 공유할 서버 정의, 공유할 로더, JARs를 가지고 있습니다.
  • server.xml: Tomcat 에서 매우 중요한 파일중 하나인데 서버의 IP 주소, 포트, 버추얼 호스트, 컨텍스트, 패스등과 같은 매우 중요한 정보를 가지고 있습니다.
  • tomcat-users.xml: 이 파일은 인증, 권한부여, 롤기반 정의에 사용될 수 있습니다. 인증을 위한 users/passwords/roles 의 데이터베이스나 컨테이너 관리 보안을 위해 사용되어집니다. 사용자를 추가/삭제나 존재하는 사용자에게 롤을 할당/비할당하기 위해서 이 파일을 편집하면 됩니다.
  • logging.properties: 이름에서 짐작했듯이, Tomcat 인스턴스의 로딩 속성들을 정의할 수 있습니다.
  • web.xml: 이것은 Tomcat 인스턴스에 의해서 로드되어 모든 웹 애플리케이션에 적용되어지는 기본 값들을 정의합니다. 만약 웹 애플리케이션이 자신만의 deployment 디스크립터를 가지고 있다며, 이 컨텐츠는 항상 기본 스크립터에 의해서 정의되어진 설정값을 오버라이드(override) 합니다.
  • context.xml: 이 파일의 내용들은 모든 애플리케이션에 로드됩니다. 세션 퍼시스턴스, Comet 접속 트래킹과 같은 파라메터 설정들을 할 수 있습니다.

CentOS 7 싱글모드 부팅

centos logoCentOS 7 에서 많은 변화가 있지만 그 중에 하나가 싱글 모드(Single Mode) 부팅 입니다.

CentOS 6 에서 싱글모드 부팅을 위해서 부팅 커널 이미지 옵션으로 1 을 입력하면 되었습니다. 하지만 CentOS 7 에서는 그렇게하면 안됩니다.

이 문서는 CentOS 7 싱글모드 부팅 을 어떻게 하는지에 대한 글 입니다.

1. 싱글모드 부팅 (Single Mode Booting)

CentOS 7 에서는 부팅 매니저가 Grub2 로 변경 되었습니다. Grub2 부팅 매니저가 나오면 ‘e’ 를 클릭해서 부팅 커널 이미지를 선택 합니다.

CentOS 7 Grub2
CentOS 7 Grub2

그러면 선택한 커널 이미지에 대한 Grub2 의 각각지 설정값들을 볼수 있으며 커널 이미지와 이에 대한 옵션들을 볼 수 있습니다.

CentOS 7 Grub2 에서 부팅 커널 편집
CentOS 7 Grub2 에서 부팅 커널 편집

화면를 자세히 보시면 파일시스템 마운트 옵션인 ‘ro’를 보실 수 있습니다. 이부분을 다음과 같이 바꿔 줍니다.

CentOS 7 싱글모드 옵션
CentOS 7 싱글모드 옵션

‘ro’ 되어 있던 부분을 ‘rw init=/sysroot/bin/sh’ 로 변경해 줍니다. 그리고 아래부분에 나온대로 Ctrl-x 를 눌러줍니다. 그러면 부팅이 됩니다.

CentOS 7 싱글모드
CentOS 7 싱글모드

가만히 생각해보면 CentOS 7 에서의 싱글모드 부팅은 CentOS 7 의 복구부팅(Rescue Booting) 과 유사합니다.

CentOS 7 싱글모드로 부팅을 하면 /sysroot 디렉토리로 파일시스템을 rw 모드로 마운팅을 해줍니다.

2. Root 패스워드 리셋

보통 싱글모드 부팅을 하는 많은 목적중에 Root 패스워드 리셋이 있습니다. Root 패스워드를 잊어먹어서 Root 패스워드를 바꾸고 싶을때에 싱글모드로 부팅을 하면 인증없이 Root 쉘을 받을 수 있고 그래서 바로 바꿀 수 있습니다.

그런데 CentOS 7 에서 싱글모드 부팅은 복구모드처럼 부팅을 하기 때문에 먼저 파일시스템을 chroot 를 이용해서 변경해 줍니다.

CentOS 7 싱글모드에서 패스워드 변경
CentOS 7 싱글모드에서 패스워드 변경

‘chroot /sysroot’ 로 변경을 하고 패스워드를 변경해 줍니다. ‘touch /.autorelabel’ 는 SELinux 를 신규로 업데이트 해주는 겁니다.

Nginx Gzip Compression 설정

HTTP 에서도 압축전송을 지원 합니다. 이는 Header 에 압축에 대한 정보가 다음과 같이 담깁니다. Nginx Gzip Compression 설정 은 다음과같이 하시면 됩니다.

압축전송을 하게되면 트래픽을 줄일 수 있어, 서버 호스팅을 이용하는 분들에게는 큰 도움이 됩니다. 사용법은 다음과 같습니다.

잘 동작하는지 다음과 같이 테스트를 할 수 있습니다.

“Content-Encoding: gzip” 이 보이면 정상으로 설정이 된 것 입니다.

Atheros AR81 Family GigaEthernet 드라이버 설치.

AMD 칩셋을 달고 나오는 저가형 메인보드의 경우에 Atheros 의 Ethernet 칩셋을 탑재하는 경우가 있습니다. 문제는 Atheros Ethernet 드라이버가 윈도우용은 제공하는데 리눅스용은 제공을 않하더군요.

ASRock 960GM-VGS3 FX Mainboard
ASRock 960GM-VGS3 FX Mainboard

인터넷을 검색해보니까 누군가 리눅스용 드라이버를 제작해 놨는데, 오래된 경우라 최신의 리눅스 커널을 위해서는 패치를 해야하고 그 패치도 누군가 만들어서 올려놨더군요.

이 문서는 Atheros AR81 Family GigaEthernet 리눅스 드라이버를 설치하는 방법을 설명한 것 입니다.

1. 다운로드

첨부파일을 다운로드 하면 됩니다.

첨부파일: AR81Family-linux-v1.0.1.14.tar

2. 설치

먼저, 커널 소스를 설치합니다. 현재 설치된 커널의 버전에 맞는 것을 설치해야 합니다.

Atheros 드라이버는 커널의 소스를 ‘/usr/src/linux’ 디렉토리에서 찾습니다. 다음과 같이 심볼릭 링크를 생성해 줍니다.

압축을 푼 드라이버 디렉토리에서 컴파일 설치를 해줍니다.

부팅시 마다 자동으로 모듈을 로딩하도록 하기 위해서 다음과 같이 해줍니다.

재부팅해서 eth0 가 올라오는지 살펴봅니다.

대부분 다 잘 올라 옵니다. eth0 가 올라오면 이제 IP 설정을 해주면 됩니다.

  • Camera: Nikon D200
  • Focal length: 5.6mm
  • ISO: 100
  • Shutter speed: 1/204s

아파치 로그 분석하기

Apache Logo

아파치 웹 서버에는 접속에 대한 로그를 남길 수 있습니다.

로그의 형식은 다양하지만 대략적으로 어느 컴퓨터(IP 주소)에서 어떤 기기, 어떤 프로그램을 이용해서 어떤 웹 페이지를 접속했는지, 각 컨텐츠의 전송량등의 정보가 담깁니다.

이 문서는 아파치 로그 분석하기 에 대한 것입니다.

전송량 통계

로그 파일에 컨텐츠의 전송량이 담기기 때문에 이것들을 전부 더하면 아파치 웹 서버가 내보낸 전송량을 알 수 있겠지요? awk 쉘 스크립트로 간단하게 할 수 있습니다.

여기서 중요한 것이 access_log 파일에 전송량을 표시하는 위치 입니다. 위 명령어 앞줄에 ‘s += $10’ 이 있는데, 공백을 기준으로 10번째 칸이 전송량을 표시한다는 거기 때문에 전송량 표시되는 부분이 12번째 칸이라면 이것을 ‘s += $12’ 로 고쳐줍니다.

좀 더 나가서 특정 아이피에 대한 것만 계산하고 싶다면 다음과 같이 해줍니다.

grep 을 이용해서 필요로하는 컨테츠만을 뽑아서 총 전송량을 계산할 수 있습니다.

로봇에 의한 전송량도 계산할 수 있습니다. 구글 봇이 페이지를 긁어가는데 들어간 전송량은 다음과 같이 계산할 수 있습니다.

HTTP 응답코드별 트래픽 계산은 다음과 같이 할 수 있습니다.

응답코드만을 다르게하면 응답코드별로 트래픽 양을 알수 있습니다.

HTTP 응답코드 세기

HTTP 응답코드는 중요 합니다. 이를 잘 파악하면 웹 사이트에 대한 상태를 알 수도 있습니다.

외부에서 이미지 링크 파악

종종 외부 사이트에서 내 사이트에서 이미지를 링크걸어놓은 것을 볼 수 있습니다. 트래픽을 절약하기 위해서 종종 사용하기도 하는데, 이러한 것을 다음과 같이 파악할 수 있습니다.

http://linux.systemv.pe.kr 부분을 자신의 웹사이트 주소를 입력해 주시면 됩니다.

MariaDB 오픈 소스 데이터베이스

MariaDB 는 한 개발자의 노력을 시작된 오픈 소스 프로젝트 입니다. 과거 오픈 소스 데이터베이스의 대명사인 MySQL 을 개발한 개발자 중에 한인 Monty Widenius. 1962년 핀란드 태생으로 1995년 MySQL 데이터베이스를 개발하기 시작해서 그 이듬해에 첫 릴리즈를 하게 됩니다. 그리고 1998년, 3.21 버전부터 www.mysql.com 을 만들어 운영하면서 명실상부한 오픈 소스 데이터베이스로 발을 딛기 시작 합니다.

Monty Widenius
MySQL 을 개발한 Monty Widenius

MySQL은 오픈소스 정책을 가지고 있지만 개발과 판매등을 총괄하는 회사가 있습니다. MySQL AB 라는 회사인데, 개발지원에서부터 판매, 홍보까지 MySQL에 거의 모든것을 관장하던 회사입니다. MySQL이 오픈소스이긴 하지만 라이센스정책이 이중으로 되어있어(GPL, CopyRight) 이러한 라이센스 관련해서 제품의 구성등 전반적인 부분도 이 회사에서 모두 관리합니다.

MySQL이 오픈소스 진영에서 이름을 날리고 있던 2008년에 썬 아킥텍쳐 및 썬 OS로 유명한 ‘Sun microsystems’ 에 85억 달러에 인수 됩니다. 이때에 MySQL을 전부 총괄하던 MySQL AB 회사도 함께 넘어감으로써 모든 지적재산권도 썬으로 넘어가게 됩니다. 그러던 것이 1년도 않된 시점인 2009년 4월 오라클이 썬마이크로시스템즈를 인수함으로써 MySQL AB 의 모든 지적재선권은 다시 오라클로 넘어갑니다.

Oracle. 오픈소스 진영에서는 거의 악날함을 자주 보여줬던 RDBMS 최강의 회사 입니다. 상용시장에서 독보적인 오라클 데이터베이스 를 가지고 있었고 인수전에는 MySQL과 알게 모르게 경쟁하던 데이터베이스 제품을 가진 회사였기 때문에 인수당시부터 오픈소스진영에서는 MySQL에 대한 운명(?)에 대해서 우려하는 목소리가 많았습니다. ‘오라클 스럽게 죽일거다’라는 소리가 자주 들렸지요.

그런데, MySQL AB를 설립했던 Michael “Monty” Widenius(마이클 ‘몬티’ 비드니우스) 라는 사람이 오라클을 뛰쳐 나옵니다. 오픈소스 정의감으로 뛰쳐나왔으면 드라마틱하겠지만 오라클에서 대우가 별로 맘에 않들었다고 하네요. 그러한 그가 나와서 뭘했을 까요? 배운게 도둑질인데, 오라클 회사를 나와서 ‘Monty Program’ 이라는 것을 하게됩니다. 그리고 이 ‘Moty Program’ 에서 GPL 라이센스로 되어있는 MySQL 코드를 Branch 해서 RDBMS를 만들게 되었는데 그것이 바로 ‘MariaDB’ 입니다.

Monty Widenius 는  오라클이 MySQL 을 인수하게되자 오픈 소스 진영에 MySQL 을 구해달라는 호소문을 올리기도 합니다.

[MySQL 을 구해주세요!!]

실제로 오라클이 MySQL 을 인수하고 난 후에, 오라클은 라이센스 정책을 변경했으며 MySQL 의 테스트 소스코드를 비공개로 변경했습니다.

이러한 오라클의 폐쇄적인 정책으로 불구하고 MariaDB 는 수많은 개발자들의 기부로 인해서 성장했고 대부분의 리눅스 배포판에서 MySQL 을 대체하는데 이르렀습니다. 현재 MariaDB 는 10 버전을 출시로 더욱 강력해지고 안전한 데이터베이스를 제공하고 있습니다.

Mariadb
Mariadb 의 로고

 

smartctl을 이용한 하드디스크 진단

컴퓨터에서 디스크의 의미는 매우 중요합니다. 사람의 데이터를 영구적으로 보관해야 할 의무를 가지 때문이지요. 이러한 디스크에 문제가 발생한다면 데이터를 영구적으로 잃을 수도 있고 오늘과 같이 IT 를 기반으로 사회가 움직이는 마당에 그러한 일이 발생한다면 큰 금전적인 손실을 입을 수도 있습니다.

이렇게 중요한 디스크의 문제나 오류를 차단하기 위해서는 주기적으로 점검을 해야할 필요가 있는데, 리눅스 시스템에서는 이러한 유용한 도구를 제공 합니다.

smartctl

smartctl 도구는 S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) 기능이 탑재된 하드디스크를 점검하는 도구 입니다. 사실상 S.M.A.R.T 의 기능을 이용하는 도구이다보니 이 기능이 없는 하드디스크는 이 도구를 이용할 수가 없습니다. 하지만 걱정할 필요는 없습니다. S.M.A.R.T. 기능은 오래전부터 있었던 것이라 왠만한 하드디스크에는 모두 지원되고 있습니다.

먼전, 간단한 디스크 정보도 볼겸 하드디스크에 S.M.A.R.T. 가 기능이 있고 활성화가 되어 있는지를 다음과 같이 해봅니다.

‘-i’ 옵션을 주고 리눅스에서 하드디스크 장치를 인자로 주면 위와같은 결과를 보여줍니다. 주목해야 할 것은 맨 아래에 있는 ‘SMART support is: Enabled’ 입니다. 또, 자세히 보면 ‘/dev/sda’ 의 하드디스크 정보도 함께 파악할 수 있습니다.

참고로, 위의 결과는 하드디스크마다 다 다릅니다. 다른 하드디스크를 봐보겠습니다.

자세히 보면 이전 결과와 달리 ‘SATA Version is:’ 라고해서 SATA 버전도 나오고 ‘Rotation Rate’ 이라고해서 하드디스크의 회전수인 RPM 도 나옵니다. 추가적으로 WARING 을 통해서 이 하드디스크의 최신 펌웨어 정보가 있으니 업그레이드해보라고까지 나옵니다.

다음으로 좀 더 많은 자세하고 많은 정보를 봐보겠습니다.

‘-a’ 옵션을 주면 위와같이 상세한 정보가 나옵니다. 눈여겨 보실 부분은 중간에 나온 ‘SMART Attributes with Thresholds’ 부분 입니다. 각 항목별로 오른쪽에 수치가 나옵니다. 각각의 항목별은 의미가 다 있는데, 여기서 집중해서 봐야할 항목은 다음과 같습니다.

  • Raw_Read_Error_Rate : 디스크로부터 데이터를 읽을때에 발생한 오류 비율. 외부에 물리적으로 충격이 가해지면 이 수치가 치솟는다고 합니다.
  • Reallocated_Sector_Ct : 섹터에 문제가 발생할 경우에 대체영역으로 섹터를 바꾼 횟수
  • Seek_Error_Rate : 하드디스크에서 데이터를 찾는 동안에 발생한 탐색 오류 비율.
  • Offline_Uncorrectable : Offline 은 전원이 없는 상태를 말하며 하드디스크가 꺼졌을때에 잘못된 섹터 갯수로 매우 심각한 상태를 말한다.
  • UDMA_CRC_Error_Count : 데이터 전송시에 발생한 CRC 체크섬 오류 횟수.

위 부분에 수치들이 높게 나온다면 문제가 있다고 봐야 하며 될수 있으면 하드디스크 구매한 곳에가서, A/S 기간이 남았다면, 교체를 요청해야 합니다.

특히나 서버에서 사용되어지는 하드디스크는 다른 하드디스크들보다 중요성은 말할 필요도 없겠지요. smartctl 을 통해서 미리미리 장애를 대응함으로써 중요한 데이터를 보호할 수 있습니다.

 

Apache mod_ruid2 설치

Apache LogoApache 는 TCP/IP 접속과 접속이 이루어진 후에 컨텐츠를 처리하는 프로세스의 권한이 다릅니다. TCP/IP 접속관련은 Root 권한으로 동작하고 이후 동작은 아파치의 설정에 따른 권한으로 실행 됩니다.

 

아파치의 동작 권한은 다음과 같이 설정 합니다.

위 설정은 아파치의 컨텐츠를 처리하는 프로세스가 nobody:nobody 권한으로 동작하도록 지정한 것입니다.

그런데, 이렇게 하면 버추얼 호스트(VirtualHost) 설정을 할 경우에 보통 각 계정별로 RootDocument 를 설정하는데, 이럴경우 아파치 프로세스는 한가지의 권한으로 동작하고 모든 계정에 접근해야 함으로 각 계정에 액세스 권한을 줘야 합니다. 그래서 주로 다음과 같이 해줘야 합니다.

이러한 아파치 권한과 리눅스 시스템 계정별 권한때문에 공개 CMS 프로그램들(xe, gnuboard, wordpress) 등을 설치할때에 홈디렉토리의 퍼미션을 777 로 하게됩니다. 이럴경우 보안상 큰 문제가 됩니다.

아파치의 컨텐츠 프로세스마다 지정한 시스템 계정의 권한으로 동작하도록 하게 한다면 각 계정별로 퍼미션을 바꿀 필요가 없게 됩니다. 이러한 것을 가능하도록 해주는 모듈이 바로 mod_ruid2 입니다.

이 문서는 Apache mod_ruid2 설치 에 관련된 내용 입니다.

1. 설치 환경

설치 환경은 다음과 같습니다.

  • 배포판: CentOS 7
  • Apache Version: 2.4.10
  • Apache MPM: prefork

2. mod_ruid2 설치.

mod_ruid2 프로젝트 홈페이지에서 다운로드 받고 압축을 해제한 후에 apxs 를 이용해서 다음과 같이 설치 해줍니다.

모듈 파일이 설치되고 httpd.conf 파일에 이 모듈이 자동으로 활성화 됩니다.

3. mod_ruid2 설정

기본적으로 다음과 같이 사용을 하시면 됩니다.

4. 그러나, 아직은..

이 모듈은 프로세스의 소유권 변환을 해줌으로 보안성을 향상시키지만 다음과 같은 모듈과 호환성을 제공하지 않습니다. (함께 쓸수 없다는 이야기…)

  • mod_cache
  • mod_cache_disk
  • mod_cache_socache
  • MPM worker
  • MPM event

Apache 2.4.10 이후로 SSLSessionCache를 위해선 mod_cache_socache 의 의존성을 가지고 있기 때문에 mod_ruid2 를 사용한다면 SSL 제대로 동작하지 않을 가능성이 있습니다. (mod_cache_socache 는 과거의 mod_mem_cache 입니다.)

MPM event 일 경우에 이것이 동작하지 않는다는게 가장 큰 문제로 보입니다.

Apache mod_deflate 설정

Apache LogoApache 2.4 에서 mod_deflate 설정 에 대한 문서 입니다.

Apache 2.2 에비해서 Apache 2.4 에서의 설정이 새롭게 바뀌었습니다.

 

 

1. Requirement

Apache 2.4 에서 mod_deflate 를 사용하기 위해서는 다음과 같은 모듈들도 활성화되어야 합니다.

  • mod_setenvif : 환경변수를 정의한다.
  • mod_headers : HTTP 요청 헤더와 응답 헤더를 조절하고 수정하는 지시어를 제공한다.
  • mod_deflate : 서버의 출력을 네트웍으로 클라이언트에 보내기 전에 압축하는 기능 제공

위 모듈들이 Apache 2.4.10 에 활성화 되어 있어야 합니다.

2. 설정

mod_deflate 의 설정은 Apache 2.2 와 2.4 가 차이가 있습니다. 두 버전에 상관없이 설정할 수 있는 방법도 있는데, 이것은 아파치 문서에 나와 있는 방법이기도 합니다.

그런데, Apache 2.4 의 Fileter 모듈을 적용해서 특정한 컨텐츠타입에만 Deflate 를 적용하면 다음과 같습니다.

deflate 를 사용하는데 따라 클라이언트에게 압축된 컨텐츠라는 걸 알려주기 위해서 헤더값을 다음과 같이 조작해 줍니다.

이것을 종합하면 다음과 같습니다.

iptable 의 hashlimit 를 이용한 접속 제한

보통 DDOS 공격과 같은 경우에 초당 몇 십개에서 몇백번건의 접속을 시도 합니다. 이러한 초당 수백건의 접속을 이용해서 iptables 의 hashlimit 를 이용한 접속 제한을 할 수 있습니다.

예를들어 초당 20번 이상 접속을 시도하는 것을 차단하고 싶다면 다음과 같이 지정하면 됩니다.

이 차단은 약 1시간 동안 유지됩니다.