A boring day ~

#WebSphere

[WebSphere] 디렉토리 리스팅(Directory Listing) 제거 및 보안 설정 (directoryBrowsingEnabled)

웹 서버가 특정 디렉토리 내의 파일 목록을 브라우저에 노출하는 '디렉토리 리스팅' 취약점을 해결하기 위한 WebSphere 설정 가이드입니다. 애플리케이션 레벨(xml) 수정 방식과 관리 콘솔(Admin Console)을 통한 전역 설정 방식을 다룹니다.

0. 배경 및 원인 (Context)

디렉토리 리스팅이 활성화되어 있으면 공격자가 서버의 디렉토리 구조와 파일 목록(백업 파일, 소스 코드 등)을 파악할 수 있어 2차 공격의 빌미가 됩니다.

WebSphere는 정적 파일 처리를 위한 fileServingEnabled 속성과 목록 노출을 위한 directoryBrowsingEnabled 속성을 가지고 있으며, 이를 적절히 제어해야 합니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTPServer v8.5.0.0
WAS: WebSphere Application Server v8.5

1. Method A: 애플리케이션 설정 파일 수정

개별 애플리케이션 단위로 설정을 적용할 때 사용합니다. WAR/EAR 파일 내부의 IBM 확장 설정 파일을 직접 수정합니다.

설정 파일 대상

WAS v7.0 이상: ibm-web-ext.xml
WAS v6.1 이하: ibm-web-ext.xmi (Legacy)

설정 내용 (ibm-web-ext.xml)

enable-directory-browsing 속성을 false로 명시합니다.

<?xml version="1.0" encoding="UTF-8"?>
<web-ext
    xmlns="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0 http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0/web-ext.xsd">

    <!-- 정적 파일 서빙 활성화 (이미지, HTML 등) -->
    <enable-file-serving value="true"/>
    
    <!-- 핵심: 디렉토리 리스팅 비활성화 -->
    <enable-directory-browsing value="false"/>

</web-ext>

2. Method B: 웹 컨테이너(Web Container) 전역 설정

WAS 관리 콘솔에서 서버 단위로 속성을 추가하여 제어하는 방식입니다. 애플리케이션을 재배포하지 않고 설정을 변경할 수 있어 운영 환경에서 선호됩니다.

설정 경로

서버(Servers) > 서버 유형(Server Types) > WebSphere application servers > [서버명] > 웹 컨테이너 설정(Web Container Settings) > 웹 컨테이너(Web container) > 사용자 정의 특성(Custom properties)

주요 속성 값

아래 속성을 새로 작성(New)하여 추가합니다.

이름 (Name)	값 (Value)	설명
directoryBrowsingEnabled	false	디렉토리 목록 조회 기능을 비활성화합니다. (보안 필수)
fileServingEnabled	true	WAS가 정적 파일(html, img 등)을 처리할지 여부입니다. (false 설정 시 정적 파일 처리가 불가할 수 있음)

참고: fileServingEnabled를 false로 설정하면 디렉토리 리스팅도 차단되지만, WAS가 이미지나 CSS 같은 정적 리소스를 전혀 제공하지 않게 되므로 주의가 필요합니다. 일반적으로는 directoryBrowsingEnabled만 false로 설정합니다.

3. 검증 (Verification)

설정 적용 후 WAS 인스턴스를 재기동합니다.
브라우저에서 index.html이 없는 디렉토리 경로(예: http://domain/images/)로 접속합니다.
403 Forbidden 에러가 발생하면 보안 설정이 정상적으로 적용된 것입니다.

Read Log →

#apache#SSL

[OpenSSL/Apache] 사설 인증서(Self-Signed Certificate) 생성 및 적용 완벽 가이드

개발 및 테스트 환경의 HTTPS 구현을 위해 OpenSSL로 사설 인증서를 생성하는 방법을 정리합니다. 실무에서 혼동하기 쉬운 Key, CSR, CRT 파일의 정확한 역할 정의부터, 개인키 패스워드 제거 및 Apache 적용까지의 전체 프로세스를 다룹니다.

0. 배경 지식: 인증서 파일의 종류와 역할

SSL 인증서 발급 과정은 개인키 생성 → 인증 요청(CSR) → 인증서 발급(CRT)의 순서로 진행됩니다. 각 단계에서 생성되는 파일의 역할을 명확히 이해해야 합니다.

1. Private Key (.key):
- 서버가 갖는 비밀 열쇠입니다. 데이터를 암호화/복호화하는 핵심 파일로, 절대 외부로 유출되어서는 안 됩니다.
- 이 키를 분실하면 인증서를 재발급받아야 합니다.
2. CSR (.csr - Certificate Signing Request):
- 인증 기관(CA)에 "내 인증서를 만들어 달라"고 보내는 신청서입니다.
- 공개키(Public Key) 정보와 도메인, 회사 정보(DN)가 포함되어 있습니다.
3. Certificate (.crt):
- 최종적으로 발급된 인증서(신분증)입니다.
- CSR 내용을 바탕으로 CA(혹은 본인)가 전자 서명을 한 파일이며, 클라이언트(브라우저)에게 전송됩니다.

Test Environment

OS: CentOS 7.2
Web Server: Apache HTTP Server
Tool: OpenSSL

1. 개인키(Private Key) 생성

가장 먼저 모든 암호화 통신의 기반이 되는 개인키를 생성합니다.

1) 암호화된 개인키 생성

des3 알고리즘을 사용하여 2048비트 길이의 RSA 키를 생성합니다. 이때 설정하는 패스워드(Pass Phrase)는 키를 보호하기 위한 장치입니다.

[root@web01 test]# openssl genrsa -des3 -out test.vn.key 2048

