A boring day ~

#command#Linux

[Linux] zip/unzip 설치 및 명령어 사용법 (Password 설정, Legacy Unix 수동 설치)

Linux 및 Unix 환경에서 zip 포맷을 다루기 위한 설치 방법과 명령어 사용법을 정리합니다. yum을 이용한 간편 설치부터 패스워드 설정 방법, 그리고 패키지 매니저를 사용할 수 없는 Legacy Unix 환경(AIX, Solaris 등)에서의 수동 설치 절차를 포함합니다.

1. 패키지 설치 (Installation)

CentOS, RHEL 등 일반적인 리눅스 배포판에서는 패키지 매니저를 통해 손쉽게 설치할 수 있습니다.

설치 확인 및 설치

# 설치 여부 확인
rpm -qa | grep zip

# 패키지 설치 (root 권한 필요)
yum install zip unzip

2. zip 명령어 (압축하기)

파일이나 디렉토리를 .zip 포맷으로 압축합니다.

기본 구문

# 형식
zip [옵션] [생성할파일명.zip] [대상파일_또는_디렉토리]

사용 예시

# 1. 디렉토리 재귀적 압축 (-r 옵션 필수)
# directory 폴더 하위의 모든 파일을 name.zip으로 압축
zip -r name.zip directory

# 2. 패스워드 설정 압축 (-P 옵션)
# 보안상 주의: 명령어 히스토리에 패스워드가 남을 수 있음
zip -P [password] -r name.zip directory

3. unzip 명령어 (압축 해제)

.zip 파일의 압축을 해제합니다.

기본 구문

# 형식
unzip [파일명.zip]

사용 예시

# 1. 기본 압축 해제
unzip filename.zip

# 2. 특정 디렉토리에 압축 해제 (-d 옵션)
unzip filename.zip -d /target/path

# 3. 패스워드가 걸린 파일 해제
# 방법 A: 명령어 입력 시 패스워드 입력 (히스토리 노출 위험)
unzip -P [password] filename.zip

# 방법 B: 명령어 실행 후 인터랙티브하게 입력 (권장)
unzip filename.zip
# (Enter password 프롬프트 출력 시 입력)

4. Legacy Unix 수동 설치 (Manual Installation)

인터넷 연결이 제한적이거나 패키지 매니저가 없는 Unix 환경(AIX, HP-UX, Solaris 등)에서는 Oracle 등에서 제공하는 바이너리를 수동으로 설치해야 합니다.

바이너리 다운로드

각 플랫폼에 맞는 unzip 유틸리티를 다운로드합니다. (Oracle Data Server 9i Release 2 기준 레거시 자료)

Compaq Tru64 UNIX
Compaq OpenVMS (Alpha)
HP-UX 11.0
IBM RS/6000 AIX
LINUX Intel
Sun SPARC Solaris

Note: 최신 버전의 소스 코드는 Info-ZIP 공식 홈페이지에서 확인할 수 있습니다.

UNIX 플랫폼 설치 절차

바이너리 파일을 다운로드하여 Binary Mode로 서버에 전송합니다.
파일 압축을 해제합니다.
```
% uncompress unzip_<os>
```
실행 파일을 PATH 환경변수가 잡힌 경로(예: /usr/bin, /usr/local/bin)로 이동합니다.
실행 권한을 부여합니다.
```
% chmod 751 unzip_<os>
```
설치된 명령어로 압축을 해제합니다.
```
% unzip_<os> filename.zip
```

Compaq OpenVMS (Alpha) 추가 설정

OpenVMS 환경에서는 유틸리티에 대한 심볼(Symbol) 정의가 필요합니다.

unzip == $disk:[dir]unz550xV-axp.exe

Next Step:
대용량 로그 파일 관리 등을 위해 tar 명령어와 cron을 결합하여 주기적인 백업 스크립트를 작성하는 방법을 학습해 보시길 권장합니다.

Read Log →

#IBM HTTPServer

[IBM HTTPServer] 로그 로테이션(Log Rotation) 설정 (rotatelogs)

IBM HTTPServer(Apache 기반)의 로그 파일이 단일 파일로 무한정 커지는 것을 방지하기 위해 rotatelogs 유틸리티를 사용하여 일(Day) 단위 등으로 로그를 자동 분할(Rotation)하는 설정 방법을 정리합니다.

Test Environment

OS: CentOS 7.2
Web Server: IBM HTTPServer v8.5

1. httpd.conf 설정 수정

IBM HTTPServer는 Apache 기반이므로 내장된 rotatelogs 바이너리를 파이프(|)로 연결하여 로그를 제어할 수 있습니다.

설정 파일 경로

위치: /IBM/HTTPServer/conf/httpd.conf

수정 내용

기존 ErrorLog와 CustomLog 설정을 주석 처리하고, 아래와 같이 파이프라인 구문을 추가합니다. 86400은 초 단위(24시간)를 의미합니다.

