A boring day ~

#JBoss#Troubleshooting

[JBoss EAP 7] JSESSIONID 형식 변경 이슈 분석 및 jvmRoute(Instance-ID) 설정 가이드

JBoss EAP 7 도입 시 JSESSIONID 뒤에 예상치 못한 문자열(서버명, 그룹명 등)이 붙거나 길이가 늘어나는 현상을 분석합니다. 이는 Undertow 엔진의 JvmRouteHandler 동작 방식 때문이며, 이를 제어하기 위한 설정 방법을 정리합니다.

1. 이슈 현상 및 원인 분석 (Context)

EAP 6와 EAP 7은 세션 ID를 생성하고 관리하는 방식에 차이가 있습니다. 특히 클러스터링 환경에서 Sticky Session(세션 고정)을 위해 ID 뒤에 붙이는 식별자(Route)의 기본 동작이 다릅니다.

버전별 차이점

구분	JBoss EAP 6.x (JBossWeb)	JBoss EAP 7.x (Undertow)
Engine	Apache Tomcat Fork	Undertow
Format	`[ID].[jvmRoute]`	`[ID].[instance-id]`
Default	설정 없으면 ID만 생성하거나 Hostname 부착	강제로 `jboss.node.name` 부착

기술적 원인 (Undertow JvmRouteHandler)

EAP 7의 웹 엔진인 Undertow는 io.undertow.server.JvmRouteHandler를 통해 세션 ID를 처리합니다. 이 핸들러는 클러스터링 설정 여부와 관계없이, 설정된 instance-id가 있다면 무조건 세션 ID 뒤에 붙이도록 설계되어 있습니다. 또한, 이 값은 null이거나 비활성화(disable)할 수 없으며 기본적으로 노드 이름을 따라갑니다.

2. 해결 및 설정 방법 (Configuration)

JSESSIONID 뒤에 붙는 값을 제어하기 위해서는 undertow 서브시스템의 instance-id 속성을 명시적으로 변경해야 합니다.

설정 파일 수정 (standalone.xml / domain.xml)

Undertow 서브시스템 설정에서 instance-id 값을 원하는 식별자(기존 jvmRoute와 동일한 역할)로 지정합니다.

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <ajp-listener name="ajp" socket-binding="ajp"/>
        <host name="default-host" alias="localhost">
            ...
        </host>
    </server>
    
    <servlet-container name="default" default-session-timeout="30" instance-id="${jboss.node.name}" />
    
</subsystem>

CLI를 이용한 변경

운영 중인 환경에서 값을 변경하려면 관리 CLI를 사용하는 것이 안전합니다.

# instance-id를 'node1'으로 변경하는 예시
/subsystem=undertow/servlet-container=default:write-attribute(name=instance-id, value="node1")

# 설정 적용을 위해 리로드 필요
reload

주의 (Warning):
instance-id를 변경하면 기존에 발급된 세션 ID와 매핑이 달라지므로, 기존 사용자들의 세션이 끊길(Invalidate) 수 있습니다. 서비스 점검 시간에 수행하십시오.

3. 검증 (Verification)

설정 변경 후 애플리케이션을 호출하여 쿠키 값을 확인합니다.

개발자 도구 확인

브라우저 F12 (개발자 도구) 실행
Application 탭 > Cookies 선택
JSESSIONID의 값 확인

결과 예시:

변경 전: abcde12345.server-one-instance-group-a (길고 복잡함)
변경 후: abcde12345.node1 (설정한 값으로 깔끔해짐)

Next Step:
만약 앞단의 웹 서버(Apache/IHS)와 mod_cluster 또는 mod_jk로 연동 중이라면, 웹 서버 설정의 jvmRoute 값과 JBoss의 instance-id 값이 정확히 일치해야 스티키 세션(Sticky Session)이 정상 작동합니다. 반드시 양쪽 설정을 맞춰주세요.

Read Log →

#VSCode

[VS Code] 한글 깨짐 현상 완벽 해결: Auto Guess Encoding 및 인코딩 수동 변경

Windows 환경(CP949/EUC-KR)에서 작성된 텍스트 파일을 VS Code(기본 UTF-8)로 열었을 때 발생하는 한글 깨짐 현상을 해결합니다. 파일의 인코딩을 자동으로 인식하게 하는 설정과 수동으로 인코딩을 지정하여 다시 여는 방법을 정리합니다.

0. 배경 및 원인 (Context)

한글 윈도우 메모장에서 저장한 파일은 기본적으로 EUC-KR(또는 CP949) 인코딩을 사용합니다. 반면, VS Code는 전 세계 표준인 UTF-8을 기본값으로 파일을 엽니다. 이 해석 방식의 차이로 인해 한글이 ''와 같이 깨져 보이게 됩니다.

Test Environment

OS: Windows 10
Software: Visual Studio Code

1. Method A: 자동 인코딩 인식 설정 (Auto Guess Encoding)