Generating RSA private key, 2048 bit long modulus
..........................+++
e is 65537 (0x10001)
Enter pass phrase for test.vn.key: [패스워드 입력]
Verifying - Enter pass phrase for test.vn.key: [패스워드 확인]

2) 개인키 패스워드 제거 (필수 권장)

패스워드가 걸린 키를 웹 서버에 그대로 적용하면, 서버가 재기동될 때마다 관리자가 매번 패스워드를 입력해야 합니다. 자동 운영을 위해 패스워드를 제거한 키를 다시 생성합니다.

# 1. 원본 키 백업
cp test.vn.key test.vn.key.orig

# 2. 패스워드가 제거된 키 생성 (덮어쓰기)
openssl rsa -in test.vn.key.orig -out test.vn.key

# 결과 메시지
Enter pass phrase for test.vn.key.orig: [기존 패스워드 입력]
writing RSA key

2. 인증 요청서(CSR) 생성

생성된 개인키(.key)를 바탕으로 인증서 발급 신청서(.csr)를 작성합니다.

CSR 생성 명령어

openssl req -new -key test.vn.key -out test.vn.csr

주요 입력 정보 (DN: Distinguished Name)

명령 실행 후 입력해야 할 정보입니다. 다른 정보는 임의로 입력해도 되지만, Common Name은 반드시 정확해야 합니다.

Country Name: 국가 코드 (예: KR, VN)
State / Locality: 지역 정보 (예: Seoul)
Organization: 회사명/부서명 (예: IT Team)
Common Name (CN): 서비스 도메인 주소 (가장 중요! 예: *.test.vn)

Note: 추가 정보인 'Challenge password' 등은 입력하지 않고 Enter를 눌러 넘어가도 무방합니다.

3. 사설 인증서(CRT) 생성 (Self-Signing)

우리는 공인 인증 기관(VeriSign 등)이 없으므로, 생성한 CSR에 내 개인키로 직접 서명(Self-Sign)하여 인증서(CRT)를 만듭니다.

인증서 생성

유효기간을 365일로 설정하여 최종 인증서를 생성합니다.

# -req : CSR을 입력받음
# -signkey : 스스로 서명할 키 지정
openssl x509 -req -days 365 -in test.vn.csr -signkey test.vn.key -out test.vn.crt

# 성공 시 출력 메시지
Signature ok
subject=/C=VN/ST=Hanoi/L=lotte/O=admin/OU=admin/CN=*.test.vn
Getting Private key

최종 파일 확인

작업이 완료되면 다음 3개의 파일이 있어야 합니다.

test.vn.key: 개인키 (패스워드 제거됨, 서버 설정에 사용)
test.vn.crt: 인증서 (서버 설정에 사용)
test.vn.csr: 신청서 (발급 완료 후에는 불필요)

4. Apache 설정 및 검증

생성된 키와 인증서를 Apache 설정 파일(httpd.conf 또는 ssl.conf)에 등록하여 HTTPS를 활성화합니다.

설정 적용

# SSL 엔진 활성화
SSLEngine on

# 1. 인증서 파일 경로 지정 (.crt)
SSLCertificateFile /etc/httpd/conf/ssl/test.vn.crt

# 2. 개인키 파일 경로 지정 (.key)
SSLCertificateKeyFile /etc/httpd/conf/ssl/test.vn.key

검증 (Verification)

Apache를 재기동하고 브라우저로 접속해 봅니다. 패스워드를 묻지 않고 기동되어야 정상입니다.

재기동: systemctl restart httpd
브라우저 접속: https://test.vn

주의 (Warning):
사설 인증서는 브라우저가 신뢰하는 기관(CA) 목록에 없으므로, 접속 시 "주의 요함" 또는 "안전하지 않음" 경고가 뜨는 것이 정상입니다. 테스트 환경에서는 예외를 추가하여 진행하면 됩니다.

Read Log →

#JBoss

[JBoss/Apache] mod_cluster 연동 완벽 가이드: 동적 클러스터링 및 멀티캐스트 설정

JBoss EAP 6와 Apache HTTP Server를 mod_cluster 모듈을 사용하여 연동하는 방법을 정리합니다. 정적인 설정 없이도 WAS의 추가/삭제를 자동으로 감지하는 동적 클러스터링을 구현하며, 멀티캐스트(Advertise) 설정을 중심으로 다룹니다.

0. 사전 준비 (Prerequisites)

OS: Windows 10 (테스트 환경)
Web Server: Apache 2.2.x (JBoss EWS 포함 버전 권장)
Middleware: JBoss EAP 6.4.x

버전 호환성 주의: Apache 버전에 맞는 mod_cluster 모듈(.so)을 사용해야 합니다. JBoss EWS(Enterprise Web Server) 패키지를 사용하면 이미 최적화된 모듈이 포함되어 있습니다.

1. Apache 설정 (Web Server)

Apache에 mod_cluster 관련 모듈을 로드하고, JBoss가 보낸 멀티캐스트 신호를 수신할 수 있도록 설정합니다.

1) 필수 모듈 복사

JBoss EAP 설치 경로에 포함된 mod_cluster 관련 모듈(.so)을 Apache의 modules 디렉토리로 복사합니다.

원본 위치: [EAP_HOME]/modules/system/layers/base/native/lib64/httpd/modules
복사할 파일:
- mod_advertise.so
- mod_manager.so
- mod_proxy_cluster.so
- mod_slotmem.so

2) mod_cluster.conf 작성

httpd.conf에서 include 할 설정 파일을 작성합니다. 핵심은 VirtualHost 내의 ServerAdvertise On 설정입니다.

# 필수 모듈 로드 (순서 중요)
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