# 1. Error Log Rotation 설정
# ErrorLog logs/error_log (기존 주석 처리)
ErrorLog "|/IBM/HTTPServer/bin/rotatelogs /IBM/HTTPServer/logs/error_%Y%m%d.log 86400"

# 2. Access Log Rotation 설정
# CustomLog logs/access_log common (기존 주석 처리)
CustomLog "|/IBM/HTTPServer/bin/rotatelogs /IBM/HTTPServer/logs/access_%Y%m%d.log 86400" common

2. 로그 포맷 스트링 (Format Strings)

로그 파일명 생성 시 날짜 형식을 지정하기 위해 사용하는 주요 포맷 코드입니다.

Format	Description
%Y	4자리 연도 (예: 2024)
%y	2자리 연도 (예: 24)
%m	2자리 월 (01~12)
%d	2자리 일 (01~31)
%H	24시간제 시간 (00~23)
%M	분 (00~59)
%S	초 (00~59)
%a / %A	요일 이름 (단축 / 전체)
%b / %B	월 이름 (단축 / 전체)

Next Step:
설정을 변경한 후에는 반드시 IBM HTTPServer를 재기동(Restart)해야 로그 로테이션 프로세스가 정상적으로 시작됩니다. 재기동 후 logs 디렉토리에 날짜가 붙은 파일이 생성되는지 확인하십시오.

Read Log →

#IBM HTTPServer#security#SSL

[IBM HTTPServer] SSL(HTTPS) 구성 및 가상 호스트 설정 가이드

IBM HTTP Server(IHS)에 SSL 인증서를 적용하여 HTTPS 통신을 활성화하고, WebSphere Application Server(WAS)와 정상적으로 연동하기 위한 설정 절차를 정리합니다. httpd.conf 설정, 키 파일(KDB) 지정, 그리고 WAS 가상 호스트 포트 등록 과정을 포함합니다.

Test Environment

OS: CentOS 7.2 (경로는 Linux 기준, Windows는 드라이브명 참조)
Web Server: IBM HTTP Server v8.5
WAS: WebSphere Application Server v8.5

1. 웹 서버 설정 (httpd.conf)

IHS의 메인 설정 파일에서 SSL 모듈을 로드하고, 443 포트에 대한 VirtualHost를 구성해야 합니다.

설정 파일 수정

파일 위치: [IHS_ROOT]/conf/httpd.conf
주요 작업: 모듈 주석 해제, 포트 리슨, 인증서 키 파일(KDB) 경로 지정

### 1. SSL Module Load ###
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

### 2. Port Listen ###
Listen 0.0.0.0:443

### 3. Virtual Host Configuration ###
# 80 포트 (HTTP) 설정
<VirtualHost *:80>
    ServerName ad1.test.com
    DocumentRoot "/opt/IBM/HTTPServer/htdocs"
    # Redirect permanent / https://ad1.test.com/  (필요 시 HTTPS로 리다이렉트)
</VirtualHost>

# 443 포트 (HTTPS) 설정
<VirtualHost *:443>
    SSLEnable
    SSLClientAuth none
    ServerName ad1.test.com
    DocumentRoot "/opt/IBM/HTTPServer/htdocs"
    
    # 로그 설정 (권장)
    ErrorLog logs/ssl_error_log
    CustomLog logs/ssl_access_log common
</VirtualHost>

### 4. Global SSL Config ###
# VirtualHost 밖에서 전역 설정으로 Keyfile 지정
SSLDisable
Keyfile "/opt/IBM/HTTPServer/ssl/key.kdb"

# 보안 강화를 위한 프로토콜 설정 예시 (TLS 1.2만 허용 시)
# SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
# SSLProtocolEnable TLSv12

Note: Keyfile 지시어는 kdb 파일의 경로를 지정합니다. 해당 경로에 key.sth (Stash file)이 함께 존재해야 암호를 묻지 않고 구동됩니다.

2. 인증서 키 파일 (KDB) 준비

IHS는 CMS Key Database (.kdb) 포맷을 사용합니다. ikeyman GUI 툴이나 gskcapicmd(CLI)를 사용하여 개인키와 인증서를 관리합니다.

도구 위치: [IHS_ROOT]/bin/ikeyman (GUI 실행 시 X-Window 필요)
작업 내용:
- 새로운 KDB 파일 생성 (CMS 타입)
- 개인키 생성 (CSR) 및 발급받은 인증서(Signer, Personal) Import
- 중요: "Stash password to a file" 옵션을 체크하여 .sth 파일 생성 필수

3. WAS 가상 호스트 (Virtual Host) 등록

웹 서버 설정을 마쳤더라도, WAS의 가상 호스트 목록에 SSL 포트(443)가 등록되어 있지 않으면 플러그인이 요청을 거부하거나 WAS가 요청을 인식하지 못할 수 있습니다.

관리 콘솔 설정

위치: 환경(Environment) > 가상 호스트(Virtual Hosts) > default_host (또는 사용하는 가상 호스트) > 호스트 별명(Host Aliases)
작업: 새로 작성(New) 클릭
입력:
- 호스트 이름: * (모든 호스트) 또는 ad1.test.com
- 포트: 443
저장: 마스터 구성에 저장 후 변경 사항 동기화.