VS Code가 파일 내용을 분석하여 인코딩을 자동으로 추측하도록 설정합니다. 매번 인코딩을 바꿀 필요가 없어 편리합니다.

설정 방법

설정 진입: 메뉴에서 File > Preferences > Settings (단축키: Ctrl + ,)
검색: 검색창에 encoding 입력
옵션 체크: Files: Auto Guess Encoding 항목을 찾아 체크박스 선택(Check)

Note: 이 기능은 확률에 기반하여 추측하므로, 간혹 영문만 있는 파일이나 특수한 경우 인코딩을 잘못 인식할 수도 있습니다.

2. Method B: 수동으로 다시 열기 (Reopen with Encoding)

자동 설정이 불안하거나 특정 파일만 깨질 때 사용하는 가장 확실한 방법입니다.

작업 절차

VS Code 우측 하단 상태 표시줄(Status Bar)에 있는 UTF-8 클릭.
상단 명령 팔레트에서 "Reopen with Encoding (인코딩하여 다시 열기)" 선택.
목록에서 "Korean (EUC-KR)" 검색 후 선택.

이렇게 하면 파일 내용은 깨지지 않고 정상적으로 보입니다.

3. Method C: UTF-8로 영구 변환 (Save with Encoding)

EUC-KR 파일을 향후 호환성을 위해 UTF-8로 변경하여 저장하고 싶을 때 사용합니다.

작업 절차

위의 Method B를 통해 한글이 정상적으로 보이는 상태로 만듭니다.
우측 하단 상태 표시줄의 인코딩(EUC-KR) 클릭.
상단 명령 팔레트에서 "Save with Encoding (인코딩하여 저장)" 선택.
"UTF-8" 선택.

이제 이 파일은 영구적으로 UTF-8로 저장되어, 어떤 환경에서도 한글이 깨지지 않습니다.

4. 결과 확인 (Verification)

설정을 적용하거나 인코딩을 변경한 후, 깨져 보이던 한글 주석이나 텍스트가 정상적으로 표시되는지 확인합니다.

Before (깨짐)

After (정상)

Next Step:
팀 프로젝트를 진행한다면 팀원 간의 인코딩 통일을 위해 .editorconfig 파일을 프로젝트 루트에 생성하여 charset = utf-8을 강제하는 방법을 권장합니다.

Read Log →

#Error#JBoss

[JBoss EAP 7] 설치 오류 해결: java.lang.UnsupportedClassVersionError (JDK 버전 호환성)

JBoss EAP 7 설치 또는 기동 중 java.lang.UnsupportedClassVersionError가 발생한다면, 현재 서버에 설정된 Java 버전이 JBoss가 요구하는 최소 사양(JDK 1.8)보다 낮기 때문입니다. 에러 메시지의 major.minor version 숫자를 통해 원인을 분석하는 방법을 알아봅니다.

1. 문제 현상 및 원인 분석

JBoss 설치 스크립트 실행 시 아래와 같은 에러 로그가 출력되며 프로세스가 종료됩니다.

Exception in thread "main" java.lang.UnsupportedClassVersionError: 
com/ibm/websphere/... : Unsupported major.minor version 52.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    ...

원인 (Root Cause)

이 에러는 컴파일된 클래스 파일의 버전(Target JVM)보다 현재 실행 중인 JVM 버전(Runtime)이 낮을 때 발생합니다.

JBoss EAP 7.x 요구사항: 최소 JDK 1.8 이상
현재 서버 상황: JDK 1.7 이하가 설치되어 있거나 JAVA_HOME이 구버전을 가리키고 있음

2. 버전 매핑 테이블 (Class File Format)

에러 메시지에 뜨는 숫자(52.0, 51.0 등)는 Java 클래스 파일 포맷의 메이저 버전을 의미합니다. 아래 표를 참고하여 현재 필요한 Java 버전을 확인하십시오.

Java Version (SE)	Major Version (Hex)	Major Version (Dec)
Java 14	0x3A	58
Java 13	0x39	57
Java 12	0x38	56
Java 11	0x37	55
Java 9	0x35	53
Java 8	0x34	52
Java 7	0x33	51
Java 6	0x32	50

분석 예시:
에러 메시지가 Unsupported major.minor version 52.0이라면, 해당 프로그램은 Java 8로 컴파일되었으므로 서버에도 Java 8 이상이 설치되어야 합니다.

3. 해결 방법 (Solution)

1) 현재 Java 버전 확인

java -version

출력 결과가 1.7.x 이하라면 JDK 업그레이드가 필요합니다.

2) JDK 설치 및 환경 변수 변경

서버에 JDK 1.8 이상을 설치한 후, JBoss가 참조하는 설정 파일에서 JAVA_HOME 경로를 수정해야 합니다.

Standalone 모드: [EAP_HOME]/bin/standalone.conf (Windows는 .bat)
Domain 모드: [EAP_HOME]/bin/domain.conf (Windows는 .bat)