# 공유 메모리 파일 위치 지정
MemManagerFile "C:/Apache/logs/mod_cluster"


  # JBoss 상태 관리 및 Advertise 수신 포트
  Listen 6666
  
    
      Order deny,allow
      Deny from all
      Allow from 127.0.0.1  # 보안상 로컬 접근만 허용 권장
    
    
    # 멀티캐스트 광고 활성화 (핵심)
    ServerAdvertise on
    EnableMCPMReceive

    # 관리 콘솔 URL
    
      SetHandler mod_cluster-manager
      Order deny,allow
      Allow from all

2. JBoss 설정 (Middleware)

JBoss가 기동될 때 자신의 정보를 멀티캐스트로 전파하거나, 프록시(Apache) 리스트를 받아오도록 설정합니다.

1) Instance ID 설정 (domain.xml)

Sticky Session을 위해 각 서버 인스턴스에 고유한 ID를 부여해야 합니다. ${jboss.server.name} 변수를 사용하면 편리합니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="${jboss.server.name}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
    ...
</subsystem>

2) 소켓 바인딩 (Socket Binding) - 멀티캐스트 주소

동일 네트워크 내에 여러 JBoss 클러스터가 존재할 경우 혼선을 방지하기 위해 멀티캐스트 주소나 포트를 변경해야 합니다.

domain.xml 수정 (socket-binding-group):

<socket-binding-group name="full-ha-sockets" default-interface="public">
    
    ...
</socket-binding-group>

Tip: XML을 수정하지 않고 기동 시 파라미터(System Property)로 주소를 변경할 수 있습니다.
-Djboss.modcluster.multicast.address=224.10.1.1

3. 검증 및 테스트

설정 완료 후 Apache -> JBoss 순서로 기동합니다.

1) Apache 관리 콘솔 접속

브라우저에서 http://[Apache_IP]:6666/mod_cluster_manager 로 접속합니다.

정상: 하단에 연결된 JBoss Node(Node Name, IP, Port) 리스트가 나타납니다.
실패: 리스트가 비어있다면 멀티캐스트 통신이 방화벽에 막혀있거나, Advertise 설정이 잘못된 것입니다.

2) 클러스터링 동작 확인

애플리케이션 호출 시 세션이 유지되는지 확인하고, 한 쪽 노드를 셧다운 시켰을 때 Failover가 일어나는지 테스트합니다.

[그림] mod_cluster 매니저 화면 (노드 인식 성공)

Next Step:
멀티캐스트 사용이 불가능한 클라우드 환경이라면, mod_cluster 설정을 TCP 유니캐스트(Proxy List 지정 방식)로 변경하여 구성하는 방법을 검토해 보십시오.

Read Log →

#JBoss

[JBoss EAP 6] Windows Service 등록 가이드 (service.bat install)

Windows 환경에서 JBoss EAP 6를 백그라운드 서비스로 등록하여, 시스템 부팅 시 자동으로 시작되도록 설정하는 방법을 정리합니다. JBoss Native 패키지에 포함된 service.bat 스크립트를 사용합니다.

0. 사전 준비 (Prerequisites)

서비스 등록 작업을 수행하기 위해 관리자 권한(Run as Administrator)으로 실행된 명령 프롬프트(CMD)가 필요합니다.

시스템 환경 변수 설정

JBoss가 서비스로 구동될 때 참조할 필수 변수를 시스템 환경 변수에 등록해야 합니다.

JBOSS_HOME: JBoss EAP 6 설치 디렉토리 (예: C:\jboss-eap-6.4)
NOPAUSE: 값을 1로 설정.
(※ 중요: 이 설정이 없으면 서비스 종료 시 배치 스크립트가 "Press any key..." 상태로 대기하여 서비스가 정상적으로 멈추지 않는 문제가 발생합니다.)

1. 서비스 설치 스크립트 위치

JBoss EAP 6는 Windows 서비스 등록을 위한 Native 유틸리티를 내장하고 있습니다. 해당 경로로 이동합니다.

:: 경로 이동 (설치 환경에 따라 경로가 다를 수 있음)
cd %JBOSS_HOME%\modules\system\layers\base\native\sbin

:: 파일 확인
dir service.bat

2. 서비스 등록 (Install Command)

service.bat install 명령어를 사용합니다. 운영 모드(Standalone / Domain)에 따라 옵션이 다릅니다.

Case A: Standalone Mode (단독 인스턴스)

가장 일반적인 구성입니다. 로그 레벨을 지정하여 설치합니다.

service.bat install /loglevel INFO

Case B: Domain Mode (도메인 구성)

도메인 컨트롤러(Domain Controller)와 연결해야 하므로 컨트롤러 정보가 필요합니다.

:: 기본 구문
service.bat install /controller [Host:Port] /host [HostName] /loglevel INFO

:: 사용 예시 (로컬이 마스터인 경우)
service.bat install /controller localhost:9990 /host master /loglevel INFO

주요 옵션 설명

옵션	설명
`/name`	서비스 이름 지정 (기본값: JBossEAP6)
`/desc`	서비스 설명 지정
`/serviceuser`	서비스를 실행할 Windows 계정 (DOMAIN\User)
`/servicepass`	실행 계정의 암호

3. 등록 확인 및 제어 (Verification)

설치가 완료되면 Windows 서비스 관리자에서 확인할 수 있습니다.

실행 창(Win+R) > services.msc 입력.
"JBoss Enterprise Application Platform 6" 서비스를 찾습니다.
서비스를 시작(Start) 하고, 상태가 '실행 중'으로 바뀌는지 확인합니다.
브라우저로 JBoss 관리 콘솔이나 메인 페이지에 접속하여 실제 구동 여부를 체크합니다.