4. 검증 및 재기동

설정 파일의 문법 오류를 체크하고 웹 서버를 재기동하여 변경 사항을 적용합니다.

Syntax Check

# IHS bin 디렉토리로 이동
./apachectl -t

# 결과가 'Syntax OK'여야 함

Server Restart

./apachectl restart

Next Step:
브라우저에서 https://ad1.test.com으로 접속하여 자물쇠 아이콘이 정상적으로 표시되는지 확인하고, SSL Labs 등의 도구를 통해 적용된 암호화 프로토콜(TLS 1.2 등)의 보안 등급을 점검해보시기 바랍니다.

Read Log →

#WebSphere

[WebSphere] Hostname, Node Name, Cell Name 변경 가이드 (wsadmin vs 수동 설정)

서버 이관(Migration)이나 네트워크 구성 변경으로 인해 WebSphere 환경의 Hostname, Node Name, Cell Name을 변경해야 할 때가 있습니다. IBM 권장 방식인 wsadmin을 이용한 방법과, 설정 파일을 직접 수정하는 수동 방법을 정리합니다.

1. Hostname 변경

서버의 물리적 호스트명이 변경되었을 때, WAS 설정 내의 serverindex.xml 등 엔드포인트 정보를 갱신해야 합니다.

Method 1: wsadmin 사용 (IBM 권장)

IBM에서 권장하는 가장 안전한 방식입니다. AdminTask 객체를 사용하여 변경 사항을 저장소에 반영합니다.

# 1. wsadmin 접속 (Dmgr 구동 필요)
cd [Profile_Root]/bin
./wsadmin.sh -conntype NONE -lang jython

# 2. Hostname 변경 명령 수행
wsadmin> AdminTask.changeHostName('[-nodeName [노드명] -hostName [새로운_호스트명]]')

# 3. 저장 및 종료
wsadmin> AdminConfig.save()
wsadmin> quit

Note: ND(Network Deployment) 환경인 경우 작업 후 반드시 syncNode를 수행해야 합니다.

Method 2: serverindex.xml 수동 변경 (비상 시)

wsadmin 사용이 불가능하거나 특정 노드만 강제로 수정해야 할 때 사용합니다. serverindex.xml 파일에는 각 포트의 EndPoint Host 정보가 담겨 있습니다.

대상 파일 위치:

ND (Dmgr): [WAS_HOME]/profiles/[DmgrProfile]/config/cells/[CellName]/nodes/[NodeName]/serverindex.xml
Base (AppSrv): [WAS_HOME]/profiles/[AppProfile]/config/cells/[CellName]/nodes/[NodeName]/serverindex.xml

일괄 변경 스크립트 예시 (Shell):

#!/bin/sh
# 사용법: ./change_host.sh [새로운_호스트명]

OLD_HOST="target_old_hostname"
NEW_HOST=$1

find ./AppServer -type f -name "serverindex.xml" | while read file
do
    echo "Processing $file ..."
    sed "s/$OLD_HOST/$NEW_HOST/g" "$file" > "${file}.tmp" && mv "${file}.tmp" "$file"
done

2. Node Name 변경

기존에 생성된 노드의 이름을 변경할 때는 WAS에서 제공하는 renameNode 스크립트를 사용합니다.

작업 절차

Dmgr 구동: Deployment Manager가 실행 중이어야 합니다.
Node 정지: 이름을 변경할 노드의 모든 프로세스를 중지합니다.
명령어 실행: 해당 프로파일의 bin 디렉토리에서 실행합니다.

# 구문
renameNode.sh [Dmgr_Host] [Dmgr_SOAP_Port] [새로운_노드명] -username [ID] -password [PW]

# 사용 예시
cd /IBM/WAS/profiles/AppSrv01/bin
./renameNode.sh 192.168.1.10 8879 NewNode01 -username admin -password admin

3. Cell Name 및 Dmgr Node 변경 (Advanced)

Cell 이름 변경이나 Dmgr 자체의 Node 이름 변경은 별도의 스크립트가 제공되지 않으며, **다수의 설정 파일을 수동으로 편집(Manual Editing)**해야 합니다. 작업 전 전체 백업이 필수입니다.

변경 대상 파일 리스트

아래 파일들 내부의 기존 Cell/Node 이름을 새로운 이름으로 변경하고, 디렉토리 이름도 변경해야 합니다.

디렉토리 이름 변경:
- config/cells/[Old_Cell_Name] → [New_Cell_Name]
- config/cells/[New_Cell_Name]/nodes/[Old_Node_Name] → [New_Node_Name]
설정 파일 내용 수정 (String Replace):
- cell.xml
- node.xml
- security.xml
- variables.xml
- resources.xml
- setupCmdLine.bat (or .sh)
- coregroup.xml (DefaultCoreGroup 경로 하위)
- nodegroup.xml (DefaultNodeGroup 경로 하위)