# standalone.conf 예시
# JAVA_HOME="/usr/lib/jvm/java-1.7.0"  <-- 기존 (주석 처리)
JAVA_HOME="/usr/lib/jvm/java-1.8.0"    <-- 신규 경로로 변경

Next Step:
JDK 버전을 올린 후에는 기존 애플리케이션(WAR/EAR)이 새 Java 버전에서 정상적으로 동작하는지, -Xmx 등 메모리 옵션이 변경된 버전에 맞게 설정되었는지 확인해야 합니다.

Read Log →

#command#windows

[Windows] CMD를 리눅스 터미널처럼: doskey를 이용한 Alias(매크로) 설정 및 영구 적용

Windows CMD 환경에서 ls, cp, rm 등 익숙한 Linux 명령어를 사용하기 위해 doskey 매크로를 설정하는 방법을 정리합니다. 배치 파일(alias.cmd)을 작성하고 레지스트리(AutoRun)에 등록하여 CMD 실행 시 자동으로 별칭이 적용되도록 구성합니다.

0. 배경 (Context)

Windows CMD는 기본적으로 dir, copy, del 등의 명령어를 사용합니다. Linux의 ls, cp 등에 익숙한 사용자는 매번 오타를 내거나 불편함을 겪게 됩니다. 이를 해결하기 위해 doskey 명령어를 사용하여 명령어의 별칭(Alias)을 지정할 수 있습니다.

Test Environment

OS: Windows 10 / 11
Shell: Command Prompt (CMD)

1. 매크로 파일 작성 (alias.cmd)

먼저, 매크로 정의를 담을 배치 파일을 생성합니다. 적당한 위치(예: C:\Utils\alias.cmd)에 파일을 만들고 아래 내용을 작성합니다.

Tip: $*는 입력된 모든 인자(Arguments)를 그대로 전달하겠다는 의미입니다. (예: ls -al 입력 시 dir -al로 변환)

@echo off

:: --- System & Utility ---
doskey alias   = doskey $*
doskey clear   = cls
doskey history = doskey /history
doskey man     = help $*

:: --- Process Management ---
doskey ps      = tasklist $*
doskey kill    = taskkill /PID $*

:: --- File & Directory Management ---
doskey ls      = dir $*
doskey ll      = dir $*
doskey cat     = type $*
doskey pwd     = cd
doskey cp      = copy $*
doskey mv      = move $*
doskey rm      = del $*

:: --- Search (grep -> findstr 권장) ---
:: find는 단순 문자열 검색, findstr은 정규식 지원
doskey grep    = find $* :: --- Permissions (Approximate) ---
doskey sudo    = runas /user:administrator $*

2. 레지스트리 등록 (영구 적용)

위에서 만든 alias.cmd 파일은 CMD를 켤 때마다 실행해줘야 하는 번거로움이 있습니다. 이를 자동화하기 위해 레지스트리의 AutoRun 기능을 사용합니다.

설정 경로 및 값

경로: HKEY_CURRENT_USER\Software\Microsoft\Command Processor
문자열 값(String Value): AutoRun
데이터(Data): [alias.cmd 파일의 절대 경로]

등록 방법 A: 명령어로 한방에 등록 (권장)

관리자 권한으로 CMD를 열고 아래 명령어를 입력합니다. (경로는 본인 파일 위치에 맞게 수정하세요)

:: 경로 예시: E:\software\google\2_Shellscript\alias.cmd
reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /t REG_SZ /d "E:\software\google\2_Shellscript\alias.cmd" /f

등록 방법 B: regedit 사용 (수동)

Win + R 키를 누르고 regedit 실행
컴퓨터\HKEY_CURRENT_USER\Software\Microsoft\Command Processor 경로로 이동
우측 빈 공간 우클릭 > 새로 만들기 > 문자열 값 선택
이름을 AutoRun으로 지정
더블 클릭하여 값 데이터에 alias.cmd의 절대 경로 입력

3. 적용 확인 (Verification)

설정이 완료되었다면, 새로운 CMD 창을 열어서 리눅스 명령어가 작동하는지 확인합니다.

:: 1. CMD 실행
C:\Users\User>

:: 2. ls 명령어 테스트
C:\Users\User> ls
 C 드라이브의 볼륨에는 이름이 없습니다.
 ... (디렉토리 목록 출력) ...

:: 3. alias 목록 확인
C:\Users\User> alias /macros

Next Step:
만약 CMD가 아닌 PowerShell을 주로 사용하신다면, Microsoft.PowerShell_profile.ps1 파일에 Set-Alias 명령어를 추가하여 동일한 환경을 구축할 수 있습니다.

Read Log →

#command#Linux

[Linux] 서버 관리 필수 명령어 모음: 로그 정리(find), 네트워크(netstat), 메모리 점검

리눅스 시스템 운영 중 로그 파일 정리, 디스크 용량 확보, 네트워크 연결 상태 점검, 메모리 사용률 확인을 위해 자주 사용하는 명령어 패턴(One-Liner)을 정리합니다. RedHat/CentOS 7 환경을 기준으로 작성되었습니다.