4. 서비스 삭제 (Uninstall)

설정을 변경하거나 경로를 바꿀 경우, 기존 서비스를 삭제하고 다시 등록해야 합니다.

:: 서비스 중지 (먼저 수행 필수)
service.bat stop

:: 서비스 삭제
service.bat uninstall

주의: 서비스 삭제 후 services.msc 목록에 잔상이 남아있다면, 윈도우를 재부팅하거나 관리자 권한 CMD에서 sc delete [서비스명]을 강제로 수행해야 할 수 있습니다.

Read Log →

#IBM HTTPServer

[IHS/Apache] 보안 강화를 위한 불필요 HTTP Method(PUT, DELETE, TRACE) 차단 설정

웹 서버 운영 시 보안 취약점(파일 변조, 정보 노출 등)을 방지하기 위해 GET, POST를 제외한 불필요한 HTTP Method(PUT, DELETE, TRACE, OPTIONS)를 차단하는 방법을 정리합니다. IBM HTTP Server(Apache) 설정과 WAS(web.xml) 설정 두 가지 방식을 다룹니다.

0. 배경 지식 (Context)

기본적으로 웹 서버는 다양한 HTTP Method를 지원하지만, 실제 서비스에서는 대부분 GET과 POST만 사용합니다. 불필요한 메소드를 열어둘 경우 다음과 같은 보안 위험이 있습니다.

PUT, DELETE: 악의적인 사용자가 서버의 파일을 생성, 수정, 삭제할 수 있음.
TRACE: XST(Cross-Site Tracing) 공격에 악용되어 쿠키/세션 정보가 탈취될 수 있음.
OPTIONS: 서버가 지원하는 메소드 정보를 노출함.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTP Server v8.5 (Apache 2.2 Base)

1. Web Server 레벨 차단 (httpd.conf)

가장 앞단의 웹 서버에서 원천 차단하는 것이 리소스 낭비를 막고 안전합니다. 두 가지 방법 중 하나를 선택하여 적용하십시오.

Method A: LimitExcept 지시어 사용 (권장)

특정 디렉토리나 URL 패턴에 대해 허용할 메소드를 정의하고 나머지는 거부하는 방식입니다.

# 1. 특정 디렉토리 기준 차단
<Directory "/WAS/htdocs">
    Options FollowSymLinks
    AllowOverride None
    
    # GET, POST를 제외한 모든 메소드 거부
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Directory>

# 2. 전역(URL) 기준 차단 (Directory 설정이 모호할 때)
<Location "/*">
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Location>

버전별 문법 주의 (Note):
IHS v8.5(Apache 2.2)는 Order/Deny를 사용하지만, IHS v9.0(Apache 2.4) 이상에서는 Require all denied 문법을 사용해야 합니다.

Method B: Mod_Rewrite 사용

mod_rewrite 모듈을 사용하여 메소드 조건을 검사하고 강제로 에러 코드를 반환하는 방식입니다.

LoadModule rewrite_module modules/mod_rewrite.so

<IfModule mod_rewrite.c>
    RewriteEngine On
    
    # 조건: 요청 메소드가 GET 또는 POST가 아니라면
    RewriteCond %{REQUEST_METHOD} !^(GET|POST)
    
    # 규칙: 405 (Method Not Allowed) 에러 반환
    RewriteRule .* - [R=405,L]
</IfModule>

2. WAS 레벨 차단 (web.xml)

웹 서버 설정이 불가능하거나, 애플리케이션(WAR) 단위로 제어가 필요한 경우 표준 배포 서술자(web.xml)를 사용합니다.

설정 방법

web.xml에 security-constraint를 추가하여 특정 메소드에 대한 접근을 제한합니다.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Restricted Methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        
        <!-- 차단할 메소드 명시 -->
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>TRACE</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>HEAD</http-method>
    </web-resource-collection>
    
    <!-- 중요: auth-constraint를 비워두면 누구에게도 권한을 주지 않음(차단) -->
    <auth-constraint />
</security-constraint>

3. 검증 (Verification)

설정 적용 후 반드시 테스트를 통해 차단 여부를 확인해야 합니다. telnet 또는 curl을 사용합니다.

Telnet을 이용한 테스트

$ telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.

# OPTIONS 메소드 요청 입력
OPTIONS / HTTP/1.0
Host: localhost
(엔터 두 번)

# 결과 확인 (403 Forbidden 또는 405 Method Not Allowed 확인)
HTTP/1.1 403 Forbidden
Date: Wed, 04 Jul 2018 01:44:40 GMT
...

Curl을 이용한 테스트 (간편)

# -X 옵션으로 메소드 지정, -I 옵션으로 헤더만 확인
curl -v -X OPTIONS http://localhost/

# 결과: < HTTP/1.1 403 Forbidden 확인

Next Step:
메소드 차단 외에도 ServerTokens Prod 설정을 통해 헤더에 노출되는 웹 서버 버전 정보를 숨기는 보안 조치를 추가로 검토해 보시기 바랍니다.

Read Log →

#IBM HTTPServer

[IBM HTTP Server ] IBM HTTP Server v8.5 vs v9.0: Apache Base Version 확인 및 차이점 (Apache 2.2 vs 2.4)

IBM HTTP Server(IHS)는 Apache HTTP Server를 기반으로 만들어졌습니다. IHS v8.5(Apache 2.2 기반)와 IHS v9.0(Apache 2.4 기반)의 버전 정보를 확인하고, 엔진 업그레이드에 따른 설정 파일(httpd.conf) 호환성 주의사항을 정리합니다.

1. 버전 확인 방법 (Check Version)