주의: Admin Console 애플리케이션(isclite) 관련 설정 파일(deployment.xml 등)도 수정 대상에 포함될 수 있으나, 매우 복잡하므로 가급적 프로파일을 재생성하는 것을 권장합니다.

4. 후속 조치 (Post-Process)

모든 이름 변경 작업이 완료된 후에는 다음 절차를 수행하여 변경 사항을 전파해야 합니다.

Sync Node: (ND 환경) syncNode.sh를 실행하여 변경된 설정을 로컬 노드에 동기화.
플러그인 재생성: 웹 서버 플러그인(plugin-cfg.xml)을 재생성 및 전파.
웹 서버 재기동: IHS 등 웹 서버 재기동.

# 웹 서버 재기동 예시
[IHS_HOME]/bin/apachectl restart

Read Log →

#IBM HTTPServer#WebSphere

[WebSphere] WEB/WAS 정적(Static) 및 동적(Dynamic) 컨텐츠 분리 처리 전략

웹 시스템 성능 최적화를 위해 이미지, CSS, JS 등 정적 리소스는 Web Server(IHS)가 처리하고, JSP, Servlet 등 동적 리소스는 WAS가 처리하도록 역할을 분리하는 방법을 정리합니다. plugin-cfg.xml 제어 방식과 WAS의 fileServingEnabled 옵션 사용법을 다룹니다.

Test Environment

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

1. 개요 및 목적

기본적으로 WebSphere 플러그인은 모든 요청을 WAS로 전달하도록 구성될 수 있습니다. 하지만 정적 파일(*.jpg, *.css 등)까지 WAS가 처리하게 되면 컨테이너의 스레드 자원을 낭비하게 됩니다. 따라서 이를 분리하여 시스템 효율성을 높여야 합니다.

2. Method 1: Plugin-cfg.xml 수동 제어

가장 직관적인 방법은 웹 서버 플러그인 설정 파일(plugin-cfg.xml)에서 WAS로 넘길 요청의 패턴(URI)을 강제로 지정하는 것입니다.

설정 파일 수정

파일 위치: [IHS_ROOT]/Plugins/config/[WebServerName]/plugin-cfg.xml
수정 내용: UriGroup 내에서 WAS가 처리해야 할 확장자만 남기고 나머지는 제거하거나 주석 처리합니다.

<UriGroup Name="default_host_server1_root-PCNode01_Cluster_URIs">
    <!-- WAS가 처리할 동적 컨텐츠만 명시 -->
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.do"/>
    <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
</UriGroup>

위와 같이 설정하면 명시되지 않은 이미지나 HTML 파일 등은 플러그인을 타지 않고 웹 서버(IHS)가 자신의 DocumentRoot 또는 Alias 경로에서 파일을 찾아 처리합니다.

3. Method 2: WAS fileServingEnabled 옵션 사용

WebSphere 애플리케이션 배포 설정에서 정적 파일 서빙 기능을 비활성화(False)하여, 플러그인 생성 시 정적 파일에 대한 URI 매핑을 자동으로 제외하는 방법입니다.

설정 파일 위치 및 수정

애플리케이션의 WEB-INF 디렉터리에 있는 확장 설정 파일을 수정합니다.

경로 예시: [Profile_Root]/installedApps/[CellName]/[AppName].ear/[WarName].war/WEB-INF/

1) ibm-web-ext.xmi (구버전 스타일)

<webappext:WebAppExtension ... fileServingEnabled="false" ...>
</webappext:WebAppExtension>

2) ibm-web-ext.xml (WAS v7.0 이상 권장)

<web-ext xmlns="http://websphere.ibm.com/xml/ns/javaee/web-ext/1.0" ...>
    <!-- 정적 파일 서빙 비활성화 -->
    <enable-file-serving value="false"/>
</web-ext>

적용 절차

설정 파일 수정 (fileServingEnabled="false")
WAS 관리 콘솔에서 플러그인 재생성 (Generate Plug-in)
재생성된 plugin-cfg.xml을 웹 서버로 전파 (Propagate)

이 과정을 거치면 plugin-cfg.xml 내에 정적 파일(*.html, *.jpg 등)에 대한 URI 정의가 자동으로 삭제됩니다.

4. WebServer (IHS) Alias 설정

WAS로 요청이 넘어가지 않는 정적 파일들을 웹 서버가 찾아서 제공할 수 있도록 물리적 경로를 매핑해야 합니다.

httpd.conf 설정

파일 위치: [IHS_ROOT]/conf/httpd.conf
설정 예시: URL의 /images 요청을 실제 서버의 /home/images 디렉터리로 연결

# 정적 리소스 경로 매핑
Alias /images /home/images

<Directory "/home/images">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

5. 요약 및 주의사항