Test Environment

OS: CentOS 7, RedHat 7.2
Shell: Bash

1. 파일 검색 및 정리 (File Management)

서버 운영 중 가장 흔한 이슈는 로그 파일로 인한 디스크 풀(Disk Full)입니다. find 명령어를 사용하여 오래된 파일을 검색하고 삭제하는 패턴입니다.

최근 수정된 파일 찾기

설정 파일(xml 등)이 최근에 변경되었는지 확인할 때 사용합니다.

# 최근 7일 이내(-7)에 수정된 xml 파일 검색
find . -type f -name "*.xml" -mtime -7 -print

오래된 로그 파일 삭제

로그 디렉토리 관리를 위해 일정 기간이 지난 파일을 삭제합니다. 삭제 명령(rm)을 실행하기 전, 반드시 조회(ls)를 먼저 수행하여 대상을 검증해야 합니다.

# 1. 대상 확인 (7일이 지난 로그 파일 조회)
find /log/server1 -name "*.log" -mtime +7 -print

# 2. 삭제 실행 (방법 A: -delete 옵션 사용)
find /log/server1 -name "*.log" -mtime +7 -delete

# 2. 삭제 실행 (방법 B: -exec rm 사용, 가장 범용적)
find /log/server1 -name "*.log" -mtime +7 -exec rm -f {} \;

# 3. 30일 이상 된 로그 파일만 강제 삭제
find /log/server1 -type f -name "*.log" -ctime +30 -exec rm -rf {} \;

대용량 파일 검색

디스크 용량을 많이 차지하는 파일을 찾습니다.

# 3GB 이상인 파일을 찾아 용량과 함께 출력
find . -size +3000000k -exec ls -lh {} \+

날짜순 파일 정렬 보기

기본 ls -l의 날짜 포맷이 보기 힘들 때 ISO 포맷으로 변환하여 확인합니다.

ls --time-style="+%Y-%m-%d %H:%M:%S" -altr | grep ^- | more

2. 네트워크 상태 점검 (Network Monitoring)

웹 서버나 DB 서버의 현재 연결 상태를 확인하여 트래픽 스파이크나 연결 누수(Leak)를 점검합니다.

동시 접속자 수 확인 (Web Server)

ESTABLISHED 상태는 현재 연결이 수립되어 데이터를 주고받는 상태를 의미합니다.

# 80 포트 동시 접속자 수 카운트
netstat -nap | grep :80 | grep ESTABLISHED | wc -l

# 8080 포트(WAS) 동시 접속자 수 카운트
netstat -nap | grep :8080 | grep ESTABLISHED | wc -l

DB 연결 풀(Connection Pool) 확인

WAS에서 DB로 맺은 연결 개수를 확인합니다. 포트 번호로 grep하여 정렬합니다.

# 특정 포트와 연결된 소켓 정보 확인
netstat -anp | grep {port_number}

# 연결 개수 카운트
netstat -anp | grep {port_number} | wc -l

3. 메모리 사용률 점검 (Memory Check)

리눅스의 free 명령어는 버퍼/캐시 메모리를 포함하여 보여주기 때문에, 실제 애플리케이션이 사용하는 메모리(Actual Used)를 계산하기 위해서는 별도의 연산이 필요할 때가 있습니다.

메모리 계산 스크립트 (Shell)

전체 메모리 대비 실제 사용률을 백분율(%)로 계산하는 스크립트입니다.

#!/bin/sh
# free 명령어의 출력 컬럼 위치는 OS 버전에 따라 다를 수 있으므로 확인 필요 (awk $2, $3...)

# Total Memory
TOTAL=`free | grep ^Mem | awk '{print $2}'`

# Used Memory (OS 관점)
USED1=`free | grep ^Mem | awk '{print $3}'`

# Used Memory (Buffer/Cache 제외, CentOS 6 이하 구버전 방식)
# USED2=`free | grep ^-/+ | awk '{print $3}'`

# CentOS 7 이상 (available 컬럼 등 고려 필요하나 단순 계산 시)
# 버퍼/캐시를 포함한 단순 사용률
NOMINAL=$((100*USED1/TOTAL))

echo "Memory Usage: ${NOMINAL}%"

One-Liner (간편 계산)

awk를 사용하여 한 줄로 메모리 사용률을 출력합니다.

# 전체 메모리 대비 사용량(Used) 비율
awk '/^Mem/ {printf("Used: %u%%", 100*$3/$2);}' <(free -m)

# (참고) 버퍼/캐시를 제외한 실 사용률 계산은 free -m의 available 컬럼을 활용하는 것이 정확합니다.
free -m | awk 'NR==2{printf "Memory Usage: %.2f%%\n", ($3/$2)*100 }'

Next Step:
반복적으로 사용하는 위 명령어들을 ~/.bash_profile에 alias로 등록해두면, 긴 명령어를 타이핑하는 수고를 덜고 오타로 인한 사고를 방지할 수 있습니다.