IHS의 실행 파일(apache.exe 또는 httpd)에 -V 옵션을 주어 컴파일 옵션과 기반 버전을 확인할 수 있습니다.

명령어

# Windows
cd [IHS_HOME]\bin
.\apache.exe -V

# Linux/Unix
cd [IHS_HOME]/bin
./apachectl -V

2. 버전별 상세 정보 (Output Analysis)

IHS v8.5 (Apache 2.2 Base)

IHS 8.5.5는 Apache 2.2.8 버전을 베이스로 하여 IBM의 추가적인 패치와 보안 수정이 적용된 버전입니다.

PS E:\app\was\HTTPServer\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/8.5.5.0 (Win32)
Apache version: 2.2.8 (with additional fixes)  <-- Check Point
Server built:   Feb 20 2013 13:50:05
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/winnt"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

IHS v9.0 (Apache 2.4 Base)

IHS 9.0은 Apache 2.4.12 버전을 베이스로 합니다. Apache 2.4로 넘어오면서 성능 개선(Event MPM 등)과 설정 문법의 변화가 생겼습니다.

PS E:\software\IBM\HTTPServer9\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/9.0.0.0-PI56034 (Win32)
Apache version: 2.4.12 (with additional fixes) <-- Check Point
Server built:   Apr 18 2016 20:28:53
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

3. 마이그레이션 주의사항 (Apache 2.2 vs 2.4)

IHS v8.5에서 v9.0으로 업그레이드할 때 가장 주의해야 할 점은 접근 제어(Access Control) 구문의 변화입니다. 기존 httpd.conf를 그대로 사용하면 에러가 발생할 수 있습니다.

주요 변경 점 비교

구분	IHS v8.5 (Apache 2.2)	IHS v9.0 (Apache 2.4)
모든 요청 허용	Order allow,deny Allow from all	Require all granted
모든 요청 거부	Order deny,allow Deny from all	Require all denied
특정 IP 허용	Order deny,allow Deny from all Allow from 127.0.0.1	Require ip 127.0.0.1

Warning: IHS 9.0에서 기존 2.2 문법(Order/Allow)을 사용하려면 mod_access_compat 모듈을 로드해야 합니다. 하지만 장기적으로는 신규 문법(Require)으로 전환하는 것을 권장합니다.

Next Step:
IHS 버전을 업그레이드할 계획이라면, 운영 중인 httpd.conf 파일 내의 접근 제어 구문을 미리 전수 조사하여 Apache 2.4 문법으로 변환하는 작업을 진행해 보십시오.

Read Log →

#Liberty#WebSphere

[WebSphere] Liberty Core 설치 및 필수 설정 가이드 (CLI Install, server.xml, Plugin)

IBM WebSphere Liberty Core를 GUI 없이 Command Line(CLI) 환경에서 설치하고, 서버 생성 및 기동, 핵심 설정(server.xml, JVM), 그리고 웹 서버 연동을 위한 플러그인 생성(pluginUtility) 과정을 단계별로 정리합니다.

1. 제품 설치 (CLI Mode)

Liberty는 Installation Manager(IM)의 imcl 명령어를 통해 설치합니다. GUI를 사용할 수 없는 리눅스/유닉스 서버 환경에서 필수적인 방법입니다.

설치 명령어 (imcl)

-repositories 옵션에는 설치 파일(Repository)의 경로를 지정합니다. 콤마(,)로 구분하여 WAS와 JDK 리포지토리를 동시에 지정할 수 있습니다.

# 설치 예시 (Windows 기준, Linux는 경로만 변경)
imcl install com.ibm.websphere.liberty.v85_8.5.16002.20160526_2338 \
com.ibm.websphere.liberty.IBMJAVA.v80_8.0.3020.20161124_1304 \
-repositories "D:\Liberty\16.0.0.2-WS-LIBERTY-CORE,D:\work_file\was_install\v8.5.5\SDK\8.0.3.20" \
-installationDirectory "F:\app\IBM\wlpcore\AppServer" \
-acceptLicense \
-showProgress -sP

Tip: 패키지 ID(com.ibm...)를 모를 경우 imcl listAvailablePackages -repositories [경로] 명령어로 미리 확인해야 합니다.

2. 서버 생명주기 관리 (Server Lifecycle)

설치가 완료되면 bin 디렉토리의 server 스크립트를 사용하여 서버 인스턴스를 생성하고 제어합니다.

1) 서버 생성 (Create)

cd [WLP_HOME]/bin
# 구문: server create [서버명]
server.bat create test01

생성이 완료되면 [WLP_HOME]/usr/servers/test01 경로에 설정 파일들이 만들어집니다.

2) 서버 기동 및 상태 확인 (Start/Status)

# 서버 기동
server.bat start test01

# 상태 확인 (필수 검증 단계)
server.bat status test01

3. 핵심 설정 (server.xml)

Liberty의 모든 구성은 server.xml 파일 하나에 통합되어 있습니다. 필요한 기능(Feature)만 선언해서 사용하는 구조입니다.

설정 파일 위치

[WLP_HOME]/usr/servers/[서버명]/server.xml

주요 설정 예시