Full URI 패턴 주의: plugin-cfg.xml에 Name="*" 와 같은 설정이 있다면 모든 요청이 WAS로 넘어갑니다. 성능 저하의 주원인이므로 삭제해야 합니다.
동기화: fileServingEnabled 옵션을 변경했다면 반드시 플러그인을 재생성 및 전파하고 웹 서버를 재기동(Restart) 해야 적용됩니다.
배포 전략: 정적/동적 분리 구성 시, 개발팀은 정적 리소스(이미지 등)를 WAS 배포 패키지(WAR/EAR)와 별도로 웹 서버 경로에 배포하는 프로세스를 수립해야 합니다.

Next Step:
구성이 완료되었다면 브라우저 개발자 도구(F12)의 Network 탭을 통해 정적 파일 요청 시 Response Header에 Server: IBM_HTTP_Server가 찍히는지(WAS 정보가 아닌지) 확인하여 분리 처리가 정상적인지 검증해보십시오.

Read Log →

#WebSphere

[WebSphere] 한글 깨짐 현상 조치 가이드 (Encoding 설정)

WebSphere Application Server(WAS)에서 한글이 깨져 보일 때 확인해야 할 인코딩 설정을 정리합니다. 애플리케이션 소스 코드(JSP/HTML) 레벨의 명시적 선언과 JVM 레벨의 시스템 프로퍼티 설정을 모두 점검해야 합니다.

Test Environment

OS: CentOS 7.2
WAS Version: WebSphere v8.5

1. 소스 코드 레벨 설정 (Application Level)

웹 애플리케이션 서버는 기본적으로 소스 코드 상단에 선언된 인코딩 설정을 최우선으로 인식합니다. JSP와 HTML 파일에 인코딩이 명시적으로 선언되어 있는지 확인합니다.

JSP 지시어 (Directive) 선언

JSP 파일 최상단에 pageEncoding과 contentType을 일치시켜 선언합니다. (최근 환경은 UTF-8 권장, 레거시 시스템은 EUC-KR 사용)

<!-- UTF-8 설정 (권장) -->
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

<!-- EUC-KR 설정 (Legacy) -->
<%@ page language="java" contentType="text/html; charset=EUC-KR" %>

HTML Meta 태그 선언

브라우저가 문서를 해석할 때 사용할 문자셋을 지정합니다.

<!-- UTF-8 설정 -->
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">

<!-- EUC-KR 설정 -->
<META http-equiv="Content-Type" content="text/html; charset=EUC-KR">

2. 서버 레벨 설정 (JVM Custom Properties)

소스 코드 설정이 올바름에도 불구하고 한글이 깨지거나, 시스템 로그 및 파일 입출력 시 인코딩 문제가 발생할 경우 WAS의 JVM 속성을 강제해야 합니다.

설정 경로

WAS 관리 콘솔(Admin Console)에서 아래 경로로 이동합니다.

Servers > Server Types > WebSphere application servers
[Server Name] 클릭
Java and Process Management > Process definition
Java Virtual Machine > Custom properties

주요 속성 설정

사용하는 인코딩 방식(UTF-8 또는 EUC-KR)에 맞춰 아래 두 가지 속성을 추가합니다.

client.encoding.override: 클라이언트(브라우저)와 통신 시 사용할 인코딩 강제 지정
file.encoding: JVM이 파일 시스템을 읽고 쓸 때 사용할 기본 인코딩 지정

# Case 1: UTF-8 환경 (권장)
client.encoding.override = UTF-8
file.encoding = UTF-8

# Case 2: EUC-KR 환경
client.encoding.override = EUC-KR
file.encoding = EUC-KR

3. 점검 포인트

우선순위: 일반적으로 JVM 설정 < web.xml 설정 < JSP/HTML 내 선언 순으로 우선순위를 가집니다.
DB 연동: WAS 설정뿐만 아니라 DB의 Character Set 설정과 JDBC URL의 인코딩 옵션도 일치해야 완벽한 한글 처리가 가능합니다.

Next Step:
위 설정을 적용한 후에는 반드시 해당 서버(인스턴스)를 재기동해야 JVM 설정이 반영됩니다. 재기동 후 `SystemOut.log` 파일에 한글 로그가 정상적으로 기록되는지 확인하십시오.

Read Log →

#JVM#WebSphere

[WebSphere/JVM] HeapDump & JavaCore 생성 옵션 및 경로 변경 가이드

WebSphere Application Server(WAS) 운영 중 Out Of Memory(OOM) 에러 발생 시, 원인 분석을 위해 힙 덤프(HeapDump)와 자바 코어(JavaCore) 파일을 생성해야 합니다. 이를 위한 JVM Custom Properties 설정 방법과 생성 경로 변경, 그리고 AIX 환경에서의 필수 설정 사항을 정리합니다.

1. JVM Custom Properties 설정

WAS 관리 콘솔에서 JVM 인수에 직접 환경 변수를 설정하여 덤프 생성 여부와 경로를 제어할 수 있습니다.

설정 경로

Application servers > [Server Name] > Process definition > Java Virtual Machine > Custom properties

주요 속성 (Key & Value)