Read Log →

#Liberty#WebSphere

[WebSphere] Liberty Profile & Eclipse 연동 개발 환경 구축 가이드 (WDT 설치)

IBM WebSphere Liberty Profile(WLP)을 로컬 개발 환경인 Eclipse에 연동하여 애플리케이션 개발, 배포, 디버깅 환경을 구축하는 절차를 정리합니다. IBM WebSphere Developer Tools(WDT) 플러그인 설치 및 서버 런타임 구성 과정을 포함합니다.

Test Environment

OS: Windows 10
IDE: Eclipse IDE for Enterprise Java Developers (2020-06 이상 권장)
Middleware: WebSphere Liberty Profile (Kernel or Core)

1. 사전 준비 (Prerequisites)

Liberty 개발 환경을 구축하기 위해서는 Java SDK와 Eclipse가 미리 설치되어 있어야 합니다.

JDK: 1.8 이상 설치 및 환경 변수(JAVA_HOME) 설정.
Eclipse: 'Eclipse IDE for Enterprise Java and Web Developers' 패키지 사용 권장.

2. WebSphere Developer Tools (WDT) 플러그인 설치

Eclipse에서 Liberty 서버를 제어하기 위해서는 전용 플러그인을 설치해야 합니다.

설치 절차

Eclipse 메뉴에서 Help > Eclipse Marketplace...를 선택합니다.
검색창에 IBM Liberty 또는 WebSphere Developer Tools를 입력합니다.
"IBM Liberty Developer Tools" 항목을 찾아 Install 버튼을 클릭합니다.
라이선스 동의 후 설치를 진행하며, 완료 후 Eclipse를 재시작합니다.

3. Liberty 런타임(Runtime) 등록

이미 설치된 Liberty Core를 Eclipse에 등록하거나, Eclipse를 통해 새로 다운로드할 수 있습니다.

서버 등록 과정

Servers 뷰에서 우클릭 > New > Server 선택.
서버 타입에서 IBM > WebSphere Liberty 선택.
Server's host name은 localhost, Server name은 식별 가능한 이름 입력.
Runtime Environment 설정 단계:
- 기존 설치된 경우: 'Choose an existing installation' 선택 후 Liberty 설치 경로(wlp 폴더) 지정.
- 새로 설치할 경우: 'Install from an archive or a repository' 선택 후 원하는 버전 다운로드.
Finish를 클릭하여 설정을 완료합니다.

4. 서버 구동 및 애플리케이션 배포

설정이 완료되면 Eclipse 내에서 서버를 제어할 수 있습니다.

서버 제어

Start: Servers 뷰에서 서버 우클릭 > Start (또는 Debug).
Console 확인: CWWKF0011I: The server defaultServer is ready to run a smarter planet. 메시지가 뜨면 정상 구동된 것입니다.

프로젝트 배포

Dynamic Web Project 생성.
프로젝트 우클릭 > Run As > Run on Server.
등록한 Liberty 서버를 선택하고 Finish.
server.xml에 애플리케이션 구성이 자동으로 추가되며 배포가 진행됩니다.

5. 참고 영상 (Reference Video)

실제 설치 및 구동 과정에 대한 데모 영상입니다.

Next Step:
개발 환경 구축이 완료되었다면, server.xml 파일의 <featureManager> 섹션을 수정하여 필요한 기능(JSP, Servlet, JDBC 등)을 활성화하는 방법을 학습해 보십시오.

Read Log →

#tomcat

[Tomcat] Windows 환경 Apache Tomcat 9 설치 및 디렉토리 구조 완벽 가이드

Windows 10 환경에서 Java 기반 웹 애플리케이션 서버인 Apache Tomcat 9을 설치하는 과정을 정리합니다. JDK 설치 확인부터 다운로드, 압축 해제, 그리고 주요 디렉토리(bin, conf, logs)의 역할과 구동 테스트까지 다룹니다.

0. 사전 준비 (Prerequisites)

Tomcat은 Java로 구동되므로 JDK(Java Development Kit)가 필수입니다. 설치 전 반드시 Java 환경 변수가 설정되어 있는지 확인해야 합니다.

Java 설치 확인

:: CMD 창에서 확인
java -version
javac -version

Check Point: 버전 정보가 출력되지 않는다면 JDK를 먼저 설치하고, 시스템 환경 변수(JAVA_HOME, PATH)를 설정해야 합니다. Tomcat은 실행 시 JAVA_HOME을 참조합니다.

1. 다운로드 및 설치 (Download & Install)

설치형(Installer)보다는 압축형(Zip)을 사용하는 것이 디렉토리 관리가 용이하고, 여러 버전을 동시에 관리하기 좋습니다.

다운로드

공식 사이트: http://tomcat.apache.org/
버전 선택: Tomcat 9 (Latest Stable) > Binary Distributions > Core: zip (64-bit/32-bit Windows)

설치 (압축 해제)