<?xml version="1.0" encoding="UTF-8"?>
<server description="Test Server">

    <!-- 1. Feature Manager: 필요한 기능 모듈 로드 -->
    <featureManager>
        <feature>jsp-2.2</feature>
        <feature>jdbc-4.0</feature>
        <feature>localConnector-1.0</feature> <!-- 로컬 관리용 -->
        <feature>adminCenter-1.0</feature>    <!-- 웹 관리 콘솔 -->
    </featureManager>

    <!-- 2. HTTP Endpoint: 포트 설정 -->
    <!-- host="*"는 모든 IP 대역에서의 접속을 허용함 -->
    <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443">
        <tcpOptions soReuseAddr="true" />
    </httpEndpoint>

    <!-- 3. Web Server Plugin 설정 -->
    <pluginConfiguration webserverPort="80" webserverSecurePort="443"/>

    <!-- 4. Application 배포 설정 (자동 인식이 편함) -->
    <applicationManager autoExpand="true"/>
    
    <!-- 5. DB Connection (Oracle 예시) -->
    <dataSource id="WorklightDS" jndiName="jdbc/WorklightDS">
        <jdbcDriver libraryRef="OracleLib"/>
        <properties.oracle 
            driverType="thin" 
            databaseName="ORCL" 
            serverName="localhost" 
            portNumber="1521" 
            user="SCOTT" 
            password="{xor}KDAtNDM2ODcr"/> <!-- securityUtility로 암호화 권장 -->
    </dataSource>

    <!-- 6. Logging 설정 -->
    <logging maxFiles="5" consoleLogLevel="INFO"/>

</server>

초보자를 위한 Tip:
설정 파일의 password="{xor}..." 부분은 평문을 그대로 넣지 않고, Liberty가 제공하는 bin/securityUtility encode [암호] 명령어를 사용하여 인코딩된 값을 넣어야 보안상 안전합니다.

4. 환경 변수 및 JVM 옵션 설정

메모리(Heap) 설정이나 로그 경로 변경 등은 별도의 설정 파일에서 관리합니다.

1) JVM 옵션 (jvm.options)

Heap Size나 GC 로그 설정은 jvm.options 파일에 라인 단위로 작성합니다.

위치: [WLP_HOME]/usr/servers/[서버명]/jvm.options

# Heap Memory 설정
-Xms512m
-Xmx1024m

# GC 로그 설정
-verbose:gc
-Xverbosegclog:verbosegc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC

2) 환경 변수 (server.env)

JAVA_HOME 지정이나 커스텀 로그 경로는 server.env에 정의합니다.

# Java 버전 지정
JAVA_HOME=C:\Java\jdk1.8.0

# 로그 경로 변경 (Optional)
WLP_OUTPUT_DIR=F:\app\IBM\wlpcore\AppServer\usr\logs\test02

5. 웹 서버 플러그인 (Plugin) 생성

Liberty 서버 앞단에 IHS(Apache)를 둔다면, plugin-cfg.xml을 생성하여 웹 서버에 알려주어야 합니다.

플러그인 생성 도구 (pluginUtility)

Liberty 16.0.0.4 버전부터 pluginUtility 명령어를 사용합니다.

cd [WLP_HOME]/bin

# 1. 로컬 서버용 플러그인 생성
pluginUtility generate --server=test01 --targetpath=./plugin-cfg.xml

# 2. 원격 서버용 플러그인 생성 (Admin Center 기능 필요)
pluginUtility generate --server=admin:password@remoteHost:9443 --targetpath=./plugin-cfg.xml

# 3. 여러 플러그인 병합 (Merge)
pluginUtility merge --sourcepath=../usr/plugin --targetpath=../usr/merged_plugin.xml

웹 서버(httpd.conf) 적용

생성된 xml 파일을 웹 서버로 복사한 후 httpd.conf에 등록합니다.

# Windows 예시
LoadModule was_ap22_module "C:\IBM\HTTPServer\plugins\bin\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\plugins\config\webserver1\plugin-cfg.xml"

# Linux/Unix 예시
LoadModule was_ap22_module "/opt/IBM/HTTPServer/plugins/bin/mod_was_ap22_http.so"
WebSpherePluginConfig "/opt/IBM/HTTPServer/plugins/config/webserver1/plugin-cfg.xml"