Name	Value	Description
IBM_HEAPDUMP	true / false	힙 덤프 생성 활성화 여부
IBM_HEAPDUMP_OUTOFMEMORY	true / false	OOM 발생 시 힙 덤프 자동 생성
IBM_JAVADUMP_OUTOFMEMORY	true / false	OOM 발생 시 자바 코어(Thread Dump) 자동 생성
IBM_JAVA_HEAPDUMP_TEXT	true / false	힙 덤프를 텍스트 형식으로 생성 (phd 대신)
JAVA_DUMP_OPTS	ONANYSIGNAL(JAVADUMP[5],HEAPDUMP[5])	시그널 발생 시 덤프 생성 옵션 제어

2. 덤프 생성 위치 변경 (Dump Path)

기본 생성 위치는 WAS 버전에 따라 다르며, 디스크 공간 부족 등의 이유로 별도 경로로 변경할 수 있습니다.

기본 생성 위치 (Default Path)

WAS V6.0 ~ V7.0: [Profile_Root]/logs/[Server_Name]
WAS V5.1: [Install_Root]/logs/[Server_Name]

경로 변경 설정

위와 동일한 Custom properties 메뉴에서 아래 속성을 추가합니다.

# AIX / Linux 예시 (/waslog 디렉토리로 변경)
IBM_COREDIR       /waslog
IBM_HEAPDUMPDIR   /waslog
IBM_JAVACOREDIR   /waslog

# Windows 예시 (D:\waslogs 디렉토리로 변경)
IBM_COREDIR       D:\waslogs
IBM_HEAPDUMPDIR   D:\waslogs
IBM_JAVACOREDIR   D:\waslogs

3. AIX 환경 필수 설정 (Environment Setup)

AIX 환경에서는 OOM 분석을 위해 OS 레벨의 사용자 제한(ulimit) 해제와 메모리 세그먼트 설정이 중요합니다.

1) 사용자 프로세스 제한 해제 (ulimit)

덤프 파일이 잘리지 않도록 파일 크기(fsize), 코어 크기(core), 데이터 세그먼트(data) 제한을 해제합니다. (root 권한 필요)

# 사용자(user_id)에 대해 제한 해제
chuser fsize=-1 data=-1 core=-1 stack=-1 [WAS_USER_ID]

# 적용 확인 (WAS 사용자 계정으로 로그인 후)
ulimit -a

2) 메모리 할당 방식 설정 (LDR_CNTRL)

Java Heap과 Native Heap을 분리하고 공간을 확보하기 위해 환경 변수를 설정합니다. MAXDATA 값은 Java Heap 크기(Xmx)에 따라 계산해야 합니다.

# 계산 공식: 8 - (Xmx(MB) / 256)
# 예: Xmx가 512MB인 경우 -> 8 - (512/256) = 6 -> 0x60000000

export IBM_JAVA_MMAP_JAVA_HEAP=true
export LDR_CNTRL=MAXDATA=0x60000000

3) GC 로그 활성화

메모리 누수 패턴 분석을 위해 GC 로그를 반드시 활성화해야 합니다. JVM Generic Arguments에 추가합니다.

-verbose:gc

표준 에러(stderr)가 파일로 리다이렉션 되도록 설정되어 있는지 확인하십시오. (native_stderr.log 등)

Next Step:
생성된 .phd 또는 .txt 형식의 힙 덤프 파일은 IBM HeapAnalyzer나 Eclipse Memory Analyzer (MAT) 도구를 사용하여 분석할 수 있습니다.

Read Log →

#WebSphere

[WebSphere] manageprofiles 상세 가이드: 생성, 백업, 복구 및 삭제

WebSphere Application Server(WAS)의 manageprofiles 명령어를 사용하여 프로파일을 생성(Create), 삭제(Delete)하는 방법과 장애 대비를 위한 백업(Backup) 및 복구(Restore) 절차를 상세히 기술합니다.

1. 명령어 개요 및 위치

manageprofiles는 WAS의 인스턴스(프로파일) 생명주기를 관리하는 스크립트입니다.

위치: [WAS_INSTALL_ROOT]/bin
실행 파일: manageprofiles.sh (Unix/Linux) 또는 manageprofiles.bat (Windows)

2. 프로파일 생성 (Create)

서버의 역할에 따라 적절한 -templatePath를 지정해야 합니다.

주요 템플릿 경로 (templatePath)

Dmgr (Deployment Manager): .../profileTemplates/dmgr
AppServer (Managed Node): .../profileTemplates/managed
Default (Standalone Server): .../profileTemplates/default

예제 1: Deployment Manager (Dmgr) 생성

# Unix/Linux Line-breaking 예시
./manageprofiles.sh -create \
  -profileName Dmgr01 \
  -templatePath /IBM/WAS/AppServer/profileTemplates/dmgr \
  -profilePath /IBM/WAS/AppServer/profiles/Dmgr01 \
  -cellName WebSphereCell01 \
  -nodeName WebSphereManager01 \
  -hostName myhostname

예제 2: Application Server (Default) 생성

./manageprofiles.sh -create \
  -profileName AppSrv01 \
  -templatePath /IBM/WAS/AppServer/profileTemplates/default \
  -profilePath /IBM/WAS/AppServer/profiles/AppSrv01 \
  -hostName myhostname