다운로드한 Zip 파일을 원하는 경로에 압축 해제하는 것만으로 설치는 끝납니다.

설치 경로 예시: E:\APP\WAS\TOMCAT9

2. 주요 디렉토리 구조 (Directory Structure)

압축을 해제하면 다음과 같은 폴더 구조를 볼 수 있습니다. 각 폴더의 역할을 이해하는 것이 WAS 운영의 첫걸음입니다.

디렉토리	역할 및 주요 파일
/bin	서버 실행 및 종료 스크립트가 위치합니다. - `startup.bat`: 서버 시작 (Windows) - `shutdown.bat`: 서버 중지 (Windows) - `catalina.bat`: 실행 환경 변수 및 옵션 설정
/conf	서버 전체 설정 파일이 위치합니다. - `server.xml`: 포트(8080, 8009), 엔진 설정 - `web.xml`: 세션 타임아웃, MIME 타입 등 공통 설정
/lib	Tomcat 구동에 필요한 라이브러리(Jar) 저장소 (JDBC 드라이버 등 포함)
/logs	서버 로그가 저장됩니다. - `catalina.yyyy-mm-dd.log`: 엔진 로그 - `localhost_access_log`: 접속 로그
/webapps	웹 애플리케이션(WAR 파일)을 배포하는 기본 경로입니다.

3. 구동 및 검증 (Start & Verify)

설치가 제대로 되었는지 서버를 켜서 확인합니다.

서버 구동

:: bin 디렉토리로 이동
cd E:\APP\WAS\TOMCAT9\bin

:: 실행 스크립트 동작
startup.bat

새로운 CMD 창이 뜨면서 로그가 올라가고, 마지막에 Server startup in [xxx] ms 메시지가 보이면 구동 성공입니다.

접속 테스트

브라우저를 열고 http://localhost:8080 에 접속합니다. 고양이 그림이 있는 Tomcat 기본 페이지가 뜬다면 정상적으로 설치된 것입니다.

Next Step:
기본 설치가 완료되었습니다. 다음 포스팅에서는 server.xml을 수정하여 HTTP 포트를 변경하거나, 인코딩 설정을 추가하는 Tomcat 기본 설정 튜닝에 대해 알아보겠습니다.

Read Log →

#IBM HTTPServer

[IHS] SSL/TLS 보안 강화: Protocol 비활성화 및 Cipher Suite 화이트리스트 설정

IBM HTTP Server(IHS)는 Apache 기반이지만, SSL 모듈은 별도의 mod_ibm_ssl을 사용합니다. 따라서 커뮤니티 Apache(mod_ssl)와 프로토콜 설정 문법이 상이합니다. 두 서버 간의 설정 차이를 비교하고, IHS v8.5 환경에서의 보안 강화 설정을 정리합니다.

[Image of SSL TLS handshake process]

1. Apache vs IHS 설정 차이점 (Comparison)

두 웹 서버는 SSL/TLS 핸드쉐이크를 처리하는 엔진과 모듈이 다르기 때문에, httpd.conf에 작성하는 지시어(Directive)가 다릅니다. 마이그레이션이나 운영 시 혼동하지 않도록 주의해야 합니다.

구분	Apache HTTP Server (Community)	IBM HTTP Server (IHS)
사용 모듈	`mod_ssl` (OpenSSL 기반)	`mod_ibm_ssl` (IBM GSKit 기반)
프로토콜 설정	`SSLProtocol` (한 줄로 제어)	`SSLProtocolDisable` `SSLProtocolEnable` (개별 제어)
Cipher 설정	`SSLCipherSuite`	`SSLCipherSpec`

설정 문법 비교 예시

Apache (mod_ssl)

# 모든 프로토콜에서 SSLv2, SSLv3 제외
SSLProtocol all -SSLv2 -SSLv3

# Cipher Suite 설정 (OpenSSL 명명규칙 사용)
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

IHS (mod_ibm_ssl)

# 개별적으로 활성/비활성 지정
SSLProtocolDisable SSLv2
SSLProtocolDisable SSLv3
SSLProtocolEnable TLSv12

# Cipher Spec 설정 (Long Name 사용, 초기화 후 추가 방식 권장)
SSLCipherSpec ALL NONE
SSLCipherSpec ALL +TLS_RSA_WITH_AES_128_CBC_SHA

2. IHS 보안 설정 가이드 (Configuration)

IHS v8.5 이상 환경에서 취약한 프로토콜을 차단하고 안전한 Cipher만 허용하는 설정입니다.

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443

# IP 기반 가상 호스트 활성화 (IHS 8.5 이하 필수)
NameVirtualHost *:443