Next Step:
기본 설치와 설정이 끝났다면, adminCenter 기능을 활성화하고 브라우저(https://localhost:9443/adminCenter)로 접속하여 GUI 환경에서 서버 상태를 모니터링해 보십시오.

Read Log →

#JBoss

[JBoss EAP 6] Context Root를 루트(/)로 변경하기: Welcome Page 비활성화 설정

웹 애플리케이션을 배포할 때, URL 뒤에 붙는 프로젝트명(예: /MyApp) 없이 도메인 자체(예: http://localhost:8080/)로 접속하도록 설정하는 방법을 정리합니다. 애플리케이션 설정 변경과 JBoss 서버의 기본 Welcome Page 비활성화 작업이 필요합니다.

0. 배경 지식 (Context)

기본적으로 JBoss EAP는 루트 경로(/)에 "Welcome to JBoss"라는 기본 환영 페이지가 매핑되어 있습니다. 사용자의 애플리케이션을 루트 경로에 배포하려면, 이 기본 환영 페이지 기능을 끄고 애플리케이션이 그 자리를 차지하도록 설정해야 합니다.

Test Environment

OS: CentOS 7.2
WAS: JBoss EAP 6.4

1. 애플리케이션 설정 (jboss-web.xml)

애플리케이션(WAR) 내부의 설정 파일을 통해 "이 앱은 루트 컨텍스트(/)를 사용하겠다"고 선언합니다.

파일 생성 및 수정

위치: [WAR_FILE]/WEB-INF/jboss-web.xml
파일이 없다면 새로 생성하십시오.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
    <!-- Context Root를 / 로 지정 -->
    <context-root>/</context-root>
</jboss-web>

2. 서버 설정 (domain.xml / standalone.xml)

애플리케이션 설정만으로는 부족합니다. JBoss 웹 서브시스템(Web Subsystem) 설정에서 enable-welcome-root 옵션을 false로 변경하여 기본 페이지를 비활성화해야 합니다.

설정 파일 선택

Domain Mode: [EAP_HOME]/domain/configuration/domain.xml
Standalone Mode: [EAP_HOME]/standalone/configuration/standalone.xml

수정 내용

도메인 모드의 경우, 현재 서버 그룹이 사용 중인 프로파일(Profile)(예: ha, full, full-ha)을 정확히 찾아 수정해야 합니다.

<!-- 해당 프로파일 내의 web 서브시스템 검색 -->
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    
    <!-- 핵심 수정 부분: enable-welcome-root를 false로 변경 -->
    <virtual-server name="default-host" enable-welcome-root="false">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>

</subsystem>

주의 (Warning):
enable-welcome-root="true"인 상태에서 애플리케이션의 Context Root를 /로 설정하고 배포하면, JBoss 기동 시 "Context / is already in use" 에러가 발생하며 배포에 실패합니다.

3. 적용 및 검증 (Verification)

설정 변경 후에는 서버 재기동이 필요합니다.

재기동 및 접속 테스트

JBoss 서버를 재기동합니다.
브라우저 주소창에 http://[서버IP]:8080/ 을 입력합니다.
JBoss 기본 환영 페이지가 아닌, 내가 배포한 애플리케이션의 메인 페이지가 뜨는지 확인합니다.

Next Step:
루트 컨텍스트 설정이 완료되었다면, Apache 웹 서버와의 연동 시 mod_jk의 JkMount 설정도 /*로 변경하여 모든 요청을 WAS로 넘기도록 조정해야 합니다.

Read Log →

#JBoss

[JBoss EAP 6] Session Clustering 완벽 가이드: 애플리케이션 설정부터 TCP 유니캐스트 전환까지

JBoss EAP 6의 HA(High Availability) 프로파일 환경에서 웹 애플리케이션의 세션 클러스터링을 구현하는 방법을 정리합니다. <distributable/> 선언부터 복제 트리거 설정, 그리고 웹 서버(Apache)와의 연동을 위한 jvmRoute 및 JGroups 네트워크 설정까지 다룹니다.

Test Environment

Middleware: JBoss EAP 6.4 (Domain Mode)
Profile: ha 또는 full-ha (클러스터링 모듈이 포함된 프로파일 필수)

1. 애플리케이션 설정 (Application Config)

세션 클러스터링이 작동하려면 먼저 애플리케이션이 "나는 분산 가능한 애플리케이션입니다"라고 선언해야 합니다.

1) web.xml 설정 (필수)

<distributable/> 태그가 없으면 JBoss는 해당 애플리케이션의 세션을 메모리에만 저장하고 복제하지 않습니다.

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" ...>
    
    <distributable/>

    <session-config>
        <session-timeout>30</session-timeout> </session-config>

</web-app>

2) jboss-web.xml 설정 (옵션/상세 튜닝)

세션 복제의 빈도와 범위를 세밀하게 제어하려면 WEB-INF/jboss-web.xml 파일을 설정합니다.

<jboss-web>
    <replication-config>
        <cache-name>web</cache-name>
        <!-- 복제 시점 결정 -->
        <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
        <!-- 복제 단위 결정 (SESSION: 전체 / ATTRIBUTE: 변경된 속성만) -->
        <replication-granularity>SESSION</replication-granularity>
    </replication-config>
</jboss-web>

Replication Trigger 설명:

SET: 세션 속성이 변경(setAttribute)될 때만 복제 (성능 우수).
SET_AND_GET: 세션을 읽기만 해도 복제 (데이터 일관성 최우선).
SET_AND_NON_PRIMITIVE_GET: (Default) 기본형이 아닌 객체를 읽거나 변경할 때 복제.

2. Sticky Session 설정 (jvmRoute)

웹 서버(Apache mod_jk/mod_cluster)가 로드밸런싱을 할 때, 사용자가 처음 접속한 JBoss 서버로 계속 요청을 보내게 하려면(Sticky Session), 세션 ID 뒤에 서버 식별자(jvmRoute)를 붙여야 합니다.

1) host.xml 설정 (서버별 식별자 부여)

각 서버 인스턴스에 고유한 jvmRoute 값을 시스템 프로퍼티로 정의합니다.

<servers>
    <server name="Server01" group="main-server-group" auto-start="true">
        <system-properties>
            <!-- 이 값은 workers.properties의 워커 이름과 일치해야 함 -->
            <property name="jvmRoute" value="Server01" boot-time="true"/>
        </system-properties>
    </server>
    
    <server name="Server02" ...>
        <system-properties>
            <property name="jvmRoute" value="Server02" boot-time="true"/>
        </system-properties>
    </server>
</servers>

2) domain.xml 설정 (Web Subsystem 적용)

정의한 시스템 프로퍼티(${jvmRoute})를 웹 서브시스템의 instance-id로 매핑합니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="${jvmRoute}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <!-- AJP 커넥터 필수 (mod_jk 연동 시) -->
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
    ...
</subsystem>

3. JGroups 네트워크 설정 (UDP vs TCP)

JBoss 클러스터링 멤버 간의 통신은 기본적으로 UDP(Multicast)를 사용합니다. 하지만 클라우드 환경이나 네트워크 장비에서 멀티캐스트를 차단하는 경우 클러스터링이 되지 않습니다. 이럴 땐 TCP(Unicast)로 변경해야 합니다.

domain.xml 수정

jgroups 서브시스템의 default-stack 속성을 변경합니다.

<!-- 기존 UDP 설정 -->
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="udp">

<!-- TCP로 변경 -->
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
    <stack name="tcp">
        <transport type="TCP" socket-binding="jgroups-tcp"/>
        ...
    </stack>
</subsystem>

주의: TCP로 변경 시, MPING(멀티캐스트 기반 멤버 검색) 대신 TCPPING을 사용하여 정적으로 IP 리스트를 지정해야 서로를 찾을 수 있는 환경이 많습니다. 네트워크 구성에 따라 추가 설정이 필요합니다.

4. 검증 (Verification)

서버 기동 확인: 서버 시작 로그에 Received new cluster view 메시지가 나타나며 멤버들이 서로를 인식하는지 확인합니다.
세션 ID 확인: 브라우저 개발자 도구(F12)에서 JSESSIONID 쿠키 값 뒤에 .Server01 처럼 jvmRoute 값이 붙는지 확인합니다.
Failover 테스트: 한 쪽 서버를 강제로 내린 후(Shutdown), 다른 서버에서 로그인 풀림 없이 세션이 유지되는지 테스트합니다.

Read Log →

#JBoss

[JBoss EAP 6] 도메인 모드(Domain Mode) 서버 로그 경로 변경 및 분리 설정

JBoss EAP 6를 도메인 모드(Domain Mode)로 운영할 때, 기본 로그 경로가 아닌 별도의 디스크 경로로 로그를 저장하는 방법을 정리합니다. domain.xml의 paths 설정과 logging 서브시스템을 수정하여 각 서버 인스턴스별로 로그 폴더를 동적으로 분리하는 구성을 다룹니다.

0. 배경 지식 (Context)

도메인 모드에서는 하나의 도메인 컨트롤러(Domain Controller)가 여러 서버 그룹과 인스턴스를 관리합니다. 로그 설정 시 가장 중요한 점은 "여러 서버가 동시에 실행될 때 로그 파일이 섞이지 않게 하는 것"입니다.

이를 위해 JBoss는 ${jboss.server.name}이라는 시스템 변수를 제공하여, 설정은 한 번만 하더라도 실제 로그는 각 서버의 이름으로 된 폴더에 쌓이도록 구성할 수 있습니다.

1. 사전 준비 및 백업

설정 변경 중 오타가 발생하면 JBoss 도메인 전체가 기동되지 않을 수 있습니다. 작업 전 반드시 설정 파일을 백업하십시오.

백업 대상

파일 경로: [EAP_HOME]/domain/configuration/domain.xml

# 백업 예시
cp domain.xml domain.xml.bak_YYYYMMDD

2. 로그 경로(Path) 정의

먼저 로그를 저장할 물리적인 디렉토리 경로를 domain.xml 내에 논리적인 이름으로 정의해야 합니다. 이 설정은 파일의 상단 <paths> 섹션에 위치합니다.

domain.xml 수정

기존 <paths> 태그 내부에 새로운 경로를 추가합니다.

<paths>
    <!-- 기존 경로들 ... -->
    
    <!-- 신규 로그 경로 정의 -->
    <!-- name: 설정에서 사용할 논리적 이름 / path: 실제 파일 시스템 경로 -->
    <path name="server.log.dir" path="D:\app\log"/>
</paths>

주의: Windows 환경에서는 백슬래시(\)를 사용하고, Linux 환경에서는 슬래시(/)를 사용하여 경로를 지정하십시오. 또한 해당 경로에 JBoss 실행 계정이 쓰기 권한을 가지고 있어야 합니다.

3. 프로파일(Profile) 로깅 설정 적용

위에서 정의한 경로를 실제로 사용하도록 로깅 서브시스템(Subsystem)을 수정합니다. 도메인 모드에는 여러 프로파일(default, ha, full, full-ha 등)이 존재하므로, 현재 운영 중인 서버 그룹이 사용하는 프로파일을 정확히 찾아 수정해야 합니다.

domain.xml 수정 (logging subsystem)

<profile name="ha"> (예시) 내부의 로깅 설정을 찾아 file-handler 부분을 수정합니다.

<profile name="ha">
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
        <!-- Console Handler 생략 -->

        <!-- File Handler 수정 -->
        <periodic-rotating-file-handler name="FILE" autoflush="true">
            <formatter>
                <named-formatter name="PATTERN"/>
            <formatter>
            
            <!-- 핵심 설정 부분 -->
            <!-- relative-to: 위에서 정의한 경로 변수 참조 -->
            <!-- path: 서버 이름별로 폴더 자동 생성 -->
            <file relative-to="server.log.dir" path="${jboss.server.name}/server.log"/>
            
            <suffix value=".yyyy-MM-dd"/>
            <append value="true"/>
        </periodic-rotating-file-handler>
        
        <!-- 이하 생략 -->
    </subsystem>
</profile>

설정 설명

relative-to="server.log.dir": 2번 단계에서 정의한 D:\app\log를 기준 경로로 잡습니다.
path="${jboss.server.name}/server.log": 기준 경로 하위에 서버 인스턴스 이름(예: Server1, Server2)으로 폴더를 만들고 그 안에 server.log를 생성합니다.

4. 적용 및 검증 (Verification)

domain.xml은 정적 설정 파일이므로 변경 사항을 적용하려면 도메인 전체 재기동이 필요합니다.

재기동

# Linux
[EAP_HOME]/bin/domain.sh

# Windows
[EAP_HOME]\bin\domain.bat

결과 확인

서버가 기동된 후, 탐색기나 쉘을 통해 지정한 경로(D:\app\log)에 서버별 폴더가 생성되었는지 확인합니다.

D:\app\log\
    ├── Server1\
    │     └── server.log
    └── Server2\
          └── server.log

Next Step:
로그 경로 변경에 성공했다면, 운영 편의를 위해 로그 파일의 보관 주기(Retention Policy)를 설정하거나, 로그 포맷(Formatter)을 변경하여 가독성을 높이는 작업을 고려해 보십시오.

Read Log →