3. 프로파일 백업 (Backup)

프로파일 레지스트리와 파일 시스템 및 메타데이터를 백업합니다. 반드시 해당 프로파일의 모든 프로세스를 정지한 후 수행해야 합니다.

구문

manageprofiles.sh -backupProfile -profileName [프로파일멍] -backupFile [저장할파일경로]

사용 예시

# AppSrv01 프로파일을 백업
./manageprofiles.sh -backupProfile -profileName AppSrv01 -backupFile /backup/AppSrv01_2023.zip

4. 프로파일 복구 (Restore)

백업된 파일을 이용하여 프로파일을 복원합니다. 복구 절차는 단순 덮어쓰기가 아니며, 레지스트리 정합성 검증 과정이 필요합니다.

복구 절차 (Step-by-Step)

프로세스 정지: 복원하려는 프로파일과 관련된 모든 서버 및 프로세스를 중지합니다.
디렉토리 삭제: 파일 시스템에서 기존 프로파일 디렉토리를 수동으로 삭제합니다. (예: rm -rf /IBM/WAS/AppServer/profiles/AppSrv01)
레지스트리 검증: 프로파일 레지스트리 정보를 정리합니다.
```
./manageprofiles.sh -validateAndUpdateRegistry
```
복구 실행: 백업 파일을 사용하여 프로파일을 복원합니다.
```
./manageprofiles.sh -restoreProfile -backupFile /backup/AppSrv01_2023.zip
```

5. 프로파일 삭제 (Delete)

더 이상 사용하지 않는 프로파일을 시스템에서 제거합니다. 삭제 시 관련 디렉토리가 제거되며, 레지스트리 정보가 갱신됩니다.

옵션 설명

-delete: 특정 프로파일 하나를 삭제합니다.
-deleteAll: 등록된 모든 프로파일을 일괄 삭제합니다.

사용 예시

# 특정 프로파일 삭제
./manageprofiles.sh -delete -profileName AppSrv01

# 모든 프로파일 삭제 (주의 요망)
./manageprofiles.sh -deleteAll

Next Step:
프로파일 복구가 완료되었다면, syncNode 명령어를 통해 Dmgr과 로컬 노드 간의 설정 동기화를 수행하여 데이터 불일치 문제를 사전에 방지하십시오.

Read Log →

#WebSphere

[WebSphere] addNode 명령어: 노드 연합(Federation) 및 Dmgr 연동 가이드

addNode 명령어는 Standalone 형태의 프로파일(Profile)을 Deployment Manager(Dmgr)가 관리하는 셀(Cell)에 포함시키는 '연합(Federation)' 작업을 수행합니다. 이를 통해 중앙 집중식 관리가 가능해집니다.

1. 구문 (Syntax)

기본적으로 Dmgr의 호스트와 포트 정보를 필요로 하며, 보안이 설정된 경우 인증 정보가 추가로 요구됩니다.

addNode [Dmgr_Host] [Dmgr_SOAP_Port] [-options]

2. 주요 옵션 (Parameters)

자주 사용되는 핵심 옵션들을 기능별로 분류하였습니다.

필수 및 연결 옵션

-profileName [name]: (권장) 명령을 수행할 로컬 프로파일의 이름을 명시합니다. 다중 프로파일 환경에서는 필수입니다.
-conntype [type]: Dmgr 연결 방식(SOAP, RMI 등). 기본값은 SOAP입니다.
-username [uid] / -password [pwd]: Dmgr에 보안이 설정된 경우 관리자 계정 정보를 입력합니다.

애플리케이션 및 리소스 포함 여부

-includeapps: 노드에 이미 설치된 애플리케이션을 Dmgr 셀 구성에 포함시킵니다. (기본값: 포함 안 함)
-includebuses: 노드의 버스(Bus) 구성을 셀에 포함시킵니다.

노드 설정 옵션

-nodeagentshortname [name]: 생성될 NodeAgent의 이름을 지정합니다.
-startingport [port]: 포트 충돌 방지를 위해 노드 내 서버들의 포트를 지정된 번호부터 시작하도록 변경합니다.
-registerservice: (Windows 전용) NodeAgent를 윈도우 서비스로 등록합니다.

기타 옵션

-noagent: 연합 후 NodeAgent 프로세스를 구동하지 않습니다.
-trace: 디버깅을 위해 상세 트레이스 정보를 출력합니다.
-logfile [filename]: 로그 파일 경로를 지정합니다.

3. 작업 절차 (Procedure)

Step 1: 사전 점검

작업을 수행하기 전, 대상 Deployment Manager(Dmgr)가 반드시 구동(Running) 상태여야 합니다.

Step 2: 경로 이동

연합할 노드(Profile)의 bin 디렉토리로 이동합니다.

# 예시
cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin

Step 3: addNode 실행

Dmgr의 IP와 SOAP 포트(기본값 8879)를 확인하여 명령어를 실행합니다.