<VirtualHost *:443>
    ServerName www.example.com
    DocumentRoot /app/EAR/SSL
    
    # SSL 엔진 활성화
    SSLEnable
    
    # 1. 취약 프로토콜 명시적 비활성화
    # (TLS 1.0, 1.1도 보안 정책에 따라 차단 고려)
    SSLProtocolDisable SSLv2
    SSLProtocolDisable SSLv3
    SSLProtocolDisable TLSv10
    SSLProtocolDisable TLSv11
    
    # 2. 안전한 프로토콜 활성화
    SSLProtocolEnable TLSv12
    
    # 3. Cipher Suite 화이트리스트 설정
    # 중요: 'ALL NONE'으로 기존 설정 초기화
    SSLCipherSpec ALL NONE
    
    # Forward Secrecy(PFS)를 지원하는 ECDHE 계열 우선 배치
    SSLCipherSpec ALL +TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    SSLCipherSpec ALL +TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 +TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    
    # 호환성을 위한 RSA/AES 계열 추가
    SSLCipherSpec ALL +TLS_RSA_WITH_AES_256_CBC_SHA +TLS_RSA_WITH_AES_128_CBC_SHA
</VirtualHost>

KeyFile /SW/web/HTTPServer/key/key.kdb
SSLDisable

3. 설정 검증 (Verification)

설정 적용 후 IHS를 재기동하기 전, 명령어를 통해 적용된 Cipher 목록을 확인합니다.

적용된 Cipher 확인

cd [IHS_HOME]/bin
./apachectl -t -D DUMP_SSL_CONFIG

접속 테스트 (nmap)

외부에서 스캔하여 취약한 프로토콜(SSLv3 등)이 노출되지 않는지 교차 검증합니다.

nmap --script ssl-enum-ciphers -p 443 [Target_IP]

Next Step:
IHS 9.0 (Apache 2.4 기반)으로 업그레이드할 경우, SSLProtocol 지시어를 Apache 스타일로 사용할 수 있게 되지만, 기존 IHS 설정과의 호환성을 위해 IBM 문서를 반드시 참조하시기 바랍니다.

Read Log →

#apache#IBM HTTPServer

[Apache/IHS] IP 접속 및 미등록 도메인 요청 차단 설정 (Default VirtualHost)

Apache(IHS) 웹 서버에서 도메인명이 아닌 IP 주소로 접속하거나, ServerName에 정의되지 않은 요청이 들어올 경우 이를 차단하거나 에러 페이지를 보여주는 방법을 정리합니다. 가장 먼저 로딩되는 Dummy VirtualHost를 활용하는 것이 핵심입니다.

0. 배경 지식 (Context)

Apache는 클라이언트 요청의 Host 헤더와 일치하는 ServerName(또는 ServerAlias)을 찾지 못할 경우, 설정 파일에서 가장 먼저 정의된 VirtualHost를 기본값(Default)으로 사용하여 요청을 처리합니다.

이 원리를 이용하여, 최상단에 아무런 ServerName을 갖지 않는(혹은 더미 값을 가진) VirtualHost를 배치하고 403 Forbidden 등을 반환하게 하면, 지정된 도메인 외의 모든 접근을 차단할 수 있습니다.

Test Environment

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

1. httpd.conf 설정 (VirtualHost 구성)

핵심은 순서입니다. 차단용(Dummy) 설정을 정상 서비스 설정보다 반드시 위쪽에 작성해야 합니다.

1) 기본 설정 및 포트 리슨

Listen 80
Listen 4958

# Apache 2.2 / IHS 8.5 이하 필수 (IP 기반 가상호스트 활성화)
NameVirtualHost *:80
NameVirtualHost *:4958

2) 차단용 Dummy VirtualHost (최상단 배치)

이 블록에는 ServerName을 지정하지 않거나 의미 없는 값을 넣습니다. 이곳으로 들어오는 요청은 모두 에러 메시지를 반환합니다.

# [80 포트] 미등록 도메인/IP 접속 차단
<VirtualHost *:80>
    DocumentRoot /app/was/htdocs
    
    # 접근 거부 메시지 설정 (보안상 상세 정보 숨김 권장)
    ErrorDocument 403 "Forbidden: Access is denied."
    ErrorDocument 404 "Not Found."
    ErrorDocument 500 "Internal Server Error."
    
    # 모든 요청에 대해 403 Forbidden 강제 반환 (mod_rewrite 사용 시)
    # RewriteEngine On
    # RewriteRule .* - [R=403,L]
    
    # 또는 디렉토리 접근 권한 제어
    <Directory "/app/was/htdocs">
        Order allow,deny
        Deny from all
    </Directory>
</VirtualHost>

# [4958 포트] 미등록 도메인/IP 접속 차단
<VirtualHost *:4958>
    DocumentRoot /app/was/htdocs
    ErrorDocument 403 "Forbidden: Access is denied."
    # ... (상동)
</VirtualHost>

3) 실제 서비스 VirtualHost

정상적인 도메인(ServerName)을 가진 요청만 처리하는 블록입니다. Proxy 설정을 포함합니다.

# Reverse Proxy 사용 시 Open Relay 방지
ProxyRequests Off