# 1. 기본 실행 (보안 미설정 시)
./addNode.sh 192.168.1.10 8879

# 2. 보안 설정 시 (ID/PW 포함)
./addNode.sh 192.168.1.10 8879 -username wasadmin -password wasadmin -includeapps

* Windows 환경에서는 addNode.bat를 사용하십시오.

Step 4: 상태 확인

작업이 성공하면 NodeAgent가 자동으로 시작됩니다. serverStatus 명령어로 상태를 확인합니다.

./serverStatus.sh -all -username [ID] -password [PW]

Next Step:
노드 연합이 완료되었다면, 관리 콘솔에서 '전체 동기화(Full Resynchronize)'를 수행하여 Dmgr과 노드 간의 설정 정보를 일치시키는 것이 좋습니다.

Read Log →

#Plugin#WebSphere

[WebSphere] plugin-cfg.xml 병합 가이드 (pluginCfgMerge 사용법)

여러 개의 WebSphere 프로파일이나 클러스터 환경에서 생성된 plugin-cfg.xml 파일을 하나로 통합해야 할 때 사용하는 pluginCfgMerge 도구의 사용법과 작업 절차를 정리합니다. 또한 수동 병합 시 관리 콘솔에서 변경해야 할 설정을 다룹니다.

1. 플러그인 병합 도구 (Plugin Merge Tool)

WAS 설치 루트의 bin 디렉토리에 위치한 스크립트를 사용하여 두 개의 플러그인 파일을 하나로 병합합니다. WAS 버전에 따라 스크립트 이름이 pluginMerge 또는 pluginCfgMerge일 수 있습니다.

구문 (Syntax)

# 기본 구문
[실행스크립트] [소스파일1] [소스파일2] [결과파일]

운영체제별 실행 경로

Unix / Linux

# WAS 버전에 따라 파일명이 다를 수 있음
[AppServer_Root]/bin/pluginMerge.sh plugin_cfg1.xml plugin_cfg2.xml result_cfg.xml
# 또는
[AppServer_Root]/bin/pluginCfgMerge.sh plugin_cfg1.xml plugin_cfg2.xml result_cfg.xml

Windows

[AppServer_Root]\bin\pluginMerge.bat plugin_cfg1.xml plugin_cfg2.xml result_cfg.xml
# 또는
[AppServer_Root]\bin\pluginCfgMerge.bat plugin_cfg1.xml plugin_cfg2.xml result_cfg.xml

2. 병합 작업 절차 (Workflow)

Step 1: 사전 준비 및 백업

작업 시작 전, 기존에 웹 서버에서 사용 중인 plugin-cfg.xml 파일을 반드시 백업합니다.

# Linux 예시
cp /apps/wes/IBM/plugin-cfg.xml /apps/wes/IBM/plugin-cfg.xml.bak_YYYYMMDD

Step 2: 소스 파일 준비

각 프로파일(또는 노드)에서 최신 plugin-cfg.xml 파일을 새로 생성(Generate)합니다.
병합할 플러그인 파일들을 작업할 한 디렉토리에 모아둡니다.
파일명이 겹치지 않도록 구분하여 변경합니다. (예: plugin-cfg01.xml, plugin-cfg02.xml)

Step 3: 병합 명령어 실행

준비된 두 개의 파일을 병합하여 최종 파일을 생성합니다.

# 예시: plugin-cfg01.xml과 plugin-cfg02.xml을 병합하여 plugin-cfg.xml 생성
./pluginCfgMerge.sh /apps/wes/IBM/plugin-cfg01.xml /apps/wes/IBM/plugin-cfg02.xml /apps/wes/IBM/plugin-cfg.xml

Step 4: 웹 서버 적용

생성된 최종 plugin-cfg.xml 파일을 웹 서버의 플러그인 경로로 복사하고, 필요시 웹 서버를 재기동합니다.

3. WebSphere 관리 콘솔 설정 (필수)

플러그인 파일을 수동으로 병합하여 사용하는 경우, WAS 관리 콘솔에서 자동 생성 및 전파 옵션을 비활성화해야 합니다. 이 옵션이 켜져 있으면 WAS가 자동으로 파일을 재생성하여 수동 병합된 내용을 덮어쓸 위험이 있습니다.

설정 경로

웹 서버(Web Servers) > [웹서버명] > 플러그인 특성(Plug-in properties)

변경 사항

플러그인 구성 파일 자동 생성 (Automatically generate the plug-in configuration file): 체크 해제 (False)
플러그인 구성 파일 자동 전파 (Automatically propagate the plug-in configuration file): 체크 해제 (False)

Note: 위 설정을 적용하면 이후 플러그인 변경 사항이 발생할 때마다 수동으로 병합 및 복사 작업을 수행해야 합니다.

Next Step:
병합된 플러그인 파일이 정상적으로 작동하는지 확인하기 위해, 웹 서버의 http_plugin.log를 모니터링하여 파싱 오류나 로딩 실패 메시지가 없는지 점검하십시오.

Read Log →