# [80 포트] 정상 서비스
<VirtualHost *:80>
    ServerName test.apache.com
    
    # WAS 또는 백엔드 서버로 프록시
    ProxyPass / http://172.31.98.155/ Keepalive=on
    ProxyPassReverse / http://172.31.98.155/
    
    # Host 헤더 유지 (WAS가 도메인을 인식하도록 함)
    ProxyPreserveHost On
    
    ErrorLog /app/was/HTTPServer/logs/test_proxy_error.log
    CustomLog /app/was/HTTPServer/logs/test_proxy_access.log combined
</VirtualHost>

# [4958 포트] 정상 서비스
<VirtualHost *:4958>
    ServerName test.httpserver.com
    
    ProxyPass / http://172.31.98.209/ Keepalive=on
    ProxyPassReverse / http://172.31.98.209/
    ProxyPreserveHost On
    
    ErrorLog /app/was/HTTPServer/logs/http_proxy_error.log
    CustomLog /app/was/HTTPServer/logs/http_proxy_access.log combined
</VirtualHost>

Tip: ProxyPreserveHost On 옵션은 클라이언트가 요청한 도메인 정보(Host Header)를 백엔드 서버(WAS)까지 그대로 전달합니다. WAS에서 가상 호스트를 구분해야 한다면 필수 옵션입니다.

2. 검증 (Verification)

설정 적용 후 웹 서버를 재기동하고 curl을 이용하여 테스트합니다.

1) 정상 도메인 접속 테스트

# 정상 응답(200 OK)이 와야 함
curl -v -H "Host: test.apache.com" http://localhost:80/

2) IP 접속 및 미등록 도메인 테스트

# 1. IP로 직접 요청 -> 403 또는 설정한 에러 메시지 출력되어야 함
curl -v http://localhost:80/

# 2. 엉뚱한 도메인 요청 -> 403 출력되어야 함
curl -v -H "Host: unknown.com" http://localhost:80/

Next Step:
Apache 2.4 (IHS 9.0 이상)를 사용 중이라면, NameVirtualHost 지시어는 더 이상 필요하지 않으므로 삭제하고, 접근 제어 구문을 Require all denied 등으로 변경해야 합니다.

Read Log →

#command#Linux

[Linux] CentOS 7 호스트네임(Hostname) 영구 변경 및 필수 후속 조치 (hostnamectl)

CentOS 7 및 systemd 기반 리눅스 시스템에서 hostnamectl 명령어를 사용하여 호스트네임을 영구적으로 변경하는 방법을 정리합니다. 변경 후 쉘 프롬프트에 즉시 반영하는 방법과 /etc/hosts 파일 수정의 중요성을 포함합니다.

0. 배경 지식 (Context)

호스트네임은 네트워크 상에서 서버를 식별하는 이름입니다. 과거에는 /etc/sysconfig/network 파일을 수정하고 재부팅해야 했으나, CentOS 7부터는 hostnamectl 명령어를 통해 재부팅 없이 즉시 설정을 영구 반영할 수 있습니다.

Test Environment

OS: CentOS 7.2
System: systemd based

1. 호스트네임 변경 (hostnamectl)

hostnamectl 명령은 커널 호스트네임 설정과 /etc/hostname 파일 수정을 동시에 수행합니다.

현재 상태 확인

hostnamectl status

변경 명령어

# 구문: hostnamectl set-hostname [새로운_이름]
hostnamectl set-hostname web-server-01

2. 변경 사항 확인 및 적용 (Verification)

명령어 실행 즉시 시스템 설정은 변경되지만, 현재 로그인된 터미널의 프롬프트(Shell Prompt)에는 반영되지 않을 수 있습니다.

변경 확인

# 1. 설정값 확인
hostname

# 2. 상세 확인
hostnamectl status

터미널 프롬프트 갱신

로그아웃 후 다시 로그인(Reconnect)하면 프롬프트가 변경됩니다. 재접속 없이 바로 확인하려면 아래 명령어를 사용하세요.

# 현재 쉘 세션 갱신
exec bash

결과: [root@old-name ~]# 에서 [root@web-server-01 ~]# 로 변경됨.

3. 필수 후속 조치: /etc/hosts 수정

호스트네임을 변경했다면, 서버 자신이 자신의 이름을 찾아갈 수 있도록 로컬 DNS 설정 파일인 /etc/hosts도 반드시 수정해야 합니다. 이를 누락하면 sudo 명령어 실행이 느려지거나 일부 애플리케이션 기동 시 에러가 발생할 수 있습니다.

파일 수정

vi /etc/hosts

수정 내용

기존 호스트네임이 적힌 부분을 새로운 이름으로 변경하거나 추가합니다.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

# 변경된 호스트네임 추가 (자신의 IP 또는 Loopback에 매핑)
127.0.0.1   web-server-01

Tip: 클러스터링(Cluster) 환경이나 WAS(WebSphere, JBoss) 환경에서는 127.0.0.1 대신 실제 서버의 공인 IP(또는 사설 IP)에 호스트네임을 매핑하는 것이 좋습니다.

Read Log →